184 lines
7.0 KiB
Plaintext
184 lines
7.0 KiB
Plaintext
|
|
================================================================================
|
|
Things that need validation by the compiler
|
|
================================================================================
|
|
Many of these are probably already covered, but being paranoid.
|
|
Make a list of things as I think of them.
|
|
Keep them here in case I forget and re-think of them.
|
|
|
|
Mark these as follows:
|
|
X = Yes, confirmed that the compiler covers this
|
|
! = No! Confirmed that the compiler does not check this, and should.
|
|
? = TBD
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
X resetsignal width
|
|
reset signals shall have width of 1
|
|
|
|
X Field has no knowable value
|
|
- does not implement storage
|
|
- hw is not writable
|
|
- sw is readable
|
|
- No reset value specified
|
|
|
|
--> emit a warning?
|
|
|
|
X References to a component or component property must use unambiguous array indexing
|
|
For example, if "array_o_regs" is an array...
|
|
The following is illegal:
|
|
my_reg.my_field->next = array_o_regs.thing
|
|
my_reg.my_field->next = array_o_regs.thing->anded
|
|
This is ok:
|
|
my_reg.my_field->next = array_o_regs[2].thing
|
|
my_reg.my_field->next = array_o_regs[2].thing->anded
|
|
|
|
NEVERMIND - compiler does not allow indefinite array references at all!
|
|
References are guaranteed to be unambiguous:
|
|
"Incompatible number of index dimensions after 'CTRL'. Expected 1, found 0."
|
|
|
|
X Clause 10.6.1-f (wide registers cannot have access side-effects)
|
|
|
|
X multiple field_reset in the same hierarchy
|
|
there can only be one signal declared with field_reset
|
|
in a given hierarchy
|
|
|
|
X multiple cpuif_reset in the same hierarchy
|
|
there can only be one signal declared with cpuif_reset
|
|
in a given hierarchy
|
|
|
|
X Mutually-exclusive property checking
|
|
--> Yes. compiler now auto-clears mutex partners on assign, so it is
|
|
implicitly handled
|
|
|
|
X incrwidth/incrvalue & decrvalue/decrwidth
|
|
these pairs are mutually exclusive.
|
|
Make sure they are not both set after elaboration
|
|
Compiler checks for mutex within the same scope, but
|
|
i dont think I check for mutexes post-elaborate
|
|
|
|
... or, make these properties clear each-other on assignment
|
|
|
|
X Illegal property references:
|
|
- reference any of the counter property references to something that isn't a counter
|
|
decrsaturate / incrsaturate / saturate
|
|
overflow / underflow
|
|
- reference hwclr or hwset, but the owner node has them set to False
|
|
means that the actual inferred signal doesnt exist!
|
|
- reference swwe/swwel or we/wel, but the owner node has them, AND their complement set to False
|
|
means that the actual inferred signal doesnt exist!
|
|
- only valid to reference if owner has this prop set
|
|
enable/mask
|
|
haltenable/haltmask
|
|
hwenable
|
|
hwmask
|
|
decr/incr, decr../incrthreshold/..value
|
|
- others references that may not always make sense:
|
|
intr/halt - target must contain interrupt/halt fields
|
|
next
|
|
is this ever illegal?
|
|
|
|
X If a node ispresent=true, and any of its properties are a reference,
|
|
then those references' ispresent shall also be true
|
|
This is an explicit clause in the spec: 5.3.1-i
|
|
|
|
X Flag illegal sw actions if not readable/writable
|
|
The following combinations dont get flagged currently:
|
|
sw=w; rclr;
|
|
sw=w; rset;
|
|
sw=r; woset;
|
|
sw=r; woclr;
|
|
their counterparts do get flagged. such as:
|
|
sw=w; onread=rclr;
|
|
|
|
X Signals marked as field_reset or cpuif_reset need to have activehigh/activelow
|
|
specified. (8.2.1-d states that activehigh/low does not have an implied default state if unset!)
|
|
Also applies to signals referenced by resetsignal
|
|
|
|
X incrvalue/decrvalue needs to be the same or narrower than counter itself
|
|
|
|
X field shall be hw writable if "next" is assigned.
|
|
|
|
X sticky=true + "(posedge|negedge|bothedge) intr"
|
|
Edge-sensitivty doesnt make sense for full-field stickiness
|
|
|
|
X we/wel + implied or explicit "sticky"/"stickybit"
|
|
we/wel modifier doesn't make sense here.
|
|
|
|
X sticky/stickybit shall be hw writable
|
|
|
|
X Illegal to use enable/mask/haltenable/haltmask on non-intr fields
|
|
|
|
X incrwidth/decrwidth must be between 1 and the width of the counter
|
|
|
|
X counter field that saturates should not set overflow
|
|
counter; incrsaturate; overflow;
|
|
counter; decrsaturate; underflow;
|
|
|
|
Flag this as an error on the overflow/underflow property.
|
|
overflow/underflow property is meaningless since it can never happen.
|
|
|
|
Same goes to prop references to overflow/underflow
|
|
|
|
! hwclr/hwset/we/wel probably shouldn't be able to reference itself
|
|
y->hwclr = y;
|
|
y->we = y;
|
|
... it works, but should it be allowed? Seems like user-error
|
|
|
|
================================================================================
|
|
Things that need validation by this exporter
|
|
================================================================================
|
|
List of stuff in case I forget.
|
|
X = Yes! I already implemented this.
|
|
! = No! exporter does not enforce this yet
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
X Contents of target are all internal. No external regs
|
|
|
|
X Does not contain any mem components
|
|
|
|
X Warn/error on any signal with cpuif_reset set, that is not in the top-level
|
|
addrmap. At the very least, warn that it will be ignored
|
|
|
|
|
|
X "bridge" addrmap not supported
|
|
export shall refuse to process an addrmap marked as a "bridge"
|
|
Only need to check top-level. Compiler will enforce that child nodes arent bridges
|
|
|
|
X regwidth/accesswidth is sane
|
|
X accesswidth == regwidth
|
|
Enforce this for now. Dont feel like supporting fancy modes yet
|
|
X regwidth < accesswidth
|
|
This is illegal and is enforced by the compiler.
|
|
X regwidth > accesswidth
|
|
Need to extend address decode strobes to have multiple bits
|
|
this is where looking at endianness matters to determine field placement
|
|
Dont feel like supporting this yet
|
|
X constant regwidth?
|
|
For now, probably limit to only allow the same regwidth everywhere?
|
|
|
|
|
|
X Do not allow unaligned addresses
|
|
All offsets & strides shall be a multiple of the regwidth used
|
|
|
|
X each reg needs to be aligned to its width
|
|
X each regfile/addrmap/stride shall be aligned to the largest regwidth it encloses
|
|
|
|
X Error if a property is a reference to something that is external, or enclosed
|
|
in an external component.
|
|
Limit this check to child nodes inside the export hierarchy
|
|
|
|
! async data signals
|
|
Only supporting async signals if they are exclusively used in resets.
|
|
Anything else declared as "async" shall emit a warning that it is ignored
|
|
I have zero interest in implementing resynchronizers
|
|
|
|
! Error if a property references a non-signal component, or property reference from
|
|
outside the export hierarchy
|
|
|
|
! Add warning for sticky race condition
|
|
stickybit and other similar situations generally should use hw precedence.
|
|
Emit a warning as appropriate
|
|
Or should this be a compiler warning??
|