port initial value
JohnSmith
Is some difference between port and signal initial value?
--- example file---------------------------
library ieee;
use ieee.std_logic_1164.all;
entity test is port(
a: IN std_logic := 'X'
);
end test;
architecture arch of test is
signal a1: std_logic := '1';
signal b: std_logic;
begin
b <= a;
end arch;
-- tb
library ieee;
use ieee.std_logic_1164.all;
entity test_tb is
end test_tb;
architecture TB_ARCHITECTURE of test_tb is
component test
port(
a : in std_logic );
end component;
signal a : std_logic;
begin
UUT : test
port map (
a => a
);
process
begin
a <= '0';
wait;
end process;
end TB_ARCHITECTURE;
------------------------------
--- result from modelsim ---------------------------
@0 +0
/test_tb/a U
/test_tb/uut/a U
/test_tb/uut/a1 1
/test_tb/uut/b U
@0 +1
/test_tb/a 0
/test_tb/uut/a 0
@0 +2
/test_tb/uut/b 0
------------------------------
---- script file --------------------------
vsim -t fs -novopt work.test_tb
add wave sim:/test_tb/*
add list -r sim:/test_tb/*
run 1 us
write list -events test1.lst
------------------------------
I would expect a = 'X' at "0 +0"
Thanks
Jonathan Bromley
>Is some difference between port and signal initial value?
The := syntax on a port is not initialization.
It's the default value if the port is left
unconnected.
>entity test is
> port(a: IN std_logic := 'X');
>end test;
>
>architecture arch of test is
> signal a1: std_logic := '1';
> signal b: std_logic;
>begin
> b <= a;
>end arch;
OK, so we would expect 'b' to follow 'a' after
one delta cycle. 'a' will be stuck at X if it
is left unconnected, but that is not what you did...
>architecture TB_ARCHITECTURE of test_tb is
> signal a : std_logic;
>begin
> UUT : test port map (a => a);
> process begin
> a <= '0';
> wait;
> end process;
OK. So...
- signal test_tb/a starts life at 'U';
- your process will drive it to '0' at 0ns+0.
But, furthermore, signal test_tb/a is connected to
test_tb/uut/a. Consequently THESE TWO SIGNALS ARE
MERGED and form one and the same signal. In VHDL,
signals are merged (or "collapsed" in Verilog-speak)
across a port boundary. The default value 'X' on
input uut/a is completely ignored, because you have
connected something to the input.
[Note to keep the pedants and other mischief-mongers
happy: the exception to this is in VHDL-2008 where
an expression can be connected to an input port;
the expression ain't a signal, and there is an
implicit concurrent signal assignment across the
port boundary. That introduces a delta delay.]
>--- result from modelsim ---------------------------
>@0 +0
>/test_tb/a U
>/test_tb/uut/a U
[JB] This MUST be the same as /test_tb/a because they
are in fact exactly the same signal, thanks to the
port connection.
>/test_tb/uut/a1 1
[JB] Sure, because you initialized that signal.
>/test_tb/uut/b U
[JB] Of course.
>@0 +1
[JB] Your process has now executed as far as the 'wait'...
>/test_tb/a 0
[JB] and after one delta the update propagates to /test_tb/a...
>/test_tb/uut/a 0
[JB] and therefore to /test_tb/uut/a also. That triggers
the concurrent signal assignment, which executes and therefore
updates /test_tb/uut/b one delta cycle later...
>@0 +2
>/test_tb/uut/b 0
[JB] and there's the resulting update.
>------------------------------
That's good; it spares us the trouble of sending
Mentor a bug report, since that's exactly the
right behaviour :-)
>I would expect a = 'X' at "0 +0"
No. The 'X' is a default, used ONLY if the port
is left unconnected. If a signal is connected,
the default has no effect.
--
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...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
JohnSmith
wrote:
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
This is only for input ports? I tested some design and it seems the
initial value is applied on output ports at "0 +0".
Jonathan Bromley
>This is only for input ports? I tested some design and it seems the
>initial value is applied on output ports at "0 +0".
Ah, yes. Sorry, this is a corner of the language that
I never usually visit (initialization on output ports).
What I *should* have mentioned in my earlier post is that
the default on an input port is, in truth, an initialization
but it takes effect only if the port is unconnected. That's
a very useful thing to do, because it gives you an optional
input port. By contrast, initialization on an *output* port
is just that - an initialization - and it takes precedence
over the initialization of any signal connected to that
port on the outside of your entity. I guess this makes
perfect sense when you think about it. An initial value
is applied to the signal itself, and to any driving
processes in the same scope - but driving processes in
another scope (something the other side of a port
connection) may have their own initializations.
--
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...@MYCOMPANY.com
JohnSmith
wrote:
> On Sun, 27 Sep 2009 09:44:00 -0700 (PDT), JohnSmith wrote:
> >This is only for input ports? I tested some design and it seems the
> >initial value is applied on output ports at "0 +0".
>
> Ah, yes. Sorry, this is a corner of the language that
> I never usually visit (initialization on output ports).
>
> What I *should* have mentioned in my earlier post is that
> the default on an input port is, in truth, an initialization
> but it takes effect only if the port is unconnected. That's
> a very useful thing to do, because it gives you an optional
> input port. By contrast, initialization on an *output* port
> is just that - an initialization - and it takes precedence
> over the initialization of any signal connected to that
> port on the outside of your entity. I guess this makes
> perfect sense when you think about it. An initial value
> is applied to the signal itself, and to any driving
> processes in the same scope - but driving processes in
> another scope (something the other side of a port
> connection) may have their own initializations.
> --
> 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
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
It seems ports/signals keeps its initial values, when they aren't
driven.
For example GSR, GTS in Xilinx VCOMPONENTS has an initial value, but
in "0 +0" is 'U', because X_TOC drives it (probably).
Jonathan Bromley
>It seems ports/signals keeps its initial values, when they aren't
>driven.
If there is no process driving a signal, yes, it keeps its
initial value. Initialization on a signal causes initialization
of the signal itself, and also of the drivers in all processes
that drive that signal.
>For example GSR, GTS in Xilinx VCOMPONENTS has an initial value, but
>in "0 +0" is 'U', because X_TOC drives it (probably).
Yes, but that's because there is a connection across a port
boundary, surely? Sorry, I'm not quite sure I understand
what you are saying/asking. Just to emphasise once again:
the initial value specified on an input port has NO EFFECT
if you wire-up that input port to an external signal.
--
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...@MYCOMPANY.com