How to get clocks from DCM that the duty cycle is not 1:1

Hello all,

I have an ASIC design to be converted to FPGA, I'm using Spartan-3A.

The ASIC uses 60MHz input clock, and divides it to 3 20MHz clocks
inside, the duty cycle is not 1:1 and has phase shifting like below:
                     |<-  50ns ->|
     ___           ___           ___
 __/   \___.___/   \___.___/   \___.___.
    .   .   .   .   .   .   .   .   .   .
             _                _               _
  _.___._/ \___.___._/ \___.___._/ \___.
    .   .   .   .   .   .   .   .   .   .
                 _               _                _
  _.___.___/ \_.___.___/ \_.___.___/ \_.
    .   .   .   .   .   .   .   .   .   .

These 3 clocks are the main clocks in the design, so I want to get
them from DCM, but found I can't set duty cycles in DCM.

Now I use logic to divide the clocks and add BUFG after them, but the
skew before BUFG can't be managed.

Is there anyone has a better idea?

jay wrote:
> Hello all,
> 
> I have an ASIC design to be converted to FPGA, I'm using Spartan-3A.
> 
> The ASIC uses 60MHz input clock, and divides it to 3 20MHz clocks
> inside, the duty cycle is not 1:1 and has phase shifting like below:
>                      |<-  50ns ->|
>      ___           ___           ___
>  __/   \___.___/   \___.___/   \___.___.
>     .   .   .   .   .   .   .   .   .   .
>              _                _               _
>   _.___._/ \___.___._/ \___.___._/ \___.
>     .   .   .   .   .   .   .   .   .   .
>                  _               _                _
>   _.___.___/ \_.___.___/ \_.___.___/ \_.
>     .   .   .   .   .   .   .   .   .   .
> 
> These 3 clocks are the main clocks in the design, so I want to get
> them from DCM, but found I can't set duty cycles in DCM.
> 
> Now I use logic to divide the clocks and add BUFG after them, but the
> skew before BUFG can't be managed.
> 
> Is there anyone has a better idea?

Hi Jay,
Clock everything at 60 MHz. Use the 60MHz to make three clock enables 
for your three phase shifted domains.
HTH., Syms.

On Oct 13, 7:08=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> jay wrote:
> > Hello all,
>
> > I have an ASIC design to be converted to FPGA, I'm using Spartan-3A.
>
> > The ASIC uses 60MHz input clock, and divides it to 3 20MHz clocks
> > inside, the duty cycle is not 1:1 and has phase shifting like below:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<- =A050ns ->|
> > =A0 =A0 =A0___ =A0 =A0 =A0 =A0 =A0 ___ =A0 =A0 =A0 =A0 =A0 ___
> > =A0__/ =A0 \___.___/ =A0 \___.___/ =A0 \___.___.
> > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 _
> > =A0 _.___._/ \___.___._/ \___.___._/ \___.
> > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0_
> > =A0 _.___.___/ \_.___.___/ \_.___.___/ \_.
> > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
>
> > These 3 clocks are the main clocks in the design, so I want to get
> > them from DCM, but found I can't set duty cycles in DCM.
>
> > Now I use logic to divide the clocks and add BUFG after them, but the
> > skew before BUFG can't be managed.
>
> > Is there anyone has a better idea?
>
> Hi Jay,
> Clock everything at 60 MHz. Use the 60MHz to make three clock enables
> for your three phase shifted domains.
> HTH., Syms.

Hi Symon,

This sounds a good idea, but it needs change the whole ASIC design.
And two clocks' high period is only half of the 60MHz cycle, I need
run my design in 120MHz to catch it.

Best Regards,
Jay

On Oct 13, 6:47=A0pm, jay <heavenf...@gmail.com> wrote:
> On Oct 13, 7:08=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
>
>
>
>
> > jay wrote:
> > > Hello all,
>
> > > I have an ASIC design to be converted to FPGA, I'm using Spartan-3A.
>
> > > The ASIC uses 60MHz input clock, and divides it to 3 20MHz clocks
> > > inside, the duty cycle is not 1:1 and has phase shifting like below:
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<- =A050ns ->|
> > > =A0 =A0 =A0___ =A0 =A0 =A0 =A0 =A0 ___ =A0 =A0 =A0 =A0 =A0 ___
> > > =A0__/ =A0 \___.___/ =A0 \___.___/ =A0 \___.___.
> > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 _
> > > =A0 _.___._/ \___.___._/ \___.___._/ \___.
> > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_
> > > =A0 _.___.___/ \_.___.___/ \_.___.___/ \_.
> > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
>
> > > These 3 clocks are the main clocks in the design, so I want to get
> > > them from DCM, but found I can't set duty cycles in DCM.
>
> > > Now I use logic to divide the clocks and add BUFG after them, but the
> > > skew before BUFG can't be managed.
>
> > > Is there anyone has a better idea?
>
> > Hi Jay,
> > Clock everything at 60 MHz. Use the 60MHz to make three clock enables
> > for your three phase shifted domains.
> > HTH., Syms.
>
> Hi Symon,
>
> This sounds a good idea, but it needs change the whole ASIC design.
> And two clocks' high period is only half of the 60MHz cycle, I need
> run my design in 120MHz to catch it.
>
> Best Regards,
> Jay

Jay, find out what the clocks are doing. If they clock only flip-
flops, then only the rising edges are important, and the high-time is
irrelevant, and Symon's advice is perfect.
If, however, the "clocks" are also used for other purposes (e.g. with
latches), then you have to be more careful with High and Low timing,
and any clock overlap.
Peter Alfke

On Oct 14, 11:17=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Oct 13, 6:47=A0pm, jay <heavenf...@gmail.com> wrote:
>
>
>
> > On Oct 13, 7:08=A0pm, Symon <symon_bre...@hotmail.com> wrote:
>
> > > jay wrote:
> > > > Hello all,
>
> > > > I have an ASIC design to be converted to FPGA, I'm using Spartan-3A=
.
>
> > > > The ASIC uses 60MHz input clock, and divides it to 3 20MHz clocks
> > > > inside, the duty cycle is not 1:1 and has phase shifting like below=
:
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<- =A050ns ->|
> > > > =A0 =A0 =A0___ =A0 =A0 =A0 =A0 =A0 ___ =A0 =A0 =A0 =A0 =A0 ___
> > > > =A0__/ =A0 \___.___/ =A0 \___.___/ =A0 \___.___.
> > > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 _
> > > > =A0 _.___._/ \___.___._/ \___.___._/ \___.
> > > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_
> > > > =A0 _.___.___/ \_.___.___/ \_.___.___/ \_.
> > > > =A0 =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 . =A0 .
>
> > > > These 3 clocks are the main clocks in the design, so I want to get
> > > > them from DCM, but found I can't set duty cycles in DCM.
>
> > > > Now I use logic to divide the clocks and add BUFG after them, but t=
he
> > > > skew before BUFG can't be managed.
>
> > > > Is there anyone has a better idea?
>
> > > Hi Jay,
> > > Clock everything at 60 MHz. Use the 60MHz to make three clock enables
> > > for your three phase shifted domains.
> > > HTH., Syms.
>
> > Hi Symon,
>
> > This sounds a good idea, but it needs change the whole ASIC design.
> > And two clocks' high period is only half of the 60MHz cycle, I need
> > run my design in 120MHz to catch it.
>
> > Best Regards,
> > Jay
>
> Jay, find out what the clocks are doing. If they clock only flip-
> flops, then only the rising edges are important, and the high-time is
> irrelevant, and Symon's advice is perfect.
> If, however, the "clocks" are also used for other purposes (e.g. with
> latches), then you have to be more careful with High and Low timing,
> and any clock overlap.
> Peter Alfke

Peter,

The design mostly used latches, I'm unlucky.

All three clocks are registered by main clock however, I think if I
can constraint the FF output to BUFG input delay of them (be the
same), the phase relationship can be kept. Can I do that?

Best Regards,
Jay

jay wrote:
> 
> Peter,
> 
> The design mostly used latches, I'm unlucky.
 >
Ouch!
> 
> All three clocks are registered by main clock however, I think if I
> can constraint the FF output to BUFG input delay of them (be the
> same), the phase relationship can be kept. Can I do that?
> 
> Best Regards,
> Jay

I can think of two choices, both of which use a DCM to make 120MHz from 
your 60MHz.

1) Rewrite it all to use FFs only (i.e. no latches) clocked at 120MHz.

2) Use the 120MHz to make the three clock signals the original design 
used. Constrain these with MAXDELAY to three BUFGs to distribute the clocks.

Do (1) if you're ever gonna add any new features to the design. Do (2) 
if you're planning on getting a job somewhere else soon! ;-)

Good luck, Syms.

