Honored ContributorHello everybody
Is adding clock uncertainty in TimeQuest a good idea when timing analysis says that everything is OK but the Design still does not operate correctly? Can clock uncertainty lead to a more robust fitting result or a more pessimistic timing analysis?
Honored ContributorHonored ContributorHonored ContributorHonored Contributor
-- reset is asynchronous signal from other block
state.clk = clk;
if
-- synchronize reset with clock of machine
dff(reset, clk)
then
state = s0;
else
case state is
when s0 =>
...
when s1 =>
...
when s2 =>
...
end case;
end if;
state.clk = clk;
state.reset = reset;
-- reset is asynchronous signal from other block
state.clk = clk;
if
-- synchronize reset with clock of machine
dff(reset, clk)
then
state = s0;
else
case state is
when s0 =>
...
when s1 =>
...
when s2 =>
...
end case;
end if;
state.clk = clk;
state.reset = reset;
Other things to consider are that this may be a power / bypassing issue or perhaps a simultaneous switching noise (SSN) issue and not a timing issue.
We had similar issues to yours - sometimes the design would work and then with seemingly trivial design changes it would stop working. In our case it looked like the FPGA was getting "reset" (all state machines, registers, etc. went to reset state) as a result of driving certain combination's of outputs - basically SSN issues. SSN is more likely in QFP packages and there are some forums or web info on SSN with respect to Altera parts you can search for. If there is noise on the power lines, or marginal bypassing, it's possible this could be effecting the operation. Changes to the design effect the routing and placement which may put susceptible signals closer to problem areas.Honored ContributorThanks for the advice StefanLevie. Actually I'm using a Cyclone II in a 240 pin PQFP so this could be an issue. However the layout and decoupling is above average in my opinion.
By the way I found out that some of the problems happended outside the FPGA but not all.
