internal tristates and busses

Hello all,

I'm curious to hear some comments on the following idea. I had a bus interface (total of 9, 16 bit wide registers) that I had originally designed a large bus multiplexer for. The select lines were coded into a 9 bit vector "000000001" when the first register was addressed, "000000010" when the second register was addressed, and so on, all controlled via address lines, chip selects, and read strobes. This seemed to produce a fair amount of logic, and slower speeds so I thought of using the 9 bit select vector to control internal tristates i.e. :

data

Reply to
Jason Berringer
Loading thread data ...

I'm not certain about the Xilinx parts, but in many FPGA's there is no tri-state capability in internal logic (onl;y in the IO blocks). So, whilst the synthesis should make your idea work, it will in truth create something similar to the MUX

Reply to
Gary Pace

designed

vector

design a bus(mux) to use internal tristate (TBUFs') can reduce the logic by significant amount, but for the new(current) technologies (S3/V4) TBUFs are no longer available so you end up using logic resources resources if targetting new families.

for S2/E there internal tristate (TBUF) based mux saves logic

antti

Reply to
Antti Lukats

It is a good way when you have tristates and I have used it many times. However not many people used this technique and Xilinx have reduced and totally phased out internal tristates in their later families for this reason and others. For Spartan-II though it is a very good way to save CLB resources but don't expect the same results for Spartan-3 etc.

John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board.

formatting link

designed

vector

lines,

appreciated.

Reply to
John Adair

Tip: if you can arrange that units sourcing the bus drive 0's when "tristated", either by using flip-flop outputs (use the built-in synchronous reset functionality) or using logic that can be finagled to output 0, then you can simply 'or' these sources together. This can be cheaper in gates or levels of logic than using a general purpose n-bit m-source multiplexer.

Ex-100%-of-TBUFs-user, Jan Gray

Reply to
Jan Gray

This is similar to what I do for wide muxes. But I don't bother with the tristate.

I use decoded signals like you have above, sel(n). They are both easier to create and use (in terms of logic). I then AND each bus with its enable and OR together the result. If you want to "help" the software optimally map this to LUTs, you can use two data inputs to a LUT along with the two enables. Then four of these LUTs can be combined in one LUT to give an 8 input mux in five LUTs.

The most Xilinx parts will give you an 8 input mux using 4 LUTs and some give a 16 input mux using 8 LUTs since they include the muxes to combine LUTs. Otherwise my approach above is the best I have found that is (relatively) technology independant.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

This works better than the tristate logic which some parts (Xilinx) have. You can use the verilog wired-or type to avoid a lot of typing:

// register file

wor [15:0] read_bus; // 16 N-input OR gates.

bus_register #(.ADDRESS(0)) control ( .read_data (read_bus), ... );

bus_register #(.ADDRESS(1)) status ( .read_data (read_bus), ... );

--
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Reply to
Joseph H Allen

Thanks for the tips, and hints. Very useful indeed.

Jason

designed

vector

lines,

appreciated.

Reply to
Jason Berringer

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.