More designing with Incremental Design?

Question

I'm working on a design used Incremental Design ( ID ). In the design I need to create some gated clocks on output pins. To do this I'm using the Altera altddio_out function where I'm feeding it a continuous clock and synchronously change the rising edge and/or falling edge data inputs to create the gated clock. The question I have is;

Does the altddio_out function have to be in the top level of the ID design or can it be part of a lower level partition?

I'm having an issue of placement of the data input generation logic, within the partition, being to far from the selected output pin when the altddio_out function exists only in the top level of the ID design.:rolleyes:

altera_forum · Answer

What device? Generally, the altddio and IO pad are specific silicon structures, where the signals feeding them for the gated clocks will be general logic.

As far as if the altddio buffers need to be in the top-level, I don't believe so, but would recommend it in general. These structures can only be placed in one way(in the IO cell feeding the pad), so there's not much of a way to mess it up.

Now, the problem you're having is the gating logic feeding the altddio is being placed too far away(and I'm assuming is in a different partition). Is this partition in a LogicLock region, forcing it to be further away? Is there a timing constraint on the logic going off chip(telling Quartus to move it near the IO)? Note that if you have logic in two partitions, and they're not post-fit, then the fitter should treat them as if they're flat, i.e. it doesn't purposely group partitions together and spread logic in different partitions. But it will use user constraints(like LogicLock regions or IO constraints) and timing constraints to decide how to place the logic.

altera_forum · Answer

First, the device is a Stratix 2 EP2S60 which the handbook says all standard I/O pins have altddio capability.

The partition is Logic Locked and post-fit with routing but its butt up against the I/O pins being used. The clock is a 200MHz 40/60 clock Globally fed and being generated in an EPLL. The logic being driven to the altddio_out pins is simply the data inputs into the altddio_out which are clocked by the same 200Mhz clock. The idea is that if the gated clock to the external device needs the clock to be low when off then,

datain_l = '0'; all the time.

datain_h is a registered signal clocked out when the clock needs to be on.

The result looks like a gated clock at the 200MHz clock rate. Really simple and clean.

Now what I'm getting is from the Timing Analyzer which is telling me that the path delay to the output pin (altddio_out function?) is too long for the clock speed (?).

I don't know how to put the altddio_out function into the lower level partition and NOT have it be part of the partition. If I could I believe placement and routing for this logic would be improved.

Any suggestions?

altera_forum · Answer

The clock gating structure looks good. I try to avoid anything but a 50/50 duty cycle, but assume that's a requirement.

Are you using the Classic Timing Analyzer? Note that the path delay to your output pin is:

Input clock -> PLL -> clock tree -> altddio register -> output port

So the delay from your gating logic to the datain_h signal is not even used in the calculation. Can you do a right-click List Paths on the output port's Tco to examine more closely why it is not meeting timing. Note that the path I described above is almost all dedicated hardware. (There is an output delay chain, but I've never seen that go on without user intervention). What's your requirement to get the clock off chip?

altera_forum · Answer

The 40/60 clock is the external device requirement so I'm kinda stuck with it. I would go 50/50 otherwise.

Yes I am using the Classic Timing Analyzer.

I'm not able to do that right now, I'm reworking the lower level functions of this partition to cover some other issues. I'm printing out your response to remind myself to follow up correctly.

I really don't have a requirement for off chip timing. I just need to send it then, later, line up another EPLL clock to the responding data from the device into the FPGA. Long story there and something that (hardware wise) is further down to road to be visited.

My biggest concern with the Timing Analyzers complaint is not issuing the expected number of gated clock cycles cleanly and not having reliable timing.

I might be blowing in the wind here, the hardware guys have been testing the outputs and they say they're nice. I just want to make sure on my end. (Always more to do.)

altera_forum · Answer

The classic timing analyzer, especially in terms of Tco values, are raw data delays.  They are extremely accurate, but they do not know what occurs during gated clocks besides the delays they pass though.  Basically it reports the delay it takes for an edge on the input clock port to create an edge on the output port.  If there is some sort of clock manipulation(like you invert the clock), it won't add 180 degrees to the Tco value or anything like that.  I'm not sure what you mean by gated clock cycles, but the timing should be extremely reliable(every design done depends on the timing models being reliable).

Forum Discussion

More designing with Incremental Design?

10 Replies

Recent Discussions

QSYS Subsystem Export Port order

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Repeat of a Questa License Issue

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

Board-Aware Flow autoring