Tristate buffer

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

Reply to
Tobias Möglich
Loading thread data ...

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 --
Reply to
PO Laprise

Read the data sheet. Does the target device support internal tristate busses?

-a

Reply to
Andy Peters

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 l>
Reply to
Peter Alfke

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.

Reply to
Tobias Moeglich

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.

Reply to
Tobias Möglich

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.

Reply to
Tobias Möglich

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:

Reply to
Peter Alfke

dinb '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.

--
/ 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
Reply to
Paulo Dutra

Hi,

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

Tullio

--
Tullio Grassi

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

Univ. of Maryland-Dept. of Physics   |
College Park, MD 20742 - US          |
Tel +1 301 405 5970                  |
Fax +1 301 699 9195                  |
======================================
Reply to
Tullio Grassi

Tullio Grassi 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 ----------
Reply to
Uwe Bonnes

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.
Reply to
Andy Peters

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.