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

Fusesoc and Linter #368

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

wallento
Copy link
Contributor

This adds support for FuseSoC. As example, it fixes the verilator model to directly use it.
But even more interesting, it adds a github action that automatically runs the linter on each push and pull request. When the linter fails, the action fails and a PR can be polished.
As a caveat, there are 421 Linter warnings on the codebase at the moment. I have added a waiver file that suppresses them, but I suggest to fix the issues or replace the placeholder comments with an explanation. Happy to help, but too many for a "quick PR".

@wallento
Copy link
Contributor Author

Here is an example for the annotations: https://github.com/wallento/riscv/actions/runs/137172924
At an PR it will put them right to the code changes.

@wallento wallento mentioned this pull request Jun 16, 2020
@wallento
Copy link
Contributor Author

From #367:

Thanks for getting the ball rolling on this @wallento. I've added a few minor comments, and have three big ones:

1. A lot of the "tb" dirs/files in this repo are slated to be removed to encoruage people to use [core-v-verif](https://github.com/openhwgroup/core-v-verif) testbenches, so we'll need to replicate some of this there.

2. tb/verilator-model/Makefile has a complete manifest embedded within it.  This is exactly what we are trying to displace.

3. Many (all?) of the RTL port map and parameter changes you suggest have been (or are being) taken care of elsewhere.

The minor things are to resolve warnings with recent GCCs.

About 2, you are right. I kept it in there for reference. If you are happy I would replace it with Makefile.fusesoc in that same folder. It does the same job. I would suggest, but didn't want to be too drastic :)
About 3, you are right, seems it slipped in there and relates to #350 that I fixed while doing it. Will look into it and amend.
Thanks!

@wallento wallento force-pushed the fusesoc-and-linter branch from 6e58444 to 457f8e0 Compare June 16, 2020 18:22
@wallento
Copy link
Contributor Author

Hi @MikeOpenHWGroup,
I have ameneded the PR. The changes of 3 are necessary to make the verilator-model run again. I believe long term it would be more useful to have a more sophisticated verilator-model as Quick Start vs. this rather simple bench and the full blown verification flow. I would be happy to contribute this as I am pretty fluent in it. I will also add a CI test to it, if you want.
I have remove the original Makefile, this change pretty much shows the power FuseSoC :)
Best,
Stefan

@wallento
Copy link
Contributor Author

I can't really understand what Github feels about that Makefile to be a conflict, seems pretty straight-forward to me..

@wallento
Copy link
Contributor Author

Ah, I see! There was a massive rename between my first PR and now :) I will amend again after rebase!

Copy link
Member

@MikeOpenHWGroup MikeOpenHWGroup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @wallento. Looks good to me. By definition I exclude myself from approving this PR (the verification people should never make-or-approve changes to the RTL). Having said that, this is the right track to be on.

@bluewww
Copy link
Contributor

bluewww commented Jun 16, 2020

PR is guaranteed to be broken with this merge #360. I believe a rebase is in order.

wallento added 4 commits June 17, 2020 07:13
This fixes compilation issues with the Verilator simulations.

Signed-off-by: Stefan Wallentowitz <[email protected]>
This adds support for FuseSoC, currently for the verilator model only.

Signed-off-by: Stefan Wallentowitz <[email protected]>
This is based on the LibreCores CI infrastructure and doesn't need
anything except this file.

Signed-off-by: Stefan Wallentowitz <[email protected]>
This silences the linter for all known warnings. That eases the
migration to a linter flow, because new linter warnings are identified
quickly.

Anyhow, I suggest to curate the waiver file by either solving the
underlying problem or replacing the comment with a meaningful
description.

Also, we can now be pedantic, linter will fail on any warning.

Signed-off-by: Stefan Wallentowitz <[email protected]>
@wallento wallento force-pushed the fusesoc-and-linter branch from 457f8e0 to 54bd9e8 Compare June 17, 2020 08:33
@wallento
Copy link
Contributor Author

Rebased and amended to match the changed naming

steps:
- name: Checkout
uses: actions/checkout@v1
- name: Lint Verilog sources with Verilator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not want any dependency on Verilator

command: 'run'
core: 'openhw:cv32e40p:core'
target: 'lint'
tool: 'verilator'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not want any dependency on Verilator

- files_rtl
lint:
<<: *default
default_tool: verilator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make sure things run without Verilator as well?

Copy link
Contributor

@Silabs-ArjanB Silabs-ArjanB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot try this out because we do not have the permissions to run pip3 install git+https://github.com/olofk/fusesoc@master

Can you please make sure this flow works for xrun and Questa as well and can run without any dependency on Verilator?

@Silabs-ArjanB
Copy link
Contributor

Hi @wallento Is there a way we can merge your pull request and also have the possibility to keep the old way of working for 1-2 weeks so that we do not immediately block many people just in case there are initial problems? How about core-v-verif, that would need to be updated as well, right?

@Silabs-ArjanB Silabs-ArjanB added the WAIVED:CV32E40P Issue does not impact a major release of CV32E40P and is waived label Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WAIVED:CV32E40P Issue does not impact a major release of CV32E40P and is waived
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants