We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

# AR# 1494

## Description

Urgency: Standard

Keywords: Duty Cycle, 4000, Routes, transistors

Description
XC4000E/EX/XL/XV/XLT Design:

- I'm developing a high density project with a 4013E PQ240-4 LCA.

- I must use six global buffers for clocks (at 34MHz) distribution.

-> I have a input signal, at 34MHz with 50% duty cycle, that go through
few level of
combinatorial logic, but it outputs with a duty cycle less than 50% and
routing dependent.

For example, in a unlucky routing, I have obtained (input signal with
Ton = Toff = 14.7 ns)
the output signal with Ton = 4.7 ns and Toff = 24.7 ns.

Now, I have two questions:

1. why the duty cycle fall?

2. how can I do to avoid my problem?

## Solution

When you run a signal through several levels of logic, it is unavoidable that the duty cycle gets changed a little.
For the duty cycle to be unaffected, the delay of the rising edge would have to be exactly as long as the delay of the falling edge. But completely different transistors are responsible for each edge.
So, the best our designers can do, is to carefully match the drive of the
pull-up and the pull-down, so theta the two edges are delayed by almost the same amount. And that's what they have done.
Apparently, this case is worse.
Once you understand the reason, there is a way to improve the situation.
You can turn your signal "upside down" at various places in the chain, and thus mix up the rising and falling delays. Since inputs to and outputs from function generators can be inverted "for free", these modifications don't affect the
routing. The simplest way would be to poke around in XDE, invert selected parts of the chain, and measure the result physically. ( I would not trust XDELAY or a simulator with the timing anaysis. They usually just give tou the worst-case delay, which in this particular case, is not what one is after.
AR# 1494
Date 10/01/2008
Status Archive
Type General Article
Page Bookmarked