[spi_device/dv] Verify CDC path when switching to/out of FW mode

[weicaiyang]

Depend on how we decide in #15452

1. We need to have CDC model in the sram, in order to verify this
2. The sequence to switch to or out of FW mode is defined in the CSR section - sram_clk_en

estimate 12
This is from effort estimation exercise

[andreaskurth]

Triaged for spi_device. Assigning to M2.5 with Priority:P1 Priority: high because I think verifying this CDC path is of high importance and we should work on this sooner rather than later.

[johngt]

@cindychip / @msfschaffner to comment or reassign

[johngt]

Assigning to @msfschaffner to forward assign

[msfschaffner]

We are not going to make any FIFO / DPRAM changes to spi_device (as proposed in #15452) before M2.5 due to the invasive nature of that change.

The course of action is to waive the associated CDC messages, and rely on proper sequencing of the mode change / clock change as described here:

opentitan/hw/ip/spi_device/rtl/spi_device.sv

Lines 957 to 975 in 4fbf55e

	// SRAM clock
	// If FwMode, SRAM clock for B port uses peripheral clock (clk_i)
	// If FlashMode or PassThrough, SRAM clock for B port uses SPI_CLK
	// To remove glitch, CG cell is put after clock mux
	// The enable signal is not synchronized to SRAM_CLK when clock is
	// switched into SPI_CLK. So, change the clock only when SPI_CLK is
	// not toggle.
	//
	// Programming sequence:
	// Change to SPI_CLK
	// 1. Check if SPI line is idle.
	// 2. Clear sram_clk_en to 0.
	// 3. Change mode to FlashMode or PassThrough
	// 4. Set sram_clk_en to 1.
	// Change to peripheral clk
	// 1. Check if SPI_CLK is idle
	// 2. Clear sram_clk_en to 0.
	// 3. Change mode to FwMode
	// 4. Set sram_clk_en to 1.

CC @cindychip

[johngt]

CDC enablement was done recently.
@msfschaffner to provide a more up to date comment about this issue given the recent changes.

[msfschaffner]

The course of action was to waive the associated messages in static CDC analysis (which was done by @cindychip), and update the docs in #18102 to note this limitation.

We can therefore move this to the M2.5 backlog so that we can track this issue and fix it properly at a later point in time.

[msfschaffner]

Oh, one thing I should point out: we have two CDC methodologies:

1. static CDC analysis using the RealIntent tool. This has been cleaned up by @cindychip.
2. simulation based insertion of random delays in CDC crossings. this has been enabled on some but not all IPs, yet - see [dv/cdc] Enable CDC instrumentation in all ips #16689.
   I think the one you are referring to was 2), but this issue was referring to 1).

[johngt]

@hcallahan-lowrisc - I believe that you will be working on V2.5 sign-off for SPI_Device.
Just to note this particular path.

[a-will]

FW mode to be removed, so issue is moot.