-
Notifications
You must be signed in to change notification settings - Fork 18
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
Active path and FSM #59
base: master
Are you sure you want to change the base?
Active path and FSM #59
Conversation
Add to set if a component as active path, active finite state machine(fsm) for this state or the component was active fsm Add also to check if a component is active path, active finite state machine(fsm) for this state or the component was active fsm
If a port is on the active path or FSM then it will set the colour of the port
The changes of active path will not affect RISCV processors
getText rerurn the label of the port
Add methods for component for active path and active fsm
Set colour the component if it is active without affect RISCV processors
I reuploaded it. I removed the comments and it is qt6. Also it is working fine with the Ripes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two fundamental issues with this PR:
- You're adding VSRTL Graphics related stuff into the VSRTL core library. VSRTL core is fully isolated from VSRTL graphics - deliberately. Core is strictly a simulation library, that exposes hooks which core then uses to inspect the circuit and create a visualization of it. The point of
vsrtl_interface.h
is to define the interface that a simulation backend must adhere to such that VSRTL graphics can work with it. The design descision for this is based on the fact that you in theory could bring any simulation backend (or HDL language) and implement the VSRTL interface, and then the graphics library can work with it. - You're adding implementation-specific logic into the library. That is, you have logic which explicitly has been written for your processor model inside the framework - this is obviously a no go. It would be similar to writing a program in a programming language, and you then trying to get your program logic into the programming language itself :).
I understand that these might be big changes that you have to make to your PR, but it's important to recognize that the framework was designed this way for a reason. Whatever changes you make to VSRTL must not have anything specific to do with your processor model/whatever you're using VSRTL for. If you do find that VSRTL is lacking in capability, then it is fine to submit a PR to fix that, but then recognize that whatever change that you make to VSRTL has to be a generic change that applies to all circuit simulations one may want to visualize using VSRTL.
So is it better to upload the PRs on Ripes mortbopet/Ripes#290 without my VSRTL changes and then add them? |
Before considering PRs into either repository you need to address the above comments.
I cannot stress this enough. Whereever you have non-generic code inside VSRTL this is an indication that you need to change that code. VSRTL is a framework and thus implementation-specific logic should not be anywhere within the framework. And the same goes with an eventual Ripes PR. If you study the current Ripes codebase you will see that ISA-specific information is only found in two places:
So similarly, wherever your code does not follow this pattern means that you'll have to refactor it. |
Okay. First I will try to reimplement it outside the VSRTL. I think I tried it again on the past but I will try again. |
Do you want first to upload my PRs on Ripes without the VSRTL changes? |
Correct!
If you have small, atomic, PRs which do not depend on the changes in VSRTL, and represent incremental improvements to Ripes, then by all means, go ahead and submit those PRs! :) |
Yes I have small PRs ready to upload but I have some tests that fail because it is for different ISA. I mentioned exact the prblem here: mortbopet/Ripes#290 |
No description provided.