Timing Analysis

[waris.mohammad]

HI,

      I am using an SSRAM from GSI. I use ISE10.1.

The SSRAM runs at 250MHz. The setup time for memory is 1.2ns and hold time is 0.2ns.the clock to output time for the memory is 2.5ns.

I use DCM to generate the a clock of 500MHz and divide it by 2 for the purpose of driving SSRAM data out along with passing a copy on another output port.

Can any one help me in writing the offset in and out cnstraint for this scenario?

I read in somoe document that i need to use REFERENCE_NET for source synchronous data.

thanks .

[eteam00]

I wonder what FPGA you are targeting.

And which SRAM.  Do you have a link to a datasheet?

-- Bob Elkind

[waris.mohammad]

I am using XC5VLX30TFF665.

the link for the SSRAM datasheet is here :

GSI SSRAM

regards

waris

[waris.mohammad]

I plan to use the SSRAM in pipeline mode.

[waris.mohammad]

Can any one plz help me in writing these constraints.

[avrumw]

Writing the constraints are really the last part of this problem - there are lots of other ones that need to be solved first.

Basically, you need to design the memory controller. For SSRAMs, the controller state machine is very simple (almost non-existant), but the mechanism of managing the timing is quite complex.

At 250MHz (4ns period), nothing is simple - generally you will need to design a number of mechanisms

The first mechanism is  to generate the forwarded clock and the associated data/control to guarantee the setup/hold relationships required by the SSRAM. This is usually not too hard as long as you are using

    - IOB FFs for all signals

    - (probably ODDR for the forwarded clock - using a 500MHz clock for this purpose is probably not the best way to go)

    - either invert the outgoing clock to generate the SU/H requirement, or use the ODELAY, or generate two clocks in a MMCM/DCM with the desired phase relationship to guarantee the SU/H requirement

The second mechanism is FAR more difficult. The complete read path is from

  - clock inside the FPGA

  - A DDR output FF

  - An OBUF (1-3+ns)

  - Trace delay to the RAM (??ns)

  - RAM CLK->Q (1.5 - 2.5ns)

  - Trace delay back to the FPGA (??ns)

  - an IOBUF input stage

  - an IOB FF (SU/H window around 1+ns), which needs an "appropriate" clock to capture the data

All of this will have to be done in such a way to satisfy the IOB FF's SU/H requirement in a 4ns clock period. This is not easy. There are some techniques that can help

  - using an externally deskewed capture clock to remove the OBUF/IBUF and trace delay uncertainties

     - then you have to figure out how to move data back to the main domain

  - using dynamic calibration to find the data eye

     - lots of extra stuff to do

Lastly, it appears that this RAM has a bidirectional data bus - you will need to figure out how to control the tristate enable of the IOBUF to ensure that you don't have contention on the read-write and write-read turnaround.

Once you have designed these mechanisms

  a) then you will be able to constrain the design but

  b) most of these mechanisms are either "correct by construction" (using clock phases and IOB FFs) hence constraints are unecessary or use dynamic calibration, in which case there are no correct constraints

Avrum

[eteam00]

Have you already designed the board?

How is the SSRAM clock generated?  By FPGA or external oscillator?

Is the V5 FPGA both reading from AND writing to the SSRAM?

-- Bob Elkind

[waris.mohammad]

Hi bob, thanks for the reply.

Board layout is under progress (pre layout SI phase).

SSRAM clock is generated by FPGA by dividing the DCM clock(500Mhz) by 2(user logic). And that clock is used to drive the FSM generating the address,data and control. The same clock is assigned to another net connected to top level port driving the clock input of SSRAM.

v5 is doing both write and read from memory.

thanks

[waris.mohammad]

hi avrum, 

                  thanks for the detailed reply.

i have few doubts :

1. you suggest to invert the clock. Is it not against the ideal way of designing synchronous circuits. What i understand is it may even worsen the timing.

2.can you give an explanation or a link for these methods:

-----------------------------------------------------------------------------------------------------------------------

All of this will have to be done in such a way to satisfy the IOB FF's SU/H requirement in a 4ns clock period. This is not easy. There are some techniques that can help

  - using an externally deskewed capture clock to remove the OBUF/IBUF and trace delay uncertainties

     - then you have to figure out how to move data back to the main domain

  - using dynamic calibration to find the data eye

     - lots of extra stuff to do

-----------------------------------------------------------------------------------------------------------------------------

[avrumw]

---

waris.mohammad wrote:

1. you suggest to invert the clock. Is it not against the ideal way of designing synchronous circuits. What i understand is it may even worsen the timing.

I am not referring to inverting the internal FPGA clock, but generating an inverted clock for clock forwarding - this would be done by using the ODDR with D0 connected to 0 and D1 connected to VCC; on the rising edge of the internal clock, the external signal would fall and vice versa. If the data comes from an SDR FF on the same internal clock, then this will generate a 1.25ns SU and 1.25ns hold around the rising edge of the external clock.

2.can you give an explanation or a link for these methods:

-----------------------------------------------------------------------------------------------------------------------

All of this will have to be done in such a way to satisfy the IOB FF's SU/H requirement in a 4ns clock period. This is not easy. There are some techniques that can help

  - using an externally deskewed capture clock to remove the OBUF/IBUF and trace delay uncertainties

     - then you have to figure out how to move data back to the main domain

  - using dynamic calibration to find the data eye

     - lots of extra stuff to do

These are really too complex to cover in a chat forum. What I am trying to illustrate is that you need to design the physical layer interface to this SSRAM - lots of people have spent lots of time designing interfaces for high speed memories. However, without some "fancy" stuff, your design won't work - the uncertainty of the returning data plus the SU/H window of your capturing FPGA FF are larger than one clock period.

Incidentally, you need to design this BEFORE you lay out your board - some of these solutions (deskewing the clock externally) requires some additional connections outside the FPGA.

---