Are all these claims in VHDL correct?

Hi,
I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim
simulations.

signal   X  : unsigned(63 downto 0);
signal   X0 : unsigned(63 downto 0);
signal   X1 : unsigned(63 downto 0);
signal   X2 : unsigned(63 downto 0);
signal   X3 : unsigned(63 downto 0);
signal   A1 : std_logic;
signal   A2 : std_logic;
signal   A3 : std_logic;

1. The following M1 and M2 process code implementations are the same:

M1 : process(..)
begin
   X <= X0;
   if A1 = '1' then
      X <= X1;
      if A2 = '1' then
         X <= X2;
      elsif A3 = '1' then
         X <= X3;
      end if;
   end if;
end process;

M2 : process(..)
begin
   if A1 = '1' then
      if A2 = '1' then
         X <= X2;
      elsif A3 = '1' then
         X <= X3;
      else
         X <= X1;
      end if;
   else
      X <= X0;
   end if;
end process;

2. The following M3 to M5 process code implementations are the same:

M3 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   else
      null;
   end if;
end process;

M4 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   end if;
end process;

M5 : process(A1)
begin
   if A1 = '1' then
      X <= X1;
   else
      X <= X;
   end if;
end process;

3. The following M6 to M8 process code implementations are the same:

M6 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      else
         null;
      end if;
   end if;
end process;

M7 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      end if;
   end if;
end process;

M8 : process(CLK)
begin
   if CLK'event and CLK = '1' then
      if A1 = '1' then
         X <= X1;
      else
         X <= X;
      end if;
   end if;
end process;

Thank you.

Weng

On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote:

>I am trying to claim the following things in VHDL in
>some written materials, and want to know if they are absolute
>correct practically based on Xilinx FPGA implementations, not
>theoretically on ModelSim simulations.

That's a very strange way to look at it.  The VHDL language
is defined by its simulation semantics.  Synthesis creates
hardware that conforms to a certain (very useful) subset
of those behaviours.  It makes no sense to say that your
understanding of VHDL is "absolutely correct... based on
FPGA implementations".

On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?".

>signal   X  : unsigned(63 downto 0);
>signal   X0 : unsigned(63 downto 0);
>signal   X1 : unsigned(63 downto 0);
>signal   X2 : unsigned(63 downto 0);
>signal   X3 : unsigned(63 downto 0);
>signal   A1 : std_logic;
>signal   A2 : std_logic;
>signal   A3 : std_logic;
>
>1. The following M1 and M2 process code implementations are the same:
>
>M1 : process(..)
>begin
>   X <= X0;
>   if A1 = '1' then
>      X <= X1;
>      if A2 = '1' then
>         X <= X2;
>      elsif A3 = '1' then
>         X <= X3;
>      end if;
>   end if;
>end process;
>
>M2 : process(..)
>begin
>   if A1 = '1' then
>      if A2 = '1' then
>         X <= X2;
>      elsif A3 = '1' then
>         X <= X3;
>      else
>         X <= X1;
>      end if;
>   else
>      X <= X0;
>   end if;
>end process;

Well... single-stepping through the two pieces of
code in a simulator will of course show slightly
different sequences of activity, but I agree that
the externally-visible results of the two processes
should be identical.  It is impossible to tell the
difference between

  Y <= A;
  Y <= B; -- completely replaces assignment Y<=A

and

  Y <= B;

(unless the evaluation of expression A has side-effects,
of course).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>2. The following M3 to M5 process code implementations are the same:
>
>M3 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   else
>      null;
>   end if;
>end process;
>
>M4 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   end if;
>end process;

I agree that these two are identical in every meaningful way.
"null;" really does nothing.

>M5 : process(A1)
>begin
>   if A1 = '1' then
>      X <= X1;
>   else
>      X <= X;
>   end if;
>end process;

No, this is not the same.  In M5 but not in M4, when 
A1 transitions to a value that is not '1', signal X 
is written; there will be no value-change on X as a 
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

None of the processes M3 to M5 follow any conventional
synthesis template.  If you had included X1 in the 
sensitivity list, they would all be perfectly good
descriptions of a transparent latch.  If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>3. The following M6 to M8 process code implementations are the same:
>
>M6 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      else
>         null;
>      end if;
>   end if;
>end process;
>
>M7 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      end if;
>   end if;
>end process;

M6 and M7 are completely identical in behaviour, yes.

>M8 : process(CLK)
>begin
>   if CLK'event and CLK = '1' then
>      if A1 = '1' then
>         X <= X1;
>      else
>         X <= X;
>      end if;
>   end if;
>end process;

Same discussion as for M5, above.

-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:ri0a15dqak38clq3j8uuvb2tl6lusob9lu@4ax.com...
>>
>>M4 : process(A1)
>>begin
>>   if A1 = '1' then
>>      X <= X1;
>>   end if;
>>end process;
>
> I agree that these two are identical in every meaningful way.
> "null;" really does nothing.
>
>>M5 : process(A1)
>>begin
>>   if A1 = '1' then
>>      X <= X1;
>>   else
>>      X <= X;
>>   end if;
>>end process;
>
> No, this is not the same.  In M5 but not in M4, when
> A1 transitions to a value that is not '1', signal X
> is written; there will be no value-change on X as a
> result, for sure, but there *is* a transaction on X
> and that could be detected, outside the process,
> with the 'transaction, 'active or 'quiet attributes.
>
> None of the processes M3 to M5 follow any conventional
> synthesis template.  If you had included X1 in the
> sensitivity list, they would all be perfectly good
> descriptions of a transparent latch.  If you had
> rewritten the condition as "if rising_edge(A1)" they
> would all be perfectly good descriptions of a register.
>

>>
>>M7 : process(CLK)
>>begin
>>   if CLK'event and CLK = '1' then
>>      if A1 = '1' then
>>         X <= X1;
>>      end if;
>>   end if;
>>end process;
>
> M6 and M7 are completely identical in behaviour, yes.
>
>>M8 : process(CLK)
>>begin
>>   if CLK'event and CLK = '1' then
>>      if A1 = '1' then
>>         X <= X1;
>>      else
>>         X <= X;
>>      end if;
>>   end if;
>>end process;
>
> Same discussion as for M5, above.
>

I'm missing the point here.  The sensitivity list for M4 and M5 only 
includes A1, so any change in X1 doesn't propagate through to X in either 
case.

Also, are you suggesting that an X <= X; would be seen as a transaction 
within a sensitivity list?

M9: process (X)
begin
    if X = '1' then
        Y <= Y1;
    end if;
end process;

where Y will take on the value of Y1, despite no change in X?

On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:

>> None of the processes M3 to M5 follow any conventional
>> synthesis template.  If you had included X1 in the
>> sensitivity list, they would all be perfectly good
>> descriptions of a transparent latch.  If you had
>> rewritten the condition as "if rising_edge(A1)" they
>> would all be perfectly good descriptions of a register.
[...]
>I'm missing the point here.  The sensitivity list for M4 and M5 only 
>includes A1, so any change in X1 doesn't propagate through to X in either 

Right.  So the description is not a piece of synthesisable
hardware; it's neither a latch, nor a register, nor a 
combinational function.  I agree that the externally 
observable simulation behaviour would be the same for
all those examples, apart from the 'transaction thing
I mentioned.  But it's not very useful.

>Also, are you suggesting that an X <= X; would be seen as a transaction 
>within a sensitivity list?

No.  Be careful about the terminology; sensitivity lists see
EVENTS, i.e. value-changes, on a signal; there is of course
no such event as a result of X<=X.  However, there is a
TRANSACTION, an attempt to update X.  You can't ordinarily
see transactions in VHDL, but you can detect them using
the built-in attributes I mentioned.

>M9: process (X)
>begin
>    if X = '1' then
>        Y <= Y1;
>    end if;
>end process;
>
>where Y will take on the value of Y1, despite no change in X?

