Skip to content
This repository was archived by the owner on Apr 7, 2026. It is now read-only.

feat(components): add invert support to mcu component#179

Open
WangHaoZhengMing wants to merge 3 commits intol0uisgrange:mainfrom
WangHaoZhengMing:main
Open

feat(components): add invert support to mcu component#179
WangHaoZhengMing wants to merge 3 commits intol0uisgrange:mainfrom
WangHaoZhengMing:main

Conversation

@WangHaoZhengMing
Copy link
Copy Markdown

  • Added an invert parameter and invert-radius style support to stub, allowing it to render an inverting circle for active-low representations.
  • Updated MCU test vectors (tests/mcu/test.typ) to utilize the new invert feature in mcu, demonstrating how to draw an active-low 74LS138 IC.
  • Updated reference test images for the mcu component.
  • Updated docs
image

- Added an `invert` parameter and `invert-radius` style support to `stub`, allowing it to render an inverting circle for active-low representations.
- Updated MCU test vectors (`tests/mcu/test.typ`) to utilize the new invert feature in mcu, demonstrating how to draw an active-low 74LS138 IC.
- Updated reference test images for the mcu component.
- Updated docs
@l0uisgrange
Copy link
Copy Markdown
Owner

l0uisgrange commented Mar 22, 2026

Hey @WangHaoZhengMing 👋,

Thank you for the feature 🫶! If you have more time, would it be possible to also bring support for the arrow inverter? Here's an example.

image

This is already implemented in the logic symbols if you want to have a template (not, nand, etc.).

If not, I will merge this PR 😇

@WangHaoZhengMing
Copy link
Copy Markdown
Author

Ok, I will implement it as soon as possible.

@WangHaoZhengMing
Copy link
Copy Markdown
Author

Hi, I had a quick question about the use of the triangle-style arrow to represent inversion. Is there a particular reason or reference behind choosing this form?

I tried looking into common standards (like IEEE and IEC), and it seems that inversion is usually represented with a bubble (small circle). I didn’t come across the triangle form in those specifications, so I was wondering if this is more of a stylistic or DSL-driven choice.

If so, would it make sense in the future to separate the inversion semantics from the visual style (e.g., allowing both triangle and bubble as rendering options)? Just curious about your design considerations here.

@l0uisgrange
Copy link
Copy Markdown
Owner

l0uisgrange commented Mar 22, 2026

Hey, no worries I had the same question in #182.

I found this article this morning that states:

Inputs, Outputs and Polarity Indicators
Symbols can include bubbles or wedges at inputs or outputs to indicate logic negation. A bubble marks an inversion (logic 0 becomes 1 and vice versa). For example, the NOT (inverter) symbol is a triangle with a bubble on its output. The bubble must be accompanied by a statement specifying the logic convention (whether a high voltage represents 1 or 0). A wedge indicates an active‑low input or output without requiring a uniform convention. Polarity indicators help clarify whether a gate is drawn in positive or negative logic and are essential for understanding De Morgan equivalents.

Therefore, since it seems to have different meaning, it shouldn't be on the styling system.
Imo the default should be the bubble (when invert: true), but option to change to invert: wedge).

The wedge seems to be used in specific cases, but most of the time the bubble is the correct one.

@WangHaoZhengMing
Copy link
Copy Markdown
Author

Hi, i have impled the wedge for stub, here are the example:
image

// Test wedge symbol (active-low) in all directions
#test({
    import lib: *
    let p = (
        (content: "1", side: "west"),
        (content: "2", side: "west"),
        (content: "3", side: "west"),
        (content: "4", side: "west"),
        (content: "5", side: "east"),
        (content: "6", side: "east"),
        (content: "7", side: "east"),
        (content: "8", side: "east"),
    )
    
    mcu("u1", (0, 0), pins: p, width: 2)
    wstub("u1.pin1", label: $overline(W)_1$, invert: "wedge")
    wstub("u1.pin2", label: $overline(W)_2$, invert: "wedge")
    wstub("u1.pin3", label: $overline(W)_3$, invert: "wedge")
    wstub("u1.pin4", label: $overline(W)_4$, invert: "wedge")

    estub("u1.pin5", label: $overline(E)_1$, invert: "wedge")
    estub("u1.pin6", label: $overline(E)_2$, invert: "wedge")
    estub("u1.pin7", label: $overline(E)_3$, invert: true)
    estub("u1.pin8", label: $overline(E)_4$, invert: "wedge")
})

and I am not sure if it is what you want.so i just ask you before i PR

@l0uisgrange
Copy link
Copy Markdown
Owner

l0uisgrange commented Mar 24, 2026

It it correct, thanks!
Could you use the already existing wedge style from logic, just so it has the same dimensions everywhere to look consistent. If it looks weird don't change and I will merge, no worries.

Oh, and could you also format your code and fix the checks please (check the CONTRIBUTING.md if needed)? 😇

@WangHaoZhengMing
Copy link
Copy Markdown
Author

Got it! I'll sync up the wedge styling with the existing logic and run the formatting/linting fixes.

@WangHaoZhengMing
Copy link
Copy Markdown
Author

image

And I also add this in styles.typ

    // Components
    stub: (
        scale: auto,
        length: .8,
        invert-width: 0.15,
        invert-height: 0.12,
    ),

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants