Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
730 Views

ALTMEMPHY to UNIPHY switch causes sim failure. Clock or Calibration issue?

In the process of transferring code from the Arria II GX to GZ, I migrated from the ALTMEMPHY to the UNIPHY IP. I’ve tried everything I can think of, and I have no idea how to fix this problem. I didn't use SOPC or QSYS and I'm using Verilog in Quartus 11.1. I'm doing RTL functional sims in Modelsim. 

 

I had built an FSM that used a Avalon MM interface to interface with the ALTMEMPHY. I do a test write and read from the RAM, and it looks good for the ALTMEMPHY. Simulation Passes. 

 

When I move things over to the UNIPHY and the GZ (renaming ports as needed), I have some issues as the Simulation Fails (basically, the write then read does not produce the data it should). Looking at the read data, it looks like timing is off. local_cal_success and local_init_done go high when I expect them to. I examined things, and I believe that it has to do with the fact that the clocks are different between the two sims. 

 

Both interfaces are running a half rate controller, with a reference clock of 50MHz and a DDR2 clock at 250MHz. Since it is a half rate controller, the FSMs driving the local interface to the DDR2 IP runs at 125 MHz 

 

In the GX/ALTMEMPHY sim: 

The rising edge of Clk_to_ram is 0.6ns before the rising edge of the phy_clk (produced by ALTMEMPHY and is the fsm_clock). 

Address/Command lines to DDR2 transition 0.9ns after the rising edge of the clock to RAM 

 

In the GZ/UNIPHY 

All the rising edges of the clks are aligned 

Address/Command lines to DDR2 transition on the rising edge of the clock to RAM  

 

 

So, I’ve tried everything I could think of to try to fix this 

-changing settings in UNIPHY IP for address/command phase 

-changing calibration settings in UNIPHY IP 

 

Any thoughts on what I am doing wrong here 

1)was I doing something wrong in the original GX sim so that the clk_to_ram 0.6 ns offset from phy_clk was buying me time that I shouldn’t have had and putting me off by a cycle when I did the FSM logic 

2)Am I missing a calibration setting or another setting in UNIPHY that should shift the clocks to be like ALTMEMPHY? If so, what is that setting because as I said, I tried different settings in the UNIPHY IP and none seemed to change the clocks 

 

In both cases, I am running the same sim, which is basically a RTL simulation with an augmented version of the FSM that is created in the ALTMEMPHY. I use the testbench that came with the ALTMEMPHY, but have changed it so that it can write, then read from the DDR2. I use the memory model that comes with the ALTMEMPHY as well. 

 

Alternatively, I’d be happy to use the simulation flow of the UNIPHY, but in my looking at the files so far, it seems like a huge heap of files, and figuring out how to incorporate my logic and testing in that seems rather difficult based on what I’ve read and seen. 

 

Thank you
0 Kudos
1 Reply
Altera_Forum
Honored Contributor I
32 Views

I solved the issue. 

 

It turns out that the changing in timing was not the issue, but just a red herring.  

 

The problem was fixed by changing to the memory model created by UNIPHY.  

 

I was using the memory model from ALTMEMPHY since I couldn't get Nativelink and the flow described in the Upgrade doc to work: 

http://www.altera.com/literature/hb/external-memory/emi_uniphy_ref_upgrade.pdf 

 

Alternatively, I couldn't figure out how to incorporate my custom logic and testbench into the example_project/simulation that UNIPHY created.
Reply