<ZirconiumX>
Synthesized with Yosys, PnR'd with Quartus.
<mwk>
heh, congrats :)
<mwk>
night
cr1901_modern has quit [Ping timeout: 240 seconds]
kraiskil has quit [Ping timeout: 265 seconds]
citypw has joined #yosys
cr1901_modern has joined #yosys
kraiskil has joined #yosys
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale` is now known as X-Scale
_whitelogger has joined #yosys
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
_whitelogger has joined #yosys
Twix has quit [Ping timeout: 264 seconds]
Jybz has joined #yosys
Twix has joined #yosys
<pepijndevos>
Sometimes I hate formal... I probably have some uninitialised thing or missing whatever, which make sby just go "yay, proved in step 0" obviously not giving me a trace or any clue what happened.
<pepijndevos>
My quite modest module has a clock, reset, and *one* std_logic input, but past 30 cycles it just completely bogs down, and it needs to run at least 12*8 cycles to do anything interesting at all
<pepijndevos>
Can you do anything to limit the search space? Will adding assumptions make it faster?
<ZirconiumX>
Yes, assumptions make it drop parts of the search space that don't match the assumption.
<ZirconiumX>
pepijndevos: ^
<pepijndevos>
Hm ok
<pepijndevos>
My code is one big off-by-one error because the C code assumed everything happens sequentially and I'm still figuring out new stupid interdependencies
Jybz has quit [Ping timeout: 276 seconds]
<pepijndevos>
I decided to use one or two variables to stay sane... but I don't think a longest topological path of 200 is quite sane.
<pepijndevos>
Oh well... Gowin IDE thinks it'll run at 65.4 MHz, and it only needs to do 33 MHz, so whatevs
Jybz has joined #yosys
<ZirconiumX>
Bleh. Quartus says that some I/O pins are held at GND, which means somewhere something got lost in translation.
<mwk>
damn, the whole paper really is "look how much virtex 5 sucks"
<mwk>
while conveniently ignoring that virtex 5 LUT6s can, in fact, be split into LUT5s as well
<ZirconiumX>
I mean, it does raise a question of how best to weight LUT sizes
<ZirconiumX>
Although the ALM in the Cyclone V grew two more DFFs.
<ZirconiumX>
I think it should be weighted to prefer LUT3 over LUT2, but LUT5 over LUT6?
<ZirconiumX>
It'd be nice to have numbers on the internal delays here
<ZirconiumX>
But oh well
togo has joined #yosys
<ZipCPU>
pepijndevos: LTP of 200 is "sane"??? I typically think of an LTP of 20 as bordering on insanity--and that's for an ASIC topological path too (not that I've ever done ASIC design ....)
<pepijndevos>
ZipCPU, no, that's my point. Porting C code becomes a whole lot more trivial by sneaking in a variable here and there, but it really, really messes up synthesis it turns out.
<ZipCPU>
May I ask what the algorithm's supposed to do? I mean ... how complicated is it? Is it a data flow algorithm, or something more complex?
<pepijndevos>
ZipCPU, don't laugh... it's an RF receiver that has to talk to a particular Arduino library on the other end.
<janrinze>
ooohh! nice. does it use the differential inputs for radio input?
<pepijndevos>
So I'm sure there are millions of better ways to do this, but for compatibility on a lazy sunday, porting said Arduino library to C seemed the easiest thing to do given my failed attempt at doing a more demanding receiver as a university project.
<pepijndevos>
janrinze, no, it's a pretty boring thing. These things are ment to run at 2kbps with 8-bit micros, so no fancy FPGA stuff needed. The demodulation is all done inside the board, so you just get a 2kbps binary output
<pepijndevos>
Basically all the C code does is clock recovery, some preamble, and 6-to-4 decoding
<janrinze>
LORA?
<pepijndevos>
Nah, still thinking too fancy. FS1000A and XY-MK-5V
<pepijndevos>
It's impossible to find a proper datasheet for these things, but they appear to be some ASK thing
<pepijndevos>
So... all of these small dev boards have USB FTDI chips, right? Can you use those to UART stuff from your FPGA to the PC, or are they not set up to do anything else besides write the flash?
<pepijndevos>
In particular thinking of the Tang Nano at the moment, but I suspect not many have used it. I also have an Icebreaker...
<janrinze>
The icebreakers are hard to get. Similar like the small ecp5 boards.
<pepijndevos>
Yea, still hoping to one day aquire a ULX3S *sigh*
<janrinze>
I have bought the ecp5 eval board from lattice. added HDMI out. That works quite nice.
<pepijndevos>
Oh! The Icebreaker actually has RX and TX pins set up. I guess I'll test on that then.
<janrinze>
anyone who knows a good random number generator in verilog? :)
<janrinze>
only need 16 bits :D
<ZirconiumX>
Build a ring oscillator and extract randomness from frequency variation /s
<whitequark>
build two ring oscillators and race them against each other
<whitequark>
that's almost a reasonable solution
<whitequark>
almost, because it is prone to lock-in due to interference, especially if they're placed close together
<whitequark>
but in general, racing two asynchronous clocks is a perfectly fine way to generate entropy
<janrinze>
yosys doesn't seem to like ring oscillators, right>
Laksen has joined #yosys
<whitequark>
use (*keep*) and it'll be fine
<whitequark>
you need to instantiate the LUTs of course
pie_ has quit [Remote host closed the connection]
<ZirconiumX>
What units are the ABC9 .lut delays in?
pie_ has joined #yosys
<ZirconiumX>
Seems like picoseconds?
<daveshah>
Arbitrary units
<daveshah>
But convention is picoseconds
gorbak25 has quit [Quit: gorbak25]
fsasm_ has joined #yosys
<janrinze>
how to tell yosys that two clock delay is fine for timing?
<janrinze>
ehrm, next-pnr of course.
<daveshah>
I'm afraid that's not supported yet
<daveshah>
(it's called a multicycle constraint)
citypw has quit [Ping timeout: 245 seconds]
adjtm has joined #yosys
emeb_mac has joined #yosys
Laksen has quit [Quit: Leaving]
emeb has joined #yosys
<ZirconiumX>
daveshah: I am trying to crib timing information for ABC9 LUT delay from the Quartus Timing Analyzer. It models four different types of unateness, and I should probably standardise on one. Which do you recommend?
<daveshah>
ZirconiumX: worst case
<ZirconiumX>
So collect all four and pick the worst?
<daveshah>
Unless one is explicitly worst case
<ZirconiumX>
daveshah: And fanout?
<daveshah>
That's unlikely to be significant enough at synthesis time
<ZirconiumX>
Fair
<daveshah>
In any case most routing resources are buffered, so physical fanout will differ significantly from logical fanout
<ZirconiumX>
Fair.
<ZirconiumX>
The data here is a bit interesting.
<ZirconiumX>
For example, of the inputs A-F of a cyclonev_lcell_comb primitive, F has the least delay and A the most.
<daveshah>
That sounds quite typical
<daveshah>
I think ecp5 is the same for A-D
<ZirconiumX>
Ah, I see the ECP5 LUT library is labeled D-A not A-D
<daveshah>
For some esoteric reason I think abc needs delays in non-decreasing order
<daveshah>
Don't ask why
<ZirconiumX>
That presents a bit of an issue, because the only data point I have for input C so far gives it lower delay than input D
<ZirconiumX>
I'll fudge it, and use the one data point lower than input C for testing
<ZirconiumX>
Same for B having lower delay than A
<ZirconiumX>
...Vice versa
<daveshah>
Well for ECP5 I just mirrored the inputs :/
<daveshah>
Given that pnr probably permutes inputs anyway, giving them all the max of any of them would probably work fine
<ZirconiumX>
It also appears to depend on the specific LUT in the tile
<ZirconiumX>
(yay)
<ZirconiumX>
These numbers look quite weird to me...
<daveshah>
Because each layer is probably a layer of a mux tree one way or another, the delay can differ a lot
<ZirconiumX>
This isn't strictly "the max delay", more "maximum of the ones I scavenged before datamining"
<ZirconiumX>
Datamining is not quite the right term here, but it will do
<ZirconiumX>
daveshah: So now presumably I need to build a box library for the DFFs?
<daveshah>
I don't know what the deal with ABC9 and DFFs is
dys has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Jybz has quit [Excess Flood]
Jybz has joined #yosys
attie has quit [Quit: WeeChat 2.6]
fsasm_ has quit [Ping timeout: 250 seconds]
kmehall has quit [*.net *.split]
jhol has quit [*.net *.split]
pointfree has quit [*.net *.split]
pointfree has joined #yosys
kmehall has joined #yosys
jhol has joined #yosys
<janrinze>
daveshah: when I run nextpnr with the same seed for 90 MHz target it returns 88 MHz, and 85Mhz target it returns 84.. looks like it dodges the target frequency.