Sorry, I don't see what you're asking here.  If there's no change
in X's value then the process won't run and Y won't update.
In a real hardware transparent latch, you DO expect Y to follow
the input Y1 if the enable X is asserted; you can easily get this
by including both X and Y1 in the sensitivity list, and that gives
you a good synthesisable description of a transparent latch.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:g85a15lp0jd5kap4u0n5rlbq82k2l3mbh1@4ax.com...
> On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:
>
>>> None of the processes M3 to M5 follow any conventional
>>> synthesis template.  If you had included X1 in the
>>> sensitivity list, they would all be perfectly good
>>> descriptions of a transparent latch.  If you had
>>> rewritten the condition as "if rising_edge(A1)" they
>>> would all be perfectly good descriptions of a register.
> [...]
>>I'm missing the point here.  The sensitivity list for M4 and M5 only
>>includes A1, so any change in X1 doesn't propagate through to X in either
>
> Right.  So the description is not a piece of synthesisable
> hardware; it's neither a latch, nor a register, nor a
> combinational function.  I agree that the externally
> observable simulation behaviour would be the same for
> all those examples, apart from the 'transaction thing
> I mentioned.  But it's not very useful.
>
>>Also, are you suggesting that an X <= X; would be seen as a transaction
>>within a sensitivity list?
>
> No.  Be careful about the terminology; sensitivity lists see
> EVENTS, i.e. value-changes, on a signal; there is of course
> no such event as a result of X<=X.  However, there is a
> TRANSACTION, an attempt to update X.  You can't ordinarily
> see transactions in VHDL, but you can detect them using
> the built-in attributes I mentioned.
>

It is synthsisable but perhaps not tgive the intended result.  In essence an 
event on A1 and A1 = 1, would cause the value X1 to be latched into X.  In 
both cases?

>>M9: process (X)
>>begin
>>    if X = '1' then
>>        Y <= Y1;
>>    end if;
>>end process;
>>
>>where Y will take on the value of Y1, despite no change in X?
>
> Sorry, I don't see what you're asking here.  If there's no change
> in X's value then the process won't run and Y won't update.
> In a real hardware transparent latch, you DO expect Y to follow
> the input Y1 if the enable X is asserted; you can easily get this
> by including both X and Y1 in the sensitivity list, and that gives
> you a good synthesisable description of a transparent latch.


That was my point, how would a transaction on X be "seen"? I thought VHDL 
was all about events.

On Thu, 21 May 2009 10:09:26 +0100, "Fredxx" wrote:

[regarding this example]

  M4 : process(A1)
  begin
     if A1 = '1' then
        X <= X1;
     end if;
  end process;

>It is synthsisable but perhaps not tgive the intended result.  
>In essence an event on A1 and A1 = 1, would cause the value 
>X1 to be latched into X.

I'm confused.  I already explained, with justification,
why it's not correctly synthesisable, and then you tell 
me it is...

Here's why that is BAD code for synthesis:
- The description, as you say, implies latching only on the
  rising edge of A1.  Like a D flop.
- But there is no "if A1'event" or "if rising_edge(A1)" in
  the process.  So it doesn't match the standard clocked
  synthesis template.

In the synth tool I tried just now (Mentor Precision)
I got a warning about precisely this, telling me that
there might be synthesis/simulation mismatches (there will).
And it created a transparent latch, because - as usual -
for any non-clocked process, synthesis will assume a 
complete sensitivity list.  Personally I would prefer it
if synthesis tools were to reject the code as an error,
but that's not what happens; instead you get hardware 
whose behaviour doesn't match the simulation.  I'm fairly
sure that almost all mainstream synthesis tools behave
in a similar way on this example, but I can't be bothered
trying them all because it's code that should not be
synthesised.

>In both cases?

I already stated, correctly and with explanation, that 
Weng's processes M4 and M5 have identical behaviour
in simulation.  Both of them are inappropriate for
synthesis.

>how would a transaction on X be "seen"? I thought VHDL 
>was all about events.

As I already pointed out, you can sense transactions in
simulation by using the 'transaction, 'active and 'quiet
built-in attributes.  VHDL transactions have no use
in synthesis.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

I think we can summarize...

M1 and M2 will synthesize to identical combinatorial circuits. There
may be warnings about synthesis/simulations mis-matches if the
sensitivity lists are not complete.

M3, M4 and M5 will synthesize to identical combinatorial circuits,
with a warning on the incomplete sensitivity list.

