Open oharboe opened 3 weeks ago
With https://github.com/parallaxsw/OpenSTA/pull/11 we could get source annotations back to RTL from yosys but that would be limited to things that are annotated (usually registers not every gate). Is that preferable to gate-level?
With parallaxsw/OpenSTA#11 we could get source annotations back to RTL from yosys but that would be limited to things that are annotated (usually registers not every gate). Is that preferable to gate-level?
Any way to navigate back to the original source is most helpful and I'll take what I can get over what isn't doable...
That said, when looking at fMax issues, I generally look at the register to register paths, so navigating back to the input source code to Yosys would be most helpful, yes.
You should note that we will navigate back to the always statement. If you put a wrapper around your register then all instances will map to the same line. It is not a "call stack" for the instance. Just trying to avoid expectation surprises.
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2043 enables src attributes in yosys towards this end.
I've done preparatory work in ORFS & odb (see PRs above) so it should just be a GUI issue now.
@maliberty @oharboe I'm a bit confused to where we'd see the Verilog. Would the idea be to read the verilog in the GUI? We could have another widget for displaying verilog text for this navigation case, but perhaps that's not the intention.
@maliberty @oharboe I'm a bit confused to where we'd see the Verilog. Would the idea be to read the verilog in the GUI? We could have another widget for displaying verilog text for this navigation case, but perhaps that's not the intention.
I would like to go to the verilog in vscode.
The GUI could show the line number and right click to "open with" and choose app based upon OS conventions?
Some googling suggests QDesktopServices::openUrl(QUrl::fromLocalFile("<path_to_your_file>"));
but I haven't actually tried it. Getting it to go to a specific line is likely very application specific and won't work through such a general mechanism (I am glad to be proven wrong).
The other option is to just pop up a Qt window with the code.
#include <QApplication>
#include <QPushButton>
#include <QProcess>
#include <QString>
void openVSCode(const QString &filePath, int lineNumber) {
QProcess process;
QString program = "code";
QStringList arguments;
// Add the file path argument
arguments << filePath;
// Add the line number argument
arguments << QString("--goto") << QString("%1:%2").arg(filePath).arg(lineNumber);
// Start the process
process.startDetached(program, arguments);
}
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
QPushButton button("Open VSCode on a Specific Line");
QObject::connect(&button, &QPushButton::clicked, []() {
QString filePath = "/path/to/your/file.txt"; // Replace with your file path
int lineNumber = 10; // Replace with your desired line number
openVSCode(filePath, lineNumber);
});
button.show();
return app.exec();
}
Easy, but not terribly generic...
yeah not really a solution
How about something like a user envar to configure the viewer. For example setenv VIEWER "vscode -goto <FILE>:<LINE>"
where we sub <FILE>
and <LINE>
at runtime
Then you could use it with vscode/vim/emacs/whatever
How about something like a user envar to configure the viewer. For example
setenv VIEWER "vscode -goto <FILE>:<LINE>"
where we sub<FILE>
and<LINE>
at runtime
I think mixing environment variables and the GUI in this way is a recipie for this feature never being used.
Can you pop up a requester with a proposed string in the GUI to choose editor + syntax and "do not show this again" with some reasonable way to revise it from within the GUI?
Then you could use it with vscode/vim/emacs/whatever
It seems simpler to just open it in a Qt window. This seems like a lot of extra complication and will generate lots of user confusion.
It seems simpler to just open it in a Qt window. This seems like a lot of extra complication and will generate lots of user confusion.
It solves one problem and creates another. As soon as I have opened the Verilog, I want to navigate and the user will be more familiar with his editor than Qt.
Both?
Also, be able to copy the path to clipboard.
I think a minimal version that leaves room for future improvement is to present all the information in the GUI and allow copying the path to clipboard.
Is vscode -goto <FILE>:<LINE>
something that could be set in the GUI and then stored in the .openroad file?
Where would the user go to set it? Putting it in the timing report settings seems odd (also the inspector would want it) but we don't have a general settings area (we could start one but with just one setting?). Please describe how you envision the GUI use model.
Yeah, it would be the start of a general settings popup window. Not sure if that's the direction you want to take, but it might be the best method.
Another quicker (but less visible) option might be to create a Tcl command like gui::set_code_editor_string "STRING"
I would give that about the same chances as an env var w.r.t. how many would then use the feature... Few...
@oharboe I think it might be more generally useful if a right click went to the inspector for the instance and the inspector had line info that could be clicked to go the Verilog source. There are other attributes of the instance that might be interesting.
I would view general settings as a menu choice rather than a pop-up as it is in most programs. If external viewing is important than we can start down that road. I suspect many people won't notice that option either but perhaps for them a simple Qt window will suffice.
Description
I find myself doing this manual navigation a lot:
Ideally I could go from synthesized Verilog back to the Verilog source code too, but meanwhile navigating to the synthesized Verilog would be great.
Suggested Solution
Right click -> go to -> Verilog -> opens Verilog and navigates to file.
Right click -> go to -> instance shows:
If I could look up the instance, that would help too, because then I can see the input and outputs in OpenROAD directly.
Additional Context
No response