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

Dominik Froehlich wrote:
> 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

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.

John_H wrote:
> Dominik Froehlich wrote:
>> 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
> 
> 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.

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

"Dominik Froehlich" <dfroehli@htwm.de> wrote in message 
news:43v2qpF1pph55U1@news.dfncis.de...
> 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

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. 

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.

Dominik

John_H wrote:
> "Dominik Froehlich" <dfroehli@htwm.de> wrote in message 
> news:43v2qpF1pph55U1@news.dfncis.de...
>> 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
> 
> 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. 
> 
> 

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.

2. 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

wtxwtx@gmail.com wrote:
> Hi John,
> "But it's never good design practice to have tristates with multiple
> sources; "
> 
> I disagree with your opinion.

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

wtxwtx@gmail.com wrote:

> 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.

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

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:
> wtxwtx@gmail.com wrote:
>
> > 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.
>
> 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

<wtxwtx@gmail.com> wrote in message 
news:1138639411.086462.285470@o13g2000cwo.googlegroups.com...
> 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



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.