Lattice Announces EOL for XP and EC/P Product Lines

rickman wrote:
[snip]
> My understanding is that TBUFs may have been a good idea when LUT delays 
> were 5 nS and routing was another 5 to 10 between LUTs, but as they made 
> the devices more dense and faster they found the TBUFs just didn't scale 
> in the same way, in fact the speed got worse!  The capacitance being 
> driven didn't go down much and the TBUFs needed to scale which means 
> they had less drive.  So they would have actually gotten slower.  No, 
> they are gone because TBUFs just aren't your friend when you want to 
> make a dense, fast chip.
> 

I think TBUFs went away along with "long lines" due to capacitive delay 
as you noted.  Modern FPGA's use buffered routing, and tristates don't
match up with that sort of routing network since the buffered routes
become unidirectional.  The silicon for line drivers is now much faster
than routing prop delays, making the buffered network faster than a
single point driving all that line capacitance.  So the new parts have
drivers in every switch box instead of just pass FETs.  I think the
original Virtex line was the first to use buffered routing, part of
the Dyna-Chip aquisition by Xilinx.  They still had long lines and
TBUFs, but that went away on Virtex 2.

-- 
Gabor

rickman <gnuarm@gmail.com> wrote:
>> "
> 
> Yes, that is what we are discussing.  Why did *Xilinx* give out the 
> family jewels to Lucent?  We know it happened, the question is *why*?

(snip)
>> Yes, that's why I miss the TBUF's :)

>> In the XC4000/Virtex days, the same 32 bit core fit into
>> 300-400 LUT4's, and a good number of TBUF's.

>>   The growth to ~800 LUT4 is split between the TBUF
>> replacement muxes and new instruction set features.
 
> My understanding is that TBUFs may have been a good idea when LUT delays 
> were 5 nS and routing was another 5 to 10 between LUTs, but as they made 
> the devices more dense and faster they found the TBUFs just didn't scale 
> in the same way, in fact the speed got worse!  The capacitance being 
> driven didn't go down much and the TBUFs needed to scale which means 
> they had less drive.  So they would have actually gotten slower.  No, 
> they are gone because TBUFs just aren't your friend when you want to 
> make a dense, fast chip.

That is probably enough, but it is actually worse than that.

At about 0.8 micron, the wiring has to use a distributed RC model.

Above, you can treat it as driving a capacitor with a current source.
All points are, close enough, the same voltage, and the only thing
that matters is what that voltage is. (LC delay is pretty low.)

Below 0.8 micron, and besides the fact that the lines are getting
longer, the resistance is also significant. It is then modeled as
series resistors and capacitors to ground, all the way down the line.
(As well as I remember, the inductance is less singificant that
resistance, but I haven't thought about it that closely for
a while now.)

-- glen

Gabor wrote:
> I think TBUFs went away along with "long lines" due to capacitive delay 

I appreciate the rationale.
Yet still I miss their functionality for processor designs.
[ "Lament of the TBUF" would make an excellent dirge title ]

> Modern FPGA's use buffered routing, and tristates don't match up with that 

I think I once read that the last generation or few of TBUF's were actually implemented with dedicated muxes/wired OR's, or something similar.

I wish that had been continued on a reduced scale, TBUF's every 4 or 8 columns, matching the carry chain pitch, spanning some horizontal fraction of a clock region.

-Brian

Brian Davis <brimdavis@aol.com> wrote:
> Gabor wrote:
(snip)
>> Modern FPGA's use buffered routing, and tristates don't 
>> match up with that 
 
> I think I once read that the last generation or few of 
> TBUF's were actually implemented with dedicated muxes/wired 
> OR's, or something similar.

As far as I know, they are still implemented by the synthesis
tools as either OR or AND logic. I don't know any reason to remove
that ability, as it doesn't depend on the hardware. Then again, it
isn't hard to write the logic directly.

-- glen

In article <l08jta$9m8$1@speranza.aioe.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Brian Davis <brimdavis@aol.com> wrote:
>> Gabor wrote:
>(snip)
>>> Modern FPGA's use buffered routing, and tristates don't 
>>> match up with that 
> 
>> I think I once read that the last generation or few of 
>> TBUF's were actually implemented with dedicated muxes/wired 
>> OR's, or something similar.
>
>As far as I know, they are still implemented by the synthesis
>tools as either OR or AND logic. I don't know any reason to remove
>that ability, as it doesn't depend on the hardware. Then again, it
>isn't hard to write the logic directly.

We do this now in verilog - declare our read data bus (and similar signals) as
"wor" nets.  Then you can tie them all together as needed.  Saves you the
hassle of actually creating/managing individual return data, and muxxing it
all.

The individual modules must take care to drive 0's on the read_data when not
in use.  Then you're really creating multi-source signals (like past bus 
structures), but relying on the "wor" to resolve the net.   

Works in Xilinx XST and Synplicity.  Don't know about others.  Don't know if 
this trick would work in VHDL.

--Mark

Mark Curry <gtwrek@sonic.net> wrote:

(snip, I wrote)
>>As far as I know, they are still implemented by the synthesis
>>tools as either OR or AND logic. I don't know any reason to remove
>>that ability, as it doesn't depend on the hardware. Then again, it
>>isn't hard to write the logic directly.
 
> We do this now in verilog - declare our read data bus 
> (and similar signals) as "wor" nets.  Then you can tie them 
> all together as needed.  Saves you the hassle of actually 
> creating/managing individual return data, and muxxing it all.
 
> The individual modules must take care to drive 0's on the 
> read_data when not in use.  Then you're really creating 
> multi-source signals (like past bus structures), but 
> relying on the "wor" to resolve the net.   

I think you can also do it with traditional tri-state gates,
but pretty much the same as AND with the enable, and then onto
the WOR line.
 
> Works in Xilinx XST and Synplicity.  Don't know about others.  
> Don't know if this trick would work in VHDL.

I can usually read VHDL but don't claim to write it.

-- glen

The standard data type (std_logic) is tri-statable in VHDL, so that would b=
e the preferred choice, rather than WAND or WOR. It does come in handy in t=
hat a single bidirectional port in RTL can represent both input and output =
wires, and part of the mux, at the gate level.

Tri-state bidirectional ports allow distributed address decoding in the RTL=
 (give a module the address and a generic to tell it what addresses to resp=
ond to), even though at the gate level it will all get optimized together a=
t the muxes.

Some synthesis tools can even "register" tri-state values to allow you to s=
implify pipelining in the RTL. Synthesis takes care of the details of separ=
ating out the tri-state enable from the data, and registering both appropri=
ately.

Andy