| *** tpb has joined #litex | 00:00 | |
| *** futarisIRCcloud has quit IRC | 06:14 | |
| _florent_ | Hi daveshah: i don't have the same results you have for the DDR3 calibration on the Versa ECP5: | 08:23 |
|---|---|---|
| _florent_ | https://hastebin.com/uxefibakun.rb | 08:23 |
| _florent_ | do you still have the bistream you tested so that i test on my board? | 08:24 |
| daveshah | Sorry not at home for the next few days so don't have that bitstream | 08:25 |
| _florent_ | i'm going to investigate, but that would be interesting to see if it's a variation between the boards | 08:25 |
| daveshah | Surprising to see such a variation at a fairly low frequency | 08:26 |
| _florent_ | When you was testing the SoC with DDR3/Ethernet, you were using the ethernet SoC in versa_ecp5 and just removing the integrated_main_ram_size=0x800? | 08:28 |
| daveshah | Yup | 08:28 |
| daveshah | https://github.com/daveshah1/versa_ecp5_dram/commit/81813a8f7853781ee8c6b58e70f5c246cd5164ff | 08:29 |
| tpb | Title: Integrated DDR3 and Ethernet SoC · daveshah1/versa_ecp5_dram@81813a8 · GitHub (at github.com) | 08:29 |
| _florent_ | thanks, i'll do a test with that | 08:33 |
| *** cedric_ has joined #litex | 10:04 | |
| cedric_ | Bonjour @_florent_, j'ai une petite question concernant les adresses de registre pour la communication via UART. Mon AES-128 est fonctionnel, et j'aimerais maintenant l'interfacer avec l'UART afin d'envoyer et recevoir depuis un terminal Litex les clairs et chiffrés. En exécutant "python3 base.py", cela génère le fichier "csr.h" qui permet d'avoir toutes les adresses et méthodes qui permettent d'allumer les leds, lire les valeurs | 10:15 |
| cedric_ | Je me demande donc si je dois modifier directement ce fichier pour y intégrer des méthodes me permettant de stocker les valeurs entrantes dans des registres, et surtout quelles sont les adresses accessibles ? | 10:16 |
| _florent_ | Hi cedric_, i'm answering in english so that others can follow. So the csr.h define all the registers but also the access functions. | 10:20 |
| _florent_ | the CSR_XXYY_ADDR are the addresses of the registers | 10:21 |
| _florent_ | the CSR_XXYY_SIZE are the size of these registers, 4 with a csr_data_width=8 --> 32 bits | 10:21 |
| _florent_ | since the csr.h is automatically generated, i would not recommend touching it | 10:22 |
| cedric_ | What i didn't manage to know is where and when is it generated ? | 10:22 |
| _florent_ | it's generated when building the SoC (builder.build()) | 10:24 |
| _florent_ | are you going to use a CPU for your system for the UART communication, or do you want to use a uart bridge? (Host <--> UART <--> Wishbone <--> your peripherals) | 10:26 |
| _florent_ | because if it's the latter, you can also generate a .csv file with all the registers of the design | 10:27 |
| cedric_ | What I wanted to do is to write my plaintext in a register, the AES module would read this register, and then write the ciphertext in another register, and read this register with the UART | 10:30 |
| cedric_ | Not sure if it's very clear... | 10:30 |
| _florent_ | ok i see | 10:32 |
| cedric_ | does the line "user_leds = Cat(*[platform.request("user_led", i) for i in range(16)])" has the effect to declare the registers of the Led values ? | 10:32 |
| _florent_ | it's just to concatenate 1 bits signals | 10:33 |
| _florent_ | for your application, you will just need to add CSR register to your AES module: | 10:34 |
| _florent_ | plaintext as CSRStorage | 10:34 |
| _florent_ | ciphertext as CSRStatus | 10:34 |
| _florent_ | and then start/done CSR | 10:34 |
| cedric_ | ok | 10:34 |
| _florent_ | you could reuse the uart bridge to test it: | 10:34 |
| _florent_ | write the plaintext register with the host | 10:35 |
| _florent_ | then write the start register | 10:35 |
| _florent_ | then poll the done register while waiting the AES to do the computation | 10:35 |
| _florent_ | and then read the ciphertex register | 10:36 |
| _florent_ | that would be a good first test | 10:36 |
| cedric_ | I keep you informed ! | 10:37 |
| _florent_ | you can use https://github.com/enjoy-digital/fpga_101/tree/master/lab003 to see how to do it | 10:37 |
| tpb | Title: fpga_101/lab003 at master · enjoy-digital/fpga_101 · GitHub (at github.com) | 10:38 |
| *** futarisIRCcloud has joined #litex | 10:49 | |
| *** cedric_ has quit IRC | 11:11 | |
| _florent_ | daveshah: i did some cleanup/changes, it's now working fine: https://hastebin.com/uvucelexic.rb | 12:42 |
| keesj | nice | 12:54 |
| keesj | what is the SDRAM now under software control v.s. SDRAM now under hardware control part? | 12:59 |
| _florent_ | keesj: during the initalization, the CPU controls the DFI interface to do the SDRAM initialization | 13:16 |
| somlo | _florent_: it's litex commit 3dd529e4 (modified #defines in software/bios/sdram.c to accomodate ECP5) that breaks memtest on nexys4ddr for me | 15:17 |
| *** futarisIRCcloud has quit IRC | 15:19 | |
| somlo | _florent_: for the nexys4ddr, generated/sdram_phy.h contains "#define DFII_NPHASES 2"; I can already see how in software/bios/sdram.c, ERR_DDRPHY_BITSLIP will now end up being 4 (not 8, which is the old value), and NBMODULES ends up divided by 4 not 2 as before. I think the new nexys4ddr DFII_NPHASES generated define should be 4 not 2 (if we're to keep 3dd529e4 in its current form). | 15:28 |
| _florent_ | somlo: ah ok thanks, i was doing some tests but didn't find yet the commit | 15:29 |
| somlo | BTW, what part of the code generates the headers in "generated" ? | 15:29 |
| somlo | and from what template? | 15:29 |
| _florent_ | sdram initialization is generated by: https://github.com/enjoy-digital/litedram/blob/master/litedram/sdram_init.py | 15:30 |
| tpb | Title: litedram/sdram_init.py at master · enjoy-digital/litedram · GitHub (at github.com) | 15:30 |
| somlo | thanks -- I don't feel qualified to patch it at my current level of understanding, but I need to study it orthogonally to this bug :) | 15:30 |
| _florent_ | the csr.h is generated by: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/cpu_interface.py | 15:31 |
| tpb | Title: litex/cpu_interface.py at master · enjoy-digital/litex · GitHub (at github.com) | 15:31 |
| _florent_ | that's fine, my nexys4ddr is connected, i'll look at that, thanks for finding the commit | 15:31 |
| *** cedric_ has joined #litex | 15:46 | |
| somlo | _florent_: LOL, after skimming through sdram_init.py, it doesn't look like DFII_NPHASES is negotiable :) | 15:59 |
| _florent_ | somlo: no, it's related to the dram and phy configuration | 16:00 |
| somlo | which leaves the option of changing software/bios/sdram.c to "#define ERR_DDRPHY_BITSLIP DFII_NPHASES*4" and "#define NBMODULES DFII_PIX_DATA_SIZE*DFII_NPHASES/4" (unless of course *that* conflicts with anything elsewhere in the codebase) | 16:00 |
| _florent_ | i'm having difficulties reproducing the issue | 16:02 |
| _florent_ | can you give me the commit you are using for litedram? | 16:02 |
| somlo | c65ff97 | 16:02 |
| *** cedric_ has quit IRC | 16:04 | |
| somlo | which I believe is the current master | 16:07 |
| somlo | the entire set of steps I am using is in litex issue #151 | 16:08 |
| somlo | _florent_: I see the "# if defined (USDDRPHY)" block software/bios/sdram.c has further changes beyond 3dd529e4 | 16:26 |
| somlo | looking at the current master, which branch is nexys4ddr falling through ? USDDRPHY, or the default? | 16:27 |
| somlo | * the default #else I mean ? | 16:27 |
| somlo | https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/sdram.c#L217 | 16:28 |
| tpb | Title: litex/sdram.c at master · enjoy-digital/litex · GitHub (at github.com) | 16:28 |
| somlo | because, in the last commit that works for me (2fd6d0e7) ERR_DDRPHY_BITSLIP was hardcoded to 8, and NBMODULES was DFII_PIX_DATA_SIZE/2 | 16:30 |
| somlo | right now, that's clearly NOT the same values that end up being computed based on DFII_NPHASES, which is 2 | 16:31 |
| somlo | _florent_: this: https://pastebin.com/Q5jzuei9 applied on top of current litex master (7de1fe51) fixes it for me (with current master litedram, unpatched) | 16:52 |
| tpb | Title: [Diff] diff --git a/litex/soc/software/bios/sdram.c b/litex/soc/software/bios/sdram.c - Pastebin.com (at pastebin.com) | 16:52 |
| somlo | of course this is probably not a general fix, but it ends up calculating the same #define values as pre-3dd529e4 for nexys4ddr, and gets the memory test on it to pass for me | 16:54 |
| _florent_ | somlo: thanks, i reproduce your result, i'm testing a generic fix | 16:58 |
| _florent_ | somlo: can you test with: https://github.com/enjoy-digital/litex/commit/317dba831492474cde30b26a4324b3b684debcda | 17:11 |
| tpb | Title: software/bios/sdram: use specific ERR_DDRPHY_BITSLIP/NMODULES computa… · enjoy-digital/litex@317dba8 · GitHub (at github.com) | 17:11 |
| _florent_ | N | 17:11 |
| _florent_ | ? | 17:11 |
| somlo | _florent_: just got back from lunch, testing now :) | 17:55 |
| somlo | _florent_: 317dba83 does indeed fix the issue -- thanks! | 18:24 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!