Tristates in synthesis

[Philipp Klaus Krause]

How well can the synthesis tools deal with tristates?

If I use the following Verilog code for a Xilinx CPLD, with t as the
top-level module, and data_io and addr_i connected to I/O ports. Will
this work as intended?

module b(data_io, addr_i);
inout[6:0] data_io;
input[12:0] addr_i;

assign data_io = (addr_i == 321) ? 7'b1111111 : 7'bZZZZZZZ;
endmodule

module i(data_io, addr_i);
inout[1:0] data_io;
input[12:0] addr_i;

assign data_io = (addr_i == 123) ? 2'b00 : 2'bZZ;
endmodule

module t();
inout[6:0] data_io;
input[12:0] addr_i;

b b(data_io[6:0], addr_i);
i i(data_io[1:0], addr_i);
endmodule

 

[GaborSzakacs]

Philipp Klaus Krause wrote:

How well can the synthesis tools deal with tristates?

If I use the following Verilog code for a Xilinx CPLD, with t as the
top-level module, and data_io and addr_i connected to I/O ports. Will
this work as intended?

module b(data_io, addr_i);
inout[6:0] data_io;
input[12:0] addr_i;

assign data_io = (addr_i == 321) ? 7'b1111111 : 7'bZZZZZZZ;
endmodule

module i(data_io, addr_i);
inout[1:0] data_io;
input[12:0] addr_i;

assign data_io = (addr_i == 123) ? 2'b00 : 2'bZZ;
endmodule

module t();
inout[6:0] data_io;
input[12:0] addr_i;

b b(data_io[6:0], addr_i);
i i(data_io[1:0], addr_i);
endmodule

And did you try it?

I've never had a problem with external (IOB) tristates with Xilinx
tools. Internal tristates are not recommended, even though in some
cases the tools infer similar logic. The last devices that had
internal tristates (Virtex and Virtex E, Spartan 2 and 2e) are
either past end of life or not recommended for new design.

--
Gabor

 

[alb]

Hi Philipp,

Philipp Klaus Krause <pkk@spth.de> wrote:
> How well can the synthesis tools deal with tristates?

it is possible the tool vendor provides you recommendations on how to
describe tristates. Check their coding guidelines.

AFAIK tristates can be easily handled if connected directly to I/O since
they generally support this mode. But I do use them at lower levels as
well to describe bus access for instance. since I find it more readable
than describing muxes myself.

It works, if you follow tool vendor coding guidelines. And if it does
not, you may blame them!

Al

 

[Brane2]

Dne petek, 04. april 2014 13:14:49 UTC je oseba Gabor napisala:

<SNIP>

The last devices that had

internal tristates (Virtex and Virtex E, Spartan 2 and 2e) are

either past end of life or not recommended for new design.

Does anyone know why were tristates banned from newer devices ?
Is it about signal integrity, some kind of leakages on the floating nets or something different alltogether ?

 

[glen herrmannsfeldt]

Brane2 <brankob@avtomatika.com> wrote:

(snip)

Does anyone know why were tristates banned from newer devices ?
Is it about signal integrity, some kind of leakages on the
floating nets or something different alltogether ?

Scaling.

When the wires get smaller and longer, they require buffers along
the way to drive fast signals the full length. The buffers only go
one direction.

-- glen

 

[rickman]

On 4/5/2014 1:27 AM, Brane2 wrote:

Dne petek, 04. april 2014 13:14:49 UTC je oseba Gabor napisala:

SNIP

The last devices that had

internal tristates (Virtex and Virtex E, Spartan 2 and 2e) are

either past end of life or not recommended for new design.

Does anyone know why were tristates banned from newer devices ?
Is it about signal integrity, some kind of leakages on the floating nets or something different alltogether ?

Tristates are just not a good solution to most problems in FPGAs. They
were called "long lines" because that is what they were, very long wires
in the part which use up a lot of real estate and slow down a signal.
Considering that they use space on every part when most designers don't
use them, they decided to give them the boot and free the space for more
logic which can do the same job and runs faster anyway.

--

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip)
> Tristates are just not a good solution to most problems in FPGAs.

Well, at some point getting the logic right is most important,
and if implementing it with simulated tristates gets it right,
and is more readable, then that is probably better.

They were called "long lines" because that is what they were,
very long wires in the part which use up a lot of real estate
and slow down a signal.

Above about 0.8u, one could consider a "wire" as an equipotential,
that is, (close enough to) a perfect conductor, with capacitance
to ground and driven by a current source. The capacitance depends
on the width and length. If width is constant, then length.

The delay, then, depends on the total length of the wire, not
the distance between the source and sink. (That is, when there
is more than one source or sink.) The model is a lumped capacitance
driven by a current source. (Proper scaling of MOSFETs decreases
the channel width, length, and oxide thickness in proportion,
keeping the on resistance constant.) Circuits speed up as
capacitance decreases, both from width and length.

As above, the capacitance depends on width and length, but the
resistance depends on width, length, and height. Height scales
with width. As width gets smaller, capacitance decreases in
proportion, but resistance increases quadratically. The model
is now a distributed capacitance and distibuted resistance,
which required a big change in all the timing tools.

At some point the delay through the distributed RC wires
gets too long, and intermediate buffers are required.

Considering that they use space on every part when most
designers don't use them, they decided to give them the
boot and free the space for more logic which can do the
same job and runs faster anyway.

I haven't thought about this for a while. I think the lines
would still be used, but the driver always enabled.

-- glen

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip)
> Tristates are just not a good solution to most problems in FPGAs.

Well, at some point getting the logic right is most important,
and if implementing it with simulated tristates gets it right,
and is more readable, then that is probably better.

They were called "long lines" because that is what they were,
very long wires in the part which use up a lot of real estate
and slow down a signal.

Above about 0.8u, one could consider a "wire" as an equipotential,
that is, (close enough to) a perfect conductor, with capacitance
to ground and driven by a current source. The capacitance depends
on the width and length. If width is constant, then length.

The delay, then, depends on the total length of the wire, not
the distance between the source and sink. (That is, when there
is more than one source or sink.) The model is a lumped capacitance
driven by a current source. (Proper scaling of MOSFETs decreases
the channel width, length, and oxide thickness in proportion,
keeping the on resistance constant.) Circuits speed up as
capacitance decreases, both from width and length.

As above, the capacitance depends on width and length, but the
resistance depends on width, length, and height. Height scales
with width. As width gets smaller, capacitance decreases in
proportion, but resistance increases quadratically. The model
is now a distributed capacitance and distibuted resistance,
which required a big change in all the timing tools.

At some point the delay through the distributed RC wires
gets too long, and intermediate buffers are required.

Considering that they use space on every part when most
designers don't use them, they decided to give them the
boot and free the space for more logic which can do the
same job and runs faster anyway.

I haven't thought about this for a while. I think the lines
would still be used, but the driver always enabled.

-- glen

 

[Theo Markettos]

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

At some point the delay through the distributed RC wires
gets too long, and intermediate buffers are required.

The advantage of switched interconnect, which is what often gets used today
instead of buses, is that the intermediate buffers become registers. That
means it's possible to have more than one value in flight at once.

With buffers you still have to charge/discharge the whole wire, the buffers
just make it faster than a driver at one end. But if it's registered the
cycle time can be shorter because you only need to charge the section of line
until the next register. It'll then pass along in the next (shorter) clock
cycle. Next cycle you can put something else on the wire.

Of course this means handling the case that data doesn't come back in a
single cycle, but it means your cycles end up a lot faster than they would
otherwise be (well, bottlenecked somewhere else more likely).

Theo

 

[rickman]

On 4/6/2014 5:57 AM, glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:

Considering that they use space on every part when most
designers don't use them, they decided to give them the
boot and free the space for more logic which can do the
same job and runs faster anyway.

I haven't thought about this for a while. I think the lines
would still be used, but the driver always enabled.

Not sure what you mean. The original tristate busses on FPGAs crossed
the entire chip. I seem to recall the last generation of chips with
tri-state busses only had them across quadrants, but I may be confusing
this with another feature. The point is that if you don't need them
they are entirely wasted (just like any other special feature) but
unlike other hard logic on the chip the equivalent logic implemented in
the fabric is not so terribly larger or slower.

I talked about this a number of times with the FAEs and I don't recall
them mentioning the need for buffers. I think it was just a chip area
vs. utility trade off. There are just a lot of people who think in
terms of tri-state busses rather than muxed busses so they stuck around
for some time past their real usefulness.

I remember when I was still in grad school a friend had started work at
IBM where they were making chips for government sonar work. They had
already reached the point of not using tristate busses on chip,
replacing them with the extra wiring and muxes. That was some 20 years
before these features were taken off of FPGAs.

--

Rick