_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
lf_ has quit [Ping timeout: 260 seconds]
lf has joined #litex
<david-sawatzke[m> Hi, I've done something with the dram on the colorlite and it doesn't work. Is there any way to simulate Litedram stuff with migen? DRAMMemory sounds promising, but seems to be for internal tests only
proteusguy has quit [Ping timeout: 264 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
proteusguy has joined #litex
futarisIRCcloud has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
Bertl_oO is now known as Bertl_zZ
hansfbaier has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
kgugala_ has joined #litex
hansfbaier has quit [Quit: WeeChat 2.8]
hansfbaier has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
acathla has quit [Ping timeout: 256 seconds]
hansfbaier has quit [Read error: Connection reset by peer]
Bertl_zZ is now known as Bertl
<_florent_> david-sawatzke[m: Hi, it's possible to simulate LiteDRAM directly with litex_sim --with-sdram
<_florent_> you can customize the SDRAM with: --sdram-module, --sdram-data-width
<_florent_> and it's also possible to preinitialize the contents from a file with --sdram-init
<_florent_> It's using a SDRAM Model interfacing at the DFI level
<_florent_> somlo: the SDCard is now also working with Linux-on-LiteX-Vexriscv, that was the clock-frequency that was missing in the .dts as you suggested by mail, thanks!
<_florent_> somlo: I forgot to add it to VexRiscv-SMP when replacing VexRiscv with VexRiscv-SMP in litex_json2dts.py
<somlo> _florent_: that's great news!
<somlo> _florent_: now what's left is to figure out why multi-block transfers are having such a hard time
<somlo> I may end up having to learn something new (debug running gateware) after all... Been successfully avoiding it all this time, but the writing is on the proverbial wall :D
<_florent_> somlo: yes that's great. The fact that we are now using a common linux branch is a time saver for finding these subtle things :)
<somlo> speaking of, what's the purpose of the "loop" and "offset" registers in the LiteX DMA modules?
<somlo> seems "loop" resets the FSM while it's running, but I'm probably misunderstanding that - anywhere I can go read about it?
<_florent_> somlo: also, what do you think about adding Rocket support to litex_json2dts? This would simplify Linux-on-LiteX-Rocket and would also mutualize the efforts on the .dts front
<somlo> _florent_: that's next on my agenda after getting to the bottom of the linux-vs-litesdcard issue
<_florent_> somlo: as we already discussed by mail, LiteScope can also be very powerful to develop/debug Linux drivers! You should really try it :)
<somlo> _florent_: I'll drop everything and do that, starting today (modulo how much crap $DAYJOB will throw my way) :D
<_florent_> ,somlo: for Litescope, you can learn/try it directly in simulation by following: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC
<_florent_> using it on hardware after is only matter of changing the bridge between the computer and FPGA: https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC
<somlo> thanks, I promise I won't touch anything else litex/linux related before I force myself to go through each step of those two documents :)
<somlo> but one more (mostly unrelated) question before that: there's that one-bit "loop" CSR in both WishboneDMA[Writer,Reader] -- https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/dma.py#L111 and https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/dma.py#L196
<somlo> it seems if one writes to it during the DMA transfer, it starts again from the beginning -- does that make sense, am I right, and if not, what's going on :)
<somlo> seems WishboneDMAReader also exposes the current offset in a read-only way: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/dma.py#L83 (sort-of like a progress bar type thing :)
<somlo> am I even in the proverbial ballpark with my understanding of how this is supposed to work ?
<_florent_> somlo: in LiteX's DMA: loop CSRStorage allow you to create a continous DMA that restart automatically when done
<_florent_> somlo: the offset can be used to monitor the DMA status (to know how much data have been already transfered)
<_florent_> ah sorry, haven't seen your previous messages, so you are right yes
<_florent_> no sure you'll have a need for the loop mode, but the offset can be useful in case you have troubles with a DMA that does not end
<somlo> _florent_: thanks! any clue on why only the DMAReader exposes `offset` as a read-only CSR (and not DMAWriter as well)?
<_florent_> somlo: I probably only had a need for it on the DMAReader, but we could add it to the Writer too
<somlo> _florent_: ok, I don't know that we need it (yet), was just curious if there's some underlying structural reason why it could only work on *Writer :)
mntmn has quit [Quit: WeeChat 2.8]
chgavilana has joined #litex
chgavilana98 has joined #litex
<chgavilana> hi: I am trying to use an hdmi output with litevideo. Can anyone who has experience with litevideo give me the reference of the monitor you used?
chgavilana98 has quit [Client Quit]
chgavilana01 has joined #litex
<cr1901_modern> _florent_: I had a bad day computer-wise yesterday. I'll test your PR changes soon.
<somlo> anyone in possession of a nexys-a7 board able to (or willing to try) building linux-on-litex-rocket bitstream using the nexys4ddr instructions? (https://github.com/litex-hub/linux-on-litex-rocket)
<somlo> I have a report that programming the bitstream on a nexys-a7 results in only the led-chaser but no console output, and I only have the "classic" nexys4ddr, so I'm blind to any small-but-relevant differences between it and the nexys-a7
<somlo> even just pushing the pre-built nexys4ddr bitstream (https://github.com/litex-hub/linux-on-litex-rocket/files/5711713/bitstream.tar.gz) to your a7 board and letting me know what happened would help
<daveshah> Hmm I think I might have one somewhere
<daveshah> somlo: I don't have a tftp server but it passes memtest and starts trying to talk to the network at least
<daveshah> *tftp server running
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<daveshah> found a microSD card, let's try that...
<daveshah> yep boots linux fine
<daveshah> ah I spoke too soon
<daveshah> it's hanging trying to talk to the microsd by the looks of things
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<daveshah> it doesn't respond to input beyond that point
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 240 seconds]
Bertl is now known as Bertl_oO
kgugala has joined #litex
<somlo> daveshah: thanks!
<somlo> that's more than what I got in the bug report (led-chaser, no other console output)
<daveshah> sorry, I've just realised that I'm an idiot and I actually have an old nexys4
kgugala_ has quit [Ping timeout: 246 seconds]
<daveshah> I thought it was an A7 for some reason but it's actually a nexys4ddr
<somlo> works fine on my old nexys4 (and iirc. it passed timing in vivado)
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
Dolu has joined #litex
<somlo> daveshah: depending on how fresh your (litex-hub/linux litex-rebase branch) kernel is, the hanging microsd driver may or may not be reason for concern... :)
<somlo> but thanks for checking, sorry to have wasted your time on the old board
<daveshah> Don't worry, it was my own confusion to blame!
<Dolu> fpu
<Dolu> sorear : Got some FPU design which pass add/mul/fma/div/sqrt
<Dolu> So basicaly, the design choices are : To not implement subnormals, having 1 mul pipeline + 1 add pipeline, which are chained when FMA, both div and sqrt use a LUT based initial aproximation and get closer via 2-3 newton iterations.
<Dolu> Currently trying to have a centralised register file between multiple CPU, just not sure how well this will scale for floating point store, as it has to do the roundtripe between CPU instruction decode => FPU register file => CPU D$
<_florent_> somlo: I thought the nexys4ddr and nexysa7 where exactly the same but it seems not. If the led chaser is on, the clock is probably good and the boards is not in reset
<_florent_> the UART pins are the same, so the CPU should start printing things on the UART
<_florent_> Unfortunately I also only have a nexys4ddr
<somlo> _florent_: that's what I remember from reading about the nexys a7 too, but no actual first hand experience...
acathla has joined #litex
<somlo> _florent_, daveshah: apparently after some tinkering with jumpers, my nexys-a7 user managed to get some console output when booting their bitstream, so we're back on assuming the a7 is backward compatible :) Thanks again for your help!
<somlo> * back *to* assuming... Apparently I need more coffee...
acathla has quit [Changing host]
acathla has joined #litex
<cr1901_modern> _florent_: Your changes work fine
<cr1901_modern> re: litex_term
<zyp> _florent_, do you know if the vexriscv interrupt controller is documented anywhere?
<zyp> I'm looking at implementing support for it in my own lib, and I think I understand how it works just based on https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/irq.h, but it'd still be nice to have a reference
lambda has quit [Ping timeout: 260 seconds]
lambda has joined #litex