02:01 <tcal> gatecat: targeting an internal board, I'm getting this error due to a pin constraint: `ERROR: IO 'data_IB_I' is constrained to pin G7 (PCLKC5_2/ADC_CN2/COMP3N) which is not a general purpose IO pin.` (the part is LIFCL-17-WLCSP72). Is there a chance this check is too restrictive? Radiant describes many of these pins as dual function, for example this one G7 is described as "PCLK", "true LVDS", and "differential -".

07:31 <keesj> what is a good approch for testing my verilog module that is integrated into litex.

07:31 <keesj> can I .. test a wishbone slave or similar then?

07:31 <keesj> before integrating I used a verilog test bench and gtkwave

07:32 <_florent_> keesj: you could start by adapting litex_sim and add your peripheral to it

07:33 <_florent_> you can then do iteration in a few seconds and write/read to your peripheral with the mem_write/read commands from the BIOS

07:33 <keesj> lxsim like magic (at least it does not matter wheren I run it I get this nice prompt :P )

07:35 <keesj> but I am correct that using the python eval type won't work right?

07:37 <_florent_> litex_sim is here: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_sim.py

07:37 <keesj> so I would modify the code there and run again correct?

07:38 <_florent_> you copy it to your project and add your peripherals to it here (similarly than adding it to your target): https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_sim.py#L330

07:38 <_florent_> litex_sim is a regular LiteX SoC with peripherals stub/models for the simulation (ex UART/Ethernet/SDRAM DFI Model, etc...)

07:39 <keesj> I am working on nand flash so I will also need to emulate that part

07:39 <_florent_> instead of runnning on hardware, the SoC run on your PC with Verilator

07:39 <_florent_> runs

07:43 <_florent_> yes, you'll have to create a model or create an emulator. You can eventually look at the I2C/SDCard integration in litex_sim: I2C is simulated with a software model, SDCard with a gateware SD Emulator (adapted from flipsyfat/project Vault): https://github.com/enjoy-digital/litesdcard/tree/master/litesdcard/emulator

07:57 <gatecat> tcal: this isn't to do with clocks per se, but just some LIFCL-17 IO being missing. I will look into this over the next few days but without any hardware to test with LIFCL-17 support should be assumed to be incomplete

09:22 <leons> gatecat: whoo, I've got my Kintex-7 board running the bootloader and printing to the serial, awesome! :)

09:23 <leons> Now I'm stuck at the DRAM, that's a whole new world for me. I have a MT41K512M8 which should(?) be very similar to the already supported MT41K256M16, but I can't really seem to make sense of the banks, rows, cols defined in litedram, compared to the numbers I see in the datasheet...

09:28 <leons> I think the real question here is, what's the potential for persitent damage to my board when trying with wrong parameters for DRAM?

11:16 <leons> Is there any standard approach on how to debug LiteDRAM with a specific chip? I can't seem to get mine to work, always "Memtest KO" with 8191/8192 data and 524288/524288 data errors.

11:18 <_florent_> leons: good for the initial SoC

11:18 <_florent_> can you share the boot log with the DDR3 calibration?

11:19 <leons> _florent_: Absolutely! https://gist.githubusercontent.com/lschuermann/c48e8668e13c38f413480d66967e1945/raw/8946498c200b09434025090dfd2966aed0e15007/litex_dram_log.txt

11:19 <leons> With the disclaimer that I don't really know what I'm doing quite honestly :)

11:20 <_florent_> ok thanks, so nothing it responding during write/read leveling

11:20 <_florent_> which boards are you using as a reference?

11:22 <leons> I've been basing this on the Genesys2 (since it uses the same FPGA) but a different DRAM chip

11:22 <leons> Uploaded my current target and platform definition here https://gist.github.com/lschuermann/d7262248b0f077b25932c73c553e0e1c

11:23 <leons> I tried defining my DRAM chip in the target definition, with the proper values from the Datasheet, but that didn't work

11:25 <leons> And I've of course changes the constraints to match those of the board vendor 🙂 https://reference.digilentinc.com/reference/programmable-logic/netfpga-1g-cml/reference-manual#appendix_bfpga_pin_constraints

