Increased range of SACI_NUM_CHIPS_G to support more than 4 chips

[hsandber]

Description

The AxiLiteSaciMaster currently has a fixed limit of four ASICs ("chips"). This has been increased to six to work with a new readout system with that many ASICs.

Details

The new 3x2 Readout (https://confluence.slac.stanford.edu/x/eKRxG) seems to be first system to use more than four ASICs with a common SACI interfaces. There is no mention why only four chips were allowed previously. The hardware will arrive in a couple of weeks with which we can test running SACI with six chips, but from the code alone I don't see any reason why more than four would not work.

[ruck314]

@hsandber The "why 6 and not 8 or more question"..... What's the upper limit that we could support in the way the code is currently structured?

[hsandber]

@ruck314 From the hardware side, the limitations would be from the capacitive loading on the common SACI signals (clk, cmd and rsp). I’m 👍 on removing the limitation altogether from the surf library and leave it to the user to evaluate for each application.

Would probably benefit from a test bench that exercise “large” number of chips and corner cases in that case to make sure nothing else in the module breaks. The current test bench seems to only have one chip.

[ruck314]

@hsandber

v.chip := axilWriteMaster.awaddr(22+CHIP_BITS_C-1 downto 22);

Seems like the FW limit is SACI_NUM_CHIPS_G(limit) = 2^(31 -22) = 512, where 31 is the max. AXI-Lite address bit and 22 is the chip address index.

I could imagine in the future that we would need to support 8 (or more) chips on a bus in the future. Should we change this to SACI_NUM_CHIPS_G : positive; with no constraint on the range to match SaciMaster2?
https://github.com/slaclab/surf/blob/main/protocols/saci/rtl/SaciMaster2.vhd#L33
.... Or we could change it to SACI_NUM_CHIPS_G : positive range 1 to 6 := 512; to reflect the actual FW limit