Is NOT operator allowed in port map?
Paul Uiterlinden
Or in other words: is VHDL code as below legal or illegal (in
87 and 93 VHDL)?
--
ENTITY tb IS
END tb;
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ARCHITECTURE arch OF tb IS
COMPONENT dut
PORT
(
i_p: IN std_logic;
i_n: IN std_logic
);
END COMPONENT;
SIGNAL i: std_logic;
BEGIN
dut_i: dut
PORT MAP
(
i_p => i,
i_n => NOT i -- <== Legal?
);
END arch;
--
Paul Uiterlinden
Lucent Technologies
Ingmar Hohmann
A conversion is allowed but must be implemented as a function all . See
examble below:
--- snip ---
library ieee;
use ieee.std_logic_1164.all;
entity test is
end test;
architecture testarch of test is
component foo
port (
a : in std_ulogic;
b : out std_ulogic);
end component;
function my_not ( constant din : std_ulogic) -- any conversion
function with
return std_ulogic is -- correct return type
and constant input.
begin
return (not din);
end my_not;
signal a_int, b_int : std_ulogic;
begin
foo_instance : foo
port map
( a => my_not(a_int), -- conversion on 'driven side'
of port map
my_not(b) => b_int); -- conversion on 'driven side'
of port map
end testarch;
--- snip ---
Ingmar Hohmann
SEH Computertechnik
Paul Uiterlinden
Okay, I see this is a solution that should work, for all simulators.
Thanks.
But I do not see where it is actually defined in the LRM (87 and 93) that
I cannot use the NOT *operator*. When I follow the syntax for a port map, all
the way down, I reach "factor", which is (amongst others) "not primary":
port_map_aspect ::=
port map ( port_association_list )
association_list ::=
association_element { , association_element }
association_element ::=
[ formal_part => ] actual_part
actual_part ::=
actual_designator
| function_name ( actual_designator )
So here is your "my_not" *function*.
But if I follow the first possibily (actual_designator), then it
seems that I also can use the not *operator*:
actual_designator ::=
expression
| signal_name
| variable_name
| open
expression ::=
relation { and relation }
| relation { or relation }
| relation { xor relation }
| relation [ nand relation ]
| relation [ nor relation ]
relation ::=
simple_expression [ relational_operator simple_expression ]
simple_expression ::=
[ sign ] term { adding_operator term }
term ::=
factor { multiplying_operator factor }
factor ::=
primary [ ** primary ]
| abs primary
| not primary
Any hints?
--
Paul Uiterlinden
Lucent Technologies
Bell Labs Innovations
Botterstraat 45 Tel : +31 35 687 4911
P.O. Box 18 Fax : +31 35 687 5958
1270 AA Huizen Email : uiter...@lucent.com
the Netherlands Room : HV205
rob_di...@my-deja.com
some code for the maxplus2 vhdl tool which worked with the NOT and then
with a later version stopped working. It was a pain in the but to add
another signal to do the inversion. It wasn't in the "new features"
list but someone at altera decided that the not wasn't allowed and
quietly moved the compiler "closer to the spec".
Rob
Sent via Deja.com http://www.deja.com/
Before you buy.
Ingmar Hohmann
> Any hints?
When reading your question I've tried it with "a => NOT(b)", but it didn't work.
When trying it with "my_not()", the first try was
function my_not ( signal din : std_ulogic)
return std_ulogic is
but the compiler advised me to use a constant instead of a signal.
So may be the implementation of NOT() uses a signal or isn't declared for the needed type.
Ingmar Hohmann.
Renaud Pacalet
The function form of not is:
"not"(A)
and not:
not(A)
Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr
me...@mench.com
article <8l6lpt$cuf$1...@nnrp1.deja.com>:
> I would also be interested to hear from an "expert" about this. I
> have some code for the maxplus2 vhdl tool which worked with the NOT
> and then with a later version stopped working. It was a pain in the
> but to add another signal to do the inversion. It wasn't in the
> "new features" list but someone at altera decided that the not
> wasn't allowed and quietly moved the compiler "closer to the spec".
See my previous answer.
I suspect that Alter finally implemented a check that was always
supposed to be there.... More a bug fix than new feature, IMHO....
Paul
--
|"EDA tools are a cruel joke inflicted on electronics designers
Paul Menchini | by computer scientists, and stating that a software-programming
www.mench.com | language can describe hardware is the continuation of the same
| sadistic behavior." -- Gabe Moretti
me...@mench.com
in article <3976F37B...@seh.de>:
> When reading your question I've tried it with "a => NOT(b)", but it
> didn't work. When trying it with "my_not()", the first try was
> function my_not ( signal din : std_ulogic)
> return std_ulogic is
> but the compiler advised me to use a constant instead of a signal.
Interesting--I can't recall (or find) a specific LRM requirement that
the function parameter be of class constant. So I suppose that this
function should work as a conversion function.
> So may be the implementation of NOT() uses a signal or isn't
> declared for the needed type.
The cause is actually a specific LRM restriction. Calling the
provided not on std_ulogic as a function (and not as an expression)
should work.
Ingmar Hohmann
When using a signal for the function parameter the compiler tells me:
"Formal parameter for a type conversion function must be a constant."
When calling NOT as a function within the port map, it also works
(like Renaud Pacalet <pac...@enst.fr> wrote before)
port map(
a => "NOT"(a_int),
"NOT"(b) => b_int);
Bye, Ingmar. (i...@seh.de)
e...@riverside-machines.com.nospam
<uiter...@lucent.com> wrote:
>Okay, I see this is a solution that should work, for all simulators.
>Thanks.
>
>But I do not see where it is actually defined in the LRM (87 and 93) that
>I cannot use the NOT *operator*. When I follow the syntax for a port map, all
>the way down, I reach "factor", which is (amongst others) "not primary":
>
> port_map_aspect ::=
> port map ( port_association_list )
>
> association_list ::=
> association_element { , association_element }
<association list syntax snipped>
>Any hints?
What you're following is the generalised syntax for an association
list for ports, generics, and subprogram calls. There's a further
restriction on ports, which is covered in 1.1.1.2, p7: "the actual, if
an expression, must be a globally static expression". This means that
an actual which is an expression can't contain any signals; signals
don't have a value during elaboration. "not a" is clearly an
expression and, since 'a' is a signal, "not a" isn't globally static,
and can't be used as an actual in a port association list. The problem
with following the syntax summary in appendix A is that it's only
informative - you need to read the text of the LRM to get the full
story. Expressions are only any use in a port association list when
you want to give a constant driving value to a port.
You may be thinking: "but, if "not a" isn't globally static and so
isn't valid, why is "not"(a) or my_not(a) valid?". Good question - a
function call is an expression, and so should be globally static. The
analyser has to check whether you've got a function call in the list,
and whether it's allowable as a "conversion function", before deciding
on whether to apply the globally static rule. This seems to be glossed
over in the LRM (Paul? :)).
Evan