| lkcl | cesar, i tried 55, 40, 30, 25, 20, 15, 12.5 and 10 mhz. | 10:11 |
|---|---|---|
| lkcl | only 12.5mhz and 10 mhz worked on the ulx3s | 10:12 |
| lkcl | took a frickin long time because that's a 2+ hour FPGA route/build each time | 10:12 |
| lkcl | nextpnr-ecp5 is struggling with the larger design | 10:15 |
| cesar | Right. But does the router give you an Fmax estimate, each time? | 11:14 |
| lkcl | yes, and if i recall correctly it matched (roughly). interestingly it varied depending on target speed iirc. | 11:20 |
| lkcl | okaay got a successful verilator build from copying microwatt's simulated uart, Makefile etc. | 11:36 |
| lkcl | it's not actually doing anything because there's no actual core wired in but it's a start | 11:36 |
| cesar | So, 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 |
| lkcl | no, it gave timing reports varying between... i think 12 and... 25 mhz | 12:17 |
| lkcl | the higher i tried the higher the frequency went but it was still always a Fmax below the attempted frequency | 12:18 |
| lkcl | *until* i went to either 10 or 12.5 mhz and then it was ok | 12:18 |
| octavius | cesar, I'm going through you gtkwave example, and I noticed an error in the | 13:16 |
| octavius | tutorial (an perhaps an interesting failure?). | 13:16 |
| octavius | When you add color based on 'in' or 'out' tags, | 13:16 |
| octavius | I saw that 'p_ready_o' was changed in the src code to 'p_o_ready'. | 13:16 |
| octavius | Because gtkwave couldn't find 'p_ready_o', it failed quietly and | 13:16 |
| octavius | didn't display the waveform. | 13:16 |
| octavius | 'fsm_state' (the next signal in traces) was assigned yellow as if it was an | 13:16 |
| octavius | output, but didn't have the 'out' tag! | 13:16 |
| lkcl | octavius, there was a convention-conformance change a few months ago, just update the wiki (and example) to match | 14:31 |
| lkcl | btw you saw this? (new) https://git.libre-soc.org/?p=ls2.git;a=blob;f=src/ls2.py;hb=HEAD | 14:32 |
| lkcl | that's where the pinmux - the auto-generator version - would drop in | 14:32 |
| lkcl | the goal is that pretty much 100% of that is to be auto-generated based on what comes from the pinmux JSON file | 14:33 |
| octavius | sure, will do | 14:59 |
| octavius | Can 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 convention | 17:19 |
| octavius | Also, this ls2.py file is doing quite a bit. For the entire thing to be auto-generated, I guess there's a lot of work left XD | 17:22 |
| octavius | Actually, 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 |
| lkcl | octavius, done | 18:50 |
| lkcl | yes. 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 |
| octavius | nice | 18:53 |
| octavius | Also, where is this convention-conformance about the signal names coming from? Tried searching for it on the wiki | 18:54 |
| lkcl | it's not a published convention | 18:58 |
| octavius | So is the signal "p_shift_i" incorrect then? Should it be "p_i_shift"? | 19:10 |
| octavius | Ooooh, very cool project: https://www.crowdsupply.com/eevengers/thunderscope | 21:36 |
| programmerjake | neat! | 22:03 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!