Strange behaviour when synthesising with Quartus

Discussion in 'VHDL' started by joel.pigdon@gmail.com, Nov 2, 2006.

  1. Guest

    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
    , Nov 2, 2006
    #1
    1. Advertising

  2. Guest

    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

    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
    , Nov 2, 2006
    #2
    1. Advertising

  3. KJ Guest

    <> wrote in message
    news:...
    > 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, Nov 2, 2006
    #3
  4. KJ Guest

    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
    KJ, Nov 2, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Leventis

    Re: Quartus bug or wrong VHDL?

    Paul Leventis, Jun 24, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,468
    Paul Leventis
    Jun 24, 2003
  2. Panic
    Replies:
    2
    Views:
    5,221
    Marc Guardiani
    Oct 24, 2003
  3. Jan
    Replies:
    2
    Views:
    1,430
    Mike Treseler
    Dec 16, 2004
  4. Andy Chambers
    Replies:
    1
    Views:
    385
    Daniel Dyer
    May 14, 2007
  5. Replies:
    2
    Views:
    1,073
    David Bishop
    Mar 2, 2008
Loading...

Share This Page