- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 youLink Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page