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

Analyzer: Generic Wishbone Device Analyzer #1427

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

Conversation

drewrisinger
Copy link
Contributor

ARTIQ Pull Request

Description of Changes

Adds a generic Wishbone device handler for unknown or out-of-tree Wishbone/RTIO devices.

Type of Changes

Type
✨ New feature

Steps (Choose relevant, delete irrelevant before submitting)

All Pull Requests

  • Use correct spelling and grammar.
  • Update RELEASE_NOTES.md if there are noteworthy changes, especially if there are changes to existing APIs.
  • Close/update issues.
  • Check the copyright situation of your changes and sign off your patches (git commit --signoff, see copyright).

Code Changes

  • Run flake8 to check code style (follow PEP-8 style). flake8 has issues with parsing Migen/gateware code, ignore as necessary.
  • Test your changes or have someone test them. Mention what was tested and how.
  • Add and check docstrings and comments
  • Check, test, and update the unittests in /artiq/test/ or gateware simulations in /artiq/gateware/test

Tested on in-development PHY. Only deficiencies are listed in #TODO sections, feedback appreciated.

Documentation Changes

  • Check, test, and update the documentation in doc/. Build documentation (cd doc/manual/; make html) to ensure no errors.

Git Logistics

  • Split your contribution into logically separate changes (git rebase --interactive). Merge/squash/fixup commits that just fix or amend previous commits. Remove unintended changes & cleanup. See tutorial.
  • Write short & meaningful commit messages. Review each commit for messages (git show). Format:
    topic: description. < 50 characters total.
    
    Longer description. < 70 characters per line
    

Licensing

See copyright & licensing for more info.
ARTIQ files that do not contain a license header are copyrighted by M-Labs Limited and are licensed under LGPLv3+.

Add generic handler for Wishbone PHY devices, that will save the
bus transactions to a VCD file.

Signed-off-by: Drew Risinger <[email protected]>
Unknown RTIO channels will be converted to VCD by
GenericWishboneHandler.

Signed-off-by: Drew Risinger <[email protected]>
Formats the data properly for interpretation by VCD viewer
(on a per-channel basis).

Args:
Copy link
Member

Choose a reason for hiding this comment

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

This isn't the usual way those are formatted, see e.g.

:param channel: DAC channel to read (8 bits)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I disagree. This is a standard format recognized by Sphinx (using the standard Napoleon extension). https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html

The format you cite above I consider much more obtuse and illegible, and doesn't include type information.

Copy link
Member

Choose a reason for hiding this comment

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

I for one also prefer the numpy/napoleon style.

Copy link
Collaborator

@dnadlinger dnadlinger Mar 13, 2020

Choose a reason for hiding this comment

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

Can we just stick to :param foo: bar. in the ARTIQ code base please? This is not a statement on the relative merits of the two choices, just that uniformity decreases cognitive load. (Also, with type annotations now being a thing in the language proper, there is no need to mangle them into the docstring.)

Copy link
Member

Choose a reason for hiding this comment

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

I meant in general. I agree that consistency trumps that preference here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ack. will change.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks!

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this wasn't an argument about which style is best, but simply an argument for consistency.

If you want to change the format @drewrisinger please submit a separate issue (to discuss it) and then a PR that changes it everywhere in ARTIQ. The same goes for the type annotations that you wanted earlier (though I have some reservations about them).

)
self.set_channel("in_data", message.data)
self.set_channel("in_stb", 1)
self.set_channel("in_stb", 0)
Copy link
Member

Choose a reason for hiding this comment

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

Those strobe signals are very much an artifact of hardware implementations.
For visualizing transactions from a higher level, maybe use a single VCD channel for the bus and write a string there (similar to your log message) whenever there is a transaction?
You can find code in Migen (commit 1caf61d5e44dbb60491574bf31601cd080d09ad0) to write strings to VCDs, used in FSMs.

@jordens jordens removed their request for review July 19, 2021 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants