Add new Bool type to MyHDL?

Enhancement Request
1

Hi,

While designing modules using bool signals asserted high and others asserted low, I thought it could be a good idea to create a new Bool() type where the polarity is internally managed. Like with ResetSignal().

For example, using the Flexbus (parallel bus) of a microcontroller, there is ALE (Address Latch Enable) which is asserted high and CS and OE that are asserted low.

These signals could be instantiated like this :

ale = Signal(Bool(init_value=False, asserted_high=True))
cs  = Signal(Bool(init_value=False, asserted_high=False))
oe  = Signal(Bool(init_value=False, asserted_high=False))

Testing would be :

    if ale :
        # do something
    if cs :
        # do something else

Asserting would be :

    ale.next = True
    cs.next  = True

De-asserting would be :

    ale.next = False
    cs.next  = False

What do you think of this proposition ?

2

I don’t think we need this.
And I am sure I wouldn’t use it. I treat all internal signals active high and if necessary change the polarity at the top level. Most of the time, it doesn’t always hold …

1 Like
3

Adding an inverter adds one level of logic which modifies the timings. Most often, this is not a problem. Most often…

4

The vendor tool will take care of that. It will optimize that inverter into the input or output block or into the next register.

5

Yes. Most often…

6

99.9 % will do? IMO asynchronous buses like you describe should not suffer from that 1 extra level of logic, if ever this is not optimized away. Wait, the Flexbus is actually synchronous, however the above still applies.

7

Flexbus is synchronous but very sensitive to logic delays.

8

However, I’m not trying to forcibly convince you to adopt my proposition.
I expose an idea I had.
We have ResetSignals which can be active high or active low. Why not have the same behavior for booleans ?

9

And I gave my opinion about it.

I think the proposed Bool() will have serious impact on simulation and conversion.
The ResetSignal() is specifically aimed at decoupling the design from the actual physical implementation, making life easy. Its implementation is relatively simple as it is an input only signal (at least I have never seen it at the LHS).
Now you may say that the proposed Bool() will make life easy too. You may be very well right, and I just don’t see the light … (yet). In fact you may use my argument of keeping everything internal active high against me.
If you do proceed, can you make sure that statements like cs.next = 1 also work? (I never use False or True) What about tristate signals?

So you almost won me over? Or did I do that myself? :slight_smile:
Regards,
Josy

10

Correct

Totaly agree on that :wink:

Why should it be different from current bool ?

Well, tristate signals are tristate signals bools are bools (from MyHDL perspective).

:smile: