Thanks for the feedback guys, the only asynchronous signal is rst,
this is an input from some external supervisory cct, i want to
maintain this as i dont want external signals in an undefined state
before clk is stable.
Unless rst is glitchy, I don't think this is your problem, but you're
missing the point when it comes to rst. Since it comes in
asynchronous to the clock, what makes you think you'll end up in the
correct state when rst goes away if it happens to go away within the
setup time of the flip flop? That flop could go to either a '1' or a
'0' depending on the logic and precisely when rst goes away relative
to clk. Maybe it doesn't matter much for this particular process, but
any state machine or other clocked logic that is in your current
design may not like it very well and fail in odd ways.
The thing to think about is NOT what flops are doing when rst is
active, but what happens when rst is going away...and where does it go
away relative to the clock?
Hint1: Setup and hold times are requirements that must be met for
proper operation, not just nice to haves.
Hint2: No signal arrives at precisely the same time at two different
places, so two random flops in your CPLD will see 'rst' at slightly
different times.
The way you handle this is the same way you handle any asynchronous
input, you synchronize first into one and only one flop then use the
output of that flop. Generally people use two stage synchronizers in
order to reduce the effects of metastability.
clk, rw and Addr are all synchronous.
Well, how you think 'clk' can be synchronous is a mystery...maybe a
typo on your part. It appeared from your original post that rw and
Addr were coming in from external I/O pins, and now you've added that
they are synchronous. Since they are synchronous to clk you don't
need to synchronize them but that doesn't mean that there is no timing
analysis needed. To perform timing analysis you need to take the
following into account at a bare minimum:
- What is the clock skew between your CPLD and the external device
that generates rw and Addr (Call that Tskew).
- What is the clock to output delay between clk and rw as well as
between clk and Addr? (Call the larger of the two Tco).
- From the CPLD timing report, what is the setup time requirement for
rw and Addr relative to clk? (Call the larger of the two Tsu)
Now plug in the numbers and verify that you meet the following timing
requirement
Tsu < T - Tskew - Tco (where T=minimum clock period)
Repeat this process for every input to your CPLD.
Generally speaking, one would enter a setup time requirement into the
CPLD synthesis tools so that when it performs the timing analysis it
will tell you whether it has detected any timing violations. However,
even if you don't, it will produce a report telling you what the setup
time is and you can use that to calculate whether you have a problem
or not.
The other aspect of this is that your CPLD has outputs and those
outputs probably have requirements that must be met by the devices
that receieve those outputs. You do the same basic analysis but now
you're solving for Tco in order to determine what the clock to output
delay requirement that your CPLD must meet should be.
One thing
is that IntAddress is a type conversion of the actual input
address...
Not relevant.
Not sure if this would cause any issues, the qualification
is all zero wait state
You're focusing on the wrong things, you most likely have a timing
problem and you're not presenting anything to indicate that you've
performed any sort of timing analysis.
The other obvious timing thing to check from the CPLD timing report is
that the clock frequency that it computed your design can run at is
greater than the clock frequency of the actual clock used. Again, one
would normally enter that in as a timing constraint to the CPLD
synthesis tool to tell it that 'clk' has a requirement of say 100
MHz. That way it will flag it as a timing problem if it can't achieve
that number.
My concern is that any design changes made overcome the problems seen,
unfortunately this includes re-building the existing project without
any changes. This makes me wonder if i've really addressed the
underlined problem.- Hide quoted text -
Since the underlying problem is (with nearly 100% certainty) a timing
problem, the lack of timing analysis on your part would indicate to me
that you have not addressed the underlying problem. The analysis
isn't hard, but it is important. Failure to do so means you're
counting on luck to get you through...since you've seen your design
fail, your luck has run out.
Kevin Jennings