AMD Alchemy Au1550 Security Network Processor Data Book
191
Security Engine
30283D
The host may track the command queue status by waiting for a corresponding Result Descriptor to have been produced by
the security engine—there is always a 1-to-1 correspondence. Alternatively, the host can read the sec_glbqstat register to
determine if the command queue can accept another entry.
When descriptors are written into the command queue, the ownership bits are ignored. The descriptor is always assumed
to be immediately valid.
When using this mode, the Result Descriptor Ring (RDR) must be located in system memory.
Descriptor Fetch Processing
When the descriptor fetch engine is enabled, the security engine expects the Packet Descriptor Ring (PDR) to be located in
system memory. The DMA engine is used to fetch entries from this ring and read them into the internal command queue
where they are then processed. There are a couple of parameters which control the operation of the descriptor fetch
engine:
Once either the Ring Poll or Read Descriptor Interrupt event has occurred, a DMA request is queued to fetch one descriptor
from the “current” pointer within the PDR. Once in the command queue, the descriptor is checked to determine if the own-
ership bits are set. If not, that descriptor is discarded from the command queue. Those descriptors which do have the own-
ership set are queued for sequential processing by the Packet Engine.
RDR Processing
The Result Descriptor Ring (RDR) can be viewed as a separate entity from the PDR, although in some configurations they
overlap. The RDR is typically the same size as the PDR. One RDR entry is written for each PDR entry processed. There is
always a one-to-one correspondence, regardless of any error event encountered during processing.
The Result Descriptor has most of the Packet Descriptors fields updated. The following table shows the behavior for each of
the fields:
Descriptor Field
Result Descriptor
sec_qctrlstat
Control
Bit 0, HD=0: Host not done
Bit 1, CD=1: Security engine done
Bits 2-7: Same as packet descriptor
Next Header/Pad
For IPsec Outbound, the Next Header byte is updated to reflect the result after
processing. For example, a successful ESP returns 50.
For IPsec Inbound, the Next Header byte provides the extracted Next header
byte.
For other operations, it returns a 0.
Status
The status is marked valid.
Pad Control/Status
For IPsec and PKCS #7 pad modes, the Pad Status byte indicates the number
of pad bytes detected
For Zero Pad and Constant Pad modes, this field returns a 0
sec_qsrcaddr
Source Address
Same as packet descriptor
sec_qdstaddr
Destination Address
Same as packet descriptor
sec_qsaaddr
SA Handle
Same as packet descriptor
sec_qlenctrl
Length
Result length is updated
Control 2
Ownership bits = 0b10 – “Security engine done”
—
Reserved.