<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 - https://git.io/JJ8M2
<_whitenotifier-b>
[nmigen-boards] FFY00 edited a comment on issue #89: [RFC] handling boards that are very similar - https://git.io/JJ8M2
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.
<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 nmigen.build 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 - www.ntalk.de]
<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
<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>
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
<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 :)
<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 :)
<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
<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>
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>
(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
<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