| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi_ <[email protected]> has joined #litex | 00:13 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 00:14 | |
| *** Degi_ is now known as Degi | 00:14 | |
| *** Emantor <[email protected]> has quit IRC (Quit: ZNC - http://znc.in) | 01:20 | |
| *** Emantor <[email protected]> has joined #litex | 01:20 | |
| swetland | I think I've missed _florent_ but maybe somebody else knows -- what's the mechanism to fix the litex CSR base addresses? | 04:36 |
|---|---|---|
| tnt | swetland: csr_map https://github.com/litex-hub/zephyr-on-litex-vexriscv/blob/master/soc_zephyr.py#L47 | 05:30 |
| tnt | (ok, this example is more complex than needed because they use a class generator for some reason but couldn't google for an online example ...) | 05:31 |
| tnt | you basicaly just put a csr_map = { } variable in your SocBase that contains the base address for the modules | 05:31 |
| swetland | yay! I am really lousy at deciphering all the piles of python. thanks | 05:35 |
| swetland | it probably says something (worrisome) about me that I find qemu's elaborate C object system less puzzling ^^ | 05:35 |
| swetland | I am saved from having to inflict devicetree or some other dynamic hw enumeration thing on a bunch of beginner/hobbyist os hackers ^^ | 05:37 |
| swetland | also I finally found a linux diagram tool that's not hateful. what a great day: https://twitter.com/dnaltews/status/1522578533301645313 | 05:38 |
| swetland | huh. I can't make it work, with or without the **soc_class.csr_map, **{ business | 05:54 |
| swetland | it ignores my map and just puts the csrs whereever it wants | 05:55 |
| swetland | oh wait, operator error | 05:55 |
| swetland | (stuck it inside the __init__ method | 05:57 |
| _florent_ | swetland: you can do it like this at the top: | 06:57 |
| _florent_ | https://github.com/litex-hub/linux-on-litex-vexriscv/commit/dec4cb399db6cf3e1f53433f6969946dd224f419 | 06:57 |
| _florent_ | or directly in your code like this: | 06:57 |
| _florent_ | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/naxriscv/core.py#L280-L281 | 06:57 |
| _florent_ | by default, LiteX automatically collect/assign the CSR base address, this allows you to force/reserve them | 06:58 |
| swetland | thanks! what's the **{ business about? overriding a csr_map in the superclass? | 06:58 |
| swetland | I've now got qemu, ULX3S and IceSugarPro in agreement about peripheral bases and interrupt numbers, which is very nice | 06:59 |
| 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 | 07:08 |
| 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! | 12:54 |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Excess Flood) | 13:14 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 13:14 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (*.net *.split) | 14:56 | |
| *** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has quit IRC (*.net *.split) | 14:56 | |
| *** gatecat <[email protected]> has quit IRC (*.net *.split) | 14:57 | |
| *** joseng <[email protected]> has quit IRC (*.net *.split) | 14:57 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 14:57 | |
| *** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has joined #litex | 14:57 | |
| *** gatecat <[email protected]> has joined #litex | 14:57 | |
| swetland | xobs: I tried renode but most of the litex peripherals did not operate like they did in litex on the fpga | 15:28 |
| 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. | 15:29 |
| 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. | 15:30 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 16:35 | |
| *** TMM_ <[email protected]> has joined #litex | 16:36 | |
| swetland | okay this patch stack is tidied up, includes the litex-timer, and uart and timer are both happily working in irq mode now: https://github.com/swetland/qemu/commits/litex | 17:43 |
| mithro | _florent_: FYI - https://docs.google.com/document/d/1jyodwCNK-9mokDAe6X1AMhEDPW-qPeqPTHI-z9aUGVg/edit# | 17:54 |
| tpb | Title: Carl's Arty CI for Tim - Pictures and Links - Google Docs (at docs.google.com) | 17:54 |
| mithro | swetland: I think I mentioned that the lack of config file support in QEMU was what ended up stopping my QEMU work | 17:55 |
| mithro | swetland: I did investigate the idea of using devicetree to configure QEMU and others had proposed that idea too | 17:55 |
| mithro | swetland: Did you generate a Renode configuration for your LiteX gateware? | 18:32 |
| 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 | 18:41 |
| swetland | my takeaway was that a number of the peripherals would need work before I could get anything working | 18:41 |
| swetland | see the conversation on this issue: https://github.com/renode/renode/issues/324 | 18:42 |
| 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. | 18:45 |
| 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 | 18:46 |
| mithro | swetland: you might find some useful info at https://docs.google.com/spreadsheets/d/1XTHfdYXuvwoYdPXm4M6qDA0D2fZCPy220-9q6qZpTw4/edit?usp=drivesdk | 18:47 |
| tpb | Title: LiteX Soft-CPU, FPGA and Firmware Support - Google Tabellen (at docs.google.com) | 18:47 |
| swetland | nice | 18:47 |
| 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. | 18:48 |
| 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 | 18:48 |
| mithro | swetland: do you have an Google account so you could update the QEMU model? | 18:49 |
| mithro | S/model/spreadsheet column/ | 18:49 |
| swetland | because I assume you don't want to start breaking the upstream linux, zephyr, etc drivers needless as qemu evolves | 18:49 |
| swetland | I do. I haven't looked into how involved getting stuff upstream into qemu is yet | 18:50 |
| 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 | 18:50 |
| 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 ^^ | 18:52 |
| mithro | swetland: I had a script here https://github.com/timvideos/litex-buildenv/blob/master/scripts/build-qemu.sh that generated a QEMU command line with a set of peripherals found in LiteX gateware | 18:53 |
| mithro | swetland: BTW you can write peripherals for Renode without needing to recompile all of Renode - see xobs precursor stuff for example | 18:54 |
| mithro | swetland: I would not say the QEMU command line generation script was better the "terrible, horrible, hack" either :-) | 18:55 |
| swetland | that's nice. does that include updating/replacing the existing ones? there's definitely a lot of interesting stuff in renode | 18:55 |
| mithro | swetland: you can subclass / extend an existing one | 18:55 |
| swetland | yeah I think a solid argument could be made that qemu would benefit from a configuration language | 18:55 |
| swetland | requested edit access to your spreadsheet if you want me to info on my patches | 18:56 |
| mithro | swetland: there have been multiple attempts at getting a config language into QEMU with resulting multiple flame wars and people quoting. | 18:56 |
| swetland | oh joy | 18:57 |
| mithro | S/quoting/quiting/ | 18:57 |
| mithro | swetland: should have access now | 18:57 |
| mithro | swetland: dunno if you are a rust person or not https://antmicro.com/blog/2021/07/rust-peripheral-support-in-renode/ | 18:58 |
| tpb | Title: Antmicro · Rust peripheral support in Renode (at antmicro.com) | 18:58 |
| mithro | swetland: Renode can even co-similate with a peripheral being emulated by verilog code in Renode | 18:58 |
| 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 | 18:59 |
| swetland | now *that's* a useful feature | 18:59 |
| mithro | https://renode.readthedocs.io/en/latest/tutorials/verilator-cosimulation.html | 18:59 |
| tpb | Title: Co-simulating HDL models — Renode - documentation (at renode.readthedocs.io) | 18:59 |
| swetland | co-simulation is super hand | 18:59 |
| swetland | handy | 18:59 |
| 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 | 19:00 |
| mithro | swetland: take a look at https://renode.readthedocs.io/en/latest/advanced/writing-peripherals.html some time | 19:01 |
| tpb | Title: Peripheral modeling guide — Renode - documentation (at renode.readthedocs.io) | 19:01 |
| mithro | swetland: xobs is probably the most advanced Renode user outside of paying Antmicro customers | 19:02 |
| swetland | so spreadsheet doesn' | 19:02 |
| swetland | t have entries for the timer, interrupt controller (maybe that counts as vexriscv support) | 19:03 |
| swetland | should I just add them? | 19:03 |
| mithro | Yeah | 19:04 |
| mithro | swetland: https://antmicro.com/blog/2021/09/cfu-support-in-renode/ is pretty cool, it is extending the simulated CPU with specific custom opcodes deligated to simulation in verilator | 19:05 |
| tpb | Title: Antmicro · Boosting Machine Learning with tailored accelerators: Custom Function Units in Renode (at antmicro.com) | 19:05 |
| mithro | Sometimes it is really hard to stop talking about Renode as there is just *so* many cool features it has | 19:09 |
| swetland | it certainly looks promising | 19:10 |
| 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 | 19:10 |
| swetland | slick | 19:11 |
| mithro | https://docs.google.com/drawings/d/13bRFtmgb7Og6hmWEYqxPrfbshxPwuIRDJ0NzPKeBoZs/edit?usp=drivesdk | 19:11 |
| tpb | Title: LiteX Wishbone Bridge Infrastructure - Google Zeichnungen (at docs.google.com) | 19:11 |
| mithro | http://bit.ly/litex-bridge-proto | 19:12 |
| tpb | Title: LiteX Bridge Protocol - Google Docs (at bit.ly) | 19:12 |
| mithro | I'm sure I had some better diagrams somewhere | 19:12 |
| mithro | https://docs.google.com/drawings/d/1tfDZcxK3Ui8EaOnEDisxe8_LyromUIGIFkmcP76gBdc/edit?usp=drivesdk | 19:13 |
| tpb | Title: Renode Wishbone Bridge Infrastructure - Google Zeichnungen (at docs.google.com) | 19:13 |
| mithro | A lot of this is demonstrated in the Fomu workshop | 19:16 |
| mithro | Being able to poke/peek and single step the soft CPU via USB is pretty magical | 19:16 |
| mithro | Anyway, lunch time for me | 19:17 |
| swetland | later! | 19:18 |
| 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. | 19:50 |
| jevinskie[m] | The DECA would be so wonderful with native litedram support! :) | 19:51 |
| swetland | wow the video framebuffer has some serious impact on memory bandwidth ^^ | 20:28 |
| swetland | I get 20.4MB/s memset with video dma off, 3.1MB/s memset with it on | 20:29 |
| 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 | 20:44 |
| _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 | 20:57 |
| _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 :) | 20:57 |
| _florent_ | jevinskie[m]: I'm interested to help if you have troubles (and also have the DECA) | 20:58 |
| 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 | 21:31 |
| 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. | 22:29 |
| mithro | swetland: If you need a Fomu so you can do the Fomu workshop, I would be happy to send you one | 22:29 |
| mithro | The paper at https://www.researchgate.net/profile/Sergiu-Mosanu/publication/360226899_PiMulator_a_Fast_and_Flexible_Processing-in-Memory_Emulation_Platform/links/6269a750d99ac24cc46e4339/PiMulator-a-Fast-and-Flexible-Processing-in-Memory-Emulation-Platform.pdf seems to be doing stuff with LiteX | 22:50 |
| 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. | 22:51 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!