On Oct 14, 5:56=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> jay wrote:
>
> > Peter,
>
> > The design mostly used latches, I'm unlucky.
>
> =A0>
> Ouch!
>
>
>
> > All three clocks are registered by main clock however, I think if I
> > can constraint the FF output to BUFG input delay of them (be the
> > same), the phase relationship can be kept. Can I do that?
>
> > Best Regards,
> > Jay
>
> I can think of two choices, both of which use a DCM to make 120MHz from
> your 60MHz.
>
> 1) Rewrite it all to use FFs only (i.e. no latches) clocked at 120MHz.
>
> 2) Use the 120MHz to make the three clock signals the original design
> used. Constrain these with MAXDELAY to three BUFGs to distribute the cloc=
ks.
>
> Do (1) if you're ever gonna add any new features to the design. Do (2)
> if you're planning on getting a job somewhere else soon! ;-)
>
> Good luck, Syms.

The ASIC was designed so long ago that it was written by a proprietary
HDL code, it will take lots man-months to rewrite it.
It has a post-layout Verilog netlist with foundry library models for
simulation, I have created all the libraries (gates, Latches, FFs,
multipliers, memories) using Verilog RTL, so get a gate level
synthesizable design.

What I'm thinking now is to replace Latch instance with FF instance in
the design like below:
latch_cell latch_inst1 (.o(o), .i(i), .en(en)) to ff_cell ff_inst1 (.o
(o), .i(i), .en(en), .clk(clk))

So it may fit into a FPGA better, I just need get a high speed clock
(120MHz) to every modules, and write a script to convert all latch
instances through the design.

My concern is 120MHz is fast enough for a low cost FPGA that I will
get lots of setup time problems then...

jay <heavenfish@gmail.com> wrote:
<> jay wrote:

<> > The design mostly used latches, I'm unlucky.
(big snip)
 
< The ASIC was designed so long ago that it was written by a proprietary
< HDL code, it will take lots man-months to rewrite it.
< It has a post-layout Verilog netlist with foundry library models for
< simulation, I have created all the libraries (gates, Latches, FFs,
< multipliers, memories) using Verilog RTL, so get a gate level
< synthesizable design.

Yes, that is what I would expect.
 
< What I'm thinking now is to replace Latch instance with FF 
< instance in the design like below:

< latch_cell latch_inst1 (.o(o), .i(i), .en(en)) to ff_cell ff_inst1 (.o
< (o), .i(i), .en(en), .clk(clk))

It would depend somewhat on the design, but my first thought
is that you just use (en) as the clock.  (or ~en depending on
rising edge or falling edge.)

Does the design have a two phase clock?

Does the signal flow go:

(latch on phase 1) (gates) (latch on phase 2) (gates) (repeat as needed)

In that case, you should be able to replace them all by edge
triggered FFs and run the clock twice as fast.  

How old is this design?

< So it may fit into a FPGA better, I just need get a high speed clock
< (120MHz) to every modules, and write a script to convert all latch
< instances through the design.
 
< My concern is 120MHz is fast enough for a low cost FPGA that I will
< get lots of setup time problems then...

-- glen

On Oct 15, 5:56=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> jay <heavenf...@gmail.com> wrote:
> <> jay wrote:
>
> <> > The design mostly used latches, I'm unlucky.
> (big snip)
>
> < The ASIC was designed so long ago that it was written by a proprietary
> < HDL code, it will take lots man-months to rewrite it.
> < It has a post-layout Verilog netlist with foundry library models for
> < simulation, I have created all the libraries (gates, Latches, FFs,
> < multipliers, memories) using Verilog RTL, so get a gate level
> < synthesizable design.
>
> Yes, that is what I would expect.
>
> < What I'm thinking now is to replace Latch instance with FF
> < instance in the design like below:
>
> < latch_cell latch_inst1 (.o(o), .i(i), .en(en)) to ff_cell ff_inst1 (.o
> < (o), .i(i), .en(en), .clk(clk))
>
> It would depend somewhat on the design, but my first thought
> is that you just use (en) as the clock. =A0(or ~en depending on
> rising edge or falling edge.)
>
> Does the design have a two phase clock?
>
> Does the signal flow go:
>
> (latch on phase 1) (gates) (latch on phase 2) (gates) (repeat as needed)
>
> In that case, you should be able to replace them all by edge
> triggered FFs and run the clock twice as fast. =A0
>
> How old is this design?
>
> < So it may fit into a FPGA better, I just need get a high speed clock
> < (120MHz) to every modules, and write a script to convert all latch
> < instances through the design.
>
> < My concern is 120MHz is fast enough for a low cost FPGA that I will
> < get lots of setup time problems then...
>
> -- glen

