Please pardon me if this is a very stupid question. My Verilog
is rusty. Could some Verilog guru please explain what the
following means ? I have seen it before, and it seems very
complicated. Does it mean that if sum[25] == true, normalshift is
assigned 0, and so on down the chain.
Thanks for your help.
Daku <dakup...@gmail.com> wrote:
> Please pardon me if this is a very stupid question. My Verilog
> is rusty. Could some Verilog guru please explain what the
> following means ? I have seen it before, and it seems very
> complicated. Does it mean that if sum[25] == true, normalshift is
> assigned 0, and so on down the chain.
> Thanks for your help.
> assign normalshift =
> sum[25] ? 0 :
> sum[24] ? 1 :
> sum[23] ? 2 :
(snip)
This is the conditional operator that came from C. (At least that
is where I first knew it in this form.)
So, yes, if sum[25] is true the value is zero (the left side of the : ),
otherwise it has the value of the expression on the right side of the :.
Whether that is a good way to implement a priority encoder, I don't
know.
The logic, as written, would be very slow, propagating all the way
through in the low sum[], high return value cases. The tools are very
good at optimizing much logic, and reasonably likely this one, too.
>> Please pardon me if this is a very stupid question. My Verilog
>> is rusty. Could some Verilog guru please explain what the
>> following means ? I have seen it before, and it seems very
>> complicated. Does it mean that if sum[25] == true, normalshift is
>> assigned 0, and so on down the chain.
>> Thanks for your help.
> This is the conditional operator that came from C. (At least that
> is where I first knew it in this form.)
> So, yes, if sum[25] is true the value is zero (the left side of the : ),
> otherwise it has the value of the expression on the right side of the :.
> Whether that is a good way to implement a priority encoder, I don't
> know.
> The logic, as written, would be very slow, propagating all the way
> through in the low sum[], high return value cases. The tools are very
> good at optimizing much logic, and reasonably likely this one, too.
> Even so, I probably wouldn't write it this way.
> -- glen
Because the ? operator can be used in a continuous assignment it is
often used to generate multiplexers and encoders. The alternative
is to use a reg instead of a wire, and then in an always @* block
use a case statement. Normally I would not use the ? operator
for building very large encoders or multiplexers, however it is likely
that the synthesis tool will build the same hardware as if you
used a reg and a case statement.
I think this is more a matter of style than substance. Some people
like to keep combinatorial equations in continuous assigns rather
than using always @*, and may go to extreme lengths to make it happen
as you can see here. Still, once you know how it works, the code
is readable enough, I guess...
