UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor breaking.rad
Visitor
1,256 Views
Registered: ‎01-25-2019

Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

How are the ODT settings for the DRAM mode register writes from the MIG 2.2 SDRAM controller adjusted seperately by the user?

For DDR4 SDRAM, during calibration/configuration the MIG controller writes values to the mode registers in the DRAMs.  Specifically, Mode Register 1 (MR1) bits 10,9,8 represent the Nominal ODT (Rtt_nom) value for the data bus termination setting for the DRAM.  This value is written, from the controller, to the DRAM device during startup with Mode Register Write commands to the DRAMs. (Note: ODI, Dynamic ODT, Parked ODT and all other DRAM parameters are of interst also.)

Question:  How are the values for the Mode Registers manually/user selected (either in the Vivado GUI or subsequent .tcl script or other custom .csv files etc.) so that the memory controller programs the manually/user selected values into the DDR DRAM device during the mode register write command?

PG150 states "Memory IP sets the most ideal ODT setting".  Is that implying that the ODT settings are ONLY set by the memory IP and that the user has no control of the setting?  (other than specifying the DRAM type and configuration)

 

PG150Note15.JPGFrom PG150, page 591, "UltraScale Architecture-Based FPGAs Memory IP v1.4"

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
897 Views
Registered: ‎11-28-2016

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

Hello @breaking.rad,

The reason you're seeing this behavior is because you're using an Out of Context flow for the design.  Here when you generate output products the IP is immediately synthesized with the current settings and those are the ones you'll see in the netlist simulation and implemented design.  When you modified the ddr4_0_0_ddr4.sv file the behavior simulation results changed but the design in hardware will have the default value.

There are two ways to get around this.  The first is to use the "Global" option when generating output products.  Here you'll select "Global" when generating output products, you'll modify the file, and then run through synthesis and implementation.  To get a netlist you'll issue a 'write_verilog' command after synthesis.

The other option is to "Skip" output product generation and then manually issue the commands to run an Out of Context flow but modify the IP output products after one of the steps.  When you generate output products with OOC selected you'll see a set of commands that are issued in the TCL console.  Here you'll issue a few commands to get the IP output products, then modify the ddr4_0_0_ddr4.sv file, and then run synthesis:

  • Clear and disable the IP cache in the Project Manager -> Settings -> IP
  • Issue this TCL command:
    • generate_target all [get_files  /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci]
  • Edit the ddr4_0_0_ddr4.sv file outside of Vivado
  • Issue these TCL commands:
    • export_ip_user_files -of_objects [get_files /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci] -no_script -sync -force -quiet
    • create_ip_run [get_files -of_objects [get_fileset sources_1] /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci]
    • launch_runs -jobs 20 ddr4_0_synth_1
    • export_simulation -of_objects [get_files /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci] -directory /path/project_1/project_1.ip_user_files/sim_scripts -ip_user_files_dir /path/project_1/project_1.ip_user_files -ipstatic_source_dir /path/project_1/project_1.ip_user_files/ipstatic -lib_map_path [list {modelsim=path/project_1/project_1.cache/compile_simlib/modelsim} {questa=/path/project_1/project_1.cache/compile_simlib/questa} {ies=/path/project_1/project_1.cache/compile_simlib/ies} {xcelium=/path/project_1/project_1.cache/compile_simlib/xcelium} {vcs=/path/project_1/project_1.cache/compile_simlib/vcs} {riviera=/path/project_1/project_1.cache/compile_simlib/riviera}] -use_ip_compiled_libs -force -quiet
  • Update the paths and file names as necessary
  • If you have any issue just look at the TCL command that are run in a normal OOC flow output product generation and then isolate each one so you can modify the IP output products before synthesis
8 Replies
Voyager
Voyager
1,222 Views
Registered: ‎02-01-2013

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

 

DDR ODT settings are rather fixed in the newer MIGs. Older versions gave the user more flexibility/rope.

In the MIG GUI, there's a link you can follow that (somewhat) explains the fields of the "Parts Data File" used by the MIG to configure the memory controller to interact with a particular memory device.

2019-01-25_17-28-01.jpg

If you follow the link, you'll find the "documentation" showing that the permissible ODT value range is quite limited:

2019-01-25_17-39-48.jpg

I am at this time unsure as to how the MIG computes other ODT values that may need to be set in the DDR devices via Mode Register writes.

-Joe G.

 

Visitor breaking.rad
Visitor
1,207 Views
Registered: ‎01-25-2019

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

Thanks Joe,

