chipsalliance / aib-protocols

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[LPIF] x1, Gen 1 configurations

arta-eximiusdesign opened this issue · comments

The current llink configuration replicated structure for the x1, Gen1 configurations is too big for 1 AIB channel.

In the half-rate AIB mode, a channel has 80 bits and in the full-rate AIB mode, a channel has 40 bits.

Without going into all the details, we're having trouble fitting into 1 AIB channel and need to expand to 2 AIB channels.

The high-level question is: Can we drop support for x1, Gen1 since it doesn't save any channels over the x2, Gen1 configuration?

If it helps, this is the current structure of the x1 data we send:

dstrm_state 4
dstrm_protid 2
dstrm_data 32
dstrm_dvalid 1
dstrm_crc 1
dstrm_crc_valid 1
dstrm_valid 1
(total = 42)

Gen1 AIB supports 40 bits, but we need to reserve 1 bit for markers (for inter operability) so we need to drop 3 bits from the above if we want to squeeze into a single AIB channel. There are some exotic encodings / alternate features we could discuss. However, before we dive into those, the is squeezing a x1 into a single AIB channel worth spending time / resources on or can we live with two AIB channel for x1?

Related, if that is case, does it make sense to have both a x1 option and a x2 option that operates over two AIB channels or should we just do the x2 over two AIB channels?

commented

I think it is reasonable to drop support for x1. Let's go ahead and make the minimum configuration x2 for AIB gen1 and x4 for AIB gen2.

Hi Michael, are you sure CXL does not require x1 for downtraining?

commented

CXL primarily supports x16/x8/x4 link widths over FlexBus. There is optional support in the spec for x2/x1 links, but these widths are non-standard. We are opting to support x2 only in AIB gen1 to allow for a lower channel count in congested designs. However, neither x1 or x2 are supported with AIB gen2 as a single channel is sufficient for a x4 link.