<mithro>
@_florent_: The SymbiFlow toolchain has Zynq support -- we should get that working in a similar manner to the arty version
_whitelogger has joined #litex
jeanthom has joined #litex
<pepijndevos>
How do I exit litex_term?
<jeanthom>
ctrl+c ?
<pepijndevos>
nope
<daveshah>
At one point it was double ctrl+c
<pepijndevos>
lol okay will try, I just killed it now
<pepijndevos>
yeah works
jeanthom has quit [Ping timeout: 240 seconds]
tcal has quit [Quit: Connection closed for inactivity]
<pepijndevos>
How can I see what variants are available for a cpu?
<zyp>
not sure there's a way to list it apart from looking in the source
<zyp>
which cpu?
<pepijndevos>
yea, looking at the source now
<pepijndevos>
was mainly looking at vexrisc and picorv32, to match them with the correct Rust tripple
<_florent_>
mithro: we could had a Zynq target example with Symbiflow, but supporting Symbiflow still requires some workarounds, so that would be good also working on https://github.com/enjoy-digital/litex/issues/554 before adding Symbiflow support to other targets
<_florent_>
pepijndevos: to exit lxterm, it's ctrl+c two times quickly, this was added to be able to do ctrl+c in the linux shell when linux is running on the FPGA
<pepijndevos>
ewps, when I change the CPU type on ulx3s.py to picorv I get interrupt errors when compiling the bios
<pepijndevos>
undefined reference to `_irq_mask'
<somlo>
if I read the rest of the DMA patch (d38048baa), if the cpu exposes a dma_bus, then the dma masters are connected to the cpu dma slave on a dedicated (separate from the "main" mmio wishbone bus) interconnect
<somlo>
which means that any and all DMA accesses are routed through the cpu's dma_bus slave, either to DRAM, or back out the mmio wishbone "main" bus
<somlo>
which then means that `size` should be (at least) 0x10000_0000 (to cover the whole 4GB physical address space we currently support)
<somlo>
(e.g., rocket has DRAM *starting* at 0x8000_0000)
<pepijndevos>
Can LiteX on ULX3S actually run with picorv32, or is the bios thingy not compatible?
<_florent_>
pepijndevos: we should indeed improve --help on the targets to provide more useful information, i wanted to revisit things a bit, but haven't been able to work on this yet
<_florent_>
pepijndevos: but i think if you give a wrong variant, it should give you an error message and list the supported ones
<pepijndevos>
It does actually
<somlo>
_florent_ but if I bump size up beyond 0x8000_0000, vivado craps fails to synthesize with "part-select [29:30] does not match declaration" when trying to access dma_bus_interconnect_shared_adr[29:30]
<somlo>
(unsurprisingly, since it's declared as a "wire [29:0]" somewhere earlier in the generated verilog.... Hmmm, maybe I need to find the corresponding Signal() statement in the migen sources :)
<_florent_>
pepijndevos: you should be able to run picorv32 on the ULX3S, if not it's broken, could you open a PR?
<pepijndevos>
_florent_, where does this bios stuff live?
<somlo>
bumped it up to 32, see if 1. vivado survives the build run and 2. it actually works once built :D
<somlo>
_florent_: looks like vivado won't crap out; testing the bitstream will have to wait though, until I get back from doing chauffeur duty for the family, in a few hours :)
<_florent_>
key2, jeanthom: i saw you were porting LiteDRAM to nMigen in https://github.com/jeanthom/gram, but wouldn't it be better to help us eventually make LiteX work with nMigen in compat mode in a first time if you really want to reuse the LiteDRAM codebase with nMigen? (or generate a standalone controller to verilog which is already possible?)
<_florent_>
somlo: sorry, i also have the family around and will have difficulties looking at that closely now :), would you mind eventually creating an issue to follow your changes/progress and be able to answer there?
<pepijndevos>
My LiteX core defines rom, sram, csr, and main_ram, what is each typcially used for?
<somlo>
_florent_: sure thing; I'll do that later today; for now, with the modified wishbone interface adr_width and dma_bus region I got it to copy boot.bin to 0x80000000 successfully. It hangs at "liftoff", so there's still some lingering badness, but I think I'm on to something :)
lambda has quit [Ping timeout: 260 seconds]
lambda has joined #litex
<pepijndevos>
Why does this version have 32 bit values, while mine has 4 8 bit values?
<pepijndevos>
Why is my litex stuck at 0% uploading?
<pepijndevos>
uhhhh. maybe because my binary is 1GB???
<daveshah>
sounds like a linker script gone wrong
<daveshah>
not seen this with litex before though
<daveshah>
usually it is because it tried to put both ROM and RAM in the binary, and they are at base addresses 1GB apart or whatever
<pepijndevos>
that would be a nice oops
<zyp>
yeah, that's not an uncommon mistake
Finde has quit [Quit: WeeChat 2.3]
Finde has joined #litex
<_florent_>
pepijndevos: it's possible to configure the data-width of the CSR bus (that is used for the registers), for historical we are still using 8-bit as default (thus the 4 8 bit value you see) and the icebreaker design you are linking is probably using --csr-data-width=32
<pepijndevos>
_florent_, is there a good reason to not use that?
<_florent_>
somlo: nice, that's already better :) now just need to understand why the data is not valid...
<_florent_>
pepijndevos: until a few months, some features were still requiring csr-data-with=8, but it's no longer the case now, and we'll switch the default value to 32 soon
<_florent_>
pepijndevos: so you can use 32 and it will provide better performance. (csr-data-width=8 was initially used to reduce resource usage/improve timing on the CSR bus, but 32-bit seems to work fine even in iCE40 and relatively large designs, so there are no real reason to continue using it).
kgugala has joined #litex
<pepijndevos>
okay thanks, I'll try that later. Probably saves a bunch of bit magic
kgugala__ has quit [Ping timeout: 264 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<somlo>
_florent_: I'll need another hour or so of peace and quiet to dig into it, then I'll post an RFC PR with what I have so far and we can take it from there over the next few days
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala_ has quit [Quit: -a- Connection Timed Out]