Tuesday, 2019-03-05

*** tpb has joined #litex00:00
*** futarisIRCcloud has quit IRC06: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.rb08:23
_florent_do you still have the bistream you tested so that i test on my board?08:24
daveshahSorry not at home for the next few days so don't have that bitstream08:25
_florent_i'm going to investigate, but that would be interesting to see if it's a variation between the boards08:25
daveshahSurprising to see such a variation at a fairly low frequency08: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
daveshahYup08:28
daveshahhttps://github.com/daveshah1/versa_ecp5_dram/commit/81813a8f7853781ee8c6b58e70f5c246cd5164ff08:29
tpbTitle: Integrated DDR3 and Ethernet SoC · daveshah1/[email protected] · GitHub (at github.com)08:29
_florent_thanks, i'll do a test with that08:33
*** cedric_ has joined #litex10: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 valeurs10: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 registers10:21
_florent_the CSR_XXYY_SIZE are the size of these registers, 4 with a csr_data_width=8 --> 32 bits10:21
_florent_since the csr.h is automatically generated, i would not recommend touching it10: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 design10: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 UART10:30
cedric_Not sure if it's very clear...10:30
_florent_ok i see10: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 signals10:33
_florent_for your application, you will just need to add CSR register to your AES module:10:34
_florent_plaintext as CSRStorage10:34
_florent_ciphertext as CSRStatus10:34
_florent_and then start/done CSR10:34
cedric_ok10:34
_florent_you could reuse the uart bridge to test it:10:34
_florent_write the plaintext register with the host10:35
_florent_then write the start register10:35
_florent_then poll the done register while waiting the AES to do the computation10:35
_florent_and then read the ciphertex register10:36
_florent_that would be a good first test10: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 it10:37
tpbTitle: fpga_101/lab003 at master · enjoy-digital/fpga_101 · GitHub (at github.com)10:38
*** futarisIRCcloud has joined #litex10:49
*** cedric_ has quit IRC11:11
_florent_daveshah: i did some cleanup/changes, it's now working fine: https://hastebin.com/uvucelexic.rb12:42
keesjnice12:54
keesjwhat 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 initialization13:16
somlo_florent_: it's litex commit 3dd529e4 (modified #defines in software/bios/sdram.c to accomodate ECP5) that breaks memtest on nexys4ddr for me15:17
*** futarisIRCcloud has quit IRC15: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 commit15:29
somloBTW, what part of the code generates the headers in "generated" ?15:29
somloand from what template?15:29
_florent_sdram initialization is generated by: https://github.com/enjoy-digital/litedram/blob/master/litedram/sdram_init.py15:30
tpbTitle: litedram/sdram_init.py at master · enjoy-digital/litedram · GitHub (at github.com)15:30
somlothanks -- 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.py15:31
tpbTitle: 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 commit15:31
*** cedric_ has joined #litex15: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 configuration16:00
somlowhich 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 issue16:02
_florent_can you give me the commit you are using for litedram?16:02
somloc65ff9716:02
*** cedric_ has quit IRC16:04
somlowhich I believe is the current master16:07
somlothe entire set of steps I am using is in litex issue #15116:08
somlo_florent_: I see the "# if defined (USDDRPHY)" block software/bios/sdram.c has further changes beyond 3dd529e416:26
somlolooking at the current master, which branch is nexys4ddr falling through ? USDDRPHY, or the default?16:27
somlo* the default #else I mean ?16:27
somlohttps://github.com/enjoy-digital/litex/blob/master/litex/soc/software/bios/sdram.c#L21716:28
tpbTitle: litex/sdram.c at master · enjoy-digital/litex · GitHub (at github.com)16:28
somlobecause, in the last commit that works for me (2fd6d0e7) ERR_DDRPHY_BITSLIP was hardcoded to 8, and NBMODULES was DFII_PIX_DATA_SIZE/216:30
somloright now, that's clearly NOT the same values that end up being computed based on DFII_NPHASES, which is 216: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
tpbTitle: [Diff] diff --git a/litex/soc/software/bios/sdram.c b/litex/soc/software/bios/sdram.c - Pastebin.com (at pastebin.com)16:52
somloof 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 me16:54
_florent_somlo: thanks, i reproduce your result, i'm testing a generic fix16:58
_florent_somlo: can you test with: https://github.com/enjoy-digital/litex/commit/317dba831492474cde30b26a4324b3b684debcda17:11
tpbTitle: software/bios/sdram: use specific ERR_DDRPHY_BITSLIP/NMODULES computa… · enjoy-digital/[email protected] · GitHub (at github.com)17:11
_florent_N17: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!