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

Provide a way to specify that a Signal is driven by a given Elaboratable #629

Closed
alanvgreen opened this issue Aug 21, 2021 · 1 comment
Closed

Comments

@alanvgreen
Copy link
Contributor

It would be useful to have a way to specify that a Signal is driven by a specific Elaboratable.

Consider this example, which presupposes a driven_by attribute on Signal().

class MyCounter(Elaboratable):
  def __init__(self):
    self.advance = Signal()
    self.count = Signal(16, driven_by=self)

  def elaborate(self, platform):
    m = Module()
    with m.If(self.advance):
      m.d.sync += count.eq(count + 1)

Here, specifying driven_by=self on the count signal performs two functions:

  1. It acts as documentation of the MyCounter interface, making it clear that count is an output. Since advance is not specified to be driven by this Elaboratable, it can be assumed to be an input.
  2. It provides a mechanism to find some class of bugs, such as forgetting to drive the signal from this module or also driving it from a second module.

It is probably only worth adding a driven_by type property if it is programatically checked.

Not every Signal would need to have a specified driver. Probably the vast majority of uses would be as above: documenting the outputs of an Elaboratable by specifying driven_by=self on those Signals.

@Lunaphied
Copy link
Contributor

I'm not confident that a driven_by attribute on Signals is a good way of addressing this problem. The issue you're having is that you want an interface defined on a particular Elaboratable which defines outputs/inputs/etc. This is a feature that will be coming soon and address this better than a marker attribute.

There should be an RFC for interfaces very soon so I'm closing in favor of that approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants