Top level output keeps showing undefined XXX in simulation

Hi there,

I hope someone on this group can explain the reason for what I'm
seeing, for me it does not make any sense...

I have an output port that is defined like this, (other ports and
signals left out for simplicity sake):

entity darv_leaf_node is
Port( s_response : out response_bus );

where response bus is a record defined like this:

type response_control is
record
valid : std_logic;
status : status_type;
end record;

type response_bus is
record
data : std_logic_vector(31 downto 0);
control : response_control;
end record;

In the architecture of darv_leaf node I declare an internal/
intermediate signal as follows:

signal s_response_internal : response_bus;

and I have a process assigning different values to
s_response_internal. All I want to do is assign the output port,
s_response to the signal. This worked fine until I made some changes
to the design which are as far as I can see totally unrelated to this
output port. The process is shown below:

process (clk, rst_n)
begin
if (clk'event and clk = '1') then
if (rst_n = '0') then
s_response.data <= (others => '0');
s_response.control.valid <= '0';
s_response.control.status <= startup;
else
s_response <= s_response_internal;
end if;
end if;
end process;

The s_response simulation shows that only the .control.status bits
change correctly, the other bits (.data and .control.valid) are
staying X's for the complete duration of the simulation. Thus, it is
not even initialized properly during reset. s_response_internal's bits
are correct in simulation.

I'm doing a ModelSim PE simulation and there are lots of other places
where the same bus types work fine, thus the package inclusion is not
the problem.

Any ideas would be much appreciated, that's if I haven't gone grazy
before getting any responses .

Thanks,
Jaco

Jaco Naude

On 26 Nov, 07:52, Jaco Naude <naude.j...@gmail.com> wrote:
> Hi there,
>
> I hope someone on this group can explain the reason for what I'm
> seeing, for me it does not make any sense...
>
> I have an output port that is defined like this, (other ports and
> signals left out for simplicity sake):
>
> entity darv_leaf_node is
> * *Port( s_response *: out response_bus );
>
> where response bus is a record defined like this:
>
> * * * * type response_control is
> * * * * *record
> * * * * * * * * * valid * * * * : std_logic;
> * * * * * * * * * status * * * * * * * *: status_type;
> * * * * *end record;
>
> * * * * type response_bus is
> * * * * *record
> * * * * * * * * * data * * * * * * * * *: std_logic_vector(31 downto 0);
> * * * * * * * * * control * * * * : response_control;
> * * * * *end record;
>
> In the architecture of darv_leaf node I declare an internal/
> intermediate signal as follows:
>
> signal s_response_internal * * * * * * * * * * * * * * * * * * *: response_bus;
>
> and I have a process assigning different values to
> s_response_internal. All I want to do is assign the output port,
> s_response to the signal. This worked fine until I made some changes
> to the design which are as far as I can see totally unrelated to this
> output port. The process is shown below:
>
> process (clk, rst_n)
> begin
> * * * * if (clk'event and clk = '1') then
> * * * * * * * * if (rst_n = '0') then
> * * * * * * * * * * * * s_response.data <= (others => '0');
> * * * * * * * * * * * * s_response.control.valid <= '0';
> * * * * * * * * * * * * s_response.control.status <= startup;
> * * * * * * * * else
> * * * * * * * * * * * * s_response <= s_response_internal;
> * * * * * * * * end if;
> * * * * end if;
> end process;
>
> The s_response simulation shows that only the .control.status bits
> change correctly, the other bits (.data and .control.valid) are
> staying X's for the complete duration of the simulation. Thus, it is
> not even initialized properly during reset. s_response_internal's bits
> are correct in simulation.
>
> I'm doing a ModelSim PE simulation and there are lots of other places
> where the same bus types work fine, thus the package inclusion is not
> the problem.
>
> Any ideas would be much appreciated, that's if I haven't gone grazy
> before getting any responses .
>
> Thanks,
> Jaco

'X's show that you are driving the same signal from two different
sources. Normally the fix for this is to either declare the signals
(status and valid) as std_ulogic so they are picked up in the
compiler, or just search through your code for a second assignment.
Like you said, it worked fine until you made some changes.

I notice you have put the rst_n in the sensitivity list, but you've
made it a synchronous reset. Were you expecting for an asynch reset
behaviour (hence your not getting a proper reset)?

Another point to note: Synthesisors tend not to like anything other
than std_(u)logic(_vector) for the top level ports. If this isnt
intended as the top (ie pin) level, then there should be no problem.

Tricky

>
> Another point to note: Synthesisors tend not to like anything other
> than std_(u)logic(_vector) for the top level ports. If this isnt
> intended as the top (ie pin) level, then there should be no problem.

Actually, I kind of lie. Its not that it doesnt like them, its just
constraining an enumerated type is impossible.

Tricky

On Nov 26, 11:14*am, Tricky <Trickyh...@gmail.com> wrote:
> > Another point to note: Synthesisors tend not to like anything other
> > than std_(u)logic(_vector) for the top level ports. If this isnt
> > intended as the top (ie pin) level, then there should be no problem.
>
> Actually, I kind of lie. Its not that it doesnt like them, its just
> constraining an enumerated type is impossible.

Thanks for the response. It is indeed multiple drives, don't know how
I didn't pick it up after staring at the code. Well, it works now,
thanks.

My title was not entirely correct, this block is the top level of this
part of the design but the there is a top level higher up in the
hierarchy with proper inputs and outputs. Thanks for the input in any
way.

In regard with the reset, I can just as well take it out, since the
reset should be synchronous all the time. I think I put it in there
while trying to get the X's away.

Thanks again for the help,
All the best.
Jaco

Jaco Naude

Jaco Naude submitted:

|---------------------------------------------------------------------|
|"[..] |


| |


|Thanks for the response. It is indeed multiple drives, don't know how|


|I didn't pick it up after staring at the code. Well, it works now, |


|thanks. |


| |


|[..]" |
|---------------------------------------------------------------------|

I have been trying unsuccessfully to convince someone to use
std_ulogic and std_ulogic_vector instead of std_logic and
std_logic_vector. I mentioned
WWW.VHDL.org/comp.lang.vhdl/FAQ1.html#std_ulogic
to him and he conceded that simulations could be better with
std_ulogic and std_ulogic_vector but any time this was investigated to
cause a bug for us the bug was not or the bugs were not caused by using
resolved logic instead of unresolved logic.

Reasons he gave for staying with resolved logic is that synthesizers
would reject multiple drivers and third parties support resolved logic
instead of unresolved logic.

It is not important enough to persist at him, but could anyone advise
me as to how I could be more persuasive?

With kind regards,
Colin Paul Gloster

Paul Cole Gloster

Paul Cole Gloster wrote:

> It is not important enough to persist at him, but could anyone advise
> me as to how I could be more persuasive?

Unsolicited advice is rarely used, persuasive or otherwise.
If I am a paying customer, I can insist, but this
would likely cost me more time than fixing up the
types myself.

-- Mike Treseler

Mike Treseler