| *** tpb has joined #litex | 00:00 | |
| *** peeps[zen] has quit IRC | 00:03 | |
| *** proteusguy has quit IRC | 00:03 | |
| *** shorne has quit IRC | 00:03 | |
| *** feldim2425 has quit IRC | 00:03 | |
| *** st-gourichon-fid has quit IRC | 00:03 | |
| *** _whitelogger has quit IRC | 00:03 | |
| *** Claude has quit IRC | 00:03 | |
| *** tannewt has quit IRC | 00:03 | |
| *** the_jinx has quit IRC | 00:03 | |
| *** carlomaragno has quit IRC | 00:03 | |
| *** y2kbugger has quit IRC | 00:03 | |
| *** rohitksingh has quit IRC | 00:03 | |
| *** bubble_buster has quit IRC | 00:03 | |
| *** pdp7 has quit IRC | 00:03 | |
| *** flammit has quit IRC | 00:03 | |
| *** ric96 has quit IRC | 00:03 | |
| *** DerFetzer[m] has quit IRC | 00:03 | |
| *** xobs has quit IRC | 00:03 | |
| *** jryans has quit IRC | 00:03 | |
| *** gruetzkopf has quit IRC | 00:03 | |
| *** joseng has quit IRC | 00:03 | |
| *** benh has quit IRC | 00:03 | |
| *** iTitou has quit IRC | 00:03 | |
| *** tumbleweed has quit IRC | 00:03 | |
| *** DerFetzer[m] has joined #litex | 00:05 | |
| *** xobs has joined #litex | 00:05 | |
| *** jryans has joined #litex | 00:05 | |
| *** gruetzkopf has joined #litex | 00:05 | |
| *** joseng has joined #litex | 00:05 | |
| *** iTitou has joined #litex | 00:05 | |
| *** benh has joined #litex | 00:05 | |
| *** tumbleweed has joined #litex | 00:05 | |
| *** _whitelogger has joined #litex | 00:05 | |
| *** Claude has joined #litex | 00:05 | |
| *** tannewt has joined #litex | 00:05 | |
| *** ric96 has joined #litex | 00:05 | |
| *** the_jinx has joined #litex | 00:05 | |
| *** carlomaragno has joined #litex | 00:05 | |
| *** y2kbugger has joined #litex | 00:05 | |
| *** rohitksingh has joined #litex | 00:05 | |
| *** bubble_buster has joined #litex | 00:05 | |
| *** pdp7 has joined #litex | 00:05 | |
| *** flammit has joined #litex | 00:05 | |
| *** jryans has quit IRC | 00:06 | |
| *** peeps[zen] has joined #litex | 00:06 | |
| *** proteusguy has joined #litex | 00:06 | |
| *** st-gourichon-fid has joined #litex | 00:06 | |
| *** shorne has joined #litex | 00:06 | |
| *** feldim2425 has joined #litex | 00:06 | |
| *** DerFetzer[m] has quit IRC | 00:06 | |
| *** xobs has quit IRC | 00:07 | |
| *** apolkosnik[m] has quit IRC | 00:07 | |
| *** promach3 has quit IRC | 00:07 | |
| *** sajattack[m] has quit IRC | 00:07 | |
| *** david-sawatzke[m has quit IRC | 00:07 | |
| *** CarlFK[m] has quit IRC | 00:07 | |
| *** disasm[m] has quit IRC | 00:07 | |
| *** jevinskie[m] has quit IRC | 00:07 | |
| *** FFY00 has quit IRC | 00:07 | |
| *** leons has quit IRC | 00:08 | |
| *** lf has quit IRC | 00:08 | |
| *** lf_ has joined #litex | 00:08 | |
| *** FFY00 has joined #litex | 00:08 | |
| *** ric96 has quit IRC | 00:12 | |
| *** ric96 has joined #litex | 00:12 | |
| *** DerFetzer[m] has joined #litex | 00:35 | |
| *** apolkosnik[m] has joined #litex | 00:43 | |
| *** xobs has joined #litex | 00:43 | |
| *** david-sawatzke[m has joined #litex | 00:47 | |
| *** CarlFK[m] has joined #litex | 00:47 | |
| *** Dolu has quit IRC | 00:47 | |
| *** CarlFK[m] has quit IRC | 00:51 | |
| *** DerFetzer[m] has quit IRC | 00:51 | |
| *** david-sawatzke[m has quit IRC | 00:52 | |
| *** apolkosnik[m] has quit IRC | 00:52 | |
| *** xobs has quit IRC | 00:52 | |
| *** apolkosnik[m] has joined #litex | 01:02 | |
| *** leons has joined #litex | 01:22 | |
| *** disasm[m] has joined #litex | 01:22 | |
| *** sajattack[m] has joined #litex | 01:22 | |
| *** xobs has joined #litex | 01:22 | |
| *** david-sawatzke[m has joined #litex | 01:22 | |
| *** CarlFK[m] has joined #litex | 01:22 | |
| *** DerFetzer[m] has joined #litex | 01:22 | |
| *** promach3 has joined #litex | 01:22 | |
| *** jryans has joined #litex | 01:22 | |
| *** jevinskie[m] has joined #litex | 01:22 | |
| *** [Matt] has quit IRC | 01:22 | |
| *** [Matt] has joined #litex | 01:36 | |
| *** lkcl has quit IRC | 02:00 | |
| *** chgavilana01 has quit IRC | 02:04 | |
| *** chgavilana has quit IRC | 02:04 | |
| *** lkcl has joined #litex | 02:11 | |
| *** peeps[zen] is now known as peepsalot | 02:24 | |
| david-sawatzke[m | florent: Thanks for the help! | 02:40 |
|---|---|---|
| *** st-gourichon-fid has quit IRC | 02:41 | |
| *** st-gourichon-fid has joined #litex | 02:44 | |
| *** cr1901_modern has quit IRC | 02:46 | |
| *** feldim2425 has quit IRC | 03:09 | |
| *** feldim2425 has joined #litex | 03:24 | |
| *** Degi_ has joined #litex | 04:09 | |
| *** Degi has quit IRC | 04:12 | |
| *** Degi_ is now known as Degi | 04:12 | |
| *** lkcl has quit IRC | 04:31 | |
| *** lkcl has joined #litex | 04:43 | |
| *** lkcl has quit IRC | 05:00 | |
| *** lkcl has joined #litex | 05:12 | |
| *** Bertl_oO is now known as Bertl_zZ | 05:25 | |
| *** kgugala has joined #litex | 06:51 | |
| *** Dolu has joined #litex | 06:53 | |
| *** kgugala_ has quit IRC | 06:54 | |
| *** lkcl has quit IRC | 07:13 | |
| *** lkcl has joined #litex | 07:25 | |
| *** futarisIRCcloud has joined #litex | 07:42 | |
| *** kgugala has quit IRC | 08:11 | |
| *** kgugala has joined #litex | 08:11 | |
| Dolu | zyp : For the interrupts, there is how it is implemented : https://github.com/SpinalHDL/VexRiscv/blob/98de02051e1a5c9400c022dc61acd4bd0507f8a5/src/main/scala/vexriscv/plugin/ExternalInterruptArrayPlugin.scala that's a layer over the regular RISC-V previlegied spec added to be compatible with the way misoc/litex were used to use interrupts | 08:15 |
| zyp | Dolu, ah, thanks | 08:17 |
| *** proteusguy has quit IRC | 08:30 | |
| *** proteusguy has joined #litex | 08:42 | |
| *** hansfbaier has joined #litex | 08:45 | |
| *** Bertl_zZ is now known as Bertl | 11:42 | |
| *** hansfbaier has quit IRC | 12:32 | |
| *** roboknight has joined #litex | 14:13 | |
| roboknight | So, I've been trying to add a verilog component to my vexriscv processor. I've finally got it compiling. How do I go about simulating everything such that I can see what happens to the signals when I access the component? I can get a handle around that if I'm setting up a single component, but what about monitoring the wishbone bus signals | 14:17 |
| roboknight | coming into my target component? | 14:17 |
| _florent_ | roboknight: if it's some verilog code, you can use litex_sim as a starting point for your simulation, you'll be able to simulate vexriscv and your component with verilator | 14:25 |
| _florent_ | you can also just generate the verilog from LiteX and do the simulation manually with verilator, icarus, etc... | 14:26 |
| roboknight | I'll take a look at that... I was trying to dig into the betrusted-io stuff for some simulation help, but a lot of the stuff seems wrapped up in some of their own tools for generating the proper simulation files. I'll also take a look at verilator and icarus to see how that goes... those might be significantly easier... not sure. | 14:31 |
| somlo | _florent_: I think I managed to hook up litex_sim, litex_server, and litescope_cli, and to trigger a capture based on the rising edge of a signal. | 14:46 |
| somlo | Remaining issue is that dump.vcd looks "blank" when I bring it up in gtkwave... | 14:47 |
| somlo | hoping the "nothing showing in gtkwave" issue is a common well-known n00b mistake with an easy answer :) | 14:48 |
| _florent_ | somlo: I just saw your mails, it seems good. For GTKWave, you have to select the Signals and click on Append | 14:50 |
| somlo | _florent_: so I was right, then: well-known n00b mistake with an easy answer :D | 14:58 |
| somlo | thanks much, looks like I'm on my way! | 14:58 |
| roboknight | Can the migen.fhdl.verilog convert function generate the full SoC? Or is it mainly used for generating parts of an SoC for testing? When attempting to use it like this: soc = BaseSoC(...) and then convert(soc).write("output.v") it says attempted to use a reset synchronizer, but platform does not support them... So I'm guessing I that's not | 15:17 |
| roboknight | quite right. | 15:17 |
| joseng | I have a strange behavior of the LiteDRAMDMAReader. When I read with it the first time, it returns the correct RAM content. When I change the data in the RAM and read again, I get the same content from the DMA Reader as before. | 16:29 |
| joseng | Do I need to set/reset something between transactions? Or might I have the timing/handshaking wrong for the addresses? | 16:30 |
| joseng | Just used a base address of 0 to read from the beginning of the RAM. When I read/write with the BIOS commands to the RAM, I see the correct values also changing in the RAM | 16:31 |
| joseng | Or now the DMA Reader reads only FF for all data I try to read... | 17:06 |
| *** roboknight has quit IRC | 17:19 | |
| _florent_ | joseng: it's possible you are writing/reading at a different location. | 17:37 |
| _florent_ | using the BIOS's mem_read/mem_write functions can be useful to diagnose this: verify that you read the same value with the mem_read and the LiteDRAMDMAReader, then update the data with mem_write and be sure you also get the updated data with LitedRAMDMAReader. | 17:38 |
| _florent_ | you can also try to replicate this in simulation with litex_sim and look at the .vcd traces or use Display as a printf equivalent to understand/debug the gateware | 17:41 |
| _florent_ | for example: https://github.com/enjoy-digital/litedram/blob/e5f4f828ad781a38c1ce99186819d75c0b878b39/litedram/phy/model.py#L265-L276 | 17:42 |
| joseng | Thanks for the hints with the wrong address. Thought when I provide the address 0 to the DMA Reader this means address 0x40000000 where the RAM starts | 19:27 |
| joseng | But my empirical tests showed now, that a write in the BIOS console "mem_write 0x40000000 0xAAAABBBB 0x810" shows exactly 16 byte of AAAABBBB returned by the DMA reader | 19:28 |
| joseng | After the 16 bytes of correct data I get FF again. When I write longer data from the BIOS command, I get more data returned by the DMA reader | 19:29 |
| joseng | Where does this come from, that the "start address" of the DMA reader is shifted up to 0x800 * 4 byte? | 19:30 |
| joseng | _florent_ Does the vexriscv I instantiate shift the address up with the memory sizes I provide there? | 19:32 |
| joseng | Or what do these lines exactly do? "integrated_rom_size=0x10000" and "integrated_main_ram_size=0x0000" (just copied this from the NeTV2 code when I first started) | 19:33 |
| joseng | The only thing I can find with a size of 0x2000 (0x800 * 4) is the "integrated_sram_size = 0x2000," in the SoCCore class, but the csr.csv export said that the "sram" region is at 0x01000000?! So whats the offset for the DMA Reader then? | 19:45 |
| *** Bertl is now known as Bertl_oO | 20:16 | |
| _florent_ | joseng: not sure that's your issue, but the addressing of the DMA reader is in controller's words not bytes, so 256-bit / 32-bytes | 20:17 |
| *** oter has joined #litex | 20:38 | |
| *** oter_ has joined #litex | 20:38 | |
| *** oter_ has quit IRC | 20:41 | |
| *** oter has quit IRC | 20:41 | |
| *** Defferix has joined #litex | 21:27 | |
| *** Defferix has joined #litex | 21:28 | |
| joseng | _florent_ Did some more testing. You are right, it is no offset or address mismatch. It seems to be some kind of caching in/in font of the DRAM Reader. When I write more than 8kB data to the RAM (either by a BIOS command or by a WIshbone RemoteClient in Python) the data the DMA Reader outputs changes immediately. When I write smaller junks of data, | 21:53 |
| joseng | the output of the DRAM Reader does not change. (Strangely the output of the mem_read BIOS command reflects all RAM writes from the Python client immediately, and vice versa) | 21:53 |
| joseng | I see that there is the l2 cache when calling "add_sdram", and the default is 8kB | 21:57 |
| tcal | kgugala -- https://github.com/enjoy-digital/litex/pull/774 caught my interest -- I had just been looking at the `add_debug(..)` routine in soc/cores/cpu/vexriscv/core.py. And I've used the debug interface before. What does the call to `soc.bus.add_slave(..)` add? Is it for information logging, to put more info in csr.csv? | 21:59 |
| tcal | Oops that should have been kgugala: | 22:01 |
| *** Defferix has quit IRC | 22:38 | |
| *** mithro has quit IRC | 22:38 | |
| *** mithro has joined #litex | 22:39 | |
| palmer | is there some way to run this setup without an FPGA? https://lore.kernel.org/linux-riscv/CAMuHMdXQr-qNQ2aNVmgQFfs_dJ8=A-xzrhxRf9VUmzFXx+2o_w@mail.gmail.com/ | 22:43 |
| tpb | Title: Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32 - Geert Uytterhoeven (at lore.kernel.org) | 22:43 |
| *** key2 has quit IRC | 22:57 | |
| *** key2 has joined #litex | 22:58 | |
| *** sorear has quit IRC | 22:58 | |
| *** sorear has joined #litex | 22:58 | |
| *** sajattack[m] has quit IRC | 23:00 | |
| *** david-sawatzke[m has quit IRC | 23:00 | |
| *** jevinskie[m] has quit IRC | 23:00 | |
| *** DerFetzer[m] has quit IRC | 23:03 | |
| *** xobs has quit IRC | 23:03 | |
| *** lambda has quit IRC | 23:03 | |
| joseng | _florent_ Tested now a design with an l2_size=128, sets the caching size down and I need to write less data. Not quite only 128 32bit words, but 140 words is enough to get the DMA reader output 128 changed words (16 * 256bit) | 23:06 |
| joseng | So something seems to be a bit odd with the caching? | 23:06 |
| *** david-sawatzke[m has joined #litex | 23:16 | |
| *** lambda_ has joined #litex | 23:17 | |
| *** sajattack[m] has joined #litex | 23:19 | |
| *** jevinskie[m] has joined #litex | 23:20 | |
| *** Finde has quit IRC | 23:20 | |
| *** Bertl_oO has quit IRC | 23:20 | |
| *** Finde has joined #litex | 23:21 | |
| *** xobs has joined #litex | 23:23 | |
| *** DerFetzer[m] has joined #litex | 23:25 | |
| *** Bertl_oO has joined #litex | 23:26 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!