Logiclock TCL flow -- near completion

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

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