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

Feature Proposal: allowing latches #85

Closed
cristianmacario opened this issue Nov 9, 2017 · 4 comments · Fixed by #944
Closed

Feature Proposal: allowing latches #85

cristianmacario opened this issue Nov 9, 2017 · 4 comments · Fixed by #944
Labels
feature ✨ Feature idea with clear API defined good first issue GitHub good first issue
Milestone

Comments

@cristianmacario
Copy link

Hi,
talking about latches (let's say today is Latch day ;) ), even if they are rarely used, they might be useful (for instance in describing clock gating cells).
I would propose to allow the intentional introduction of Latches, using tags, just as we do with combinatorial loops (with the "noCombinatorialLoopCheck" tag)
For instance, introducing a tag called "noLatchCheck" or something similar, we could define latches like follws:

  val d = Bool
  val e = Bool
  val l = Bool addTag(noLatchCheck)
  when (e) {
    l := d
  }

This would need to be translated in Verilog as:

  wire e;
  wire d;
  reg l;
  always @ (e or d)
  begin
    if(e)begin
      l <= d;
    end
  end

Let me point out that in Verilog (I don't know about VHDL) latches should be assigned using the non-blocking assignment ("<=") instead of the blocking assignment ("=").
Just a proposal, let me know what you think.
Thanks!

@Dolu1990
Copy link
Member

Hi,

So until now, the idea was "If you want latches, you have to instanciate them through blackboxes"

But now it could be possible to integrate the feature in reworkDev branch, be before trying it, i would like to release the reworkDev branch into the master one, see if everything is fine, get some feedbacks, and later adding new feature of this order (latches).

Until that time, is the blaboxing way enough ?
Maybe those blackboxes could be integrated into devRework, and be instanciated via a wrapper. Then when the feature is nativly supported it would not need any changes in the user code base.

@cristianmacario
Copy link
Author

Sure, latches are not so essential and blackboxing is OK.
Future/long term feature is totally fine.

@Dolu1990 Dolu1990 added the feature ✨ Feature idea with clear API defined label Nov 10, 2017
@numero-744
Copy link
Collaborator

For the design I think a Latch(T) would feel more natural (like Reg(T)). With LatchWhen(...), etc.

So your example would be:

val d = Bool
val e = Bool
val l = Latch(Bool)
when (e) {
    l := d
}

Or

val d = Bool
val e = Bool
val l = LatchWhen(d, e)

@Dolu1990
Copy link
Member

Dolu1990 commented Jun 2, 2022

Yes, Latch(T) seems more natural. That maybe just some makeup which would add addTag(noLatchCheck) under the hood

@numero-744 numero-744 added the good first issue GitHub good first issue label Oct 23, 2022
@numero-744 numero-744 added this to the Long term milestone Oct 23, 2022
@numero-744 numero-744 linked a pull request Nov 2, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature ✨ Feature idea with clear API defined good first issue GitHub good first issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants