tristate to logic conversion

hi,

for some devices xilinx ise offers an option to convert internal tristate buffers to equivalent logic. however, i cannot find any information how this works in detail.

i understand that all tristate buffers driving one signal can be replaced by a multiplexer or equivalent logic. the problem is how the selector logic is derived from the original enable signals. if multiple enables are active concurrently, is there a sort of prioritization?

why is the conversion restricted to specific devices?

any hint, or even conference papers, manuals, etc. are very welcome.

thank you in advance.

dominik

Reply to
Dominik Froehlich
Loading thread data ...

The data sheet for the tristate emulators in the earliest families that got rid of tristates described the situation beautifully; I would expect the synthesis to do the same but I can't guarantee 100%:

When no enables are active, result is logic 1. When a single enable is active, the result is the signal controlled by that enable. When more than one enable is active, the result is logic zero if *any* of the inputs are a zero, otherwise 1.... Effectively it becomes an AND function of the enabled inputs.

But it's never good design practice to have tristates with multiple sources; that was a good way to put a crach in the old XC4000 parts if I recall those days long gone correctly. I've done multiple enabled sources myself with good results where the hardware emulation was described in the datasheet so very well but wouldn't have done it without that backup info.

Reply to
John_H

Dear John,

thank you for this information. The background of my question is academic, hopefully I do not crash any devices ;-). Since there are many ways the conversion can be done, I was interested in the particular approach that used used by Xilinx. Unfortunately there is a lack of information here.

If you saying this was documented for the earliest device families to which family do you refer in particular? I was seeking the data-sheets to XC2000 family but didn't find any hint :-(.

Is anybody aware of according documentation for modern Xilinx devices or even devices of other vendors?

Thank you and have a nice weekend.

Dominik

Reply to
Dominik Froehlich

My Spartan-2E design used the non-tristate tristates where the data sheet documented the "emulated" functionality (or the detail may have been in the Virtex-E data sheet which fully applied to Spartan-2E). The XC2000 family is ancient - a little like looking for documentation on the Notre Dame Cathedral. It's out there, but it's pretty academic unless you visit the cathedral.

The detail information you seek is quite possibly in online help for varios tools since tristate emulation is a function provided by the tools. You could also try synthesizing code with tristate emulation and looking at the results at the implementation level.

Reply to
John_H

I was just taking "earliest" literally, but the cathedral is quite nice :-). Anyway, thanks a lot for your information.

Best regards and have nice weekend.

Dom>> Dear John,

Reply to
Dominik Froehlich

Hi John, "But it's never good design practice to have tristates with multiple sources; "

I disagree with your opinion.

Tristate gates are used everywhere in an ASIC chip with no exception of FPGA. BLOCK RAM in Xilinx chip has to use tristate to get the selected data to output.

In my opinion, there are two types of tristate buses:

  1. Passive. It works well for interrupt system. If one of sources is to assert, it pulls down the bus. If it is to deassert, tristate the output and leave the bus to return high state by a pullup. It cannot be used for fast data transactions.

  1. Active. It works well for any multiple mutually exclusive sources to drive a data bus. The example is BLOCK RAM in Xilinx FPGA. In a normal FPGA design, the tristate bus can be safely used for the last stage of data output. This type of tristate buses is active because only one source drives the data bus at each clock, either high or low, there is no limit on its driving data. In my many designs, tristate data bus for the last stage of data outputs is much better than combinational logic. I will do a comparison between a tristate bus and its logic equilance for Xilinx chip to see if there is any impact on the performance. I have been always using tristate bus for my last stage of data outputs.

By the way, there is an patent from Xilinx: 5,677,638 "High Speed Tristate Bus with Multiplexers for Selecting Bus Driver". It deals with what you want to know. One trick is you always can find the most secret or core technology of Xilinx by reading their patents. All patents must meet a requirement that can be implemented by people in the art. We always belong to the people in the art.

In my opinion, there are many smart and brand new ideas imbedded in the

1100 patents of Xilinx that give you many lessons, teaching and experiences that couldn't get from college or textbooks, but they also expose many points that can be further improved.

Altela seems to adopt another type of strategies and tries to keep its secrets as commercial ones. Recently Alterla has gotten few patents. I don't know why.

Weng

Reply to
wtxwtx

If an unseasoned engineer is developing code or if the code can be targeted by engineers months later into an architecture where the tristates are no longer "equivalent" tristate functionality, problems may arise. The tools will not exclude two drivers active at once. The new architecture with the real internal tristate might go pfffft. To Dominik's credit (the original poster) he's trying to find out about the less-than-clear practice of synthesis providing tristate emulation.

Careless use of tristates is especially bad if a later retargeted architecture is an ASIC.

If you know everything you're getting into, tristates with multiple

*simultaneous* sources is fine but the code can't be moved to an architecture where the internal tristate bus contention will fry the device (any implementation with one source active at a time is fine, but multiple active drivers is not - perhaps this nuance wasn't communicated well before).

As I stated in the original reply, I indeed designed a multiple-simultaneous-source tristate bus in the FPGA architecture where the behavior of the tristate emulation was very clear. It would not be good design practice to do this willy-nilly but only to do it when it's guaranteed there will be no disasterous side effects now or for other engineers later.

And as you pointed out, it is just my opinion.

- John_H

Reply to
John_H

I can't think of a FPGA device new enough to have block RAM yet old enough to have a real internal tri-state bus.

-- Mike Treseler

Reply to
Mike Treseler

Hi Mike, I disagree with your opinion.

BLOCK RAM data output is driven by its address, no matter it is old or brand new. How does it work for a 4K bytes block? Each RAM bit internally drives a 1-bit tristate data bus selected by its address decode logic. From outside, it is only one data output bus.

For any CPUs, its SRAM in cache are also driven by its addresses. So tristate buses are as ubiquitous as a register. No any exception is for general FPGA design.

Only passive tristate bus is rarely used and shouldn't be used for an active data bus.

Weng

Mike Treseler wrote:

Reply to
wtxwtx

So my earlier comment that you disagreed with should be modified to state:

"But it's never good design practice to have [Verilog] tristates with multiple [simultaneous] sources"

I don't think anyone doubts that tristate functionality in silicon IP blocks is a bad idea because the issues of multiple simultaneous drivers is excluded.

Reply to
John_H

Hi John, I would like to say: Multiple sources can safely drive a tristate bus without any bad effects if their enable signals are mutually exclusive either by their logic or by physical conditions.

There are many situations where mutually exclusive conditions exist by their physical conditions, not by their logic. For example, you must drive a data bus on two different physical conditions, then their enable signals are mutually exclusive. For example, if one chip has to drive a bus, the bus runs with either 64-bit or 32-bit conditions. The source enable signals driving 64-bit and 32-bit are mutually exclusive, no matter how your design logic is.

Weng

John_H wrote:

Reply to
wtxwtx

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.