Strange behaviour when synthesising with Quartus

Hi all,
We had some strange behaviour with our project today. We have been
using Mentor Graphics HDL Maker, ModelSim and Quartus for our
university project. The code simulated fine in ModelSim, everything was
perfect. However when synthesised onto the Flex10k device we had
everything worked fine except for one signal. We revised our code and
retried various approaches all with the same result. Next we combed
through the output of the synthesiser to try and find any relevant
errors. We had a simple slow speed project so most of the errors were
from timing violations.
As a last approach, which should probably have been a first approach,
we took all of the signals to output pins on the device so we could
observe their state. With that simple change in HDLMaker, just adding
three more output ports and wiring them up to the existing signals
between modules the difficult signal started working.
I assume this is something to do with optimisation in the synthesiser.
But I don't think it should have done it.
Has this happened to anyone else?
What can I do to prevent it happening again? Is it because of bad
coding style?
What errors or warnings does Quartus give when it's done something like
this?
Try to take it easy on me, I am a university student but this is for my
own knowledge not any homework question
Thanks
Joel

 

Sorry this should have been posted to comp.arch.fpga, which it now has
been.
everyone is still invited to comment,
sorry about the crosspost.
Joel

joel.pig...@gmail.com wrote:

Hi all,
We had some strange behaviour with our project today. We have been
using Mentor Graphics HDL Maker, ModelSim and Quartus for our
university project. The code simulated fine in ModelSim, everything was
perfect. However when synthesised onto the Flex10k device we had
everything worked fine except for one signal. We revised our code and
retried various approaches all with the same result. Next we combed
through the output of the synthesiser to try and find any relevant
errors. We had a simple slow speed project so most of the errors were
from timing violations.
As a last approach, which should probably have been a first approach,
we took all of the signals to output pins on the device so we could
observe their state. With that simple change in HDLMaker, just adding
three more output ports and wiring them up to the existing signals
between modules the difficult signal started working.
I assume this is something to do with optimisation in the synthesiser.
But I don't think it should have done it.
Has this happened to anyone else?
What can I do to prevent it happening again? Is it because of bad
coding style?
What errors or warnings does Quartus give when it's done something like
this?
Try to take it easy on me, I am a university student but this is for my
own knowledge not any homework question
Thanks
Joel

 

[KJ]

<joel.pigdon@gmail.com> wrote in message
news:1162469084.174546.245130@e3g2000cwe.googlegroups.com...

Hi all,
We had some strange behaviour with our project today. We have been
using Mentor Graphics HDL Maker, ModelSim and Quartus for our
university project. The code simulated fine in ModelSim, everything was
perfect. However when synthesised onto the Flex10k device we had
everything worked fine except for one signal. We revised our code and
retried various approaches all with the same result.
I would've taken that one errant signal and ascertained under just what

conditions it could be 'wrong' and then bactracked to the source. Changing
a 'broken' design without knowledge of what is fundamentally broken is not a
good debug approach.

Next we combed
through the output of the synthesiser to try and find any relevant
errors. We had a simple slow speed project so most of the errors were
from timing violations.
Slow speed and yet you say had timing violations.....note, timing violations

are design errors that indicate the design will not always (maybe never)
work properly.

As a last approach, which should probably have been a first approach,
we took all of the signals to output pins on the device so we could
observe their state.
First approach should have been static timing analysis.

With that simple change in HDLMaker, just adding
three more output ports and wiring them up to the existing signals
between modules the difficult signal started working.
I assume this is something to do with optimisation in the synthesiser.
But I don't think it should have done it.
The timing changed which is the reason it appears to 'work'. Now you've

made it worse though. You 'think' you've fixed it but you haven't (hence
your question here because of the nagging feeling) so now you have a design
with a latent design error and you no longer have a 'broken' system to
debug. I'd suggest going back to the original code that had the problem,
since that had the demonstratable error.

Has this happened to anyone else?
Can happen to anyone who happens to debug a design that has a timing

violation that also didn't perform static timing analysis on as well.

What can I do to prevent it happening again?
Perform static timing analysis.

Is it because of bad
coding style?
Doubtful.

What errors or warnings does Quartus give when it's done something like
this?
Fails the static timing analysis.

Try to take it easy on me, I am a university student but this is for my
own knowledge not any homework question
OK, then take the repetition about performing static timing analysis as the

well intentioned advice that it is. Good luck

KJ

 

[KJ]

In addition to timing, also look at the synthesis log and inspect any
warnings and understand what they are all about since synthesis
'warnings' are usually run time 'errors'. Some things that it will
warn about are:
- Combinatorial latches (get rid of them, they are a likely source for
timing problems).
- Incomplete sensitivity lists (add the missing signals and recheck to
see if your sim still works. If it still works the same way then this
was not the problem. If it works differently AND matches what the
actual board is doing, then you're home free. Debug the problem in the
simulator, rebuild and retest).

These types of things I guess could be considered 'coding style' types
of things since those who write code using unclocked processes tend to
have these problems at some point whereas those who only use clocked
processes and very few (if any) unclocked ones tend to not have these
problems.

KJ