Forum Discussion

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

TimeQuest Timing Analyzer - control signal marked as clocks

I was creating a constraint file which consists of two clocks, but errors were generated complaining about certain control signals be identified as clocks. For example, the SS signal (Slave Select) was designated by Timequest as a clock signal. First question: What is it about certain signals that TimeQuest will designate them as a clock signal ? Why wasn't MOSI or MISO marked as a clock signal that needs clock constraints identified? What should I do to satisfy TimeQuest to move forward (i.e, applying periods to signals that are aperiodic)

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I sent an email to a very similar question yesterday, so cutting and pasting from there(in there case they were pretty sure the problem was an inferred latch, but the steps are similar no matter what it's driving).

    I usually do a “create_clock -name missing_clk -period 10.0 {name_of_unconstrained_clock_signal_in_report}”. Then update the timing netlist and do a “report_timing -detail full_path -to_clock missing_clk -panel_name missing_clk”. Then look at the Data Required Path and you should see it start at the clock you just constrained and proceeding to the latch.

    You might be able to get away with running derive_clocks -period 10.0 instead of manually doing the create_clock.

    And just type the word latch in the search box for synthesis messages, as that’s what it is in 95% of these cases.

    ----------

    Once you find the issue, the question is if it's correct. Ideally you don't want some internal node being used as a clock and you code it so it uses the main clock instead. That's the best fix and you don't have to worry about how to time it.