Monday, 2022-02-14

lkclcesar, i tried 55, 40, 30, 25, 20, 15, 12.5 and 10 mhz.10:11
lkclonly 12.5mhz and 10 mhz worked on the ulx3s10:12
lkcltook a frickin long time because that's a 2+ hour FPGA route/build each time10:12
lkclnextpnr-ecp5 is struggling with the larger design10:15
cesarRight. But does the router give you an Fmax estimate, each time?11:14
lkclyes, and if i recall correctly it matched (roughly). interestingly it varied depending on target speed iirc.11:20
lkclokaay got a successful verilator build from copying microwatt's simulated uart, Makefile etc.11:36
lkclit's not actually doing anything because there's no actual core wired in but it's a start11:36
cesarSo, when you tried 55 MHz, it gave you an Fmax of approximately 55 MHz, and even so it didn't work on the FPGA? That is not good... I guess the timing information on the reverse engineered tools is not so accurate. Or, your FPGA is borked...11:54
lkclno, it gave timing reports varying between... i think 12 and... 25 mhz12:17
lkclthe higher i tried the higher the frequency went but it was still always a Fmax below the attempted frequency12:18
lkcl*until* i went to either 10 or 12.5 mhz and then it was ok12:18
octaviuscesar, I'm going through you gtkwave example, and I noticed an error in the13:16
octaviustutorial (an perhaps an interesting failure?).13:16
octaviusWhen you add color based on 'in' or 'out' tags,13:16
octaviusI saw that 'p_ready_o' was changed in the src code to 'p_o_ready'.13:16
octaviusBecause gtkwave couldn't find 'p_ready_o', it failed quietly and13:16
octaviusdidn't display the waveform.13:16
octavius'fsm_state' (the next signal in traces) was assigned yellow as if it was an13:16
octaviusoutput, but didn't have the 'out' tag!13:16
lkcloctavius, there was a convention-conformance change a few months ago, just update the wiki (and example) to match14:31
lkclbtw you saw this? (new);a=blob;f=src/;hb=HEAD14:32
lkclthat's where the pinmux - the auto-generator version - would drop in14:32
lkclthe goal is that pretty much 100% of that is to be auto-generated based on what comes from the pinmux JSON file14:33
octaviussure, will do14:59
octaviusCan I get access to nmutils repo lkcl (I checked only have R access)? The 'p_shift_i' signal looks like it's not following the convention17:19
octaviusAlso, this file is doing quite a bit. For the entire thing to be auto-generated, I guess there's a lot of work left XD17:22
octaviusActually, I'm seeing some resemblance to the code you've been guiding me through, it's just a matter of parsing I guess. Although I don't see any muxing or bank selection there (probably because we don't have that yet)17:24
lkcloctavius, done18:50
lkclyes. a stub base class SoC would be totally empty then go "for peripheral in pinmux_list_from_json(blah blah): do_stuff_with(perihperal)"18:51
octaviusAlso, where is this convention-conformance about the signal names coming from? Tried searching for it on the wiki18:54
lkclit's not a published convention18:58
octaviusSo is the signal "p_shift_i" incorrect then? Should it be "p_i_shift"?19:10
octaviusOoooh, very cool project:

Generated by 2.17.1 by Marius Gedminas - find it at!