cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nkiguta
Visitor
Visitor
12,138 Views
Registered: ‎07-31-2009

DDR Ram on Spartan 3E

Hi all,

 

Disclaimer: Please bear with me as I am new to this.I have also scoured the net (this forum included) and have not found a solution to the problems I'm having.

 

I have a s3e kit  with 64MB DDR ram (xc3s500e fg320 -4) and I would like to use this ram. I am running ISE Webpack 10.1 (and given the connection I have at the moment - its impossible to download a newer version) and MIG version 2.1. I have generated about 21 different designs with MIG but none of them are working (the past 2-1/2 weeks). I have tried the reference board designs and those haven't worked either. Let me clarify: The reference design also includes a bit file. This does not work on my board (none of the led's are on). So I changed a few settings in the UCF file (e.g setting the clock to LOC C9 etc) and ran the ise_flow batch script and I seem to get a lot of constraint errors. I've tried the cleanup project option from ISE but still, doesnt work.

 

I tried the new design option from MIG and selected banks 0 and 3 to generate the design (also tried 2 and 3). Incidentally, after cleaning up the generated code a little bit (removing sys_clkb, changing cntrl0_rst_dqs_div_in/out to just cntrl0_rst_dqs_div, reset = active high etc) this option does not give me the errors and I am actually able to generate a bit file.Trace reports the best I can run the design is 78MHz (which I'm assuming Im not running at considering this is the best I can do given the design - I dont know for sure though). Plus, I think the minimum I can run the SDRAM is 77MHz.

 

The design I have now (the 78MHz one) when run only lights up the init_done, cntrl0_ddr_ras/cas_n and cntrl0_ddr_we_n led. BTW, all the designs I've successfully generated a bit file for exhibit this very same behavior. Neither the cntrl0_led_error_output1 nor the cntrl0_data_valid_out led's are lit up. So I decided to output two more signals from the top level module and connected them to an oscilloscope - these signals are the clk_0 and clk90_0 generated by the DCM. Nada!! There is no activity on the oscilloscope - which means the DCM is not generating the clocks. I have no idea why since the ucf file shows C9 as my "sys_clk" with a standard of LVCMOS25 (Is that okay?) and that clock is routed to a IBUFG which generates sys_clk_ibuf which in turn is connected to the DCM as an input. 

 

NET  "sys_clk"                                  IOSTANDARD = LVCMOS25;

NET  "sys_clk"                                    LOC = "C9" ;     #bank 0
NET "sys_clk" PERIOD = 20.0ns HIGH 50%;
 

 

This whole experience is extremely frustrating and I'm hoping that someone has been there, done that and has a solution for me. I am using verilog (not familiar with VHDL) and pretty new to this whole HW thing (what a welcome entry to HW from SW).I enjoy a challenge as much as the next guy but this is bewidlering! I dont know what is going on inside there and dont even know if the SDRAM is shot or not or ....

 

I know I'm doing something very wrong but I dont know what (however, I'm pretty surprised that Xilinx would release something that does not work - coming from software, I dont know how anyone would do that - which of course leads me to believe that I am doing something wrong). I welcome anything! Suggestions, tips, advice, insults, ridicules -  I would just like to get this to work. Thanks for reading and if you can, please help.

 

Nick

 

 

Tags (2)
0 Kudos
23 Replies
jprovidenza
Voyager
Voyager
12,134 Views
Registered: ‎08-30-2007

Since it sounds like you are having multiple problems, start with something very simple.  Route

a simple counter to output pins and verify that they work:

 

reg [3:0] cnt = 'b0;

 

always (posedge clk)

  cnt <= cnt + 1'b1;

 

You should be able to hook something like this up and verify that you can synthesize & download

a design to the board.

 

Next, try adding the DCM to buffer the clock.  Make sure you bring out the DCM lock signal to a

pin so you can make sure that the DCM achieves lock.

 

You should probably feed a power-reset to the DCM, something simple like this will work:

reg [15:0]  rst_pipe = 'b0;

