02:20 <hammdist> I need to generate randomness in ECP5. it seems the only option is a ring oscillator. however this requires --force to nextpnr. will this negatively impact the place and route of the remainder of the circuit?

07:13 <azonenberg> hammdist: FPGAs generally go out of their way to be deterministic

07:14 <azonenberg> forcing nondeterminism in them is challenging. Ring oscillators are one of several sources but all of them are hard to get right and susceptible to injection locking through power supply coupling

07:14 <azonenberg> Is this for cryptographic purposes or just something like random backoff in some protocol?

07:14 <azonenberg> if it's NOT cryptographic, a simple LFSR is sufficient for most stuff

07:15 <azonenberg> if it is crypto related, honestly i'd recommend getting a MCU or security chip external to the FPGA that has a built in hardware RNG and using that

07:15 <azonenberg> depending on how much randomness you need, either offload all of the generation to the other chip, or use it as a seed for a CSPRNG implemented in the FPGA

07:16 <azonenberg> (so you grab one block of hardware randomness at boot then run off the PRNG from then on, perhaps periodically re-seeding with more randomness from the external chip)

14:44 <hammdist> it's for cryptographic use, but a large number of bits generated by the ring oscillator will be aggregated by hashing to generate the seed for the CSPRNG. so even only a very low rate of true entropy generation by the ring oscillator will be sufficient. also it is assumed that the attacker does not have physical access which I assume is needed for

14:44 <hammdist> injection locking

14:46 <hammdist> to partially answer my own question, I've found there is a better option `--ignore-loops` that can be passed to `nextpnr`. the presence of the ring oscillator doesn't seem to affect the rest of the circuit as far as I can tell

17:36 <hammdist> how do I determine the ftdi_serial value for a board? I'm trying to set up openocd to be able to flash separate to two boards with the same vid/pid

18:07 <hammdist> apparently it's just done with lsusb

18:50 <hammdist> why does nextpnr use 2 threads for routing and ignores --threads 4, for example?

18:56 <hammdist> const int Nq = 4, Nv = 2, Nh = 2; looks like it has a fixed multithreading strategy .. though it's strange that only 2 threads appear in top

18:59 <hammdist> I'm tempted to change it to place it in single threaded mode only but sometimes you don't want to know how the sausage is made

20:01 <hammdist> well there are bigger problems than multithreading that have cropped up now. I have a design that can run at up to 138MHz on 5g, but when I try to compile the same sources for non-5g variant, the maximum clock drops rather inexplicably to only 74MHz (at least 125MHz is required and specified as a constraint)

20:09 <tnt> hammdist: You mean ECP5 ?

20:09 <tnt> What speedgrade are you specifying for non-5g variant ?

20:10 <tnt> I'd expect a -6 to indeed be half the speed of a 5G or so.

20:10 <hammdist> yes ECP5. I'm not specifying a speed grade for either build

20:10 <tnt> 5G is a speedgrade in itself.

20:10 <tnt> Speed wise it goes -6 -7 -8 5G

20:11 <hammdist> uhm ok how do I determine what speed grade a particular chip is? can it be determined from the markings? and how do I specify it to nextpnr?

20:11 <tnt> Well depends which chip you bought :)

20:11 <tnt> it's part of the part number ... -8 are more expensive :)

20:12 <tnt> --speed 8

20:13 <hammdist> chip markings are LFE5UM-45F 8BG3811 A1401R20

20:13 <tnt> So it's 8

20:13 <hammdist> ok I will try with --speed 8

20:20 <hammdist> the speed went up to 100MHz or so before routing. let's see what it is after routing but my gut feeling is it won't get to pass

20:24 <tnt> if it's only 138 MHz on 5G, I doubt it would do 125M on -8. The 5g are _really_ faster because they power them up with a higher core voltage to speed them up.

20:40 <hammdist> it ended up at 107MHz. blast