New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limited support for Distributed Memory / LUTRAM #20
Comments
Very good, thanks! |
Added support for RAM128X1S and RAM256X1S though not sufficiently tested. I was able to build litex-ddr-kc705 after latest changes. However, I am now running into DDR memtest issues it seems: https://gist.github.com/hansemro/5f48f4098e59f9db2e34ae25cb0b6ecd |
@hansemro Wow, that was quick! We might want to write some basic tests here: |
@hansfbaier Sounds good. I'll try to write some tests soon. DDR issue could be totally unrelated to this. |
@hansemro Yes, very likely your code works. I never got 8 modules working nice with OpenXC7. At some point the timing just falls apart, because of congestion, I suppose. See my comment on your gist. |
Rebased experimental branch on 8120acd (current stable-backports) |
@hansemro great, thanks |
Fixed up RAM32X1D not creating RAMD32 instances (was creating RAMD64 instances previously) and made sure RAM32X1S is handled in pack_dram (forgot this one apparently). |
Made initial tests: https://github.com/hansemro/primitive-tests/commits/lutram-tests/
Notably nextpnr-xilinx hangs with RAM256X1S. Seems #10 made this observation months ago. I'll try to spend some time debugging this. |
RAM256X1S and RAM256X1D were not handled correctly since their address pins are in an array A[N:0] rather than specified individually (A0, A1, A2, ... ). I'll need to validate every transform rule anyway... |
@hansemro I pushed an MMCM-fix to stable-backports. The MMCM should work now, if you have time to try. |
@hansfbaier Thanks for the heads up. I will get to it at some point. I decided it is better for me to fix dual-port LUTRAMs before moving forward, because everything is broken (for at least xc7, not sure about ultrascale).
|
Yes definitely, that is more important. Thanks for working on this. |
I misspoke since I was testing RAM256X1D (thought I was testing RAM256X1S) which does not fit in xc7 anyhow. Still, yosys should not allow unsupported LUTRAMs to be synthesized! |
@hansemro How are things going? Have you been able to test the changes? |
MMCM is confirmed working with multiple clock outputs on KC705 though with a BUFG on all clock outputs. fasm2frames would throw segment DB errors if I didn't have them. Test branch: https://github.com/hansemro/primitive-tests/commits/mmcm-blinky-kc705-db-error/ Interestingly, the first clock output didn't require me to place BUFG buffer, though it should probably have one.
Things were going well until I had to handle each LUTRAM as an edge case. Initially, I was less bothered to write things down, but now I feel it is appropriate to actually spend time documenting the port/parameter transformations for all cells (including ultrascale-only cells). I intend to resume work on validation and get xc7 cells covered. Anyhow, it turns out I made some incorrect assumptions about some things. Here are some TODOs:
Will elaborate further with a follow-up post on LUTRAM transformations to RAMS/RAMD primitive cells to LUT5/LUT6 BELs in more detail. |
Yes, I had similar observations. |
Thanks for the update! |
Naming Notation:I'll define the following name notation to fold port/parameter names:
LUTRAM Cell Table:Additional notes:
|
XC7 LUTRAM to LUTRAM Primitive Transformations:LUTRAMs are broken down to primitive cell(s) that will eventually map to SLICEM LUT_OR_MEM6/LUT_OR_MEM5 BEL site(s) once placed. Convention:
RAM32X1S -> 1x RAMS32Cell Rules:
Parameter Rules:
Port Rules:
RAM32X1D -> 2x RAMD32Cell Rules:
Parameter Rules:
Port Rules:
RAM32M -> 2x RAMS32 + 6x RAMD32Cell Rules:
Parameter Rules:
Port Rules:
RAM64X1S -> RAMS64ECell Rules:
Parameter Rules:
Port Rules:
RAM64X1D -> 2x RAMD64ECell Rules:
Parameter Rules:
Port Rules:
RAM64M -> 4x RAMD64ECell Rules:
Parameter Rules:
Port Rules:
RAM128X1S -> 2x RAMS64ECell Rules:
Parameter Rules:
Port Rules:
RAM128X1D -> 4x RAMD64ECell Rules:
Parameter Rules:
Port Rules:
RAM256X1S -> 4x RAMS64ECell Rules:
Parameter Rules:
Port Rules:
|
LUTRAM Primitive to BEL Transformations:Additional notes:
RAMD64E -> LUT_OR_MEM6 BEL
RAMS64E -> LUT_OR_MEM6 BEL
RAMD32 -> LUT_OR_MEM6 BEL
RAMD32 -> LUT_OR_MEM5 BEL
RAMS32 -> LUT_OR_MEM6 BEL
RAMS32 -> LUT_OR_MEM5 BEL
|
Thanks for the effort! I am looking forward to what you will come up with! |
Issue: nextpnr checks INIT{A:D} instead of INIT_{A:D} parameters for RAM32M/RAM64MWhile working on an INIT parameter test, I noticed that the INIT parameters for RAM32M/RAM64M were not being set with correct values in the FASM result. nextpnr-xilinx/xilinx/pack_dram.cc Lines 455 to 469 in 1c57f51
Merely adding underscores does not immediately solve the issue, so I will need to look more into this later. WIP INIT Parameter Test: https://github.com/hansemro/primitive-tests/tree/xc7-lutram-tests/lutram-tests/init-test |
This should be fixed in this branch: https://github.com/hansemro/nextpnr-xilinx/tree/fix-ram32m-ram64m-init However, I am noticing some discrepancies compared to Vivado that I will need to verify. Notice how the upper and lower 32-bits of the ?LUT.INIT pattern are swapped. RAM32M NextPNR fasm result:
RAM32M Vivado bit2fasm result:
|
Issue: nextpnr does nothing with
|
Great work! |
Issue Description
memory_libmap
pass in Yosys 0.18 and newer would synthesize LUTRAMs unsupported by nextpnr including:Part of the issue stems from nextpnr not fully supporting all LUTRAMs in the Distributed RAM packer in
xilinx/pack_dram.cc
.Resolving this should also address openXC7/demo-projects#6.
Tasks/Status
TODO: rewrite tasks
Development Branches
References
See 018-clb-ram minitest. Build and view design checkpoint in Vivado.
https://f4pga.readthedocs.io/projects/prjxray/en/latest/architecture/dram_configuration.html
https://docs.xilinx.com/v/u/en-US/ug474_7Series_CLB
https://docs.xilinx.com/v/u/en-US/ug574-ultrascale-clb
https://docs.xilinx.com/r/en-US/ug953-vivado-7series-libraries
https://docs.xilinx.com/r/en-US/ug974-vivado-ultrascale-libraries
https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/7series_hdl.pdf
https://docs.amd.com/v/u/en-US/7series_hdl
https://github.com/Xilinx/XilinxUnisimLibrary/tree/master/verilog/src/unisims
The text was updated successfully, but these errors were encountered: