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: 
Observer sanjaac
Observer
15,350 Views
Registered: ‎03-16-2009

Spartan-3E, DDR, MIG

Jump to solution

Hi guys,

 

I am working on DDR controller for the Spartan-3E Starter Kit. I want to "report" that it seems to be working, but partially. In simulation everything goes fine, both for writing and reading data. I generate a sequence of numbers, fill the memory with it, and then read all the positions back, comparing with the sequence of numbers written. If an error is found, a counter is incremented. At the end of the read sequence, if everything goes fine, one led should glow, if not (even a single mismatch was found, which means the error counter is different to zero) then 6 leds glow.

 

I am testing my stuff on an S3E Kit. If I just run the test for a very few rows (say 3), then most of the times the test passes, others it does not. If I run for higher number of rows, then at all times it fails. So, it seems to me that I am getting timing problems. Besides, I have to add that I am not using an external 133 MHz clock to SMA connector, I am using the onboard 50Mhz clock instead and a couple DCMs, one for generating a 100 MHz clock and another one to generate the 90 degree phase shifted clock.

 

Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). Looking into the details of the UCF, I see that this signal, which for the S3E Starter kit is implemented as a loopback, has an assigment to pin P13. I suppose that that is needed because of packaging to IOBs, which is one of the project options for the MIG generated project. Is there a way to make the signal always internal and not look for a physical pin?

 

The only way I have found to meet timing constraints was to remove that constraint in the UCF (the one that assigns rst_dqs_div signal to pin P13), but now another problem arises: when generating the bitstream, it fails because DRC is not passed, saying that the signal rst_dqs_div was assigned to bank3 which uses impedance controlled buffers or has Vref requeriments, which rst_dqs_div does not meet. How can it be got to work reliably? Even the original project generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without modifications, fails to meet the timing constraints for signal rst_dqs_div, which is supposed to be a critical timing signal necessary to get the controller working correctly. All your comments and suggestion are very welcome.

 

Kind regards.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Observer sanjaac
Observer
17,677 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

I want to report that finally got it meeting all the contraints. Jspaldings' note on jitter was a right one; what I did was to use the cascaded DCM method, and use 2x from DCM1 to feed DCM2. Basically the same I was doing with separate DCMs, but seems like with the cascaded DCM core there is much better control of timing behavior. I use the 50 MHz as input, take 2x from it with DCM1 and then get 0, 90 and 180 degree copies of it from DCM2.

 

I simply updated the VHDL code (UCF untouched) and ran the toolsets. For 9.2.04i it worked seameless. For 10.1.03 I had to play a trick on the P&R options, but constraints got met. The DCMs where generated with 10.1.03i

 

Next step is to check  with the S3E kit, I do not have the HW here.

 

Regards.

View solution in original post

Tags (3)
25 Replies
Xilinx Employee
Xilinx Employee
15,341 Views
Registered: ‎10-23-2007

Re: Spartan-3E, DDR, MIG

Jump to solution

Cascaded DCM's can result in high levels of jitter which might be a problem.  If you can, you might try using a good external source.

 

Rst_dqs_div is used to enable the data capture on the input flops.  That's why it is supposed to be trace matched to the outbound clock to the memory and the data trace back from the memory.  But the Spartan-3E kit didn't have this routed properly, so there is a slightly modified design given in the board files for this particular board which doesn't quite match the standard MIG output.  This is needed to make the board function with the MIG design.  Rst_dqs_div compensates for the output and input buffers (and any variations in them over voltage and temperature) and the trace delay.

 

 

Observer sanjaac
Observer
15,318 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

Thank you very much for your feedback. It seems very likely as you say, that internal jitter is the cause of my trouble. I tried implementing the normal TestMemory app on EDK for this board (rev D) at internal 50 MHz, and the app passes the tests with no problem; even for the 16 bit test I incremented the amount of data to test and it passes, but now the concern is the speed.

 

I checked the UCF for the EDK project and the constraints are not that tight, it even allowed around 2+ ns MAX_DELAY  for rst_dqs_div, which is "great" compared to the 460 ps of my initial attempt.

 

Still, several questions arise:

 

- I might keep the 2 DCM for obtaining a lower speed implementation (80 MHz would be ok, and is around the lower limit for the DDR according to datasheet). Would that help with my possible internal jitter problem?

- How can I know exactly the DDR speed that the EDK project is setting for the DDR controller? I would not expect it to be 50 MHz, since the DDR demands for a higher speed clock.

- Unfortunately I have no access to a good external clock as the MIG project for this board demands for. Still, the timing constraint for this project (untouched) is never met, and by a very huge margin. So, how reliably can this DDR controller work, if it even works?

 

Finally: overall, should I better switch to DDR2? For me DDR seemed to be easier to handle at the beginning, but now I am finding  myself really into trouble. Suggestions are very welcome.

 

Regards.

0 Kudos
Xilinx Employee
Xilinx Employee
15,296 Views
Registered: ‎10-23-2007

Re: Spartan-3E, DDR, MIG

Jump to solution

I'm not a jitter expert, so it's hard for me to say if your issue will go away at 80 MHz.  And I also don't know much about what EDK is doing, so there's strike two.  I do think you should open a support case on the timing constraint not being met by a large margin as you say.  This should not be happening.  Make sure you are using a matched set of tools, preferably the latest (ISE 10.1.3 and MIG 2.3).

 

DDR2 is certainly cheaper and has a better future.  The issue with DDR2 is that Spartan-3E IO's only support SSTL18 class I, not class II.  For this reason MIG doesn't support DDR2 on Spartan-3E.  But that is somewhat conservative in some applications.  If you have a small interface (for example, one component) and you've done IBIS simulations to check signal integrity, then you may find that 3E works fine with DDR2 in your system.  Also, the JEDEC minimum frequency of DDR2 is 125 MHz although some vendors may allow operation at lower frequency.

0 Kudos
Observer sanjaac
Observer
17,678 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

I want to report that finally got it meeting all the contraints. Jspaldings' note on jitter was a right one; what I did was to use the cascaded DCM method, and use 2x from DCM1 to feed DCM2. Basically the same I was doing with separate DCMs, but seems like with the cascaded DCM core there is much better control of timing behavior. I use the 50 MHz as input, take 2x from it with DCM1 and then get 0, 90 and 180 degree copies of it from DCM2.

 

I simply updated the VHDL code (UCF untouched) and ran the toolsets. For 9.2.04i it worked seameless. For 10.1.03 I had to play a trick on the P&R options, but constraints got met. The DCMs where generated with 10.1.03i

 

Next step is to check  with the S3E kit, I do not have the HW here.

 

Regards.

View solution in original post

Tags (3)
Observer sanjaac
Observer
15,268 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution
Let me correct: The DCMs where generated with MIG 2.3
0 Kudos
Observer sanjaac
Observer
14,936 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

I am sorry to say that this is FAR from solved... My "checker" does not work, simply because the cntrl0_data_valid_out signal does not show valid data in a Post-Translate simulation, whereas in the Behavioral Simulation it works perfect.

 

Examining the code in the file (generated from MIG2.3) xxx_data_read_controller_0.vhd one can see this code:

 

-- User data valid output signal from data path.

  fifo_0_empty          <= '1' when (fifo0_rd_addr(3 downto 0) = fifo_0_wr_addr_3d(3 downto 0)) else '0';
  fifo_1_empty          <= '1' when (fifo1_rd_addr(3 downto 0) = fifo_1_wr_addr_3d(3 downto 0)) else '0';
  read_valid_data_0_1   <= ((not fifo_0_empty) and (not fifo_1_empty));
  read_valid_data_1_val <= (read_valid_data_0_1);

  process(clk90)
  begin
    if clk90'event and clk90 = '1' then
      if reset90_r = '1' then
        u_data_val         <= '0';
        read_valid_data_r  <= '0';
        read_valid_data_r1 <= '0';
      else
        read_valid_data_r  <= read_valid_data_0_1;
        read_valid_data_r1 <= read_valid_data_r;
        u_data_val         <= read_valid_data_r1;
      end if;
    end if;
  end process;

 

There is where the signal is actually generated, the other things are merely structural connections. However, in the synthesis one get the following warnings:

 

WARNING:Xst:2677 - Node <reset90_r> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r1> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_0> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_1> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_2> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_3> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_4> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_5> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_6> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_7> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_8> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_9> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_10> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_11> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_12> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_13> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_14> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_15> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_0> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_1> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_2> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_3> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_4> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_5> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_6> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_7> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_8> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_9> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_10> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_11> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_12> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_13> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_14> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_15> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_0> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_1> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_2> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_3> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_4> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_5> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_6> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_7> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_8> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_9> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_10> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_11> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_12> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_13> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_14> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_15> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_16> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_17> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_18> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_19> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_20> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_21> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_22> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_23> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_24> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_25> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_26> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_27> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_28> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_29> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_30> of sequential type is unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_31> of sequential type is unconnected in block <data_read0>.

It looks like all what I needed is stripped down from the netlist. Does someone know how to get rid of this, and make the MIG2.3 DDR Controller work????

 

Thanks!

 

 

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
14,932 Views
Registered: ‎10-23-2007

Re: Spartan-3E, DDR, MIG

Jump to solution

Are you sure this code is from MIG 2.3?  I just tried to generate the board files from 2.3 and I do not see this code.  I do see it in the output of MIG 2.2.  Here's the header I see in the 2.3 file:

 

Vendor             : Xilinx
Version            : 2.3
Application        : MIG
Filename           : vhdl_bl4cl2_data_read_controller_0.vhd
Date Last Modified : $Date: 2008/07/24 12:27:57 $

 

Questions:

- are you using the board files for the 3E or a new design?

- if a new design, are you trying to simulate the example design or the user design?

- is this purely the MIG output or have you added your own code or made changes?

- does "not work" mean only that it doesn't pass post translate simulation?  Or does it fail in hardware?  You mention that behavioral simulation passes.

 

0 Kudos
Explorer
Explorer
14,876 Views
Registered: ‎02-18-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi jspaldings,

 

I'm a newbie with ddr, can you post your project so I can study and understand how work?

 

 

Regards,

AlexGiul

0 Kudos
Xilinx Employee
Xilinx Employee
14,855 Views
Registered: ‎10-23-2007

Re: Spartan-3E, DDR, MIG

Jump to solution
You can get the exact same set of files from MIG that I was looking at by using the "Create Design for Xilinx Reference Boards" in MIG.  Just pick the part family of interest in Coregen, then click on MIG.  Instead of the plain "Create Design" option, choose the Board option and then the board of interest.  You'll get a zip file with all the files.
0 Kudos
Observer sanjaac
Observer
14,695 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

I want to thank jspaldings for this insightful contribution. I regenerated in MIG2.3 (the headers I had said it was 2.1), and it worked. I did some minor modifications to be able to use it with the onboard 50 MHz clock, by adding a DCM which generates 100 MHz clock.

 

The system has been running continuously for more than 3 days with no problem at all. I must say that I did it based on the DDR demo for the S3E Kit provided with MIG2.3.

 

Right now I am concentrated in getting rid of the specifics of the S3E demo, still keeping the needed modifications necesary to make a "normal" DDR controller from MIG to work with S3E kit. Now the behavioral, post-translate, post-map and post-route simulations give consistent and correct results. I still have to clean up some latches in my own code which interfaces to the DDR controller, but now the results seem to be much more promising.

 

Regards.

Tags (4)
0 Kudos
Observer sanjaac
Observer
14,638 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

So far, so frustrating (again). For the previous post I just got the MIG2.3 generated project for the S3E kit and modified a tlittle bit to add a DCM which generates an internal 100 MHz clock from the onboard 50 MHz.

 

I was trying to get rid of the Chipscope stuff on that project, as well as the Testbench in the Top Level connections, but it seemed that the stuff I wanted to get rid of was deeply embedded into the code, so I decided to take another approach.

 

I generated a clean MIG2.3 project with the correct settings for the S3E kit (burst length 4, CAS latency 2), but did not use the "board" option. I did not include any DCM or Testbench, since they ara generated in the top level project, where I include my own Testbench. I did the modifications comparing file to file, and added the additional ram8 file, so it now is a project with the code for the S3E kit, excluding the Top Level code which inserts Chipscope and the levels which insert the original S3E kit Testbench. UCF modifications also took place where needed. I am using all the same project options like the original S3E kit project has.

 

My testbench includes a Verilog module for the DDR memory, directly from Micron.

 

In behavioral simulation it behaves like a charm. The simulation transcript tells that the writes and all the reads are correct, and the memory window on modelSim I can see the data, correctly written. In the read back process I compare every received data to an expected data, and raise a flag whenever a fault is detected, and at the end of the readback, if any error was detected I write a certain pattern to the LEDs. If everything is OK, I just write another pattern to the LEDs. In behavioral simulation none of these flags is rised, and the success pattern shows up.

 

But in post-translate simulation, the very first reads start giving me errors. Instead of reading 0x00000001, 0x00020003, 0x00040005, .... etc, it reads something like 0x00010009, 0x00030008, and garbage like that. Those values are the ones delivered by the DDR controller generated by MIG. To make things more strange, the values on the actual DDR bus are perfect: 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006... and so on, consecutive values. Also the ModelSim transcript says that the values read back from the DDR are the correct ones (perfect sequence). So, it looks like the DDR controller can control the DDR but can NOT deliver the right data... Is that possible!!!???

 

If I synthesize and run on the actual kit hardware, most of the times it passes, but some other times it does not, it fails randomly, not under a defined pattern. When I say it passes, I mean: it turns the LED success pattern on. I added chipscope, and set everything up to trigger when the readback starts. When the system passes (success pattern on LEDs), I can see that for every clock the received and expected words are the same, and no flags are rised. So it works fine. BUT, when it fails (failpattern on LEDs), several things or cases can be seen:

 

1. At all times the expected data is incrementing one by one with every clock and when data valid is active.

2. Sometimes the mismatch starts from the very first word received, maybe it starts on 0x00020003 instead of 0x00000001, som from now on all the comparisons give mismatch.

3. Sometimes the received data starts OK, but somewhere during the transfer it reads a different value, say 0x01A401A5 when 0x01A801A9 was expected. This happens after some inactivity due to attending an Auto Refresh Request.

 

So, my questions are:

 

- Why does it exhibit such a strange behavior on post-translate simulation? Are post-translate, post-map, post-place and route really reliable, do they reflect the actual behavior or the FPGA under a given Testbench?

- Can it be the case that the DDR controller behaves different with different Testbenches under the same project settings (I am not talking about the results of the Testbench, I am talking about the DDR controller itself)

- How can I be sure of being always aligned at the beggining of rows / columns when an Auto Refresh Request is attended in order to continue reading from where I left once I attended the Auto Refresh request?

 

And finally: is there an available DDR controller for the S3Ekit wich works and does not have all the Chipscope and Testbench stuff generated by MIG 2.3, that one can use off the self???

 

 

Kind regards.

0 Kudos
Explorer
Explorer
14,545 Views
Registered: ‎02-18-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Sanjaac,

 

I generate with MIG 2.3 the board files for Spartan3e starter kit but I have troubles because there are a lot of constraints errors .

 

I sum up what I have done:

 

1) with IG generate the board files 

2) create a new project and add all vhdl file, ucf and the chipscope core.

3) Manualy modified the VHDL to enabke a line in some code lines (where I have found spartan 3e) in main and in ucf.

4) Syntethize (ok).

 

I add the rar with the ise project (ise 10.1).

 

Thanks a lot

 

0 Kudos
Observer sanjaac
Observer
14,510 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

I can say I got it working, or at least, I won't fight it anymore and will move forward with the current results. The way I am testing it is:

 

- Write a sequence of numbers 0x0000 - 0x0001, 0x0002 - 0x0003, etc. to the DDR. Right now I am testing 9 rows, writting to all columns in every row.

- Read back the memory, and compare to an "expected" value. If some mismatch is found, a "flag" is rised. At the end of the read (9 rows, each 1024 columns long), if some mistake was found, a set of LEDs is turned on. If no mismatch is found, another (single) LED is turned on.

 

I corrected a small bug on my testing code, which prevented from incrementing the row at the end of it under some special circustances. Now it works nicely. 

 

All the sequence starts when a pushbutton is pressed.

 

The results: most of the time no errors are found. Very seldom a mismatch is found. Using Chipscope, I can see that the error happens because some times the "expected" value starts on 0x00020003, and not on 0x00000001 as it should be. But the value read back from the DDR is _always_ correct, and in the right sequence. That is why I say I think I got it working and won't fight it anymore.

 

