Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,038 Views

SDRAM timing constraints

Using http://www.altera.com/literature/ug/ug_sopc_builder.pdf as a reference, I've been trying to constrain my SDRAM I/O. I've been using the SDRAM without constraints and it has been working fine at 80MHz with a 3.2ns leading phase shift. Now, what I don't understand is what I'm missing from this document. Using only the 5 tcl commands they show I don't get the correct timing relationship for reads. It shows the launch clock correctly, but the latch clock edge is wrong. It should not be the closest edge. 

 

Am I suppose to put in a multicycle path relationship? 

 

My constraints 

create_generated_clock -name sdram_clk -source }] -offset 0.5 set_input_delay -clock sdram_clk -max }] set_input_delay -clock sdram_clk -min }] set_output_delay -clock sdram_clk -max MEM_ADDR MEM_BA MEM_nCS MEM_nRAS MEM_nCAS MEM_nWE}] set_output_delay -clock sdram_clk -min MEM_ADDR MEM_BA MEM_nCS MEM_nRAS MEM_nCAS MEM_nWE}]
0 Kudos
5 Replies
Highlighted
Valued Contributor III
1 View

Re: SDRAM timing constraints

I don't know why the example does the -offset 0.5. I know that's to represent the board delay to the SDRAM, but that's not how it's normally done. I would get rid of that and instead increase my set_out_out_delay values by 0.5(both of them).  

Anyway, TimeQuest always defaults with the most restrictive setup and hold relationships, which is what you see in your screen-shot. If you're shooting for the next edge, do something like: 

set_multicycle_path -setup 2 -to [get_clocks sdram_clk] 

If the clocks are edge-aligned, then that is not necessary since the next edge is the one you want. In the example, they would be edge-aligned without the -offset, which is why I'm not sure why they did that.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: SDRAM timing constraints

 

--- Quote Start ---  

If the clocks are edge-aligned, then that is not necessary since the next edge is the one you want. In the example, they would be edge-aligned without the -offset, which is why I'm not sure why they did that.  

--- Quote End ---  

 

 

I'm sorry, I don't understand how this holds true when using a PLL for a phase shift. If I remove the -offset command it will still do a relationship based on the phase shift signal and the original.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: SDRAM timing constraints

In the example, if they get rid of the offset and instead account for that in the delays, then no multicycle is necessary and the example would be correct. (I just filed something against that). 

In your case, you're manually phase-shifting the clock and want to latch data on the subsequent edge, so a multicyle is necessary either way.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: SDRAM timing constraints

So, maybe I'm just confused by the example. If they phase shifted that clock going into the pll by -3ns. Then, would they need to use the multicycle path? 

 

I was only thinking multicycle path because of the way the tAS looks like in the data sheet with the data not appearing vallid until after that time plus routing delays. I don't do anything special in my design. I thought that was just how the SDRAM works.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: SDRAM timing constraints

I guess what I'm trying to say is I don't understand how they can meet any sort of timing constraints using a phase shifted clock and those 5 tcl constraints without the -offset command, not using a multicycle path constraint.

0 Kudos