Tristates in synthesis

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

Reply to
Philipp Klaus Krause
Loading thread data ...

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
Reply to
GaborSzakacs

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

Reply to
alb

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

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 ?

Reply to
Brane2

(snip)

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

Reply to
glen herrmannsfeldt

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
Reply to
rickman

(snip)

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.

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.

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

-- glen

Reply to
glen herrmannsfeldt

(snip)

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.

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.

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

-- glen

Reply to
glen herrmannsfeldt

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
Reply to
rickman

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

Reply to
Theo Markettos

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.