Interface Description

Section 2.1: Block Description

An overview of the configured IP-Core with the specified or inferred signal widths can be seen in Figure 2.1. All important constants and configured or inferred parameters are also exposed in a vhdl interface package.
Anti-Replay Core (Packet IF) Inner Anti-Replay Core Second Stage Second stage of the physical window implementation. This stage actually holds a bitmap with one bit per window entry. Memory Memory Path: /FrameAdapter0/AntiReplay0/SecondLookupStage0/scl_memory0 Geometry: 16384x512 (8Mib) Latency: 2 Type: MEDIUM Primitive: M20K Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Pipeline register, actually distributed throughout the core. Total latency: 10 Control Logic Control logic w. memories for holding connection status (activation, highest sequence number). Highest sequence number memory and comparisons are split into 1 stages, but only the memory for one is shown here. Memory Memory Path: /FrameAdapter0/AntiReplay0/active0/scl_memory0 Geometry: 2048x1 (2Kib) Latency: 1 Type: MEDIUM Primitive: M20K Memory x1 Memory x1 Path: /FrameAdapter0/AntiReplay0/lastSequenceNumber0/stage0/scl_memory0 Geometry: 2048x64 (128Kib) Latency: 2 Type: MEDIUM Primitive: M20K First Stage First stage of the physical window implementation. Memory Memory Path: /FrameAdapter0/AntiReplay0/FirstLookupStage0/scl_memory0 Geometry: 2048x8 (16Kib) Latency: 1 Type: MEDIUM Primitive: M20K FIFO Fifo Memory Fifo Memory Path: /FrameAdapter0/FrameFifo0/scl_fifo0/scl_memory0 Geometry: 32x524 (16768b) Latency: 1 Type: SMALL Primitive: MLAB FIFO Fifo Memory Fifo Memory Path: /FrameAdapter0/scl_fifo0/scl_memory0 Geometry: 32x3 (96b) Latency: 1 Type: SMALL Primitive: MLAB 512 bit word width 512 bit word width 512 bit word width Command stream: in_cmd_valid (1b) in_cmd_opcode (3b) in_cmd_connectionIndex (11b) in_cmd_sequenceNumber (64b) in_cmd_windowSize (17b) in_cmd Command stream: in_cmd_valid (1b) in_cmd_opcode (3b) in_cmd_connectionIndex (11b) in_cmd_sequenceNumber (64b) in_cmd_windowSize (17b) Input packet stream: in_frame_valid (1b) in_frame_channel (1b) in_frame_startofpacket (1b) in_frame_endofpacket (1b) in_frame_empty (6b) in_frame_error (1b) in_frame_data (512b) in_frame_userdata (0b) in_packet Input packet stream: in_frame_valid (1b) in_frame_channel (1b) in_frame_startofpacket (1b) in_frame_endofpacket (1b) in_frame_empty (6b) in_frame_error (1b) in_frame_data (512b) in_frame_userdata (0b) Result stream: out_result_valid (1b) out_result_data (3b) out_result Result stream: out_result_valid (1b) out_result_data (3b) Output packet stream: out_frame_valid (1b) out_frame_channel (1b) out_frame_startofpacket (1b) out_frame_endofpacket (1b) out_frame_empty (6b) out_frame_error (1b) out_frame_data (512b) out_frame_userdata (0b) out_packet Output packet stream: out_frame_valid (1b) out_frame_channel (1b) out_frame_startofpacket (1b) out_frame_endofpacket (1b) out_frame_empty (6b) out_frame_error (1b) out_frame_data (512b) out_frame_userdata (0b) Command stream: in_cmd_valid (1b) in_cmd_opcode (3b) in_cmd_connectionIndex (11b) in_cmd_sequenceNumber (64b) in_cmd_windowSize (17b) in_cmd Command stream: in_cmd_valid (1b) in_cmd_opcode (3b) in_cmd_connectionIndex (11b) in_cmd_sequenceNumber (64b) in_cmd_windowSize (17b) Result stream: out_result_valid (1b) out_result_data (3b) out_result Result stream: out_result_valid (1b) out_result_data (3b)
Figure 2.1: Block diagram of the Anti-Replay Core. Hover over labels for details.
The "Packet IF" is a wrapper around the inner, actual Anti-Replay Core. The input stream for commands and the output stream for results is described in detail in Section 2.3. The packet based input and output streams are described in Section 2.4. Potential signals for external memories as well as clock and reset signals are handled on separate pages. For example waveforms, see Page Example Waveforms.

Section 2.2: Common Signals

All streams are Avalon-Streams with one particularity: They share a common ready signal, that is, both input streams share a ready signal and both output streams share one. This is necessary because results are associated with packets and having a common output ready signal ensures that result and packet streams can not be forced out of sync. The IP-Core in turn gives the same guarantee, that input command and packet streams can only be ready simultaneously, an thus has only one input ready signal. Signals common to all ports are listed in Table 2.2.
Field Name Width In/Out/Meta Description
clock 1b in Clock of the IP-Core
in_ready 1b out Shared ready signal for command and input packet streams
out_ready 1b in Shared ready signal for result and output packet streams
Table 2.1: Signals common to command/result and packet streams.

Section 2.3: Command and Result Streams

The core is controlled by issuing commands on the command stream. All commands are processed in order and their effects are causal: A command only affects subsequent operations/commands, not preceding ones. Commands can be issued during a packet frame or outside of it. Their interaction with packets/frames are described in Section 2.4.
The signals of the command interface can be seen in Table 2.2.
Field Name Width In/Out/Meta Description
in_cmd_valid 1b in Whether the lookup request is valid.
in_cmd_opcode 3b in Indicates the operation to be performed. See Table 2.3
in_cmd_connectionIndex 11b in For commands referring to a specific connection (OpUpdate, OpActivate, OpDeactivate, OpSetSeqNr), the connection index..
in_cmd_sequenceNumber 64b in In case of OpSetSeqNr the sequence number to set, in case of OpUpdate the new sequence number, otherwise unused.
in_cmd_windowSize 17b in In case of OpSetWindowSize the new virtual window size to use for all connections.
Table 2.2: Input command stream signals and parameters.
Opcode Binary Representation Meaning
OpUpdate b000 Initiates an actual replay check for the given sequence number and connection index, triggering a reply on the result stream. Also updates the internal state as having received that packet.
OpActivate b101 Activates replay checks for a given connection index. OpUpdate querries on that connection index will no longer return PassCheckDisabled.
OpDeactivate b001 Deactivates replay checks for a given connection index. OpUpdate querries on that connection index will return PassCheckDisabled.
OpSetSeqNr b010 For a given connection index, clears and initializes the list of all seen packets to the given sequence number, so that all other sequence numbers are deemed unseen. Connections are disabled and uninitialized on reset. Use OpSetSeqNr and a sequence number of 0 to initialize a connection.
OpSetWindowSize b011 Sets the virtual window size for all connections. This can also be larger than the actual physical size. The reset value equals the physical window size to effectively disable the virtual window feature.
Table 2.3: Opcodes of the input command stream and their meaning. All opcodes can also be found in the vhdl interface package as vhdl constants.

The request signal is composed of a code, that indicates the type of request, and arguments to that request. The possible codes and their binary representation are listed in Table 2.3. Most requests configure the core and do not trigger a response. Only the actual replay check OpUpdate prompts a result on the output result stream, the composition of which can be seen in Table 2.4. The binary representations of the result codes were chosen such that the least significant bit indicates whether the packet sequence number passed or failed the replay check.
Field Name Width In/Out/Meta Description
out_result_valid 1b out Whether the output is valid.
out_result_data 3b out Result code of the operation. See Table 2.5.
Table 2.4: Input stream signals and parameters.
Opcode Binary Representation Meaning
PassAboveWindow b001 The packet is deemed new because its sequence number was larger than the largest so far seen sequence number for that connection.
PassCheckDisabled b011 The packet is deemed new because actually checking was disabled for that connection.
PassInVirtualWindow b101 The packet is deemed new by definition because its sequence number is older than the physical window size but still within the virtual window size. This never occurs if the virtual window size is set to be equal or smaller than the physical one.
PassInPhysicalWindow b111 The packet is deemed new because it falls within the virtual and physical windows and had not been marked as having been seen before.
FailBelowWindow b000 The packet is deemed a replay because it is older than the virtual window size.
FailReplay b010 The packer is deemed a replay because it fell within the virtual and physical windows and had been marked as having been seen before.
Table 2.5: Result codes of the result output stream and their meaning. Note that the binary outcome of the test can be checked from the least significant bit alone. All result codes can also be found in the vhdl interface package as vhdl constants.

Section 2.4: Packet Streams

The packet input (see Table 2.6) and output (see Table 2.7) streams follow the usual semantics of packet based streams. The content is forwarded through an internal fifo to the output and largely ignored.
Field Name Width In/Out/Meta Description
in_frame_valid 1b in Indicates that the current beat is a valid one.
in_frame_channel 1b in Identifies the channel to which the beat belongs.
in_frame_startofpacket 1b in Indicates the start of a packet. Requests issued on the same beat or any following beat until (and including) EOP are considered to happen during the packet.
in_frame_endofpacket 1b in Indicates the last beat of a packet.
in_frame_empty 6b in Can be used to indicate how many words of the payload contain valid data. This is useful for packets whose total size is not a full multiple of the packet stream payload size. The signal is only forwarded but otherwise ignored by the core.
in_frame_error 1b in Indicates errors.
in_frame_data 512b in Packet payload
in_frame_userdata 0b in User defined data that is passed through.
Table 2.6: Input packet stream signals and parameters.
Field Name Width In/Out/Meta Description
out_frame_valid 1b out Indicates that the current beat is a valid one.
out_frame_channel 1b out Identifies the channel to which the beat belongs.
out_frame_startofpacket 1b out Indicates the start of a packet. Requests issued while receiving a packet will yield a result at the earliest on the corresponding beat of the outgoing packet.
out_frame_endofpacket 1b out Indicates the last beat of a packet.
out_frame_empty 6b out Can be used to indicate how many words of the payload contain valid data. Simply forwarded from the input packet stream.
out_frame_error 1b out Indicates errors.
out_frame_data 512b out Packet payload
out_frame_userdata 0b out User defined data that is passed through.
Table 2.7: Input packet stream signals and parameters.