| *** tpb has joined #litex | 00:00 | |
| futarisIRCcloud | https://gitlab.com/theseus-cores/theseus-cores | 00:23 |
|---|---|---|
| tpb | Title: Theseus Cores / Theseus Cores · GitLab (at gitlab.com) | 00:23 |
| keesj | hmm sdr+fpga .. so nice.. | 08:26 |
| keesj | I also have a pluto sdr module with lots of documentation. it is really amazing as it does so much stuff (pc communication, it is running a full linux, it has an fpga(psoc I think) , the analog modules and the RF front end | 08:28 |
| keesj | https://wiki.analog.com/university/tools/pluto | 08:29 |
| tpb | Title: ADALM-PLUTO Overview [Analog Devices Wiki] (at wiki.analog.com) | 08:29 |
| _florent__ | keesj: indeed, the pluto is really interesting for the price | 08:36 |
| *** futarisIRCcloud has quit IRC | 08:48 | |
| keesj | the only "down side" is that it can not transmist high power.. for me this is probably a good thing.. (I have a few more SDR's). | 09:30 |
| keesj | An other project I spend time one before this FPGA project I am currently working on is the chipwhisperer (This is a SAM3U + Spartan 6 + ADC for side channel analisys) the board itself is open hardware and the sources are also available. It is just waiting for litex to provide cool protocol and triggering features | 09:33 |
| keesj | the sides from osda look like a nice overview of litex/fhdl/migen https://osda.gitlab.io/19/1.1-slides.pdf | 09:33 |
| keesj | if there is a workshop somewhere I would probably join | 09:34 |
| *** futarisIRCcloud has joined #litex | 10:02 | |
| _florent__ | keesj: yes these devices are generally not intended to transmit high power. It's fine for testing in the lab. | 11:44 |
| _florent__ | keesj: doing a workshop could be fun, i know a few others people that could be interested, i'll see in the future if i can organize one | 11:49 |
| keesj | I am currently also writing a small game in verilog (a modification from pong from fpga4fun). over the week-end I replaced the padle code with something that use an ultra sonic distance sensor. | 12:44 |
| keesj | I am will next try to get two sensors working (one at the time) but perhaps can also do some more radare type stuff | 12:44 |
| keesj | this is on the tinyfpga and inspired by older videos from Jeri Ellsworth I think it would also be fun to use the VGA output as scope | 12:45 |
| keesj | and because it was kingsday in .nl there was a huge flee market in Amsterdam and I got hold of a second px1000 device https://www.cryptomuseum.com/crypto/philips/px1000/index.htm | 12:47 |
| tpb | Title: PX-1000 (at www.cryptomuseum.com) | 12:47 |
| keesj | (I might .. if I ever get to it implement it in fpga) | 12:48 |
| _florent__ | nice, feel free to share you progress here :) | 12:50 |
| keesj | it remains kinda slow ... | 12:53 |
| keesj | after more reading and trying last week I am still working on the serdes. today I "discovered" that not all high speed input pins of the arty can be used as clock source | 12:59 |
| keesj | I also am reading the xapp1017 app notes on the serdes. | 13:00 |
| keesj | if I will try to clock in DDR mote at at 48Mhz clock (96 Mbit/s) | 13:02 |
| keesj | and push this to LiteScope | 13:02 |
| keesj | also by reading the SelectIO resource I am starting to see the pattern between the "self.special" items and the generated code | 13:04 |
| keesj | it would be nearly impossible to understand the python code without this documentation | 13:04 |
| keesj | futher more.. for my design I am thinking it might be best to use the incomming ddr clock to clock the whole system (my ddr clock is at 530 Mhz) but I think the A7 can only do about 450 Mhz internal logic | 13:06 |
| keesj | turtles all the way down | 13:07 |
| _florent__ | your internal logic will not run at the DDR clock since you are using IOSerdes in 1:8 mode, but yes that's still challenging since in LiteDRAM the default DDR clock is 400MHz on Artix7 | 13:17 |
| _florent__ | i remembered testing Artix7 DRAM with higher frequencies (at least 500MHz DDR clock) | 13:18 |
| keesj | I can't even use 1:8 mode I probably need 1:2 for more real time capabilities(less latency) | 14:03 |
| keesj | the arty page states 256MB DDR3L with a 16-bit bus @ 667MHz | 14:08 |
| keesj | that is the clock rate right (e.g. the bit rate is 16 * 667 * 2) ? | 14:09 |
| keesj | or does this require some xilinx magic? | 14:10 |
| somlo | litedram_gen.py is highly Xilinx-centric :) | 14:23 |
| * somlo trying to "translate" it into something that'd work on ecp5versa... | 14:23 | |
| _florent__ | somlo: that should help you integrate the rocket CPU: https://github.com/enjoy-digital/litex/commit/5c1d9805400d1593ebe6cd42f6948af735f02de9 :) | 14:59 |
| tpb | Title: soc/interconnect/axi: add burst support to AXI2Wishbone · enjoy-digital/litex@5c1d980 · GitHub (at github.com) | 14:59 |
| _florent__ | somlo: the AXIBurst2Beat was already well tested in LiteDRAM, so it should work without too much troubles | 15:00 |
| somlo | _florent_: oh cool, back to plan A, then :) Just started working on an ecp5 specific version of litedram_gen.py, with the long-term goal of re-factoring it to the point where the xilinx-specific (or lattice-specific) bits are in the *_config.py files :) | 15:03 |
| somlo | but now I can't *not* go back to trying out straight-forward rocket integration again :) | 15:04 |
| _florent__ | yes sorry, for now litedram_gen was only for Xilinx FPGA | 15:06 |
| _florent__ | having support for the others family would be really nice | 15:07 |
| _florent__ | if you have a patch for ECP5, i'm happy to merge | 15:07 |
| _florent__ | otherwise for the AXI2Wishbone, i also have a need for it, that's why i did it, but that would be interesting to see if it allow you to integrate rocket | 15:08 |
| somlo | about that, it looks like the standalone litedram module handles clock generation internally, and outputs a "user" clock that goes to the CPU and other non-LiteX SoC blocks | 15:08 |
| _florent__ | yes because in most of the cases the CPU will just use the DRAM clock | 15:10 |
| _florent__ | CPU = (not the embedded CPU but the CPU of the SoC where the LiteDRAM core is integrated) | 15:10 |
| somlo | wait, user_clk is the same as what the litex embedded cpu uses, and it's different from e.g. ddram_clk_p | 15:15 |
| somlo | which is fine, the fastest I got Rocket to run on ecp5 was 20MHz, and I'm totally fine with the ddram going faster than that | 15:15 |
| _florent__ | but i'm not sure we tested the DRAM controller on ECP5 below 50MHz | 15:21 |
| _florent__ | and you'll need to run your Rocket CPU with the provided user_clk | 15:22 |
| somlo | wait, I'm getting confused :) | 15:23 |
| somlo | I thought the DRAM itself is in a different clock domain from user_clk | 15:24 |
| _florent__ | it's a different clock domain but synchronous and dram_clk = 4*user_clk | 15:25 |
| somlo | oh, so if you specify a low user_clk you get a correspondingly lower dram clock, because hardcoded 4? | 15:26 |
| somlo | easy test, I can try building a vexriscv litex soc for the versa at 20MHZ, see if it passes dram test :) | 15:27 |
| _florent__ | yes i would recommend testing before | 15:30 |
| *** futarisIRCcloud has quit IRC | 15:32 | |
| somlo | ok, so simply changing sys_clk_freq doesn't work below 50MHz here: https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/versa_ecp5.py#L82 | 16:22 |
| tpb | Title: litex/versa_ecp5.py at master · enjoy-digital/litex · GitHub (at github.com) | 16:22 |
| somlo | but then, there's this, a few lines further down: https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/versa_ecp5.py#L97 | 16:23 |
| tpb | Title: litex/versa_ecp5.py at master · enjoy-digital/litex · GitHub (at github.com) | 16:23 |
| somlo | apparently the rate is 1:2, wonder what will happen if I change that to 1:4 | 16:23 |
| somlo | I suppose I could find out if I dug around long enough, but what's the preferred target dram clock interval for MT41K64M16 (the dram chip on the ecp5 versa)? | 16:26 |
| _florent__ | on ECP5, the controller has only been validated at 1:4, 1:2 would need specific work to work | 16:29 |
| somlo | so how come it's 1:2 in the upstream sources? | 16:29 |
| somlo | and it works (with 1:2 and 50..75 MHz) too, so I'm not complaining, just confused :) | 16:31 |
| _florent__ | ah no sorry, we only validated 1:2 | 16:31 |
| somlo | ok, so far it failed at 25Mhz and 1:4, trying 30Mhz next :) | 16:32 |
| _florent__ | 1:4 won't work | 16:32 |
| somlo | like, not at all? | 16:32 |
| somlo | ok, might as well not waste time on it, then | 16:32 |
| _florent__ | it's not possible with the IOs of the ECP5 | 16:33 |
| somlo | ok, so that's good to know, if/when I get Rocket to work with AXI under verilator, I'll have to get it to run at min. 50MHz | 16:34 |
| _florent__ | if you want to test/integrate rocket, it's maybe better to use the other xilinx board you have in a first time | 16:34 |
| somlo | I have a nexys4ddr, but I hate Vivado :) | 16:34 |
| daveshah | Running at a lower frequency might be possible by changing the READ pulse position | 16:35 |
| daveshah | https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/ecp5ddrphy.py#L462 | 16:35 |
| tpb | Title: litedram/ecp5ddrphy.py at master · enjoy-digital/litedram · GitHub (at github.com) | 16:35 |
| somlo | daveshah: I'm writing that link down for future reference :) Right now it looks like some bit passing through a shift register, and dqs_read is asserted when the bit passes through a certain 2-bit window in that register :) No clue as to how I'd change that, but before spending time on this mystery, I'd first have to get Rocket working in simulation anyway :) | 16:52 |
| somlo | _florent_: still triggering the (same) AXI assertion inside rocket :( Something about an AXI RVALID response arriving before the corresponding AXI ARVALID request being sent... | 18:33 |
| _florent__ | somlo: can you share you simulation code so that i can have a look? | 19:03 |
| somlo | sure thing. I just sent a bunch of PRs to factor out the (hopefully) "uncontroversial" mods to litex, litedram, and tapcfg (vexriscv simulation and nexys4ddr & ecp5versa synthesis still work perfectly fine after these patches) | 19:17 |
| somlo | so I'll then only have to point at Rocket-specific hacks, which should be easier to consider once the "noise" has been factored out :) | 19:18 |
| *** futarisIRCcloud has joined #litex | 22:12 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!