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

"Default Block" / more than one match per line for switch statement #526

Open
jchang0 opened this issue Feb 23, 2017 · 7 comments
Open

"Default Block" / more than one match per line for switch statement #526

jchang0 opened this issue Feb 23, 2017 · 7 comments
Assignees
Labels
API Modification Challenge Issue A nice-to-have but difficult to implement feature request Feature New feature, will be included in release notes
Milestone

Comments

@jchang0
Copy link

jchang0 commented Feb 23, 2017

Two separate feature requests

  1. Have a default block available for switch statements (where if none of the is block match, it will execute the default block)
    e.g.
switch(value) {
  is(1) {
  // do something
  }
  is(2) {
  // do something
  }
  default {
    error := true.B
    assert(0)
  }
}
  1. Allow more than one matched value for each is block match.
    e.g. (the first two cases are more useful, the subsequent examples have potential usages, but I haven't encountered it yet)
switch(value) {
  is(1) {
  // do something
  }
  is(2, 4) {
  // do something
  }
  // we might need to figure out what it means if the user duplicate a value in this case (perhaps 
  execute both is blocks?)  Or just error out and disallow it if it overlaps.
  is(4, 6) {
  }
  // or maybe even more fancy, but can no longer check for non-overlapping matches if that's a requirement
  is(>5) {
  }
  // Or even generalizing it by allowing a predicate function (Maybe this and the previous is too much, since if it gets that fancy, should probably just use when statement, and feature not in verilog anyway)
  is( (v: Int):Bool => { v<7 }) {
  }
}
@mwachs5
Copy link
Contributor

mwachs5 commented Feb 23, 2017

What is the benefit of switch over when/elsewhen/otherwise ? I feel like switch is never used...

@sdtwigg
Copy link
Contributor

sdtwigg commented Feb 23, 2017

On 2, you can actually already (most of) this. The is function takes a varargs. It will run both blocks if you repeat a value in two blocks (although unclear whether this is guaranteed behavior or just a side effect of the implementation).

@mwachs5 switch is currently immediately (at frontend) transcribed into "when, when, when" so the only benefit is in potential Chisel readability.

@ducky64 ducky64 added this to the 3.1.0 milestone Apr 18, 2017
@edwardcwang edwardcwang added Feature New feature, will be included in release notes API Modification and removed API Modification labels Nov 8, 2017
@jackkoenig
Copy link
Contributor

I think there's more to this that we should consider that is an API modification. Because switch emits when, when, when, instead of when, elsewhen, otherwise it leaves coverage holes in the Verilog. This makes it a terrible thing to use for state machines which is what it's really intended for. We probably should change it (but should also check what Verilog case statements do). This would be an API backwards incompatible change though.

@ducky64
Copy link
Contributor

ducky64 commented Dec 13, 2017

Resolution: do both by 3.1

@ducky64 ducky64 self-assigned this Dec 13, 2017
@ducky64 ducky64 modified the milestones: 3.1.0, 3.1.1 Dec 22, 2017
@j-marjanovic
Copy link

+1

@edwardcwang edwardcwang modified the milestones: 3.1.1, 3.3.0 Jan 25, 2019
@azidar
Copy link
Contributor

azidar commented Oct 7, 2019

#1198 is related. Conclusion: is a Challenge Issue.

@azidar azidar added the Challenge Issue A nice-to-have but difficult to implement label Oct 7, 2019
@azidar azidar modified the milestones: 3.3.0, 3.X Oct 7, 2019
@juliusbaxter
Copy link

Just a ping that this would be useful 👍

I notice it didn't make it into the latest Chisel release as per:
https://www.chisel-lang.org/api/latest/chisel3/util/switch$.html

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Modification Challenge Issue A nice-to-have but difficult to implement feature request Feature New feature, will be included in release notes
Projects
None yet
Development

No branches or pull requests

9 participants