Logiclock TCL flow -- near completion

[Spyros Lyberis]

Hi everyone,

I'm near the completion of the final TCL flow for a Quartus II
hierarchical design (based on a previous comp.arch.fpga discussion
with the same subject).

I ran into a problem while finalizing the TOP script, which is
supposed to import the locked, back-annotated BOTTOM regions and
simply connect them on a top level.

The BOTTOM blocks, after they are fitted, are back-annotated and
exported along with their routing information. This is desirable,
because if the routing was not exported the final top-level
performance would not be guaranteed. However, there is a conflict
with the global clock networks.

Specifically, when each BOTTOM block is compiled it automatically
promotes its high fanout nets onto global clocks. This, again, is
desirable. But if this process is done automatically by Quartus and
independently for each BOTTOM entity, when the BOTTOM blocks are
assembled by the TOP script the routing on the global clock networks
makes the fit impossible: Quartus has used the same global
resources for different top-level nets.

Is there any way that I can assign a _specific_ global clock network
to a design node? Note that while a BOTTOM entity is compiled, the
source of this global clock is not yet known: in my case, this
global clock network will be driven by a different BOTTOM entity
which is the reset controller (or a PLL with many output clocks).

Does Quartus support this? The assignments "global signal" and
"auto global clock" simply declare that a signal will be promoted
to a global clock network, but do not specify _which_ of the
available global clock networks will be used. Does anybody know
something on this?

Thanks in advance,
Spyros

 

[Stephen Brown]

Altera engineering has been working with Spyros on this issue outside
of the news group, but wanted to share the results in case anyone else
is running into similar issues.

The main problem was that a module used a different global net in the
top-level then it did in the lower-level. Spyros solved this problem
by locking down this pin in both the lower and higher level designs.
Once that was done, the higher level project was forced to use the
same global as the low level, and the routing constraints could be
obeyed.

Other tidbits that may be useful:

1. LogicLock regions automatically become floating when imported. The
regions can be restored to a locked state using the TCL command
"set_logiclock -region $region_name -floating false".
2. Virtual I/O's can be used when a lower-level IO is not meant to be
an I/O at the top-level. This can help ensure routing constraints
are legal.
3. Logiclock_export -routing does nothing unless routing has already
been back-annotated. We will put a warning for this in future
versions of the Quartus II software.

It was a pleasure to work with Spyros on this issue.

Stephen Brown,
Altera Corp.

lyberis@isd.gr (Spyros Lyberis) wrote in message news:<ebe66d13.0405110647.c7a33a@posting.google.com>...

Hi everyone,

I'm near the completion of the final TCL flow for a Quartus II
hierarchical design (based on a previous comp.arch.fpga discussion
with the same subject).

I ran into a problem while finalizing the TOP script, which is
supposed to import the locked, back-annotated BOTTOM regions and
simply connect them on a top level.

The BOTTOM blocks, after they are fitted, are back-annotated and
exported along with their routing information. This is desirable,
because if the routing was not exported the final top-level
performance would not be guaranteed. However, there is a conflict
with the global clock networks.

Specifically, when each BOTTOM block is compiled it automatically
promotes its high fanout nets onto global clocks. This, again, is
desirable. But if this process is done automatically by Quartus and
independently for each BOTTOM entity, when the BOTTOM blocks are
assembled by the TOP script the routing on the global clock networks
makes the fit impossible: Quartus has used the same global
resources for different top-level nets.

Is there any way that I can assign a _specific_ global clock network
to a design node? Note that while a BOTTOM entity is compiled, the
source of this global clock is not yet known: in my case, this
global clock network will be driven by a different BOTTOM entity
which is the reset controller (or a PLL with many output clocks).

Does Quartus support this? The assignments "global signal" and
"auto global clock" simply declare that a signal will be promoted
to a global clock network, but do not specify _which_ of the
available global clock networks will be used. Does anybody know
something on this?

Thanks in advance,
Spyros