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

Adding functionality to check whether current packets are diplomatically valid for both master and slave #2505

Merged
merged 20 commits into from Jun 29, 2020

Conversation

brrmorre
Copy link
Contributor

@brrmorre brrmorre commented Jun 5, 2020

Related issue:
Adding functionally to check whether current packets are diplomatically valid for both master and slave instead of just checking what the slave supports. We now want to check for both what the master can emit and what the slave can support. We want to check for what is expected on the tilelink edge using both information about what the master can emit and what the slave can support or vice versa.

Type of change: feature request

Impact: API modification

Development Phase: implementation

Release Notes

@brrmorre brrmorre self-assigned this Jun 5, 2020
@brrmorre brrmorre added the draft Used by mergify.io automated merging rules label Jun 5, 2020
}
}

private def emitHelper(
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't insert this code between the definition of safety_helper and usage of safety_helper, because it seems like the safety_helper is only used here.

sourceId: UInt,
lgSize: UInt,
range: Option[TransferSizes]): Bool = {
def trim(x: TransferSizes) = range.map(_.intersect(x)).getOrElse(x)
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need trim?

Copy link
Member

Choose a reason for hiding this comment

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

It seems asymmetric to "ignore" the range argument that is passed into the expectsXYX functions below. The helper that helps with sourceId-based calculations and the helper that helps with address-based calculations should probably treat range in the same way?

Copy link
Member

Choose a reason for hiding this comment

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

We agreed that we do not need to be concerned with range trimming for the version of these functions used for VIP circuitry.


//We don't use Safe vs Fast because we don't have the equivalent of address decoder for sourceIds
// TODO (can use sourceId here to see if the specific master can support this transaction)
def expectsProbeSlaveToMaster = master.supportsProbe
Copy link
Member

@hcook hcook Jun 9, 2020

Choose a reason for hiding this comment

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

Duality: these B channel messages from SlaveToMaster are:

  • being routed to a master based on sourceId bits, so they need to be passed to a helper that checks whether the master that owns certain sourceIds claimed to support transactions of this size/type
  • being sent from a slave owning certain addresses, so they need to be passed to a helper that checks with the slave that owns certain addresses claimed to emit transactions of this size/type


// For emits, check that the source is allowed to send this transactions
// TODO emitAcquire, source => sourceId (or don't need sourceId at all)
// Probe, source => address
Copy link
Member

@hcook hcook Jun 9, 2020

Choose a reason for hiding this comment

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

These A channel messages from MasterToSlave are:

  • being routed to a slave based on address bits, so they need to be passed to a helper that checks whether the slave that owns certain addresses claimed to support transactions of this size/type
  • being sent from a master using sourceId bits, so they need to be passed to a helper that checks whether the master that owns certain sourceIds claimed to emit transactions of this size/type

if (allSame) member(clients(0)).containsLg(lgSize) else {
Mux1H(find(id), clients.map(member(_).containsLg(lgSize)))
// Available during RTL runtime, checks to see if (id, size) is supported by the master's (master's) diplomatic parameters
private def safety_helper(member: TLMasterParameters => TransferSizes)(id: UInt, lgSize: UInt) = {
Copy link
Member

@hcook hcook Jun 9, 2020

Choose a reason for hiding this comment

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

We need to reason about which features of the proposedemitHelper need to be merged with this function and whether they actually produce different logic in valuable ways.

I recommend changing the name of what is currently supportsHelper to be addressHelper and
the combination of safety_helper +emitsHelper to be sourceIdHelper, since I believe the supports/emits aspect is orthogonal (e.g. it is just whichever TLMasterParameters => TransferSizes you happen to pass in to sourceIdHelper, which could be either about supporting or about emitting).

Put another way, what really matters to the circuit generation helpers is which bit fields of the message you are filtering on, and since there are two options (id vs address), there should be two helper functions, one defined on TLMasterPortParameters (ids) and one defined on TLSlavePortParameters (addresses)

// Available during RTL runtime, checks to see if (id, size) is supported by the master's (master's) diplomatic parameters
private def safety_helper(member: TLMasterParameters => TransferSizes)(id: UInt, lgSize: UInt) = {
val allSame = masters.map(member(_) == member(masters(0))).reduce(_ && _)
if (allSame) member(masters(0)).containsLg(lgSize) else {
Copy link
Member

Choose a reason for hiding this comment

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

I think this if statement is a coarse generalization of the groupBy in the emitsHelper version; the case where there is only one group.

@@ -534,20 +537,53 @@ class TLSlavePortParameters private(
// Does this Port manage this ID/address?
def containsSafe(address: UInt) = findSafe(address).reduce(_ || _)

// all we need to change about this is adding 2 members, one for the tlmaster parametrs and one for the tlslave parameters
// All wee need to do is change the membership function to instead of only slave pamaters it looks at the intersection of both master and slave
// do we need to pass in two different arguments
Copy link
Member

Choose a reason for hiding this comment

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

I think we concluded below that two different helper functions are necessary and that we will && the results of the duals together in the edge function. So this one should remain focused on TLSlaveParameters => TransferSizes cases that look at address.

val allSame = clients.map(member(_) == member(clients(0))).reduce(_ && _)
if (allSame) member(clients(0)).containsLg(lgSize) else {
Mux1H(find(id), clients.map(member(_).containsLg(lgSize)))
// Available during RTL runtime, checks to see if (id, size) is supported by the master's (master's) diplomatic parameters
Copy link
Contributor

Choose a reason for hiding this comment

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

sic

@terpstra
Copy link
Contributor

terpstra commented Jun 15, 2020

As a follow-up PR we might want to split fast/safe into:

  • a VIP checker API that consults both the full address (not assumed to be legal) and the full source (not assumed to be legal) -- range is not relevant
  • a what possible sizes of Get might flow over this edge API (that does not look at address/source; just an intersection of the unions of master with the unions of slaves, but does include an optional range); Place-holder name: isMessagePossible
  • a check for whether or not a message (+size) is legal for a given address (assumed to be legal and given a range within which the checked size will fall) -- used by masters; Place-holder name: canMasterSend
  • a check for whether or not a message (+size) is legal for a given source (assumed to be legal and given a range within which the checked size will fall) -- used by slaves; Place-holder name: canSlaveSend

val supportsPutPartialChecker = sourceIdHelper(_.supportsPutPartial) _
val supportsHintChecker = sourceIdHelper(_.supportsHint) _

// TODO: Merge sourceIdHelper2 with sourceIdHelper
Copy link
Member

Choose a reason for hiding this comment

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

Please resolve this

@brrmorre brrmorre removed the draft Used by mergify.io automated merging rules label Jun 22, 2020
@brrmorre brrmorre requested a review from jchang0 June 29, 2020 03:30
@jchang0 jchang0 merged commit 70a7556 into master Jun 29, 2020
@hcook
Copy link
Member

hcook commented Jul 16, 2020

@jchang0 @brrmorre Because the diplomacy information for the edge contains the static tile id, this means that the monitors on the tile master crossbar and master ports breaks deduplication of multicore tiles...

@jackkoenig
Copy link
Contributor

Chisel 3.4 should support instance-specific annotations no longer breaking deduplication. TBD how to handle annotated signals that get constant propagated, but this should make it possible make things like monitors link against the DUT via annotations and thus not break dedup when they have custom code per instance.

Just mentioning some nearish possibilities, but for now I think we need to remove that part of the info String.

@brrmorre brrmorre changed the title Supporthelperchange Adding functionality to check whether current packets are diplomatically valid Jul 23, 2020
@brrmorre brrmorre changed the title Adding functionality to check whether current packets are diplomatically valid Adding functionality to check whether current packets are diplomatically valid for both master and slave Jul 23, 2020
ingallsj added a commit that referenced this pull request Dec 4, 2020
* un-deprecate TLMasterSlavePortParameters.supports*

* move expectsVipCheckerMaster/Slave into Monitor.scala from Parameters.scala

* remove TLMasterPortParameters.expectsVipChecker

* remove TLSlavePortParameters.expectsVipChecker

* TileLink Monitor.scala: addressHelper supports/emit Safe, not Fast (assumed address exists)

* TileLink Parameters.scala: unresolved feedback from PR (#2505)

* remove deprecated TLMasterParameters.supports*
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

6 participants