B
bharat_in
Guest
Why is it avoided to have tri-state in RTL?
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Mike Lewis
Guest
"bharat_in" <ecbharat@gmail.com> wrote in message
news:1170910752.428324.179640@j27g2000cwj.googlegroups.com...
that a common homework question?
Here is my opinion ...
1. tri-state usually implies that the signal (or bus) is bi-directional. A
bi-dir is usually used to save pins. Within an FPGA/ASIC .. there is no need
to save pins so two uni-directional pins/busses can be used.
2. Care must be taken when using a tri-state .. it is very easy to create a
design that accidently has more than one source driving the tri-state signal
causing contention. Contention cause high current to flow and can cause
permanent damage.
3. tri-states require a "turn-around" signal when switching from one source
to another source to prevent the aformentioned contention. This is a wasted
clock cycle for high performance designs.
4. In FPGAs .. tri-states are a limited resource (at least they were years
ago when I last used one).
I can't think of any more reasons why I wouldn't use them.
Mike
news:1170910752.428324.179640@j27g2000cwj.googlegroups.com...
I see this question repeated a number of times within this newsgroup ... isWhy is it avoided to have tri-state in RTL?
that a common homework question?
Here is my opinion ...
1. tri-state usually implies that the signal (or bus) is bi-directional. A
bi-dir is usually used to save pins. Within an FPGA/ASIC .. there is no need
to save pins so two uni-directional pins/busses can be used.
2. Care must be taken when using a tri-state .. it is very easy to create a
design that accidently has more than one source driving the tri-state signal
causing contention. Contention cause high current to flow and can cause
permanent damage.
3. tri-states require a "turn-around" signal when switching from one source
to another source to prevent the aformentioned contention. This is a wasted
clock cycle for high performance designs.
4. In FPGAs .. tri-states are a limited resource (at least they were years
ago when I last used one).
I can't think of any more reasons why I wouldn't use them.
Mike
G
glen herrmannsfeldt
Guest
Mike Lewis wrote:
(snip)
synthesized as an appropriate MUX. The change is related to the scaling
rules for FPGAs, specifically the need to buffer signals, which requires
knowing which direction they are going.
Real tri-states are still available on output drivers, though.
-- glen
(snip)
As I understand it, tri-states are now gone from FPGA hardware, and are4. In FPGAs .. tri-states are a limited resource (at least they were years
ago when I last used one).
synthesized as an appropriate MUX. The change is related to the scaling
rules for FPGAs, specifically the need to buffer signals, which requires
knowing which direction they are going.
Real tri-states are still available on output drivers, though.
-- glen
G
Guenter
Guest
On Feb 8, 6:25 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
while...
Now when you have a soft core processor, does that mean they use split
busses? So all the peripherals have a data in and data out bus?
Cheers,
Guenter
Not a homework question, but I have been pondering about this for a"bharat_in" <ecbha...@gmail.com> wrote in message
news:1170910752.428324.179640@j27g2000cwj.googlegroups.com...
Why is it avoided to have tri-state in RTL?
I see this question repeated a number of times within this newsgroup ... is
that a common homework question?
Here is my opinion ...
1. tri-state usually implies that the signal (or bus) is bi-directional. A
bi-dir is usually used to save pins. Within an FPGA/ASIC .. there is no need
to save pins so two uni-directional pins/busses can be used.
while...
Now when you have a soft core processor, does that mean they use split
busses? So all the peripherals have a data in and data out bus?
Cheers,
Guenter
R
Ralf Hildebrandt
Guest
Guenter schrieb:
tri-state bus:
<http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/ee979676214413cb/ecb0b12c1e9b5a76?lnk=st&q=Ralf+Hildebrandt+tri+state+%22OR%22+bus&rnum=1#ecb0b12c1e9b5a76>.
Ralf
Yes - this is common practice. Furthermore it is often better than aNow when you have a soft core processor, does that mean they use split
busses? So all the peripherals have a data in and data out bus?
tri-state bus:
<http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/ee979676214413cb/ecb0b12c1e9b5a76?lnk=st&q=Ralf+Hildebrandt+tri+state+%22OR%22+bus&rnum=1#ecb0b12c1e9b5a76>.
Ralf
A
Andy
Guest
On Feb 9, 9:17 am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote:
rtl. But, in devices where tri-state buses get converted to
multiplexers, the synthesis tool assumes the tri-state enables are
mutually exclusive. This is a handy means of getting the tool to
assume mutual exclusivity, even when it cannot be proven.
For instance, If I decode an address into strobes, that decoding
assumes the different address values are mutex. But if I register the
strobes, and then use those registered strobes control a mux, all
knowledge of their being mutex is gone, and I either get priority
encoding or exclusive encoding, neither of which is optimal. If I use
those registered strobes as tri-state enables on a bus, then the
synthesizer assumes they are mutex, and optimizes the mux accordingly.
Andy
I agree with the reasons stated previously for not using tri-states inGuenter schrieb:
Now when you have a soft core processor, does that mean they use split
busses? So all the peripherals have a data in and data out bus?
Yes - this is common practice. Furthermore it is often better than a
tri-state bus:
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/ee979...>.
Ralf
rtl. But, in devices where tri-state buses get converted to
multiplexers, the synthesis tool assumes the tri-state enables are
mutually exclusive. This is a handy means of getting the tool to
assume mutual exclusivity, even when it cannot be proven.
For instance, If I decode an address into strobes, that decoding
assumes the different address values are mutex. But if I register the
strobes, and then use those registered strobes control a mux, all
knowledge of their being mutex is gone, and I either get priority
encoding or exclusive encoding, neither of which is optimal. If I use
those registered strobes as tri-state enables on a bus, then the
synthesizer assumes they are mutex, and optimizes the mux accordingly.
Andy
G
glen herrmannsfeldt
Guest
Andy wrote:
(snip)
get bigger, and wires get smaller, the only way to keep up the
speed is to buffer them along the way.
the appropriate signal, and then OR the result. That means only
two gate delays, (not counting wires or buffers). With tristate
drivers, avoiding contention probably means you are less than
optimal, but I don't see that AND/OR logic is less optimal,
other than unneeded work to avoid contention.
-- glen
(snip)
My understanding is that it is related to scaling. As processorsI agree with the reasons stated previously for not using tri-states in
rtl. But, in devices where tri-state buses get converted to
multiplexers, the synthesis tool assumes the tri-state enables are
mutually exclusive. This is a handy means of getting the tool to
assume mutual exclusivity, even when it cannot be proven.
get bigger, and wires get smaller, the only way to keep up the
speed is to buffer them along the way.
Not knowing how they do it, if I did it I would AND each enable withFor instance, If I decode an address into strobes, that decoding
assumes the different address values are mutex. But if I register the
strobes, and then use those registered strobes control a mux, all
knowledge of their being mutex is gone, and I either get priority
encoding or exclusive encoding, neither of which is optimal.
the appropriate signal, and then OR the result. That means only
two gate delays, (not counting wires or buffers). With tristate
drivers, avoiding contention probably means you are less than
optimal, but I don't see that AND/OR logic is less optimal,
other than unneeded work to avoid contention.
What optimization do you mean here?If I use
those registered strobes as tri-state enables on a bus, then the
synthesizer assumes they are mutex, and optimizes the mux accordingly.
-- glen
A
Andy
Guest
On Feb 12, 6:39 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
optimize to the AND/OR tree you described above. If they are not Mutex
(or known/assumed to be mutex), then each AND also has to take the
nots of the other selects, or implement a priority scheme, which
requires wider AND functions on all but the highest priority line.
Andy
A non-prioritized multplexer with mutually exclusive selects willAndy wrote:
(snip)
I agree with the reasons stated previously for not using tri-states in
rtl. But, in devices where tri-state buses get converted to
multiplexers, the synthesis tool assumes the tri-state enables are
mutually exclusive. This is a handy means of getting the tool to
assume mutual exclusivity, even when it cannot be proven.
My understanding is that it is related to scaling. As processors
get bigger, and wires get smaller, the only way to keep up the
speed is to buffer them along the way.
For instance, If I decode an address into strobes, that decoding
assumes the different address values are mutex. But if I register the
strobes, and then use those registered strobes control a mux, all
knowledge of their being mutex is gone, and I either get priority
encoding or exclusive encoding, neither of which is optimal.
Not knowing how they do it, if I did it I would AND each enable with
the appropriate signal, and then OR the result. That means only
two gate delays, (not counting wires or buffers). With tristate
drivers, avoiding contention probably means you are less than
optimal, but I don't see that AND/OR logic is less optimal,
other than unneeded work to avoid contention.
If I use
those registered strobes as tri-state enables on a bus, then the
synthesizer assumes they are mutex, and optimizes the mux accordingly.
What optimization do you mean here?
-- glen
optimize to the AND/OR tree you described above. If they are not Mutex
(or known/assumed to be mutex), then each AND also has to take the
nots of the other selects, or implement a priority scheme, which
requires wider AND functions on all but the highest priority line.
Andy
G
glen herrmannsfeldt
Guest
Andy wrote:
(snip on tristate buses, I previously wrote)
with tristate TTL, it is the users responsibility to avoid contention.
Since there is no guarantee of the result if more than one are
enabled at the same time, it might just as well be a "don't care"
state for logic synthesis. I believe that would come under your
"assumed to be mutex" case.
I don't know of any tristate logic implementing a priority scheme.
-- glen
(snip on tristate buses, I previously wrote)
(snip)Not knowing how they do it, if I did it I would AND each enable with
the appropriate signal, and then OR the result. That means only
two gate delays, (not counting wires or buffers). With tristate
drivers, avoiding contention probably means you are less than
optimal, but I don't see that AND/OR logic is less optimal,
other than unneeded work to avoid contention.
For real tristate logic, which Xilinx (at least) used to provide, asA non-prioritized multplexer with mutually exclusive selects will
optimize to the AND/OR tree you described above. If they are not Mutex
(or known/assumed to be mutex), then each AND also has to take the
nots of the other selects, or implement a priority scheme, which
requires wider AND functions on all but the highest priority line.
with tristate TTL, it is the users responsibility to avoid contention.
Since there is no guarantee of the result if more than one are
enabled at the same time, it might just as well be a "don't care"
state for logic synthesis. I believe that would come under your
"assumed to be mutex" case.
I don't know of any tristate logic implementing a priority scheme.
-- glen