11:25 <tpb> Title: NetFPGA-1G-CML Reference Manual - Digilent Reference (at reference.digilentinc.com)

11:36 <_florent_> leons: ok, it seems good, can you just change the IOStandard for the DQS pins: https://gist.github.com/lschuermann/d7262248b0f077b25932c73c553e0e1c#file-platform-py-L55-L56

11:37 <_florent_> from "DIFF_SSTL15_T_DCI" to "DIFF_SSTL15"? (since we are only using DQS as outputs)

11:39 <leons> _florent_: Sure, building the bitstream now! Thanks for the help, for me this is really a black box, going to read up on the difference between the two IO standards now

11:47 <leons> Unfortunately changing DQS to DIFF_SSTL15_T_DCI makes no difference in the output

12:21 <_florent_> leons: ok, I don't think you are far from getting it working, I don't see anything obvious but would need to have a closer look

12:22 <_florent_> leons: you can maybe try to get the MIG project for this boards and compare the constraints that are used in the MIG to the ones you are using

12:23 <leons> _florent_: thanks, that's a great idea. don't worry about it, I'm grateful for any help I can get!

12:24 <leons> I'll keep experimenting - though is there a high chance I can brick my board by choosing wrong constraints / DRAM parameters? Apart from obvious shorts or wrong voltages

12:27 <_florent_> That would be really unlikely, at least I never damaged a boards with a wrong LiteDRAM config

13:46 <geertu> _florent_: When building linux-on-litex-vexriscv for OrangeCrab, I get "Warning: Max frequency for clock '$glbnet$sys_clk': 60.72 MHz (FAIL at 64.00 MHz)"

13:47 <geertu> Looking at my old build logs, this seems to have always failed since forever (that is, the last 6 months), with values ranging from 56.46 to 63.56 MHz.

13:54 <_florent_> geertu: ok, we are currently looking at LiteSDCard with gsomlo to fix some backpressure issues with Linux, this should allow reducing buffering and relax timing a bit on the OrangeCrab that is pretty full with VexRiscv and LiteSDCard

15:00 <leons> I tried generating a memory interface with the MIG and copied all of the timing parameters etc., still no luck... Would it even be expected that the RAM is not responding at all due to a bad timing configuration?

15:29 <leons> Can I by chance get a QDRII+ SRAM to work instead of DRAM for now with LiteX?

16:18 <tcal> gatecat: thanks! Let me know if I can help at my end in some way.

17:04 <tcal> gatecat: ...or if it's useful for me to send you a tar of the litex build/ directory.

17:05 <gatecat> tcal: yes that would definitely be useful

18:08 <tcal> gatecat: Ok, I have a 45kB self-contained tar I can e-mail to you -- is the ds0 address good? Or do you prefer a different channel?

18:08 <gatecat> tcal: yes, please email to the ds0 address, thanks

18:11 <leons> Is there any other approach to debugging LiteDRAM if nothing seems to work, other than trial and error?

18:12 <leons> I was looking into using the Vivado-generated memory controller IP standalone to see if the DRAM works at all, but that seems a lot more complex than I anticipated :)

18:12 <gatecat> I think there are some debug things like some of the registers but if nothing is responding that may not help

18:13 <gatecat> staring at the board file can be useful, too

18:13 <gatecat> it's also worth checking if anything like power/termination supplies need to be enabled for the DRAM to work, this has caught me out before

18:14 <leons> that's a good point. I can't shake the feeling that there's something wrong with my clocks. LiteEth also doesn't (at least in the bootloader), although I can read the MDIO regs of the PHY

18:24 <leons> gatecat: mhm, according to the datasheet, the DRAM is always powered, all other pins are connected to the proper FPGA pins. it behaves like it's not even there...

18:58 <leons> Oh no, I just now realized I can also use an integrated main RAM for getting started! That works at least :D

19:13 <leons> Very exciting, LiteEth works as well. I'll keep working on LiteDRAM on this board, however how upstreamable is an initial version of a board which only has internal RAM?