I do have a custom .csv file for the configuration we're using (it's validated by the tool) but nowhere in that file can you directly adjust the ODT settings.   The 63642 Answer Record is curious because it shows only RZQ/6.  Note: RTT is now removed in 2018.3.  However, I can see from simulation (by observing the Mode Register Write commands to the DRAMs) the core is programming the DRAMs to RZQ/1 (I have a two slot UDIMM configuration see below).  Evidently the RTT range has changed and been removed from user control. 
Of course the DRAMs support a much wider range for RTT shown here:

000 = RTT(NOM) disabled
001 = RZQ/4 (60 ohm)
010 = RZQ/2 (120 ohm)
011 = RZQ/6 (40 ohm)
100 = RZQ/1 (240 ohm)
101 = RZQ/5 (48 ohm)
110 = RZQ/3 (80 ohm)
111 = RZQ/7 (34 ohm)


 Here's the .csv custom setting I'm using:

Part type,Part name,Rank,StackHeight,CA Mirror,Data mask,Address width,Row width,Column width,Bank width,Bank group width,CS width,CKE width,ODT width,CK width,Memory speed grade,Memory density,Component density,Memory device width,Memory component width,Data bits per strobe,IO Voltages,Data widths,Min period,Max period,tCKE,tFAW,tFAW_dlr,tMRD,tRAS,tRCD,tREFI,tRFC,tRFC_dlr,tRP,tRRD_S,tRRD_L,tRRD_dlr,tRTP,tWR,tWTR_S,tWTR_L,tXPR,tZQCS,tZQINIT,tCCD_3ds,cas latency,cas write latency,burst length
UDIMMs,DDR4_72r2,2,1,1,1,17,16,10,2,2,2,2,2,2,83E,16GB,8Gb,72,8,8,1.2V,72,833,1600,5000 ps,21000 ps,0,8 tck,32000 ps,13320 ps,3900000 ps,350000 ps,100000 ps,13320 ps,3300 ps,4900 ps,4 tck,7500 ps,15000 ps,2500 ps,7500 ps,360 ns,128 tck,1024 tck,0,16,16,8

In our situation we have a dual slot UDIMM configuration BUT we are soldering the parts directly down on the board.  So meeting the guidelines in "UltraScale Architecture PCB Design and Pin Planning User Guide (UG583)" becomes very difficult since that guide assumes true UDIMM routing and a connector.

I am suspicious that what I want to do [manually adjust ODT settings] can't be done.  The MIG just 'does it for you' based on your .csv input.   The documentation doesn't explicilty tell you what you can't do, so I'm left to wonder.

0 Kudos
Voyager
Voyager
1,193 Views
Registered: ‎02-01-2013

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution


My apologies; I was too subtle in my earlier post: yes, Xilinx now limits the selection of the ODT setting to a single value, and they've even removed the setting from the Parts Data File--ostensibly since they won't let you change it.

I can't explain the discrepancy you've witnessed regarding the ODT setting during simulation. But I do recognize the tool's possible reason for an oversight, there: the ODT setting doesn't matter in digital simulation.

Xilinx provides support for a handful of different (but overall, simple) DDR configurations, and those configurations satisfy a great number of customers' needs. If you're planning to venture out, using an exotic custom configuration, you've got a lot of miles to row. Mimicking DIMM routing on a PCB that's thick enough to support a large Xilinx FPGA will be some feat. Best of luck.

-Joe G.

 

Moderator
Moderator
1,103 Views
Registered: ‎11-28-2016

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

Hello @breaking.rad,

The MIG IP automatically generates all the memory and FPGA drive/termination settings based on your FPGA configuration and memory topology.  These are the supported, tested, and characterized values that are guarnated to work for that application when your board was laid out following the guidelines in UG583 (a link is in my signature).  Modifying the default settings are not supported by Xilinx and operation is not guranateed if you choose to do it.  If you dig in to the design files you can see where all of these are set.

Visitor breaking.rad
Visitor
1,087 Views
Registered: ‎01-25-2019

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

ryana,

Thank you for clarifying that it is possible to modify the memory controller settings if one 'digs in to the design files'. Understanding that modifications are not supported by Xilinx.  I may have found at least one soution to doing so but If you can provide any guidance on:

"How are the values for the Mode Registers manually/user selected (either in the Vivado GUI or subsequent .tcl script or other custom .csv files etc.) so that the memory controller programs the manually/user selected values into the DDR DRAM device during the mode register write command?"  (MIG 2.2, DDR4, 2018.3)

I would be very grateful.

0 Kudos
Moderator
Moderator
1,066 Views
Registered: ‎11-28-2016

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

Hello @breaking.rad,

You can change the FPGA driver and ODT in the I/O Ports tab with a synthesized or implemented design or you can manually change them in the XDC.  For the DDR4 ODT settings you'll have to manually change the Mode Register settings that are specified in the ddr4_0_ddr4.sv file in this path (simple design) /project/project.srcs/sources_1/ip/ddr4_0/rtl/ip_top/ddr4_0_ddr4.sv. If you regenerate the IP then the changes will be overwritten.  Overall I would only take approach for debug purposes and would review your board layout against the rules in UG583.

0 Kudos
Visitor breaking.rad
Visitor
947 Views
Registered: ‎01-25-2019

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

@ryana

Digging in to the design files, the mode register settings are in the "ddr4_0_0_ddr4.sv" file.  I did 'Copy All Files Into Project' and then outside of Vivado, I modified line 353 to change the value of Mode Register 1 write to the DDR during initialization.  The original line is commented out and the modified line follows.

//  parameter         MR1                       = 13'b0010000000001,
    parameter         MR1                       = 13'b0001100000001,

This modification worked as expected when I ran a 'Behavioral Simulation' using Vivado and it wrote the desired value to the DDR1 mode registers.
 However, when I proceeded on through synthesis and implementation and subsequently ran a 'Post-Implementation Timing Simulation' I found the default values were programmed instead of the new value - per the simulation waveform.  Upon inspection of the generated simulation netlist "ddr4_0_0_sim_netlist.v" I can see that the original (default) value "(* MR1 = "13'b0010000000001" *)"  appears in the netlist. 

I was hoping to see the post implementation netlist simulate with the modified value.  At this point, I'm unsure what the actual bitstream will do.  Can you help explain why the implementaion netlist did not pick up the modified value in the IP source?  And can you suggest a better(proper) way of modifiying the IP source to affect this change?

 

0 Kudos
Moderator
Moderator
898 Views
Registered: ‎11-28-2016

Re: Memory IP, DDR MIG 2.2, Manual settings for OnDieTermination, Nominal ODT and ODI, DDR4, Vivado 2018.3

Jump to solution

Hello @breaking.rad,

The reason you're seeing this behavior is because you're using an Out of Context flow for the design.  Here when you generate output products the IP is immediately synthesized with the current settings and those are the ones you'll see in the netlist simulation and implemented design.  When you modified the ddr4_0_0_ddr4.sv file the behavior simulation results changed but the design in hardware will have the default value.

There are two ways to get around this.  The first is to use the "Global" option when generating output products.  Here you'll select "Global" when generating output products, you'll modify the file, and then run through synthesis and implementation.  To get a netlist you'll issue a 'write_verilog' command after synthesis.

The other option is to "Skip" output product generation and then manually issue the commands to run an Out of Context flow but modify the IP output products after one of the steps.  When you generate output products with OOC selected you'll see a set of commands that are issued in the TCL console.  Here you'll issue a few commands to get the IP output products, then modify the ddr4_0_0_ddr4.sv file, and then run synthesis:

  • Clear and disable the IP cache in the Project Manager -> Settings -> IP
  • Issue this TCL command:
    • generate_target all [get_files  /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci]
  • Edit the ddr4_0_0_ddr4.sv file outside of Vivado
  • Issue these TCL commands:
    • export_ip_user_files -of_objects [get_files /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci] -no_script -sync -force -quiet
    • create_ip_run [get_files -of_objects [get_fileset sources_1] /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci]
    • launch_runs -jobs 20 ddr4_0_synth_1
    • export_simulation -of_objects [get_files /path/project_1/project_1.srcs/sources_1/ip/ddr4_0/ddr4_0.xci] -directory /path/project_1/project_1.ip_user_files/sim_scripts -ip_user_files_dir /path/project_1/project_1.ip_user_files -ipstatic_source_dir /path/project_1/project_1.ip_user_files/ipstatic -lib_map_path [list {modelsim=path/project_1/project_1.cache/compile_simlib/modelsim} {questa=/path/project_1/project_1.cache/compile_simlib/questa} {ies=/path/project_1/project_1.cache/compile_simlib/ies} {xcelium=/path/project_1/project_1.cache/compile_simlib/xcelium} {vcs=/path/project_1/project_1.cache/compile_simlib/vcs} {riviera=/path/project_1/project_1.cache/compile_simlib/riviera}] -use_ip_compiled_libs -force -quiet
  • Update the paths and file names as necessary
  • If you have any issue just look at the TCL command that are run in a normal OOC flow output product generation and then isolate each one so you can modify the IP output products before synthesis