ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting July 27th
<awygle> only after Qyriad's message do i understand why the bridge bot is named "d1b2"
<d1b2> <Qyriad> It took me a bit too heh
<_whitenotifier-b> [nmigen-boards] FFY00 commented on issue #89: [RFC] handling boards that are very similar -
<_whitenotifier-b> [nmigen-boards] FFY00 edited a comment on issue #89: [RFC] handling boards that are very similar -
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
<awygle> dang my branch was behind by 34 commits
<awygle> been a while i guess
<awygle> whitequark: ping
<awygle> ... so i just re-read the logs from Monday's meeting and i had the wrong picture in my head of what conclusion we reached for #355... even tho i'm the one who wrote the summary on the issue.
<awygle> derp.
<_whitenotifier-b> [nmigen] awygle opened pull request #449: Implement ValueCastable -
<_whitenotifier-b> [nmigen] awygle commented on pull request #449: Implement ValueCastable -
<_whitenotifier-b> [nmigen] awygle edited a comment on pull request #449: Implement ValueCastable -
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
_whitelogger has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
<whitequark> awygle: pong
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
<awygle> I was gonna ask about 355 but I think I figured it out
<awygle> And I left my remaining question about staging as a comment on the pr
<whitequark> will review later
<awygle> Yup no rush
jeanthom has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
chipmuenk has joined #nmigen
hitomi2505 has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
peepsalot has joined #nmigen
Asu has joined #nmigen
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #88: CI: Setup github actions -
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0]
<_whitenotifier-b> [nmigen/nmigen-boards] rroohhh 1a3f2b8 - CI: Setup github actions
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #88: CI: Setup github actions -
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-b> [nmigen] jeanthom opened pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] whitequark reviewed pull request #450 commit -
<_whitenotifier-b> [nmigen] jeanthom synchronize pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom edited pull request #450: nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom edited pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom commented on pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<jeanthom> Is there a way to force formal in nMigen to consider something as an output and not an input?
<jeanthom> I'm having this issue in, for n=1 there is no assignment to self.grant
<jeanthom> This results in symbiyosys considering self.grant as an input, and therefore my tests fail
<_whitenotifier-b> [nmigen] jeanthom synchronize pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom synchronize pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom synchronize pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom synchronize pull request #450: [WIP] nmigen.lib: Add RoundRobin -
<_whitenotifier-b> [nmigen] jeanthom edited pull request #450: nmigen.lib: Add RoundRobin -
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern1 has quit [Client Quit]
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Disconnected by services]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined #nmigen
<cesar[m]1> Greetings.
<cesar[m]1> I recently started using nMigen, as a contributor to libre-SOC.
<cesar[m]1> At the moment I'm giving feedback (at the user side) to
<whitequark> cesar[m]1: I'm working on it--the issue turned out to be more complex than I expected
<whitequark> might take a few more days
<cesar[m]1> I work at a research institute, developing embedded systems for data acquisition and control for astronomical instruments.
<cesar[m]1> whitequark: Sure, no hurry.
<cesar[m]1> I mainly use FPGAs and microcontrollers.
<cesar[m]1> For FPGA development, I transitioned: schematics->VHDL->Verilog.
<cesar[m]1> Do you remember a time when the Xilinx flow started from schematics? They even had symbols for common 7400 family chips.
<cesar[m]1> With nMigen, I began to see the power of higher level languages, beyond Verilog.
<cesar[m]1> For a long time, I used FPGAs mainly as glue logic between ADC and microcontrollers.
<cesar[m]1> Then I began using them as signal processors for Radio Frequency signals in Radioastronomy.
<cesar[m]1> There is a group that develops libre hardware for Signal processing in Astronomy.
<cesar[m]1> It's called CASPER.
<cesar[m]1> Collaboration for Astronomy Signal Processing and Electronics Research
<cesar[m]1> You can see their hardware at
<cesar[m]1> We recently got a ROACH-2, and will get a SKARAB shortly.
<cesar[m]1> My first FPGA design was on a XC3020.
<cesar[m]1> My biggest one so far was a correlator on a XCV800.
<cesar[m]1> My latest is an experiment for detecting X-rays in a baloon experiment.
<cesar[m]1> Also just finishing firmware for a nano-satellite. No FPGA on this one, sadly.
<cesar[m]1> The CASPER group also designs and releases IP blocks for signal processing.
<cesar[m]1> Sadly, they are based on Simulink as their HDL.
<cesar[m]1> They began migrating to Python, though. But there still much heritage in Simulink.
<DaKnig> what does `Memory` translate into?
<whitequark> RTLIL memories
<DaKnig> I have a case where using a `Memory` class would be the most readable but the "address" is just 5 bits so LUTs should be enough and there's no point in using bram (though this distinction is on the yosys level I believe)
<whitequark> yosys should be smart enough to translate that to a LUT
<whitequark> and if it isn't, it should be fixed
<DaKnig> a LUT for every bit of data
<DaKnig> so 30 in my case
<whitequark> sure
emeb has joined #nmigen
alexhw has quit [Remote host closed the connection]
alexhw has joined #nmigen
<DaKnig> does Memory support operator []?
<DaKnig> .... it looks like it does not. that's a shame.
<whitequark> DaKnig: only in simulation
* lkcl waves to cesar[m]1 :)
* cr1901_modern did some reading last night YIKES... looks like you have to do a massive dance of bullshit just to load a bitstream onto Zynq (if you want nonvolatile bitstreams)
<cr1901_modern> Uhhh, does support emitting the binary format that you need to load over JTAG (or SD card) onto a Zynq?
<DaKnig> what zynq are you using
<DaKnig> what board?
<cr1901_modern> zynq-7000 7s, Cora z7
<cr1901_modern> Cora isn't supported yet, I'm working on it
<cr1901_modern> I just am wondering in general if you can generate the required build artifacts w/ nmigen alone
<DaKnig> I have zynq7020 I think , it does indeed output the bitstream
<cr1901_modern> _before_ I dive into a rabbit hole that I tbh really don't have time for
<DaKnig> take a look at arty_z7
<trabucayre> cr1901_modern: from linux or using jtag (bypass CPU) ?
<DaKnig> I use it, it works.
<cr1901_modern> trabucayre: Basically I want a bare-metal way to load bitstreams via the CPU because JTAG is volatile
hitomi2505 has quit [Quit: Nettalk6 -]
<cr1901_modern> And I don't think one can use a proxy-bitstream in this case to load the correct image to SD card
<trabucayre> I don't know with bare-metal but without processing_system, linux freeze (but maybe you already know that)
<cr1901_modern> Nope! I don't know much about Zynq lol... I'll have to look into it
<trabucayre> I _must_ using zynq. With linux the processing_system is mandatory or linux freeze :-/
<trabucayre> block design required :(
<trabucayre> (in my case)
<d1b2> <emeb> I remember a while back the Xilinx "petalinux" had a /dev/fpga device that you could just pipe a bitstream into and it would reload the PL. That seems to have gone away though.
<cr1901_modern> Supposedly the bitstream format is discussed in the Zynq manual, but again... I'll have to look into it later
<trabucayre> d1b2: with modern kernel there are a new infra -> fpga_manager
<cr1901_modern> err the blob* format
<cr1901_modern> (of course the bitstream is undocumented, b/c LOL)
<cr1901_modern> (Random aside: Generating the correct Xilinx blobs would be useful for nmigen-soc)
<daveshah> not true, Xilinx document their bitstream format (as in the container) quite well
<trabucayre> for current programming see:
<trabucayre> 7.2
<daveshah> they just don't document what the bits themselves actually _do_
<daveshah> but things like the bitstream commands are all documented
<cr1901_modern> okay fair enough
<DaKnig> is it possible to have the bitstream be persistant on zynq without touching the ARM?
Asu has quit [Remote host closed the connection]
<cr1901_modern> I don't know
Asu has joined #nmigen
<trabucayre> DaKnig: I think no. For all zynq based boards I've seen, it's uboot (bootloader) whos flash FPGA from sdcard (most board) or from flash area (plutosdr f.i.).
<trabucayre> Or it's possible to flash at run time using fpga_mgr
<DaKnig> guess I wont do this then :(
<trabucayre> jtag...
<d1b2> <novakov> If you don't want to play with u-boot/fpga_mgr you can use bare FSBL which will load bitstream from BOOT.bin
<trabucayre> d1b2: True.
<jeanthom> are the sources of uboot for Zynq available?
<trabucayre> uboot mainline support zynq
<trabucayre> I use this one for redpitaya (
<trabucayre> but to have bitstream shipped in fsbl I think (I'm maybe wrong) vitis/sdk is mandatory (with .hwdef produces from processing_system block in block design)
<trabucayre> I'm not sure and I'm interested by an alternate way :)
<vup> I would recommend the mainline uboot, ime the xilinx fork tends to break regularly
<trabucayre> vup: uboot break regularly :)
<trabucayre> barebox support zynq (I've never tested)
<vup> hmm mainline uboot has been solid for me, but I guess I am not doing anything crazy either
<vup> the fsbl stuff is also open source:
<vup> so it can be built without vivado, however creating the initial configuration without vivado is probably tricky
<trabucayre> ps7_gpl_init.c is produce from hwdef.
<trabucayre> each time I need to update uboot it's painfull
<vup> yeah I can imagine, I just generated it once and tweaked it manually after that
<trabucayre> ps7_init ? or uboot ?
<vup> ps7_init
<trabucayre> condolences ;)
<trabucayre> the worst. Only RAM configuration is mandatory here, rest maybe to configured by uboot (like every classic boards)
<vup> well in theory everything could be done by uboot
<trabucayre> *in thoery*
<vup> this is what this project tried to do:
<vup> but that seems to have bitrotten to the point of unusability
<vup> (it still uses the non Kconfig based uboot configuration system for example)
<trabucayre> Have you see how to configure a simple gpio with devicetree? It's awfull
<trabucayre> vup: ouch
<vup> trabucayre: I actually think the zynq devicetree stuff is not *that* bad
<trabucayre> the configuration is a bit complex
<vup> for sure
<trabucayre> it's a nightmare :)
<lkcl> cr1901_modern, DaKnig: i have a ZC706 which has a z-7045. it's niiice.
<lkcl> however the license has almost certainly expired. DaKnig: do you happen to know if there are "monetarily zero cost" proprietary tools that can be used with it?
<daveshah> You can still old Vivado versions with that license
<DaKnig> ^
<daveshah> the licenses don't stop working, you just cant use post-expiration updates
<DaKnig> iirc licenses work like so: you get finite period of sw upgrades, then you just keep the thing you have for life
<lkcl> daveshah: ah ok. interesting. what if you move to a different machine with a different MAC address?
<trabucayre> daveshah: it's true. I use my education license with 2018.3
<lkcl> DaKnig: oh ok, that's slightly better than i expected
<DaKnig> their website has a thing for this
<daveshah> Coincidentally happen to have a VM or USB ethernet adapter with the same MAC address
<trabucayre> lkcl: change the mac of your computer
<DaKnig> my license (depends on what you have) allows me to transfer it over to 5 computers
jeanthom has quit [Ping timeout: 244 seconds]
<lkcl> trabucayre: :)
<DaKnig> some allow you to move it to however many computers you want
<DaKnig> some allow you to have a server
<trabucayre> lkcl: it's not a joke you can
<lkcl> trabucayre: i remember, andrew tridgell did it at a hotel. got free wifi without a login :)
<trabucayre> sudo ifconfig <interface_name> hw ether 94:C6:91:A9:1E:B6
<lkcl> that's why i found it funny
<DaKnig> its not the mac it checks I think
<DaKnig> I think it checks the machine name too
<trabucayre> DaKnig: no
<trabucayre> just mac
<DaKnig> I dont remember the details, I tried a different OS with different computer name on the same phys machine
<DaKnig> didnt work
<DaKnig> I actually use a container for this
<DaKnig> lxc
<trabucayre> DaKnig: I need to check again if hw ether is enough... Or not
<DaKnig> I dont trust this thing enough to allow it to ruin my files or snoop around
<lkcl> re OS building: rocket-chip got this right. it's why i asked my sponsor to get the zc706 in the first place. they have full automated build scripts for absolutely everything.
<DaKnig> when I would finally remove the thing, I want a clean remove
<DaKnig> just `lxc delete xilinx-box` or whatever
<trabucayre> I need to do this to use microsemi tools :)
<trabucayre> for gowin it's seems working ->
<lkcl> downloads the toolchain, cross-compiles it from scratch. downloads buildroot for zynq, cross-compiles that from scratch. all command-line-based behind a Makefile. real easy.
<trabucayre> lkcl: the toolchain may be produce by buildroot.
<trabucayre> 1/2h to produces sdcard.img
<lkcl> the rocket-chip team did a little more than that: it was a fully automated build of absolutely everything. 4-core SMP RV64GC, command-line (non-GUI) vivado integration using appropriate tcl scripts - everything.
<lkcl> full OS for the ZC706
<lkcl> full OS for the RV64GC target
<lkcl> full bitstream for the FPGA
<trabucayre> lkcl: url? Maybe I've something good to do with this board
<trabucayre> :)
<lkcl> the point being: it's worth looking at to see what they did and how they did it, if struggling / head-against-wall-bashing trying to duplicate any of that process
<lkcl> 1 sec...
<trabucayre> nothing with zcu102 (ultrascale)?
<trabucayre> "Warning: This repository is deprecated and does not track Rocket Chip master." :-(
<lkcl> they said "it's unsupported" at the time that i ran it.
<lkcl> and it was successful.
<trabucayre> I've tried this by the past .... And nothing working :-(
<trabucayre> I will retry !
<lkcl> i had to go through 3 different versions of xilinx vivado before it worked.
<trabucayre> :-(
<trabucayre> version working ?
<lkcl> that was the only real nuisance.
<lkcl> apologies, it was... 2 and a half years ago, now
<lkcl> ah! 2016.02
<lkcl> ls /opt/Xilinx/SDK/2016.2/
<lkcl> it's still there
<trabucayre> ouch !!
<lkcl> the board's 5 years old now!
<trabucayre> jurassic park power :)
<lkcl> lol.
<lkcl> still USD $2500 worth of FPGA board. 300k LUTs, where the ECP5 maxes out at 85k
<trabucayre> yes old board. And xilinx is unable to respect FMC spec... Wrong signals in HPC ...
<trabucayre> for the same price you have an ultrascale now
<lkcl> we're developing a GPU so may *sigh* actually need to use it, old as it is.
<lkcl> sigh
<trabucayre> I need for phase noise using this
<lkcl> well whatever we get, support in nmigen is critically important
<trabucayre> this for the rest I _must_ using redpitaya because it's a low cost board
<trabucayre> lkcl: yes !!!
<trabucayre> lkcl: whoo!
<trabucayre> vup: I need to test this!
<DaKnig> what would be the preferred way to write a shift reg?
<DaKnig> rn I have this: `m.d.synq += symbol_queue[:9].eq(symbol_queue[1:]`
<d1b2> <TiltMeSenpai> vup: does the Axiom Micro use mipi to communicate with the imaging sensor?
<vup> TiltMeSenpai: hispi, some aptina (now onsemi) proprietary thing
<vup> but a mipi core is planned for the next image sensor
<d1b2> <TiltMeSenpai> I'm theoretically working on an ecp5-based dev board for the raspberry pi cameras (as in I need to order more parts)
<vup> trabucayre: well don't expect too much, its very in flux and wip
<d1b2> <TiltMeSenpai> part of this involves building out a mipi core, if you're also working on something using mipi, I'd love to contribute where I can
<trabucayre> vup: It a base to improve :)
<vup> trabucayre: of course :)
<trabucayre> fed up to have to use vivado directly
<trabucayre> see for try to have something for f*g graphic and vendor dependant ...
<trabucayre> ok I need to add some page in the wiki :)
<vup> TiltMeSenpai: cool, the next revision of the micro will also use a ecp5 and a mipi only sensor, so we will have to write a mipi core some time in the future, might still take a couple of months to get to that though
<trabucayre> something not graphic only and vendor independant...
<d1b2> <TiltMeSenpai> I think the mipi bit itself will be reasonably easy, the protocol looks pretty straightforward. Fun part is figuring out the sensor-specific registers lol
<d1b2> <TiltMeSenpai> also i2c but at 4mhz or something
<vup> yep, the sensor specific stuff is always ~interesting~
<d1b2> <TiltMeSenpai> do you have unredacted datasheets for the sensors you're using?
<d1b2> <TiltMeSenpai> that always simplifies things
<vup> yes, I found a stash of aptina datasheets on some ftp server:
<d1b2> <TiltMeSenpai> nice
<d1b2> <TiltMeSenpai> lol
<vup> (ok as far as I can tell the ftp server used to be a aptina internal ftp server and they had a sharepoint backup on there, which I extracted the pdfs from)
<vup> trabucayre: interesting, fpga independent gateware is something I am very interested in myself
<trabucayre> vup: I try this. but need to improve doc ...
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 244 seconds]
Asu has quit [Quit: Konversation terminated!]
jeanthom has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<FL4SHK> so I'm looking to buy some resistors for constructing some R-2R ladder DACs
<FL4SHK> three 6-bit ones
<FL4SHK> what does parts per million mean?
<FL4SHK> I'm seeing "15 ppm"
<FL4SHK> I want very low tolerance resistors for accuracy
<FL4SHK> accuracy++, like with bsnes
<sorear> 1/1_000_000 ? this seems too easy, what am I missing
<FL4SHK> I don't know analog stuff too well
<d1b2> <TiltMeSenpai> I think that's exactly what it means
<DaKnig> isnt 1% or something enough for your thing
<FL4SHK> I don't know
<DaKnig> simulate
<FL4SHK> wow
<FL4SHK> I'd need to learn SPICE for it
<DaKnig> change the numbers in the range, see the graphs
<FL4SHK> I'm not doing enough analog stuff to do that
<DaKnig> > learn spice
<DaKnig> well
<DaKnig> yeah
<DaKnig> important tool
<sorear> ppm is easy, they could be saying something like "permyriad" or "basis points" :p
<FL4SHK> 1% is probably fine
<DaKnig> just check :)
<FL4SHK> I'm basing this off of what I read
<FL4SHK> sounded like 5-bit was fine with 1% tolerance
<DaKnig> 1% does not mean that the output would be within 1% of the correct result
<DaKnig> ah 5 bit
<DaKnig> yeah
<DaKnig> whats the voltage range
<FL4SHK> uhhh, 0 to 3.3V
<DaKnig> ah I was thinking in 5V
<DaKnig> idk then
<FL4SHK> FPGAs don't usually come with 5V logic levels any more
<d1b2> <TiltMeSenpai> I think 1% means +- 1%
<FL4SHK> well, here's what I plan on doing
<FL4SHK> I plan on using temporal + spatial dithering to get 8-bit DACs
<FL4SHK> three 8-bit DACs -> 24-bit color
<daveshah> You'd be doing well if the stability of your FPGAs Voh was better than 1%
<d1b2> <TiltMeSenpai> I mean temperature stability matters more than your resistor ladders
<d1b2> <TiltMeSenpai> also yeah, that
<FL4SHK> I see
<daveshah> Particularly as it is likely to vary on temperature, how good the voltage reg is, current load on the output and rail, etc etc
<FL4SHK> My analog foo is rather weak
<DaKnig> yeah 1% does mean +-1% ("within one percent of the specified value") but it does not mean the output would be within 1% of the predicted numbers
<FL4SHK> I can see why that'd be the case
<FL4SHK> it's probably a more complex calculation
<d1b2> <TiltMeSenpai> if you had components with low tolerance but absolutely no environmental drift, that would be fine
<DaKnig> FL4SHK your arty can have 5V I think
<d1b2> <TiltMeSenpai> because you can compensate for it
<daveshah> DaKnig: I doubt it, certainly not 5V outputs
<d1b2> <TiltMeSenpai> on the other hand, if your components had absolute accuracy at 20c but undefined temp drift, your measurements would be close to useless
<FL4SHK> Maybe it'd be better to just buy a DAC
<DaKnig> that works too :)
<FL4SHK> this was going to be $87
jeanthom has quit [Ping timeout: 240 seconds]
<awygle> Is `platform is None` a reliable way to check for simulation? is there a way to encode in a module "if we're being simulated and this condition occurs, print this message"?
<awygle> I basically want `unimplemented!()` for nmigen lol
kernelmethod has joined #nmigen