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

FIFO Metadata Specification #1391

Open
grebe opened this issue Apr 23, 2024 · 0 comments
Open

FIFO Metadata Specification #1391

grebe opened this issue Apr 23, 2024 · 0 comments
Labels
codegen Related to emitting (System)Verilog. dslx DSLX (domain specific language) implementation / front-end enhancement New feature or request ir stitching Issues related to stitching, multi-proc codegen, and integration with external verilog modules

Comments

@grebe
Copy link
Collaborator

grebe commented Apr 23, 2024

Currently, the FifoConfig construct has fields for fifo depth and bypass. Bypass, which is not carefully specified, may imply combinational coupling between push- and pop-side signals. The combinational coupling between signals should be specified in greater detail.

The only mechanism we have in DSLX to specify FIFO metadata is an undocumented feature where you optional include the fifo depth in the channel declaration, e.g. chan<some_type, fifo_depth>(...). This feature should be documented and perhaps changed to something better.

We need a way to specify other fifo metadata, like bypass or more detailed combinational coupling and latency behavior. Most of this metadata does not effect the semantics at proc-level evaluation, so perhaps it should be bound via configuration at codegen. Now that internal channels are getting better names, perhaps binding fifo configuration by name is the way to go.

This fifo metadata should factor into scheduling and codegen. Scheduling needs to be aware of combinational coupling (e.g. a recv's in one stage may be ready after as the send in its stage depending on fifo metadata. Similarly, combo loops may occur unless care is taken in block conversion (e.g. pop_ready may imply push_ready in the same cycle and allow you to remove some logic (which may also avoid combo loops)).

@grebe grebe added enhancement New feature or request dslx DSLX (domain specific language) implementation / front-end ir codegen Related to emitting (System)Verilog. stitching Issues related to stitching, multi-proc codegen, and integration with external verilog modules labels Apr 24, 2024
copybara-service bot pushed a commit that referenced this issue Apr 25, 2024
Ideally, we'd have richer FIFO metadata and better ways to specify that metadata. For now, side-step the issue by choosing no-bypass FIFOs as the default (unless depth=0, where bypass is required).

See #1391 for some discussion.

PiperOrigin-RevId: 627902552
copybara-service bot pushed a commit that referenced this issue May 6, 2024
The `bypass` parameter in `FifoConfig` is not sufficient to eliminate combinational paths between push- and pop-side signals. This change adds `register_push_outputs` and `register_pop_outputs`, parameters that control if the push- or pop-side outputs are registered (breaking combinational paths).

Also, the config is getting big enough that I changed it from a struct (where some values are often unspecified) to a class with a constructor that requires all members to be specified. It seems better to be explicit everywhere, even if it's annoying (especially because there are so many `bool`s, which should be disambiguated with `/*param_name=*/`-style comments.

Ideally, I think it will be best to remove FIFO-config from channels and bind FIFO-config to channels at codegen time. See also #1391 for more discussion.

PiperOrigin-RevId: 631217053
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen Related to emitting (System)Verilog. dslx DSLX (domain specific language) implementation / front-end enhancement New feature or request ir stitching Issues related to stitching, multi-proc codegen, and integration with external verilog modules
Projects
None yet
Development

No branches or pull requests

1 participant