[i2c] Clean up target mode transaction boundaries and NACK handling

[a-will]

Change recording of Start symbols to always accompany the address data,
instead of recording a separate R.Start, then Start+address. This helps
maintain certain availability invariants needed for reliable stretching
and NACK handling.

Note that a controller that chooses to do a Repeated Start and address a
different target is an unusual case, and it leads to a situation where
the transfer closing symbol won't appear until the Stop or a later
Repeated Start that does address this target. While this transaction
style is not explicitly forbidden in the I2C specification, it is not
typically supported in the wild. In any case, software should be able to
resolve this case, and a closing symbol will eventually appear.

Fix up the DV transaction generation to match the expected behavior.

Remove the extra NACK-specific states, generate ACQ FIFO entries at the
point of the NACK timeout, and go to WaitForStop to release SDA and SCL.
Return 0xFF on reads for NACK'd transactions.

Add NackStop as an ACQ FIFO value to indicate the end of transactions
that had errors (generally, NACK'd transfers).

Fix up the glitch sequence to better handle the various states.

Finally, add a StretchAcqSetup state to force the target FSM to maintain the required setup time for the ACK bit it started driving.

[a-will]

After this PR, the DV regression is looking substantially better:

I2C Simulation Results

Monday April 08 2024 18:31:07 UTC

GitHub Revision: 9cd8512681

Branch: i2c-target-cleanup

Testplan

Simulator: VCS

Test Results

Stage	Name	Tests	Max Job Runtime	Simulated Time	Passing	Total	Pass Rate
V1	target_smoke	i2c_target_smoke	6.010s	4.329ms	5	5	100.00 %
V1		TOTAL			5	5	100.00 %
V2	target_error_intr	i2c_target_unexp_stop	1.050s	941.057us	0	5	0.00 %
V2	target_glitch	i2c_target_glitch	2.910s	2.461ms	5	5	100.00 %
V2	target_maxperf	i2c_target_perf	0.310s	105.488us	0	5	0.00 %
V2	target_fifo_empty	i2c_target_intr_smoke	1.860s	14.778ms	5	5	100.00 %
		i2c_target_stress_rd	19.130s	2.344ms	5	5	100.00 %
V2	target_fifo_reset	i2c_target_fifo_reset_acq	11.770s	10.033ms	5	5	100.00 %
		i2c_target_fifo_reset_tx	12.290s	10.051ms	5	5	100.00 %
V2	target_fifo_full	i2c_target_intr_stress_wr	10.860s	15.368ms	5	5	100.00 %
		i2c_target_stress_wr	35.710s	53.386ms	5	5	100.00 %
		i2c_target_stress_rd	19.130s	2.344ms	5	5	100.00 %
V2	target_timeout	i2c_target_timeout	2.190s	1.321ms	5	5	100.00 %
V2	target_clock_stretch	i2c_target_stretch	5.565m	30.367ms	5	5	100.00 %
V2	bad_address	i2c_target_bad_addr	1.440s	1.742ms	5	5	100.00 %
V2	target_mode_glitch	i2c_target_hrst	0.920s	494.797us	5	5	100.00 %
V2		TOTAL			55	65	84.62 %
		TOTAL			60	70	85.71 %

The results prior to this PR had many more failures. As for the remaining two... It appears i2c_target_unexp_stop doesn't apply its stimulus correctly, never appending the 0xFF byte to transmit on reads (forcing the target to release SDA and make a Stop possible), leading to FIFO states not matching. The ACK STOP sequence detection does appear to work, however.

For i2c_target_perf, the timing parameters seem to lead to the host agent generating stimulus with bogus timing. SDA and SCL are transitioning simultaneously, causing Start and Stop conditions to trigger after random CDC delay insertion.

[engdoreis]

I think that FDATA.NAKOK should be renamed to FDATA.NACKOK for consistency.

[a-will]

While I agree, I am going to defer all such non-functional cleanups until after the RTL is feature complete. (stuff like this that will spread into a lot of files, I mean)

[hcallahan-lowrisc]

These changes seem sensible to me. Thanks @a-will

[hcallahan-lowrisc]

nit: This first sentence doesn't make much sense.

[a-will]

Fixed up all the descriptions.

[hcallahan-lowrisc]

This comment is stale

[a-will]

Right you are! Removed and replaced.

[a-will]

Failures are unrelated. Merging.