Add an isolatable CDC module

[LucaRufer]

Motivation: The current implementation of the axi_cdc module has the limitation that it does not allow for one-sided 'warm' resets of the module. This means that the axi_cdc module can "only" be used as a clock domain crossing, but not as a reset domain or power domain crossing with one-sided resets/power-downs.

To get rid of this limitation, this PR adds an isolatable CDC module axi_cdc_isolatable. This new module allows for one-sided resets or power-downs using the isolation signals available on both sides of the CDC crossing. These signals can be used to gracefully separate the two sides of the CDC and reset or turn them off individually, without facing the problem of the CDC FIFO pointers only being reset on one sideb only. Details on these signals can be found in the module description.

The PR adds the following modules:
axi_cdc_isolatable: Isolatable variant of the axi_cdc, allowing for one-sided resets or power-downs.
axi_cdc_src_clearable: Clearable variant of the 'axi_cdc_srcusing the clearable CDC FIFO instead of the 'normal' CDC FIFOaxi_cdc_dst_clearable: Clearable variant of the 'axi_cdc_dst using the clearable CDC FIFO instead of the 'normal' CDC FIFO

Additionally, the PR adds a testbench for the axi_cdc_isolatable module, which was adapted from the axi_cdc testbench. The testbench tests the one-sided resets for the src and the dst side.

[micprog]

I'm a bit confused as to why we need to use a clearable cdc fifo for this implementation and cannot use the existing cdc fifo. In effect, the reset boundary does not need to equal the clock boundary, so you should be able to use the isolate module to properly ensure the slave is not active and set the reset boundary at either side of the CDC, ensuring both sides of the cdc fifo are reset together (or both sides of the cdc fifo are not reset when the slave is reset). This is similar to what we implemented for Carfield. Please let me know if I'm missing something!

[Scheremo]

I'm a bit confused as to why we need to use a clearable cdc fifo for this implementation and cannot use the existing cdc fifo. In effect, the reset boundary does not need to equal the clock boundary, so you should be able to use the isolate module to properly ensure the slave is not active and set the reset boundary at either side of the CDC, ensuring both sides of the cdc fifo are reset together (or both sides of the cdc fifo are not reset when the slave is reset). This is similar to what we implemented for Carfield. Please let me know if I'm missing something!

I think what you suggest is probably correct for Carfield. I think, however, the crux of your point is the reset boundary does not need to equal the clock boundary. Sometimes they cannot be decoupled (e.g. both resets are generated synchronously with two fundamentally asynchronous clocks, might see this in peripherals, or in any system where you don't get to design reset- and clock strategies).

If I understand correctly you suggest to tie both the slow and fast domain reset to the same reset (either slow or fast). Assuming the resets are synchronized to the respective clocks somewhere, this seems (generally speaking) unsafe to me, as reset deassertion can then no longer be statically analyzed against clock period, so likely this would mean the reset has to be modelled as a false path; this is probably okay for systems with "slowly changing resets", but it seems like an unnecessary constraint. Maybe I misunderstood what you were suggesting, or there are some constraints that make this okay?

I think unless there is some clear potential relaxation of constraints that I'm missing, the advantages of having a clearable CDC FIFO with double-sided warm resets are:

1. Simplifies RDC design, as it may coincide with CDC and power domain design
2. Initial CDC and RDC verification (spyglass etc.) can be done on a module level, rather than SoC level (more of a convenience, but speeds up development time)
3. Helps handle AXI protocol compliance after destination domain reset (e.g. clear the entire CDC after reset, as no transactions may be in flight just after resetting the destination) as both ends of the FIFO may be reset in a warm state.

Let me know if I am missing something or misunderstood what you meant!