Asynchronous Data Channels


Proposal Details

  • Who Updates:Main.KevinCameron
  • Date Proposed:
  • Date Last Updated:
  • Priority:
  • Complexity:
  • Focus:

Current Situation

We only have signals for driving event driven code. Signals do not conserve data, and are intended for modeling wire-like communications.

As transistor dimensions shrink the dimension that does not scale well is resistance, meaning that "clock reach" (how many gates you can reach in a clock cycle) keeps shrinking. As a result data moving across a chip usually requires a lot of intermmediate buffer/repeater stages.

The RTL logic abstraction is now decades old as a design abstraction and many tools will rip-up the user's RTL description and retime it.

It is therefore time to add a construct to the language that allows data to be moved and processed independent of any clocking scheme.

Requirement

Add a signal-like construct for use in abstract logic description that can be used to conservatively transfer data from process to process. Signals are not conservative because there is no requirement that it is read when updated, i.e. if a signal input changes that a process is not sensitive to it the data is lost.

Implementation details

Add the keyword "pipe" which can be used much the same as "signal" - processes can drive values into a pipe directly and can be sensitive to pipes. Pipes behave as FIFO storage, and only reading from a pipe destroys the data. Attributes include depth and number of items in the pipe. A pipe is active while it has data, attached processes are woken up in random order when data is written into a pipe until all process have been tried or the pipe is empty.

Code Examples

pipe my_fifo : integer; -- infinite depth pipe

pipe my_fifo4 : integer depth 4; -- 4 deep pipe

Use Cases

For self-timed logic descriptions: basically FSMs with no clock. The goal being to allow the synthesis tools to work out the clocking schemes.

-- JimLewis - 2013-07-22:

Self-timed logic sounds interesting. What other mechanisms do we need. I would think we need a big picture of what needs to happen before implementing some of the details.

Arguments FOR

RTL is well past its prime as a design abstraction.

Arguments AGAINST

General Comments

Supporters

Add your signature here to indicate your support for the proposal

Topic revision: r4 - 2020-02-17 - 15:34:49 - JimLewis
 
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback