deploying OpenPiton to dev board with ddr4

334 views
Skip to first unread message

Jiangbin Yuan

unread,
May 27, 2017, 7:52:53 AM5/27/17
to OpenPiton Discussion
Hi, 
Is there anyone trying to deploy OpenPiton to a dev board with ddr4, any hints on using the ddr4 memory?  

jbalkind

unread,
May 31, 2017, 5:33:26 PM5/31/17
to OpenPiton Discussion
We at Princeton don't have any boards with DDR4 yet so we haven't given it a go. Hopefully someone else will have given it a try. I would hope that the Xilinx memory interface generator hasn't changed much from DDR3 to DDR4.

Jiangbin Yuan

unread,
Jul 17, 2017, 8:12:10 AM7/17/17
to OpenPiton Discussion

Hi, jbalkind, currently I want to make use of the ddr4 device on my dev board via the Xilinx MIG user interface. now I think I have found the file needed to be edited which is the pkt_trans_dp_wide.v. My QUESTION is: In your experience of implementating the ddr3 user interface, are there any other files I should edit  to let the system run? p.s.   I found the mig user interface little changes from ddr3 to ddr4.
 
Thank you for reply~.
sincerely, Jiangbin Yuan

jbalkind

unread,
Jul 17, 2017, 2:20:32 PM7/17/17
to OpenPiton Discussion
Hi Jiangbin,

You found the right file (apologies for the other unnecessary ones if they were confusing). I think this should be the only file, though Alexey might correct me. The mig also didn't change much in coming to ddr3 so I'm not too surprised it's the same. I expect you shouldn't really have to change much as a result.

Out of interest, which board are you using for development?

Thanks,
Jon

Jiangbin Yuan

unread,
Jul 19, 2017, 3:53:14 AM7/19/17
to OpenPiton Discussion

Hi jbalkind, My dev board is Xilinx VCU118.


And now after generating the ddr4 MIG IP core, and wiring it onto the project, another problem come out. Using Vivado 2016.4 doing the “Synthesis” step is OK, but when implementing the project, “Opt Design” error occurred as the picture below shows


The error msg is "[Mig 66-99] Memory Core Error - [et/u_ddr4_0] Cascaded MMCM/PLL (user MMCM driving memory IP MMCM or user PLL driving memory IP MMCM) can be supported only for lower speed because cascaded structure jitter will be high. System clock port sys_clk_n is connected to top level via MMCM or PLL primitive which is not supported. "

it says that cascaded MMCM/PLL is not supported in high speed device, and I searched the Xilinx documentation and the Internet and found pg150 is about mem IP cores. I read the part for ddr4 ip core clock, but still don’t know how to set its clock souce.  so please help me solve the problem.

for convenience, the attached file is the part of the pg150 file descriping ddr4 MIG ip core clocks settings and requrements . 

Thank you.
pg150-ultrascale-memory-ip_clock.pdf

Alexey Lavrov

unread,
Jul 19, 2017, 2:00:37 PM7/19/17
to OpenPiton Discussion
Hi Jiangbin,

As documentation is saying, MIG requires a reference clock for generating its internal clocks.
In our design we currently use pins from external oscillator to drive a MMCM (clock generator IP core), and one its outputs is used as a reference clock for a MIG.
For your MIG controller it looks like this cascading of MMCMs causes jitter issues, as error message is saying.

I would suggest two solutions for this problem.
The first one is that you use a differential buffer for input clock and feed it to both MIG and clk_mmcm IP core, as described in Sharing of Input Clock Source (sys_clk_p) of pg150.
The second options for you is using generated clocks from MIG for the rest of the design. Section Additional Clocks  says you can generate up to four additional clocks, which can be used instead of chipset_clk, spi_sys_clk, net_phy_clk and nex_axi_clk from clk_mmcm IP core for the design.

Alexey

Jiangbin Yuan

unread,
Jul 20, 2017, 6:37:58 AM7/20/17
to OpenPiton Discussion
Hi Alexey, 
     many thank for your suggestions, I just created a demo in which a GCIO drive 2 IP cores---one is ddr4 mig ip core, the other is mmcm ip core---- over a IBUFDS. And it seems OK, I'll try in OpenPiton.

Jiangbin Yuan

unread,
Jul 22, 2017, 6:48:56 AM7/22/17
to OpenPiton Discussion
Hi all,  
         I got questions. I need to edit module pkt_trans_dp_wide to fit the ddr4 mig ip core for my dev board, but I am not so sure about some of the parameters in this module. below is piece of code from it.

.............
  parameter MAX_PKT_LEN                 = 11, // measured in flits
  parameter MAX_PKT_LEN_LOG             = 4,
  parameter ADDR_WIDTH                  = 29, // size of addr to MC
  parameter CL_ADDR_WIDTH               = 24, // 1G, addressed by 64 byte cache lines
  parameter MIG_APP_ADDR_WIDTH          = 28,
  parameter MEMORY_WIDTH                = 8,  
  parameter DATA_WIDTH                  = 64,   
  parameter MIG_RATIO                   = 4,  
  parameter APP_DATA_WIDTH              = 512, // local value DATA_WIDTH * MIG_RATIO * 2,
  parameter APP_MASK_WIDTH              = APP_DATA_WIDTH / 8,   // byte mask
  parameter MIG_APP_DATA_WIDTH          = 128, // value for a generated MIG, which varies for different FPGAs
  parameter MIG_APP_MASK_WIDTH          = MIG_APP_DATA_WIDTH / 8,
.............



       Questions are 1.  what is the DATA_WIDTH referring to? the "Data Width" parameter in the Controller Options section in the first picture? or ?  

        2. Is MIG_RATIO the setting in the Clocking section as the red arrow points  in the first picture.
        3. a third problem,  I assume DATA_WIDTH refer to the Data Width in the Controller Options section and MIG_RATIO is 4, and now bitstream file has been generated , download it to dev board, use the command  pitonstream -b genesys2 -f tests.txt -p ttyUSB1  , the terminal just freezes for a long time as shown in the second picture. so my question is how can I debug the project? just give me some hints. 




Thank you

Jiangbin Yuan


Alexey Lavrov

unread,
Jul 24, 2017, 1:08:42 PM7/24/17
to OpenPiton Discussion
Hi Jiangbin,

1) DATA_WIDTH parameter is an artifact from our older version of pkt_trans_dp_wide. It is not used in the module. We will clean it up in the next release.
2) MIG_RATIO is also an artifact. PHY to controller ratio must be four. You pointed to a correct place where is should be set.
As you can find in mc_top.v  only MIG_APP_ADDR_WIDTH and MIG_APP_DATA_WIDTH are currently used for configuring pkt_trans_dp_wide.
3) In order to use pitonstream for loading an assembly test to main memory you have to run protosyn with --uart-dmw ddr option. On top of that, you have to set a right frequency for your board (in your case change genesys2 frequency, and you may need to change memory size and data width for the script).
And as specified in an output message, you should press reset button on FPGA so pitonstream receives a special control sequence from UART and starts loading an assembly test.

Alexey
Reply all
Reply to author
Forward
0 new messages