Timing issues in implemented design

Question

Hello everyone,
I have been reading in these forums for a long time now, but have never posted. Possibly because I have never had such a design-specific issue that was above my knowledge...I wish my problem was more "friendly" for a first post.
Anywho, my problem is as follows: I've been working on a design for a few months now and everything was working fine up until recently (apart from logic errors of course that I would run into and fix here and there). I recently integrated a module that I did not design myself. My behavioral simulations work fine and all of my previous functionality seems to be working as well when the design is implemented. However, the functionality based on the "foreign" module has introduced problems.
What I am using: Spartan 6-XC6SLX16 and therefore ISE
Here are some of the functional symptoms I have recorded so far:
- The functionality always produces the same output after the design is implemented and uploaded
- The functionality can differ if I change something (no matter how small or where) in the design itself
- The same applies for changing constraints
- After some implementations+uploading the functionality works correctly, and in other cases it fails by either producing erroneous results or just "getting" stuck (i.e. one of my FSMs)
- The critical path w.r.t. my system clock is in the module that seems to be the source of the problems
This leads me to believe that there is some timing-related issue. The only timing related constraint I have used is for my system clock period. The timing report does not show any errors regarding this constraint.
My guess so far would be that I have an unconstrained path problem, possibly in combination with insufficient account for system and input jitter, as the design does take up around 40-50% of FPGA. The problem is that I have no experience in tracking such an issue down, so I could definitely use some pointers in the right direction.
Things I have tried:
- Basic logic debugging of the input-output behavior of the problematic functionality using chipscope
- Post-PAR simulation of the module that includes "foreign" components: Works fine with a 100MHz constraint
- Increasing the frequency constraint for the entire design from 100 to 120 MHz but that was just out of lack for better ideas, it did not help.
- Looking at the unconstrained paths that the timing analysis can provide. I was hoping to find something related to the component that seems to be causing the problems, but no luck. Mainly just entries related to all of the ring oscillators that I am using, which it seems to be interpreting as a clock domain crossing case. These, however, have nothing to do with the problematic portion of the design.
I have a few questions at this point:
-Can one problem lead to a totally uncontrollable landslide of other seemingly independent problems?
-Also, how do I make sure that I get ALL of the unconstrained paths and not just a subset?
-Could it even be an unconstrained path issue if nothing in the report indicates that there is an unconstrained path in the problematic region?
I hope I have described my problem thoroughly enough for you to make some educated assumptions about what could be going wrong. I'm interested in learning what typically causes such problems. I am aware of synchronizing between clock domains, or the de-assertions of asynchronous resets, the standard problems...but I missed something critical here and I don't want it to happen again. Perhaps somebody has a pointer for me where I could do a little more digging?
I will set up a timing simulation of the entire design, but as this is a rather lengthy process it will be some time until I get some results.
Cheers,
Shibby

Answer 1

Hello,
Thank you for the quick replies so far.
austin wrote:
So, my questions to you are:
Did you review the entire (verbose) timing report?
What is your smallest positive slack number?
What is your system jitter? Your clofck source jitter?
How well is the device bypassed on the board you are using (is it one of ours, or one from our distributors)?
- Yes, I went over the entire verbose timing report that DIDN't cover unconstrained paths. However, when I did have the timing analyzer output unconstrained paths as well, there were a lot of timing errors. I assume this is due to the fact that unconstrained = period requirement of 0 and the slack is therefore always negative? I had a look at these and none of them really indicate a problem to me.
- The smallest positive slack in the case of the standard verbose timing report was 0.304ns.
- The system jitter is (the default?...I did not specify it in my UCF) 0.070ns. The other jitter values (TIJ and DJ) are both set to zero. So the resulting clock uncertainty is very small...possibly too small.
- The board is a Nexys 3 from Digilent. I assume they know their stuff when it comes to capacitive bypassing of ICs. How would this play a role? If I've understood correctly then this is correlated to the system jitter. Bypassing problems would lead to larger/more frequent voltage dips (especially for larger designs) and therefore a clock that exhibits more/larger uncertainty (i.e. jitter)?
I think my lack of knowledge in correctly constraining larger designs might be causing the problems here. But perhaps also not, so just to be sure, I want to ask the following (possibly stupid) questions:
- Instead of increasing parameters related to jitter of a certain clock, wouldn't increasing the period constraint of that clock have the same effect? As I wrote, increasing for example the system clock constraint to 120MHz rather than 100MHz showed no improvement of the problem...I'm not sure what this tells me...if anything at all.
- I do have another clock domain and I do synchronize signals (there is nothing big going on, mainly just handshaking) between the two domains. What could the effect be if I removed the period constraint for one of the clocks apart from possible timing problems in that clock domain?
- The ring oscillators that I have clock certain FFs if oscillators enabled, however I do not know their exact frequencies. Would it suffice to just use a known upper bound?
The latter two questions concern parts of the design that habe been there for a long time and have no functional connection to what was added that seems to be causing the problem, though.
austin wrote:
ISE ignores clock domain crossing (Vivado does not, but Vivado only supports 7 series and later devices). Do you have any unidentifed clock crossings that require synchronizers?
 Yes, I do. As mentioned above I synchronize my handshake signals between clock domains using simple level synhronizers (since I'm not doing anything fancy like transforming pulses). I am also synchronizing the de-assert of my asynchronous system reset in both clock domains using standard reset bridges, which are basically just level synchronizers.
Interestingly, the timing report containing unconstrained path info tells me that one constraint was not met whereas the other one does not. It also concludes that the maximum frequency is lower than 100MHz, but gives the same result for the system clock. If I've understood correctly, this is due to the fact that there is an unconstrained path with maximum combinational path delay larger than 10ns. I had a look at this path (there are a few of the same type) and it is a path that I don't think needs to be constrained, so I wouldn't see this as the issue. 
Albeit having looked at the timing reports, I wouldn't exclude that I've missed something, simply because I haven't dealt with such problems until now. So, I'm not sure whether or not it would be helpful to attach both the standard verbose timing report and the one including unconstrained paths...but perhaps someone could point me to something that might seem fishy..?
One thing I will do is continue to try and isolate the location of the problem using timing simulations or possibly stripping the logic of certain components and checking the behavior of the implemented design.
Best regards,
Shibby