same constraint, different compiling time

[Altera_Forum]

My system has 360 input signal and need to be constraint as clock. 

I use the following two method to create clock:  method 1: create_clock -name {FREQMeasure_ChannleIn} -period 10000.000 -waveform { 0.000 5000.000 } }] method 2: set FREQMeasure_Total_Channel 360 for {set loop 0} {$loop < $FREQMeasure_Total_Channel} {incr loop} { puts "loop is $loop" create_clock -name FREQMeasure_ChannleIn_Clk -period 100000.000 FREQMeasure_ChannleIn }  Compiling elapsed time for method 1 is 50 minutes. Compiling elapsed time for method 2 is 80 minutes.  the result for two compilation are the same.  Is there anything I should take into account?

[Altera_Forum]

Hello David, 

 may be the question sounds heretical. Could it be, that you're spending at lot of effort constraining a clock that is simply unrelated? If it's unrelated, the only condition to be met is, that the counter driven by this clock must be fast enough to follow the input. Synchronization to system clock must be performed anyway, but doesn't require constraints.  If you want to simply tell a common fmax for all clock inputs, the first syntax should be appropriate, unless you don't combine clock inputs in your logic, which probably isn't the case.  Regards, Frank

[Altera_Forum]

for {set i 0} {$i<16} {incr i} { 

create_clock   -period 10.000   -name clk[$i]   [get_ports "clk[$i]"] }  The above code works fine for me. I attaced my example source code. Maybe your design is different for some reason?

[Altera_Forum]

The 360 input signals are unrelated and they never crossing into each other domain. 

So I think the two constraints listed above should result into the same result.  In fact, they output the same result actually. But what confused me is why there exist so large compiling time different between them.  Thanks for you response!

[Altera_Forum]

If the assignments are no longer being ignored as you stated in another post then this is a different issue. Method 1 and 2 are doing different things. Method one creates 1 abstract clock object and applies that same clock object to 360 different ports in the design. Method 2 creates 360 different clock objects and assigns one each to one of 360 different ports in the design.  

The fitter works by optimizing each clock domain independently so in method one you have only 1 clock domain to be optimized. In method two you have 360 independent clock domains to be optimized.  If all 360 clocks arrive at the chip at the exact same time (which seems to be the case if you can use either method 1 or 2) then you should use method 1 in order to save compile time. If each clock domain will eventually be given a slightly different offset with respect to each other than you should use method 2.

[Altera_Forum]

--- Quote Start ---  for {set i 0} {$i<16} {incr i} {  create_clock   -period 10.000   -name clk[$i]   [get_ports "clk[$i]"] }  The above code works fine for me. I attaced my example source code. Maybe your design is different for some reason?  --- Quote End ---    Wow...I find the different:  [get_ports {In_Target_Signal[$i]}]  VS  [get_ports "In_Target_Signal[$i]"]  I am not farmiliar with tcl. It will be very appreciated if you can explain for me. :)

[Altera_Forum]

square brackets mean execute the command and return the value: 

