e does not actually apply the beam weight but preconfigures the various components to hold a specific "new" beam. Typically, this step involves writing a single "index" value to the RFIC. Weight application involves applying the selected beam weights as well as the settling time associated with the analog on-chip and off-chip components. We assume weight application to be done by means of a unique GPIO signal that allows for highest speed [targeting the 100-200 ns beam switching time or a fraction of the OFDM Cyclic Prefix (CP)]. Typical RF subsystems for mmWave include multiple RFICs, each supporting only 2-4 PAs. This allows the RFIC design to be simplified, whilst keeping the RF antenna close to the RFIC (minimize RF losses) and providing scalability by cascading multiple RFICs. But, each RFIC needs individual control signaling for Rx/Tx switching, as well as beam weight assignment/selection/application. Typical signaling is implemented by a combination of I2C (2 wires) or SPI (4-5 wires) for programming beam weights, combined with SPI or GPIO for Rx/Tx switching and weight application triggering. Assuming a 50 MHz SPI clock and 100 bits/weight update, each RFIC requires 2 us programming time. This means SPI chaining cannot (or only to very limited extend) be used: the latency implication would directly impact beam weight assignment cost. The obvious challenge with this approach is the impact on Baseband SoC I/O connectiv- ity. The number of low-speed I/O between baseband SoC and RF subsystem can grow pro- hibitively large. For example, assuming a SPI controlled RFIC that implements 8x PA + LNA and a 512 AE subsystem would require (512/8 X 4 = ) 256 SPI I/O elements on the baseband Typical systems solve this challenge by adding an FPGA to the system that provides the fanout by translating a single (or a few) SPI interfaces from the baseband SoC to a large amount of individual SPI connections to each RFIC. The FPGA can additionally implement the logic to calculate the appropriate individual weights to each RFIC