<_florent_>
by default, LiteX automatically collect/assign the CSR base address, this allows you to force/reserve them
<swetland>
thanks! what's the **{ business about? overriding a csr_map in the superclass?
<swetland>
I've now got qemu, ULX3S and IceSugarPro in agreement about peripheral bases and interrupt numbers, which is very nice
<swetland>
I know mithro doesn't have a ton of interest in qemu, but if others do, I'm assembling some patches to provide compatible peripherals in this repo: https://github.com/swetland/qemu/commits/workshop
<xobs[m]>
I tend to do all of my sim work in Renode, just because it's a lot easier to implement peripherals, and it works cross-platform. It's really nice to see more examples of how to add peripherals to qemu, though!
shoragan has quit [Excess Flood]
shoragan has joined #litex
shoragan[m] has quit [*.net *.split]
Melkhior has quit [*.net *.split]
gatecat has quit [*.net *.split]
joseng has quit [*.net *.split]
gatecat has joined #litex
shoragan[m] has joined #litex
Melkhior has joined #litex
<swetland>
xobs: I tried renode but most of the litex peripherals did not operate like they did in litex on the fpga
<swetland>
at that point, already invested in qemu, I just kept going there. I do want to revisit renode at some point, it seems very slick.
<swetland>
qemu suffers from the same problems the linux kernel does: enormous codebase, fast moving, documentation on development is rather thin, lots of examples but they use different APIs, styles, etc and it's sometimes hard to figure out what's the modern vs old fashioned way of doing something.
<tpb>
Title: Carl's Arty CI for Tim - Pictures and Links - Google Docs (at docs.google.com)
<mithro>
swetland: I think I mentioned that the lack of config file support in QEMU was what ended up stopping my QEMU work
<mithro>
swetland: I did investigate the idea of using devicetree to configure QEMU and others had proposed that idea too
<mithro>
swetland: Did you generate a Renode configuration for your LiteX gateware?
<swetland>
mithro: I did. the framebuffer crashed. turns out the registers are the multiple 8bit slices (some old litex model), and this impacts other peripherals as well
<swetland>
my takeaway was that a number of the peripherals would need work before I could get anything working
<swetland>
I will again suggest that device tree is maybe not the optimal answer and that while reinventing the wheel is not always great, not every existing solution is a good solution just because it exists.
<swetland>
though as far as device tree goes, the point would be to indicate where the peripherals are right? instead of pushing DT *into* qemu why not have qemu generate DT for the machine it's emulating (which many machines in qemu already do) and have the litex build/bios generate DT, then in both cases whatever you're running would look at the DT for where everything is
<tpb>
Title: LiteX Soft-CPU, FPGA and Firmware Support - Google Tabellen (at docs.google.com)
<swetland>
nice
<mithro>
swetland: agreed that it seems like the most logical solution would be for QEMU to have a config file format and then generate the device tree for the machine it was emulating.
<swetland>
though looking at this it drives home the fact that I think litex really needs a vehicle to ensure registers/fields are stable even if the base addresses and irq maps may vary
<mithro>
swetland: do you have an Google account so you could update the QEMU model?
<mithro>
S/model/spreadsheet column/
<swetland>
because I assume you don't want to start breaking the upstream linux, zephyr, etc drivers needless as qemu evolves
<swetland>
I do. I haven't looked into how involved getting stuff upstream into qemu is yet
<mithro>
BTW qmeu is so entrenched with Linux kernel developers at the moment that even if Renode is a better solution, QEMU support could still be useful
<swetland>
I haven't looked at building renode from source, etc yet, so not sure how involved working on it is. qemu I just need a c compiler ^^
<tpb>
Title: Antmicro · Rust peripheral support in Renode (at antmicro.com)
<mithro>
swetland: Renode can even co-similate with a peripheral being emulated by verilog code in Renode
<swetland>
I have not had enough time to work with rust. I like a lot of the ideas. in practice it seems a bit fiddly. not a fan of the hyper-opinionated build system and package system
<mithro>
At some point, I would like to enable LiteX to export just a peripheral into verilog which is then embedded into Renode via verilator all automagically
<tpb>
Title: Antmicro · Boosting Machine Learning with tailored accelerators: Custom Function Units in Renode (at antmicro.com)
<mithro>
Sometimes it is really hard to stop talking about Renode as there is just *so* many cool features it has
<swetland>
it certainly looks promising
<mithro>
swetland: oh, the functionality that Renode uses to bridge to verilator is the same Etherbone stuff that LiteX uses which allows you to also bridge between emulated CPUs and peripherals running on real hardware
<mithro>
A lot of this is demonstrated in the Fomu workshop
<mithro>
Being able to poke/peek and single step the soft CPU via USB is pretty magical
<mithro>
Anyway, lunch time for me
<swetland>
later!
<jevinskie[m]>
Does anybody have advice about adding a new PHY (max10 using altera gpio_lite primitives) to litedram? Are there specific test cases I can use? I’ve never done ddr3 bringup before but I figure building on litedram would be my best bet.
<jevinskie[m]>
The DECA would be so wonderful with native litedram support! :)
<swetland>
wow the video framebuffer has some serious impact on memory bandwidth ^^
<swetland>
I get 20.4MB/s memset with video dma off, 3.1MB/s memset with it on
<swetland>
16bit fb gets me 7.7MB/s write bandwidth. I think I may add rgb233 or idx8 formats to get that up to 15MB/s or so
<_florent_>
jevinskie[m]: I would recommend studying the S7DDRPHY and understand how serialization/deserialization/output delays/input delays/bitslip work. Then studying the Altera primitives and compare them to 7-Series (serialization ratios, latencies, etc..). This will allow you to create the skeleton of the PHY. Then you can use a model from Micron and do initial simulations (but not sure Verilator will work, you'll maybe have to use a
<_florent_>
non open source simulator or the one provided by Quartus). Once things start to work correctly in simulation, start testing on hardware and debug :)
<_florent_>
jevinskie[m]: I'm interested to help if you have troubles (and also have the DECA)
<jevinskie[m]>
Thanks for the pointers! Yeah I’ve used the micron models before with modelsim. I’ll take a look at the 7 series. For the max10 I’ll definitely have to do the bitslip in logic
<mithro>
swetland: I would double check what you expect the values to be and see if they match what you are seeing -- they should hopefully match within 20% to rough calculations.
<mithro>
swetland: If you need a Fomu so you can do the Fomu workshop, I would be happy to send you one
<mithro>
> G. Integration with LiteX - We wrap the top PiMulator System Verilog module in LiteX [14] and interface it with the LiteDRAM memory controller and VexRiscV processor system by defining a target script.