VHDL and Latch

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1173293293.597472.321940@p10g2000cwp.googlegroups.com...
> 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

I thought it was XAPP250

http://www.xilinx.com/bvdocs/appnotes/xapp250.pdf

but a quick scan of the document and search for "latch" came up empty.  Some 
of the techniques I've been using lately are mentioned in that article as 
are the ones in XAPP671.  Ah, there it is.  Mentioned on page 4 and 
elaborated on page 11:

http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf

Fun with silicon!

- John_H

On Mar 7, 12:16 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> news:1173293293.597472.321940@p10g2000cwp.googlegroups.com...
>
>
>
>
>
> > 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
>
> I thought it was XAPP250
>
> http://www.xilinx.com/bvdocs/appnotes/xapp250.pdf
>
> but a quick scan of the document and search for "latch" came up empty.  Some
> of the techniques I've been using lately are mentioned in that article as
> are the ones in XAPP671.  Ah, there it is.  Mentioned on page 4 and
> elaborated on page 11:
>
> http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf
>
> Fun with silicon!
>
> - John_H- Hide quoted text -
>
> - Show quoted text -

Hi John,
Thank you for your suggestion.

Silicon is living and money to me.

Weng

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,
I have another question for you.

1. Is any combinational equation with target signal in both right part
and left part of the equation a latch like your equations 3 or 4 show?

2. Is there any general algorithm to change such an equation to a
latch equation?

Thank you.

Weng

Weng
> Hi KJ,
> I have another question for you.
> 
 >> Q <= (C and D) or (not(C) and Q);
> 1. Is any combinational equation with target signal in both right part
> and left part of the equation a latch like your equations 3 or 4 show?

A latch is the most benign form.
There are oscillators (however when they occur by
accident, they are not necessarily this obvious):
    Q <= not Q ;

There is also other strange latch-like behavior.
I don't have an equation for you, but I do remember
analyzing one - it was very interesting.

Cheers,
Jim

I think we will agree that a latch needs positive feedback from the
output to at least one of the inputs.
If the feedback is negative (Qbar to D, for example) you end up with
an oscillator.
Peter Alfke

On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote:
> Weng> Hi KJ,
> > I have another question for you.
>
>  >> Q <= (C and D) or (not(C) and Q);
>
> > 1. Is any combinational equation with target signal in both right part
> > and left part of the equation a latch like your equations 3 or 4 show?
>
> A latch is the most benign form.
> There are oscillators (however when they occur by
> accident, they are not necessarily this obvious):
>     Q <= not Q ;
>
> There is also other strange latch-like behavior.
> I don't have an equation for you, but I do remember
> analyzing one - it was very interesting.
>
> Cheers,
> Jim

On Mar 8, 11:36 am, "Weng Tianxiang" <wtx...@gmail.com> wrote:
> 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,
> I have another question for you.
>
> 1. Is any combinational equation with target signal in both right part
> and left part of the equation a latch like your equations 3 or 4 show?
While Jim and Peter can debate whether or not it's a latch or an
oscillator, suffice it to say that any time you have something of the
form of equations #3 and #4 where you have the same signal on both
sides of the '<=' in a concurrent statement you have some form of
storage or memory being inferred that will cause you the exact same
timing/glitch/hazard issues to deal with as you would if you have
something that matches exactly #3 and #4.

The important thing to take away is not whether it's a latch or an
oscillator or anything else, just that red flags should go off in your
head when you see the output being used on the right side of the
equation.  Whether this is a problem or not depends on what the target
device is.  In ASICs this will not be a problem, in FPGAs you have to
be very careful or it will be a problem.

>
> 2. Is there any general algorithm to change such an equation to a
> latch equation?
Not sure what you mean....all four forms that I presented are exactly
equivalent 'latch equations', they will produce the same synthesized
result.  Equations #1 and #2 involve less typing then #3 and #4.

Also keep in mind, that latches do not need to fit into a single
equation, any time that you form a combinatorial loop you have to be
concerned about how this will get implemented.  A combinatorial loop
happens when you have multiple equations, none of which inherently
shows any feedback but taken together the whole set does.  A simple
example of this would be

#5
Q <= (C and X) or (not(C) and Y);  -- Eqn. 5a
Y <= Q and Z;  -- Eqn. 5b

Equation 5a, on the surface appears to be a 2->1 multiplexer where 'C'
is simply used to select between two signals 'X' and 'Y'.

Equation 5b, on the surface appears to be a simple anding of two
signals 'Q' and 'Z'.

But when you put them together the two form a combinatorial loop
because 'Q' depends on 'Y' and 'Y' depends on 'Q'.  When you run
through synthesis, these things generally get flagged as warnings
somewhere.  The nice thing is that it will find all these loops no
matter how complex the equations or how spread out they are as long as
they are totally self contained within the entire design.  By that I
mean, lets say that Equation 5a was implemented in some entity
somewhere in some file and Equation 5b in a totally different entity
in some other file.  By themselves, each entity/file will synthesize
just fine.  But when you add the code for the entity that ties these
two blocks together that new design and synthesize that new block,
you'll have now formed the loop and the synthesizer should flag the
warning for you.  Take those warning seriously if you're designing in
the FPGA/CPLD world.

Kevin Jennings

Peter,
No argument from me as you seem to be saying the same
thing I said.

I interpreted Weng's question as being, when a combinational
signal is on both the right and left side of an equation,
is the only hardware solution a latch.

The answer which we both observed is no and the simple
case is an oscillator.

Cheers,
Jim


> I think we will agree that a latch needs positive feedback from the
> output to at least one of the inputs.
> If the feedback is negative (Qbar to D, for example) you end up with
> an oscillator.
> Peter Alfke
> 
> On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote:
>> Weng> Hi KJ,
>>> I have another question for you.
>>  >> Q <= (C and D) or (not(C) and Q);
>>
>>> 1. Is any combinational equation with target signal in both right part
>>> and left part of the equation a latch like your equations 3 or 4 show?
>> A latch is the most benign form.
>> There are oscillators (however when they occur by
>> accident, they are not necessarily this obvious):
>>     Q <= not Q ;
>>
>> There is also other strange latch-like behavior.
>> I don't have an equation for you, but I do remember
>> analyzing one - it was very interesting.
>>
>> Cheers,
>> Jim
> 
> 

On Mar 8, 4:18 pm, Jim Lewis <j...@synthworks.com> wrote:
> Peter,
> No argument from me as you seem to be saying the same
> thing I said.
>
> I interpreted Weng's question as being, when a combinational
> signal is on both the right and left side of an equation,
> is the only hardware solution a latch.
>
> The answer which we both observed is no and the simple
> case is an oscillator.
>
> Cheers,
> Jim
>
>
>
> > I think we will agree that a latch needs positive feedback from the
> > output to at least one of the inputs.
> > If the feedback is negative (Qbar to D, for example) you end up with
> > an oscillator.
> > Peter Alfke
>
> > On Mar 8, 9:49 am, Jim Lewis <j...@synthworks.com> wrote:
> >> Weng> Hi KJ,
> >>> I have another question for you.
> >>  >> Q <= (C and D) or (not(C) and Q);
>
> >>> 1. Is any combinational equation with target signal in both right part
> >>> and left part of the equation a latch like your equations 3 or 4 show?
> >> A latch is the most benign form.
> >> There are oscillators (however when they occur by
> >> accident, they are not necessarily this obvious):
> >>     Q <= not Q ;
>
> >> There is also other strange latch-like behavior.
> >> I don't have an equation for you, but I do remember
> >> analyzing one - it was very interesting.
>
> >> Cheers,
> >> Jim- Hide quoted text -
>
> - Show quoted text -

Hi KJ, Jim and Peter,
Thank you for your response and help.

Anyway now I understand the latch a little more than before the
posting.

In coding experiences, when writing code equations, a reasonalble FPGA
engineer will never generate a situation that leads to a signal
appearing in both sides of logic equation in concurrent area. Because
most of time the odd behavior equations would be fully beyond the
acknowledgable. And there is no reason to generate an oscillator
neither.

Jim correctly repeated my question and both of you gave me a right
answer.

Weng

Weng,
 > 2. Is there any general algorithm to change such an
 > equation to a latch equation?
I have not seen any evidence of one you can expect different
tool vendors to support.

For RTL code, if you want a synthesis tool to reliably
create a latch library part, only use #1 or #2 (below from
KJs post).  Going further, if you want to avoid portability
issues with some of the ASIC synthesis tools, then use
only #1.

>> #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');

If you use other forms, a synthesis tool may generate
logic that implements latching behavior without using
a latch part.  If you use these to deliberately create
a latch, good luck.

Generally people accidentally create the other forms
when two separate pieces of logic communicate.

Cheers,
Jim

On Mar 8, 4:30 pm, Jim Lewis <j...@synthworks.com> wrote:
> Weng,
>  > 2. Is there any general algorithm to change such an
>  > equation to a latch equation?
> I have not seen any evidence of one you can expect different
> tool vendors to support.
>
> For RTL code, if you want a synthesis tool to reliably
> create a latch library part, only use #1 or #2 (below from
> KJs post).  Going further, if you want to avoid portability
> issues with some of the ASIC synthesis tools, then use
> only #1.
>
> >> #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');
>
> If you use other forms, a synthesis tool may generate
> logic that implements latching behavior without using
> a latch part.  If you use these to deliberately create
> a latch, good luck.
>
> Generally people accidentally create the other forms
> when two separate pieces of logic communicate.
>
> Cheers,
> Jim

Hi Jim,
I am not going to write an odd equation to confuse VHDL compilers that
would be stupid, but just wondering about how can a VHDL compiler
figure out its inherent complex structures.

The best way to do FPGA design is to follow rules. No exceptions.

>From this posing, I have learned how to write a latch correctly in
standard VHDL form, how to use a new possible attribute to let VHDL
compiler to generate an error information, instead of a warning
information, and the last and not the least, how to avoid confusing
VHDL compiler by using a signal name in both side of "<=" in
concurrent area.

Thank you.

Weng