Are all these claims in VHDL correct?

[Weng Tianxiang]

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

 

[Fredxx]

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


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.


M6 and M7 are completely identical in behaviour, yes.


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]

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?

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.

 

[Andy]

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

 

[Weng Tianxiang]

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?".









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).

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








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


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.

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








M6 and M7 are completely identical in behaviour, yes.


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
(e-mail address removed)://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

 

[Martin Thompson]

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

 

[Weng Tianxiang]

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



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
(e-mail address removed)://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