Hi Glen,

I don't think I can replace Latch with FF that easy, the design
intended to use Latch, changing the trigger from level to edge will
change the registers behavior.
The latest version of this ASIC was taped out about 10 years ago, it's
probably the 3rd generation of it's family. I don't know when the
design was initiated, should in the days when Latch uses less
transistors than FF.

Jay

jay <heavenfish@gmail.com> wrote:
< On Oct 15, 5:56?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
<> jay <heavenf...@gmail.com> wrote:
<> <> jay wrote:

<> <> > The design mostly used latches, I'm unlucky.
<> (big snip)
(snip)

<> < What I'm thinking now is to replace Latch instance with FF
<> < instance in the design like below:

<> < latch_cell latch_inst1 (.o(o), .i(i), .en(en)) to ff_cell ff_inst1 (.o
<> < (o), .i(i), .en(en), .clk(clk))

<> It would depend somewhat on the design, but my first thought
<> is that you just use (en) as the clock. ?(or ~en depending on
<> rising edge or falling edge.)

<> Does the design have a two phase clock?

<> Does the signal flow go:

<> (latch on phase 1) (gates) (latch on phase 2) (gates) (repeat as needed)

<> In that case, you should be able to replace them all by edge
<> triggered FFs and run the clock twice as fast. ?

I had forgetten your original question, which was about a three
phase clock.  The big advantage of edge triggered FF's is the
need for only a single clock.  What actually has to happen is
that, internally to each FF, a two phase clock is generated to
clock separately the two halves of the FF, such that the input
can be latched before the output changes.

With an edge triggered FF, the timing requirement is that
the input must have settled to the appropriate value by the
next clock edge minus the setup time for that FF.  It must
not change before the clock edge plus the hold time.
Most logic now has zero hold time, and a setup time sufficiently
small that you don't have to worry about it.  (The tools will
do that for you, but propagation delay is much larger.)

Using transparent latches requires a two (or more) phase clock
such that the delay between FF states is less than the time
from the rising edge of one to the falling edge of the next,
minus the propagation delay for the latch itself.  Clock skew
subtracts from the time that you can allow, as one edge
may come earlier than expected.

If you replace the latches with rising edge FF's then the
delay has to be less than the time between the rising edge
of one and the rising edge of the next.  

If you replace transparent latches with edge triggered FF's,
and if the clock is slow enough, the design should still work.

Much of the complication of designing an FPGA is in clock 
distribution such that the user (you) doesn't have to worry
about clock skew.  The tools can compute the maximum delay
from one FF output to the next input, add the allowable clock
skew, and guarantee that the FF input is stable in time.
With zero hold time, even after allowing for clock skew,
you never need to worry about logic being too fast.

<> How old is this design?

<> < So it may fit into a FPGA better, I just need get a high speed clock
<> < (120MHz) to every modules, and write a script to convert all latch
<> < instances through the design.

<> < My concern is 120MHz is fast enough for a low cost FPGA that I will
<> < get lots of setup time problems then...

I believe that your biggest problem is clock skew.  
 

< I don't think I can replace Latch with FF that easy, the design
< intended to use Latch, changing the trigger from level to edge will
< change the registers behavior.

If you can verify that the logic works as I described, three phases
and the appropriate amount of logic between each phase, then,
with the appropriate clock speed it should work.  

Part of my previous suggestion included inverting every other
phase such that you had the time from the rising edge of one
to the falling edge of the next.  That only works with an even
number of phases.  

With transparent latches and using the general routing fabric
for clock distribution I believe that the clock skew will be
large enough that the timing will be worse.  That depends on
the specific FPGA, how the clock distribution works, and such.

Also, the tools may or may not be able to do the timing calculation
for you.

< The latest version of this ASIC was taped out about 10 years ago, it's
< probably the 3rd generation of it's family. I don't know when the
< design was initiated, should in the days when Latch uses less
< transistors than FF.

Well, yes, but the complications of distributing three clock phases
have to be added in.  As logic gets faster, clock skew becomes
more singificant.    I do remember someone trying to design
with the original TMS9900 with a four phase clock.  I don't know
of a commercial microprocessor using a three phase clock, though
it is hard to know now.  All the clock generation is done on
chip on the high end processors.  

-- glen