Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

can quartus break the compilation?

Hi Experts,

I've ran into very weird problems. I have a design which is simulated (including time simulation), works in testbench without any problems. then i burn it in and under 'certain' conditions it works, sometimes it does not work. I've found that these problems are somehow related to:

1) whether one uses signal tap analyser to observe data (surprisingly with stp it works 'sometimes' better)

2) on how full the FPGA is (my code is around 80%)

3) how good mood has quartus

from unknown reasons even the slightest change in the design, completely irrelevant to functionality (e.g. adding new pin in the top entity _without connecting it_) finishes with broken design.

does someone experience the same problems? how can I deal with those things? Is there any way how to compare what is different when the design works and when the design breaks? I know that the problems I have are very weird, however I'm not the first one who experiences the same behaviour with altera chips. It seems that without using the incremental compilation quartus starts from scratch and sometimes it does not generate good code. Or maybe I have not specified correctly the timing requirements. Could someone give me a hint what could be wrong?

I did not try to use xilinx chips whether they 'behave' when using the same design.

thanks

david

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Usually this indicates a timing problem. Did you properly constrain all your input/outputs, and do you have any critical warning from Timequest when you compile your design?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    well, depends what is constraints. i have constrained all the clocks in the system in belief that it is sufficient. i'm not using timingquest. still old good classic timing analyser with default required fmax=100MHz. Maximum frequencies in the design are of that order. I have in the design an interface which provides communication between cpld and fpga. the clock-enable is generated in the cpld acting as a master, transported via +-10cm long pcb track into fpga. both are using 40MHz clock (the same) so one would think of phasing problems. this is however not the case as majorily it does not hang on communication. it hangs on processing of the data itself in a statemachine because it is waiting on a signal which apparently never arrives. another issue is, that if one connects stp to the affected signals, it starts to run properly.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    i had these mysterical behavioral when i started with quartus that adding signaltap lead to a different behavioral of the design.

    daixiwen is correct, it was some kind of timing problem.

    to specify only the input clock and maybe indirectly other clocks via a pll does not constrain the design.

    do you have a fully synchronous design ?

    or do you have some logic that depends upon more than only one clock ?

    i had designs where a verilog code

    always @ ( posedge clk or negedge nreset)

    lead to nreset as a clock signal, but only for a few registers within the same modul.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You say you have multiple clocks?

    Are these all generated via PLLs, or do you create some of them via logic? Is data passed between the domains safely (double buffering or FIFOs)?

    Is the design fully synchronous, or are you adding logic delays deliberatly to re-balance timings manually?

    Are you adding a phase shift to clocks going off chip to try and align the data with the clocks without using a PLL feedback input to automatically adjust for skew?

    Any of these can cause the problems you describe, and can cause situations where on some compilations it works and some it doesnt.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    There is 50MHz XOSC generated onboard and feeds both cpld and fpga. another 40MHz clock is generated from outside (external sma input). it is a VME card, VME communication is driven by 50MHz clock, 40MHz stuff is driven completely separately using information from VME registers, however this information is 'almost static'. i.e. changes once every five seconds or so (in case of interest see design: http://svnweb.cern.ch/world/wsvn/fi/lhc/projects/lhcb_calibrator/branches/broken_dac_pin_newlineariser/vhdl/#path_lhc_projects_lhcb_calibrator_branches_broken_dac_pin_newlineariser_vhdl_)

    I have tried to make everything fully synchronous hence no async or time compensation of async should appear. it does not hang on communication. it hangs in random state machine inside fpga and it is caused by not-catching operation finished impulse (although those are always generated in the same clock domain)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Is there any relationship between this "operation finished" pulse and a signal coming from a different clock domain? Even if those clock domain crossing signals are almost static, you could face metastability issues if they decide to change at a really bad time. This can create a chain of events that put state machines in strange states. You should really put synchronization registers between the two domains, just to be on the safe side. As they are slowly changing, just two D-flip-flops in series should do the trick, and will have a minimal impact on your design. If after that you still have the same phenomenon, we can definitely rule out clock domain crossing as the cause of your problem.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    dear all, thanks for all fruitful responses. i need to digest all that. it seems really a timing problem. i try to setup the advanced timings and try to find what could be wrong.