always @(posedge clk)

  rst_pipe <= {rst_pipe, 1'b1};

wire power_rst = ~rst_pipe[15];

 

Make sure you don't use the clock from the DCM to drive the power-on-reset!  You must use

the clock from the pads!

 

See if this gets you started.

 

John Providenza

 

0 Kudos
nkiguta
Visitor
Visitor
12,122 Views
Registered: ‎07-31-2009

Hi John,

 

Thanks for the quick response. I have been able to synthesize other circuits and actually get them to work on that board. Just to double check, I generated a 9MHz clock using a DCM (for driving an LCD) and it works just great. So I know that the board should be fine. I dont understand why it still does not work.

 

Nick

0 Kudos
nkiguta
Visitor
Visitor
12,097 Views
Registered: ‎07-31-2009

Okay...so I just updated to the ISE 10.1SP3 which among other things includes MIG 2.3, and tried to simply generate the reference board ddr controller for spartan 3e. The ReadMe file claims that the test was successfully run at 133MHz using the on board clock. BUT, the bit file that comes with it DOES NOT work. None of the leds even light up. Did Xilinx even test it on a spartan 3e kit at all? Seriously, how does anyone - let alone a corporation, ship out stuff that does NOT WORK and claim it does? Clearly, I had no hand in the generation of the bit file - so that means its not a user error. I generated a new design and no led's light up. Has anyone got this to work at all? How is this possible?
0 Kudos
jprovidenza
Voyager
Voyager
12,094 Views
Registered: ‎08-30-2007

It sounds like there is some fundamental problem going on.

 

Are you absolutely sure that the refence design from MIG targets the exact board that you're using?

 

Any chance your board has been damaged or the FPGA has been damaged?

 

Have you checked Xilinx' answer records to see if there is any known issues?

 

John Providenza

 

0 Kudos
nkiguta
Visitor
Visitor
12,088 Views
Registered: ‎07-31-2009

I have generated numerous designs with MIG and I am sure the reference designs match my board. A spartan 3e xc3s500e-FGG320 -4. In generating the design, I choose spartan 3e, fg320, -4, select Verilog as the HDL and ISE for synthesis. On the next page, there are 4 choices for a spartan board but only one for a spartan 3e kit, which is what I have. I have also designed many other circuits using this very same FPGA kit and they work well. On top of that, I never erased the ROM program it comes with so on power up, it displays the text on the LCD xter display. 

 

 

0 Kudos
drjohnsmith
Teacher
Teacher
12,082 Views
Registered: ‎07-09-2009

Hi,

 

I know about the challenge of software V hardware, I'm having to do it the other way around to you, and I can not believe the long windedness of the code generated compared to ASM, but that's another story which we WILL NOT get into here.....

 

Anyway.

 

 can I ask for a clarification please.

 

Have you a working project  for the board, either one that you wrote or one that came with the board.

 

i.e. it flashes the lights etc as you'd expect it to.

 

My confusion is the bit file that came with the board should have worked 'out the box'.

 I'm also confused in that you edited the ucf file that came with the board to make it work. Again this should not have been required.

 

To reinforce one of the earlier response, I find if the hardware is doing 'strange' things, then it's something strange that has caused it !

 

 I'd take big step back, a few cups of coffee / a new day and concentrate on the reference board designs.

    You know the code works, so that is one less variable to worry about.

 

Go back to the known clean reference designs,  as your from the SW background you'll know all about the importance of version control etc.

 

Download the reference bit file to the board ( don't re compile it or anything ), and confirm that does as you expect.

  If it does , then try re compiling and downloading and confirm it still does as you expect.

    If the bit file did not work, either you do not have the file / board you think you have, or the board / programmer is 'suspect'.

 

I've done it, it's just possible that the code is not actual being downloaded to the board, but it keeps coming up from the on board PROM.  Try with the JTAG to erase the on board prom.

 

One other thing to clarify, is the board as it came out of the box ? I ask as there are normal a number of configuration options on these boards, not least where the clock to the FPGA is coming from  / going to. 

 

Hope this helps and keep us in the loop as to how yo get on. You never know I might ask you an OO question or two.

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nkiguta
Visitor
Visitor
12,071 Views
Registered: ‎07-31-2009

Hi drjohnsmith,

 

Thats just the problem, the bit file that MIG generates (i.e the one MIG generates when I select a reference board design - no input from me) does not work right out of the box. I have tried that numerous times (with every new reference design generated).I load it and not a single led lights up.So I generate a non-reference design since I seem to have a little more luck this way (at least some led's light up).

 

I have programmed the board many times and the designs work just fine. As far as the board options, there is really only one where it counts (the spartan 3e kit). So that confirms that the programmer works and so does the board.

 

Update: So I ran MIG (non-ref design), tweaked the UCF file accordingly and now (for the first time in about 2 weeks now), not only are the ras, cas and init_done led's on but so are the data_valid_out and error leds. Obviously I'd like the error led off but hey, you gotta crawl before you walk. That is a welcome sign of life on the board.The design is capable of running at 81.593MHz (at least as trace sees it). Now the next question is why its failing and how to get rid of the errors. But man I tell you, just watching the led's (even the error led) is making my day.

 

I dont suppose it would help just attaching the iseflow_results and ucf files w/out the design but just in case someone has been there, I'm attaching them. Really, thanks for all the suggestions guys.

 

0 Kudos
nkiguta
Visitor
Visitor
12,070 Views
Registered: ‎07-31-2009

I was not able to attach both files (kept erring on me) so here is the UCF file. I hope I didn't submit multiple posts.
0 Kudos
drjohnsmith
Teacher
Teacher
12,016 Views
Registered: ‎07-09-2009

Hi

 

I'm a little concered when you say the referance design with the board does not work.

 

When I get a board from Xilinx, it comes with a cd containing a design or two for that board, which can just be downloaded and proves the board. No need to run MIG , just the programming tools. 

 

Have you that CD, and can you install the bit file on that CD and does the board then work as described in the documentation on the CD ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
bhfletcher
Voyager
Voyager
9,944 Views
Registered: ‎10-01-2007

I'm not sure why the provided MIG reference design for the Spartan-3E Starter Kit isn't working for you.  It should, although I will admit that I haven't tried it myself recently.

 

I do know that you cannot generate a brand-new design for a XC3S500E, change the UCF for the S3E Starter, and get it to work.  Check out the notes from the readme.txt from the S3E reference design:

 

"There were several hand-modifications to the rtl and simulation files required to do to the core targetted on the Spartan-3E Starter Kit board. To view all of these changes, search all rtl and sim files for comment lines that contain "SPARTAN-3E STARTER KIT".

These changes include:

1. The loop-back signal is being done using a single IO pin, rather than an output pin, a loop on the board, back into an input

pin. Therefore, the nets cntrl0_rst_dqs_div_in and cntrl0_rst_dqs_div_out have been collapsed to single net known as

cntrl0_rst_dqs_div. The signal simply loops out through an output buffer, and then back in through the same pin's input

buffer. While the actual board loopback length is normally a critical measurement for proper operation of the controller,

the loopback was not designed on this board. To mitigate for the effects of this, the delay time to/from the

cntrl0_rst_dqs_div pin had to be taken into account, and the data_read_controller had to be very slightly modified.

2. The net control0_rst_dqs_div should be placed in the center of the data bank. Instead in Spartan-3E starter kit this signal placed

in different bank, As a result the delay on this signal is more than the expected delay. There may also be MAXDELAY violation of around

1.6ns on this net. To overcome this issue number of LUTs selected for rst_dqs_div signal in data_read_controller is reduced compared

to the data.

3. reset_active_low parameter in parameter file is changed to 1'b0 to use the board's active-high momentary pushbuttons.

4. cntrl0_led_error_output1 is brought to LD0, and cntrl0_data_valid_out is brought to LD1 on the board. The data comparison in

the testbench is only considered to be error-free if LD1 is lightly illuminated (cyclical pulse signal), while LD0 is not

illuminated.

Spartan-3E pin allocation should consider the following rule.

 

1. Odd numbered DQ bit should be allocated to the top pad of an tile and even numbered DQ bits should be allocated to the

bottom pad of an IO tile..

2. No two even DQ bits or no two odd DQ bits should be connected to the same IO tile.

As some of the pins of the SPARTAN-3E STARTER KIT not followed the above rule, we modified the rtl generated out of mig to suit the Starter Kit hardware. A new module ram8d_1 is added and ram8d_0 module was hand modified."

 

It is for these same reasons that if you are designing your own board with Spartan-3E and DDR, you should not follow the pinout on the S3E Starter Kit.  You should generate a fresh design from the latest MIG and use the pinout that it gives you.  It is possible to modify the pinout and stay within the bounds of the MIG rules, but you need to understand the rules.

 

Bryan

nkiguta
Visitor
Visitor
9,918 Views
Registered: ‎07-31-2009

Ah I see what you mean..Well, I bought this board from Digilent (www.digilentinc.com) and due to licensing issues, they are unable to provide *any* Xilinx related documentation or software. I just got a board with the programming cables and that was it. So I dont have any test code for it or anything of the sort that I can revert to, to test the board. However, I have written a few tests for it and the board seems to work quite well.

 

I am assuming that you have a similar board and that you have managed to get the DDR to work. If so, would you please share your insights on how you did it? I would appreciate it - I should say, the DDR design is running but the error led is constantly on and I have not managed to get it to pass. The DDR is such a pain - but without it, my project is useless. Thanks!

0 Kudos
nkiguta
Visitor
Visitor
9,917 Views
Registered: ‎07-31-2009

Hi Bryan,

 

I'm not sure why the provided MIG reference design for the Spartan-3E Starter Kit isn't working for you.  It should, although I will admit that I haven't tried it myself recently.

 

I am not sure why it does not work for me either. There is a readme file that implies that it is intended to be used with chipscope? Which I dont have - but even then, the generated design uses pin A10 for the clock which I believe is for the user supplied external clock. Besides changing the sys_clk to C9, I dont see what else to change from the MIG generated reference board design. It is simply not working. The led's do not even light up. I don't think I'm doing anything wrong at this stage - here is the sequence

 

1. Generate a Spartan 3E starter kit design

2. Navigate to the folder where the bit file is located

3. Change the UCF file to use C9 as the sys_clk as opposed to A10

4. Run ise_flow.bat to generate a new bit file

5. A lot of errors here..

 

I do know that you cannot generate a brand-new design for a XC3S500E, change the UCF for the S3E Starter, and get it to work.

 

I own a Spartan 3E Starter Kit so that should work right out the box. But since it does not, I am generating a new design and making those changes in that new design. However, I know that I'm not doing something right here because even though a bit file is generated, the design fails and is running a lot slower than what the reference design should run at (133MHz)

 

It is possible to modify the pinout and stay within the bounds of the MIG rules, but you need to understand the rules.

 

Yeah - very true. I do *not* understand the rules- ive been reading up on Xilinx docs so I'm slowly getting there.

 

0 Kudos
drjohnsmith
Teacher
Teacher
9,905 Views
Registered: ‎07-09-2009

Hi

 

not seen the Digilent stuff, so had a look.

 

I can understand whythey are not allowed to supply any Xilinx stuff, but they do supply referance designs on the site.

 

http://www.digilentinc.com/Support/Support.cfm?NavTop=85

 

I don't know which board you have, but I'd start withthe referance design from the board designers, then step on modifying that to get to where you want to go.

 

Trying to get a design from the wrong board working is going to be 'fun'. Start with one that works is always a good short cut.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nkiguta
Visitor
Visitor
9,845 Views
Registered: ‎07-31-2009

Hi John,

 

If I download these designs and program my fpga with them, it will only prove that I can configure the fpga and that the board is working correctly. Well, I have already done that. I have designs that I can load/configure the fpga with and they run without any problems - so that part is taken care of. My problem is with the DDR SDRAM. Right now, its failing and I think that it has a lot to do with the placement of the dq* components (odd numbered on top tiles and even numbered on bottom tiles - whatever that means). 

 

I compared the ucf file generated when I generate a new design to the one generated when I select the custom board (spartan 3e kit) and made adjustments to the clock and the loop back clock. I noticed that after these changes, the design is running (but failing). However, I have not changed the dq* components - because I dont know what I am doing. Can anyone please shed some light on this (PS: I just cant copy and paste these changes since some pins are reserved for my LCD in the design I'm generating). Is there any document that discusses this stuff? i.e the tiles. I'm hoping that the reason its failing is because of the misplacement of the dq* bits.

 

Thanks a lot!

 

Nick../

0 Kudos
drjohnsmith
Teacher
Teacher
9,843 Views
Registered: ‎07-09-2009

Hi

 

the reason for suggesting the designs from the demo board manufacturer was partly to prove the boards, but mainly for you to 'borrow' the design.

 

I assume their reference design has DDR driven, and has a UCF file.

 

So I'd start with their working design and modify it to what you want, testing as I go. That's one of the advantages of FPGA's, you can take small steps and 'simulate' in real silicon, not like ASICS where you have to simulate to death.

 

There should also be some app notes from the board manufacturer as to how they got the DDR working, and any features they had to hand implement.

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nkiguta
Visitor
Visitor
9,831 Views
Registered: ‎07-31-2009

Ah I see...well, they dont seem to have a DDR reference design (I wish they did). They only have a few basic modules but not DDR. Just my luck! Thanks
0 Kudos
drjohnsmith
Teacher
Teacher
9,814 Views
Registered: ‎07-09-2009

Hi

 

So you have a board, with DDR ram on it, but the manufacturer of this ref board has no evaluation code for the DDR ?

 

Amazing. I'd have a long chat with the demo board supplier as to where the code is and how they got the DDR to work.

 

I'd also strongly suggest you get a Xilinx demo board, which has  working DDR examples on it.

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nkiguta
Visitor
Visitor
9,772 Views
Registered: ‎07-31-2009

Hi John,

 

But its the same board as Xilinx offers. I even looked up the specs and it is exactly the same board that Xilinx offers. In fact, on the Xilinx website (http://www.xilinx.com/products/devkits/HW-SPAR3E-SK-US-G.htm) - it is what I have. Initially when I bought it, I had looked up boards under the academic option and the board listed was sold by Digilent.

 

Nick../

0 Kudos
drjohnsmith
Teacher
Teacher
9,764 Views
Registered: ‎07-09-2009

Hi

 

 that is a good find.

 

In that case, you have access to the working Xilinx demo code.

 

just download it, and put it on the board.

 

Once that is done, then  try modifying the code to what you want, one step at a time.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nkiguta
Visitor
Visitor
6,568 Views
Registered: ‎07-31-2009

John, this whole thread has been revolving around the fact that I can not get the MIG output to work on the board (not for lack of trying..). I imagine that by

 

In that case, you have access to the working Xilinx demo code.

 

you mean the output from MIG. I recently contacted Digilent and they advised me to use MicroBlaze to get the DDR to work, which is quite annoying considering I had no intentions of using that for my project. Anyway, if you have a Spartan 3e kit, I would really appreciate it if you could experiment with DDR to see if you can get it to work. It seems like no-one else is having any troubles with DDR but me so I must be doing something wrong. Has anyone gotten the DDR to run (w/out using MicroBlaze) and if so, would you please send me your ucf file. Thanks a million.

 

Nick../

0 Kudos
drjohnsmith
Teacher
Teacher
6,556 Views
Registered: ‎07-09-2009

Your certainly having a tough time of it arn't you.

 

If it 's any consolation, DDR and high speed memory interfaces in general push the designer. it's one of the reasons MIG came out, there are so amny different rules to observe to get a fast and efficient desing working.

 

I'd suggest that you either go back to your board supplier, and find out why they have not go the DDR working ( there might be a reason ).

 

I'd also suggest that you get a board that does have working designs supplied with it to evaluate the board. 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
lynn0p
Visitor
Visitor
6,360 Views
Registered: ‎08-16-2009

You wonder why there are reference designs for almost every other chip on the Spartan3e Starter Board, but NOT the mt46v32m16? I mean, they cover the flash chip, they cover the CPLD, they cover the RS232 interface, etc, but not that SDRAM chip. Well, write your own, and you'll quickly figure out why. It's not a trivial task, and there are a fair amount of gotchas that you only learn about if you've done it. I'll put it this way, it's not a project you're going to complete over a weekend. I personally almost gave up before I got mine working.

 

I've published a design for interfacing with the mt46v32m16 on the Spartan3e Starter Board on opencores.org, for those of you who just want to get on with it and not learn the wonders of state machine timing. Or maybe you do and you can expand upon the basic design. The URI for it is:

 

http://opencores.org/project,sdram_controller

0 Kudos
ajad
Visitor
Visitor
5,684 Views
Registered: ‎05-04-2010

Hi guys,

 

You have probably figured out the solution already. Nevertheless, it looks like you have directly programmed your S3 kit with the reference design bit file. I think this bit file is generated for clock source through SMA connector loc="A10" and not the onboard clock loc="C9". This is the case for at least the ucf included with the design. I recently went through the same problem but haven't tested completely with it, yet.

 

Another thing, I am getting a "Translate Failed" problem with 12 errors. Can you enlighten me how to remove this problem. I solved this once (not sure how??) but I am getting it again when using MIG 3.0 of ISE 11. I have posted the problem as "MIG Translate Failed" and a "thought-so" solution which I am not so sure now.

 

Cheers,

Ajad

0 Kudos