"Tbufs don't exist"

I've heard this rumor many times from different sources: that Virtex4 TBUFs don't actually have tri-state buffers in them, and that they're actually implemented as a set of wires and muxes which is logically (though not electrically) equivalent to everything you could do if they were.

Has Xilinx ever gone on-record with any complete or partial answer to this question? I can't find anything in the app notes.

If this is true, I'm pretty baffled as to how you could have long lines. To implement an equivalent structure without tri-state buffers, you'd need to replace each long line with N wires where N is the number of "possible drivers" -- a pretty large number. Isn't that rather inefficient?

Reply to
Jack Falk
Loading thread data ...

"Jack Falk" schrieb im Newsbeitrag news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

how official do you need to have it?

There are NO TBUFs in any of the new Xilinx FPGAs !!

Spartan-3, 3E, V4 : NO TBUFs

(all other older familes are not to be used anyway) so the TBUFs are gone forever :(

in S2 it was possible to get huge savings in some designs by using TBUFs, those designs will not fit into the S3 of same slice count. So not everything gets better in new familes.

Antti

Reply to
Antti Lukats

Hold the phone there, kids. You're talking about two different things:

1) Some of the earlier Virtex devices, e.g., Virtex II, had internal TriState buffers that were actually implemented with AND/OR logic. So there were things called TriState buffers that were TriState in name only. Not that there's anything wrong with that.

2) Internally, parts like Virtex 4 have neither real TriState buffers nor pseudo-TriState buffers.

Of course, all Virtex parts have TriStateable I/O drivers.

Personally, I liked the internal TriState buffers, real or pseudo; they were useful for building things like slow processor readback paths. And as best I can recall, they were free of errata. Those were the days.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

I don't care that they're gone: you can make wide input OR gates with carry chains, which end up being faster.

A problem with real TBUFs was that they were very limiting as far as placement: you would end up with this giant array of host registers overlayed on the rest of your design.

Another issue is that I wish all verilog synthesizers understood the "wor" (wired-or) type. I know Altera doesn't, but does understand tristate, which is just weird because it's going to synthesize into a big OR gate.

[Also gone in recent Xilinx: the and-or structure for simulating PALs]
--
/*  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

As I understand it, the problem is buffering.

While a long line may look like a wire to you, it has internal buffers in it in hardware. Those buffers have to point the right direction.

It is related to the scaling laws. As wires scale they get smaller in two dimensions, increasing the resistance by the square of the scale (decrease) factor, but the capacitance depends only on the width.

RC then increases as devices get smaller when it needs to decrease to keep up with the faster logic. The solution is internal buffers.

-- glen

Reply to
glen herrmannsfeldt

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.