# Programmable Priority Encoder

1. ## Re: Programmable Priority Encoder

- - - Updated - - -

Originally Posted by vGoodtimes
ah, ok. I see what the project was.

I think this project was to show this masking idea. I hadn't seen it before but it makes sense.

There are four ppe's that could be compared. There is the one from the book -- that has two mask and two priority encoders and a mux on the output. There is also a version that has N priority encoders and an output mux. There is also this barrel shifter version that allows a single encoder. There is also a version that does the masks and then determines which mask would be best and then has a mux on the input. Because the book mentions two options -- the one that is depicted with a diagram and a version that has N priority encoders and a mux -- I suggest you focus on these two. This will let you post the results and conclusions reached in the book.

2. ## Re: Programmable Priority Encoder

A solution not in that book might be to apply the preferred mask to the input. Then to check to see if the preferred portion has any 1's set using the or-reduce. Then have a mux to select the correct input to the priority encoder.

For example, if the highest priority is bit 5, with bit 4 having lower priority, then having any bits set in [5:0] means there is no reason to check [31:6] for a 32b design. If 5:0 has no bits set, the priority encoder can use the original input. otherwise it uses the masked input.

This is an easy change to the design that follows the solutions found in the book.

•

3. ## Re: Programmable Priority Encoder

Originally Posted by vGoodtimes
A solution not in that book might be to apply the preferred mask to the input. Then to check to see if the preferred portion has any 1's set using the or-reduce. Then have a mux to select the correct input to the priority encoder.

For example, if the highest priority is bit 5, with bit 4 having lower priority, then having any bits set in [5:0] means there is no reason to check [31:6] for a 32b design. If 5:0 has no bits set, the priority encoder can use the original input. otherwise it uses the masked input.

This is an easy change to the design that follows the solutions found in the book.

I have made this too.You mentioned once about making a ppe with the use of ( rotate + priority encoder + adder)...Can you post any picture related to it which explains its working or can you explain its working..?

•

4. ## Re: Programmable Priority Encoder

I hadn't thought of the method from that book. the adder is used as part of the priority encoder. The original post made it seem that the problem was mostly about constructing a priority encoder.

If you have a priority encoder already, a programable version could have a barrel shifter for the inputs. That would use a lot of area though. The index generated by the priority encoder would be off by some amount and would be added back in.

This doesn't scale very well but might edge out the book's two priority encoder version for small numbers of inputs.

5. ## Re: Programmable Priority Encoder

.ok...My teacher is saying that the model that uses n priority encoders is not an efficient one..if I make the basic priority encoders used in it with some other methodology it might help..

- - - Updated - - -

.ok...My teacher is saying that the model that uses n priority encoders is not an efficient one..if I make the basic priority encoders used in it with some other methodology it might help..Can you suggest a way to make priority encoders which uses less area and with less delay.. like with the help of muxes or adders etc?

•

6. ## Re: Programmable Priority Encoder

This might be worse than a design that uses N priority encoders really. While you still clearly don't understand what I'm describing, it doesn't really matter as the book poses a better solution.

The original question didn't make it clear that "priority encoder" was one of the primitives that could effectively be written with behavioral modelling and that the structural part was the input/output modifications. As a result, my responses were focused on a generic structural coding of a priority encoder. The priority encoder that is based on an adder is one method that I know of that can do this. The goal is to use a trick to convert the arbitrary input to the priority encoder into a one hot input suitable for a simple encoder. From there, the logic for a simple encoder is the vector-and + or-reduce which can be constructed in a structural manner if needed, or with basic operators. But again, it sounds like "priority encoder" is being treated as a primitive /wrt this problem. You should ask your professor if the implementation of the generic priority encoder can be a behavioral implementation. Or maybe your book has an interesting example that shows a generic priority encoder and you should use that.

Also, saying N encoders is inefficient is not accurate. It is not area efficient. If N is small and the circuit needs to be fast, it is possible that the N encoder design would be justified. Likewise if N is small and area isn't a concern, N encoders could be justified as it is easier to write/verify.

