FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 01-17-2005, 08:10 PM
Guest
 
Posts: n/a
Default 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;

Reply With Quote
  #2 (permalink)  
Old 01-17-2005, 09:04 PM
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

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

Reply With Quote
  #3 (permalink)  
Old 01-17-2005, 11:16 PM
VC
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

[email protected] 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.

Reply With Quote
  #4 (permalink)  
Old 01-18-2005, 12:50 AM
John_H
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

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?


<[email protected]> wrote in message
news:[email protected] ups.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;
>



Reply With Quote
  #5 (permalink)  
Old 01-18-2005, 05:26 AM
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

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

Reply With Quote
  #6 (permalink)  
Old 01-20-2005, 06:06 AM
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

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/paper...ase_rev1_1.pdf

Reply With Quote
  #7 (permalink)  
Old 01-20-2005, 06:22 AM
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

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

Reply With Quote
  #8 (permalink)  
Old 01-20-2005, 04:30 PM
John_H
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:

<[email protected]> wrote in message
news:[email protected] ups.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.


Reply With Quote
  #9 (permalink)  
Old 01-25-2005, 03:18 PM
Gordon Old
Guest
 
Posts: n/a
Default Re: Please help me with this odd selector design:


[email protected] 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.

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Rotating priority interupt decoder/selector Brian Guralnick Verilog 3 06-30-2004 01:07 AM


All times are GMT +1. The time now is 12:58 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved