Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HW] Start of high imedence operations and types #8134

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

darthscsi
Copy link
Contributor

Separate high impedence from the rest of the system. This will lead to a great simplification of inout and hw.

@darthscsi darthscsi marked this pull request as ready for review January 31, 2025 17:37
Copy link
Contributor

@fzi-hielscher fzi-hielscher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

I'd also suggest adding HiZType to the list of movable declarations in PrepareForEmission.cpp:568. Otherwise I expect crashes for non-dominated uses of hw.hiZ.create.

wrapper and read and conditional drive operations. Not having implicit `z` in
the normal types seen by most of the system greatly simplifies semantics.

HiZ types may only be inputs to modules.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be a little confusing. Maybe add a clarification that this only refers to the SSA value flow and HiZ implicitly produces a bidirectional port?

: HWOp<"hiZ.create", [DeclareOpInterfaceMethods<OpAsmOpInterface, ["getAsmResultNames"]>]> {
let summary = "Create a new HiZ bus";
let description = [{
High impedance busses must come from somewhere. Thw two options are as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
High impedance busses must come from somewhere. Thw two options are as
High impedance busses must come from somewhere. The two options are as

Comment on lines +1133 to +1134
for (auto t : type.getPorts())
if (t.dir != ModulePort::Direction::Input && isa<HiZType>(type))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for (auto t : type.getPorts())
if (t.dir != ModulePort::Direction::Input && isa<HiZType>(type))
for (auto p : type.getPorts())
if (p.dir != ModulePort::Direction::Input && isa<HiZType>(p.type))

@@ -390,6 +390,38 @@ hw.module @SimpleConstPrintReset(in %clock: i1, in %reset: i1, in %in4: i4) {

}

// CHECK-LABEL: module HIZ
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// CHECK-LABEL: module HIZ
// CHECK-LABEL: module HIZC

to drive the bus. This behavior is resolved by simulation or physics.
}];

let arguments = (ins HiZType:$input, HWValueType: $value, I1:$cond);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my experience, most tristate busses (QSPI, I2C, GPIO, etc.) will need independent direction control for each bit. Could we give $cond the same type as $value? This would make verilog lowering more complex though.
Alternatively, if we had some way of concatenating HiZ types, we also would not have to plumb all lines out individually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants