How many mux input on a Xilinx V4 are pratical
Brad Smallridge
video data with a number of adjustable
parameters (like window borders) and
process results (like pixel counters).
I seen to have about 28 of them so far,
ranging from binary on/off to 10 bit BCD
counters.
These are displayed on a VGA port or an
NTSC overlay. All these parameters exist
on the fabric and are Muxed into a overlay
module that displays them in real time.
My question is how many of these parameters
and counters can I add before I run into
some real serious routing issues? Is there
anything I can do to minimize this potential
problem?
Brad Smallridge
AiVision
John_H
Since modern FPGAs are significantly routing resources, I'd suggest you
won't run into a routing problem. Have you seen something that suggests
you'll have a problem?
Consider that the mux can be implemented as a binary tree with 2-input
muxes (or 4-input for some families). A binary tree is much simpler to
implement and distribute than a priority encoder style of multiplexer
(using cascade logic).
If your timing is ample, the binary tree is great. If you need better
timing, coding to force more than one level of priority encoder style
mux (10:1 mux structures, for instance) can provide a good balance
between more, longer lines and speed.
I seriously think that if you don't concern yourself with it, it won't
be an issue. Unless timing is a problem. Even then, pipelining of the
large mux will help as well. There are too many ways to make it work
cleanly.
Just my humble opinion,
- John_H
Peter Alfke
wrote:
You might think of using a BlockRAM as a big multiplexer.
You can use one port to enter variable data, and the other port to
output them for display.
Speed will not be an issue.
Just a thought....
Peter Alfke, from home
Gabor
I typically use block or distributed RAM for such muxes. Many of
my designs contain parameters set by I2C bus (very slow). I use
RAM as the readback port for all read/write registers / bits. For
other read-only bits there is a mux in the fabric. So now you have
a mux with many fewer inputs, specifically adding more parameters
to the mix makes no impact on the mux size. Obviously adding
more dynamic inputs like counters will increase the mux unless
those are slow enough to add to the RAM instead.
Regards,
Gabor
Brad Smallridge
I guess I plow ahead and wait for
a timing issue.
John, I'm not sure what you mean
by a binary tree. If you mean the
outputs of muxes going into the
input of a next layer mux, then
I would suspect that the synthesizer
is already doing that.
I suppose I could explicitly write
those muxes, grouping what I think
might be the best routing.
I should probably get rid of my if,
elsif constructions to avoid any kind
of priority coding. I have seen where
the anti-if condition is routed forward
to the next if slice. A clean way of
handling the synthesis, but might make
for a long chain. That's not for the
counters but for the memory data output.
I am considering using the BRAM as Peter
suggest. The BRAM has huge nearly-free
muxing capability. But some of my data I
collect is fast and some of the data going
out to the fabric really needs to be there
all the time. I don't know what the tradeoff
between having everthing in the fabric or
having BRAM with copies of the faster items
in fabric.
Yeah Gabor, I have I2C stuff to but right now
I don't fiddle with the constants in real time.
Brad
AiVision
RCIngham
>I should probably get rid of my if,
>elsif constructions to avoid any kind
>of priority coding. I have seen where
>the anti-if condition is routed forward
>to the next if slice. A clean way of
>handling the synthesis, but might make
>for a long chain. That's not for the
>counters but for the memory data output.
For inferring multiplexers, use a 'case' statement (in VHDL - I can't
remember the equivalent Verlog syntax, and can't be bothered to look it
up!).