<tpb>
Title: Degrees Of Freedom: Booting ARM Processors | Hackaday (at hackaday.com)
HoloIRCUser1 has joined #litex
HoloIRCUser2 has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]
HoloIRCUser has quit [Ping timeout: 272 seconds]
mescobar has joined #litex
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #litex
<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?
MyGreenBalloon has joined #litex
_whitelogger has joined #litex
MyGreenBalloon has quit [Remote host closed the connection]
kgugala__ has joined #litex
kgugala_ has quit [Ping timeout: 256 seconds]
mescobar has quit [Remote host closed the connection]
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Ping timeout: 260 seconds]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 240 seconds]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
CarlFK has joined #litex
anand has joined #litex
anand is now known as Guest44036
<Guest44036>
Hi, I am facing an error while trying to run the simulation
<Guest44036>
OSError: Unable to find any of the cross compilation toolchains: - lm32-elf
<Guest44036>
the list of cross compilation toolchains differ according to the cpu i choose
<Guest44036>
How can I fix this? Any help would be appreciated, Thanks :)
<zyp>
install the required toolchain :)
<Guest44036>
I tried that, still fails
<zyp>
which cpu are you trying and which toolchain did you install?
<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
<zyp>
you need to be more specific, lm32 and vexriscv requires different toolchains
<zyp>
the gcc_triple parameter to the CPU class tells litex what toolchain to use to build the litex bios
<zyp>
so if you're adding a new CPU, you'll want to set it to something suitable
<zyp>
(and also have it installed)
_whitelogger has joined #litex
<daveshah>
awygle: I haven't had much luck above 100MHz system/200MHz memory/400Mbps DDR
<daveshah>
I think that is partly due to the control CPU though, and also the magic latency numbers not being tuned right above that
<scientes>
risc-v also has MANY options
<scientes>
and you need to make sure that you get it right i your cpu doesn't have multiplication for example
<scientes>
(the compilers also don't really support the bit manip extensions yet, but that too)
<daveshah>
For the LiteX BIOS it shouldn't matter as LiteX provides a minimal standard library and compiler_rt
<daveshah>
Even a riscv64 gcc can still build 32-bit rv32i code, it just doesn't necessarily have a standard library available
<scientes>
clang can build all targets that from the same binary...
<scientes>
and if you use zig to drive clang then it also can cross-compile musl for you and compiler-rt
<daveshah>
Yes, someone should probably add the LiteX glue to use that as an option
<scientes>
(this is a well known deficiency of GCC that is difficult to fix)
<scientes>
oh wow, libgcc really does have multiplication implemented as addition in a loop
<scientes>
*addition and shifts
<daveshah>
LiteX uses LLVM compiler-rt already
<lkcl>
h
<lkcl>
hi all
<lkcl>
anyone any clues why would nextpnr-ecp5 fail routing of sys_clk2x ?
<lkcl>
does its thing, gets down to only 175 routes left to do, then wark
<daveshah>
Possibly because of edge clock promotion issues
<daveshah>
Can you run with --debug --verbose and post the last few output lines?
<lkcl>
sure... ah... that means restarting one of those 10-15 min long runs... :)
<lkcl>
argh, this time it succeeded
<lkcl>
hey i got the time down from 45ns routing latency to 22ns yippee
<lkcl>
daveshah: it appears that nextpnr-ecp5 is non-deterministic in its routing. i can *maybe* catch it "in the act" (some time)
<daveshah>
Shouldn't be
<lkcl>
what do i need to run with --debug --verbose?
<daveshah>
nextpnr
<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?
<daveshah>
not sure
<lkcl>
or am i doing "find litex -name "nextpnr"" ? :)
<daveshah>
incidentally, nextpnr should print checksums of the design at various points so you can see which step is actually being nondeterministic
<lkcl>
ahh interesting
<lkcl>
"litex/build/lattice/trellis.py"
* lkcl
modified _build_template... started...
<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
<lkcl>
good idea
<lkcl>
oh.
<lkcl>
i remember: raptor engineering found a bug in yosys. must remember to update.
<lkcl>
it was quite recent
* lkcl
hmmm yosys git logs don't show anything though
Guest44036 has quit [Ping timeout: 245 seconds]
<lkcl>
daveshah: annoying. succeeded again
<lkcl>
nonreproducible.
<daveshah>
weird, it's not something I've seen either
<lkcl>
it happened on the microwatt build as well
<daveshah>
what board? versa
<lkcl>
yes - versa ecp5 (LFE5UM)
<daveshah>
I see, I will try and see if I can trigger it at some point
<lkcl>
about the DDR3: i managed to get up to 44mhz so far
<lkcl>
24.2ns routing latency
<lkcl>
if say 40mhz DDR3 initialisation worked, we'd be operational (without needing to mess with a separate PLL)
<lkcl>
daveshah: would you be able to help with either of those? (donations from NLNet available)
<daveshah>
Yes, I'm a bit backlogged but I will see what I can do
<daveshah>
not so sure about the DDR3 init but the eclk bug is probably an easy fix once it can be reliably triggered
<lkcl>
running DDR3 off of a 2nd PLL would be the "nicer" solution, as other projects could benefit from being able to run...
<lkcl>
daveshah: ok cool
<daveshah>
_florent_ (or perhaps one of the Antmicro people) would probably be the better person for big litedram changes
<lkcl>
daveshah: yeahh florent's on holiday at the moment
<daveshah>
lkcl: this patch makes 40MHz system clock work, it should be possible to make other rates work tweaking the magic number more
<lkcl>
i am on commit 198bcbab676e2b4065e5b6a7dc8a7733bae8315a
<lkcl>
hmmm
<daveshah>
snap
<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)
<lkcl>
currently building with "read_latency = 2 + cl_sys_latency + 2 + log2_int(4//nphases),"
<lkcl>
good question
<daveshah>
asking because I've made that mistake before :)
<daveshah>
that seems like too low
<daveshah>
I would expect the correct value to be between 3 and 6
<daveshah>
+ 3 and + 6
<lkcl>
tried +4 +3 +2 will give +6 a go
m4ssi has joined #litex
<lkcl>
hmm best to try with picorv32
<lkcl>
nope - not with picorv32 @ 30mhz, not any values - 0-7.
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<awygle>
daveshah: thanks! good to know
m4ssi has quit [Remote host closed the connection]
<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
<daveshah>
sadly the cross-clock constraint support in nextpnr is probably not yet good enough for such a design to work 100% reliably
<awygle>
Yeah I'm doing a design without a cpu which has a CDC to the close-to-the-chip part of the design
<awygle>
Should handle 800Mbps/pin, or more if the i/o buffers were better
<awygle>
I was a bit worried about the multiple clock constraints, what should I know about that?
<daveshah>
nextpnr prints the max and min delay between clock domains, but it doesn't support constraining or optimising for this
<awygle>
So to be clear, multiple constraints work fine _within_ domains, but the cross clock constraints are not supported?
<awygle>
I.E. It's the CDC FIFO that would be failing?
<daveshah>
Yep
<daveshah>
If you design is conservative and follows usual CDC best practice then it will probably work
kgugala has quit [Ping timeout: 265 seconds]
kgugala_ has joined #litex
<awygle>
ok, cool. the nmigen async fifos seem pretty good, so should be relatively safe
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #litex
m4ssi has joined #litex
lf_ has quit [Ping timeout: 260 seconds]
lf has joined #litex
m4ssi has quit [Remote host closed the connection]