VHDL (others => '1') construct

[Erik de Castro Lopo]

Hi all,

I'm in the process of evaluating two different VHDL
packages. The first package, Orcad Express, allowed me
to do something like :

signal mysig : unsigned (7 downto 0);

and then within a process do :

if mysig = (others => '1') then ....

The second package, from Aldec, does not allow this
construct.

What I'd like is some feedback as to whether this
construct is allowed in other VHDL simulators/synthesis
engines. I'd also like to know if there is some document
which outlines which VHDL language features should be
avoided for crossplatform portability reasons.

Thanks in advance,
Erik

[Moonwook,Oh]

Synopsys' tools such as VHDL System Simulator(VSS) and Design Compiler
support that construct. I don't know about teh guidelines.

[Bert Molenkamp]

"Erik de Castro Lopo" <e.de....@fairlightesp.com.au> writes:
> Hi all,
>
> I'm in the process of evaluating two different VHDL
> packages. The first package, Orcad Express, allowed me
> to do something like :
>
> signal mysig : unsigned (7 downto 0);
>
> and then within a process do :
>
> if mysig = (others => '1') then ....
>
> The second package, from Aldec, does not allow this
> construct.
>
> What I'd like is some feedback as to whether this
> construct is allowed in other VHDL simulators/synthesis
> engines. I'd also like to know if there is some document
> which outlines which VHDL language features should be
> avoided for crossplatform portability reasons.

mysig = (OTHERS => 1)
I think I know what your intention is. The right operator should have the
same length as the left operator and all postions should be '1'. But how
should the langauge know about that?

A correct solution is:
mysig = (mysig'RANGE => '1');

At least I think that is you want.

Regards,

Egbert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE Enschede
the Netherlands
email: mole...@cs.utwente.nl

[Andreas Gieriet]

Erik de Castro Lopo wrote:
>

> Hi all,
>
> I'm in the process of evaluating two different VHDL
> packages. The first package, Orcad Express, allowed me
> to do something like :
>
> signal mysig : unsigned (7 downto 0);
>
> and then within a process do :
>
> if mysig = (others => '1') then ....
>
> The second package, from Aldec, does not allow this
> construct.
>
> What I'd like is some feedback as to whether this
> construct is allowed in other VHDL simulators/synthesis
> engines. I'd also like to know if there is some document
> which outlines which VHDL language features should be
> avoided for crossplatform portability reasons.
>

> Thanks in advance,
> Erik

Try this:

constant mysig_all_one : unsigned(mysig'range) := (others => '1');
...
if mysig = mysig_all_one then
...

This code is portable.

Explanation:
Unfortunately, most of the simulators have their own way to implement
unsigned/signed logic. This implies, that there are differences in
what operators and conversions are available. If one package defines
an additional "=" operator for comparing unsigned with std_logic_vector
or bit_vector, the construct

if mysig = (others => '1') then

is ambiguous. I.e., the VHDL simulator (correctly) does not accept
this construct in this context.

The simulator will accept this construct as soon as there is only one
"=" operator that matches.
How to achieve this?
A) by only providing one "=" operator (usually not possible, because
the packages are used as they are)
B) by removing the ambiguity (make sure, that the type of both
arguments are known to the "=" operator)

--
Andreas Gieriet

(Please replace "nospam" by "pobox" in the return address,
which has been altered to foil junk mail senders)

[Paul Uiterlinden]

Bert Molenkamp wrote:

> mysig = (OTHERS => 1)
> I think I know what your intention is. The right operator should have the
> same length as the left operator and all postions should be '1'. But how
> should the langauge know about that?

Nice explanation, which immediately triggers the next observation: in an
assignment, it _is_ allowed to use OTHERS (except when the target is
unconstrained). If the compiler derives the correct length in an assignment,
why not in a boolean_expression?

--
Paul Uiterlinden

Lucent Technologies
Bell Labs Innovations

Botterstraat 45 Tel : +31 35 687 4911
P.O. Box 18 Fax : +31 35 687 5964
1270 AA Huizen Email : uiter...@lucent.com
the Netherlands

[Martin Radetzki]

Paul Uiterlinden wrote:
>
> Bert Molenkamp wrote:
>
> > mysig = (OTHERS => 1)
> > I think I know what your intention is. The right operator should have the
> > same length as the left operator and all postions should be '1'. But how
> > should the langauge know about that?
>
> Nice explanation, which immediately triggers the next observation: in an
> assignment, it _is_ allowed to use OTHERS (except when the target is
> unconstrained). If the compiler derives the correct length in an assignment,
> why not in a boolean_expression?

Because the assignment operator is defined by the LRM and only by the
LRM. It cannot be overloaded by some package or so. The "=" operator,
on the other hand, is implicitly declared by the language but can be
overloaded or hidden by an explicit declaration. This means that the
VHDL compiler can use some built-in knowledge that the right-hand side
of the array assignment mysig <= (OTHERS => '1') must have the same
number of elements as the left-hand side, and derive the range that
is represented by OTHERS. But in the expression mysig = (OTHERS => '1')
the "=" operator might be defined in a way that it can compare arrays
of different lengths.

________________________________________________________________________
Martin Radetzki Tel.: **49-441-798-2988
OFFIS Research Institute Fax.: **49-441-798-2145
Escherweg 2 http://eis.informatik.uni-oldenburg.de/~martin
26121 Oldenburg, Germany e-mail: rade...@offis.uni-oldenburg.de

[Bob Flatt]

> > mysig = (OTHERS => 1)
> > I think I know what your intention is. The right operator should have the
> > same length as the left operator and all postions should be '1'. But how
> > should the langauge know about that?
>
> Nice explanation, which immediately triggers the next observation: in an
> assignment, it _is_ allowed to use OTHERS (except when the target is
> unconstrained). If the compiler derives the correct length in an assignment,
> why not in a boolean_expression?

Because two arrays are only equal if they have the same element values and length. A compare of arrays different lengths returns false. In this case the compare doesn't know the length of the aggregate so you get an error message. (Yes it would be possible
to extent the language to detect this special case, such a change should be made through the IEEE standards process. Unilateral implementation by the tool vendor may result in non portable application code)