Bidirectional Data Buses in VHDL
Stephen Molloy
ported SRAM. A greatly simplified version of the model is
given at the bottom of this post. I have another device that
is hanging off the data bus (with a tristate driver in
between). This other device generates valid outputs when it
is not connected to the bus, but with the single ported SRAM
in write mode (OEB=1 and WEB=0) the bus is always undefined.
There is nothing else hanging off the bus that could be
trying to drive it to a conflicting state. Any help would be
appreciated.
Thanks
Steve
P.S. all the putline statements in the VHDL file are for my
own debugging purposes
-- Single Ported 128Kx8 SRAM
-- Chip Enables CE1B (active low), CE2 (active high)
-- Write Enable WEB (active low)
-- Output Enable OEB (active low)
-- Address A[16:0] (address bus)
-- Data DQ[7:0] (bidirectional data bus)
entity testsram is
port (signal CE1B : in vlbit;
signal CE2 : in vlbit;
signal WEB : in vlbit;
signal OEB : in vlbit;
signal A : in vlbit_1d(16 downto 0);
signal DQ : inout vlbit_1d(7 downto 0));
end testsram;
architecture behavior of testsram is
begin
testsram_process: process(CE1B,CE2,WEB,OEB,A,DQ)
type rammemory is array(0 to 131071) of vlbit_1d(7 downto 0);
variable ram: rammemory;
begin
if ((CE1B='0') AND (CE2='1')) then
putline("Chip Enabled OK...");
if ((WEB='1') AND (OEB='0')) then
putline("===> Read Operation");
DQ <= ram(v1d2int(A)) after 45 NS;
elsif ((WEB='0') AND (OEB='1')) then
putline("===> Write Operation");
ram(v1d2int(A)):=DQ;
elsif ((WEB='0') AND (OEB='0')) then
putline("*** ERROR - READ AND WRITE");
else putline("... No Operation");
end if;
else
putline("... Chip Not Enabled");
end if;
end process;
end behavior;
Bert Molenkamp
+------------+ +-------------+
| +<- en1 en2 ->+ |
| | databus | |
| device 1 +------<->--------+ device 2 |
| | | |
| | | |
+------------+ +-------------+
Assume you have two devices coupled with a bidirectional
bus than only at most one device may be active. The other
devices should be in tri-state. I think, the latter is
probably forgotten. You have to write an explicit statement
that a device goes to tri-state.
Now we come to the type VLBIT. VLBIT has a resolution function
(see the package 'pack1076.vhd' for the VIEWLOGIC user's). In
this resolution function 'Z' is used to indicate the tri-state.
device_1: PROCESS(en1,databus)
BEGIN
IF en1='1'
THEN databus <='0'
ELSE databus <='Z' ;
END IF;
END PROCESS device_1;
device_2: PROCESS(en2,databus)
BEGIN
IF en2='1'
THEN databus <='1'
ELSE databus <='Z' ;
END IF;
END PROCESS device_2;
* In this example if both enable signals (EN1, EN2) are NOT equal to
'1' the databus is 'Z'. (due to the resolution function)
* If exactly one enable signal is '1', then the databus will
get the value '0' or '1' (depending on which enable signal is '1').
(In fact the resolution function (coupled with the type vlbit) is
called with a '0' (or '1') and 'Z', and the resolved value is
'0' (or '1'), as expected).
* If both enable signals are '1', we have a conflict (like real hardware)
The databus is driven with a '1' AND a '0'. The resolution function
will produce an 'X'.
I think the latter is the case in your description. You have to assign
a 'Z'.
I often get the following question related to the same problem "If
device 1 assigns a '1' to the databus, and LATER (in time) device 2
assigns a '0' does that not overrule the previous assignment of device 1?"
The answer is NO! Device_1 will 'continuously' drive the value '1' until
THAT device assigns a new value to the databus (like 'Z').
I hope this solves your problem.
Egbert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE Enschede
the Netherlands
email: mole...@cs.utwente.nl
Paul J Menchini -- Menchini and Associates
Stephen Molloy <mol...@bigbear.janet.ucla.edu> wrote:
>Hi, I'm having trouble using Viewlogic VHDL to model a single
>ported SRAM. A greatly simplified version of the model is
>given at the bottom of this post.
>
If you've ever done a read when you get here, you're still driving a value
on DQ and will only read Xs off of this bus. So, if your RAM can go directly
from a read to a write, you need to model disconnection here by driving Zs
onto DQ and waiting for them to become effective prior to reading DQ.
> putline("===> Write Operation");
> ram(v1d2int(A)):=DQ;
> elsif ((WEB='0') AND (OEB='0')) then
> putline("*** ERROR - READ AND WRITE");
> else putline("... No Operation");
> end if;
> else
> putline("... Chip Not Enabled");
Here you need to disconnect DQ by driving Zs.
> end if;
> end process;
>end behavior;
In VHDL, once a process drives a signal, it does not stop driving merely
because the process reactivates. You must explicitly disconnect from the
signal, usually by driving Zs onto it. (This works only if the signal is
resolved and the resolution function knows to ignore Zs.)
Hope this helps.
--Paul
--
Paul Menchini Menchini & Associates "Any clod can have the
2 Davis Drive email: me...@rock.concert.net facts, but having an
P.O. Box 13036 voice: 919-990-9506 opinion is an art!"
RTP, NC 27709-3036 fax: 919-990-9507 -- Charles McCabe
Michael T.Y. McNamara
mole...@cs.utwente.nl (Bert Molenkamp) writes:
| Assume you have two devices coupled with a bidirectional
| bus than only at most one device may be active. The other
| devices should be in tri-state. I think, the latter is
| probably forgotten.
|
| ...
|
| I often get the following question related to the same problem "If
| device 1 assigns a '1' to the databus, and LATER (in time) device 2
| assigns a '0' does that not overrule the previous assignment of device 1?"
| The answer is NO! Device_1 will 'continuously' drive the value '1' until
| THAT device assigns a new value to the databus (like 'Z').
|
| I hope this solves your problem.
This understanding was so much more easily instilled in
designers when they prototyped their design on a breadboard. Then,
such a event (one transister driving 1, another 0), would result
in a lot of heat, and eventually a strong ozone smell, and a fried
component.
Having your HDL display an X for the bus value, offers the
same lesson in a much less statisfingly, much more undramatic
manner. (saves money in fewer burned up components, though... :-)
-mac
--
,------. Michael McNamara Send mail to in...@chronologic.com for INFO
|CHRONO|LOGIC SIMULATION to sup...@chronologic.com for SUPPORT
`------' See our AD in EE Times! For information, call 1-800-VERILOG