VHDL and Latch

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1173203586.424949.18610@s48g2000cws.googlegroups.com...
>
> Hi Kevin,
> In my first posting, there are 3 questions:
> 1. Why doesn't compiler generate an error for unintended latch
> generation?
Simply put because it is not an 'error' to write code that infers a latch. 
To presume that every latch is 'unintended' would be wrong.

> This question is satisfactorily answered: there is a new attribute to
> give errors if an unintended latch is to generate. It says that some
> other people had already observed the situation long time ago.
>
If you choose to use that attribute and find a tool that supports it then by 
all means use it.  But keep in mind that if you forget to use the new 
attribute (because people are human) that you can still end up in the same 
situation.  It's up to you if that's the coding style you prefer to use to 
avoid unintended latches, personally I prefer other coding styles but the 
attribute is at least an improvement and gives another method which is good.

No matter which of these two methods you use, you can still get an 
'unintended latch' with the following type of code which infers a latch

Q <= (C and D) or (not(C) and Q);

This is obviously a very stripped down example, a 'real' design might be 
much more complicated, but you have to train yourself to look at every 
concurrent statement and make sure that you don't see the output on both 
sides of the equation.

It gets worse though because the 'latch' could be a function of multiple 
concurrent statements that happen to loop back.  The synthesizer report that 
it finds a combinatorial loop works to catch that but nothing in the 
language prevents it (nor should it, since it may not be 'unintended').

> 2. If the above error is given an error, VHDL may include a special
> statement to generate a latch.
If you want a 'special' statement that creates a latch, then write one and 
instantiate it until your heart is content....but don't presume that 
everyone else agrees with you and that the language itself should only 
support your coding style for creating a latch and any other method should 
cause an error.

> This is another big problem: I don't know how ASIC people generate a
> real latch using VHDL? I think they may most likely use latch library
> to generate special latch instead of using VHDL statements.
That doesn't preclude them from inferring a latch in other ways.

> I read an
> article about asynchronous FIFO written by two engineers one of whom
> is Pete Alfke of Xilinx (it is the best article I have read in my
> life). In the paper they say that they fail to generate two or 3
> latches in their design using Xilinx chip.
No idea what you mean by this...but reading on

> If so, it seems to me that
> there is no reliable statement in VHDL to generate a latch for a FPGA
> chip.
Unless the underlying hardware has a hard latch available as a resource to 
use and most (if not all) FPGAs do not, then I would agree that there is no 
reliable way to generate a latch inside an FPGA in any language, not just 
VHDL.  The lack of latches in FPGAs though has nothing at all to do with 
VHDL or any language it is simply recognition by the FPGA suppliers that 
there is very little demand for a hard latch inside the FPGA.  A flip flop 
would have the exact same coding issues, the only reason it's not a 
'problem' is because there are hard flip flops inside the FPGA.

The 'problem' with inferring any storage element (latch, flip flop, big 
hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly 
support the inferred element and it needs to be cobbled together from basic 
logic blocks.  In the FPGA/CPLD world, it is very difficult to meet internal 
setup, hold time and 'no glitching' requirements between two arbitrary 
signals.

Remember also, that you can build ANY logical element strictly from NAND 
gates or NOR gates....so in theory you could write your code using only 
these two building blocks.  Were you to do so and target an FPGA, it would 
most certainly fail if that design had any sort of storage.

>
> 3. If the example would generate a latch for signalA, how it is
> generated?
Same as any other logical description....it gets mapped to whatever internal 
resources exist in the device (LUTs, macrocells, flip flops, latches, 
whatever the target device supports).

>
> KJ answered the question. If the equation KJ suggested is true, it
> would like the following:
> if (state = stateA_S and a = "000001") then
>  signalA <= '1';
> end if;
>
> Finally I realized KJ saying is correct.
>
You're welcome.

Kevin Jennings 

On Mar 6, 5:37 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> news:1173203586.424949.18610@s48g2000cws.googlegroups.com...
>
> > Hi Kevin,
> > In my first posting, there are 3 questions:
> > 1. Why doesn't compiler generate an error for unintended latch
> > generation?
>
> Simply put because it is not an 'error' to write code that infers a latch.
> To presume that every latch is 'unintended' would be wrong.
>
> > This question is satisfactorily answered: there is a new attribute to
> > give errors if an unintended latch is to generate. It says that some
> > other people had already observed the situation long time ago.
>
> If you choose to use that attribute and find a tool that supports it then by
> all means use it.  But keep in mind that if you forget to use the new
> attribute (because people are human) that you can still end up in the same
> situation.  It's up to you if that's the coding style you prefer to use to
> avoid unintended latches, personally I prefer other coding styles but the
> attribute is at least an improvement and gives another method which is good.
>
> No matter which of these two methods you use, you can still get an
> 'unintended latch' with the following type of code which infers a latch
>
> Q <= (C and D) or (not(C) and Q);
>
> This is obviously a very stripped down example, a 'real' design might be
> much more complicated, but you have to train yourself to look at every
> concurrent statement and make sure that you don't see the output on both
> sides of the equation.
>
> It gets worse though because the 'latch' could be a function of multiple
> concurrent statements that happen to loop back.  The synthesizer report that
> it finds a combinatorial loop works to catch that but nothing in the
> language prevents it (nor should it, since it may not be 'unintended').
>
> > 2. If the above error is given an error, VHDL may include a special
> > statement to generate a latch.
>
> If you want a 'special' statement that creates a latch, then write one and
> instantiate it until your heart is content....but don't presume that
> everyone else agrees with you and that the language itself should only
> support your coding style for creating a latch and any other method should
> cause an error.
>
> > This is another big problem: I don't know how ASIC people generate a
> > real latch using VHDL? I think they may most likely use latch library
> > to generate special latch instead of using VHDL statements.
>
> That doesn't preclude them from inferring a latch in other ways.
>
> > I read an
> > article about asynchronous FIFO written by two engineers one of whom
> > is Pete Alfke of Xilinx (it is the best article I have read in my
> > life). In the paper they say that they fail to generate two or 3
> > latches in their design using Xilinx chip.
>
> No idea what you mean by this...but reading on
>
> > If so, it seems to me that
> > there is no reliable statement in VHDL to generate a latch for a FPGA
> > chip.
>
> Unless the underlying hardware has a hard latch available as a resource to
> use and most (if not all) FPGAs do not, then I would agree that there is no
> reliable way to generate a latch inside an FPGA in any language, not just
> VHDL.  The lack of latches in FPGAs though has nothing at all to do with
> VHDL or any language it is simply recognition by the FPGA suppliers that
> there is very little demand for a hard latch inside the FPGA.  A flip flop
> would have the exact same coding issues, the only reason it's not a
> 'problem' is because there are hard flip flops inside the FPGA.
>
> The 'problem' with inferring any storage element (latch, flip flop, big
> hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly
> support the inferred element and it needs to be cobbled together from basic
> logic blocks.  In the FPGA/CPLD world, it is very difficult to meet internal
> setup, hold time and 'no glitching' requirements between two arbitrary
> signals.
>
> Remember also, that you can build ANY logical element strictly from NAND
> gates or NOR gates....so in theory you could write your code using only
> these two building blocks.  Were you to do so and target an FPGA, it would
> most certainly fail if that design had any sort of storage.
>
>
>
> > 3. If the example would generate a latch for signalA, how it is
> > generated?
>
> Same as any other logical description....it gets mapped to whatever internal
> resources exist in the device (LUTs, macrocells, flip flops, latches,
> whatever the target device supports).
>
>
>
> > KJ answered the question. If the equation KJ suggested is true, it
> > would like the following:
> > if (state = stateA_S and a = "000001") then
> >  signalA <= '1';
> > end if;
>
> > Finally I realized KJ saying is correct.
>
> You're welcome.
>
> Kevin Jennings

Hi KJ,
1. Q <= (C and D) or (not(C) and Q);
I have never seen such equation in my coding experiences and have no
idea how this equation would be written. The logic result is beyond a
reason. Could you please write it in equivalent latch equation in
informal VHDL?

2. FPGA of Xilinx chip really has latch primative and one may use it
using latch primative to call it. But it is hard to refer to it in
VHDL. I don't mean VHDL should have included latch statement, what I
mean is VHDL really lacks the statement element to refer to a latch in
a clear and reliable way and the lack can be easily corrected.

Thank you.

Weng

Weng Tianxiang wrote:
> On Mar 6, 5:37 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>>
>> news:1173203586.424949.18610@s48g2000cws.googlegroups.com...
>>
>>> Hi Kevin,
>>> In my first posting, there are 3 questions:
>>> 1. Why doesn't compiler generate an error for unintended latch
>>> generation?
>> Simply put because it is not an 'error' to write code that infers a latch.
>> To presume that every latch is 'unintended' would be wrong.
>>
>>> This question is satisfactorily answered: there is a new attribute to
>>> give errors if an unintended latch is to generate. It says that some
>>> other people had already observed the situation long time ago.
>> If you choose to use that attribute and find a tool that supports it then by
>> all means use it.  But keep in mind that if you forget to use the new
>> attribute (because people are human) that you can still end up in the same
>> situation.  It's up to you if that's the coding style you prefer to use to
>> avoid unintended latches, personally I prefer other coding styles but the
>> attribute is at least an improvement and gives another method which is good.
>>
>> No matter which of these two methods you use, you can still get an
>> 'unintended latch' with the following type of code which infers a latch
>>
>> Q <= (C and D) or (not(C) and Q);
>>
>> This is obviously a very stripped down example, a 'real' design might be
>> much more complicated, but you have to train yourself to look at every
>> concurrent statement and make sure that you don't see the output on both
>> sides of the equation.
>>
>> It gets worse though because the 'latch' could be a function of multiple
>> concurrent statements that happen to loop back.  The synthesizer report that
>> it finds a combinatorial loop works to catch that but nothing in the
>> language prevents it (nor should it, since it may not be 'unintended').
>>
>>> 2. If the above error is given an error, VHDL may include a special
>>> statement to generate a latch.
>> If you want a 'special' statement that creates a latch, then write one and
>> instantiate it until your heart is content....but don't presume that
>> everyone else agrees with you and that the language itself should only
>> support your coding style for creating a latch and any other method should
>> cause an error.
>>
>>> This is another big problem: I don't know how ASIC people generate a
>>> real latch using VHDL? I think they may most likely use latch library
>>> to generate special latch instead of using VHDL statements.
>> That doesn't preclude them from inferring a latch in other ways.
>>
>>> I read an
>>> article about asynchronous FIFO written by two engineers one of whom
>>> is Pete Alfke of Xilinx (it is the best article I have read in my
>>> life). In the paper they say that they fail to generate two or 3
>>> latches in their design using Xilinx chip.
>> No idea what you mean by this...but reading on
>>
>>> If so, it seems to me that
>>> there is no reliable statement in VHDL to generate a latch for a FPGA
>>> chip.
>> Unless the underlying hardware has a hard latch available as a resource to
>> use and most (if not all) FPGAs do not, then I would agree that there is no
>> reliable way to generate a latch inside an FPGA in any language, not just
>> VHDL.  The lack of latches in FPGAs though has nothing at all to do with
>> VHDL or any language it is simply recognition by the FPGA suppliers that
>> there is very little demand for a hard latch inside the FPGA.  A flip flop
>> would have the exact same coding issues, the only reason it's not a
>> 'problem' is because there are hard flip flops inside the FPGA.
>>
>> The 'problem' with inferring any storage element (latch, flip flop, big
>> hunk-o-memory, fifo, etc.) is when the underlying hardware doesn't directly
>> support the inferred element and it needs to be cobbled together from basic
>> logic blocks.  In the FPGA/CPLD world, it is very difficult to meet internal
>> setup, hold time and 'no glitching' requirements between two arbitrary
>> signals.
>>
>> Remember also, that you can build ANY logical element strictly from NAND
>> gates or NOR gates....so in theory you could write your code using only
>> these two building blocks.  Were you to do so and target an FPGA, it would
>> most certainly fail if that design had any sort of storage.
>>
>>
>>
>>> 3. If the example would generate a latch for signalA, how it is
>>> generated?
>> Same as any other logical description....it gets mapped to whatever internal
>> resources exist in the device (LUTs, macrocells, flip flops, latches,
>> whatever the target device supports).
>>
>>
>>
>>> KJ answered the question. If the equation KJ suggested is true, it
>>> would like the following:
>>> if (state = stateA_S and a = "000001") then
>>>  signalA <= '1';
>>> end if;
>>> Finally I realized KJ saying is correct.
>> You're welcome.
>>
>> Kevin Jennings
> 
> Hi KJ,
> 1. Q <= (C and D) or (not(C) and Q);
> I have never seen such equation in my coding experiences and have no
> idea how this equation would be written. The logic result is beyond a
> reason. Could you please write it in equivalent latch equation in
> informal VHDL?

That equation is written exactly as-is and would work in theory. 
Glitches on Q while C goes from 1 to 0 may break the feedback loop or 
make it metastable in practice.

Another VHDL way of putting it would be:

Q <= D when C = '1' else Q;

An equivalent VHDL process would be:

process(c,d)
begin
	if(c='1') then
		q <= d;
	end if;
end process;

Exactly what each of these would actually infer is tool- and 
hardware-specific. The only thing you can do is check your synthesis 
reports to determine exactly what was synthesized. This applies to all 
matters of getting HDL to map onto specific FPGA resources.

> 2. FPGA of Xilinx chip really has latch primative and one may use it
> using latch primative to call it. But it is hard to refer to it in
> VHDL. I don't mean VHDL should have included latch statement, what I
> mean is VHDL really lacks the statement element to refer to a latch in
> a clear and reliable way and the lack can be easily corrected.

Latches: "if somesig='1' then ... end if;"
Latches(2): see equations and process above

FFs: "if clk='1' and clk'event then ... end if;"
FFs(2): "if rising_edge(clk) then ... end if;"

That seems like plenty straight-forward VHDL to me. Latches are active 
on levels, FFs are active on edges. Simple.

Xilinx devices do not have dedicated latches BUT they do allow you to 
program a slice FF to bypass HALF of it so it can be used as a latch. As 
far as power is concerned though, the whole FF is still connected to the 
clock so you most likely won't be saving any power here. BTW, the 
configuration logic that goes behind FPGA FFs uses more surface area 
than the FF itself and the "latch bypass logic" probably uses nearly as 
much power as a pure FF.

To reach high clock speeds, FPGAs and ASICs need their pipeline storage 
elements to be able to forward values from D to Q with as little setup, 
hold and settling time as possible to maximize timing margins between 
clock edges. This is most effortlessly and reliably achieved with FFs, 
hence the dominance of FFs in the world of high-speed digital systems 
and the FF-oriented nature of FPGAs even though they cost a little more 
surface area and power.

Simply put, FFs are the path of least unnecessary pain.

If you want lower power FPGAs, some flexibility has to be sacrificed. If 
Xilinx stripped the latch option from slice FFs, it would reduce the 
slice FF cells' power and size by 15-20% while making them a little bit 
faster. I wonder how many would have a problem with this.

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1173237015.878201.302510@p10g2000cwp.googlegroups.com...
> 1. Q <= (C and D) or (not(C) and Q);
> I have never seen such equation in my coding experiences and have no
> idea how this equation would be written. The logic result is beyond a
> reason. Could you please write it in equivalent latch equation in
> informal VHDL?
It's the same old transparent latch that we've been talking about all along. 
The following forms are exactly equivalent logic and will result in the 
exact same synthesized result.
#1 -- Traditional form of writing a latch
process(C, D)
begin
if (C='1') then
   Q <= D;
end if;
end process;

#2 -- Another traditional form of writing a latch.
Q <= D when (C = '1');

#3 -- Latch equations written as a sum of products
Q <= (C and D) or (not(C) and Q);

#4 -- Latch equation written in a sum of products form that includes a 
'cover' term
Q <= (C and D) or (not(C) and Q) or (D and Q);

Try all four of the above out and run them through synthesis and you should 
get the exact same fitted equations for all 4.

Of the four different forms, only #4 is written in a way that will not have 
timing issues that are caused simply by the implementation (over which you 
have no real control in an FPGA).  However, the last term ".. or (D and Q)" 
is redundant and any synthesizer worth a dime will 'optomize the logic' and 
implement it as form #3.  This 'optomization' though creates a logic hazard 
when 'C' switches from '1' to '0'.  This logic hazard will in turn show up 
as a failure in the latch operation.  Specifically, what you'll run into is 
that even if you have 'D' set up oodles of time before 'C' switches from '1' 
to '0', the output 'Q' can latch itself at either '1' or '0' (depending on 
the targetted part) because of differences in prop delay in computing the 
first two or terms or glitches in 'C'.  That last "D and Q" term is 
absolutely required in order to even have a shot at inferring a latch that 
will actually work but since it is logically 'redundant' it will always get 
optomized away.  If you hark back to Boolean Logic 101, you may recall that 
adding redundant terms is the method you employ to get rid of logic hazards. 
The FPGA LUT implementation leaves even more to the imagination as you 
wonder just what those RAM outputs are doing with this combinatorial loop 
and whether 'Q' will glitch and cause even more havoc since it would feed 
back to the address input of the LUT.

The bottom line is
- There are various forms of writing source code that infers a latch.
- Whether a latch is a 'good' thing or a 'bad' thing depends on the 
targetted device itself and whether that device actually has a hard latch 
and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
- Inferring any storage element (flops, latches, memory) needs to be done in 
such a way that the storage is not implemented as a collection of 
LUTs/macrocells but instead uses hard storage resources of the device.

>
> 2. FPGA of Xilinx chip really has latch primative and one may use it
> using latch primative to call it. But it is hard to refer to it in
> VHDL.
You'll still have trouble meeting and guaranteeing the timing and glitch 
requirements on 'D' relative to 'C' in order to get it to work correctly for 
arbitrary signals 'D' and 'C'.  If it does work, it likely won't scale well 
(i.e. if you try to infer thousands of these as you would like to)

> I don't mean VHDL should have included latch statement, what I
> mean is VHDL really lacks the statement element to refer to a latch in
> a clear and reliable way and the lack can be easily corrected.
>
I've shown above four different forms for inferring the exact same latch 
(i.e. synthesizes to the exact same thing).  Which form you prefer (or if 
you prefer to make up your own) to use is up to you.  Making up a new method 
though will not prohibit the earlier forms from being used and outlawing the 
other forms gets in the way of people who do use latches and are doing so in 
a way that they can control the various issues so you're not helping them by 
outlawing their method.

Kevin Jennings 

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1173140726.435538.84620@30g2000cwc.googlegroups.com...
> Hi,
> I am very confused with latch generation in VHDL.
>
> 1. I have been using VHDL for 7 years and I have never met a situation
> I need a latch.
>
Just thought I'd add to this thread that, all other things being equal, 
latches generally have less setup time than FFs. This can be important for 
some circuits.
HTH, Syms. 

On Mar 7, 3:02 am, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> news:1173237015.878201.302510@p10g2000cwp.googlegroups.com...> 1. Q <= (C and D) or (not(C) and Q);
> > I have never seen such equation in my coding experiences and have no
> > idea how this equation would be written. The logic result is beyond a
> > reason. Could you please write it in equivalent latch equation in
> > informal VHDL?
>
> It's the same old transparent latch that we've been talking about all along.
> The following forms are exactly equivalent logic and will result in the
> exact same synthesized result.
> #1 -- Traditional form of writing a latch
> process(C, D)
> begin
> if (C='1') then
>    Q <= D;
> end if;
> end process;
>
> #2 -- Another traditional form of writing a latch.
> Q <= D when (C = '1');
>
> #3 -- Latch equations written as a sum of products
> Q <= (C and D) or (not(C) and Q);
>
> #4 -- Latch equation written in a sum of products form that includes a
> 'cover' term
> Q <= (C and D) or (not(C) and Q) or (D and Q);
>
> Try all four of the above out and run them through synthesis and you should
> get the exact same fitted equations for all 4.
>
> Of the four different forms, only #4 is written in a way that will not have
> timing issues that are caused simply by the implementation (over which you
> have no real control in an FPGA).  However, the last term ".. or (D and Q)"
> is redundant and any synthesizer worth a dime will 'optomize the logic' and
> implement it as form #3.  This 'optomization' though creates a logic hazard
> when 'C' switches from '1' to '0'.  This logic hazard will in turn show up
> as a failure in the latch operation.  Specifically, what you'll run into is
> that even if you have 'D' set up oodles of time before 'C' switches from '1'
> to '0', the output 'Q' can latch itself at either '1' or '0' (depending on
> the targetted part) because of differences in prop delay in computing the
> first two or terms or glitches in 'C'.  That last "D and Q" term is
> absolutely required in order to even have a shot at inferring a latch that
> will actually work but since it is logically 'redundant' it will always get
> optomized away.  If you hark back to Boolean Logic 101, you may recall that
> adding redundant terms is the method you employ to get rid of logic hazards.
> The FPGA LUT implementation leaves even more to the imagination as you
> wonder just what those RAM outputs are doing with this combinatorial loop
> and whether 'Q' will glitch and cause even more havoc since it would feed
> back to the address input of the LUT.
>
> The bottom line is
> - There are various forms of writing source code that infers a latch.
> - Whether a latch is a 'good' thing or a 'bad' thing depends on the
> targetted device itself and whether that device actually has a hard latch
> and a way to guarantee the timing and glitch requirements of 'D' and 'C'.
> - Inferring any storage element (flops, latches, memory) needs to be done in
> such a way that the storage is not implemented as a collection of
> LUTs/macrocells but instead uses hard storage resources of the device.
>
>
>
> > 2. FPGA of Xilinx chip really has latch primative and one may use it
> > using latch primative to call it. But it is hard to refer to it in
> > VHDL.
>
> You'll still have trouble meeting and guaranteeing the timing and glitch
> requirements on 'D' relative to 'C' in order to get it to work correctly for
> arbitrary signals 'D' and 'C'.  If it does work, it likely won't scale well
> (i.e. if you try to infer thousands of these as you would like to)
>
> > I don't mean VHDL should have included latch statement, what I
> > mean is VHDL really lacks the statement element to refer to a latch in
> > a clear and reliable way and the lack can be easily corrected.
>
> I've shown above four different forms for inferring the exact same latch
> (i.e. synthesizes to the exact same thing).  Which form you prefer (or if
> you prefer to make up your own) to use is up to you.  Making up a new method
> though will not prohibit the earlier forms from being used and outlawing the
> other forms gets in the way of people who do use latches and are doing so in
> a way that they can control the various issues so you're not helping them by
> outlawing their method.
>
> Kevin Jennings

Hi KJ,
Thank you very much for your points.

Your answer really opens my eye and expand my knowledge range in FPGA
and VHDL !!!

Weng

On Mar 7, 5:57 am, "Symon" <symon_bre...@hotmail.com> wrote:>
> Just thought I'd add to this thread that, all other things being equal,
> latches generally have less setup time than FFs. This can be important for
> some circuits.
> HTH, Syms.

Symon, I disagree.
The set-up time of a flip-flop is really the set-up time of the master
latch (the last chance for input data to become locked up in the latch
when the clock is going High.) The flip-flop's slave latch has nothing
to do with the set-up time. Therefore I see no reason for the flip-
flop to have a longer set-up time than a simple latch.  The evidence
seems to be anecdotal...
Peter Alfke

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1173287136.833622.29220@v33g2000cwv.googlegroups.com...
> On Mar 7, 5:57 am, "Symon" <symon_bre...@hotmail.com> wrote:>
>> Just thought I'd add to this thread that, all other things being equal,
>> latches generally have less setup time than FFs. This can be important 
>> for
>> some circuits.
>> HTH, Syms.
>
> Symon, I disagree.
> The set-up time of a flip-flop is really the set-up time of the master
> latch (the last chance for input data to become locked up in the latch
> when the clock is going High.) The flip-flop's slave latch has nothing
> to do with the set-up time. Therefore I see no reason for the flip-
> flop to have a longer set-up time than a simple latch.  The evidence
> seems to be anecdotal...
> Peter Alfke
>
>
Hi Peter,
Yes, thinking about it again, you're absolutely right. I dredged back though 
my memory and the situation I so badly recalled was a double data rate 
circuit near the toggle limit of the part. I needed to synchronise phase 
alignment between two signals, one in the rising and one in the falling edge 
clock domains. To do this I had the output of a falling edge FF feeding the 
input of a rising edge FF. By changing the falling edge FF to a latch 
(transparent when clock is high), I gained extra set-up time for the rising 
edge FF, as the latch passed data through a little earlier.
Many thanks for correcting me, and putting the record straight.
Best regards, Symon. 

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:esmu00$mnc$1@aioe.org...
> Hi Peter,
> Yes, thinking about it again, you're absolutely right. I dredged back 
> though my memory and the situation I so badly recalled was a double data 
> rate circuit near the toggle limit of the part. I needed to synchronise 
> phase alignment between two signals, one in the rising and one in the 
> falling edge clock domains. To do this I had the output of a falling edge 
> FF feeding the input of a rising edge FF. By changing the falling edge FF 
> to a latch (transparent when clock is high), I gained extra set-up time 
> for the rising edge FF, as the latch passed data through a little earlier.
> Many thanks for correcting me, and putting the record straight.
> Best regards, Symon.


I've come up with this approach myself, subsequently seen it mentioned in an 
app note, and now find you've concluded the same circuit is useful in this 
situation.

More engineers should be exposed to this one application where a latch is 
indespensible.  Without it, DDR domains can get messy.

The one sad thing about it, in my opinion, is that the Xilinx timing tools 
don't treat this case well.  My recollection is that the setup is referenced 
to the wrong edge giving me no chance to get clean numbers by only including 
latch_d_q path tracing.

- John_H 

On Mar 7, 10:41 am, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:esmu00$mnc$1@aioe.org...
>
> > Hi Peter,
> > Yes, thinking about it again, you're absolutely right. I dredged back
> > though my memory and the situation I so badly recalled was a double data
> > rate circuit near the toggle limit of the part. I needed to synchronise
> > phase alignment between two signals, one in the rising and one in the
> > falling edge clock domains. To do this I had the output of a falling edge
> > FF feeding the input of a rising edge FF. By changing the falling edge FF
> > to a latch (transparent when clock is high), I gained extra set-up time
> > for the rising edge FF, as the latch passed data through a little earlier.
> > Many thanks for correcting me, and putting the record straight.
> > Best regards, Symon.
>
> I've come up with this approach myself, subsequently seen it mentioned in an
> app note, and now find you've concluded the same circuit is useful in this
> situation.
>
> More engineers should be exposed to this one application where a latch is
> indespensible.  Without it, DDR domains can get messy.
>
> The one sad thing about it, in my opinion, is that the Xilinx timing tools
> don't treat this case well.  My recollection is that the setup is referenced
> to the wrong edge giving me no chance to get clean numbers by only including
> latch_d_q path tracing.
>
> - John_H

Hi John,
Could you please tell which application note you are talking about.

Thank you.

Weng