cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
6,738 Views
Registered: ‎07-25-2013

Timing Constraints for Asynchronous Memory Interface

Hello, I have 2 asynchrnous memory interfaces (1 SRAM, 1 NAND Flash) connected to my Spartan-6 FPGA. Now I wander how I could apply the timing from the memories to the FPGA design. As far as I know, the Timing constraints (OFFSET IN AFTER / OFFSET OUT BEFORE) are always relative to the clock driving the FFs. For the Memory Interface however I need to specify data & address relative to WE/RE pulses. So should I use WE/RE lanes as clock to drive the FFs of the data/address lanes? Which obviously would require the use of gated clocks to avoid having WE/RE being active the whole time. I know this approach seems weird, but I'm out of ideas at the moment. I would very much welcome any suggestions how to achieve defining Asynchronous memory interface timings in the ucf file. Thanks & best regards Fabian
0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
6,723 Views
Registered: ‎08-01-2008

Re: Timing Constraints for Asynchronous Memory Interface

check this forum post
https://forums.xilinx.com/t5/Timing-Analysis/Timing-constraints-for-an-Asynchronous-SRAM-interface/td-p/656030

 

check this link for all the details about timing 

http://www.xilinx.com/support/documentation-navigation/design-hubs/dh0004-vivado-applying-design-constraints-hub.html

 

 

Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Highlighted
Guide
Guide
6,698 Views
Registered: ‎01-23-2009

Re: Timing Constraints for Asynchronous Memory Interface

So, you should start with the post mentioned by @balkris on constraining SRAM interfaces. For reference, in asynchronous SRAM interfaces (assuming they are not running ridiculously  fast), we do the timing "by design". If a two of outputs come from IOB flip-flops, then the skew between them is guaranteed to be "small" (less than 100-200ps depending on how close to each other they are, and what family they are) - assuming they are driven by the same clock, and use the same IOSTANDARD. So, if you have one change on one edge of the clock, and the other change on the next edge, you are guaranteeing the separation between them as being one clock period minus 200ps. You can design an interface that meets all the SRAM timing using this fact alone (again, assuming you can afford "a couple of system clocks" for doing the SRAM operations).

 

In Vivado, it is possible to write meaningful constraints for interfaces like this. When you do so, you can get nice reports that give you the margins on the interface signals. These constraints don't affect the timing of the interface itself, since, as I mentioned above, the timing is fixed by the architecture - this just generates reports.

 

However, you are using Spartan-6, and hence are using ISE (and hence UCF). UCF format is far more limited, and there is no reasonable way to write constraints for this interface. Generally, I won't bother - just ENSURE (and the post above shows you the steps to do so) that all your I/O come and go directly to IOB flip-flops, and then do the timing of the interface manually based on the number of clocks periods between events and an unknown (say) 200ps skew.

 

Avrum

0 Kudos
Highlighted
Observer
Observer
6,655 Views
Registered: ‎07-25-2013

Re: Timing Constraints for Asynchronous Memory Interface

Thanks for the quick reply. I'm going to work through the post.

 

If I understand you correctly, the only option is to place all driving FFs in IOB and control the timing on a "clock cycle basis".

 

My desigs aims on driving an interface with a minimum Write/Read Cycle time of 20 ns, with a FPGA clock of 48 MHz (20.83 ns).

Do you think this is possible using a ODDR2 for the Write/Read enable signals and controlling timing just by placing FFs in IOBs?

Or do you think the timing is too close and I need to do a 2 clock cycle Write/Read access?

 

Thank you for your help.

 

Fabian

0 Kudos
Highlighted
Guide
Guide
6,642 Views
Registered: ‎01-23-2009

Re: Timing Constraints for Asynchronous Memory Interface

Do you think this is possible using a ODDR2 for the Write/Read enable signals and controlling timing just by placing FFs in IOBs?

 

If the RAM has a minimum of 20ns read/write cycle time then that means that there is a sequence of signal transitions on the address, data in, write enable, chip enable that can do operations in as little as 20ns (and generate data out at some point in that sequence). So the questions are

  - can you generate all the events of this sequence at the right time with an FPGA

  - can you capture the resulting data in the FPGA

 

The first one will depend on the requirements of the SRAM, and what you are allowing yourself to work with in the FPGA. If you are planning to use only your 48MHz clock and the ODDR then you basically have two phases which are available to generate all the events in the sequences to the SRAM - it's virtually certain that this won't be enough. However, if you are willing to get more creative - like using a DCM/MMCM to generate - say - a 96MHz internal clock and possibly a 90 degree out of phase version of that 96MHz clock, then you get 4 or 8 phases to work with, still within one 48MHz clock period - that's probably enough (although - again - this will depend on the actual timing requirements of the SRAM).

 

The second question (capturing the data) is more complex. The SRAM will start generating data as soon as you give it the latest of address, chip-select and/or read enable. Only once you have determined the sequence of the control signals above will you know when in your 48MHz cycle this occurs. Then you have propagation delay of these control signals from the FPGA to RAM, the clock-to-out of the RAM and the routing delay of the return data and the setup/hold requirement of the FPGA... You have to (manually) analyze this entire path and then determine if it will work or not... (and its not trivially simple to do).

 

So, there is no simple answer to your question. It MAY be possible to do all this in 20.83ns, but not in the straight-forward "just use an ODDR" way. Or it may not... Figuring out if its possible and how to do it - That's the job of an engineer!

 

Avrum

Tags (1)
0 Kudos
Highlighted
Observer
Observer
6,489 Views
Registered: ‎07-25-2013

Re: Timing Constraints for Asynchronous Memory Interface

The event generation within 1 clock cycle is not a problem, as long as I can guarantee that all IO signals are aligned (which I hope to achieve with the IOB placement).

 

Of course the reading has a more complicated timing.

I know the delay from my board, what I don't know is the delay from the FFs to the IO (through the Tristate driver).

 

How can I get these dalays? I couldn't find them in the Timing Report.

Is the OBUF/IBUF delay identical to a IOBUF (Tristate driver)

 

I tried to add this to the UCF file:

 

TIMESPEC TS_Flash = FROM PADS("Flash*") TO FFS("Flash*") 1 ns DATAPATHONLY;

 

No I get at least the timing in the report. Still I'm not fully sure if I interpret it correctly.

 

What I get is the following:

     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     M14.I                Tiopi                 1.557   Flash_Data<14> 
                                                        Flash_Data<14> 
                                                        Flash_Module_INST/Flash_Handler_16_INST/GEN_DATA_TRISTATE[14].Flash_DATA_IOBUF_inst/IBUF 
                                                        ProtoComp1196.IMUX.47 
     ILOGIC_X18Y4.D       net (fanout=1)        0.171   Flash_Module_INST/Flash_Handler_16_INST/v_HW_Data_in<14> 
     ILOGIC_X18Y4.CLK0    Tidock                1.723   Flash_Module_INST/Flash_Handler_16_INST/v_HW_Data_rd<14> 
                                                        ProtoComp1301.D2OFFBYP_SRC.14 
                                                        Flash_Module_INST/Flash_Handler_16_INST/v_HW_Data_rd_14 
     -------------------------------------------------  --------------------------- 
     Total                                      3.451ns (3.280ns logic, 0.171ns route) 
                                                        (95.0% logic, 5.0% route) 

Now here is my interpretation:

  • Tiopi: IO-Driver delay
  • Tidock: FF propagation delay

Hence for my analysis the only relevant part is Tiopi + Tnet

I'm missing the setup time of the FF (or this this meant with Tidock?)

 

Is this correct?

 

Fabian

0 Kudos