> set sum [expr 3.0 + 4.0 + 5.0] > 12.0 Curly brackets mean everything inside should be take literally: > set sum {expr 3.0 + 4.0 +5.0} returns: > expr 3.0 + 4.0 + 5.0 (i.e. sum is a list, where the first member is expr, the second member is 3.0, etc.  Quotation marks are used for a list also, but not as literal: >set sum "a [expr 3.0 + 4.0] b" sum is now a list, with the first member a, the second member 7.0, and the last member b  The big problem is that Quartus(and most tools) use square brackets for node indices. So if you want a simple node: get_ports data get_ports "data" get_ports {data} all three of these are the same thing. But if grabbing a member of a bus:  get_ports data[3] get_ports "data[3]" get_ports "data\[3\]" get_ports {data[3]" The first two will fail since it will try to execute the command 3. The second two will work with what you want. But if you're passing in a variable, you need to use quotes: get_ports "data\[$i\]"  It takes a little getting used to, but all languages tend to be confusing in this area. (Or they're too strict and severely limited if they don't have lots of options.)

[Altera_Forum]

--- Quote Start ---  If the assignments are no longer being ignored as you stated in another post then this is a different issue. Method 1 and 2 are doing different things. Method one creates 1 abstract clock object and applies that same clock object to 360 different ports in the design. Method 2 creates 360 different clock objects and assigns one each to one of 360 different ports in the design.  The fitter works by optimizing each clock domain independently so in method one you have only 1 clock domain to be optimized. In method two you have 360 independent clock domains to be optimized.  If all 360 clocks arrive at the chip at the exact same time (which seems to be the case if you can use either method 1 or 2) then you should use method 1 in order to save compile time. If each clock domain will eventually be given a slightly different offset with respect to each other than you should use method 2.  --- Quote End ---    Hi,  The 360 input signals are unrelated so they won't arrive at the chip at the exact same time. But they never crossing into each other domain. So I think the two constraints listed above should result into the same result. Am I wrong?

[Altera_Forum]

--- Quote Start ---  square brackets mean execute the command and return the value: > set sum [expr 3.0 + 4.0 + 5.0] > 12.0 Curly brackets mean everything inside should be take literally: > set sum {expr 3.0 + 4.0 +5.0} returns: > expr 3.0 + 4.0 + 5.0 (i.e. sum is a list, where the first member is expr, the second member is 3.0, etc.  Quotation marks are used for a list also, but not as literal: >set sum "a [expr 3.0 + 4.0] b" sum is now a list, with the first member a, the second member 7.0, and the last member b  The big problem is that Quartus(and most tools) use square brackets for node indices. So if you want a simple node: get_ports data get_ports "data" get_ports {data} all three of these are the same thing. But if grabbing a member of a bus:  get_ports data[3] get_ports "data[3]" get_ports "data\[3\]" get_ports {data[3]" The first two will fail since it will try to execute the command 3. The second two will work with what you want. But if you're passing in a variable, you need to use quotes: get_ports "data\[$i\]"  It takes a little getting used to, but all languages tend to be confusing in this area. (Or they're too strict and severely limited if they don't have lots of options.)  --- Quote End ---    Thanks very much for the detailed explaination. Is there any book about FPGA you have written? I think you are qualified for a writer.

[Altera_Forum]

Sorry, no books about FPGAs.

[Altera_Forum]

Could you answer my question? 

  --- Quote Start ---  --------------------------------------------------------------------------------  Quote: Originally Posted by godfather  If the assignments are no longer being ignored as you stated in another post then this is a different issue. Method 1 and 2 are doing different things. Method one creates 1 abstract clock object and applies that same clock object to 360 different ports in the design. Method 2 creates 360 different clock objects and assigns one each to one of 360 different ports in the design.  The fitter works by optimizing each clock domain independently so in method one you have only 1 clock domain to be optimized. In method two you have 360 independent clock domains to be optimized.  If all 360 clocks arrive at the chip at the exact same time (which seems to be the case if you can use either method 1 or 2) then you should use method 1 in order to save compile time. If each clock domain will eventually be given a slightly different offset with respect to each other than you should use method 2.   Hi,  The 360 input signals are unrelated so they won't arrive at the chip at the exact same time. But they never crossing into each other domain. So I think the two constraints listed above should result into the same result. Am I wrong?  --- Quote End ---    P.S. Any other book?

[Altera_Forum]

--- Quote Start ---  Hi,  The 360 input signals are unrelated so they won't arrive at the chip at the exact same time. But they never crossing into each other domain. So I think the two constraints listed above should result into the same result. Am I wrong?  --- Quote End ---    You are correct. If each domain is independent in the design you can apply one clock constraint to them all.

[Altera_Forum]

By the way, and just to be sure, you keep saying 360 inputs signals, but you mean 360 input signals that are clocks? I've never seen 360 different clocks on a signle board and wanted to make sure that is the situation. (I'm also concerned about how they're all handled, but I think that's been the gist of all the postings so far.) Needless to say, you have a very complicated design.

[Altera_Forum]

Hello, 

 just want to remind my comment, that I'm not sure, if the said 360 measurement or "clock" signals need constraints at all. It depends on the kind of processing, that is performed with this signals, e. g. frequency counting, intervall measurement, etc. In other words, I doubt if the discussion, beside giving interesting insights in Timequest operation, has an actual object.  Regards, Frank