Configurable RWDS sampling and clock-start delay.

[phsauter]

A finalized version of #20
Requires #28 and #29

Current State: Tested in RTL simulation

During the Command-Address block of read and writes (except for zero-latency writes), the RWDS signal must be sampled to determine the additional latency required (1x the configured value if it is LOW, 2x if it is HIGH).
RWDS is driven from the device some times after CS is driven low by the controller and it is de-asserted by the device synchronous to the CK edge during the time the last CA data is stable.

For the worst case timing (t_DSV max, t_CSS min and t_CKDS min) the RWDS signal is only valid for about one clock period (two cycles to three cycles after CS going low).
It is important to mention that according to spec, the RWDS signal from the device and the clock start from the host are both referenced to the CS going low edge but not each other. Meaning in the case of a slower than spec'd clock, RWDS may arrive earlier than expected (even before the clock starts).

This presents us with two problems:

1. We must ensure we sample at exactly the right time to capture the correct RWDS data.
2. Given a long chip-to-chip path (or slow pads), the arriving RWDS signal might be shifted back, meaning the valid window is at the end or even beyond the end of the outgoing CA block.

Fixing 1:
Solved by adding a separate module that counts clock edges after CS going low. This then enables a clock gate, propagating a single clock pulse to the sampling flip-flop. The exact edge where the sampling should occur is configurable.
A second flip-flop is added to cross the signal into the clk_phy domain the main FSM is in.

Fixing 2:
Two additions were made:

1. There is a configurable CS going low to clock-start delay which can give the FSM more time to work before it needs to start the RWDS sampling process.
2. Applying the additional latency is delayed from the Command-Address phase to the end of the first latency. This increases the available time for RWDS sampling by at least three cycles (depending on the configured latency).

Together the clock-start and RWDS sampling time are a lot more configurable and should greatly increase the control, especially when operating with out-of-spec frequencies.

See Figure 9.4 and 9.5 in the spec (read timing diagrams) as well as table 9.4 (AC parameters). Consider that the diagrams are not to scale for a worst case transaction, t_DSV in particular is way too small.

The attached image show the relevant signal of the new RWDS sampler. The chip select to clock-start time tcs->ck can be increased from the minimum of one clock cycle. trwds can be changed in 1/2 clock cycles steps with the minimum being 0.5 clock cycles (corresponding to the falling edge immediately after CS going low)

[phsauter]

I had another look at the design and spec. This PR is not needed.
In particular the t_CSS of 0.4 cycles can never occur in our design. To ensure protocol correctness the earliest we can pull chip select low and enable the clock gate is on the falling edge of the non-delayed clock. Then half a cycle later the rising edge occurs and the delayed clock is another 0.25T later, so in total a 0.75T minimum t_CSS enforced by the architecture (specifically the design to delay the clock).
This means the latest stable RWDS is 1.25T after the delayed clocks first rising edge or 1.5T after the non-delayed clock. Therefore the minimum valid RWDS window around the third falling edge of the non-delayed clock is 1T before and 0.25T after (not accounting for pad delays). This is very resilient against timing variations and additional delays and should be used as THE one sampling edge.

Meaning the complex RWDS sampler here is not needed. It was only necessary under the previous too conservative t_CC >= 0.4T assumption, which does not hold.