«

On Feb 13, 1:01*am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 12, 7:35*pm, Patrick Maupin <pmau...@gmail.com> wrote:

> > On Feb 12, 10:32*am, rickman <gnu...@gmail.com> wrote:
>
> > > In the case of using latches in place of registers, the speed gains
> > > are always usable. *But can't the same sort of gains be made by
> > > register leveling? *If you have logic that is slower than a clock
> > > cycle followed by logic that is faster than a clock cycle, why not
> > > just move some of the slow logic across the register to the faster
> > > logic section?
>
> > That's a similar technique, to be sure, for speed-gains. *But as I
> > wrote in an earlier post, I think the primary motivation for latch-
> > based design was originally cost. *For example, since each flop is
> > really two latches, if you are going to have logic which ANDs together
> > the output of two flops, you could replace that with ANDing the output
> > of two latches, and outputting that result through another latch, for
> > a net savings of 75% of the latches.
>
> Your method's target and the target used by CPU designers inserting
> latches in the pipeline line are totally different.
>
> They use it because a combinational signal time delay is tool long to
> fit within one clock cycle and too short within two clock cycles in a
> pipeline, not in any places you may want to.

I was agreeing with rickman that in many cases, register retiming can
achieve similarly satisfactory results, while pointing out there were
originally other reasons besides timing to use latches.

I agree that latches are used for speed reasons, as well as cost
reasons. But, as the paper you cite points out, the timing tools
aren't very good at analyzing the speed, and I don't know about the
specifics of the atom, but these days, if a chip designer wants
something that goes faster, he'll just as often use some domino logic
on a few paths rather than using simple latches -- same concept but
even more complicated.

In any case, you have to get your timing information somewhere -- a
latch really is just half a flop, and you have to decide when to close
it, so often you're either you're doing some fancy self-timing, or
your local clock tree gets a lot more complicated when you are doing
the described time-borrowing.

Regards,
Pat

On Feb 13, 6:21*pm, John_H <newsgr...@johnhandwork.com> wrote:
> The description comes out a little muddy which is why it took me a few
> days to buy in to the whole concept. *It's sweet! *It just takes some
> timing diagrams and head scratching. *And it's certainly not set up
> for proper analysis especially in the Xilinx tools where I
> experimented with the phase domain changes.

It's not just FPGA tools. Many of the high-end chip tools don't
support this very well, and to do it you need a PhD in the tool.

On Feb 14, 12:17*am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Feb 13, 6:21*pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > The description comes out a little muddy which is why it took me a few
> > days to buy in to the whole concept. *It's sweet! *It just takes some
> > timing diagrams and head scratching. *And it's certainly not set up
> > for proper analysis especially in the Xilinx tools where I
> > experimented with the phase domain changes.
>
> It's not just FPGA tools. *Many of the high-end chip tools don't
> support this very well, and to do it you need a PhD in the tool.

The sad thing is it *shouldn't* be difficult. For each stage of latch
traversed with an opposite clock edge, one more half cycle is added to
the overall timing spec for the path. By analyzing up to each stage,
a logic delay short enough to change the input of a latch that's still
not transparent starts the timing path fresh from this intermediate
latch.

It's such a "pretty" cascade of logic delays that I have to research
what you mean by "domino logic" to make sure we're not talking about
the same thing. It truly would be simple to analyze, no PhD required.

On Feb 14, 5:28*am, John_H <newsgr...@johnhandwork.com> wrote:
> On Feb 14, 12:17*am, Patrick Maupin <pmau...@gmail.com> wrote:
>
> > On Feb 13, 6:21*pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > The description comes out a little muddy which is why it took me a few
> > > days to buy in to the whole concept. *It's sweet! *It just takes some
> > > timing diagrams and head scratching. *And it's certainly not set up
> > > for proper analysis especially in the Xilinx tools where I
> > > experimented with the phase domain changes.
>
> > It's not just FPGA tools. *Many of the high-end chip tools don't
> > support this very well, and to do it you need a PhD in the tool.
>
> The sad thing is it *shouldn't* be difficult. *For each stage of latch
> traversed with an opposite clock edge, one more half cycle is added to
> the overall timing spec for the path. *By analyzing up to each stage,
> a logic delay short enough to change the input of a latch that's still
> not transparent starts the timing path fresh from this intermediate
> latch.
>
> It's such a "pretty" cascade of logic delays that I have to research
> what you mean by "domino logic" to make sure we're not talking about
> the same thing. *It truly would be simple to analyze, no PhD required.

John_H,
Read this paper first, then make your conclusion.

"Timing Verification and Optimal Clocking of Synchronous Digital
Circuits", published by 3 professors in University of Michigan in
1990, known as SMO algorithm.

Weng