Forum Discussion

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

M_alu_result[10] was determined as clock . . . Why?!?

Hi all,

I got the follwoing message from Timequest:

Warning (332060): Node: ad_tpdb_qsys:inst13|ad_tpdb_qsys_nios2_0:nios2_0|M_alu_result[10] was determined to be a clock but was found without an associated clock assignment.

So, as you can see, this is a signal generated by QSYS and is inside the Nios II CPU. I have no idea, or hint why Timquest thinks this is a clock.

I tried to satisfy timequest by doing the following in my SDC:

create_clock -name test_clk -period 20 [get_registers {ad_tpdb_qsys:inst13|ad_tpdb_qsys_nios2_0:nios2_0|M_alu_result[10]}]

I told timquest this signal should be a clock of the fastest type I've got in my design (just because I diddn't know what clock period else I should use).

With this statement, Timequest reports no unconstrained clocks anymore and tells me, that the Fmax of this clock can be 500MHz(!!!!).

This leads to the conclusion that, in reality, no register is clocked by this signal because otherwise FMax would not be that big, would it?

I tried to let Timequest report to me the registers which it thinks are driven by this "clock" by doing this:

report_timing -from_clock [get_clocks test_clk] -to [get_ports *] -npaths 1000

or this:

report_timing -setup -npaths 10 -detail full_path -from_clock test_clk

report_timing -setup -npaths 10 -detail full_path -to_clock test_clk

but all i get is this:

Warning (332145): Command "report_timing" found in SDC file is not a proper SDC command and is being ignored

So the question is: What is goind on here and am i save if i just ignore the message that I have one unconstrained clock which to me seems not to be a clock?

Thanks,

Maik

Ah, I forget: I'm using "Quartus II 32-bit Version 11.1 Build 173 11/01/2011 SJ Full Version / Service pack Installed: None".

8 Replies

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

    You don't want to put your 'report_timing' commands in your SDC file. You can either run them from the TQ GUI (from the Tasks window), or type them in the Console window at the prompt, or better yet, put them in a Tcl script and run the script either from the menus or at in the console window with the command 'source <filename>.tcl'. If you can find the source of this clock with report_timing command (or even report_path commands), then you may be able to determine its actual frequency. You assigned this clock the frequency of 500 MHz by declaring it to have a period of 20 ns with the -period option on create_clock.

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

    Hu jimbo,

    thanks for your answer.

    Okay, now when I use those commands directly in the TQ console, they work . . . Now, I got some output to examine why this signal is determined as a clock. It feeds some onchip rom memory WE signal. Which should be also constrained by QSYS, shouldn't it?

    Okay, i have to dig a little deeper into this.

    The clock constraint for 50MHz (which indeed has a period of 20ns) was an approproate choice, I suppose.

    However, after re-compiling and re-running TQ, it reports a FMax for that clock of 437.64 MHz which it says is "limit due to minimum period restriction (tmin)".

    I'm still wondering why i have to care about internal QSYS timing constraints. maybe someone can explain?

    Regards,

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

    Sorry, my mistake on the -period 20 being 500 MHz. That should be 50 MHz as you point out. Unfortunately, QSYS doesn't currently output an SDC file to my knowledge, but I believe they are working on that.

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

    Hi,

    QSYS does create an SDC file which I also included in my TQ analysis.

    However, there are no clocks defined in this SDC file. Maybe that is the problem. It seems that I solved th issue by applying my own clock definition to this signal. It#s just a little unconfotable that I have to care about QSYS timing constraints, as I don't really know what the mentioned signal is doing.

    Thanks for you hints regarding the correct usage of report_timing!

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

    The mesage "was determined to be a clock but was found without an associated clock assignment" means what it says: The signal is acting as a clock in your design, usually driving the clock input of a FF respectively used in an edge sensitive expression.

    You should check why this happens and if the usage is actually intended.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi,

    the message is well understood. I'm just wondering why, when this is a QSYS design, QSYS does not write this clock definition to the SDC file.

    It can be either that the SDC creation of QSYS is still just in some case of beta state or that QSYS itself is not aware that the design it creates leads to the assumption of TQ that some signal is used as a clock.

    For me as the user of QSYS and TQ (and quiet not an expert as the subject is far too complex), I kind of relay on the tools, that they know what they are doing and that they prepare all recommended dependencies correctly.

    I tried to evaluate why TQ thinks that this signal is a clock by using the report_timing command. I got some output from this, but I just didn't had the time to examine it because I have some kind of preassure on my main project which is to design a working firmware for our product.

    In my opinion it is sufficient to assign the clock speed of 50MHz to this determined clock as this is the fastest clock in my design. So it should be fine under all circumstances, right?

    Regards,

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

    --- Quote Start ---

    the message is well understood.

    --- Quote End ---

    I don't understand why apparently a combinational or registerd signal is used as a clock. This effectively creates a new clock domain that causes at least difficulties in timing closure with the primary clock domain. Or it would be treated as unrelated clock domain using full cross domain synchronization.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Okay, then you are saying that it could be that I'm not fine with my clock definition but that i also do have to examine clock domain issues?

    I still believe that this must be some kind of "missunderstanding" by TQ or QSYS, because, as I said, FMax can be around 480MHz. To me it sounds as if this "clock" can cause no real problem because it seems that nothing really is connected to it. Otherwise I suppose, FMax would be much smaller . . .

    Maik