| *** tpb has joined #litex | 00:00 | |
| *** rj has quit IRC | 00:28 | |
| *** rj has joined #litex | 00:33 | |
| *** lf has quit IRC | 00:36 | |
| *** lf has joined #litex | 00:36 | |
| *** rj has quit IRC | 01:13 | |
| *** rj has joined #litex | 01:17 | |
| *** FFY00_ has quit IRC | 01:47 | |
| *** rj has quit IRC | 02:00 | |
| 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 -". | 02:01 |
|---|---|---|
| *** rj has joined #litex | 02:19 | |
| *** Degi_ has joined #litex | 02:28 | |
| *** rj has quit IRC | 02:29 | |
| *** Degi has quit IRC | 02:30 | |
| *** Degi_ is now known as Degi | 02:30 | |
| *** rj has joined #litex | 03:59 | |
| *** rj has quit IRC | 04:04 | |
| *** Bertl_oO is now known as Bertl_zZ | 05:44 | |
| *** kgugala_ has joined #litex | 05:47 | |
| *** kgugala has quit IRC | 05:50 | |
| *** pftbest has joined #litex | 06:57 | |
| *** kgugala_ has quit IRC | 07:12 | |
| *** kgugala has joined #litex | 07:13 | |
| *** rozpruwacz has joined #litex | 07:14 | |
| 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:31 |
| _florent_ | keesj: you could start by adapting litex_sim and add your peripheral to it | 07:32 |
| _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:32 |
| keesj | lxsim like magic (at least it does not matter wheren I run it I get this nice prompt :P ) | 07:33 |
| keesj | but I am correct that using the python eval type won't work right? | 07:35 |
| _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:37 |
| _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:38 |
| 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:39 |
| *** peeps[zen] has joined #litex | 07:42 | |
| _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:43 |
| *** peepsalot has quit IRC | 07:44 | |
| *** geertu_ is now known as geertu | 07:51 | |
| 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 | 07:57 |
| *** shenki has quit IRC | 08:17 | |
| *** shenki has joined #litex | 08:17 | |
| *** RaivisR_ has joined #litex | 08:35 | |
| *** RaivisR__ has joined #litex | 08:36 | |
| *** RaivisR has quit IRC | 08:38 | |
| *** RaivisR_ has quit IRC | 08:39 | |
| leons | gatecat: whoo, I've got my Kintex-7 board running the bootloader and printing to the serial, awesome! :) | 09:22 |
| 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:23 |
| 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? | 09:28 |
| 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:16 |
| _florent_ | leons: good for the initial SoC | 11:18 |
| _florent_ | can you share the boot log with the DDR3 calibration? | 11:18 |
| 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:19 |
| _florent_ | ok thanks, so nothing it responding during write/read leveling | 11:20 |
| _florent_ | which boards are you using as a reference? | 11:20 |
| 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:22 |
| leons | I tried defining my DRAM chip in the target definition, with the proper values from the Datasheet, but that didn't work | 11:23 |
| 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:25 |
| _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:36 |
| _florent_ | from "DIFF_SSTL15_T_DCI" to "DIFF_SSTL15"? (since we are only using DQS as outputs) | 11:37 |
| 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:39 |
| leons | Unfortunately changing DQS to DIFF_SSTL15_T_DCI makes no difference in the output | 11:47 |
| *** lambda has quit IRC | 11:49 | |
| *** lambda has joined #litex | 11:51 | |
| *** rozpruwacz has quit IRC | 12:16 | |
| _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:21 |
| _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:22 |
| leons | _florent_: thanks, that's a great idea. don't worry about it, I'm grateful for any help I can get! | 12:23 |
| 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:24 |
| *** rozpruwacz has joined #litex | 12:26 | |
| *** Bertl_zZ is now known as Bertl | 12:26 | |
| _florent_ | That would be really unlikely, at least I never damaged a boards with a wrong LiteDRAM config | 12:27 |
| 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:46 |
| 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:47 |
| _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 | 13:54 |
| *** m4ssi has joined #litex | 14:09 | |
| *** m4ssi has quit IRC | 14:45 | |
| 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:00 |
| *** peeps[zen] has quit IRC | 15:26 | |
| *** peepsalot has joined #litex | 15:26 | |
| leons | Can I by chance get a QDRII+ SRAM to work instead of DRAM for now with LiteX? | 15:29 |
| *** mikeK_de1soc has joined #litex | 15:31 | |
| *** felix_ has quit IRC | 15:32 | |
| *** felix_ has joined #litex | 15:33 | |
| *** awordnot has quit IRC | 15:46 | |
| tcal | gatecat: thanks! Let me know if I can help at my end in some way. | 16:18 |
| *** RaivisR__ has quit IRC | 16:24 | |
| *** pftbest has quit IRC | 16:32 | |
| *** mikeK_de1soc has quit IRC | 16:34 | |
| *** pftbest has joined #litex | 16:42 | |
| *** pftbest has quit IRC | 16:47 | |
| *** peepsalot has quit IRC | 16:48 | |
| *** peeps[zen] has joined #litex | 16:48 | |
| *** pftbest has joined #litex | 16:48 | |
| *** rozpruwacz has quit IRC | 16:58 | |
| *** peeps[zen] has quit IRC | 16:58 | |
| *** peepsalot has joined #litex | 16:59 | |
| tcal | gatecat: ...or if it's useful for me to send you a tar of the litex build/ directory. | 17:04 |
| gatecat | tcal: yes that would definitely be useful | 17:05 |
| *** pftbest has quit IRC | 18:05 | |
| *** pftbest has joined #litex | 18:07 | |
| *** pftbest_ has joined #litex | 18:07 | |
| 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:08 |
| leons | Is there any other approach to debugging LiteDRAM if nothing seems to work, other than trial and error? | 18:11 |
| *** pftbest_ has quit IRC | 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:12 |
| 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:13 |
| 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:14 |
| *** kgugala_ has joined #litex | 18:15 | |
| *** kgugala has quit IRC | 18:15 | |
| *** pftbest has joined #litex | 18:16 | |
| 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:24 |
| *** FFY00_ has joined #litex | 18:42 | |
| *** kgugala has joined #litex | 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 | 18:58 |
| *** kgugala_ has quit IRC | 19:00 | |
| 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? | 19:13 |
| *** rozpruwacz has joined #litex | 19:27 | |
| *** awordnot has joined #litex | 19:32 | |
| *** rozpruwacz has quit IRC | 20:25 | |
| *** rozpruwacz has joined #litex | 20:26 | |
| *** hansfbaier has joined #litex | 21:07 | |
| *** mikeK_de1soc has joined #litex | 21:30 | |
| *** mikeK_de1soc has quit IRC | 21:32 | |
| *** mikeK_de1soc has joined #litex | 21:44 | |
| *** lkcl has quit IRC | 22:15 | |
| *** lkcl has joined #litex | 22:28 | |
| *** hansfbaier has quit IRC | 23:23 | |
| *** pftbest has quit IRC | 23:44 | |
| *** pftbest has joined #litex | 23:54 | |
| *** pftbest has quit IRC | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!