| *** tpb has joined #litex | 00:00 | |
| *** Degi has quit IRC | 00:21 | |
| *** Degi has joined #litex | 00:21 | |
| *** _whitelogger has quit IRC | 02:03 | |
| *** _whitelogger has joined #litex | 02:05 | |
| *** CarlFK has quit IRC | 02:40 | |
| *** levi has quit IRC | 02:56 | |
| *** mithro has quit IRC | 02:59 | |
| *** guan has quit IRC | 03:02 | |
| *** jaseg has quit IRC | 03:02 | |
| *** jaseg has joined #litex | 03:04 | |
| *** rohitksingh has quit IRC | 03:09 | |
| *** bubble_buster has quit IRC | 03:11 | |
| *** rohitksingh has joined #litex | 03:12 | |
| *** bubble_buster has joined #litex | 03:13 | |
| *** rohitksingh has quit IRC | 03:20 | |
| *** bubble_buster has quit IRC | 03:21 | |
| *** rohitksingh has joined #litex | 03:24 | |
| *** bubble_buster has joined #litex | 03:24 | |
| *** guan has joined #litex | 03:25 | |
| *** mithro has joined #litex | 03:25 | |
| *** levi has joined #litex | 03:26 | |
| *** HoloIRCUser1 has joined #litex | 03:35 | |
| *** HoloIRCUser has quit IRC | 03:39 | |
| *** davidcorrigan714 has joined #litex | 03:51 | |
| *** _whitelogger has quit IRC | 05:09 | |
| *** davidcorrigan714 has quit IRC | 05:11 | |
| *** _whitelogger has joined #litex | 05:11 | |
| *** kgugala_ has joined #litex | 06:05 | |
| *** kgugala has quit IRC | 06:08 | |
| *** kgugala has joined #litex | 06:14 | |
| *** kgugala_ has quit IRC | 06:17 | |
| *** CarlFK has joined #litex | 06:28 | |
| *** kgugala has quit IRC | 06:38 | |
| *** kgugala has joined #litex | 06:38 | |
| *** tcal has quit IRC | 07:56 | |
| *** kgugala_ has joined #litex | 10:49 | |
| *** kgugala has quit IRC | 10:53 | |
| lkcl | that's interesting. nextpnr-ecp5 compiling microwatt didn't complete (overnight!) and has locked up solid after 15 hours, with 4,000 / 140,000 routes left. | 12:31 |
|---|---|---|
| daveshah | the routeability of large ecp5 designs isn't great | 12:32 |
| lkcl | annoying as i need it in order to test DDR3 memtest with 64-bit | 12:33 |
| daveshah | you can try Rocket, it isn't POWER but in the default, non-Linux-ready config, I think it should fit slightly better | 12:35 |
| lkcl | ah that's rocket-chip (written in chisel3). yeah | 12:36 |
| lkcl | arg probably need an updated rv cross compiler... hm there should be debian packages | 12:38 |
| lkcl | ah interesting, upgrading to gcc-9 didn't help | 12:41 |
| lkcl | litex/litex/soc/software/bios/isr.c:56: Error: Instruction csrr requires absolute expression | 12:42 |
| lkcl | bizarre-ness. picorv32 csrr() and microwatt csrr() macros in their respective system.h are identical | 12:45 |
| *** kgugala has joined #litex | 12:46 | |
| lkcl | but it's on mtval (in software/bios/isr.c) which i've commented out | 12:47 |
| lkcl | i *think* this is because mtval was retired (or is optional) | 12:48 |
| *** kgugala_ has quit IRC | 12:48 | |
| lkcl | ahh interesting. i'm getting data corruption on the UART terminal (minicom) | 12:50 |
| lkcl | this is on libresoc 64-bit 55mhz with latest git master | 12:51 |
| lkcl | daveshah: urrr.... rocketchip build - Info: 9.8 ns logic, 33.0 ns routing | 13:07 |
| lkcl | Warning: Max frequency for clock '$glbnet$sys_clk': 23.36 MHz (FAIL at 55.01 MHz) | 13:07 |
| lkcl | aaa i just want something to work! :) | 13:08 |
| lkcl | the axi4 to tilelink converter creates a morass of critical path dependencies | 13:09 |
| * lkcl is trying 50mhz nextpnr-ecp5 builds and that seems to work (picorv32) | 13:30 | |
| lkcl | i suspect that the libresoc build, at 55mhz, is just too close to the limit estimated by nextpnr... nope. arse. a 50mhz libresoc build gets the same UART corruption. | 13:31 |
| lkcl | ahh interesting | 13:39 |
| lkcl | _florent_: when i re-added kwargs["integrated_main_ram_size"] = 0x1000 the UART corruption (black square "?" being the predominant char) went away | 13:40 |
| *** proteusguy has quit IRC | 15:08 | |
| *** proteusguy has joined #litex | 15:22 | |
| *** kgugala_ has joined #litex | 15:44 | |
| *** kgugala has quit IRC | 15:47 | |
| *** HoloIRCUser has joined #litex | 18:20 | |
| *** HoloIRCUser1 has quit IRC | 18:20 | |
| somlo | lkcl: I'm probably late to this party, but I managed to get 30 "official" MHz timing for my 5g-versa board with this command line: | 19:43 |
| somlo | litex-boards/litex_boards/targets/versa_ecp5.py --sys-clk-freq 60e6 --csr-data-width 32 --cpu-type rocket --integrated-rom-size 0x10000 --build | 19:43 |
| somlo | I can't test it right now, but the "advertised" fmax is usually *way* lower than what one can get away with (nextpnr is typically overly conservative w.r.t. timing) | 19:44 |
| somlo | I also had to remove "-abc9" here: https://github.com/enjoy-digital/litex/blob/master/litex/build/lattice/trellis.py#L57 (latest abc crashes about 50% of the time when called from yosys' abc9 stage) | 19:44 |
| tpb | Title: litex/trellis.py at master · enjoy-digital/litex · GitHub (at github.com) | 19:44 |
| somlo | I think I'm going to revert litex commit 6c298cb7 and make abc9 optional via a command line flag | 19:45 |
| somlo | and if you have a non-5g versa board, you'll probably need to make additional tweaks to the litex build environment (but if you've already been building stuff for your versa board, you've likely already figured that part out) | 19:47 |
| somlo | once I free up my (currently busy) usb port, I can actually test the bitstream I built and see if it actually works, and if it manages to pass memtest, but that'll have to wait for a couple of hours :) | 19:48 |
| lkcl | somlo: ah thank you | 20:30 |
| lkcl | ahh interesting. csr data width normally defaults to 8 bit | 20:32 |
| lkcl | i wonder if that has any impact, here. | 20:33 |
| somlo | lkcl: historically, I don't think csr-data-width has had a major impact on timing, placement, or utilization | 20:39 |
| lkcl | ok appreciated | 20:44 |
| lkcl | aw poop, forgot the --device=LFE5UM :) | 20:48 |
| somlo | oh, so you do have a non-5g versa, then :) | 20:58 |
| lkcl | somlo: for lack of being able to purchase a 5g version via mouser 3 months ago... yes | 20:59 |
| somlo | I'm still ripping a multi-cd audiobook to mp3 for my daughter, and the one usb port I could use to hook up my dev board is currently occupied by the cd drive -- so I can't test myself for a while :) | 20:59 |
| somlo | lkcl: I initially ordered a 5g versa, they shipped me a non-5g one, daveshah helped me figure out why it wasn't working the way I thought it should have -- long story short, it took another month or so to sort out the mess :) | 21:01 |
| lkcl | doh | 21:01 |
| somlo | eventually they sent me the right one (this was via the lattice web store from the US) | 21:01 |
| lkcl | oh cool | 21:02 |
| lkcl | built - and fails. | 21:03 |
| lkcl | ./versa_ecp5.py --sys-clk-freq 50e6 --device=LFE5UM --csr-data-width 32 --cpu-type rocket --integrated-rom-size 0x10000 --build | 21:03 |
| lkcl | Warning: Max frequency for clock '$glbnet$sys_clk': 20.58 MHz (FAIL at 50.00 MHz) | 21:03 |
| somlo | aaah, that | 21:04 |
| somlo | try pushing the bitstream to the board anyway, see what happens | 21:04 |
| lkcl | because of the massive combinatorial chain between tilelink and axi-lite | 21:04 |
| lkcl | nope, fail | 21:04 |
| somlo | I consistently get "fails at 30 (or 40) MHz" on a trellisboard (after requesting 60MHz) and it works fine :) | 21:05 |
| lkcl | i mean: it loads successfully, it just doesn't report anything on the USB console | 21:05 |
| lkcl | :) | 21:05 |
| daveshah | somlo: I remember Rocket giving 50MHz+ once upon a time | 21:05 |
| somlo | right, so then it *really* fails | 21:05 |
| daveshah | did we ever figure out why that changed? | 21:05 |
| somlo | daveshah: not sure if it was rocket, or yosys/trellis/nextpnr, or some interaction between the changes made to each of them | 21:06 |
| somlo | I remember a point in time when bumping the rocket chip git version caused utilization to go up by 6-7 % | 21:06 |
| daveshah | yeah, seems likely | 21:07 |
| daveshah | that was probably almost a year ago that I remember that number from | 21:07 |
| somlo | but I didn't pay as much attention to timing. I think at some point (before that) I had been complaining about no longer meeting timing, and litex switched to "--timing-allow-fail" based on the "looseness" of that calculation in nextpnr... | 21:08 |
| somlo | these days I can get 60MHz working on the trellisboard most of the time, and the "linux" version of rocket will no longer fit on the versa no matter what (105+ % utilization), so I haven't tried with that board in the last several months | 21:10 |
| lkcl | somlo: do you happen to have _anything_ that has a 64 bit bus, that you know (last time you tried it) "works"? | 21:11 |
| lkcl | nextpnr-ecp5 on microwatt took 16 hours to fail to complete routing (locked up with 5% nets left) | 21:12 |
| somlo | lkcl: http://www.contrib.andrew.cmu.edu/~somlo/BTCP/#sec_2_2_1 | 21:18 |
| tpb | Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 21:18 |
| somlo | some git versions of things I used back a while ago. sadly, I don't remember which litex commit that was at the time | 21:18 |
| lkcl | cpu-variant "linuxd"? what's that one? | 21:19 |
| somlo | lkcl: there's several versions of rocket with different mem-axi port widths, matching the native width of litedram on various dev boards | 21:23 |
| somlo | so we can hook rocket's memory port directly to litedram, point-to-point, and bypass the wishbone bus used for MMIO | 21:23 |
| somlo | but if we're looking for something we know used to work, I'd check out litex cca. 1 year ago, e.g. commit 4cc40aad | 21:24 |
| somlo | also check out one of the earlier (earliest) versions of pythondata-cpu-rocket to match | 21:25 |
| somlo | lkcl: there's another trick I remember from a while back: using `--nextpnr-timingstrict` with `versa_ecp5.py`, so that it *properly* fails when not meeting timing | 21:34 |
| somlo | then running that in a `for` loop in the shell, until you get lucky and it succeeds :) | 21:34 |
| somlo | but that might take a while (days) | 21:34 |
| somlo | and it's not guaranteed to work | 21:34 |
| lkcl | yyeah | 21:41 |
| lkcl | and i'd have to then try to get libresoc working against that version of litex, to be able to make a fair comparison | 21:41 |
| lkcl | i think... i am tempted to track down a nmigen 64-to-32-bit converter and throw that in front, before the data requests reach litex | 21:42 |
| lkcl | hey i got the LUT4s down from 20,000 to around 16,000 by adding in sync delays into the regfile reads, that gave nextpnr a chance to to "hey i can use BRAMS now" | 21:45 |
| lkcl | yaay | 21:45 |
| daveshah | it's yosys that does that not nextpnr, jfyi | 21:45 |
| lkcl | daveshah: oh, ta :) | 21:46 |
| daveshah | and yeah, that will definitely help :) | 21:46 |
| lkcl | i'm very happy. it was... a small but hair-raising change | 21:46 |
| daveshah | this is the kind of interesting difference between what is efficient on ASIC vs FPGA | 21:46 |
| lkcl | i'm doing an out-of-order design, which (for now) has a FSM, however all the infrastructure is there to add the dependency matrices in | 21:47 |
| lkcl | which means that there are *combinatorial* "Pipeline Managers" that expect operands to come in with a "operand is ok" plus "actual operand" in the *same* cycle | 21:47 |
| lkcl | not, as things are done in regfiles, on the *next* cycle (after the read-enable) | 21:48 |
| lkcl | so, of course, to make life easier, i made the regfile combinatorial as well... | 21:48 |
| lkcl | baad move | 21:49 |
| lkcl | daveshah: well, it's more that i've never done this before. | 21:51 |
| lkcl | i had: | 21:51 |
| lkcl | * an instruction decoder that was combinatorial and | 21:52 |
| lkcl | * a regfile read likewise and | 21:52 |
| lkcl | * a pipeline manager likewise... | 21:52 |
| lkcl | no wonder i was only getting 20 mhz, a couple days ago :) | 21:52 |
| lkcl | nuts to it, i'm going to try libresoc @ 75mhz | 22:00 |
| lkcl | what's a DPR16X4? | 22:04 |
| somlo | lkcl: just tried that bitstream on the 5g versa, and it works (requested 50MHz, "passed" at 24-and-change, works fine, including passing memtest, at 50 when programmed) | 22:08 |
| daveshah | lkcl: 16x4 bit distributed RAM | 22:09 |
| daveshah | ie a cluser of 4 LUTs can be used as RAM instead of ROM | 22:09 |
| lkcl | daveshah: thx | 22:10 |
| lkcl | somlo: hmm interesting. | 22:10 |
| lkcl | what versions of... "stuff" are you using? | 22:10 |
| lkcl | because if you use latest rocket-chip, they're removed mtval | 22:11 |
| lkcl | so it's guaranteed that the litex bios won't compile | 22:11 |
| somlo | https://imgur.com/a/wpFgTbu | 22:12 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 22:12 |
| lkcl | litex git a0c8bb55 | 22:13 |
| somlo | litex 35929c0f yosys c39ebe6 trellis f93243b nextpnr b39a2a5 | 22:14 |
| somlo | "latest" to within the last week, or thereabouts | 22:14 |
| lkcl | ok got it | 22:15 |
| lkcl | i've got a version of trellis and nextpnr from about a month ago | 22:16 |
| somlo | lkcl: I would bet against that making a relevant difference, but one never knows for sure :) | 22:19 |
| lkcl | wait... is there anything that's determined by software read-levelling that is passed over to hardware? | 22:22 |
| lkcl | i get this: | 22:27 |
| lkcl | Read leveling: | 22:27 |
| lkcl | m0, b00: |0| delays: - | 22:27 |
| somlo | I think `read_delay_inc()` is used to modify `dq` based on calibration tests | 22:27 |
| lkcl | argh ok | 22:27 |
| lkcl | so, the core i'm doing is currently a FSM, not a pipelined design | 22:28 |
| somlo | but I'm dangerously approaching the limits of my understanding of litedram :) | 22:28 |
| lkcl | because the dependency matrices are massive and particularly complex, i've left them out for now (to add later) | 22:29 |
| lkcl | problem is: the CPU therefore runs at a 0.1 to 0.2 IPC | 22:29 |
| lkcl | somlo: i kiiinda get it. i'll take a look | 22:30 |
| daveshah | Given that SERV runs litedram calibration just fine and that is IPC <0 | 22:31 |
| daveshah | <0.1 | 22:31 |
| daveshah | there shouldn't be an IPC dependency | 22:31 |
| * sorear thinks about the implications of ipc<0 | 22:31 | |
| daveshah | Even PicoRV32 is an IPC of only 0.2 ish, less depending on the memory bus | 22:31 |
| lkcl | daveshah: ok. even stranger, then | 22:32 |
| daveshah | Is there any cache involved? | 22:33 |
| lkcl | daveshah: no, no caches | 22:33 |
| lkcl | (yet) | 22:33 |
| daveshah | Good, that eliminates one cause of ddr3 calibration issues | 22:34 |
| daveshah | My guess is that something somewhere is going wrong in the bus interface | 22:35 |
| lkcl | daveshah: i did have an issue with the load/store interface, dropping the wishbone "ack" far too early | 22:36 |
| lkcl | i did fix that (so that sim.py works) | 22:36 |
| lkcl | tck-tck... i need to run some of microwatt's unit tests under the litex sim.py | 22:37 |
| lkcl | how do you specify an alternative binary to be loaded in litex (at address 0x000000)? | 22:38 |
| daveshah | Not sure, I haven't used sim.py much | 22:39 |
| daveshah | https://github.com/litex-hub/linux-on-litex-vexriscv/issues/84 might be interesting though. Simulating part of the DRAM interface. | 22:39 |
| lkcl | my guess is, specify a different "BIOS" | 22:39 |
| tpb | Title: sim: use SDRAM DFI model for simulation · Issue #84 · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 22:39 |
| daveshah | Yeah | 22:39 |
| lkcl | that's an interesting one, i think i'll try that | 22:41 |
| lkcl | of course, disable --integrated_ram_size (doh) | 22:44 |
| *** lf has quit IRC | 23:08 | |
| *** lf has joined #litex | 23:09 | |
| lkcl | ahhh :) | 23:11 |
| lkcl | daveshah: good call. | 23:11 |
| lkcl | managed very quickly to put something together | 23:12 |
| lkcl | microwatt: passed | 23:12 |
| lkcl | libresoc: fail | 23:12 |
| lkcl | *now* i have something i can test/compare against | 23:12 |
| lkcl | and, as an added bonus, get a vcd trace | 23:12 |
| lkcl | excellent call | 23:12 |
| daveshah | Great! | 23:15 |
| lkcl | thank you for that. vcd file's going to be massive... one for investigating tomorrow. | 23:21 |
| lkcl | btw do you have some trellisboards available? | 23:22 |
| daveshah | No, unfortunately not | 23:27 |
| lkcl | daveshah: ok. i noticed the UXLS3 has an 85k version _and_ SDRAM. | 23:28 |
| daveshah | Yep | 23:29 |
| daveshah | Should be a bit simpler to debug than DDR3, too | 23:29 |
| daveshah | From memory it was running reliably for me even at 16MHz | 23:29 |
| lkcl | yeah that sounds not unreasonable for SDRAM. i'd really like to test opencores sdram before putting it into an actual ASIC | 23:31 |
| lkcl | ok enough. 00:31 here :) | 23:31 |
| daveshah | Ditto :) | 23:32 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!