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

Efficient backtracking from output ports to input ports #3975

Closed
mysoreanoop opened this issue Jun 24, 2024 · 4 comments
Closed

Efficient backtracking from output ports to input ports #3975

mysoreanoop opened this issue Jun 24, 2024 · 4 comments

Comments

@mysoreanoop
Copy link

I'm trying to backtrack output ports from the topModule this way:
1a. Parse all continuous and procedural assignments.
1b. For each assignment, populate an lhs2rhs map (vpiFullName is used as unique ID).
2. Parse all submodule instances for IOs: form a lowConn to highConn map called io2net map.
3. Starting at the topModule, get the ports, vpiDirection, and if it's an output port:
4a. Search lhs2rhs, io2net map:
4b. If found, recurse to 4a
4c. Else if topModule's input port is reached, end.
4d. Else if constant or parameter, end.
4e. Else mapping not found / other cases.

Is there a more efficient way to do this without having to parse all assignments and submodule IOs?
Specifically, given a vpiHandle to an output port, could I get all the sources of that port/net and keep doing that recursively?
Would procedural assignments with if-else branches complicate things?

@alaindargelas
Copy link
Collaborator

@mysoreanoop do you intent to contribute your code to main? (Hint: If you don't, no help :-))
If you intend to, then it should be a new utility class in UHDM. Let me know, and I'll help you to shape it so it more generic.

@mysoreanoop
Copy link
Author

I'd be happy to contribute back. I can get started with a preliminary PR and we can build on it, or I can develop on it separately and pull when ready; your call.

@Thomasb81
Copy link
Collaborator

Hello

Is it a step forward to solve : chipsalliance/UHDM#1037
Or a different feature ?

@alaindargelas
Copy link
Collaborator

@Thomasb81, It is indeed a step toward: chipsalliance/UHDM#1037
@mysoreanoop, PRs and this discussions should move to the UHDM repo, switching to:
chipsalliance/UHDM#1078

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

No branches or pull requests

3 participants