<Xark>
Hmm, I see nextprn-ice40 quit working for me today. I presume because of an Nvidia OpenGL update earlier? FYI: nextpnr-ice40: relocation error: nextpnr-ice40: symbol _ZTI13QOpenGLWidget version Qt_5 not defined in file libQt5Widgets.so.5 with link time reference
* Xark
tries rebuilding newest version...
pie_ has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
emeb_mac has joined ##openfpga
<Xark>
Nope, same error. Rebuilt the entire "IceStorm suite" from GitHub source. I'll try rebuilding nextpnr with GUI disabled, I guess...
<Xark>
Crud. Rebuilding nextprn with -DARCH=ice40 -DBUILD_PYTHON=OFF -DBUILD_GUI=OFF -DSTATIC_BUILD=ON "worked", but now I get "unrecognised option '--pre-pack'".
* Xark
apologizes for his fingers that keep mangling "nextpnr"...
<Xark>
Yay! Okay, I got carried away, what I wanted (and what works) is to use: -DARCH=ice40 -DBUILD_GUI=OFF
<Xark>
(However, a minor bummer that all of a sudden, I can't run GUI on Ubuntu 18.04.3 for some QT/OpenGL reason...)
freemint has quit [Ping timeout: 250 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
Flea86 has joined ##openfpga
Bike has quit [Quit: Lost terminal]
pie_ has quit [Quit: pie_]
<Sprite_tm>
Does anyone here happen to have either a random number generator or a ring oscillator lying around for the ECP5? /me needs some entropy in his life :P
<Flea86>
lol
<Flea86>
Sprite_tm: Isn't that incredibly easy to do? Even easier if you are a noob ;-D
<Flea86>
ring oscillator I mean
<Sprite_tm>
Flea86: From the Ice40, I remember you had to manually instantiate the LUTs, because otherwise Yosys would optimize them away. Did that change?
<Flea86>
Sprite_tm: I've never used that FPGA. Are you sure that comment was intended for me? :)
<sorear>
I would not assume synthesis will do anything useful with a behavioral description of a combinatorial loop
<sorear>
I would also be cautious of ring oscillators failing to produce much entropy; they have a reputation of spontaneously phase-locking to clocks or other on-chip signals
pie_ has joined ##openfpga
<whitequark>
i hve in fact observed ring oscillator locking to random shit
<Sprite_tm>
Hm, interesting. Any other ways to get entropy on an ecp5?
<Sprite_tm>
I mean, worst case I can take the temperature sensor and *hope* it jitters enough... but that'll not be much entropy per second.
<Ultrasauce>
what's the application? more specifically, does it need to be cryptographically sound
<azonenberg>
Sprite_tm: what are you using the entropy for?
<azonenberg>
For non-crypto just use a LFSR or something
<Sprite_tm>
I'd like it to be at least slightly better than a lfsr... specifically, I want the thing to be non-deterministic without outside influence.
<Sprite_tm>
If I have a lfsr and code acting on it during boot, the boot is going to be 100% the same every time.
<azonenberg>
Do you have multiple clock sources?
<azonenberg>
you can try using beats between them
<Sprite_tm>
azonenberg: Nope, only the external osc, hence me wanting to build a ring osc :)
<azonenberg>
Lol i see
<Sprite_tm>
Hmm, wait, I thought the ECP5 didn't have an accessible internal clock, but maybe I'm misremembering from the ice40...
<tnt>
1Ther eis OSCG I think
<Sprite_tm>
Looks like it. Well, one internal osc is better than none :P
<Sprite_tm>
azonenberg: what would be the way to do this? I seem to recall sampling the slow clock with the fast clock, then dumping the resulting bit into a LFSR should work?
<tnt>
I would clock a LFSR in the fast domain and sample it in your slow domain and mix that with a lfsr in your slow domain.
<Sprite_tm>
Should work :)
Asu has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
<sensille>
how far is the RE progress for artix?
<pie_>
well, if you have a good mixing function its only a question of how fast you can feed entropy into it right? (/me mumbles something about urandom and having read a bit of schneier)
<tnt>
Brilliant ... the link to get the eval license for the ecp5 evn kit is 404
swedishhat[m] has quit [*.net *.split]
scream has quit [*.net *.split]
Jybz has quit [*.net *.split]
_whitelogger has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 248 seconds]
SpaceCoaster has joined ##openfpga
rohitksingh has joined ##openfpga
pie_ has quit [Quit: No Ping reply in 180 seconds.]
pie_ has joined ##openfpga
eddyb has quit [Changing host]
eddyb has joined ##openfpga
eddyb has joined ##openfpga
eddyb has quit []
eddyb has joined ##openfpga
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Asu` has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
_whitelogger has joined ##openfpga
pie_ has quit [Quit: pie_]
pie__ has joined ##openfpga
freemint has quit [Ping timeout: 264 seconds]
freemint has joined ##openfpga
genii has joined ##openfpga
<sensille>
mithro: is the artix-7 support already in usable state?
<tnt>
Nowhere near the same as ice40 or ecp5.
<tnt>
I think VTR has some support for some things 7-series, but still relies on Xilinx tools for actual bitstream generation.
<daveshah>
I believe the SymbiFlow people have VTR+XRay working now
<daveshah>
But you would be better off asking in #symbiflow
<daveshah>
As of a few months ago they were working on IO (before they only generated a bitstream for a partial reconfig region)
<daveshah>
Not sure what status is now. They were aiming for end of the year for a useful flow iirc
<sensille>
ah, ok. thanks for the pointer
<daveshah>
(personally I've been playing about with nextpnr+rapidwright recently and have enough primitives done now to get litedram DDR4 working, but that's never going to be an end-to-end open source flow)
<daveshah>
that's for UltraScale+ not xc7 thoughg
<_florent_>
daveshah: ^ nice, have you been able to test on hardware?
<daveshah>
Yes, I need to tidy a few more things up then I'll submit a PR adding the zcu104
<daveshah>
It's a bit tricky because the PL-side memory is actually a SODIMM (so the LiteX config could vary for different sticks)
<_florent_>
great! maybe at one point we should add SPD EEPROMs support, in a first time not necessarily handling the parameters dynamically, but just preventing running with an incompabible SODIMM or load a bistream to the FPGA to get the SODIMM info and be able to re-generate the right bitstream
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
<daveshah>
Yes, that seems like a good idea.
emeb has joined ##openfpga
dh73 has joined ##openfpga
<mithro>
tnt: That isn't correct
<mithro>
tnt: The Yosys+VPR+prjxray Artix-7 flow hasn't ever needed Xilinx tools -- it has needed a harness generated by the Xilinx tools but we are in the process of removing the need for that right now
<mithro>
tnt: There was a nextpnr experiment which had some Artix-7 support using Xilinx tools for bitstream generation IIRC
<mithro>
sensille: prjxray now has documented all the bits needed for a VexRISCV + LiteDRAM + LiteEth design on the Arty-A7T35 board -- but VPR can't actually place and route that design yet
<mithro>
sensille: There isn't really a flow that is targeted at non-SymbiFlow developers yet
<sensille>
mithro: thanks. so if i look again in 1/2-1 year, there are chances i can get some moderate design implemented?
<mithro>
sensille: Target is that the toolchain will be ready for users who want to do something like the VexRISCV+LiteDRAM+LiteEth design is end of this year
<sensille>
VexRISCV+LiteDRAM+LiteEth already looks much more sophisticated than what i'm doing :)
<mithro>
sensille: I expect that we will want early testers in early october
<sensille>
mithro: [x] interested
<mithro>
FYI - When we turn all the nobs up on VPR it gets results which are within 5% of Vivado for the same input -- only problem is it takes 9h to do so at the moment :-/
<sensille>
oh
<mithro>
If we put the nobs in a more reasonable setting, it is about the same speed as Vivado for about ~30% worse
<sensille>
well, if you need a tester, i'm a light user. <30% utilization running at 20MHz
<mithro>
sensille: No DSP support yet either...
<sensille>
no need
<mithro>
sensille: First step is to test Yosys(synth)->Vivado (pnr) for your design
<sensille>
you don't need DSP for VexRISCV?
<mithro>
sensille: It decreases the performance but isn't required
<mithro>
sensille: Maybe? Depends on what you are doing...
<sensille>
i'll just ask again in october :)
Flea86 has quit [Quit: Leaving]
freemint has quit [Quit: Leaving]
rohitksingh has quit [Ping timeout: 258 seconds]
<tnt>
mithro: mmm , I was going from some old post from Eddie Hung that had some VTR patch producing a XDL.
<daveshah>
yeah, that was vtb (verilog to bitstream)
<mithro>
tnt: Yeah - that was ancient :-P
<daveshah>
istr it was distributed as a patch because way back then VTR wasn't actually open source (code public but license preventing redistribution)
dh73 has quit [Ping timeout: 260 seconds]
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
freemint has joined ##openfpga
cr1901_modern1 has joined ##openfpga
rohitksingh has joined ##openfpga
Asu` has quit [Ping timeout: 246 seconds]
Asu` has joined ##openfpga
cr1901_modern1 has quit [Client Quit]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 276 seconds]
Asu` has quit [Client Quit]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
<azonenberg_work>
mithro: is there SV struct support in mainline (non-verific) yosys?
<daveshah>
No, there isn't
<azonenberg_work>
I might want to work on that in a few weeks once i unpack more
<daveshah>
That would be awesome
<daveshah>
The first thing to solve is a nasty shift/reduce conflict in the parser that also blocks typedefs