--edit: the design of a priority encoder that needs to be generic and coded in a structural style and can't use codegen isn't a problem that should ever come up in a non-academic setting. If you need such an implementation, i'd go for the adder trick (-x) and (x) to convert the arbitrary input into a one-hot input. From there, you can use the vector-and followed by or-reduce, or you can do some generate tricks. I suspect this is not what the professor is looking for though, as the generic coding requires a fairly good understanding of Verilog/VHDL while also not aiding in teaching the core concept. It also is likely that the inappropriate coding style results in a worse design compared to the behavioral version.

7. ## Re: Programmable Priority Encoder

Yeah..for small no. of inputs using n encoders is a fair design..But the problem is that for each priority encoder we will have to write a separate module in verilog . As you said that The original question didn't make it clear that "priority encoder" was one of the primitives that could effectively be written with behavioral modelling and that the structural part was the input/output modifications....So LET ME MAKE IT CLEAR ..IT IS INDEED WHAT YOU THINK.. that "priority encoder" IS one of the primitives that CAN BE effectively written with behavioral modelling and that the structural part was the input/output modifications..ALSO THE THING YOU'RE MENTIONING THAT WE HAVE TO CONVERT THE INPUT into one hot ...using -x and +x followed by or reduce isn't clear..If you could elaborate it with an example or a code...I know you explained it earlier but I wasn't able to understand it..

8. ## Re: Programmable Priority Encoder

Ok, so a bad idea would be to have a barrel shifter -- something that is easy to write structurally -- modify the input to a priority encoder -- something that is a dumb thing to write structurally -- in order to write a programable priority encoder -- a circuit that never comes up ever -- ever -- ever -- except in books or cases where N=2 and special cases dominate. I LOVE YOUR ALL CAPS SHAMING ME FOR NOT HAVING READ YOUR TEACHER'S 4-TOTE'S FAV BOOK.

--edit: By this I don't mean that I feel I'm bad at expressing ideas. I mean you are bad at understanding ideas. I feel that I proposed a half wonderful half terrible solution to your problem and you will always be unable to understand either part. I feel bad for trying to help you at this point. Perhaps you should ask your professor for help or post questions that don't make you seem like a freeloader.

•

9. ## Re: Programmable Priority Encoder

I deeply apologize if unknowingly I have offended you..The caps didn't mean to shame you..I really appreciate all the help you have provided me during these months . I think I don't possess the knowledge to encapsulate your ideas at this moment. Indeed you aren't bad at expressing ideas but I am bad at understanding them. Thanks for bearing with me. I never needed the code or something I just couldn't come up with a different idea to make a ppe and just thought If I could get that idea here...Thanks again Sir!!

10. ## Re: Programmable Priority Encoder

But this will only give 1 in rightmost position of the input . And the select lines will only give the index of that bit then how the user will select which input has got highest priority ? And how the output would come from it.!

11. ## Re: Programmable Priority Encoder

Ok, maybe that was a bit harsh on my part. The problem you posted was about a fully structural, generic, programmable priority encoder. The priority encoder part of this problem isn't something that is easy to do in a way that is both generic and structural. However, a simple encoder -- one where the input has at most one bit set is something that can be described in a structural manner.

Using the (-x) and (x) trick converts a dense input into a one-hot input with the rightmost bit set. This allows a priority encoder to be described in a structural manner by using this trick followed by a simple encoder.

At this point you have a priority encoder. You can now use any method to address the programable part. You can have the books 2-encoder solution, a slightly deeper version that detects which encoder could have the solution and muxes that to the input, a version with N encoders, a version with a barrel shifter and then an encoder, possibly even some other solutions. The (-x) and (x) trick is only relevant to creating a generic and structural priority encoder.

1 members found this post helpful.

12. ## Re: Programmable Priority Encoder

Finally I have made another ppe with different logic...and funtionally verified it too.. And its really simple...we just need a left rotator (barrel shifter) and simple priority encoder followed be a really simple logic...Have you heard or read about any ppe with same methodology or design??.Moreover..Thanks for the help you provided me throughout these months..

--[[ ]]--