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

FixChisel3: Add some commentary to scaladoc #2339

Merged
merged 11 commits into from May 17, 2020
Merged

Conversation

mwachs5
Copy link
Contributor

@mwachs5 mwachs5 commented Mar 15, 2020

Related issue:

Type of change: other enhancement

Impact: no functional change

Development Phase: implementation

Release Notes

Added some scaladoc commentary to the "FixChisel3" operators :<>, :<=, :=> to explain what they do and the rationale for their creation.

Copy link
Contributor

@leikou01 leikou01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a new user, I found that the below comments are useful for me. That tells me that these operators can be used to connect Wires to IO.

implicit class EnhancedChisel3Assign(val x: Data) extends AnyVal {
// Assign all output fields of x from y; note that the actual direction of x is irrelevant
def :<= (y: Data): Unit = FixChisel3.assignL(x, y)
// Assign all input fields of y from x; note that the actual direction of y is irrelevant
def :=> (y: Data): Unit = FixChisel3.assignR(x, y)

Also, it might be helpful to replace "a" with "c" (as Consumer) and "b" with "p" (as Producer), I think.

Update to use producer-consumer and add some scaladoc on the RHS typed versions. I need to double check all my m/p/c when a bit less distracted.
Copy link
Contributor

@terpstra terpstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. There is a bit of additional functionality now, in that my operators allow you to customize their behaviour on your Bundles. In particular, for BundleMaps, this means that when you bulk connect two BundleMaps with different fields, mismatched fields get the field-defined default value. This is particularly relevant for user/echo-bits in the updated TileLink bundles.

src/main/scala/util/package.scala Outdated Show resolved Hide resolved
*
* In terms of [[Flipped]] with a producer 'p' and 'consumer' c:
* c :<= p // means drive all unflipped fields of 'c' from 'p' (e.g.: valid/bits)
* c :=> p // means drive all flipped fields of 'c' from 'p' (e.g.: ready)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one actually means
* c :=> p // means drive all flipped fields of 'p' from 'c' (e.g.: ready) , e.g.: p.ready := c.ready ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so should this say p :=> c for a more consistent example?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is "no".

Rule #1 for this set of operator is "consumer always on LHS". (It is sort of directional operator from the producer-consumer's viewpoint. not sure of the best way to express this).

p:=> c means that the consumer's ready (input) is driven by the producer's ready (output), which is wrong.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. Consumer is always on the left-hand-side. The comment should have been:

c :=> p // means drive all flipped fields of 'p' from 'c' (e.g.: p.ready := c.ready)

* c :<= p // means drive all unflipped fields of 'c' from 'p' (e.g.: valid/bits)
* c :=> p // means drive all flipped fields of 'c' from 'p' (e.g.: ready)
* c :<> p // do both of the above
* p :<> c // do both of the above, but you'll probably get a Gender error later.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gender has been replaced by Flow. Also if this results in flow errors in FIRRTL, I think it would be better to just catch them here instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You propose to try and introspect the actual direction? And if it cannot be determined (ie: is a wire), just trust the user? That is fine by me.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jackkoenig do you have any plan of supporting these operators in chisel?

*
* Compared with [[chisel3]] operators:
* c <> p is an 'actual-direction'-inferred 'c :<> p' or 'p :<> c'
* c := p is equivalent to 'c :<= p' + 'c :=> p' or 'c:<> p'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong.
c := p is equivalent to 'c :<= p' + 'p :=> c'.

'c :<> p' is not related to 'c := p' at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, 'c := p' says drive ALL fields of 'c' from 'p' regardless of their direction.

(which is pretty much only useful when you want to put a VIP monitor down that watches the wires of an existing producer-consumer pair)

Copy link
Contributor

@terpstra terpstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the comment about ':=', but otherwise, I approve.

@mwachs5 mwachs5 merged commit 16d49a7 into master May 17, 2020
@mwachs5 mwachs5 deleted the scaladoc-fixchisel3 branch June 9, 2020 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants