Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> 
> The use case that I really want to push with the intbv is that of
> the VHDL constrained integer type. My goal is that designers forget
> about signed/unsigned for numeric operations.
> 
> For example, when you need a counter that has to count from -1 to 5,
> I hope that people will construct it as
>      intbv(0, min=-1, max=6)
> and not as
>      intbv(0, min=-8, max=8)
> 
> Why? Because I believe such constraints give you the best assertions that
> you'll ever have. My counters usually don't count between powers of 2, but
> in my code I systematically make bound errors. The first construction gives
> you instant run-time feedback about the error, the second may not.
> 
...
> 
> The proposals I'm seeing do something else: they change the value of
> the operand based on the nature of the assignment target. That is much
> more tricky and implicit. 

...
> 
> Of course, you could make things more sophisticated by only doing
> sign-extension if the bit width of rhs and lhs are equal. But this
> is getting a little too tricky for my taste.

I see you point and agree that adding this feature to intbv looks like 
to specific.

Now that brings me back to think about the idea of an extra function 
based on concat() that is convertible with toVerilog/VHDL. That would 
not add extra code to intbv, but would allow to create an intbv instance 
with bit slices and allow to manipulate the sign.

So what about having a function like:

   concatSigned(sign, slice1, [slice2, ...[sliceN]..])

It will return an intbv by concatenating the slice(s) and setting the 
sign based on the specified sign.

The toVerilog/VHDL converter would then be able to map that direct to a 
concatenation of bits with the result being of type signed().

Guenter