Skip to content

RFC #77: Stream port name conventions. #77

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zyp
Copy link
Contributor

@zyp zyp commented May 10, 2025

@zyp zyp force-pushed the stream-port-name-conventions branch from 80bb94d to a671a19 Compare May 10, 2025 14:41
@whitequark
Copy link
Member

Which exact names should we settle on?

  • i / o

These are the ones I've been using recently.

  • input / output

These are the ones I've been using in the past. I settled on i and o because if you need to add more streams, expanding them to i_foo and o_bar feels logical, while input_foo and output_bar too verbose and somewhat at odds with how we've been approaching core design (see e.g. lib.io).

  • w_stream / r_stream

I would say these, as well as r and w, are acceptable when there is reading and writing involved (like from/to a memory), but not in general. I'm undecided on whether I want a stream.FIFO (or whatever we call it when we land it) should use r/w or i/o. I've been using r/w in Glasgow, but then I found myself mentally mapping them to i/o anyway, at which point standardizing might make more sense.

  • sink / source

This is the one option I'm decidedly against. The names are very confusing with plenty of in-the-field feedback to that end from newcomers to LiteX. They don't shorten well (si/so perhaps, but then we're back to i/o). And they have no relation to the existing language/stdlib at all, making them an additional burden to learn. If you've used lib.wiring for a while you're probably used to how inputs become outputs when flipped, and know that flipped(self.i) is an output; now you have to learn that flipped(self.sink) is a source.

@whitequark whitequark added area:core RFC affecting APIs in amaranth-lang/amaranth meta:nominated Nominated for discussion on the next relevant meeting labels May 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:core RFC affecting APIs in amaranth-lang/amaranth meta:nominated Nominated for discussion on the next relevant meeting
Development

Successfully merging this pull request may close these issues.

2 participants