_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://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
nthiel has joined #litex
nthiel has quit [Ping timeout: 272 seconds]
tweakoz has joined #litex
<tweakoz> Is it possible to easily decouple sys_clk_freq from cpu frequency using an MMCM or PLL ? (If I change sys_clk_freq to an integer multiple of the driving oscillator I can get the SOC to build and even boot - but I am pretty sure it is just an illusion as I have to multiply uart connect speed on litex_term times the inverse of the change)
<tweakoz> or maybe it is easier to just drive the whole design from a MMCM or PLL ?
<tweakoz> I am not sure how to drive sys_clk from PLL or MMCM (if there is an vendor abstract method that would be awesome too).
<tweakoz> Also - I have this board brought up (minimally - booting bios and communicating via litex_term) : https://www.micro-nova.com/mercury-2 - I can make a pull request when it is a little further along..
<tpb> Title: Mercury 2 - Xilinx Artix-7 FPGA development board — MicroNova (at www.micro-nova.com)
<tweakoz> TLDR of the MMCM/PLL questions - the mercury-2 has a 50mhz oscillator connected to theFPGA - I want to run the litex cpu at some arbitrary speed that is not 50Mhz
nthiel has joined #litex
nthiel has quit [Ping timeout: 272 seconds]
Degi_ has joined #litex
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
FabM has joined #litex
nthiel has joined #litex
nthiel has quit [Remote host closed the connection]
nthiel has joined #litex
nthiel has quit [Client Quit]
TMM__ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<Melkhior> for an Artix-7 example
<tpb> <https://x0.no/4uy0q> (at github.com)
<Melkhior> then there is a further 2 PLL to have completely unrelated clocks for the memory idelay and the optional framebuffer
ewen has joined #litex
Melkhior has quit [Remote host closed the connection]
Melkhior has joined #litex
ewen has quit [Ping timeout: 264 seconds]
<_florent_> Thanks zyp for the various PRq, I think Greg already merged your LiteHyperbus PR, the LiteSPI PRs also looks good. I'll just do a test in a couple of hours on Artix7/ice40 boards and will merge if also working (will look at it if not).
ewen has joined #litex
<_florent_> jevinskie[m]: Your approach for capturing your synchronous serial stream seems fine, you could indeed reuse LiteEthUDPStreamer for that.
<_florent_> You just need to provide the destination IP address, UDP port and then pass your stream of data (valid/ready/data), it will stream it over UDP, no need to have a CPU to control it
<_florent_> That's indeed what is used in the scope project, there it's connected to the DMA (generating a stream from DRAM data)
<_florent_> You could work on the two separate parts of your systems: 1) Capture of your synchronous stream (with a 1:8 Deserializer as you suggest and could also look at the HAD1511 peripherals from the scope project for this) and 2) The UDP Streaming (with a counter in a first time). Once each part is validated, connecting the two should be easy
<tweakoz> @Melkhior : Thank you, that did the trick.
<tweakoz> Hmm, there is hyperram on the mercury 2 as well. I should also try out litehyperbus
<tweakoz> although it looks like I would have to port from ECP5 to Xilinx 7
<zyp> depends how fast you want it
<tweakoz> I don't need it quite yet - just curious.
<_florent_> tweakoz: https://github.com/litex-hub/litehyperbus/blob/master/litehyperbus/core/hyperbus.py is generic (but low speed) so should work on Artix7
<tpb> <https://x0.no/4uy0z> (at github.com)
<tpb> <https://x0.no/4uy10> (at github.com)
<zyp> that core is probably also gonna need the latency to be made adjustable eventually
<_florent_> zyp: Indeed, with the current setting, IIRC it should work with all HyperRAM, but configuring latency could increase perf
<zyp> no, the hyperram I've got has a default latency of 7
<zyp> hence why I had to make it configurable for the X2 core
<_florent_> ah ok
<zyp> the W956A8MBYA5I does max 200 MHz, and needs 7 cycles to achieve that, which it also defaults to
<_florent_> zyp: If I add it to the generic core, would you mind testing on your hardware?
<zyp> sure, I can do that
<_florent_> zyp: BTW I had first quick look at #942, this looks good, thanks! (will try to review it more carefully soon).
<zyp> nice
<zyp> I don't think it'll break any existing functionality, and should be a good starting point for moving out the libraries
<_florent_> Indeed, I like the direction it takes, thanks.
<tweakoz> I misread the manual, the mercury2 is not hyperram, just async sram - 18-20 address lines, 8 data lines, and a write enable and chip enable and thats it.
<tweakoz> so to pull off async-sram would cloning-mutating Wishbone.SRAM be reasonable ? (mutating to use external IO instead of block ram) - looks like I would also have to reproduce what is done in SoC.add_ram (pointing to my wishbone AsyncSRAM class)
<zyp> I would expect there to be an existing core you could make use of somewhere
<tpb> <https://x0.no/4uy16> (at github.com)
RaYmAn has joined #litex
ewen has quit [Quit: leaving]
lkcl_ has quit [Ping timeout: 272 seconds]
<tweakoz> the betrusted-io did not seem to fit - so I did start with wishbone.SRAM and soc.add_ram() - and modified it. seems to work
<tweakoz> litex> mem_list
<tweakoz> VEXRISCV_DEBUG 0xf00f0000 0x100
<tweakoz> SRAM 0x10000000 0x20000
<tweakoz> Available memory regions:
<tweakoz> ROM 0x00000000 0x8000
<tweakoz> ISSIRAM 0x20000000 0x80000
<tweakoz> CSR 0xf0000000 0x10000
<tweakoz> litex> mem_test 0x20000000 0x80000
<tweakoz> Memtest at 0x20000000 (512KiB)...
<tweakoz> Write: 0x20000000-0x20080000 512KiB
<tweakoz> Read: 0x20000000-0x20080000 512KiB
<tweakoz> Memtest OK
<tweakoz> or at least the mem_test passes - not sure how thorough mem_test is
acathla has quit [Quit: [Guru Meditation]]
<tweakoz> 640K should be enough for anyone.
acathla has joined #litex
tweakoz has quit [Ping timeout: 272 seconds]
<Melkhior> Hello,
<Melkhior> Litex tells me:
<Melkhior> I'm trying to write through the Wishbone in a Litex SoC with no CPU (bridging from the bus of a host system) to the CSR of a Litex LedChaser.
<Melkhior> I've instantiated a wishbone.Interface and added it as master on the bus with:
<Melkhior> self.bus.add_master(name="SBusBridgeToWishbone", master=self.sbus_slave.wishbone)
<Melkhior> INFO:SoCCSRHandler:leds CSR allocated at Location 0.
<Melkhior> (...)
<Melkhior> INFO:SoC:32-bit wishbone Bus, 4.0GiB Address Space.
<Melkhior> (...)
<Melkhior> csr : Origin: 0x00040000, Size: 0x00010000, Mode: RW, Cached: False Linker: False
<Melkhior> So I'm trying to write my data to 0x00040000 (first location in the csr area) on the wishbone bus with:
<Melkhior> wb_fsm.act("Write",
<Melkhior> self.wishbone.adr.eq(csr_data_w_addr),
<Melkhior> self.wishbone.dat_w.eq(csr_data_w_data),
<Melkhior> self.wishbone.we.eq(1),
<Melkhior> self.wishbone.cyc.eq(1),
<Melkhior> self.wishbone.stb.eq(1),
<Melkhior> If(self.wishbone.ack == 1,
<Melkhior> self.wishbone.we.eq(0),
<Melkhior> self.wishbone.cyc.eq(0),
<Melkhior> self.wishbone.stb.eq(0),
<Melkhior> NextState("Idle")
<Melkhior> )
<Melkhior> )
<Melkhior> Some added Leds tell me this state is reached and the ack received, but the chaser keeps chasing instead of goingo to _CONTROL_MODE, so I guess the write didn't complete as I want it to.
<Melkhior> Any suggestion welcome.
C-Man has quit [Read error: Connection reset by peer]
<tpb> <https://x0.no/4uy2f> (at github.com)
sajattack[m] has quit [Ping timeout: 244 seconds]
Leon[m] has quit [Ping timeout: 244 seconds]
shoragan[m] has quit [Ping timeout: 244 seconds]
jevinskie[m] has quit [Read error: Connection reset by peer]
david-sawatzke[m has quit [Read error: Connection reset by peer]
dcallagh has quit [Read error: Connection reset by peer]
jryans has quit [Read error: Connection reset by peer]
jryans has joined #litex
shoragan[m] has joined #litex
dcallagh has joined #litex
Leon[m] has joined #litex
jevinskie[m] has joined #litex
david-sawatzke[m has joined #litex
sajattack[m] has joined #litex
gregd has quit [Remote host closed the connection]
<_florent_> Melkhior: The Wishbone bus is word addressed (something we should eventually change...) so the issue is probably here: self.wishbone.adr.eq(csr_data_w_addr)
<_florent_> it should be self.wishbone.adr.eq(csr_data_w_addr/4) (or self.wishbone.adr.eq(csr_data_w_addr[2:])
<Melkhior> @_florent_ ok it figures, this was definitely a byte address
<Melkhior> thanks
<Melkhior> will try that ASAP
<Melkhior> I feel the other way around (Wishbone master sending request that I will have to translate to SBus DMA somehow, and figuring out the SW side) is going to be harder
gruetze_ is now known as gruetzkopf
<Melkhior> But the endgame is tempting: potentially the first OHCI USB Host on a SBus-based SPARCstation :-)
FabM has quit [Remote host closed the connection]
<Melkhior> _florent_: another Wishbone while I'm at it; any 'easy' way to do CDC ? I see some 'obvious' stuff for AXI-list & Stream, but not for Wishbone
<Melkhior> I will likely need to run Wishbone in its own domain rather than synchronous with the SBUs (which can be anywhere from 16.67 to 25 MHz)
<Melkhior> although that's probably for later when i can read & write csr...
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<_florent_> Melkhior: We don't have our own Wishbone CDC yet but you can find some in verilog only and instantiate it
<Melkhior> _florent_: ok thx
<Melkhior> Also I might need FIFO to buffer between SBus and Wishbone, async FIFO could also work I suppose...
<Melkhior> I'm not quite there yet anyway :-)
<Melkhior> Bus bridging between different era doesn't look easy...
<Melkhior> (SBus is virtually addressed on the Master side... I'm guessing Wishbone isn't)
<_florent_> I could help on this when you'll need it in your system
<Melkhior> ok thx a lot
<Melkhior> :-)
<cr1901> _florent_: Just a heads up, I've started porting jcore to LiteX. It's going to be a proof-of-concept level port for now (no cache, single variant), due to the high latency in getting feedback from the jcore devs. Will you still merge it if I give a PR?
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<cr1901> mithro: How do you use pythondata-auto to create a cpu module?
<mithro> cr1901: You just add configs
<tpb> <https://x0.no/4uy3o> (at github.com)
<mithro> But things are currently broken due to https://github.com/litex-hub/pythondata-auto/issues/8
<tpb> <https://x0.no/4uy3p> (at github.com)
<cr1901> How should j-core be added then to that repo for the time being?
<cr1901> (Basically I'm asking "Is it okay if I point to my own copies of j-core and pythondata-cpu-j-core from the litex repo for now"?)
<mithro> Sure!
<cr1901> Once we go past minimum viable product we can discuss pointing to the j-core repo that belongs to GH user j-core, and adding pythondata-cpu-j-core to the litex-hub user
<mithro> Yeap! SGTM
<cr1901> mithro: How are you supposed to initialize a pythondata-cpu-* repo from the first commit using that script?
<cr1901> I created this empty repo: https://github.com/cr1901/pythondata-cpu-j-core
<cr1901> But the script bombs with "Your configuration specifies to merge with the ref 'refs/heads/master'
<cr1901> from the remote, but no such ref was fetched."
<cr1901> Well, yea, because I'm trying to create the repo to push
<mithro> I'll create the repo
<cr1901> mithro: Thanks (in addition, I also just figured it out: comment out the "download()" function :P
<mithro> cr1901: I'm guessing it would be probably be pythondata-cpu-jcore instead?
<cr1901> They have the hyphen on the website, but I seriously doubt it'll cause problems to remove it for the sake of keeping the package namespace neater
<cr1901> (and if it does cause problems, well... we'll cross that bridge later)
<cr1901> I built a bare-metal SuperH toolchain w/ the j-core insns yesterday, so that's taken care of.
<mithro> cr1901: I gave you access to the repo
<cr1901> mithro: Tyvm
<cr1901> mithro: I'm putting this minddump here as a reminder to myself. To get pythondata-auto to work for me locally, I had to do a few things:
<mithro> okay SGTM
<cr1901> 1. While there's an empty repo, the download() part of the script needs to be commented out, because it'll fail with the error I mentioned above re: refs/master
<cr1901> 2. I removed everything except the jcore section from modules.ini, because I don't need it locally :D
<cr1901> 3. I had to set GIT_MODE=https, even with commit access to pythondata-cpu-jcore, because I otherwise get "denied publickey" (I think the ssh url is "ssh://git@github.com", the script hardcodes "{MODE}://github.com")
<cr1901> I manually added a ssh to the repo that the script created
<cr1901> 4. Optionally, I will probably run "setup.py develop" in pythondata-cpu-jcore that pythondata-auto created
<cr1901> This is so I can use the script to quickly update the VHDL repo, since I anticipate a change or two will be necessary
<cr1901> /minddump