( ESNUG 257 Item 2 ) -------------------------------------------- [12/12/96]
Subject: ( ESNUG 255 #4 256 #1) Internal Tri-State Vs. MUXes Rules Of Thumb
> I thought you might like the approach I am using on my current ASIC
> design. I have an internal bus in the ASIC that has to read
> approximately 100 registers. I mux the registers internal to each
> of my approximately 5k gate partitions that get synthesized by
> Synopsys. When I mux inside the partition, I have a "case" statement
> with the default/others choice with the output all zeros if none
> of the registers are selected. I then daisy chain "OR" the partition
> outputs from one partition to the next. This approach minimizes the
> routing between partitions and so does not require lots of routing
> like the external mux approach would require. This approach only
> requires a 1x driver to drive the next partition since there is only a
> single load when you "OR" which is much better than tri-stating.
From: dchapman@goldmountain.com (Dave Chapman)
Wow, John.
It simply never occurred to me to do it that way. Perhaps the 100 gate-delay
propagation time has something to do with this. For low-performance
applications, it might be the way to go.
Meanwhile, several people pointed to the problem of finite fan-out from a
tri-state driver. Right. You will have to partition the design, with sub-
buses and so on, until it looks something like a PC, with a CPU bus, an ISA
bus, a PCI bus, and whatever the flavor of the month is bus. That's life.
My conclusion is that we still do not have a single best solution to the
problem of designing a bus, and that these things will continue to require
trade-offs and plain old design skill.
- Dave Chapman
Goldmountain
---- ---- ---- ---- ---- ---- ----
From: tbrown@armltd.co.uk (Tudor Brown)
John,
In my experience of designing complex systems, tristate buses are hard to
avoid when going for area and power efficiency (though system architecture
issues of a chip can determine area & power more than any methodology such as
tristate buses, etc.)
We naturally use tristate buses as the default approach, and I think it is
fair to say that we have had some actual problems and also some near misses
in terms of tools support spotting contention or power-up faults, but the
savings made in my opinion justify the perserverence.
My answer to the "which is better" debate would be "it depends if your
tools can support the methodology". If your tools expect to cope with the
charge-sharing, contention and undriven aspects of tristate buses, then
bidi's are usually smaller and cheaper. But if your tools expect logical
connections only, then it is best not to push the bidi philosophy, because
sooner or later you will come unstuck when the tools miss a logical driver
error -- resulting in contention, or float.
Personally, I feel it is a bit of a cop-out on the part of many tool flows
not to treat the issues of bidirectional buses and mulitle drivers correctly,
but unless you really go it on your own and use transistor level simulation
(which most of the world cannot afford to do) then most designers are limited
by the capabilities of the tools they use. So sadly, unidirectional buses are
here to stay as well.
Our ARM7TDMI core, designed for embeddability recognises this fact and
actually has 96 data pins! There is a bidirectional bus and also 2
unidirectional buses. Then it is up to the user to determine the philosphy
he wants to invoke in using the core.
- Tudor Brown, Chief Technical Officer
ARM, Ltd.
---- ---- ---- ---- ---- ---- ----
> One very serious problem with tri-states that wasn't addressed is the
> possibility of creating a tri-state net which can't be driven by the
> largest tri-state driver in the cell library, (i.e. the net capacitance
> is larger than the max_cap attribute of the tri-state driver.)
From: sgolson@trilobyte.com (Steve Golson)
A subtle point, John: if you have a big tri-state bus, you may get faster
performance by using a *smaller* drive tri-state buffer. If you use the
largest buffer in your library, then all the drivers on the bus will
see a much larger load on the bus (due to the pin capacitance of the
other big drivers). Your library probably has a "sweet spot" --
experiment and try out all possible buffers for the size bus you have,
in order to find the fastest cell.
Do not let Design Compiler blindly pick the tri-state driver! For any
given small module, DC sees a giant load on the bus, and picks the
largest drive buffer. If all the modules do this, you get sub-optimal
performance. Use "set_dont_use" on all other tri-state library cells,
so DC is forced to use the particular tri-state buffer you want.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
The big "gotcha" I've seen from internal tri-state buses is that the tools
downstream from synthesis sometimes have had problems. For example, some
ATPG tools have historically just "choked" when encountering them.
(Apparently internal tri-state buses don't test nicely.)
- John Cooley
the ESNUG guy
|
|
