Any samples about how to constrain an async SRAM interface? Timequest doesn't seem to support the required constrains. For reading, you need the sum of tCO and tSU, and for writing you need data skew. I don't see how to constrain this in Timequest. Seems that with scripting is possible to extract the information?

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.

You mean truly asynchronous, where you just supply an address and data comes out the other side? (I've seen asynchronous referred to for different scenarios, i.e. if a read_enable signal is the gating signal that gets the data out, then you just treat that as a clock and you can do it, since you really only care about the Tco of this one enable signal). The problem with the truly asynchronous is that your timing is dependent on all the address ports' Tcos. I looked into this and don't believe it's possible in the "correct" manner, as there's no way to say all the address outputs are physically connected to the data inputs plus some delay. (There was a really ugly method mentioned whereby every address was turned into a clock, and that would work, but it just isn't very elegant.) In the end, you want the fastest Tco and fastest Tsu to determine your clock period. So just keep tightening the constraint on those until you get the best possible results and that's that. 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.

Here is the example that Godfather was referring to. It is part of a document that we are putting together on TimeQuest solutions. I believe this covers the exact situation that you are trying to constrain. It even has a Quartus archive of a test case embedded in the document. Hope this helps.

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.

Not directly related to the topic, but I noted that both the Fitter and TimeQuest derive the PLL period from the desired frequency, and not from the actual period which is usually slightly different. Seems a Fitter/Timequest buglet?

Timequest constrains for async SRAM | Altera Community

14 Replies

Altera_Forum
Honored Contributor
17 years ago
I finally followed Rysc advice. Forced Fast I/O in the ports. Made a manual computation based on the Datasheet Report. And made some approximate constrains.

The only minor problem with this approach is that you must be careful about the Delay Chain that the fitter might implement. The fitter is doing a great job, and will optimize the Delay Chain automatically for getting the center of the eye according to yout setup/hold max/min constrains. But because the constrains aren't really accurate, the Delay Chain implemented might be actually far from optimal.

Not big deal, just important to remember to use one of the methods to disable the Delay Chain.

Just to make sure I was not making any mistake, I invested making a script to check the actual real slack. Not too difficult using the "get datasheet" command.

Thank you all.
Altera_Forum
Honored Contributor
17 years ago
If I'm not confusing this with something else I was told, delay chains are set by the Fitter early in the Fitting process using course timing estimates. (The Fitter runs timing analysis in the background. For some things it does a quick analysis that isn't as precise as when timing analysis is run at the end.)

Whenever I want an I/O bus to have timing as similar as possible across the bus, I manually set the delay chains through the Assignment Editor. I might let the Fitter pick the settings first to get an idea what is a good value to try for my initial manual setting. I also make manual assignments to force usage of I/O cell registers. Letting the Fitter decide whether to use I/O cell registers based on timing can result in only some bits in a bus using them.
Altera_Forum
Honored Contributor
13 years ago
--- Quote Start ---
Here is the example that Godfather was referring to. It is part of a document that we are putting together on TimeQuest solutions. I believe this covers the exact situation that you are trying to constrain. It even has a Quartus archive of a test case embedded in the document. Hope this helps.
--- Quote End ---

Hi, jimbo.
I found the attached file "Async RAM Example". It is helpful to me. However, it is a part of some document. I tried to find the document but can not find it. Would you please tell me how to get it? Thanks.
Altera_Forum
Honored Contributor
13 years ago
Just thought I would chime in here. I've recently discovered that the PROPER method of constraining a purely asynchronous interface (like the DE2-115's async SRAM) is by using the Synopsys Design Constraint's 'set_data_check' command. Unfortunately, Altera does not support that particular command (they only support a subset of the full SDC syntax). Bummer! But if they ever do support it the appropriate syntax would be similar to this:

set_data_check -setup 2 -from o_SRAM_WE_n -to io_SRAM_Data

The above command says, "io_SRAM_Data must arrive 2ns before o_SRAM_WE_n". You would obviously get the appropriate setup time value from the SRAM's datasheet. The command is similar for the hold constraint:

set_data_check -hold 1 -from o_SRAM_WE_n -to io_SRAM_Data

The above is how you would constrain an asynchronous SRAM interface on an ASIC design using, for example, Synopsys Design Compiler and PrimeTime.

Cya!

Forum Discussion

Timequest constrains for async SRAM

14 Replies

Recent Discussions

retiming issue

Compilation Error (138001) Write permission

fanout issue

Questa-sim waveform- How to export to CSV?

Licencing error for Questa - Altera FPGA Starter Edition 2025.2 (Quartus Prime Pro 25.1std)