-
Notifications
You must be signed in to change notification settings - Fork 38
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
PaperProject Details #112
Comments
Branches I'm using (based off the above): Branches
|
@chick can you make sure ops like the ones in https://github.com/ucb-bar/dsptools/tree/master/src/main/scala/dsptools/numbers are also supported? i.e. <<, >> not implemented: scala.NotImplementedError: an implementation is missing |
Working on it. Is there general agreement on what it means. I would guess for shift that:
And what about merge. Not mentioned in Wikipedia Intervals
Or maybe more naively
|
So two things:
a >> n AND a.div2(n) ^ Both should be eventually supported (but not necessarily in Chisel; can be in dsptools). What is merge? It seems like, for example, with multiply, you were intending to have firrtl infer everything if uninferred i.e. maybe the naive approach? Are we going at this expecting that Chisel basically should have no knowledge of intervals besides the ones that are user assigned and letting firrtl take care of pretty much everything? |
Also, fyi, I pushed more changes to aforementioned branches to fix some bugs. |
I added the unimplemented shift functions IntervalRange and Interval. I need to add more tests but I wanted to get the implementations out there first. I left merge() in as unimplemented. Not sure what it is intended for. |
And yes, I believe @azidar thought the naive approach of anything not simple with intervals should be deferred to Firrtl as best for now. |
Ok then beyond that, the ops that should take precedence are clip, wrap, etc. (overflow behavior and truncation/round, etc.). After that, I think we're good for being able to try some more complicated legitimate hardware... I will also add some tests... (but in my FFT repo for now) |
Here are the ops Adam checked in IntervalMathSpec:
Is cat something built into the type in Chisel or an external helper? o_O Otherwise, assuming the dynamic/static shifts work, I think we've covered all of our bases there. |
And as far as the rest of Adam's non-math tests, really it's: Cannot defined unknown BP for interval (Chisel restriction) -- just my note wrap Is there a setBinaryPoint equivalent for Interval? That might be more necessary for stuff like rounding ops. |
I can't find a reference to merge in our doc. @chick, your instinct matches mine, but I'm still trying to think of why it would be useful. |
@shunshou Also I did not see a problem with running the interpreter's instrumenting-sizes branch with the intervals-oct branches of firrtl and chisel3, if you have an example can you pass it to me |
Yeah, so Adam's super busy this week--he asked to reschedule our meeting (will send out an email shortly), but if he has a few minutes to meet with you tomorrow to discuss next steps, that'd be great. The one thing I'd like to see is being able to do clip based off of some other signal's range * # of loops, as an example, to handle: multiply by a constant and accumulate. I'll test firrtl-interpreter again with various branches and copy+paste the error I get in a few minutes. |
Also, are you on the same branch of chisel-testers/dsptools as I am?
If you are on a better version of chisel-testers (and corresponding dsptools), please let me know! |
@azidar all the wrap cases I did made sense except for val base = Wire(Interval(range"[-4, 6]"))
val disjointRight = Wire(Interval(range"[7,11]"))
val w6 = base.wrap(disjointRight)
assert(w6 === 10.I()) // FAILS says it should be 6.U
// even though derived interval is disjointRight Closed(7) Closed(11) Any ideas |
Before you delve too deep into this, as a basic use case, I just want to see that |
@shunshou I'll need to change chisel-testers to fix its publishLocal problems with the instrumenting-sizes branch of firrtl-interpreter. Can there be a intervals-oct branch of chisel-testers that I can make my changes in. I'm not sure what to do with cb82340 |
yea go for it--make a branch and i'll point my stuff to it. thanks!! :D |
@shunshou pushed my latest wrap stuff to intervals-oct. This includes |
@shunshou just pushed intervals-oct branch with interpreter fixes for instrumenting-sizes branch. |
Hmm... I get
|
@shunshou just pushed clip (saturate) operator for intervals |
Thx! Finally have a ~10 pg outline of the ~6 pg paper. :P Will look into this after I'm done drafing background + intro hopefully... |
Hmnm, I am building with |
@chick, I'm still getting:
with the branches you've pointed me to :( |
Still trying to get this |
Yay looks like i was able to sbt publish-local everything this time around, but dsptools still needs editing :( -- (When I run FFT-local tests):
|
@shunshou What's the branch of dsptools |
I assumed you were on master, so I switched to that (but that's probably just not compatible w/ old stuff...). |
https://github.com/ucb-art/Chisel3DSPDependencies/tree/ranges (range branch!) points to stuff that should hopefully work now: firrtl: intervals-oct (Note: not sure if the default versions of chisel3/chisel-testers need updating in build.sbt? -- more generally; not for this particular issue). |
@chick bpsl, bpsr, bpset should also be implemented in chisel, if it hasn't already. |
I have just pushed to intervals-oct new methods on Interval |
Cool. I'm still in the process of debugging some of the shifts... Adam and I will be having a working meeting today ~1 to maybe up to 3ish? We should just clean out these details and make basic tests for everything while people are here... :o |
@shunshou I had to push some small changes to instrumenting-sizes branch of the interpreter. |
I have started a documentation page on chisel3 wiki for Intervals |
Ok, I'm still debugging some intermediate shr weirdness -- doesn't seem like I'm getting the right answer when I'm shifting by less than the width either :, but need to finish up slides for another conference tonight. Thanks for starting the intervals documentation :D |
@chick what implications are there if chisel range inference is wrong? (and firrtl is right?) |
It would imply to me that things are broken. In general, @azidar and I have tried to match the firrtl behavior, and in many cases actually use the firrtl code generate answers when we can. I think there a number of cases where chisel might defer to firrtl, by just leaving things unknown so firrtl will figure it out, but it shouldn't contradict it |
OK. I went ahead and double checked stuff and made things unknown wherever I felt there was a contradiction... Still not quite at the point of passing enough of my own tests, but getting closer. |
@chick -- looks like x.clip(uint/sint) and x.wrap(uint/sint) don't work. Namely, there's no firrtl PrimOp that operates on 1 Interval and 1 UInt/SInt type... I thought I could handle this at the Chisel level by first doing asInterval on the UInt -- when the width is known, everything's good... unfortunately, when the width is unknown, I don't think there's any mechanism to pass the unknown (?) through from the Chisel emitter... [at least for asInterval?]. |
Hmm, it looks to me like |
Hm ok I made some changes assuming known UInt and SInt. I'm making my own
tests for them locally (basically assuming my model is intended behavior).
If you can generalize to handle unknown ranges, that'd be great. Also,
looks like some of my changes broke some of your tests. I made some of them
based off of my understanding of how functions should operate (from various
discussions), so we should make sure our understandings of behaviors match
and better document.
…On Sunday, October 22, 2017, Chick Markley ***@***.***> wrote:
Hmm, it looks to me like x.wrap(sint) might be a problem, but the
rest of the family convert the argument to an interval before passing down
to firrtl.
But clearly I need to expand the tests to include use of the SInt and UInt
versions of
clip and wrap, also to add tests for all these with some arguments with
unknown ranges. Sorry, but it's going to be later tonight before I can get
to it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGTTFl1oN83VZZ82hlcQqV4k6qHLIzk-ks5su6figaJpZM4PzGSp>
.
|
FYI--when adding tests, it's important to test stuff that's not just integers. Running into annoying binary point alignment problems, etc. |
@chick to save me some time of trying to figure this out -- can you make a toy example for how firrtl interpreter stuff works with the driver in DspTools? (Likely stuff will need modification?) |
Almost got it working, but found some edge case problems :-(. |
no worries. i'm still trying to get accumulate working. :\ slow process... |
Re: Interpreter -- I think we agreed on trimming widths based on some n sigma criteria or min/max. The other thing that's useful is that, if we're trimming based off of sigma, it should be trim and optionally clip to maximum. |
The toy example works with my latest push/merges to |
Yay! OK. I will try to run the interpreter on my interval arithmetic testbench and get back to you. |
@azidar What do you expect should happen in these cases?
Looks like a always keeps a's range... |
@chick @grebe -- Intervals type classes should hopefully be in a workable state, so can actually really start using them. QOR for the firrtl output looks like what I calculated + the firrtl-interpreter sims got the right mins + maxes for the one test I paid closest attention to. I'm going to port over my testing infrastructure from my local repo to dsptools so hopefully it'll be easier for you to play with stuff. Should be up in the next hour or so? Then I'll go and try more complicated circuits and run them through some real synthesis tool. |
Branches
The text was updated successfully, but these errors were encountered: