| *** tpb has joined #litex | 00:00 | |
| *** CarlFK has quit IRC | 00:13 | |
| *** Degi has quit IRC | 00:24 | |
| *** Degi has joined #litex | 00:28 | |
| *** jaseg has quit IRC | 00:32 | |
| *** HoloIRCUser has joined #litex | 00:33 | |
| *** jaseg has joined #litex | 00:34 | |
| *** HoloIRCUser has quit IRC | 00:34 | |
| *** HoloIRCUser has joined #litex | 00:34 | |
| *** HoloIRCUser1 has quit IRC | 00:36 | |
| futarisIRCcloud | https://hackaday.com/2020/08/12/degrees-of-freedom-booting-arm-processors/ | 00:47 |
|---|---|---|
| tpb | Title: Degrees Of Freedom: Booting ARM Processors | Hackaday (at hackaday.com) | 00:47 |
| *** HoloIRCUser1 has joined #litex | 01:03 | |
| *** HoloIRCUser2 has joined #litex | 01:04 | |
| *** HoloIRCUser1 has quit IRC | 01:04 | |
| *** HoloIRCUser has quit IRC | 01:07 | |
| *** mescobar has joined #litex | 01:55 | |
| *** jaseg has quit IRC | 02:11 | |
| *** jaseg has joined #litex | 02:12 | |
| mescobar | If I wanted to access CSR register map through JTAG, can I use the Xilinx JTAG hw transactions? Or should I resort to OpenOCD? | 02:43 |
| *** MyGreenBalloon has joined #litex | 03:45 | |
| *** _whitelogger has quit IRC | 04:00 | |
| *** _whitelogger has joined #litex | 04:02 | |
| *** MyGreenBalloon has quit IRC | 04:22 | |
| *** kgugala__ has joined #litex | 04:59 | |
| *** kgugala_ has quit IRC | 05:01 | |
| *** mescobar has quit IRC | 06:04 | |
| *** HoloIRCUser has joined #litex | 06:52 | |
| *** HoloIRCUser2 has quit IRC | 06:54 | |
| *** kgugala has joined #litex | 07:07 | |
| *** kgugala__ has quit IRC | 07:09 | |
| *** kgugala_ has joined #litex | 07:52 | |
| *** kgugala has quit IRC | 07:55 | |
| *** kgugala_ has quit IRC | 08:04 | |
| *** kgugala has joined #litex | 08:04 | |
| *** CarlFK has joined #litex | 09:03 | |
| *** anand has joined #litex | 09:36 | |
| *** anand is now known as Guest44036 | 09:36 | |
| Guest44036 | Hi, I am facing an error while trying to run the simulation | 09:44 |
| Guest44036 | OSError: Unable to find any of the cross compilation toolchains: - lm32-elf | 09:44 |
| Guest44036 | the list of cross compilation toolchains differ according to the cpu i choose | 09:45 |
| Guest44036 | How can I fix this? Any help would be appreciated, Thanks :) | 09:45 |
| zyp | install the required toolchain :) | 09:45 |
| Guest44036 | I tried that, still fails | 09:51 |
| zyp | which cpu are you trying and which toolchain did you install? | 09:52 |
| Guest44036 | lm32 or vexriscv for that matter. It ran the first time, but my project is to add a new cpu along wth the existing ones. After some local changes, it started giving this error | 09:53 |
| zyp | you need to be more specific, lm32 and vexriscv requires different toolchains | 09:54 |
| zyp | the gcc_triple parameter to the CPU class tells litex what toolchain to use to build the litex bios | 09:58 |
| zyp | so if you're adding a new CPU, you'll want to set it to something suitable | 09:58 |
| zyp | (and also have it installed) | 09:58 |
| *** _whitelogger has quit IRC | 10:03 | |
| Guest44036 | okay i will try, thanks a lot | 10:04 |
| *** _whitelogger has joined #litex | 10:05 | |
| daveshah | awygle: I haven't had much luck above 100MHz system/200MHz memory/400Mbps DDR | 10:43 |
| daveshah | I think that is partly due to the control CPU though, and also the magic latency numbers not being tuned right above that | 10:43 |
| scientes | risc-v also has MANY options | 11:14 |
| scientes | and you need to make sure that you get it right i your cpu doesn't have multiplication for example | 11:14 |
| scientes | (the compilers also don't really support the bit manip extensions yet, but that too) | 11:15 |
| daveshah | For the LiteX BIOS it shouldn't matter as LiteX provides a minimal standard library and compiler_rt | 11:23 |
| daveshah | Even a riscv64 gcc can still build 32-bit rv32i code, it just doesn't necessarily have a standard library available | 11:23 |
| scientes | clang can build all targets that from the same binary... | 11:24 |
| scientes | and if you use zig to drive clang then it also can cross-compile musl for you and compiler-rt | 11:24 |
| daveshah | Yes, someone should probably add the LiteX glue to use that as an option | 11:25 |
| scientes | (this is a well known deficiency of GCC that is difficult to fix) | 11:26 |
| scientes | oh wow, libgcc really does have multiplication implemented as addition in a loop | 11:30 |
| scientes | *addition and shifts | 11:30 |
| daveshah | LiteX uses LLVM compiler-rt already | 11:32 |
| lkcl | h | 11:33 |
| lkcl | hi all | 11:33 |
| lkcl | anyone any clues why would nextpnr-ecp5 fail routing of sys_clk2x ? | 11:34 |
| lkcl | does its thing, gets down to only 175 routes left to do, then wark | 11:35 |
| daveshah | Possibly because of edge clock promotion issues | 11:35 |
| daveshah | Can you run with --debug --verbose and post the last few output lines? | 11:35 |
| lkcl | sure... ah... that means restarting one of those 10-15 min long runs... :) | 11:36 |
| lkcl | argh, this time it succeeded | 11:37 |
| lkcl | hey i got the time down from 45ns routing latency to 22ns yippee | 11:38 |
| lkcl | daveshah: it appears that nextpnr-ecp5 is non-deterministic in its routing. i can *maybe* catch it "in the act" (some time) | 11:48 |
| daveshah | Shouldn't be | 11:48 |
| lkcl | what do i need to run with --debug --verbose? | 11:48 |
| daveshah | nextpnr | 11:48 |
| lkcl | ok. litex outputs the command (full parameters) to be run, to stdout? or is there a way to modify the versa_ecp5.py build script to pass those options? | 11:49 |
| daveshah | not sure | 11:49 |
| lkcl | or am i doing "find litex -name "nextpnr"" ? :) | 11:49 |
| daveshah | incidentally, nextpnr should print checksums of the design at various points so you can see which step is actually being nondeterministic | 11:49 |
| lkcl | ahh interesting | 11:50 |
| lkcl | "litex/build/lattice/trellis.py" | 11:51 |
| * lkcl modified _build_template... started... | 11:52 | |
| daveshah | you can also try and capture the json files from two different runs to see if something nondeterminstic is going on in Yosys or LiteX | 11:53 |
| lkcl | good idea | 11:53 |
| lkcl | oh. | 11:53 |
| lkcl | i remember: raptor engineering found a bug in yosys. must remember to update. | 11:54 |
| lkcl | it was quite recent | 11:54 |
| * lkcl hmmm yosys git logs don't show anything though | 11:55 | |
| *** Guest44036 has quit IRC | 11:57 | |
| lkcl | daveshah: annoying. succeeded again | 12:00 |
| lkcl | nonreproducible. | 12:01 |
| daveshah | weird, it's not something I've seen either | 12:01 |
| lkcl | it happened on the microwatt build as well | 12:02 |
| daveshah | what board? versa | 12:02 |
| lkcl | yes - versa ecp5 (LFE5UM) | 12:02 |
| daveshah | I see, I will try and see if I can trigger it at some point | 12:02 |
| lkcl | about the DDR3: i managed to get up to 44mhz so far | 12:03 |
| lkcl | 24.2ns routing latency | 12:03 |
| lkcl | if say 40mhz DDR3 initialisation worked, we'd be operational (without needing to mess with a separate PLL) | 12:05 |
| lkcl | daveshah: would you be able to help with either of those? (donations from NLNet available) | 12:08 |
| daveshah | Yes, I'm a bit backlogged but I will see what I can do | 12:09 |
| daveshah | not so sure about the DDR3 init but the eclk bug is probably an easy fix once it can be reliably triggered | 12:09 |
| lkcl | running DDR3 off of a 2nd PLL would be the "nicer" solution, as other projects could benefit from being able to run... | 12:09 |
| lkcl | daveshah: ok cool | 12:09 |
| daveshah | _florent_ (or perhaps one of the Antmicro people) would probably be the better person for big litedram changes | 12:10 |
| lkcl | daveshah: yeahh florent's on holiday at the moment | 12:10 |
| daveshah | lkcl: this patch makes 40MHz system clock work, it should be possible to make other rates work tweaking the magic number more | 12:42 |
| daveshah | https://www.irccloud.com/pastebin/RBPjfZ4h/ | 12:42 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 12:42 |
| daveshah | a better patch would be to auto-calibrate it as part of DDR training :) | 12:42 |
| lkcl | daveshah: ah ha! | 12:43 |
| lkcl | sigh yes :) | 12:43 |
| daveshah | 30MHz works too with that patch | 12:43 |
| daveshah | unfortunately, haven't triggered the other bug yet (or seen any non-deterministic behaviour using the same JSON, for that matter)] | 12:44 |
| lkcl | will see how it goes @ 30mhz | 12:46 |
| lkcl | nope, fail. | 12:53 |
| lkcl | trying 40mhz | 12:53 |
| lkcl | hmm, max freq says 33 mhz so will try 32 | 12:54 |
| daveshah | you might also need to try other values of that latency adder value | 12:55 |
| lkcl | daveshah: yes was just thinking that | 12:55 |
| lkcl | daveshah: i'm starting to wonder if there's something introduced in the version of litedram that's not the same as what i have. | 13:26 |
| lkcl | what git revision of litedram are you using? | 13:26 |
| daveshah | 198bcbab676e2b4065e5b6a7dc8a7733bae8315a | 13:26 |
| lkcl | i am on commit 198bcbab676e2b4065e5b6a7dc8a7733bae8315a | 13:26 |
| lkcl | hmmm | 13:26 |
| daveshah | snap | 13:26 |
| daveshah | sorry if it's a dumb question but are you sure your litedram change is actually being picked up (e.g. litedram isn't pip installed somewhere or something) | 13:27 |
| lkcl | currently building with "read_latency = 2 + cl_sys_latency + 2 + log2_int(4//nphases)," | 13:27 |
| lkcl | good question | 13:27 |
| daveshah | asking because I've made that mistake before :) | 13:27 |
| daveshah | that seems like too low | 13:27 |
| daveshah | I would expect the correct value to be between 3 and 6 | 13:27 |
| daveshah | + 3 and + 6 | 13:27 |
| lkcl | tried +4 +3 +2 will give +6 a go | 13:29 |
| *** m4ssi has joined #litex | 13:35 | |
| lkcl | hmm best to try with picorv32 | 13:40 |
| lkcl | nope - not with picorv32 @ 30mhz, not any values - 0-7. | 14:02 |
| daveshah | does 40mhz work with any value? | 14:03 |
| lkcl | 1 sec | 14:04 |
| lkcl | btw one odd thing, the software test: | 14:04 |
| lkcl | best: m0, b02 delays: 04+-01 | 14:04 |
| lkcl | best: m1, b00 delays: 00+-00 | 14:04 |
| lkcl | 40mhz no. | 14:09 |
| lkcl | 60mhz yes | 14:09 |
| lkcl | 60 mhz software-test m1, b00: |11100000| delays: 01+-01 | 14:09 |
| daveshah | and you are sure that the change is actually having an effect at all? | 14:10 |
| lkcl | yes, i can see "really bad settings equals total garbage" | 14:10 |
| daveshah | I see | 14:10 |
| lkcl | vs "reasonable settings at least gets 8/256 bus errors" | 14:10 |
| daveshah | probably a board-to-board difference then | 14:10 |
| lkcl | 48 mhz fail | 14:11 |
| daveshah | particularly as you are using a non-5G board, at 1.1V vs 1.2V the internal timings might be a bit different | 14:11 |
| lkcl | i hate those | 14:11 |
| daveshah | I remember back when debugging lower frequency issues (55MHz in that case) there was a difference between different boards | 14:12 |
| daveshah | Not sure what other magic numbers would help, though | 14:12 |
| lkcl | well, i have a target routing latency to reach, of 16 ns | 14:13 |
| lkcl | back-calculated from 60mhz | 14:13 |
| daveshah | you need to add logic delay, too | 14:13 |
| daveshah | although for ECP5 most delay is in the routing, so a typical 60MHz design might be 12ns routing and 4ns logic or so | 14:14 |
| lkcl | currently Info: 6.1 ns logic, 21.7 ns routing | 14:15 |
| lkcl | which is 37mhz | 14:15 |
| lkcl | ooo got it down to 23ns | 14:53 |
| *** indy has quit IRC | 15:04 | |
| *** kgugala_ has joined #litex | 15:18 | |
| *** kgugala has quit IRC | 15:20 | |
| *** FFY00 has quit IRC | 15:26 | |
| *** FFY00 has joined #litex | 15:27 | |
| *** kgugala_ has quit IRC | 15:33 | |
| *** kgugala has joined #litex | 15:34 | |
| awygle | daveshah: thanks! good to know | 16:57 |
| *** m4ssi has quit IRC | 16:59 | |
| daveshah | awygle: if you are interested, I think the way to make it faster would be to do a soft 4:8 serialisation so most of the logic could run at 100MHz for 800Mbps data rate | 17:14 |
| daveshah | sadly the cross-clock constraint support in nextpnr is probably not yet good enough for such a design to work 100% reliably | 17:14 |
| awygle | Yeah I'm doing a design without a cpu which has a CDC to the close-to-the-chip part of the design | 17:29 |
| awygle | Should handle 800Mbps/pin, or more if the i/o buffers were better | 17:30 |
| awygle | I was a bit worried about the multiple clock constraints, what should I know about that? | 17:32 |
| daveshah | nextpnr prints the max and min delay between clock domains, but it doesn't support constraining or optimising for this | 17:33 |
| awygle | So to be clear, multiple constraints work fine _within_ domains, but the cross clock constraints are not supported? | 17:33 |
| awygle | I.E. It's the CDC FIFO that would be failing? | 17:34 |
| daveshah | Yep | 17:36 |
| daveshah | If you design is conservative and follows usual CDC best practice then it will probably work | 17:36 |
| *** kgugala has quit IRC | 17:38 | |
| *** kgugala_ has joined #litex | 17:47 | |
| awygle | ok, cool. the nmigen async fifos seem pretty good, so should be relatively safe | 17:52 |
| *** SpaceCoaster has quit IRC | 18:54 | |
| *** SpaceCoaster has joined #litex | 18:55 | |
| *** m4ssi has joined #litex | 23:11 | |
| *** lf_ has quit IRC | 23:11 | |
| *** lf has joined #litex | 23:11 | |
| *** m4ssi has quit IRC | 23:20 | |
| *** lkcl has quit IRC | 23:32 | |
| *** lkcl has joined #litex | 23:35 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!