same constraint, different compiling time

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

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?

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!

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 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. :)

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 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?

--- 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.

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?