operation on mux output

[valentin tihomirov]

A <= (X when C else Y) xor Z; -- does not work and I have to write

A <= (X xor Z) when C else (Y xor Z);

 

[rickman]

valentin tihomirov wrote:

A <= (X when C else Y) xor Z; -- does not work and I have to write

A <= (X xor Z) when C else (Y xor Z);

How does it not work? Do you get a compile error? Or do you get
unexpected values for A in simulation?

I am guessing that the first statement does not compile. A <= X when C
else Y is a conditional assignment. The right hand side of the
assignment can not be treated like an expression. Depending on how
smart your tools are, the second form may use more logic. You can
always use an intermediate signal 'B' to hold the result of the mux and
then xor B with Z to get A.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Lewis]

valentin,

A <= (X when C else Y) xor Z; -- does not work and I have to write
This does not work because conditional signal

assignment is a statement and not an expression.
However, we are working on an expression with similar
syntax. See FT10A under:
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html

A <= (X xor Z) when C else (Y xor Z);
For an FPGA target that has 4 input luts, this should

be just fine.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[valentin tihomirov]

A <= (X xor Z) when C else (Y xor Z);
For an FPGA target that has 4 input luts, this should
be just fine.

Imagine a 2^n MUX. I don't care about implementation cos synthesier must be
smart enaught to move XORs from inputs to output of the mux. I have written
a function

function MUX2(I0, I1: std_logic_vector; SEL: boolean) return
std_logic_vector;

that allows XORing its output "N <= MUX(A, B, S) xor C" but I think that the
calculation of expressions should be regulated by VHDL synthax. BTW, what is
the recommendation on the type of mux selection signal, what if it is not
True or False (possible when SEL is std_logic)?

However, we are working on an expression with
similar syntax. See FT10A under:

I have looked into the proposal and cannot undestand why do you move away
from "when/else" synthax. Why
"A if Sel, B" is better than just going on using "A if C else B" or "A
when C else B". People have adopted this kind of coding, the proposal will
overcomplicate the synthax (for machines and people). I would just extend
the existing system of conditional assignment. Furthermore, I think that
such contractions (like using comma mark instead of "else" keyword)
contradict to the spirit of <<academic>> languages.

 

[Jim Lewis]

Valentin,

Imagine a 2^n MUX. I don't care about implementation cos synthesier must be
smart enaught to move XORs from inputs to output of the mux. I have written
a function

function MUX2(I0, I1: std_logic_vector; SEL: boolean) return
std_logic_vector;

that allows XORing its output "N <= MUX(A, B, S) xor C" but I think that the
calculation of expressions should be regulated by VHDL synthax. BTW, what is
the recommendation on the type of mux selection signal, what if it is not
True or False (possible when SEL is std_logic)?
Functions work great. I would base all my inputs when possible

on std_logic family types. I like putting SEL first, but at this
point there is not compelling reason to do so.


function MUX2(Sel: std_logic; I0, I1: std_logic_vector)
return std_logic_vector;

function MUX4(
Sel: std_logic_vector(1 downto 0);
I0, I1, I2, I3 : std_logic_vector
) return std_logic_vector;


It is my opinion that it is an oversight that we don't currently
have things like this available in some standard packages. Of
course, we would need people to work on developing the packages ...

However, we are working on an expression with
similar syntax. See FT10A under:


I have looked into the proposal and cannot undestand why do you move away
from "when/else" synthax. Why ... I would just extend
the existing system of conditional assignment.

That would be my preference too, however, it can't be
done in an unambiguous manner without breaking backward
compatibility - which we are not allowed to do.

"A if Sel, B" is better than just going on using "A if C else B" or "A
when C else B". People have adopted this kind of coding, the proposal will
overcomplicate the synthax (for machines and people). Furthermore, I think that
such contractions (like using comma mark instead of "else" keyword)
contradict to the spirit of <<academic>> languages.

We are having this discussion in the working group too.
Some like brief things and wanted "?:". Some like
descriptive. Using "if ," is somewhere between the
two.

Since it can't be when/else, do you think if we changed
the syntax to if/else that people would get confused and
find the two hard to understand which is which?

From a consistency standpoint,
else is consistent with conditional signal assignment
',' is consistent with selected signal assignment

If we can allow the else condition to be left off an nnary
expression, my thought is that nnary expressions will replace
conditional signal assignment.

Having looked at a few things, with the comma, I like it,
but I can also live with else. I just cannot live with "?:".

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[valentin tihomirov]

That would be my preference too, however, it can't be
done in an unambiguous manner without breaking backward
compatibility - which we are not allowed to do.

We are having this discussion in the working group too.
Some like brief things and wanted "?:". Some like
descriptive. Using "if ," is somewhere between the
two.

If we can allow the else condition to be left off an nnary
expression, my thought is that nnary expressions will replace
conditional signal assignment.

I think that things must be kept natural. IMHO, the constructions like "X <=
(A if S else B) xor C" are natural and wonder why they are not supported so
far in year 2004. Apparently, I cannot see so far where the backward
capability is broken. I admit that I'm missing something but IMHO the
conditional "if-else" assignment (both combinatorial and processed) must
grouth into nnary expression.

Since it can't be when/else, do you think if we changed
the syntax to if/else that people would get confused and
find the two hard to understand which is which?

From a consistency standpoint,
else is consistent with conditional signal assignment
',' is consistent with selected signal assignment

Perhaps I'm just not capable to understand, but I do not see the subtle
difference between "if" and "when" (neither vhdl nor in english) and do not
understand why VHDL developers introduced the "when" statement. IMO, it is
just a source of confusion which can be eliminated by using "if"-only
synthax.

Having looked at a few things, with the comma, I like it,
but I can also live with else. I just cannot live with "?:".

As a Java/Delphi programmer I'm not so offensive against ternary operator
but a tradition must be preserved if/when benefit is not obvious. Thus,
IMHO, "if," is not in the game as a completely new creature.