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

Reply to
Spyros Lyberis
Loading thread data ...

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.
Reply to
Stephen Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.