Timequest constrains for async SRAM

[Altera_Forum]

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?

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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?

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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]

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]

--- 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]

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!