Honored Contributor
Honored Contributor4) Through "Report Delay" assignments, I managed to get the delays for the ASRAM signals. Looking at these delays, the following question comes up:
Why does the Timing Analyzer not report timing violation, even if the timing constraints are not met? For example, I have entered a Tco Requirement of 7.5ns for the SRAM1_CS_n pin, but the reported maximum delay is 16.912ns for this pin. Have I entered invalid constraints? Or is the reported delay not what I expect it to be? Is it valid to enter the PLL's "_clk0" output as a clock source for the Tco Requirement? 1) & 2) As you have suggested, I have enabled the Fast/Slow timing analysis. Both models do not produce any timing violation messages. 3) At 80MHz, the ASRAM is too slow to complete a transfer in one clock cycle, especially the write cycle. Therefore, I have designed my interface so that it generates the timing for the ASRAM in two cycles. This also means that the Address and CS signals remain stable over a period of two cycles. 5) The next thing I will do is to try my design with Quartus v7.2 (if this version works without problems) because there might be a bug in the Timing Analyzer in v6.1. While developing the ASRAM interface for Cyclone I, I have already used SignalTap to debug my transfers, anyway I will now also try and put a SignalTap into my Cyclone II design so that I can be sure nothing has changed since then. I understand that IO constraining is important, but until now it simply didn't work. Constraining gives the impression that things are under control, determined... but if it never works, the whole thing is useless and brings up more uncertainty and mistrust than confidence. Especially in my case, where the thing worked at Cyclone I already without any constraints.
