Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
83 lines (57 sloc) 3.07 KB

How to contribute to Verilator

Thanks for using Verilator! We welcome your contributions in whatever form.

This contributing document contains some suggestions that may make contributions flow more efficiently.

Did you find a bug?

  • Please Ensure the bug was not already reported by searching Verilator Issues.

  • If you’re unable to find an open issue addressing the problem, open a new issue.

    • Be sure to include a code sample or an executable test case demonstrating the bug and expected behavior that is not occurring.

    • The ideal example works against other simulators, and is in the test_regress/t test format, as described in docs/internals.

Did you write a patch that fixes a bug?

  • Please Open a new issue.

  • You may attach a patch to the issue, or (preferred) may point to a GitHub repository branch within your GitHub account.

    • Verilator uses Travis CI to provide continuous integration. You may want to setup Travis CI on your GitHub branch to ensure your changes keep the tests passing. See docs/internals.

  • Your source-code contributions must be certified as open source, under the Developer Certificate of Origin. On your first contribution, you must either:

    • Have your patch include the addition of your name to docs/CONTRIBUTORS (preferred).

    • Use "git -s" as part of your commit. This adds a "signed-of-by" attribute which will certify your contribution as described in the Signed-of-By convention.

    • Email, or post in an issue a statement that you certify your contributions.

    • In any of these cases your name will be added to docs/CONTRIBUTORS and you are agreeing all future contributions are also certified.

    • We occasionally accept contributions where people do not want their name published. Please email us; you must still certify your contribution using email.

  • Your test contributions are generally considered released into the public domain, unless you request otherwise or put a GNU/Artistic license on your test file.

  • Most important is we get your patch. If you’d like to clean up indentation and related issues ahead of our feedback, that is appreciated; please see the coding conventions in docs/internals.

Do you have questions?

Code of Conduct

  • Our contributors and participants pledge to make participation in our project and our community a positive experience for everyone. We follow the Contributor Covenant version 1.4.

Thanks!

You can’t perform that action at this time.