More designing with Incremental Design?

[Altera_Forum]

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]

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]

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]

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]

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]

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).

[Altera_Forum]

Thank you. 

 Yeah you're right, even if the data signal delay is bad it will still cover the correct number of edges. The data signal is generated by that same edge of the same clock so it has to.

[Altera_Forum]

Are you sure the device actually requires a 40/60 duty cycle? I've never actually seen that as a requirement. Usually it's a tolerance spec, i.e. we would prefer 50/50 but can tolerate a duty cycle out to 40/60. Just bringing it up because I haven't heard of that before. And if it is what they want, maybe there's a tolerance range on that, i.e. they could tolerate a 50/50 clock. : )

[Altera_Forum]

Yes, actually it requires 2 40/60 duty cycle clocks that are 180 degrees out of phase. It requires that no rising or falling edge be coincident with that of the other clock. The result at 200MHz is a pair of 40/60 duty cycle clocks 180 degrees out of phase where there is near 500ps between any edge of either clock. How's that for tolerance? And yeah its real, the core clock for the device is 1GHz (not through the FPGA). 

 Hey I just got a response from my Altera SR (10613927) asking the exact same question (exact same wording) as this thread start and they said the altddio_out can be at any level in ID. Do they really know?  I began this when I tried to import a partition with the altddio_out as part of it and the compiler complained that it didn't have a source file for the altddio_out function in the project. Note the ID partition import was a post fit with routing export.  I redid the partition moving the altddio_out to the top level and ended up with what we've been discussing.

[Altera_Forum]

Yowsers. I don't think I even want to know what that part is doing. 

 I'm pretty sure I've done designs with altddio_out in a lower-level partition, but in a top-down approach. I'm guessing the following happened in your case: - I believe when exporting a .qxp file, the synthesizer still needs to synthesize something of a non-.qxp format to get through the analysys and synthesis stage. (I believe this is being fixed, too) - Then in the next stage, partition merge, it decides what to stitch together, the synthesized partition, or the .qxp file. (And what type of info from the .qxp, netlist only, placement or placement and routing. I've used .qxp files to help users create-pseudo encrypted IP that they send to their end customer rather than original source. When they give a .qxp file, they also have to give a dummy file with the ports defined for the customer to get through synthesis.  So in your case, if the altddio_out was removed, it didn't make it through synthesis. Anyway, that's my best guess.

[Altera_Forum]

Thank you.