Timequest constrains for async SRAM

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.

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?

If you're registering your I/O, which is always recommended for best performance, than your I/O timing shouldn't really change. Just click on Report Datasheet, get the numbers and make the requirement a little bit looser. You will get an error if one of your I/O suddenly starts failing. The only benefit of a truly correct solution is if one I/O suddenly shifted and started failing, but the I/O on the other side of the transaction also shifted, which is unlikely. Yes, it would be nice if this could be done the right way, but if you do it this other way, you'll probably get the same results and it will always work, and it will give an error if something goes wrong.

Noting your next post, timing analysis is not a "how fast can that run" analysis. It is based on your requirements and is a pass/fail analysis. Now, in the simplest design where there is only one clock domain, you could probably get an accurate "how fast can that run" analysis, but as soon as you start having multiple domains interacting with each other, they don't scale like a single clock domain, for all sorts of reasons.

--- Quote Start ---

Here is the example that Godfather was referring to.

--- Quote End ---

It definitely doesn't work for me. I confirmed it doesn't consider the Tco for the outputs when they are used as clocks.

I assume it is because I am not using ALTDDIO. The document mentions that otherwise there is need to create an intermediary output clock, but doesn't give any details. Or possibly because the sample includes estimated outputs Tco in the Trace Board delays?

--- Quote Start ---

If you're registering your I/O, which is always recommended for best performance, than your I/O timing shouldn't really change. Just click on Report Datasheet, get the numbers and make the requirement a little bit looser.

--- Quote End ---

Yep, seems a good solution. I do am using fast I/O for the address and data bus, but I usually like to make one of the output enables (either the FPGA or the RAM one) combinational. I negate one with the other to avoid bus contention just in case.

Speaking about output enable, I realized that this is not constrained. I spent quite some time browsing Quartus handbook, and I couldn't find any reference whatsoever about how to constrain the high-Z and low-Z timing. Actually, I cannot even find these timing in the device datasheets at all!

Without any information, I can only assume the low-Z timing is similar to the micro tCO of the I/O element?

But even then, how can I associate the node that control the OE to the actual data nodes? Or at least how can I get a timing report for the OE node?

--- Quote Start ---

Noting your next post, timing analysis is not a "how fast can that run" analysis. It is based on your requirements and is a pass/fail analysis.

--- Quote End ---

Seems I didn't explain myself correctly. When I was talking about the "desired" frequency, I was talking about the value set in the PLL Megafunction, not in the SDC. I am not setting any frequency or period in the constrain file, but making TimeQuest to derive the frequencies from the PLL setting.

The problem is that both the Fitter and TimeQuest, take the PLL output frequency from the user selected value, not from the actual value (the PLL output clock as a result of the master clock division and multiplication) that sometimes is slightly different. The difference is quite small, probably not significant. So just a buglet in the worse case.

--- Quote Start ---

... I was talking about the value set in the PLL Megafunction, not in the SDC. I am not setting any frequency or period in the constrain file, but making TimeQuest to derive the frequencies from the PLL setting.

The problem is that both the Fitter and TimeQuest, take the PLL output frequency from the user selected value, not from the actual value (the PLL output clock as a result of the master clock division and multiplication) that sometimes is slightly different. The difference is quite small, probably not significant. So just a buglet in the worse case.

--- Quote End ---

If your PLL settings in the MegaWizard can't be implemented exactly, you probably got compilation messages (it seems like they happen in the Fitter, but I don't remember for sure) comparing the requested settings and the settings actually being implemented. I prefer to change the MegaWizard settings to the actually implemented values to get rid of these messages about the mismatch.

--- Quote Start ---

Speaking about output enable, I realized that this is not constrained. I spent quite some time browsing Quartus handbook, and I couldn't find any reference whatsoever about how to constrain the high-Z and low-Z timing. Actually, I cannot even find these timing in the device datasheets at all!

Without any information, I can only assume the low-Z timing is similar to the micro tCO of the I/O element?

But even then, how can I associate the node that control the OE to the actual data nodes? Or at least how can I get a timing report for the OE node?

--- Quote End ---

The output enable path will be reported if the data port is constrained by either set_output_delay or set_max_delay. Run report_timing with a data port in the -to field. With a high enough number for -npaths, you will see the paths for both the data register to data port and the output enable register to the data port.

--- Quote Start ---

If your PLL settings in the MegaWizard can't be implemented exactly, you probably got compilation messages (it seems like they happen in the Fitter, but I don't remember for sure) comparing the requested settings and the settings actually being implemented. I prefer to change the MegaWizard settings to the actually implemented values to get rid of these messages about the mismatch.

--- Quote End ---

I'm not getting any warning whatsoever. Of course that the difference is minimal, not really significant. Otherwise, if the difference is important, the MegaWizard does display a "red" warning that the PLL setting can't be implemented.

However I was wrong about TimeQuest using the "requested" frequency. It is just a cosmetic issue in the clock report, where the clock frequency displayed is rounded. The period is accurate and it is the actual one.

--- Quote Start ---

The output enable path will be reported if the data port is constrained by either set_output_delay or set_max_delay. Run report_timing with a data port in the -to field

--- Quote End ---

Ah, yes, I see it now, and it is being constrained automatically as another path.

I was right-clicking in the I/O report to make the Timing Report. But then the "from" field is set, and that's why it didn't include other paths.

It still seems odd to me that the datasheets don't even mention the Txz/Tzx timing. It was included in the older families.