[major] Fine-grind parameters and capabilities for memories

[CircuitCoder]

This PR changes memory statements in FIRRTL to allow more fine-grind control over parameters on memories, allowing:

• Per-port read / write latency
• Write ports with no masks

In short, a memory in the syntax proposed in this PR would look like this:

mem mymem:
  data-type => {real:SInt<16>, imag:SInt<16>}
  depth => 256
  read-under-write => undefined
  port r1:
    read => yes
    write => no
    read-latency => 0
  port r2:
    read => yes
    write => no
    read-latency => 0
  port w:
    read => no
    write => with-mask
    write-latency => 1

Note that this will be a breaking change. Although it would be easy to make the old port declaration syntax (e.g. reader => r1 ) a shorthand for the new ones, signal names is also different in this new approach (e.g. wdata vs data for writers). It would add a lot of burden to the spec to have different signal names in ports with different sets of capabilities.

This is a draft PR. The ideas presented here is still in early design stage, ~~and we've not yet added changelogs for it.~~

Pending problems

Port-pairwise read-under-write policy

In theory, there might be memories that have different read-under-write policies between different pairs of ports. If we would like to characterize such behavior, we would need to allow specifying RUW policies for all (ordered) pairs of ports in the form of, let's say, a matrix.

Though possible, we believe this would be a highly uncommon scenario. So another way of settling this is to allow a special value indicating a non-existing or non-standard global read-under-write policy for the memory instance, and allow compilers and tools to have their own implementation-dependent way of specifying those policies:

mem m1:
  read-under-write: non-standard

Another way is to simply provide no support such memories. Users would need to resort to using extmodules.

Alternative read / write latency syntax

Currently from a pure syntactical POV, we doesn't enforce ports that have read capability to have a read-latency settings. We may make this requirement purely syntactical by requiring users to provide latencies when specifying capabilities, e.g.:

mem m1:
  port rw1:
    read: yes, 1
    write: no-mask, 2

Backward compatibility

To make this new syntax backward compatible, we would have to:

1. Make the old reader => r1 a shorthand for the new syntax.
2. Allow read-latency and write-latency in global scope, and specify the validity and semantics of ports that have no read / write latency specified, or two incompatible values specified.
3. Make ports with different capabilities have different signal names.

[sequencer]

We may need an additional custom port for mbist/dft. This port will be ignored in the behavioral simulation. But exist in the post synthesis flow.

[CircuitCoder]

@sequencer Is it sufficient to have a extra-type in port instantiations, which will result in a corresponding signal generated in the port?

mem m1:
  port r1:
    extra-type => {meow:SInt<16>, meowmeow:SInt<16>}
  // ...

m1.r1.extra

[sequencer]

another thing to mention is: it's not possible to emulate the behavior for different DFT/MBIST implementation. I think it's necessary to forbid compiler to lower behavior memory with the custom port being configured.

[CircuitCoder]

@sequencer Then it's more convenient to define the behavior of custom ports during behavioral simulations to be completely undefined.

Updated in e6311a7