| *** tpb has joined #litex | 00:00 | |
| *** Degi has quit IRC | 02:20 | |
| *** Degi has joined #litex | 02:20 | |
| *** TMM has quit IRC | 03:55 | |
| *** TMM has joined #litex | 03:55 | |
| *** benh has quit IRC | 04:10 | |
| *** benh has joined #litex | 05:00 | |
| _florent_ | sajattack[m]: indeed there is no default serial on the acorn_cle_215, you can use --uart-name=crossover or --uart-name=jtag_uart | 06:46 |
|---|---|---|
| _florent_ | for the CSR, 512-bit should be ok yes but probably not very efficient (in resource and performance) | 06:50 |
| _florent_ | st-gourichon-fid: Hi, that's true that we only focused on the gateware side for CSRField, having software support in csr.h for them would be nice. Instead of inject/extract, we could maybe just use write/read but create additional functions for the CSRFields. | 06:56 |
| _florent_ | ex: we have a control CSR with an enable Field: csr.h would then have a xy_control_write/read functions and also xy_control_enable_write/read functions? | 06:58 |
| zyp | having write functions for individual fields is inefficient if you want to set more than one of them at the same time | 07:00 |
| zyp | it's better to compose all the changes in a local variable before writing everything at once | 07:01 |
| _florent_ | zyp: yes sure, that would just provide an easy way to access the fields when inefficiency is not an issue and this could be based on a generic inject/extract functions (maybe renamed to write_field/read_field? set_field/get_field?) that could also be used by the user for better efficiency. | 07:32 |
| st-gourichon-fid | _florent_, hi and thanks for your comment. | 07:49 |
| st-gourichon-fid | hi zyp too. | 07:50 |
| st-gourichon-fid | So far I wrote some local code that reflects both your inputs. | 07:50 |
| st-gourichon-fid | Reading/writing the whole CSR is already provided by LiteX. Pondering a rename. Currently mycsrname_myfield_inject, could be mycsrname_set_myfield() mycsrname_write_myfield(). (Same consideration for extract/get/read.) | 07:53 |
| st-gourichon-fid | It works here for us at the moment. Makes very shot and readable client code. Will use it for a moment before offering a PR. | 07:58 |
| st-gourichon-fid | TL;DR: makes fields as easy to use as plain registers. | 07:59 |
| st-gourichon-fid | s/very shot/very short/ | 07:59 |
| *** KSmith has quit IRC | 08:16 | |
| st-gourichon-fid | Using CSRFields fails build AttributeError, here's a PR. https://github.com/enjoy-digital/litex/pull/673 | 08:54 |
| tpb | Title: Fix syntax error preventing to use CSRField. by fidergo-stephane-gourichon · Pull Request #673 · enjoy-digital/litex · GitHub (at github.com) | 08:54 |
| _florent_ | st-gourichon-fid: thanks, sure when you think you have something that would useful for others, feel free to create PR :), we could discuss the naming in the PR. | 10:15 |
| _florent_ | daveshah: ping? (just got your results with Alveo U250) | 10:19 |
| daveshah | pogn | 10:19 |
| daveshah | *pong | 10:19 |
| _florent_ | thanks for the test, i just got the XCU1525 working on my side (but with UDIMM) | 10:20 |
| _florent_ | the automatic Clk/Cmd scan still has difficulties in some cases | 10:21 |
| daveshah | that's useful to know | 10:21 |
| _florent_ | maybe you could try to force it with the command from the bios, 2s | 10:21 |
| _florent_ | you could use sdram_force_cmd_delay command with a delay between 0 and 511 | 10:22 |
| _florent_ | with steps of 50 for example | 10:23 |
| _florent_ | and then look at the write leveling data scan | 10:23 |
| _florent_ | to try to see a full cycle of ones on each module | 10:25 |
| _florent_ | if with this you are not able to get the last 3 modules working correctly, you could try to re-generate the bitstream with cmd_latency set to 0 here: https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/usddrphy.py#L31 | 10:26 |
| tpb | Title: litedram/usddrphy.py at master · enjoy-digital/litedram · GitHub (at github.com) | 10:26 |
| daveshah | no dice on sdram_force_cmd_delay based on a quick test. All I observe is that the first 4 bytes then start failing between 250 and 300, no value seems to make the last 4 work | 10:26 |
| daveshah | that's a good idea; if that doesn't work I will check the RCD config again | 10:27 |
| _florent_ | ah otherwise, before rebuilding a bitstream | 10:27 |
| _florent_ | it's now possible to write the MR registers from the bios | 10:27 |
| daveshah | oh nice | 10:27 |
| _florent_ | and i've found it to be useful when debugging | 10:27 |
| _florent_ | because it easily allow you to see latency related issues (for example by reducing cl/cwl by one cycle) | 10:28 |
| _florent_ | i created this tool: https://github.com/enjoy-digital/litedram/blob/master/bench/ddr4_mr_gen.py | 10:28 |
| tpb | Title: litedram/ddr4_mr_gen.py at master · enjoy-digital/litedram · GitHub (at github.com) | 10:28 |
| _florent_ | that generates the commands that can just be copy/paste to the bios | 10:29 |
| _florent_ | but that was only for ddr4/udimm | 10:29 |
| _florent_ | maybe you could tweak it for udimm | 10:30 |
| _florent_ | in your case for example, i would try to change cwl (+-1) and see if it improves the behavior of the last 3 modules | 10:30 |
| _florent_ | daveshah: ah just in case, if you use sdram_force_cmd_delay, you then need to do sdram_cal, doing a full reboot with reset this force | 10:34 |
| daveshah | yeah I was doing sdram_cal | 10:34 |
| daveshah | ah thanks for the tool | 10:34 |
| daveshah | _florent_: cmd_latency=0 works! | 10:57 |
| daveshah | https://www.irccloud.com/pastebin/BVziwS2c/ | 10:57 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 10:57 |
| daveshah | some of the calibration seems a bit dodgy, but memtest ultimately passes | 10:57 |
| _florent_ | daveshah: great! | 10:59 |
| _florent_ | the write leveling is indeed not optimal | 11:00 |
| _florent_ | can you try to use sdram_force_cmd_delay to shift it? | 11:00 |
| daveshah | it shifts it, but I can't find a single value that causes all to pass | 11:10 |
| _florent_ | ok, would you mind sharing the logs with various delay? | 11:17 |
| daveshah | I'll get that in 30 mins or so | 11:22 |
| daveshah | _florent_: https://gist.github.com/daveshah1/3d039adf1cc4c81179bf16d28b134fd9 | 11:40 |
| tpb | Title: Alveo U250 DDR4 init · GitHub (at gist.github.com) | 11:40 |
| daveshah | this is 0 to 500 in steps of 50 | 11:40 |
| _florent_ | thanks, i'm looking at this | 11:50 |
| _florent_ | daveshah: the best is around 400 where we see the beginning of the 0 to 1 transition for all modules except m4 | 11:57 |
| _florent_ | daveshah: otherwise you can try to increase the sys_clk_frequency | 11:58 |
| _florent_ | this will reduce the side of the ones window and could help | 11:58 |
| _florent_ | on the xcu1525 i tested up to 200MHz (i had problem at more, but with the compilation, will look at it) | 11:59 |
| daveshah | hmm, having trouble with the PLL config above 125MHz too | 12:07 |
| daveshah | 200MHz fails as do other common freqs inbetween | 12:07 |
| daveshah | ah, maybe I need to change the IDELAY reference too | 12:08 |
| _florent_ | yes, 400MHz for the idelay_clk_freq was fine with a sys_clk_freq of 200MHz | 12:21 |
| _florent_ | but i should change that and use a separate PLL for the idelay clk (that's already done in LiteDRAM generator IIRC) | 12:22 |
| daveshah | not happy at 200MHz system clk (and changing force_cmd_delay doesn't do much either) unfortunately - perhaps it needs cmd_latency back at 1? | 12:26 |
| daveshah | https://www.irccloud.com/pastebin/mIV2rcfS/ | 12:26 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 12:26 |
| _florent_ | daveshah: ah possible for cmd_latency, but m7 seems to no longer be responding during the write leveling | 12:31 |
| daveshah | I can get a 0/1 transition for m7 by changing force_cmd_delay although it doesn't actually find a delay | 12:32 |
| daveshah | e.g with force_cmd_delay at 100 `m7: |11111111110000000000001110| delay: -` | 12:33 |
| _florent_ | ah interesting, now that write latency can be calibrated, the write leveling could probably simplified a bit and just use the last transition | 12:37 |
| *** krickit has joined #litex | 14:36 | |
| krickit | Hi everyone, | 14:36 |
| st-gourichon-fid | Hi | 14:37 |
| krickit | I have to folder: gateware e software, but I didn't understand how to use them | 14:50 |
| krickit | two* | 14:50 |
| daveshah | gateware contains the generated Verilog and resultant build products, including the final bitstream | 14:51 |
| daveshah | software contains generated header files; makefiles and software build products | 14:51 |
| krickit | yes, i know this difference, but i can't generate bitstream directly because i have to add other circuit in my fpga ed i don't understand how to use software folder in my project. | 14:53 |
| krickit | Can you help me? | 14:53 |
| daveshah | You can probably ignore the software folder and use the top level verilog in the gateware folder; combined by the memory init files also in the gateware folder that contain the software in a format suitable for readmemh | 14:55 |
| daveshah | pointing your tool to the top level verilog in the gateware and any verilog dependencies (like the CPU verilog source, check the generated tcl or whatever file for a list of these) should be enough | 14:55 |
| krickit | oh thanks. So the memory init files are the "compilation" of software folder | 14:57 |
| daveshah | yeah | 14:58 |
| krickit | thank you so much, now it's all more clear | 14:59 |
| *** CarlFK has quit IRC | 16:16 | |
| *** CarlFK has joined #litex | 16:45 | |
| *** CarlFK has quit IRC | 17:55 | |
| *** CarlFK has joined #litex | 18:18 | |
| *** CarlFK has quit IRC | 19:13 | |
| *** _franck_5 has joined #litex | 19:36 | |
| *** _franck_ has quit IRC | 19:36 | |
| *** _franck_5 is now known as _franck_ | 19:36 | |
| *** KSmith has joined #litex | 20:12 | |
| *** kgugala_ has quit IRC | 21:30 | |
| *** kgugala has joined #litex | 21:30 | |
| *** _franck_ has quit IRC | 22:04 | |
| *** _franck_ has joined #litex | 22:05 | |
| *** krickit has quit IRC | 22:24 | |
| *** feldim2425 has quit IRC | 22:58 | |
| *** feldim2425 has joined #litex | 22:59 | |
| *** awordnot has quit IRC | 23:21 | |
| *** awordnot has joined #litex | 23:22 | |
| *** vup has quit IRC | 23:25 | |
| *** vup has joined #litex | 23:25 | |
| *** lf_ has joined #litex | 23:50 | |
| *** lf has quit IRC | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!