GIC_400 contains the following CADI targets:

• GIC_400

GIC_400 contains the following MTI components:

• 4.70 GIC_400 - trace
• 4.105 PVBusSlave - trace

GIC_400 - about

This component is a wrapper that permits easier configuration of the v7_VGIC component that supports parameterized configuration.

The GIC-400 has several memory-mapped interfaces at the same address. The processor that is communicating with the GIC-400 banks them. The GIC-400 must be able to distinguish from which processor a transaction originates. In the hardware, the AUSER fields on AXI supply this information to the GIC-400. In Fast Models, there is no exact equivalent to this field. However, each transaction has a master_id that the model can use to identify the originating processor.

ARM^® clusters assign the master_id as follows:

• Bits[31:16]: SBZ (which the GIC-400 ignores).
• Bits[5:2]: CLUSTERID.
• Bits[1:0]: cpu_id within cluster.

CLUSTERID is the 4-bit field that either a parameter on the processor sets or a value on the clusterid port drives. CPUID is the core number within the cluster. CLUSTERID appears in the CP15 register space as part of the MPIDR register.

The ARM architecture suggests that each cluster in the system is given a different CLUSTERID. This distinction is essential for the VGIC to identify the cluster. The parameters in the GIC-400 component permit it to construct the map of master_id to interface number.

Processor interfaces that the GIC-400 supports have these parameters:

• interfaceN.cluster_id.
• interfaceN.core_id.
• interfaceN.inout_port_number_to_use.

N is the interface number (0-7). The cluster_id and core_id tell the GIC-400 to map that cluster or core combination to interface N.

In using inout_port_number_to_use, the GIC-400 has some input and output ports that pair with a particular processor interface. For example:

• The irqcpu[] pin wires to the irq port of the corresponding processor.
• The cntpnsirq pin from the processor wires to a cntpnsirq[] pin on GIC-400 to transport a Private Peripheral Interrupt (PPI) from the processor to the GIC-400.

The interfaceN.inout_port_number_to_use parameter supports clusters that can have variable numbers of cores. It tells the GIC-400 that to send to or receive a signal from the processor that is attached to interface N, it must use these pins:

• irqout[interfaceN.inout_port_number_to_use].
• fiqout[interfaceN.inout_port_number_to_use].
• virqout[interfaceN.inout_port_number_to_use].
• vfiqout[interfaceN.inout_port_number_to_use].
• legacyirq[interfaceN.inout_port_number_to_use].
• cntpnsirq[interfaceN.inout_port_number_to_use].
• cntpsirq[interfaceN.inout_port_number_to_use].
• legacyfiq[interfaceN.inout_port_number_to_use].
• cntvirq[interfaceN.inout_port_number_to_use].
• cnthpirq[interfaceN.inout_port_number_to_use].
• ...

legacyirq and legacyfiq are not signals from the processor but are signals into the GIC-400 from the legacy interrupt system. They are wired to PPIs. If the control registers of the GIC-400 are set up in particular ways, they can also bypass the GIC-400. See the ARM Generic Interrupt Controller Architecture version 2.0 Architecture Specification for more information.

The fabric between the clusters and the GIC might remap the master_id of a transaction. If so, then the GIC might lose the ability to identify the originating processor. The fabrics that ARM ships in Fast Models perform no such transformation.

The comparison that the GIC-400 performs on the master_id is only on the bottom 6 bits of the master_id. It ignores the rest. If you are writing your own fabric and do not properly propagate the master_id or transform it, the GIC-400 might not be able to identify the processor. The source code for the GIC_400 component can be examined to see how it might be adapted for it to understand different master_id schemes.

The GIC-400 model has these limitations:

• Reads and writes to GICD_ISACTIVERn/GICD_ICACTIVERn/GICD_ISPENDRn/GICD_ICPENDRn might not work as expected unless there is a configured target in GICD_ICFGRm.
• Some of the interaction of GICD_CTLR.EnableGrpX and level sensitive interrupts might not work entirely correctly.
• It does not model the signals nIRQOUT/nFIQOUT.
• It models interrupts with positive logic, rather than the negative logic that the hardware uses. Hence, the signal pins omit the "n" prefix in their names.