Please help me with this odd selector design:

Consider the case below. I have a list of 8 bit values and the enable
vector that indicates which values are valid. Unfortunately, more then
one value
can become valid. One way I can solve this problem is by using
priority decoder shown in the code snippet below, but it is 16 level
decode which will
kill my timing. Can anyone think of more efficient way of doing this?

Thank you very much!!!!

// start of pseudo-code
wire [7:0] val_in_0, val_in_1, val_in_2, val_in_3, ....... ,
val_in_15;
wire [15:0] val_valid[15:0]; // one or more bits can be set
wire [7:0] val_out[7:0]

always @ *
if (val_valid[0])
val_out = val_in_0;
else if (number_valid[1])
val_out = val_in_1;
else if (number_valid[2])
val_out = val_in_2;
..
..
..
..
else if (number_valid[15])
val_out = val_in_15;
else
val_out = error;

 

Forgot to mention, I would want this to be single-cycle.

 

[VC]

evolutionx1...@yahoo.com wrote:

Forgot to mention, I would want this to be single-cycle.

Instead of the if-else structure, use a casez for coding the priorty
encoder.

 

No, as it is there is now way to avoid the priority encoder structure
with multiple levels of logic but with fpga's you might get some custom
gates with high inputs and fast response.

-Neo

 

thank you all for responses!!

As it stands right now the project is targeted as "technology
independant", that is we can't take advantage of any technology
specific hardware.

I looked up on the web and ran accross the paper that implies that
synthesis should be able to generate parallel logic when casez is used
in certain manner. See page 10 of this document:
http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase_rev1_1.pdf

 

Oops,
that document does say the synthesized logic will nfer priority, in
casez case, never mind. I guess it is impossible

 

[John_H]

<evolutionx1945@yahoo.com> wrote in message
news:1106200052.464583.24640@z14g2000cwz.googlegroups.com...

thank you all for responses!!

As it stands right now the project is targeted as "technology
independant", that is we can't take advantage of any technology
specific hardware.

[snip]

Another thought since you're not targeting a specific architecture:
Design your own priority encoder.

Rather than throwing a 16-level priority encoder to the synthesizer and
hoping it does the right thing, it might be better to split the encoder into
pieces. Since 4:1 multiplexers *should* be available in most situations as
a fast design element, assembling 4 priority encoders with 4 elements each
you'd have the inputs you'd need for a final 4 element priority encoder fed
with the outputs you generated and enabled by the 4-wide ORs of the enables
in each encoder. This tree structure should be repeatable across
technologies.

Since your priority encoder "will kill my timing" you must have an idea what
your timing is. That tool (or the scratches in the back of your napkin) may
provide better results.

 

[Gordon Old]

evolutionx1945@yahoo.com wrote:

Oops,
that document does say the synthesized logic will nfer priority, in
casez case, never mind. I guess it is impossible

Hi,

I realise your design has to be technology-independent, but there is
one
trick you might like to know. Xilinx FPGAs, and, I expect other
technologies (though you'll forgive me a preference for Xilinx!), offer
very very fast carry chain logic. This carry chain logic is meant
primarily for the ripple carry of adders, but can be put to other uses.
One of these is priority encoding. Without pictures, this is hard to
convey, but please bear with me.

Your example suggested that based on an 8 bit validity vector, one of
your input vectors will be output as the result. If we consider your
input vectors to be single bit it makes things easier (all you have to
do to get back to 16 bits wide is a FOR...GENERATE or something
similar).
In Xilinx FPGAs, the carry chain is a serial connection of primitives
elements called MUXCY. The select line of the MUXCY comes from a
primitive element called a LUT (look up table). This would be your
validity input, with the highest priority (0) being the top of the
carry
chain. The first, highest priority, input would be connected via the BY
or BX input to the slice (again, Xilinx terminology) to the left hand
input to the MUXCY (input 0) and the result of the next highest
priority
MUXCY connected via the carry chain to the right hand mux input (input
1). This is all much simpler if you have a diagram of a Configurable
Logic Block.

The speed you could expect from this arrangement will depend on the
family, speed grade, routing, etc, but we are talking several hundred
MHz.

 

[John_H]

Are you working with an FPGA? Altera? Xilinx? Lattice? ASIC?
There are ways to implement very fast priority encoders in FPGAs if that's
what you need.

If you have a limited subset of enables that could be valid at once, your
logic might not have to resort to a full priority encoder but you'd have to
structure the logic to take advantage of the limited priorities.

So, what do you really need to accomplish?


<evolutionx1945@yahoo.com> wrote in message
news:1105992616.400037.12150@z14g2000cwz.googlegroups.com...

Consider the case below. I have a list of 8 bit values and the enable
vector that indicates which values are valid. Unfortunately, more then
one value
can become valid. One way I can solve this problem is by using
priority decoder shown in the code snippet below, but it is 16 level
decode which will
kill my timing. Can anyone think of more efficient way of doing this?

Thank you very much!!!!

// start of pseudo-code
wire [7:0] val_in_0, val_in_1, val_in_2, val_in_3, ....... ,
val_in_15;
wire [15:0] val_valid[15:0]; // one or more bits can be set
wire [7:0] val_out[7:0]

always @ *
if (val_valid[0])
val_out = val_in_0;
else if (number_valid[1])
val_out = val_in_1;
else if (number_valid[2])
val_out = val_in_2;
.
.
.
.
else if (number_valid[15])
val_out = val_in_15;
else
val_out = error;