If I test half the rows available I get exactly the same results, in the same pattern. I mean, even if I increase the amount of rows to be tested the system behaves the same, so it means he DDR timing is actually the same (correct), and I discard other factors like jitter.

 

If anyone is interested on it, please let me know and I can share the full ISE project. I would be happy to have some feedback about why the "expected" value starts sometimes at 0x00020003, and not from the very first value as it should.

 

Regards,

 

JaaC

Tags (3)
0 Kudos
Observer santiagordgz
Observer
14,327 Views
Registered: ‎11-01-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi:

 

I'm interested on it.

I was developing a DDR controller of my own but because of some very hard to trace inconsistencies I switched to MIG.

 

Can you send me a copy of your projec?

 

0 Kudos
Observer sanjaac
Observer
14,209 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution
Sorry for the delay. Here it goes.
0 Kudos
Explorer
Explorer
14,180 Views
Registered: ‎02-18-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Sanjaac,

 

I have seen your work and I'm very interested in your work and I would try to use in my application:

 

I would connect your code to my ADC, fill the ddr and send the content of ddr via UDP to my PC.

 

Could you explain me how use your code to make same simple "write" and "read" cycle on ddr?

 

Thanks,

 

AlexGiul

0 Kudos
Observer sanjaac
Observer
14,148 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Alex,

 

Actually, the code provided there is structured more or less this way: There are 4 basic blocks: Clock generator (clk50_100_full), DDR controller (ddrctrl), Controller of the DDR controller and data generator/reader (ddrctrl_tester_interf), and a data checker (ddrctrl_tester_interf).

 

The brain of the demo is ddrctrl_tester_interf, since it generates the waveforms for handling the DDR controller as described in UG086, as well as generates the actual data to write to the DDR, and then reads it all.  The bad news is that it is rather messy in the sense that it has both data and control functions in the same huge and complicated state machine. I am prepring some visualization options for you (and all interested parties) to have a look at it. The link is:

 

http://www.sanjaac.com/pub/fpga/MTC700_Camera_libddrctrl_testerindex.htm

 

I know that there are many improvements to the code generation structure, like having default options in the state machines to avoid latches and so on. This was only initial and experimental work.

 

Currently I am working on a project which uses the underlaying ideas to generate an "image" into DDR memory and then read from it and display in a VGA @ 800x600. This one is much more cleaner in the sense that only a block implements the control signaling from UG086, and other blocks provide and consume the data, which makes easier to handle and further expand.

 

If someone is interested, I will be hapy to share as well, when done.

 

Regards.

0 Kudos
Explorer
Explorer
14,141 Views
Registered: ‎02-18-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Sanjaac,

 

thanks for your reply, my application is for radio  porpouse: I want to store into the ddr the samples from an external adc and donwload or elaborate on my pc.

 

I see the ug086 and with your post I study your code, I try to start with init sequence to see the effect on ddr but I found this problems:

 

1) I cannot simulate with modelsim (there is an error and I haven't (I think) any infos where the error is)

 

2) When I try to "translate" I get a lot of error ...

 

Resolving constraint associations...
Checking Constraint Associations...
ERROR:ConstraintSystem:58 - Constraint <NET
   "U_4/top_00/data_path0/data_read_controller0/gen_wr_en*fifo*_wr_en_inst/clk"
   TNM_NET = "fifo_we_clk";> [ddrctrl_tester.ucf(17)]: NET
   "U_4/top_00/data_path0/data_read_controller0/gen_wr_en*fifo*_wr_en_inst/clk"
   does not match any design objects.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TS_WE_CLK" = FROM "dqs_clk"
   TO "fifo_we_clk"  5 ns DATAPATHONLY;> [ddrctrl_tester.ucf(18)]: Unable to
   find an active 'TimeGrp' or 'TNM' or 'TPSync' or 'TPThru' constraint named
   'fifo_we_clk'.

