Traffic capture of raw primitives

[bluecmd]

From playing around with fejkon with some actual FC traffic it has become clear that there will be a need to capture behavior on the primitives.

For example when debugging why Brocade loopbacks wouldn't come up in #26 it seems the Brocade switch sends a bunch of primitives that fejkon 1) does not know about and 2) implementing would be infeasible.

Switching to xcvr <-> xcvr based mode is in progress which means that supporting this kind of traffic will be done, but in order to analyze this kind of low-level traffic there needs to be a way to capture essentially a waveform of the primitives.

I have been thinking about something like this:

                        csr
                         +
                         |
                    +----v---------+           +------------+
                    |              |           |            |
    +---------+     |              +---------->+   Memory   <-------+
+-->+  Port 0 +---->+              |           |            |       |
    +---------+     |      RLE     |           +------------+       |
    +---------+     |    Encoder   |           +------------+       |
+-->+  Port 1 +---->+              |           |            |       |
    +---------+     |              +---------->+   Memory   <-------+
                    |              |           |            |       |
                    +-----^--------+           +------------+       |
                          |                                         |
                          +                                         |
                      106.25 MHz                                    |
                                                                    |
                                                                    |
                                                                    +
                                                                  Data

Writing to a fixed-sized memory should allow one to trigger a ~synchronized capture of Port 0 and 1 being written to two memories encoded using RLE. A simple data format such as 64-bit formatted as 24-bit count | 4-bit metadata | 4-bit K-value | 32-bit value should be fine. 24-bit counter means that a fully idle stream will write out 7x idle frames every second as the counter wrap around is reached. This should be ample for our needs.

[bluecmd]

Framer state will likely not be part of the metadata, as this will be driven by observed traffic only. It would be a huge pain to try to align the state transitions to be cycle accurate as well.

[bluecmd]

Making the encoder have 4 inputs and 4 memories is probably the easiest to scale up when the other ports are activated. The chip has up to 6.25 MiB block memory, so reserving something like 256 KiB per port seems fine (configurable?).