The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.41k stars 494 forks source link

Right click in timing report, go to verilog line #5189

Open oharboe opened 3 weeks ago

oharboe commented 3 weeks ago

Description

I find myself doing this manual navigation a lot:

image

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:

image

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

maliberty commented 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?

oharboe commented 3 weeks ago

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.

maliberty commented 2 weeks ago

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.

maliberty commented 2 weeks ago

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2043 enables src attributes in yosys towards this end.

maliberty commented 2 weeks ago

5216 converts verilog attributes to odb ones to enable the GUI work

maliberty commented 2 weeks ago

I've done preparatory work in ORFS & odb (see PRs above) so it should just be a GUI issue now.

AcKoucher commented 6 days ago

@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.

oharboe commented 6 days ago

@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?

maliberty commented 6 days ago

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.

oharboe commented 6 days ago

#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();
}
oharboe commented 6 days ago

Easy, but not terribly generic...

maliberty commented 6 days ago

yeah not really a solution

maliberty commented 5 days ago

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

oharboe commented 5 days ago

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

maliberty commented 4 days ago

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.

oharboe commented 4 days ago

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.

oharboe commented 4 days ago

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.

rovinski commented 3 days ago

Is vscode -goto <FILE>:<LINE> something that could be set in the GUI and then stored in the .openroad file?

maliberty commented 2 days ago

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.

rovinski commented 1 day ago

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"

oharboe commented 1 day ago

I would give that about the same chances as an env var w.r.t. how many would then use the feature... Few...

maliberty commented 1 day ago

@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.