Tristate buffer

T

Tobias Möglich

Guest
Hello

An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
dataDSP is the bus of a DSP controller.
Isn't it possible to create the tristate buffer in the way I quoted at
the bottom of this article ???
It doesn't work.
What's wrong ??

WRITING to BlockRAM
-----------------------------

....
if (cs = '0') then
dinb <= data_DSP;
else
dinb <= (others=>'Z');


Thanks for any help.

Tobias Möglich
 
Tobias Möglich wrote:
An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
Click to expand...
Are you sure that you're allowed to feed 'Z' into the input of a
blockRAM? Why don't you simply have a mux if you have multiple data
sources? If I recall correctly, recent Xilinx devices only have true
tri-state for their IOBs anyway, and this is otherwise really
implemented using muxes (performance issues), so I don't think internal
tri-states are really possible.

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --
 
Tobias Möglich <Tobias.Moeglich@gmx.net> wrote in message news:<400D78FD.DDF392BD@gmx.net>...
Hello

An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
dataDSP is the bus of a DSP controller.
Isn't it possible to create the tristate buffer in the way I quoted at
the bottom of this article ???
It doesn't work.
What's wrong ??

WRITING to BlockRAM
-----------------------------

...
if (cs = '0') then
dinb <= data_DSP;
else
dinb <= (others=>'Z');
Click to expand...
Read the data sheet. Does the target device support internal tristate busses?

-a
 
Tobias, I suggest you step back figure out what you really want to
achieve.
A tristate bus is just one particular method to multiplex data onto
lines. You can do that with a multiplexer, the way most designers do it.
Xilinx used to have real 3-state lines, but we have converted them to
multiplexers, even when the software still "thinks" it is generating
3-state lines.
3-state lines are just a tool to achieve something, and not the best
tool nowadays, when speed counts. Multiplexers achieve the same result,
and are faster and offer better control.

Peter Alfke, Xilinx Applications
==================
Tobias Möglich wrote:
Hello

An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
dataDSP is the bus of a DSP controller.
Isn't it possible to create the tristate buffer in the way I quoted at
the bottom of this article ???
It doesn't work.
What's wrong ??

WRITING to BlockRAM
-----------------------------

...
if (cs = '0') then
dinb <= data_DSP;
else
dinb <= (others=>'Z');

Thanks for any help.

Tobias Möglich
Click to expand...
 
I can't see the coherence between a 3-state-buffer for a bus and a
multiplexer.
What I want to design is following:

The data bus of a microcontroller shall be connected to a true dual port
RAM of the Spartan-IIE.
The dual port RAM (generated by the CoreGenerator) has an input port (dina)
and an output port (douta)
because the data port of the DPRAM is not bidirectional. So I try to put a
3-state buffer between the
data port lines of the controller and the data output port of the DPRAM
(douta).
The pins of the input port of the DPFRAM (dina) can be connected directly
with the data lines of the controller.(??)
I think this should work. Or?
But how to implement it? How is it expressed in VHDL?

What has a 3-state-buufer to do with a multiplexer?
A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
directs it with the output of the mux.
Isn't that the way a multiplexer works?? I thought so.
How can I use a mux instead of a 3-state buffer ??

Greatings, Tobias.
 
I can't see the coherence between a 3-state-buffer for a bus and a
multiplexer.
What I want to design is following:

The data bus of a microcontroller shall be connected to a true dual port
RAM of the Spartan-IIE.
The dual port RAM (generated by the CoreGenerator) has an input port (dina)
and an output port (douta)
because the data port of the DPRAM is not bidirectional. So I try to put a
3-state buffer between the
data port lines of the controller and the data output port of the DPRAM
(douta).
The pins of the input port of the DPFRAM (dina) can be connected directly
with the data lines of the controller.(??)
I think this should work. Or?
But how to implement it? How is it expressed in VHDL?

What has a 3-state-buufer to do with a multiplexer?
A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
directs it with the output of the mux.
Isn't that the way a multiplexer works?? I thought so.
How can I use a mux instead of a 3-state buffer ??

Greatings, Tobias.
 
I can't see the coherence between a 3-state-buffer for a bus and a multiplexer.

What I want to design is following:

The data bus of a microcontroller shall be connected to a true dual port RAM
of the Spartan-IIE.
The dual port RAM (generated by the CoreGenerator) has an input port (dina) and
an output port (douta)
because the data port of the DPRAM is not bidirectional. So I try to put a
3-state buffer between the
data port lines of the controller and the data output port of the DPRAM
(douta).
The pins of the input port of the DPFRAM (dina) can be connected directly with
the data lines of the controller.(??)
I think this should work. Or?
But how to implement it? How is it expressed in VHDL?

What has a 3-state-buufer to do with a multiplexer?
A multiplexer always chooses one out of 4,8, 16 (what ever) lines and directs
it with the output of the mux.
Isn't that the way a multiplexer works?? I thought so.
How can I use a mux instead of a 3-state buffer ??

Greatings, Tobias.
 
Tobias, let me assume that your microcontroller is outside the FPGA, and
has a bidirectional data connection to I/O pins of the FPGA.
Inside the FPGA you now have data input lines coming from the input
buffer, and data output lines going to the output buffer, and a 3-state
control that makes sure you are not driving the outputs while you are
receiving data.
You see that the external 3-state functionality can never be carried
through the I/O into the FPGA. (That is inherently impossible because
the input buffer has amplification, and the output buffer, too. ) Inside
the FPGA you now have two sets of lines, one set is input and the other
one is output. You can then route them to the appropriate pins on the BlockRAM.

3-state drivers are used to send data onto a common output, just by
wiring the drivers together. This assumes that only one of them is
active at any specific time. But if you know which one is active, you
could have ( and you will most of the time) implement this with a multiplexer.

TTL circuits existed for almost 10 years, until NSC invented the
"Tristate" output in the early seventies. I "invented" it a few months
too late :-(
Hope this explains it, otherwise you can contact me directly, even in
German (I got my degree from your neighboring TU in Hannover)

Peter Alfke
===================================


Tobias Moeglich wrote:
I can't see the coherence between a 3-state-buffer for a bus and a
multiplexer.
What I want to design is following:

The data bus of a microcontroller shall be connected to a true dual port
RAM of the Spartan-IIE.
The dual port RAM (generated by the CoreGenerator) has an input port (dina)
and an output port (douta)
because the data port of the DPRAM is not bidirectional. So I try to put a
3-state buffer between the
data port lines of the controller and the data output port of the DPRAM
(douta).
The pins of the input port of the DPFRAM (dina) can be connected directly
with the data lines of the controller.(??)
I think this should work. Or?
But how to implement it? How is it expressed in VHDL?

What has a 3-state-buufer to do with a multiplexer?
A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
directs it with the output of the mux.
Isn't that the way a multiplexer works?? I thought so.
How can I use a mux instead of a 3-state buffer ??

Greatings, Tobias.
Click to expand...
 
dinb <= data_DSP when (CS = '0') else (others => 'Z');

You still express MUX logic in VHDL as you do for tri-state inference.
The synthesis tool automatically maps the tri-states to
muxes in hardware. As peter pointed out, the tri-state hardware
capability doesn't exist in the FPGA's CLB fabric.

Tri-states can be thought of as a fully-decoded muxes. In other
words, the tri-state enable signal selects which of the drivers
has control of the bus. Thus, synthesis tools map the tri-state
enable lines to the select lines for the muxes.

There's a good book, "Essential VHDL - RTL synthesis done right"
by Sundar Rajan that talks about writing VHDL for FPGA fabric. The
author uses synplify as the example synthesis engine. There's a
discussion of hardware creation that talks about the tri-state to
mux mapping performed by synthesis tools.



What has a 3-state-buufer to do with a multiplexer?
A multiplexer always chooses one out of 4,8, 16 (what ever) lines and
directs it with the output of the mux.
Isn't that the way a multiplexer works?? I thought so.
How can I use a mux instead of a 3-state buffer ??

Greatings, Tobias.
Click to expand...

--
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ ` Xilinx hotline@xilinx.com
/ / 2100 Logic Drive http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA
 
Hi,

just to simplify the previous reccomandations, I suggest you
instantiate the primitive IOBUF at the xilinx pins.

Tullio

On Tue, 20 Jan 2004, Tobias Möglich wrote:

Hello

An application question.
I want to design a Tristate buffer for a data bus. dinb is the input
data port of a BlockRAM
dataDSP is the bus of a DSP controller.
Isn't it possible to create the tristate buffer in the way I quoted at
the bottom of this article ???
It doesn't work.
What's wrong ??

WRITING to BlockRAM
-----------------------------

...
if (cs = '0') then
dinb <= data_DSP;
else
dinb <= (others=>'Z');


Thanks for any help.

Tobias Möglich
Click to expand...
--
Tullio Grassi

======================================

Univ. of Maryland-Dept. of Physics |
College Park, MD 20742 - US |
Tel +1 301 405 5970 |
Fax +1 301 699 9195 |
======================================
 
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote:
: Hi,

: just to simplify the previous reccomandations, I suggest you
: instantiate the primitive IOBUF at the xilinx pins.

Instantiate Entities are normally manufacturer dependant. Normal verilog
code has better chances to be manufacturer indpendant.

Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
 
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>...
Hi,

just to simplify the previous reccomandations, I suggest you
instantiate the primitive IOBUF at the xilinx pins.
Click to expand...
1) The original poster wanted to use internal tristates.

2) All of the current synthesis tools infer the right sort of buffers,
so there's no need to hand-instantiate them.

--a
 
The tools are horrible at placing the internal tristates. Putting LOCs on them within the code is one *very* good reason to
instantiate them.

Andy Peters wrote:

Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>...
Hi,

just to simplify the previous reccomandations, I suggest you
instantiate the primitive IOBUF at the xilinx pins.

1) The original poster wanted to use internal tristates.

2) All of the current synthesis tools infer the right sort of buffers,
so there's no need to hand-instantiate them.

--a
Click to expand...
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top