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

[Verilator] Split top_*_verilator into testbench and chip-level module #6103

Open
1 of 3 tasks
msfschaffner opened this issue Apr 14, 2021 · 7 comments
Open
1 of 3 tasks
Labels
Component:RTL Earlgrey-PROD Candidate Temporary label to triage issues into Earlgrey-PROD Milestones Priority:P2 Priority: medium TOP:earlgrey Type:Enhancement Feature requests, enhancements
Milestone

Comments

@msfschaffner
Copy link
Contributor

msfschaffner commented Apr 14, 2021

Split out from #5221.

  • Split the Verilator top into a Verilator chip-level module (with padring and etc.) and a separate Verilator testbench. ([top] Part one of verilator refactoring #7544)
  • Template the Verilator chip-level module
  • Re-enable Verilator JTAG DPI
@GregAC
Copy link
Contributor

GregAC commented Mar 24, 2022

@msfschaffner any idea what became of this?

@tjaychen
Copy link

the status is still the same as the last update.
We managed to split the "chip" portion from the "tb" portion, but the re-templating needed inside chiplevel.sv.top has still not been done.

@msfschaffner
Copy link
Contributor Author

@tjaychen do we want to take another stab at this? The biggest issue here is probably how the verilator TB currently handles tristate drivers. It pulls out the in/out/oe signals explicitly into the DPI, likely due to limitations in Verilator's tristate modeling. So this may cause issues with the padring, and may require to breakout more signals at the chip boundary than just the pad signals themselves.

@tjaychen
Copy link

tjaychen commented Jan 13, 2023

i was wondering about this.. it's not super clear to me how the verilator stuff is going to evolve for separate tops.
I guess my feeling was that this is closer to clean-up than a requirement, but let me know what you think. I need to examine again what other differences there are.

@a-will
Copy link
Contributor

a-will commented Jan 13, 2023

@tjaychen do we want to take another stab at this? The biggest issue here is probably how the verilator TB currently handles tristate drivers. It pulls out the in/out/oe signals explicitly into the DPI, likely due to limitations in Verilator's tristate modeling. So this may cause issues with the padring, and may require to breakout more signals at the chip boundary than just the pad signals themselves.

We may want to take another look at Verilator's capabilities in more recent versions as well. Antmicro has been bringing a lot of enhancements. :)

@msfschaffner
Copy link
Contributor Author

Ok then P3 sounds right then. I'll unassign us for now, since we are not actively working on it.

@msfschaffner
Copy link
Contributor Author

We potentially want to align the verilator TB for PROD to ease SW development.

@msfschaffner msfschaffner added the Earlgrey-PROD Candidate Temporary label to triage issues into Earlgrey-PROD Milestones label Oct 6, 2023
@moidx moidx modified the milestones: Earlgrey-PROD.M5, Backlog Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:RTL Earlgrey-PROD Candidate Temporary label to triage issues into Earlgrey-PROD Milestones Priority:P2 Priority: medium TOP:earlgrey Type:Enhancement Feature requests, enhancements
Projects
None yet
Development

No branches or pull requests

7 participants