-
Notifications
You must be signed in to change notification settings - Fork 78
First draft vector parameters #1245
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
base: main
Are you sure you want to change the base?
Changes from all commits
6d0ea1f
ac9c774
9edc04f
b836017
e6c2e29
58d2461
8d52853
6cc24a4
2dd6085
071d63e
406e6d3
ba209ce
44e90e8
8d17332
95fd428
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -15,6 +15,175 @@ versions: | |
| description: | | ||
| TODO | ||
| params: | ||
| VLEN: | ||
| description: | | ||
| The number of bits in a single vector register, _VLEN_ {ge} ELEN, which must be a power of 2, and must be no greater than 2^16^. | ||
| schema: | ||
| type: integer | ||
| enum: [8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536] | ||
| ELEN: | ||
| description: | | ||
| The maximum size in bits of a vector element that any operation can produce or consume, _ELEN_ {ge} 8, which | ||
| must be a power of 2. | ||
| schema: | ||
| type: integer | ||
| enum: [8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536] | ||
| extra_validation: | | ||
| assert ELEN <= VLEN | ||
| SEW_MIN: | ||
| description: | | ||
| Implementations must provide fractional LMUL settings that allow the | ||
| narrowest supported type to occupy a fraction of a vector register | ||
| corresponding to the ratio of the narrowest supported type's width to | ||
| that of the largest supported type's width. In general, the | ||
| requirement is to support LMUL {ge} SEW~MIN~/ELEN, where SEW~MIN~ is | ||
| the narrowest supported SEW value and ELEN is the widest supported SEW | ||
| value. | ||
| schema: | ||
| type: integer | ||
| enum: [8, 16, 32, 64] | ||
| extra_validation: | | ||
| assert SEW_MIN <= ELEN | ||
| VECTOR_AGNOSTIC_BEHAVIOR: | ||
| description: | ||
| When a set is marked agnostic, the corresponding set of destination | ||
| elements in any vector destination operand can either retain the value | ||
| they previously held, or are overwritten with 1s. | ||
| schema: | ||
| type: string | ||
| enum: ["never_overwritten", "custom"] | ||
|
Comment on lines
+47
to
+54
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This appears to be parameterizing a specific possible implementation of "agnostic" for a behavior which can even be non-deterministic. Is there value in doing so? (Honest question.)
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a completely fair interpretation; I just thought there might be some value to even stating in a custom parameter "undeterministic." I think it would also be useful for a parameter to state that this behavior is never exercised, thats why I included "never_overwritten" |
||
| SUPPORT_FRACTIONAL_LMUL_BEYOND_REQUIRED: | ||
| description: | ||
| For a given supported fractional LMUL setting, implementations must support | ||
| SEW settings between SEW~MIN~ and LMUL * ELEN, inclusive. | ||
|
Comment on lines
+57
to
+58
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would seem to be a normative rule, rather than a parameter. (But don't trust my interpretation! 😉 )
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue below discusses this issue. The normative rule above simply states what is required to be implemented. For example, it doesnt state that SEW 64 LMUL 1/2 cannot be supported. Therefore in my mind I see it as up to the designer to allow for this implementation or not. Supporting vs not supporting these cases would produce a different result when executing the same program: that is why it should be a parameter in my mind. |
||
| schema: | ||
| type: string | ||
| enum: ["no_unrequired_supported", "custom"] | ||
| VILL_SET_ON_RESERVED_VTYPE: | ||
| description: | ||
| The use of `vtype` encodings with LMUL < SEW~MIN~/ELEN is | ||
| __reserved__, but implementations can set `vill` if they do not | ||
| support these configurations. | ||
| schema: | ||
| type: boolean | ||
| RESERVED_VILL_SET: | ||
| description: | | ||
| When _rs1_=`x0` and _rd_=`x0`, the instructions operate as if the current vector length in `vl` is used as the AVL... | ||
| Use of the instructions with a new SEW/LMUL ratio that would result in a change of VLMAX is reserved. | ||
| Use of the instructions is also reserved if `vill` was 1 beforehand. Implementations may set `vill` in either case. | ||
|
Comment on lines
+72
to
+73
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if these two cases should be separately parameterized? But, I guess you handle each case independently via the enum below. So, maybe fine.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the most common case would be to either do both together or none at all, but I do not feel strongly about it being one parameter or two. |
||
| schema: | ||
| type: string | ||
| enum: ["never", "on_vlmax_change", "on_vill_set", "always", "custom"] | ||
| VECTOR_LS_INDEX_MAX_EEW: | ||
| description: | ||
| A profile may place an upper limit on the maximum supported index | ||
| EEW (e.g., only up to XLEN) smaller than ELEN. | ||
| schema: | ||
| type: integer | ||
| enum: [8, 16, 32, 64] | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if this additionally needs "XLEN" as an option, given the description suggests that.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do you think instead the options should be ["XLEN", "ELEN", "custom"]?
jacassidy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| extra_validation: | | ||
| assert VECTOR_LS_INDEX_MAX_EEW <= ELEN | ||
| VECTOR_FF_UPDATE_PAST_TRIM: | ||
| description: | ||
| Similarly, fault-only-first load instructions may update active destination elements past the element that causes trimming | ||
| of the vector length (but not past the original vector length). The values of these spurious updates do not have to correspond | ||
| to the values in memory at the addressed memory locations. Non-idempotent memory locations can only be accessed when it is known | ||
| the corresponding element load operation will not be restarted due to a trap or vector-length trimming. | ||
| schema: | ||
| type: string | ||
| enum: ["update_none", "custom"] | ||
| VECTOR_FF_SEG_EXCEPTION_PARTIAL_LOAD: | ||
| description: | | ||
| For fault-only-first segment loads, if an exception is detected partway | ||
| through accessing the zeroth segment, the trap is taken. | ||
| If an exception is detected partway through accessing a subsequent segment, | ||
| `vl` is reduced to the index of that segment. | ||
| In both cases, it is implementation-defined whether a subset of the segment is | ||
| loaded. | ||
| schema: | ||
| type: string | ||
| enum: ["no_subsegment_loaded", "custom"] | ||
| VECTOR_LS_MISSALIGNED_EXCEPTION: | ||
jacassidy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| description: | | ||
| If an element accessed by a vector memory instruction is not naturally aligned to the size of the element, | ||
| either the element is transferred successfully or an address misaligned exception is raised on that element. | ||
|
|
||
| Support for misaligned vector memory accesses is independent of an implementation’s support for misaligned scalar memory accesses. | ||
| schema: | ||
| type: boolean | ||
| VECTOR_LOAD_PAST_TRAP: | ||
| description: | | ||
| Load instructions may overwrite active destination vector register | ||
| group elements past the element index at which the trap is reported. | ||
| schema: | ||
| type: string | ||
| enum: ["preserve_active", "custom"] | ||
| VECTOR_LS_SEG_FF_OVERLOAD: | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is also for loads only. However, I think this case is already covered by the "PARTIAL" parameter above.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if you're referring to "VECTOR_FF_SEG_PARTIAL_ACCESS," that parameter has to do specifically with the loading of a single segment, while this is referring to all the elements of the group. Interestingly I dont think this is covered by "VECTOR_LS_OVERWRITE_PAST_TRAP" as that parameter is constrained to only active elements. This statement (specifically referring to FF loads) states any "vector register group elements," not strictly active elements |
||
| description: | | ||
| These instructions may overwrite destination vector register group | ||
| elements past the point at which a trap is reported or past the point | ||
| at which vector length is trimmed. | ||
| schema: | ||
| type: string | ||
| enum: ["no_overwrite", "custom"] | ||
| VECTOR_LS_SEG_PARTIAL_ACCESS: | ||
| description: | | ||
| If a trap occurs during | ||
| access to a segment, it is implementation-defined whether a subset | ||
| of the faulting segment's accesses are performed before the trap is taken. | ||
| schema: | ||
| type: string | ||
| enum: ["no_partial", "custom"] | ||
|
Comment on lines
+134
to
+136
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. boolean?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is it useful to state if a partial access is performed, how much of the partial access is performed? I might be missinterpreting this section.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMHO, it's non-deterministic, so boolean here is sufficient. (That still allows one, perhaps unwisely, to "rely" on the "no partial access" behavior for whatever nefarious purposes. ;-) ) |
||
| LEGAL_VSTART: | ||
| description: | | ||
| Implementations are permitted to raise illegal-instruction exceptions when | ||
| attempting to execute a vector instruction with a value of `vstart` that the | ||
| implementation can never produce when executing that same instruction with | ||
| the same `vtype` setting. | ||
| schema: | ||
| type: string | ||
| enum: ["1_stride", "2_stride", "4_stride", "custom"] | ||
|
Comment on lines
+137
to
+145
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this needs to comport more closely to the description. Maybe "EXCEPTION_ON_UNSUPPORTED_VSTART" or something like that? Then, it would just need to be a boolean.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a really good point I did not think of. I think in this case there should actually be 2 parameters, one to state if exceptions occur on unsupported VSTART values, and another to state which VSTART values are supported. With the current parameter definition I was trying to cover which VSTART values are supported by the implementation. |
||
| VECTOR_LS_WHOLEREG_MISSALIGNED_EXCEPTION: | ||
| description: | | ||
| Implementations are allowed to raise a misaligned address exception on | ||
| whole register loads and stores if the base address is not naturally | ||
| aligned to the larger of the size of the encoded EEW in bytes (EEW/8) | ||
| or the implementation's smallest supported SEW size in bytes | ||
| (SEW~MIN~/8). | ||
| schema: | ||
| type: boolean | ||
| VSSTATUS_VS_EXISTS: | ||
| description: | | ||
| For implementations with a writable `misa.V` field, | ||
| the `vsstatus.VS` field may exist even if `misa.V` is clear. | ||
| schema: | ||
| type: boolean | ||
| VECTOR_FF_NO_EXCEPTION_TRIM: | ||
| description: | | ||
| Even when an exception is not raised, implementations are permitted to process | ||
| fewer than `vl` elements and reduce `vl` accordingly, but if `vstart`=0 and | ||
| `vl`>0, then at least one element must be processed. | ||
| schema: | ||
| type: string | ||
| enum: ["no_trim", "custom"] | ||
|
Comment on lines
+167
to
+168
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. boolean? |
||
| VFREDUSUM_NAN: | ||
| description: | | ||
| The reduction tree structure must be deterministic for a given value in vtype and vl. | ||
| As a consequence of this definition, implementations need not propagate | ||
jacassidy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| NaN payloads through the reduction tree when no elements are active. In | ||
| particular, if no elements are active and the scalar input is NaN, | ||
| implementations are permitted to canonicalize the NaN and, if the NaN is | ||
| signaling, set the invalid exception flag. Implementations are alternatively | ||
| permitted to pass through the original NaN and set no exception flags, as with | ||
| `vfredosum`. | ||
| schema: | ||
| type: string | ||
| enum: ["no_change", "custom"] | ||
|
Comment on lines
+180
to
+181
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could use more eyes on this one:
|
||
| IMPRECISE_VECTOR_TRAP_SETTABLE: | ||
| description: | | ||
| Some profiles may choose to provide a privileged mode bit to select between precise and imprecise vector traps. | ||
| schema: | ||
| type: boolean | ||
| MUTABLE_MISA_V: | ||
| description: | | ||
| Indicates whether or not the `V` extension can be disabled with the `misa.V` bit. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec has this:
So, do we need to support a parameter for this, given that only 8 is "standard"?
Related, where did these 4 values come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the testing framework we are developing for RISC-V ACT 4.0 we include SEW_MIN as a parameter. Even though it is not currently in a standard extension to use anything other than SEW_MIN=8, it is still a valid vector implementation to have a different SEW_MIN. As far as we can tell, SEW_MIN is completely arbitrary in non-standard extensions meaning it can be any SEW. For example, we interpret that a vector unit that only supports an SEW of 32 to be a valid implementation (SEW_MIN=32 and ELEN = 32).