M6 and M7 will synthesize to identical sequential circuits (D-flop
with clk enable). M8 will synthesize to a sequential circuit with
identical behavior (on a clock cycle basis) to that of M6 and M7, but
the synthesis tool may try to build a feedback mux instead of using
the built-in clk enable on the register. Different synthesis tools may
handle this differently.

It should be noted that if X were a port of mode OUT (or an alias
thereof), then the processes that attempt to read X (M5 & M8) would
not synthesize at all.

It should also be noted that of M1 and M2, M1 is preferable for one
significant reason: The default assignemnt to X up front makes it very
easy to verify that M1 will not result in a latch. It is more
difficult to verify that M2 will not result in a latch.

Andy

On May 21, 12:40=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote:
> >I am trying to claim the following things in VHDL in
> >some written materials, and want to know if they are absolute
> >correct practically based on Xilinx FPGA implementations, not
> >theoretically on ModelSim simulations.
>
> That's a very strange way to look at it. =A0The VHDL language
> is defined by its simulation semantics. =A0Synthesis creates
> hardware that conforms to a certain (very useful) subset
> of those behaviours. =A0It makes no sense to say that your
> understanding of VHDL is "absolutely correct... based on
> FPGA implementations".
>
> On the other hand, you CAN reasonably ask "do these two
> pieces of VHDL code imply identical synthesised hardware?".
>
>
>
>
>
> >signal =A0 X =A0: unsigned(63 downto 0);
> >signal =A0 X0 : unsigned(63 downto 0);
> >signal =A0 X1 : unsigned(63 downto 0);
> >signal =A0 X2 : unsigned(63 downto 0);
> >signal =A0 X3 : unsigned(63 downto 0);
> >signal =A0 A1 : std_logic;
> >signal =A0 A2 : std_logic;
> >signal =A0 A3 : std_logic;
>
> >1. The following M1 and M2 process code implementations are the same:
>
> >M1 : process(..)
> >begin
> > =A0 X <=3D X0;
> > =A0 if A1 =3D '1' then
> > =A0 =A0 =A0X <=3D X1;
> > =A0 =A0 =A0if A2 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X2;
> > =A0 =A0 =A0elsif A3 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X3;
> > =A0 =A0 =A0end if;
> > =A0 end if;
> >end process;
>
> >M2 : process(..)
> >begin
> > =A0 if A1 =3D '1' then
> > =A0 =A0 =A0if A2 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X2;
> > =A0 =A0 =A0elsif A3 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X3;
> > =A0 =A0 =A0else
> > =A0 =A0 =A0 =A0 X <=3D X1;
> > =A0 =A0 =A0end if;
> > =A0 else
> > =A0 =A0 =A0X <=3D X0;
> > =A0 end if;
> >end process;
>
> Well... single-stepping through the two pieces of
> code in a simulator will of course show slightly
> different sequences of activity, but I agree that
> the externally-visible results of the two processes
> should be identical. =A0It is impossible to tell the
> difference between
>
> =A0 Y <=3D A;
> =A0 Y <=3D B; -- completely replaces assignment Y<=3DA
>
> and
>
> =A0 Y <=3D B;
>
> (unless the evaluation of expression A has side-effects,
> of course).
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
> >2. The following M3 to M5 process code implementations are the same:
>
> >M3 : process(A1)
> >begin
> > =A0 if A1 =3D '1' then
> > =A0 =A0 =A0X <=3D X1;
> > =A0 else
> > =A0 =A0 =A0null;
> > =A0 end if;
> >end process;
>
> >M4 : process(A1)
> >begin
> > =A0 if A1 =3D '1' then
> > =A0 =A0 =A0X <=3D X1;
> > =A0 end if;
> >end process;
>
> I agree that these two are identical in every meaningful way.
> "null;" really does nothing.
>
> >M5 : process(A1)
> >begin
> > =A0 if A1 =3D '1' then
> > =A0 =A0 =A0X <=3D X1;
> > =A0 else
> > =A0 =A0 =A0X <=3D X;
> > =A0 end if;
> >end process;
>
> No, this is not the same. =A0In M5 but not in M4, when
> A1 transitions to a value that is not '1', signal X
> is written; there will be no value-change on X as a
> result, for sure, but there *is* a transaction on X
> and that could be detected, outside the process,
> with the 'transaction, 'active or 'quiet attributes.
>
> None of the processes M3 to M5 follow any conventional
> synthesis template. =A0If you had included X1 in the
> sensitivity list, they would all be perfectly good
> descriptions of a transparent latch. =A0If you had
> rewritten the condition as "if rising_edge(A1)" they
> would all be perfectly good descriptions of a register.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
> >3. The following M6 to M8 process code implementations are the same:
>
> >M6 : process(CLK)
> >begin
> > =A0 if CLK'event and CLK =3D '1' then
> > =A0 =A0 =A0if A1 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X1;
> > =A0 =A0 =A0else
> > =A0 =A0 =A0 =A0 null;
> > =A0 =A0 =A0end if;
> > =A0 end if;
> >end process;
>
> >M7 : process(CLK)
> >begin
> > =A0 if CLK'event and CLK =3D '1' then
> > =A0 =A0 =A0if A1 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X1;
> > =A0 =A0 =A0end if;
> > =A0 end if;
> >end process;
>
> M6 and M7 are completely identical in behaviour, yes.
>
> >M8 : process(CLK)
> >begin
> > =A0 if CLK'event and CLK =3D '1' then
> > =A0 =A0 =A0if A1 =3D '1' then
> > =A0 =A0 =A0 =A0 X <=3D X1;
> > =A0 =A0 =A0else
> > =A0 =A0 =A0 =A0 X <=3D X;
> > =A0 =A0 =A0end if;
> > =A0 end if;
> >end process;
>
> Same discussion as for M5, above.
>
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.- Hide quote=
d text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Hi Jonathan,
Once again I get your valuable comments.

