Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Strange behaviour when synthesising with Quartus

Reply
Thread Tools

Strange behaviour when synthesising with Quartus

 
 
joel.pigdon@gmail.com
Guest
Posts: n/a
 
      11-02-2006
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

 
Reply With Quote
 
 
 
 
joel.pigdon@gmail.com
Guest
Posts: n/a
 
      11-02-2006
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

(E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      11-02-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.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


 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      11-02-2006
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
synthesising fixed_pkg mvjijuaie@gmail.com VHDL 2 03-02-2008 12:04 AM
debugger behaviour different to execution behaviour Andy Chambers Java 1 05-14-2007 09:51 AM
Quartus II error - use clause error... - very strange behaviour Jan VHDL 2 12-16-2004 03:33 PM
Strange error in Quartus II 3.0 Panic VHDL 2 10-24-2003 01:42 AM
Re: Quartus bug or wrong VHDL? Paul Leventis VHDL 0 06-24-2003 02:10 AM



Advertisments