Anyway to find output ports on a clock in tcl?

Altera_Forum · ‎09-23-2011

I'm delving into sdc files and tcl and was wondering if there is a way to find all the output ports clocked by a certain clock for a source synchronous design.

My first guess is to make a fanout collection from the pll clock pin:

set myFan ]Then I was thinking about using get_registers filtered with *ALTDDIO* and then using the intersection of the two collections to filter out the non IO port registers. Unfortunately there is no tcl command to do this. (I was mis-remembering add_to_collection which is the union!)

This is probably a long way around to do something simple but it seems that the ::quartus::sta 1.0 'collection' operations could be extended.

Is there a cheat-sheet with useful tcl 'tricks' around?

Altera_Forum · ‎09-23-2011

The following may work for you:

report_timing -from_clock [get_clocks my_clock_name] -to [get_ports *] -npaths 1000

or if you want to use this within a script

get_timing_paths -from_clock [get_clocks my_clock_name] -to [get_ports *] -npaths 1000

Hope that helps

Altera_Forum · ‎09-23-2011

Thanks for the pointer on this. I found that I first had to put some timing on the output ports first:

set_output_delay 10.0 -max -clock -add_delay This gives all sorts of expected warning messages which I'm ignoring, but it allows:

set myPaths  -to  -npaths 1000]
foreach_in_collection path $myPaths {
    puts 
}

Unfortunately I'm stuck as it only returns a list of nodes (the ports?)

Now, if only set_output_delay would accept nodes...

Altera_Forum · ‎09-23-2011

I noticed you're assigning the clock CLK_G0X4, which is internally to the FPGA, to the output register. It's good practice to create virtual clock for these. The exception is source-synchronous outputs, whereby you want to put a generated clock on the port driving the clock out and then use that as the -clock option.

What is it you're trying to do? I've never seen a need to find what clock drives the output register and then use that external and wondering if there is another way around it.

Altera_Forum · ‎09-23-2011

Hi Rysc, Yes, this is a DDR source synchronous design. I'm trying to follow "Implementing_a_Source_Synchronous_Interface_v2.0.doc"

CLK_G0X4 is the generated clock on the output of the dll (4x the input clock).

I do have another generated clock AD2CK on the actual output port with CLK_G0X4 as its master_clock (as described in the doc).

The place where I got stuck was trying to set the OMD (Output Max Delay) on page 18 line 82: [get_ports {data_out*}] which does not work for my port list (the port names are a group of different names defined by the vendor)

This is why I want to find all the output ports driven by this clock. It seemed simple at the time!

I agree that 'set_output_delay 10.0 -max -clock [get_clocks {CLK_G0X4}] -add_delay [all_outputs]' is odd, but it does allow the following:

set myPaths  -to  -npaths 1000]
foreach_in_collection path $myPaths {
    lappend myPortList ]
}
set_output_delay $OMD -max -clock  -add_delay $myPortList

I'm not very happy with it and I really should remove the 10.0ns output_delays before they cause trouble elsewhere - and I'm sure they will!

Altera_Forum · ‎09-26-2011

Is there a reason you're not explicitly listing the ports?

set ssync_ports [get_ports {ssync_d[*] ssync_parity ssync_addr[*]}]

set_output_delay $OMD -max -clock [get_clocks {AD2CK}] $ssync_ports

FYI, I posted a source-synchronous document with examples, in case you're interested:

http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest

Nothing wrong with the one you're looking at, so if you like it then it may be more confusing to look at something else.

What's your clock rate? A 10ns output delay seems pretty high for source-synchronous interface(that usually means it's a slow interface, and slow interfaces don't often do source-synchronous, but it does happen now and then).

Altera_Forum · ‎09-26-2011

You are right, normally I would just list the ports and be done with it.

However I want to use the board's previously declared generic port names as these are tied to the validated pad lists. (These are big FPGAs and I don't want to be manually editing them!)

The idea was to have the .sdc automatically figure out the serdes ports by the clock driving them and then constrain them. Apparently this is fairly common practice in the ASIC world.

A single bus would not be so bad - but we'll be ending up with 12 FPGAs with multiple buses.

But as it is looking now I may just have to buckle-down and enter all the ports using the grouping method you show. Sometimes the slow way is the quicker way...

The 10.0ns timing I blanket-applied to all the output ports above was just to put a timing path on everything so that 'get_timing_paths' can then filter out the correct '-from_clock [get_clocks CLK_G0X4]' '-to_port [get_ports *]' davka previously suggested.

The 10ns delay can be anything - I later remove it by 'remove_output_delay [all_outputs]'

The actual constraints are applied to my filtered new port list by:

set_output_delay $OMD -max -clock [get_clocks {AD2CK}] -add_delay $myPortList

Unfortunately, while it looks like I've figured out how to do this, when I put this all in the .sdc file TimeQuest errors out saying that 'get_timing_paths' is not a proper SDC command. :mad:

So I'm back to square one...

Altera_Forum · ‎09-26-2011

Ahh, got it. I hate to say it, but think that entering the ports will get you results the most quickly.

One other idea, and I don't want to say this, is to apply the set_output_delay to all outputs:

set_output_delay $OMD -max -clock [get_clocks {AD2CK}] [all_outputs]

In your set_clock_groups command, make sure the AD2CK clock is in the same group as the clock of interest and cut from all other clocks. In essence, the output delay is applied to all I/O, but cut from all of them except the ones fed by that clock. I still think it's ugly, but just an idea...

Altera_Forum · ‎09-26-2011

Many thanks rysc for looking at this. If you have any contact with the SW team doing the development on TimeQuest maybe you could mention it for a future feature. :)

Using tcl seems to promise great power so it is disappointing that we can't access the internal databases in a consistent manner..