ERROR:ConstraintSystem:58 - Constraint <NET
   "U_4/top_00/data_path0/data_read_controller0/gen_wr_addr*fifo*_wr_addr_inst/c
   lk" TNM_NET = "fifo_waddr_clk";> [ddrctrl_tester.ucf(20)]: NET
   "U_4/top_00/data_path0/data_read_controller0/gen_wr_addr*fifo*_wr_addr_inst/c
   lk" does not match any design objects.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TS_WADDR_CLK" = FROM
   "dqs_clk" TO "fifo_waddr_clk"  5 ns DATAPATHONLY;> [ddrctrl_tester.ucf(21)]:
   Unable to find an active 'TimeGrp' or 'TNM' or 'TPSync' or 'TPThru'
   constraint named 'fifo_waddr_clk'.

ERROR:ConstraintSystem:59 - Constraint <INST
   "U_4/infrastructure_top0/cal_top0/cal_ctl0" AREA_GROUP = cal_ctl;>
   [ddrctrl_tester.ucf(262)]: INST "U_4/infrastructure_top0/cal_top0/cal_ctl0"
   not found.  Please verify that:
   1. The specified design element actually exists in the original design.
   2. The specified object is spelled correctly in the constraint source file.

 

it's very strange because when I compile the code into your rar archive everything goes well...I have check the error and the "U_4/infrastructure_top0/cal_top0/cal_ctl0" is present.

 

What can I do?

0 Kudos
Observer sanjaac
Observer
14,114 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

The two possible causes of your "problem", at least as far as I can figure out, are:

 

- Different naming in the structure. You need to modify the U_4/etc... in the .ucf stuff to match the names of the instance as you have actually named them in your code, structural one. Indeed I had to do it by hand from the MIG generated UCF; if I did not do so I got the same kind of messages.

- Beware of the synthesis options. Chances are that you do not have kept the "Keep hierarchy" setting, and the synthesizer is throwing those signal names away. This is very needed for the DDR controller itself; in my project I set to "Soft" and it works. Whenever I set "No" to keep the hierarchy, I had the same messages as you are having.

 

Good luck!

0 Kudos
Highlighted
Explorer
Explorer
9,744 Views
Registered: ‎02-18-2008

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Sanjaac,

 

thanks for your reply...with attribute "soft" now the design compile!!!!

 

I test the first task "the ddr initialization" and everything goes well.

 

Now I would write some data, but I do't understand well the timing diagram on UG086 page 254 figure 7-9 (see the attach)

 

my first question : what is D0,D1, Dx..? is D0 a word of 4 byte?So every burst I'll write 32 bytes of data?

 

ddrTiming1.JPG
0 Kudos
Observer sanjaac
Observer
9,731 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hello Alex.

 

Since it is a dual data rate memory, 16 bits wide, each tick of clk90 (which is the same as clk0, and in my case is a 100 MHz clock) writes 2x 16 bit words. This diagram is for a burst length of 4, which is also what I use in my design. So, each of those bursts writes actually 8x 16bit words. In my case I go a bit further, in the sense that I execute the burst_done cycle only when a full row is written, thus boosting the access time.

 

The generation and control of those signals is what goes inside the huge State Machine, which as I said, also generates the Dx data and Rows where to write to / read from. Soon I will post a cleaner code, which isolates this and can be used more effectively.

 

Regards.

Tags (2)
0 Kudos
Observer sanjaac
Observer
9,730 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Correction:

 

"[...] clk90 (which is the same as clk0, [...]" clk90 has the same rate as clk0, but is phase shifted 90 degrees.

0 Kudos
Observer sanjaac
Observer
9,726 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

The new stuff is posted to the theread "Image from DDR to VGA - Spartan3E kit "

 

Regards.

0 Kudos
6,347 Views
Registered: ‎02-19-2013

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi Jaac

can you please share what code did you use to implement the memory(ddr). You have written that you implemented TestMemory App..so can you please share its source code as I am unable to open your project in Xisilinx ISE 12.3..It says that the older format project has some files missing. So just share the TestMemory app code and rest I will implement on my own.

Thankx in advance

0 Kudos
Observer sanjaac
Observer
6,341 Views
Registered: ‎03-16-2009

Re: Spartan-3E, DDR, MIG

Jump to solution

Hi,

 

It was a customer project, I can not share the sources more than what I already did on the forum.

 

Good luck,

 

JaaC

0 Kudos