m4ssi has quit [Remote host closed the connection]
<tnt>
Oh so the crosslink nx configuration is actually done using an embedded risc-v ?
<TD-Linux>
wut
<emily>
;w;
<kc8apf>
tnt: from what daveshah has told me, it looks like MachXO3D does the same thing
<tnt>
What would "HSE" stand for in the context of Lattice ?
<kc8apf>
they put a RISC-V core in the security engine and use it as part of the configuration loading/verification scheme
<tnt>
Yup exactly.
<kc8apf>
hardware security engine, if we're talking about that
<tnt>
And interestingly the entire firmware is included in radiant.
<tnt>
(I mean ... no way to tell if it's the _actual_ fw ...)
<kc8apf>
means they actually implemented half-way decent signature crypto this time
<tnt>
Nice. Makes sense I guess.
<kc8apf>
MachXO3D is marketed toward NIST 800-193 (Platform Firmware Resiliance) so they tried to make it better
<kc8apf>
whether it is good enough remains to be seen
<daveshah>
It isn't just a RISC-V, afaik, there are also some hard peripherals for various parts of the crypto algorithms
<kc8apf>
daveshah: I'd expect so. Bitstream loading would be slow with pure software crypto
m4ssi has joined ##openfpga
m4ssi has quit [Client Quit]
<tnt>
yeah I saw ecdsa and sha cores in there.
<sorear>
I was wondering when there’d be relevant riscv object code in the wild for “riscv re” to be non academic
<azonenberg>
does ida do rv32 yet?
<TD-Linux>
sorear, nvidia cards and wd drives?
<sorear>
afaik none of those have shipped yet
emeb has joined ##openfpga
<tnt>
daveshah: can radiant generate svf for nx ?
<daveshah>
tnt: yeah, there's a button in the programmer for it
<tnt>
Arf, I didn't install the programmer :/
<daveshah>
I didn't know you couldn't not
<daveshah>
*could not
<daveshah>
it comes as part of Radiant
<tnt>
how is it called ? (binary name ?)
<daveshah>
programmer
<daveshah>
oh wait that's diamond
<daveshah>
it can be opened in the GUI, I don't know the binary name for radiant
<tnt>
yeah, not installed. I just re-ran the installer and you can de-select it, which I did ... most of the time I can't get the pogramming tool to work anyway (drivrs / permissions / whatever) so I deselect them ...
<tnt>
It doesn't detect the board and doesn't let me generate a svf either wtf ...
<tnt>
Did anyone manage to ever program a lifcl-40 using svf / jtag ?
<TD-Linux>
mine is still todo. I got my board the same day as my colorlight and the latter got the most love
<tnt>
Ok, so the radiant programming tool does't like compression to be enabled apparently.
dh73 has quit [Ping timeout: 240 seconds]
<TD-Linux>
looking at litex's colorlight_5a_75b.py, it initializes liteeth with clk routing delays. how do people figure this out? just trying numbers experimentally until it works?
<tnt>
... or alternatively you can do an IO timing analysis.
<TD-Linux>
how does that work? do you hook up a fast scope or is there a better way to do it
<tnt>
You can lookup the setup/hold/clock-to-out requirements from the chip you talk to.
<TD-Linux>
rx_delay = 2e-9) # 2ns FPGA delay to compensate Clk routing to IDDRX1F
<tnt>
Then diamond can provide IO timing numbers for the FPGA IOs (nextpnr can't do that yet, so you need the lattice tools). Then you try to match the two ...
<TD-Linux>
this seems to imply it's from the pcb?
<TD-Linux>
or is that saying internal fpga routing
<tnt>
It's internal fpga routing.
<TD-Linux>
oh I see, ok.
<tnt>
the clock takes ~ 2ns more to get from the clk pad to the clk input of the IO flip-flop than the data takes to get from the pad to the IO flip-flop data input.
<tnt>
so to "fix" that, it artifically adds 2 ns delay to each of the data IOs using the programmable IO delays of the ECP5.
<TD-Linux>
okay that makes sense. presumably you could also use this for data to data differences, but clk is way more significant because it probably goes in through a clock buffer (?)
<tnt>
because all the IOs are registred in the io block, the pad->reg delay is pretty much identical for all lines.
<TD-Linux>
oh, re registering io in the io block, I have another question
<TD-Linux>
I have an fpga project that talks to a bus asynchronously (it runs with its own clock unrelated to the bus clock). the bus asserts a ready line and then the fpga asserts ack
rohitksingh has quit [Ping timeout: 260 seconds]
<TD-Linux>
currently I'm synchronously capturing all the input lines and then capturing the data lines a clock after I see ready
<tnt>
sounds good
<TD-Linux>
I was reading how clock domain crossings are done inside fpgas and apparently it is common to use 2 flip flops sequentially to reduce MTBF. is that also something you do on external IO lines or do they have more robust sampling
<whitequark>
yes, you have to do it on external IO as well
<tnt>
Not really more robust sampling, but your data lines should be stable by the time you read ready so you only need to worry about your "ready" line.
<whitequark>
you also should use the IOB flip-flop as one of those so that the bus is sampled at the same time regardless of placement and routing
<whitequark>
even though it's an asynchronous bus
Dolu has quit [Ping timeout: 272 seconds]
<whitequark>
(this matters less if the FPGA has a much higher clock rate)
<tnt>
yeah, you should pretty much always uses IO flip flops for everything that's not trivially slow imho ...
<TD-Linux>
yeah I don't use IOB flip flops right now so that's first on my list (unless they get promoted automatically somehow). converting to them is what prompted this question
<TD-Linux>
tnt, so basically because I sample data the clock after I sample ready, and because the bus guarantees that data is set up before ready, I already effectively have my double flip flos?
<TD-Linux>
the buses are 16mhz and 10mhz so not super fast but there's no reason for me not to do it properly
<tnt>
Well the FF might have samples crap the cycle before, but doesn't matter, at the time when you read ready it will have sampled something that was meeting its setup time so its output should be reliably valid.
<whitequark>
it doesn't matter as long as you don't use the value from that bus anywhere
<whitequark>
(which is likely the case)
<TD-Linux>
yeah, that's the case. and just to double check I don't need to double flip flop the ready line itself?
<tnt>
yeah
<TD-Linux>
cool, thank you!
<tnt>
basically you have to image that anything you sample asynchronously can come up as not 0, not 1, but 0.5 and that messes up any kind of logic you'd try to do on it. The hope of the double FF is that the second one will resolve that to either 0 or 1.
<whitequark>
wait, why shouldn't TD-Linux synchronize the ready line?
<whitequark>
it's still asynchronous wrt FPGA clock
<tnt>
he should
<tnt>
Oh wait, I misread ...
<tnt>
I missed the "don't" which was kind of important.
<tnt>
The ready line is the only one that needs to be double registered.
<whitequark>
right, yeah
<tnt>
(once in IO and once in fabric)
<TD-Linux>
ok, so I think if I do that, the overall latency stays the same
<TD-Linux>
so right now I sample ready, and if it's 1, I sample data on the next clock
<TD-Linux>
but instead I should sample ready in IOB, then sample it again in fabric, and then use that value directly to control data sampling
<whitequark>
yep
<tnt>
Damn NX PLL won't lock.
davidc__ has quit [Quit: leaving]
<TD-Linux>
(aside, this community is amazing. I'm remembering 10 years ago when the state of the art for learning fpgas online were verilog tutorials on how not to infer latches)
<whitequark>
i mean that's still pretty important :p
<TD-Linux>
true, but now we have languages where that kind of mistake is not possible :)
<TD-Linux>
(is it possible to create a latch in nmigen?)
<whitequark>
well, you can instantiate one
<whitequark>
but nnot otherwise
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 258 seconds]
<gruetzkopf>
meh. *starts drafting a EPROM emulator*
<gruetzkopf>
i'm once again limited in productivity by my UV eraser
<levi>
I have a bunch of old PromICE EPROM emulators. They are cool little boxes, and you can find the source to the control program for them.
* gruetzkopf
crosses off "get quoted on twitter by wq" for the days task-list
<gruetzkopf>
oh, neat
<TD-Linux>
might also want to make sure there's not a drop in flash available
<levi>
Hmm, thought they might have been numerous enough to have a few up for cheap on ebay, but I guess not.
<gruetzkopf>
there are drop in EEPROM but at least some firmware versions of this thing go check for that and refuse to boot and or wipe it