Constraining internal logic?

Have you added a clock frequency requirement?

Does Time Quest report that it is meeting the clock requirement?

--- Quote Start ---

I have a bug somewhere in my design that causes data loss. All I/O has properly been constrained and verified ok. When compiling in LAI (Logic Analyzer Interface) configuration in my design (so i can debug the problem) i can no longer reproduce the issue. This tells me that internal timing changes when enabling the LAI.

The Altera documentation states that *all* paths should be constrained (even internal paths). How do i handle this? I would assume that Quartus II *knows* the tsu and th of all internal registers and that I, as user, would not have anything useful to add to the equation. Is it required to add a "default" tsu and th to all internal paths?

I'm using Timequest.

Thanks,

/John.

--- Quote End ---

Hi John,

did you try different Quartus Versions?

By implemeting Signaltap or the Logic Analyzer Interface and use of pre_synthesis nodes you do not change only the routing and placement. The synthesis results are also different.

--- Quote Start ---

The Altera documentation states that *all* paths should be constrained (even internal paths). How do i handle this? I would assume that Quartus II *knows* the tsu and th of all internal registers and that I, as user, would not have anything useful to add to the equation. Is it required to add a "default" tsu and th to all internal paths?

--- Quote End ---

Quartus does know the micro tsu, th, and tco of all internal registers, but the internal paths are not constrained unless you have a clock constraint as batfink said. Run "Report Unconstrained Paths" and "Check Timing" to see if you are missing any constraints.

All clocks are constrained. My SDRAM outputs were however not properly constrained since i had a syntax error in the SDC lists (used comma between names instead of spaces). Perhaps this caused the timing to be off when i added the LAI configuration. I will do more testing to see if i can reproduce the error. It is possible that the SDRAM address was transferred incorrectly (which would explain the data loss).

I also have a lot of asynchronous data and control signals that are hooked up to a CPU that are flagged unconstrained. The CPU is executing off the same base clock as the FPGA so in theory the CPU and FPGA clocks are related but since i don't know the timing of I/O from the CPU i treat all these signals as asynchronous. I was planning to add synchronizers to all inputs from the CPU to the FPGA. All Input ports on the CPU (from the FPGA) should already contain synchronizers since they are regular I/O ports. Anything in addition i should think about?

Thanks,

/John.

I now have other internal signals that i suspect are not meeting timing (although not flagged by quartus II). I have an SDRAM FIFO Controller which implements a circular buffer. I have a read pointer and a write pointer, both 26 bits. These pointers are being updated in Verilog (write_pointer <= write_pointer + 26'd8) as words are being burst in chunks of 8 words from / to the SDRAM. The problem is that it looks like the new pointer value is not stabilized before the next clock edge comes around which results in the circular buffer incorrectly flags as full.

How can i add an SDC constraint for *internal* signals such that i can be confident that the micro tsu/th is met? The clock domain is meeting fmax requirements with some 50 MHz to spare.

Did you run "Report Unconstrained Paths" and "Check Timing" as I suggested? If they don't list anything unconstrained, then TimeQuest is analyzing all internal paths. You don't add constraints specifically to make TimeQuest analyze micro tsu and micro th.

Be sure you are analyzing with all timing models. If you are using just the slow model, you might be missing hold violations.

If this is Cyclone III or Stratix III, use derive_clock_uncertainty. If you didn't use that, your real slacks are less than what is currently being reported.

--- Quote Start ---

Did you run "Report Unconstrained Paths" and "Check Timing" as I suggested? If they don't list anything unconstrained, then TimeQuest is analyzing all internal paths. You don't add constraints specifically to make TimeQuest analyze micro tsu and micro th.

Be sure you are analyzing with all timing models. If you are using just the slow model, you might be missing hold violations.

If this is Cyclone III or Stratix III, use derive_clock_uncertainty. If you didn't use that, your real slacks are less than what is currently being reported.

--- Quote End ---

Yes, i have run all TimeQuest reports and no warnings or errors occur in any of the timing models. My device is a Cyclone II. fmax is some 40% higher than the clock frequency used so there should be plenty of margin for the counter input to the 26-bit registers to stabilize.

I have checked in the RTL viewer and everything seems ok.

Does it *ever* happen that Quartus II or TimeQuest makes mistakes?

Even with a large setup slack, you could have a hold violation (hold is independent of frequency). Most uncertainty is covered by guard bands in the timing models of devices older than 65 nm, but you might need some clock uncertainty for something like PLL jitter. If you have small hold slacks reported with no uncertainty, then your actual slack might be negative when accounting for everything like jitter and the uncertainty in the phase relationship between two PLL outputs.

You might have something asynchronous that you are not aware of. Run the Design Assistant and go through its warnings.

If you find no problems indicated by regular compilation warnings or Design Assistant warnings and have positive slack over process/voltage/temperature even for hold with uncertainty added for PLLs, then a service request is probably appropriate.

Thanks for the suggestions Brad. I have found the issue (a Verilog issue). The bug went away except for very rare glitches which could be attributed to jitter. I will incorporate this in my SDC too.

Thanks,

/John.