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

Weng Tianxiang

"Jonathan Bromley" <> wrote in message
news:...
>>
>>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?

Fredxx

"Jonathan Bromley" <> wrote in message
news:...
> 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.

Fredxx

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 & M 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

Andy

On May 21, 12:40*am, 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. *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.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 quoted 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 = '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.

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 = '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?

Thank you.

Weng

Weng Tianxiang

Jonathan Bromley <> 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

--

TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson

On May 21, 9:44*am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> 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.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.

Hi Jonathan,
Thank you for your answer.

Have you received my email?

Weng

Weng Tianxiang