«

Everyone,

I've got a 'black box' component which has in, out and inout ports.
This component is an existing design of a chip which cannot (should
not) be modified. The VHDL model of this chip does not include any
delays (in simulations all signals change immediately after the clock
edge).

For system-level simulations, I am building a wrapping entity around
this 'black box' chip in which I model the delays on the output
signals.

This goes as follows:

* input signals are assigned directly:
input_signal_internal <= input_signal_external;

* for output signals the real chip's delay is added:
output_signal_external <= output_signal_internal after <whatever> ns;

But what do I do for bidirectional signals ? Does a similar setup like
for output signals work? Note that I do not have a simple handshake
signal which tells me whether the bidirectional line is an input or an
output at any specific time, but if needed I can probably infer the
direction by decoding a bunch of external signals.

Any suggestions? Is this possible without a direction signal?

greetings,
Tom

Tom wrote:

> I've got a 'black box' component which has in, out and inout ports.
> This component is an existing design of a chip which cannot (should
> not) be modified. The VHDL model of this chip does not include any
> delays (in simulations all signals change immediately after the clock
> edge).
>
> For system-level simulations, I am building a wrapping entity around
> this 'black box' chip in which I model the delays on the output
> signals.

What about just synthesizing the "black box-component"? Then you get
reliable delay estimations without manual interference.

Ok - the simulation time simulationg with the synthesized netlist and
maybe additionally an sdf-file will be slower than behvioral simulation.
Is this the reason, why you do not want to go this way?


One way, if you really have to model the delays is to split a
bidirectional bus into two busses for each direction. Then you may
insert delay elements for simulation for each bus. After all you may
merge the two busses.


One more question: Why do you have bidirectional busses for
on-chip-communication? Would't it be better to model this with two
busses - one for each direction and use bidirectional busses only for
pin I/O?

Ralf

Ralf,

> What about just synthesizing the "black box-component"? Then you get
> reliable delay estimations without manual interference.

That's been done (the chip has been produced as well). That will be the
source of the delay information.

> Ok - the simulation time simulationg with the synthesized netlist and
> maybe additionally an sdf-file will be slower than behvioral simulation.
> Is this the reason, why you do not want to go this way?

That's one of the reasons. Other reasons have to do with intellectual
property rights, contractual obligations, etc.

> One way, if you really have to model the delays is to split a
> bidirectional bus into two busses for each direction. Then you may
> insert delay elements for simulation for each bus. After all you may
> merge the two busses.

Like I said I cannot change anything about the 'black box' component.
This has bidirectional buses on its pin I/O's.

> One more question: Why do you have bidirectional busses for
> on-chip-communication? Would't it be better to model this with two
> busses - one for each direction and use bidirectional busses only for
> pin I/O?

This IS pin I/O. The model I am constructing is for system-level
simulations. Inside the chip the buses are split of course, but the
model won't have access to the chip's innards.

I think I may have found a solution in Ben Cohen's ZeroOhm component
(not yet tested), which I found on
http://groups.google.be/group/comp.l...14832588a0cabb

-- bidirectional signal assignments with delays
DBUS_link: for i in DBUS_ext'range generate
DBUSi_link: ZeroOhm
generic map (a_to_b_loss => 0 ns, b_to_a_loss => 1.234 ns)
port map (A => DBUS_ext(i), B => DBUS_int(i));
end generate;

greetings,
Tom

> I think I may have found a solution in Ben Cohen's ZeroOhm component
> (not yet tested), which I found on
> http://groups.google.be/group/comp.l...14832588a0cabb
>
> -- bidirectional signal assignments with delays
> DBUS_link: for i in DBUS_ext'range generate
> DBUSi_link: ZeroOhm
> generic map (a_to_b_loss => 0 ns, b_to_a_loss => 1.234 ns)
> port map (A => DBUS_ext(i), B => DBUS_int(i));
> end generate;

Actually the ZeroOhm component does not give good results. However, I
modified the WireDelay component I found at Mr. Cohen's website into a
version with two different delays, and now it does what I want:

----------------------------------------------------------------------------
-- Copyright (c) 2001, Ben Cohen. All rights reserved.
-- Author of following books
-- * Component Design by Example ... a Step-by-Step Process Using
-- VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
-- * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
0-7923-8474-1
-- * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
0-7923-8115
--
-- This source file for the WIRE model with delay may be used and
-- distributed without restriction provided that this copyright
-- statement is not removed from the file and that any derivative work
-- contains this copyright notice.

-- File name : wiredly.vhd
-- Description: This package, entity, and architecture provide
-- the definition of a zero ohm component (A, B).
--
-- The applications of this component include:
-- . Normal operation of a jumper wire (data flowing in both
directions)
--
-- The component consists of 2 ports:
-- . Port A: One side of the pass-through switch
-- . Port B: The other side of the pass-through switch

-- The model is sensitive to transactions on all ports. Once a
-- transaction is detected, all other transactions are ignored
-- for that simulation time (i.e. further transactions in that
-- delta time are ignored).
--
-- Model Limitations and Restrictions:
-- Signals asserted on the ports of the error injector should not
have
-- transactions occuring in multiple delta times because the model
-- is sensitive to transactions on port A, B ONLY ONCE during
-- a simulation time. Thus, once fired, a process will
-- not refire if there are multiple transactions occuring in delta
times.
-- This condition may occur in gate level simulations with
-- ZERO delays because transactions may occur in multiple delta
times.
--
--
--
--================================================== ===============
-- Revisions:
-- Date Author Revision Comment
-- 2/28/01 Ben Cohen Rev A Creation
--
-- 8/03/05 Tom Torfs Rev B Extended to allow different delays in
both directions
-------------------------------------------------------------
library IEEE;
use IEEE.Std_Logic_1164.all;

entity WireDelay2 is
generic (Delay_A_to_B, Delay_B_to_A: time);
port
(A : inout Std_Logic;
B : inout Std_Logic
);
end WireDelay2;


architecture WireDelay2_a of WireDelay2 is
begin
ABC0_Lbl: process
variable ThenTime_v : time;
begin
wait on A'transaction, B'transaction
until ThenTime_v /= now;
-- Break
if A'active then
wait for Delay_A_to_B; -- wire delay
else
wait for Delay_B_to_A;
end if;
ThenTime_v := now;
A <= 'Z';
B <= 'Z';
wait for 0 ns;

-- Make
A <= B;
B <= A;
end process ABC0_Lbl;
end WireDelay2_a;

greetings,
Tom

Tom wrote:

>>One way, if you really have to model the delays is to split a
>>bidirectional bus into two busses for each direction. Then you may
>>insert delay elements for simulation for each bus. After all you may
>>merge the two busses.
>
>
> Like I said I cannot change anything about the 'black box' component.
> This has bidirectional buses on its pin I/O's.

Well, I was talking about splitting the I/O signal outisde the black box.

------- --delay-->--
black |__| |___ I/O
box | | |
------- --delay--<--

But now, if I think about it, I guess its impossible to do it this way,
because this would result in a loop over the two delay elements.


> I think I may have found a solution in Ben Cohen's ZeroOhm component
> (not yet tested), which I found on
> http://groups.google.be/group/comp.l...14832588a0cabb

I guess, Ben had the same problem as mentioned above and this will be a
suitable solution.


Ralf