cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
amin_8460
Visitor
Visitor
9,035 Views
Registered: ‎11-27-2012

Spartan6 Maximum Frequency

Hi
I am using a SPARTAN6 speed grade 3 and there is a high speed SDR SRAM In my board as well. I've used DCM to generate clock for the logic and out to SRAM.
I set timing constraint but the max frequency I achieved is 125 MHz. If I increase the output clock of DCM to 150 MHz I have timing constraint error: "Slack in some nets is -3.447ns."
How can I increase the max frequency?

what should I do exactly in timing constraint?

How can I set constraint on DCM output?

Thanks
Amin

0 Kudos
8 Replies
hgleamon1
Teacher
Teacher
9,028 Views
Registered: ‎11-14-2011

You should probably read the Xilinx guides on Timing Constraints first.

 

However, you should ALWAYS specify a PERIOD constraint for your input clock signal. It sounds like you have done this (or at least tried). You can use the constraints editor for this or you can add a couple of lines to your UCF, similar to this:

 

NET "input_clock" TNM_NET = "tnm_input_clock";

TIMESPEC "TS_input_clock" = PERIOD "tnm_input_clock" 125 MHz;

 

There are other options for duty cycle and input jitter but look them up later. Hopefully you can see that the above lines specify a frequency of 125 MHz for your input clock. If you wish to reconstrain your design to a higher (or lower) INPUT clock frequency, you should edit the example given above accordingly.

 

You don't normally need to add constraints to DCM outputs. the tools are smart enough to figure out the required details from your input constraint and the configuration of the DCM itself.

 

If, after place and route static timing analysis, you have timing errors (similar to the one you quoted), you will have to examine the failing path(s) yourself and decide how best to proceed to help meet timing. This may include (but is not limited to) redesigning your code, pipelining, optimising resources, etc. The Xilinx tool SmartXplorer can help in some timing cases but is no guarantee.

 

Regards,

 

Howard

 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
amin_8460
Visitor
Visitor
9,023 Views
Registered: ‎11-27-2012

Yes, I already used priod constraint like you said. but I was thinking there are some other solution that I dont know. So, could I cunclude I can not achieve more performance by Spartan6?

 

I have another question: How can I determine Input bus (for example 32 bit) arrive ot the their corresponding FF at the same time? In other words, is there any constraint to force eqaual length routing for the BUS from input pad to FF or FF to output pad?

I read the timing constraint document but I could not find any appropriate constraint.

I tried to depict my problem:

 

 

Thanks,

Amin

 

0 Kudos
hgleamon1
Teacher
Teacher
9,019 Views
Registered: ‎11-14-2011


So, could I cunclude I can not achieve more performance by Spartan6?

Frankly, I would conclude that your design needs altering. Without knowing exactly what timing errors you get, or exactly what your code is trying to do, it is pretty difficult to suggest a further solution.

I would have expected that an FPGA-SRAM interface could run faster than 150MHz, though.

 


I have another question: How can I determine Input bus (for example 32 bit) arrive ot the their corresponding FF at the same time? In other words, is there any constraint to force eqaual length routing for the BUS from input pad to FF or FF to output pad?

I read the timing constraint document but I could not find any appropriate constraint.

I tried to depict my problem:


It isn't necessarily a case of getting them to their respective FF at THE SAME TIME that is important, though, is it? This is a synchronous interface - you need to get them to their respective FF for THE SAME CLOCK EDGE. This is quite a difference.

 

Assuming that your board has an excellent layout (and therefore the track delay is near enough the same for each data bit) then you need to constrain the input interface. You can do this by using the OFFSET constraint and relates to the setup and hold specifications of the external device, something like this:

 

OFFSET = IN 6ns VALID 10 ns BEFORE "sram_clock" RISING;

 

where "sram_clock" is the system synchronous clock driven from the FPGA to the SRAM. This example shows that the data from the SRAM will be valid 6 ns before the rising sampling clock edge and will remain valid for 10 ns. This constraint will force the tools to place the sampling FFs in such a way within the device that the constraint is met, thus your data capture is OK.

 

You will, of course, have to check the setup and hold requirements of the data from the SRAM data sheet.

 

You should also probably constraint the data going the other way (i.e. writes to the RAM), also using the OFFSET constraint but with the OUT keyword. Again, check the constraints and timing closure guides.

 

P.S. I couldn't see your diagram, so I guessed a bit.

 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
amin_8460
Visitor
Visitor
9,013 Views
Registered: ‎11-27-2012

thanks for complete answer and sorry for diagram missing. I just depicted my problem not my all design.

Can I use internal clock(s_sclk in the picture) for offest constraint? if yes, I think my problem has resolved. based on constraints editor( and also document)  I had realized just input clock can be used for this.

 

 

diagram.JPG

 

 

You know what: I had set constraint to force FF to be placed in IO block in order to overcome the same length problem I mentiond before. And so, I was reducing the flexibily of placemnet and as a result bad timing. If I can use offset as you said, I'll remove the FF in IOB constraint.

 

thanks alot.

Amin

 

 

 

0 Kudos
hgleamon1
Teacher
Teacher
9,010 Views
Registered: ‎11-14-2011

Putting FFs in the IOB can be a good idea, both for timing and size related issues.

 

The internal clock (s_clk, in your case) should not be used for the OFFSET constraint. As weird as it may sound, the OFFSET constraints relate to the INPUT clock ONLY. Like I mentioned before, the tools are clever enough to work out related timing parameters for setup and hold for downstream (i.e. DCM generated) clocks.

 

-- edit

 

P.S. Make sure you follow correct clock forwarding techniques for the clock to the SRAM.

 

-- end edit

----------
"That which we must learn to do, we learn by doing." - Aristotle
amin_8460
Visitor
Visitor
8,986 Views
Registered: ‎11-27-2012

Thats is difficult to understand how tools can handle it. What should I do? for example, if input clock period is 20 ns and derived clock (s_clk) is 5 ns then how should I set the OFFSET?

suppose I need  the below constraint:

 

OFFSET = IN 1 ns VALID 5 ns BEFORE "s_CLK" RISING;

 

so is that correct to define:

 

OFFSET = IN 1 ns VALID 5 ns BEFORE "input_clock" RISING;

 

or I should use proporion of 4 (20/5)?

 

 

thanks

Amin

0 Kudos
hgleamon1
Teacher
Teacher
8,979 Views
Registered: ‎11-14-2011

You are considering data IN to the FPGA. The setup and hold times will be dependent on the data source, not the clock entering the FPGA.

 

Let's take an example.  Your input clock is 50 MHz but your DCM clock that drives the SRAM is 200 MHz clock (a period of 5 ns). Let's assume the SRAM can output data from the edge of its clock in, say 3 ns. That gives a further 2 ns of setup before the next SRAM clock edge. If the SRAM maintains valid data until the next bit of data is output, that's a full cycle of the SRAM clock, so I would consider the correct OFFSET constraint to be:

 

OFFSET = IN 2 ns VALID 5 ns BEFORE "input_clock" RISING;

 

So we are using the input_clock EDGE for the constraint. It doesn't matter what the input_clock period is because the tools know, from your design, that the capture clock (s_clk) is related to the input clock and will report the timing based on this relationship.

 

You should check what the data source (SRAM) states for its own clock-to-out times and how long the data remains valid.

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
amin_8460
Visitor
Visitor
8,974 Views
Registered: ‎11-27-2012

I appreciate you for your complete and clear reply.

 

Amin

 

0 Kudos