DDR2 Troubles on Cyclone III

the X in the read back are because there is a randomization on the read result in hardware or because this is the result of a simulation?

I had once a problem with the data stored in DDR2 memory that time I changed the name of the controller instance in SOPC Builder but forgot to reapply assignments and re-check timing constraints; the name of the ports in the SOPC Builder instance changed losing relation with the pins of the top level design.

Hi,

there is an appnote describing how to test your design using signal tap.

Cumbersome, but quite helpful. AN 380.

If you have troubles with your timing then you will have to read up on manually adjusting the timing, which is quite time consuming..

gabrigob - This is real world, not simulation. I've run the identical design on the Cyclone III 125 dev kit, and have no problems. I've not notices any issues with the instantiation.

agdepus - Thanks. This appnote looks helpful, and not a;; that cumbersome. I'm currently using Nios memtest project to read/write to memory. I don't quite understand what you mean by bridge - can you elaborate?

Hi,

I am in the middle of Win7-64 / Nios Eclipse 10.0 and find everything regarding altera cumbersome these days...about to install linux. Ungodly slow in windows.

The bridges are essential in order to separate clock domains, ease timing req and so on.

If you do run a bunch of low speed PIOs you may separate those from the high speed CPU/memory/cache clock domain.

All of our Nios/DDR designs have:

CPU

Cache

On chip ram

JTAG

In the DDR_AUX half rate or full rate clock

and the rest is run at 10MHz using a clock separation bridge.

BUT, anything that your CPU is constantly accessing should be put in the high speed domain. That is for you to decide.

The embedded design handbook is actually quite good, you should have a look. We have designed multi core systems that has been running flawless for 4 years now based on that information.

I don't do much low level work these days, but it happens. Maybe some of the gurus can take you further.

apus

agdepus - Thanks again for your help. I am running my tools on Linux, Centos 5.5. My experience with the NIOS and SOPC builder tools on Windows 7 has not been good. Right now most of our designs are all V9.1 of the tool set and so I don't know if V10 is any better. If you go to Linux, I suggest CentOS. That worked for me without issue, is free, and has a wider range of software available than Suse and RHEL.

Yes, I'm using a bridge, and have a very similar setup to what you described. However, my NIOS is running at 125MHz.

I'm trying to bring this design up on a new custom board. I've got the identical design working correctly on the Altera Cyclone III dev kit, and the design meets FPGA timing in both the DevKit and the custom PCB.

However, the four variables that are different between our PCB and the Dev Kit:

1. We are using two 256Mb DDR2 ICs MT47H16M16, the Dev Kit uses two MT47H32M16 (512 MB) - and so our PCB design is using a different memory Preset file.

2. Our PCB uses separate clocks for each of the DDR2 ICs, the Dev Kit uses one clock that Tees - once again we have two clocks set up in the preset file.

3. I'm using a EP3C55F780C7N rather than the EP3C120F780C7N on the dev kit - so the pinout on the FPGA is a slight different.

4. Of course, the layout is different.

My suspicion is that that something in the layout or the Dual clock architecture is causing the problems I'm seeing. The fact that the lower bytes are solid, but the upper bytes are corrupt or have slipped a clock seems curious as well. It seems there is enough adjustably in the DDR core that there may be a fix here, but I'm not sure what to tweak.

Hi,

we are using two 64M16, set up as two total independent memories. I tried to merge two DDRs back in 2007, and dropped it.

But do you need to run those chip on the same controller?

Yes, the same controller.

The devices share an address bus. but have a separate clock.

Normally, we use two memory devices with a shared address bus and clock in our designs - similar to the dev kit. I'm not sure if the separate clock causes a problem or not.

So that means that all data and ctrl signals are related to one of the clocks?

That will never work unless the IP actually supports that.

My guess is that the lower bytes is the chip with the controller clock.

You need to use a clock from the same pll, maybe with a few degrees tune...

I mean, you have two totally different clock domains here....?

No, the same clock domains.

In the memory presets, we can specify the number of clocks. In this case, there are two. The clocks should be on the same domain.

The clocks each go to one of the ICs. For what it is worth, the lower byte of the each of the ICs is being read correctly and consistently. I would expect a clock domain issue to result in in a error in the upper and lower bytes in one or both of the ICs.