| *** tpb has joined #yosys | 00:00 | |
| ZirconiumX | Is there any way to communicate to Yosys that a black-box cell does drive a wire? | 00:05 |
|---|---|---|
| whitequark | make it an output? | 00:10 |
| ZirconiumX | Guess I'll have to give it a prototype. Have I mentioned I hate the Quartus IP cores? | 00:11 |
| ZirconiumX | At least Quartus itself hasn't ICEd yet | 00:17 |
| ZirconiumX | Small blessings. | 00:17 |
| mwk | you mean, hasn't ICEd today? | 00:20 |
| ZirconiumX | Yes | 00:21 |
| ZirconiumX | Mostly because I've only recently-ish started doing FPGA stuff | 00:21 |
| ZirconiumX | https://gist.github.com/ZirconiumX/2e7888e99e8db8cb23f8f0741caaf0db | 00:27 |
| tpb | Title: sigh.txt · GitHub (at gist.github.com) | 00:27 |
| ZirconiumX | mwk: On the other hand "FALSE" is apparently not within the valid parameter values of "TRUE" and "FALSE" | 00:27 |
| ZirconiumX | so | 00:27 |
| ZirconiumX | Oh, it's "ENABLE_BUS_HOLD" | 00:29 |
| ZirconiumX | Ugh | 00:29 |
| *** _whitelogger has quit IRC | 00:33 | |
| *** _whitelogger has joined #yosys | 00:35 | |
| ZirconiumX | 89.61 MHz for PicoSoC on a Cyclone V is...probably not great. | 00:36 |
| ZirconiumX | Let's compare with a pure-Quartus flow | 00:37 |
| mwk | is this still without RAM? | 00:41 |
| ZirconiumX | With RAM | 00:42 |
| mwk | hmm, yeah, not good | 00:42 |
| ZirconiumX | Granted, this is semi-incomplete; I haven't got pin assignments or clock constraints at present. | 00:44 |
| ZirconiumX | Actually, hah | 00:48 |
| ZirconiumX | Pure-quartus flow on the same source is 90.32 MHz | 00:48 |
| ZirconiumX | mwk: ^ | 00:49 |
| ZirconiumX | On the other hand I'm not sure Quartus is inferring RAM properly here. | 00:49 |
| ZirconiumX | How do I get the number of bits required for a given constant value? Quartus doesn't support $size or $bits. | 01:18 |
| mwk | $clog2? | 01:19 |
| ZirconiumX | That works, thank you! | 01:20 |
| ZirconiumX | 85.21 MHz. Even accounting for error, explicit RAM instantiation should make it much faster. | 01:25 |
| ZirconiumX | Hm. | 01:25 |
| ZirconiumX | Eh, it's 1:30am | 01:27 |
| ZirconiumX | I'll come back to it later | 01:28 |
| ZirconiumX | Still, though | 01:28 |
| ZirconiumX | Complex-ish thing synthesised qith Quartus | 01:28 |
| ZirconiumX | *with | 01:28 |
| ZirconiumX | My brain is very definitely dead | 01:28 |
| ZirconiumX | Synthesized with Yosys, PnR'd with Quartus. | 01:28 |
| mwk | heh, congrats :) | 01:55 |
| mwk | night | 01:55 |
| *** cr1901_modern has quit IRC | 02:01 | |
| *** kraiskil has quit IRC | 02:41 | |
| *** citypw has joined #yosys | 02:43 | |
| *** cr1901_modern has joined #yosys | 02:47 | |
| *** kraiskil has joined #yosys | 02:54 | |
| *** PyroPeter has quit IRC | 03:06 | |
| *** PyroPeter has joined #yosys | 03:19 | |
| *** X-Scale` has joined #yosys | 04:38 | |
| *** X-Scale has quit IRC | 04:38 | |
| *** X-Scale` is now known as X-Scale | 04:39 | |
| *** X-Scale` has joined #yosys | 04:54 | |
| *** X-Scale has quit IRC | 04:55 | |
| *** X-Scale` is now known as X-Scale | 04:55 | |
| *** _whitelogger has quit IRC | 05:51 | |
| *** _whitelogger has joined #yosys | 05:53 | |
| *** emeb_mac has quit IRC | 06:13 | |
| *** _whitelogger has quit IRC | 07:27 | |
| *** _whitelogger has joined #yosys | 07:29 | |
| *** kraiskil has quit IRC | 08:01 | |
| *** _whitelogger has quit IRC | 08:36 | |
| *** _whitelogger has joined #yosys | 08:38 | |
| *** Twix has quit IRC | 09:02 | |
| *** Jybz has joined #yosys | 09:02 | |
| *** Twix has joined #yosys | 09:08 | |
| 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. | 09:09 |
| 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 | 09:25 |
| pepijndevos | Can you do anything to limit the search space? Will adding assumptions make it faster? | 09:31 |
| ZirconiumX | Yes, assumptions make it drop parts of the search space that don't match the assumption. | 10:14 |
| ZirconiumX | pepijndevos: ^ | 10:14 |
| pepijndevos | Hm ok | 10:14 |
| 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 | 10:23 |
| *** Jybz has quit IRC | 10:50 | |
| 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. | 11:10 |
| pepijndevos | Oh well... Gowin IDE thinks it'll run at 65.4 MHz, and it only needs to do 33 MHz, so whatevs | 11:22 |
| *** Jybz has joined #yosys | 11:32 | |
| ZirconiumX | Bleh. Quartus says that some I/O pins are held at GND, which means somewhere something got lost in translation. | 12:51 |
| ZirconiumX | mwk: Found the lut-shaming article: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01003.pdf | 13:12 |
| *** adjtm has quit IRC | 13:12 | |
| mwk | ZirconiumX: hah, nice | 13:28 |
| mwk | damn, the whole paper really is "look how much virtex 5 sucks" | 13:28 |
| mwk | while conveniently ignoring that virtex 5 LUT6s can, in fact, be split into LUT5s as well | 13:29 |
| ZirconiumX | I mean, it does raise a question of how best to weight LUT sizes | 13:29 |
| ZirconiumX | Although the ALM in the Cyclone V grew two more DFFs. | 13:30 |
| ZirconiumX | I think it should be weighted to prefer LUT3 over LUT2, but LUT5 over LUT6? | 13:32 |
| ZirconiumX | It'd be nice to have numbers on the internal delays here | 13:32 |
| ZirconiumX | But oh well | 13:32 |
| *** togo has joined #yosys | 13:51 | |
| 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 ....) | 13:59 |
| 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. | 14:01 |
| 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? | 14:02 |
| pepijndevos | ZipCPU, don't laugh... it's an RF receiver that has to talk to a particular Arduino library on the other end. | 14:06 |
| janrinze | ooohh! nice. does it use the differential inputs for radio input? | 14:07 |
| 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. | 14:08 |
| 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 | 14:09 |
| pepijndevos | Basically all the C code does is clock recovery, some preamble, and 6-to-4 decoding | 14:10 |
| janrinze | LORA? | 14:11 |
| pepijndevos | Nah, still thinking too fancy. FS1000A and XY-MK-5V | 14:11 |
| pepijndevos | It's impossible to find a proper datasheet for these things, but they appear to be some ASK thing | 14:12 |
| pepijndevos | https://github.com/PaulStoffregen/RadioHead/blob/master/RH_ASK.cpp#L721 | 14:13 |
| tpb | Title: RadioHead/RH_ASK.cpp at master · PaulStoffregen/RadioHead · GitHub (at github.com) | 14:13 |
| janrinze | nice. | 14:15 |
| 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? | 14:18 |
| pepijndevos | In particular thinking of the Tang Nano at the moment, but I suspect not many have used it. I also have an Icebreaker... | 14:19 |
| janrinze | The icebreakers are hard to get. Similar like the small ecp5 boards. | 14:20 |
| pepijndevos | Yea, still hoping to one day aquire a ULX3S *sigh* | 14:25 |
| janrinze | I have bought the ecp5 eval board from lattice. added HDMI out. That works quite nice. | 14:28 |
| pepijndevos | Oh! The Icebreaker actually has RX and TX pins set up. I guess I'll test on that then. | 14:39 |
| janrinze | anyone who knows a good random number generator in verilog? :) | 15:03 |
| janrinze | only need 16 bits :D | 15:03 |
| ZirconiumX | Build a ring oscillator and extract randomness from frequency variation /s | 15:04 |
| whitequark | build two ring oscillators and race them against each other | 15:06 |
| whitequark | that's almost a reasonable solution | 15:06 |
| whitequark | almost, because it is prone to lock-in due to interference, especially if they're placed close together | 15:07 |
| whitequark | but in general, racing two asynchronous clocks is a perfectly fine way to generate entropy | 15:07 |
| janrinze | yosys doesn't seem to like ring oscillators, right> | 15:10 |
| *** Laksen has joined #yosys | 15:16 | |
| whitequark | use (*keep*) and it'll be fine | 15:17 |
| whitequark | you need to instantiate the LUTs of course | 15:17 |
| *** pie_ has quit IRC | 15:28 | |
| ZirconiumX | What units are the ABC9 .lut delays in? | 15:28 |
| *** pie_ has joined #yosys | 15:29 | |
| ZirconiumX | Seems like picoseconds? | 15:45 |
| daveshah | Arbitrary units | 15:49 |
| daveshah | But convention is picoseconds | 15:50 |
| *** gorbak25 has quit IRC | 16:27 | |
| *** fsasm_ has joined #yosys | 16:28 | |
| janrinze | how to tell yosys that two clock delay is fine for timing? | 16:34 |
| janrinze | ehrm, next-pnr of course. | 16:34 |
| daveshah | I'm afraid that's not supported yet | 16:34 |
| daveshah | (it's called a multicycle constraint) | 16:34 |
| *** citypw has quit IRC | 16:39 | |
| *** adjtm has joined #yosys | 16:42 | |
| *** emeb_mac has joined #yosys | 16:55 | |
| *** Laksen has quit IRC | 17:00 | |
| *** emeb has joined #yosys | 17:26 | |
| 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? | 17:51 |
| daveshah | ZirconiumX: worst case | 17:52 |
| ZirconiumX | So collect all four and pick the worst? | 17:52 |
| daveshah | Unless one is explicitly worst case | 17:53 |
| ZirconiumX | daveshah: And fanout? | 18:04 |
| daveshah | That's unlikely to be significant enough at synthesis time | 18:06 |
| ZirconiumX | Fair | 18:06 |
| daveshah | In any case most routing resources are buffered, so physical fanout will differ significantly from logical fanout | 18:07 |
| ZirconiumX | Fair. | 18:08 |
| ZirconiumX | The data here is a bit interesting. | 18:09 |
| ZirconiumX | For example, of the inputs A-F of a cyclonev_lcell_comb primitive, F has the least delay and A the most. | 18:09 |
| daveshah | That sounds quite typical | 18:10 |
| daveshah | I think ecp5 is the same for A-D | 18:10 |
| ZirconiumX | Ah, I see the ECP5 LUT library is labeled D-A not A-D | 18:11 |
| daveshah | For some esoteric reason I think abc needs delays in non-decreasing order | 18:11 |
| daveshah | Don't ask why | 18:11 |
| 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 | 18:14 |
| ZirconiumX | I'll fudge it, and use the one data point lower than input C for testing | 18:14 |
| ZirconiumX | Same for B having lower delay than A | 18:16 |
| ZirconiumX | ...Vice versa | 18:16 |
| daveshah | Well for ECP5 I just mirrored the inputs :/ | 18:27 |
| daveshah | Given that pnr probably permutes inputs anyway, giving them all the max of any of them would probably work fine | 18:28 |
| ZirconiumX | It also appears to depend on the specific LUT in the tile | 19:18 |
| ZirconiumX | (yay) | 19:18 |
| ZirconiumX | These numbers look quite weird to me... | 19:24 |
| ZirconiumX | F: 356 E: 558 D: 541 C: 579 B: 579 A: 572 | 19:26 |
| ZirconiumX | daveshah, does https://gist.github.com/ZirconiumX/5c75a9592d0591ea1449591f66a505c1 look sane? | 19:44 |
| tpb | Title: abc9_cyclonev.lut · GitHub (at gist.github.com) | 19:44 |
| daveshah | Seems reasonable | 19:44 |
| daveshah | Because each layer is probably a layer of a mux tree one way or another, the delay can differ a lot | 19:45 |
| ZirconiumX | This isn't strictly "the max delay", more "maximum of the ones I scavenged before datamining" | 19:46 |
| ZirconiumX | Datamining is not quite the right term here, but it will do | 19:47 |
| ZirconiumX | daveshah: So now presumably I need to build a box library for the DFFs? | 19:49 |
| daveshah | I don't know what the deal with ABC9 and DFFs is | 19:49 |
| *** dys has joined #yosys | 20:21 | |
| *** futarisIRCcloud has quit IRC | 20:34 | |
| *** Jybz has quit IRC | 20:45 | |
| *** Jybz has joined #yosys | 20:45 | |
| *** attie has quit IRC | 20:45 | |
| *** fsasm_ has quit IRC | 21:34 | |
| *** kmehall has quit IRC | 21:49 | |
| *** jhol has quit IRC | 21:49 | |
| *** pointfree has quit IRC | 21:49 | |
| *** jhol has joined #yosys | 21:54 | |
| *** kmehall has joined #yosys | 21:54 | |
| *** pointfree has joined #yosys | 21:54 | |
| 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. | 23:02 |
| janrinze | 88 Mhz target returns 85 Mhz.. | 23:12 |
| *** lutsabound has joined #yosys | 23:13 | |
| *** emeb has quit IRC | 23:19 | |
| *** futarisIRCcloud has joined #yosys | 23:21 | |
| *** Jybz has quit IRC | 23:25 | |
| *** adjtm has quit IRC | 23:59 | |
| *** adjtm has joined #yosys | 23:59 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!