Timequest constrains for async SRAM

Hi,

Thank you all, Godfather, Rysc and Jimbo for your very helpful replies.

--- Quote Start ---

You mean truly asynchronous, where you just supply an address and data comes out the other side?

--- Quote End ---

Yes, truly async.

--- Quote Start ---

Yes, you have to hand calculate your min period, which is basically your Tco + board delays in both directions + memory access times, but this hopefully isn't too big a deal.

--- Quote End ---

It is not too difficult to do the calculation manually, but the main point is that I want TimeQuest to verify everything is done correctly. I can compute a min period based on a specific fit, but then for some reason Tco could change and I will miss timing without a warning.

It seems I can use a TimeQuest script to extract the wost case Tco and Tsu, and then the min period using "get_timing_path". Seems a bit complicated, I wish there was a simpler get_tco and get_tsu as shown in the datasheet report, but it is probably doable. That won't make a direct constrain, but at least I could display a warning.

--- Quote Start ---

You can make each bit of the async SRAM address a clock and then set your input delay based on each clocks. I have attached a small example.

--- Quote End ---

Thanks a lot. Yes, not too elegant as Rysc is saying, but it should work. However I am having some problems with this approach.

I attempted to constrain the data input with respect to Output Enable. Being a single signal was easier than starting with the whole address bus. I followed the sample, but I am getting a slack too big, that doesn't make sense.

It seems that the Tco for the Output Enable signal (being the clock in the constrain) is not being considered? The sample shows huge trace board delays, in the order of 4ns. Do they already consider Tco?

Note in case it matters, I am not using ALTDDIO as in the sample, and my clock is not external, but generated internally to the FPGA by a PLL.