50 lines
1.8 KiB
Plaintext
50 lines
1.8 KiB
Plaintext
--------------------------------------------------------------------------------
|
|
Field storage / next value layer
|
|
--------------------------------------------------------------------------------
|
|
Where all the magic happens!!
|
|
|
|
Any field that implements storage is defined here.
|
|
Bigass struct that only contains storage elements
|
|
|
|
Each field consists of:
|
|
- an always_comb block:
|
|
- generates the "next value" combinational signal
|
|
- May generate other intermediate strobes?
|
|
incr/decr?
|
|
- series of if/else statements that assign the next value in the storage element
|
|
Think of this as a flat list of "next state" conditons, ranked by their precedence as follows:
|
|
- reset
|
|
Actually, handle this in the always_ff
|
|
- sw access (if sw precedence)
|
|
- onread/onwrite
|
|
- hw access
|
|
- Counter
|
|
beware of clear events and incr/decr events happening simultaneously
|
|
- next
|
|
- etc
|
|
- sw access (if hw precedence)
|
|
- onread/onwrite
|
|
- always_comb block to also generate write-enable strobes for the actual
|
|
storage element
|
|
This is better for low-power design
|
|
- an always_ff block
|
|
Implements the actual storage element
|
|
Also a tidy place to abstract the specifics of activehigh/activelow field reset
|
|
selection.
|
|
|
|
TODO:
|
|
Scour the RDL spec.
|
|
Does this "next state" precedence model hold true in all situations?
|
|
|
|
TODO:
|
|
Think about user-extensibility
|
|
Provide a mechanism for users to extend/override field behavior
|
|
|
|
TODO:
|
|
Does the endinness the user sets matter anywhere?
|
|
|
|
Implementation
|
|
Makes sense to use a listener class
|
|
|
|
Be sure to skip alias registers
|