1. "On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?". "

Yes, you are right and I accept it.

2. >M5 : process(A1)
>begin
>   if A1 =3D '1' then
>      X <=3D X1;
>   else
>      X <=3D X;
>   end if;
>end process;


No, this is not the same.  In M5 but not in M4, when
A1 transitions to a value that is not '1', signal X
is written; there will be no value-change on X as a
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

If M5 Xilinx implementation were carried out for M3 or M4, you
couldn't tell there was a transaction on X,
because it didn't generate a transaction information except it really
happend internally.
It may violate the true spirit of coding, but it doesn't hurt anybody
and always gives the correct result.

3. I have to frankly admit that I have no hardware transparent latch
in my mind. In all my designs, there are only two data signal types:
register or combinational signal.
Your comments bring me back some ideas about transparent latch:

M9: process (X, Y1)
begin
    if X =3D '1' then
        Y <=3D Y1;
    end if;
end process;

Does it mean:
X is connected to the latch enable terminal and Y1 to data input
terminal and Y is configured as a transparent latch?

Thank you.

Weng

On Thu, 21 May 2009 08:56:15 -0700 (PDT), Weng Tianxiang wrote:


>If M5 Xilinx implementation were carried out for M3 or M4, you
>couldn't tell there was a transaction on X,
>because it didn't generate a transaction information except it really
>happend internally.
>It may violate the true spirit of coding, but it doesn't hurt anybody
>and always gives the correct result.

Yes, I completely agree.  They are the same for synthesis,
in every tool I have tried.

>M9: process (X, Y1)
>begin
>    if X = '1' then
>        Y <= Y1;
>    end if;
>end process;
>
>Does it mean:
>X is connected to the latch enable terminal and Y1 to data input
>terminal and Y is configured as a transparent latch?

Yes, exactly.  It is a good description both for simulation
and for synthesis.  The problem, of course, is that many
FPGAs do not have good latch primitives (except, maybe, on
their I/O pads) and so you can get very strange hardware
implementations that will cause trouble with static
timing analysis.

Regards
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes:

> Yes, exactly.  It is a good description both for simulation
> and for synthesis.  The problem, of course, is that many
> FPGAs do not have good latch primitives (except, maybe, on
> their I/O pads) and so you can get very strange hardware
> implementations that will cause trouble with static
> timing analysis.

Hi Jonathan,

I noticed whilst delving with FPGA editor into Xilinx devices that
there is a latch option within the flipflop block - have you ever used
them?  Will synth tools map to them do you know?

As an aside - the Virtex-5 version of Microblaze has 3 latches buried
deep inside it...

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html