exact match binary cam search ip for sdnet …...exact match binary cam search ip for sdnet 7 pg189...

Exact Match Binary CAM Search IP for SDNet

SmartCORE IP Product Guide

PG189 (v1.0) January 29, 2019

Exact Match Binary CAM Search IP for SDNet 1PG189 (v1.0) January 29, 2019 www.xilinx.com

Table of ContentsChapter 1: Overview

Licensing and Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2: Product SpecificationPerformance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Register Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 3: Designing with the CoreGeneral Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 4: Design Flow StepsConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Output Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Appendix A: Upgrading

Appendix B: DebuggingFinding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Appendix C: Application Software DevelopmentData Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Device Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Device Management API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Send Feedback

https://www.xilinx.com

https://www.xilinx.com/about/feedback.html?docType=Product_Guide&docId=PG189&Title=Exact%20Match%20Binary%20CAM%20Search%20IP%20for%20SDNet&releaseVersion=1.0&docPage=2


Appendix D: Additional Resources and Legal NoticesXilinx Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Documentation Navigator and Design Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Send Feedback



Exact Match Binary CAM Search IP for SDNet 3PG189 (v1.0) January 29, 2019 www.xilinx.com Product Specification

IntroductionThe Exact Match Binary CAM Search IP for SDNet SmartCORE IP implements an associative array data structure also known as a content-addressable memory or CAM. The CAM stores {key, value} entries with arbitrary key and value bit strings and allows the retrieval of ‘value’ based on an exact match of all bits in ‘key’.

Features• Associative array containing arbitrary

{key,value} pairs• “Exact match” key lookup returns hit/miss

result and associated data on hit• Supports update through software via

AXI4-Lite or through a dedicated hardware interface

• Optional aging mode automatically removes the entries after a programmable period of inactivity

• Supports marking individual entries as “static” to prevent them from being deleted when aging mode is enabled

• Efficient implementation using 1.25 block RAM bits per entry bit (~1.33 with aging)

IP Facts

SmartCORE IP Facts TableCore Specifics

Supported Device Family

Kintex® UltraScale™Virtex® UltraScale

Kintex UltraScale+™Virtex UltraScale+

Zynq® UltraScale+™ MPSoCKintex-7Virtex-7

Spartan®-7Supported User Interfaces Lookup, Update and AXI4-Lite Interfaces

Resources See Table 2-1Provided with Core

Design Files Encrypted register transfer level (RTL) orNetlist

Example Design Not ProvidedTest Bench VerilogConstraints File Not ProvidedSimulation Model VerilogSupported S/W Driver(1) Standalone

Tested Design FlowsDesign Entry SDNet(2)

SimulationVivado® Simulator

Mentor Graphics QuestaAdvanced Simulator

Synthesis Not ApplicableSupport

Provided by Xilinx at the Xilinx Support web page.

Notes: 1. Stand-alone driver details can be found in the software

development kit (SDK) directory (<install_directory>/SDK/<release>/data/embeddedsw/doc/xilinx_drivers.htm). Linux OS and driver support information is available from the Xilinx Wiki page.

2. See the SDNet Packet Processor User Guide (UG1012) [Ref 4].

Send Feedback


https://www.xilinx.com/support



http://wiki.xilinx.com

http://wiki.xilinx.com

https://www.xilinx.com/cgi-bin/docs/rdoc?v=2016.1;t=vivado+release+notes



Chapter 1

OverviewThe CAM stores {key, value} entries in block RAM with arbitrary key and value bit strings and allows the retrieval of ‘value’, based on an exact match of all bits in ‘key’. The CAM uses an algorithmic lookup to provide efficient usage of Xilinx FPGA resources. This is in contrast with simple Ternary Content Addressable Memory (TCAM) implementations that store the keys in flip-flops and use logic resources for parallel key comparison. The CAM is able to achieve very high RAM utilization. Typically 85-90% of the maximum RAM capacity can be used for {key, value} storage depending on the configuration.

The CAM receives a lookup key on the Lookup Request interface and outputs the result of the lookup on the Lookup Response interface after a fixed number of cycles. The result contains a hit/miss flag indicating whether the key was found in the CAM. If the key is found (“hit” condition), the value associated with the key is output as well. The AXI4-Lite interface can be used to perform insertions and deletions via a CPU.

The CAM optionally supports an automatic aging mode. When aging is enabled, the CAM removes the keys that have not been accessed via the Lookup Interface for a programmed period of time. Inserting, updating or looking up a key resets its aging timer. In addition, when aging is enabled, individual entries can be marked as “static” such that they are not deleted from the CAM. When enabled, the aging timeout is the same for all entries (except those marked as static).

The CAM was originally developed as an individual IP, and it has been incorporated into being generated by the SDNet compiler as a Lookup Engine. The interface for the CAM when generated from SDNet has been wrapped and simplified to expose: a) an AXI4-Lite control interface, b) a search interface with a key, and c) a response interface with a hit/miss, value.

Licensing and OrderingNote: Customers who pay a license fee for SDNet are then are able to use the IP such as this CAM as they want for free.

For more information, visit the SDNet Development Environment page.

Send Feedback


https://www.xilinx.com/products/design-tools/software-zone/sdnet.html



Chapter 2

Product SpecificationThis chapter includes information about the performance, resource utilization, and the port descriptions of the CAM. Figure 2-1 shows a high-level block diagram of the CAM with an AXI4-Lite interface.

PerformanceThe CAM can continuously sustain a rate of one lookup per clock cycle.

Maximum FrequenciesThe CAM is designed to run at 150 MHz in Virtex®-7 -2 speed grade devices. Higher frequencies can be achieved depending on the configuration and the target device. See Table 2-1.

X-Ref Target - Figure 2-1

Figure 2-1: CAM with an AXI4-Lite Interface

LookupRequestInterfaces

AXI4-Lite

RuleDatabase

AXI4 Slave

LookupResponseInterfaces

Update/Aging FSM

Register Map

X20015-110217

Send Feedback




Chapter 2: Product Specification

LatencyThe lookup latency is 3 cycles (4 ns at 150 MHz). The CAM supports an update rate of up to 0.5% of the maximum lookup rate. The update latency is variable and depends on the fill level and aging mode. If the CAM is near capacity, updates can take approximately 200 clock cycles (1.3 μs at 150 MHz) to complete.

ThroughputBecause the CAM processes one lookup per cycle on the Lookup Interface, with a clock frequency of 150 MHz, the CAM performs 150 million lookups per second. Throughput can be expressed as follows:

Throughput [Mp/s] = Clock Frequency [MHz]

Resource Utilization Virtex-7 Devices Table 2-1 provides approximate resource counts for the various core options on Virtex®-7 devices.

Table 2-1: Device Utilization and Maximum Frequency - Virtex-7 FPGAsParameter Values(1) Device Resources

Key width (K),Value width (V),

Depth (D),Aging (AGING),

AXI Update (AXI_UPD)

Slices LUTs FFs Block RAMs(36Kb)

Max Freq(MHz)

(-2 speed grade)

K=64 V=16 D=4KAGING=1 AXI_UPD=0 760 1937 1693 15 213

K=128 V=32 D=16K AGING=1 AXI_UPD=0 1592 3480 3037 101 176

K=256 V=64 D=32K AGING=0 AXI_UPD=1 3777 8281 5972 405 155

Notes: 1. A complete list of the synthesis-time configuration parameters is given in Configuration in Chapter 4.

Send Feedback





Port DescriptionsThe following sections describe the ports.

Clock and Reset

AXI4-Lite (Optional)The AXI4-Lite interface is implemented only when the configuration option AXI_UPD is set to 1 to select the AXI4-Lite Update interface. In this case, the hardware update and the system interfaces are not implemented.

Table 2-2: Clock and Reset DescriptionsSignal Name Direction Width DescriptionRst Input 1 Synchronous active-High resetClk Input 1 Clock for Lookup and Update interface

Table 2-3: AX14-Lite SignalsSignal Name Direction Width Description

AXI Global System Signals (1)S_AXI_ACLK Input 1 AXI ClockS_AXI_ARESETN Input - AXI Reset, active-Low

AXI Write Address Channel Signals (1)

S_AXI_AWADDR Input 32AXI Write address. The write address bus gives the address of the write transaction.

S_AXI_AWVALID Input 1Write address valid. This signal indicates that valid write address and control information are available.

S_AXI_AWREADY Output 1Write address ready. This signal indicates that the slave is ready to accept an address and associated control signals.

AXI Write Data Channel Signals (1)

S_AXI_WDATA Input 32 Write data

S_AXI_WSTB Input 4Write strobes. This signal indicates which byte lanes to update in memory.

S_AXI_WVALID Input 1Write valid. This signal indicates that valid write data and strobes are available.

Send Feedback





S_AXI_WREADY Output 1Write ready. This signal indicates that the slave can accept the write data.

AXI Write Response Channel Signals (1)

S_AXI_BRESP Output 2

Write response. This signal indicates the status of the write transaction. 00 - OKAY10 - SLVERR

S_AXI_BVALID Output 1Write response valid. This signal indicates that a valid write response is available.

S_AXI_BREADY Input 1Response ready. This signal indicates that the master can accept the response information.

AXI Read Address Channel Signals(1)

S_AXI_ARADDR Input 32Read address. The read address bus gives the address of a read transaction.

S_AXI_ARVALID (2) Input 1

Read address valid. This signal indicates, when High, that the read address and control information is valid and will remain stable until the address acknowledgment signal, S_AXI_ARREADY, is High.

S_AXI_ARREADY Output 1Read address ready. This signal indicates that the slave is ready to accept an address and associated control signals.

AXI Read Data Channel Signals (1)

S_AXI_RDATA Output 32 Read data

S_AXI_RRESP Output 2Read response. This signal indicates the status of the read transfer.

S_AXI_RVALID Output 1Read valid. This signal indicates that the required read data is available and the read transfer can complete.

Table 2-3: AX14-Lite Signals (Cont’d)

Signal Name Direction Width Description

Send Feedback





Lookup InterfaceThe Lookup interface is used to request a lookup and receive the response.

IMPORTANT: SDNet exposes these ports through a wrapped interface as described in the SDNet Packet Processor User Guide (UG1012) [Ref 4].

S_AXI_RREADY Input 1Read ready. This signal indicates that the master can accept the read data and response information.

Notes: 1. The function and timing of these signals is defined in the AMBA AXI Protocol Version: 2.0 Specification [Ref 1].2. Read transactions have higher priority than write transactions.

Table 2-3: AX14-Lite Signals (Cont’d)

Signal Name Direction Width Description

Table 2-4: Lookup Request InterfaceSignal Name Direction Width Description

LookupReqValid Input 1 Lookup Request Valid

LookupReqKey Input K Lookup Request Key, valid during when LookupReqValid is asserted.

Table 2-5: Lookup Response InterfaceSignal Name Direction Width Description

LookupRespValid Output 1Lookup Response Valid, asserted fixed number of cycle following LookupReqValid assertion. Validates the rest of the LookupResp* signals

LookupRespKey Output K Valid when LookupRespValid=1. This signal is a copy of the key requested via LookupReqKey.

LookupRespHit Output 1Valid when LookupRespValid=1. Indicates LookupRespKey was found in the CAM and validates LookupRespValue signal.

LookupRespValue Output VValid when (LookupRespValid & LookupRespHit) = 1. Outputs the value word associated with LookupRespKey key.

Send Feedback





Register SpaceThe register space is used for software control, monitoring and management of the CAM. Xilinx recommends using the provided API functions for a high-level software interface to the CAM and not to access the register space directly. The register space is documented in relative offsets. During AXI system initialization, the CAM is assigned an absolute memory address range.

Table 2-6: Offset = 0x00: Unique Device IDField Name Bits Access Description

Unique Device ID 31:0 Read-only Unique Device Id. Used by the API to ensure compatibility.

Table 2-7: Offset = 0X20: Initialization Control and StatusField Name Bits Access Description

InitEnb 0 Read-writeInitialization Enable. Setting InitEnb following a reset enables the start of the self-initialization sequence. Must remain asserted until InitDone assertion.

InitDone 8 Read-onlyInitialization Completed. When set, indicates the completion of self-initialization and readiness to accept lookup and update requests.

Table 2-8: Offset = 0X24: Number of Stored EntriesField Name Bits Access Description

Size 31:0 Read-only Total number of entries currently stored

Table 2-9: Offset = 0X30: Aging Capability and ControlField Name Bits Access Description

AgingMode 0 Read-writeAging Mode

0 = Automatic aging is disabled1 = Automatic aging is enabled

AgingCapability 8 Read-only The device is capable of performing automatic key aging.

Send Feedback





Table 2-10: Offset = 0X34: Aging TimeField Name Bits Access Description

AgingTime 31:0 Read-write

Number of clock cycles between aging requests. Average aging (time-to-live) time = AgingTime * (1.25 * D + 8) * 8, where D is the depth parameter.

Table 2-11: Offset = 0X40: Update RequestField Name Bits Access Description

UpdateOp 1:0 Read-write

Writing this register offset triggers a new command request. The type of command is encoded by the value written into this field. Valid encodings are:• 01 = Insert the contents of {Key/Value/Static}

registers into the CAM.• 10= Remove the entry with key equal to the Key

register• 11= Lookup the entry with the key equal to the

key register and load Value/Static registers with data from CAM.

UpdateStatic 8 Read-write Exempts the inserted key from aging. Only used for insert operation.

Send Feedback





The number of key registers KN is equal to ceil(K /32). Using integer division,

KN = (K – 1) / 32 + 1 Equation 2-1

Key registers occupy the offset range of

[0x50: 0x50 + KN – 1]. Equation 2-2

Because K never exceeds 384, the maximum range of the key register offset is within [0x50:0x7F].

The number of value registers VN is equal to ceil(V /32).

Using integer division,

VN = (V – 1) / 32 + 1 Equation 2-3

Value registers occupy the offset range of [0x80: 0x80 + VN – 1]. Because V never exceeds 1024, the maximum range of offset value register offsets is within [0x80:0xFF].

Table 2-12: Offset = 0X40: Update ResponseField Name Bits Access Description

UpdateAck 0 Read-only

This register is reset by hardware immediately on detecting a write to the Update Request register. It is set by hardware once the Update Request is completed. Software should ensure that this register is set before scheduling a new request or reading the value register after a lookup command.

UpdateCode 1 Read-only

Indicates the status of the previously scheduled command. Only valid when UpdateAck is set. OP=’insert’

0=key inserted/updated1=failed to insert the key/value

OP=’remove’ 0=key removed1=key is not present

OP=’lookup’ 0=key found, value/static are valid1=key is not present

Table 2-13: Offset = 0X50 + N*4: Key [N]Field Name Bits Access DescriptionKey[N] 31:0 Read-write Bits [max(K-1, 31+32*N) : 32*N] of the key

Send Feedback





Table 2-14: Offset = 0X80 + N*4: Value[N]Field Name Bits Access Description

Value[N] 31:0 Read-writeBits [max(K-1, 31+32*N): 32*N] of the value. Loaded by software prior to issuing an insert operation. Loaded by hardware during lookup operation. Not used in remove operation.

Send Feedback




Chapter 3

Designing with the CoreThis chapter includes guidelines and additional information to facilitate designing with the core.

General Design GuidelinesClockingIn general, the clock frequency should be equal to the packet rate. For example, for 100Gb/s Ethernet, the packet rate is approximately 150 Mp/s and therefore, the clock frequency must be 150 MHz.

ResetsReset must be asserted for at least 100 clock cycles at startup. If the AXI update interface is implemented, at startup, both the AXI reset and the main reset must be asserted simultaneously for 100 cycles of the slower of the two clocks: AXI clock and the main clock. As long as the reset assertion time is met, either reset can be asserted or negated first. Reset negation must meet setup timing relative to the rising edge of the clock.

Send Feedback




Chapter 3: Designing with the Core

Protocol DescriptionInterface OperationThis section describes the operation of the CAM Reset and Clock, System, Lookup, and Update interfaces. The CAM operates the Lookup and the Update interfaces synchronously to the main clock.

System Interface

Following the reset signal Rst negation, the CAM will sample the InitEnb signal to begin initialization. The InitDone signal will remain negated until initialization is completed following InitEnb assertion. InitEnb can be tied to 1, in which case the initialization will start immediately after reset. The time it takes initialization to complete depends on the configuration parameters and can be up to 250 ns for a 32K-entry CAM running at 150 MHz. The Lookup and Update interfaces must be idle with LookupReqValid and UpdateReqValid inputs negated until InitDone is asserted.

When using the AXI interface, user software sets up the device context and calls the CAM_Init_Activate() function after the reset and prior to calling API functions that perform insert, remove, or lookup operations. CAM_Init_Activate() sets the InitEnb register and polls until the InitDone signal is asserted. After the CAM_InitActivate returns, the Lookup interface can be enabled and the entry management functions can be called.

Figure 3-1 shows details of the System Interface operation.X-Ref Target - Figure 3-1

Figure 3-1: System Interface Timing

Send Feedback





Lookup Interface

The Lookup Interface checks for the presence of a particular key in the CAM data structure. If the key is present, the corresponding value is fetched.

The Lookup Interface is composed of two sub-interfaces: Lookup Request and Lookup Response. The Lookup Request interface is used by the application to drive the keys that need to be checked, and the Lookup Response interface reports the presence of the keys and returns the corresponding values.

The Lookup Interface can search for keys while the update/remove operation is in progress. The {key, value} entries are guaranteed to be “hit” by lookup after completion of the Insert operation and are guaranteed to be “miss” after completion of the Remove operation. Performing a lookup while a key is being removed or deleted does not cause an error and the result is always consistent; the result can be based on the state prior to the operation, or on the post-operation state, depending on the relative timing between the remove and lookup operations

Looking up the key being updated will always result in a “hit” result, but the value returned can be new or old, depending on the relative timing of the update and lookup operations.

Looking up the key being removed can return a “hit” or “miss” result. However if the key is found, the value is always correct.

Lookup Request

The Lookup Request interface is available to accept requests as soon as the InitDone signal is asserted on the System Interface (or in a register if the AXI4-Lite interface is configured). The Lookup Request interface is fully-pipelined and is able to process a lookup request every clock cycle. LookupReqKey must be valid when LookupReqValid is asserted and must contain the key being looked up.

Lookup Response

The Lookup Response interface reports the result of looking up the key scheduled on the Lookup Request interface. LookupRespValid is asserted with a fixed latency of six clocks with respect to LookupReqValid. LookupRespValid is asserted for one cycle during which the LookupRespKey duplicates the value present on the LookupReqKey during the corresponding LookupReqValid assertion cycle. When LookupRespValid is asserted, LookupRespHit is valid together with LookupRespKey and indicates the presence of LookupReqKey in the CAM when asserted. When LookupRespHit is asserted, it also validates LookupRespValue output, which contains the value portion of the {key, value} pair stored in the CAM. When LookupRespHit is negated, it means LookupRespKey was not found and LookupRespValue is invalid.

Figure 3-1 shows the timing waveforms of the Lookup Interface operation. The first and third lookup requests result in a miss. The second and fourth requests result in hits and output the corresponding values on the response interface.

Send Feedback





Update InterfaceThe update interface is used to insert, update, and remove {key, value} entries from the CAM. New requests can be scheduled by asserting UpdateReqValid for one cycle when there is no other update operation in progress. The UpdateReqOp and UpdateReqKey signals are driven together with the assertion of UpdateReqValid. The UpdateReqOp signal encodes the desired operation according to the table below.

The Insert operation additionally requires the UpdateReqValue signal (and UpdateReqStatic signal for configurations with aging) to be driven together with the assertion of UpdateReqValid. All of the signals must be held stable until the operation is completed, which is indicated by the assertion of the UpdateRespValid signal. The completion status is indicated by the UpdateRespCode signal during the cycle along with the assertion of UpdateRespValid.


Figure 3-2: Lookup Interface Timing

Table 3-1: Update Operation EncodingEncoding Operation

‘b01 Insert {key, value, static} entry‘b10 Remove entry with {key}‘b11 Lookup entry with {key}, and load {key, value, static}

Send Feedback





Insert and Remove operations can affect the state of the Size signal (or register value if the AXI4-Lite interface is configured). Successful insertion of a new key increments Size, while removal of an existing key decrements it. The Size signal remains unchanged on an update of an existing key or a lookup operation. The Size signal is invalid while any insert or remove operation is in progress.

In configurations where aging is enabled, the Size signal can decrement anytime due to aging in automatic aging mode. In such a mode, do not rely on observing the Size signal value as an indicator of the operation completion status and decode the UpdateRespCode signal value when UpdateRespValid is asserted.

Update Interface Insert Operation

The Insert operation is used to insert a new key or update an entry with the matching key with the new value (and static flag for configurations with aging). The Insert operation can be scheduled when there is no other update operation in-progress. The UpdateReqKey, UpdateReqValue, and UpdateReqStatic signals (for configurations with aging) are driven together with the assertion of UpdateReqValid and must remain stable until the assertion of the UpdateRespValid signal indicating the completion of the insert operation. The UpdateRespCode signal contains the status of the operation completion when UpdateRespValid is asserted. A value of 0 indicates successful completion.

Figure 3-3 shows the Update Interface timing waveforms for the insert operation. The first operation successfully inserts a new entry, the second operation updates an existing entry, and the third operation fails.

Update Interface Remove Operation

The Remove operation is used to delete an existing entry with a matching key. The Remove operation can be scheduled when there is no other update operation in progress. The UpdateReqKey signal is driven together with the assertion of UpdateReqValid and must remain stable until the assertion of the UpdateRespValid signal indicating that the operation is complete. The UpdateRespCode signal contains the status of the operation completion when UpdateRespValid is asserted. A value of 0 indicates successful completion.

Figure 3-3 shows the Update Interface timing waveforms for the Remove operation. The first two removals are successful, while the third fails to locate and remove a matching key.

Send Feedback





Update Interface Lookup Operation

The Lookup operation is used to check whether an entry with a matching key is present in the CAM. The Lookup operation can be scheduled when there is no other update operation in progress. The UpdateReqKey signal is driven together with the assertion of UpdateReqValid and must remain stable until the assertion of the UpdateRespValid signal indicating that the operation is complete. The UpdateRespCode signal contains the status of the operation completion when UpdateRespValid is asserted. A value of 0 indicates successful completion.

If the lookup is successful, the UpdateRespValue and UpdateRespStatic signals are loaded with the corresponding value from the located entry. These signals are only valid when UpdateRespValid is asserted.

Figure 3-4 shows the details of the Update Interface timing for the lookup operation. The first and third requests successfully locate matching entries and output the corresponding values on the Response Interface. The second request fails to match an entry and indicates a failure via the UpdateRespCode signal.


Figure 3-3: Update Interface Remove Operation Timing

Send Feedback






Figure 3-4: Update Interface Lookup Operation Timing

Send Feedback




Chapter 4

Design Flow Steps

ConfigurationThe CAM design is highly configurable at compile time to make it suitable for a large variety of applications. Table 4-1 lists available configuration parameters. Please note that changing parameters requires design synthesis and generation of a new FPGA bitstream.

To configure the core properly for a given application, the following must be considered.

• K (Key width) must be equal to the number of bits in the search key.• V (Value width) must be equal to the number of bits in the value associated with the

key.• D (Depth) must be equal to number of keys that must be stored in the CAM.• AGING must be set to 1 if aging is required and to 0 otherwise.• AXI_UPD must be set to 0 if the CAM update is performed by hardware (e.g., in a

learning switch) or to 1 if it is performed by software running on a CPU.

Table 4-1: CAM SmartCORE Synthesis-time ParametersParameter Name Description

K Key width: 16 to 384 bitsV Value width: 1 to 256 bits D Depth/Maximum number of entries: 1 to 219

AGING0=Aging mode is not enabled.1=Aging mode is enabled.When 0, aging related signals are not present.

AXI_UPD 0=Hardware Update Interface1=AXI4-Lite Update Interface

INSTANCE_NAME Instance name used for the top level instance, e.g., “CAM_1”

Send Feedback




Chapter 4: Design Flow Steps

Output GenerationTable 4-2 shows the files associated with the core.

Constraining the CoreThis section contains information about constraining the core.

Required ConstraintsThis section is not applicable for this IP core.

Device, Package, and Speed Grade SelectionsThis section is not applicable for this IP core.

Clock FrequenciesThe design must contain a clock frequency constraint for the primary clock driving the Clk input of the CAM. An example for constraining a primary clock net called clk150 that drives the Clk input at 150 MHz as follows.

create_clock -period 6.667 -name clk150 [get_ports clk150]

Clock ManagementThis section is not applicable for this IP core.

Table 4-2: List of Files Associated with the CoreName Description

<INSTANCE_NAME>/rtl/<INSTANCE_NAME>.v Encrypted Verilog source code

<INSTANCE_NAME>/model/model.sv<INSTANCE_NAME>/sim/run.do<INSTANCE_NAME>/tb/tb.sv

Behavioral model of the CAM SmartCOREQuesta Advanced Simulator command fileDemonstration test bench

<INSTANCE_NAME>/api/<INSTANCE_NAME>.h<INSTANCE_NAME>/api/xilinx_CAM.h<INSTANCE_NAME>/api/xilinx_CAM.c

Software driver files

Send Feedback




Chapter 4: Design Flow Steps

Clock PlacementThis section is not applicable for this IP core.

BankingThis section is not applicable for this IP core.

Transceiver PlacementThis section is not applicable for this IP core.

I/O Standard and PlacementThis section is not applicable for this IP core.

SimulationFor comprehensive information about Vivado simulation components, as well as information about using supported third-party tools, see the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11]. Please also refer to the SDNet Packet Processor User Guide (UG1012) [Ref 4].

IMPORTANT: For cores targeting 7 series or Zynq-7000 devices, UNIFAST libraries are not supported. Xilinx IP is tested and qualified with UNISIM libraries only.

Synthesis and ImplementationFor details about synthesis and implementation, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 12].

Send Feedback




Appendix A

UpgradingThis appendix is not applicable for the first release of the core.

Send Feedback




Appendix B

DebuggingThis appendix includes details about resources available on the Xilinx® Support website and debugging tools.

Finding Help on Xilinx.comTo help in the design and debug process when using the CAM, the Xilinx® Support web page contains key resources such as product documentation, release notes, answer records, information about known issues, and links for obtaining further product support.

DocumentationThis product guide is the main document associated with the CAM. This guide, along with documentation related to all products that aid in the design process, can be found on the Xilinx Support web page or by using the Xilinx® Documentation Navigator.

Download the Xilinx Documentation Navigator from the Downloads page. For more information about this tool and the features available, open the online help after installation.

Answer RecordsAnswer Records include information about commonly encountered problems, helpful information on how to resolve these problems, and any known issues with a Xilinx product. Answer Records are created and maintained daily ensuring that users have access to the most accurate information available.

Answer Records for this core can also be located by using the Search Support box on the main Xilinx support web page. To maximize your search results, use proper keywords such as:

• Product name• Tool message(s)• Summary of the issue encountered

A filter search is available after results are returned to further target the results.

Send Feedback





https://www.xilinx.com/support/download.html



Appendix B: Debugging

Technical SupportXilinx provides technical support at the Xilinx Support web page for this CAM product when used as described in the product documentation. Xilinx cannot guarantee timing, functionality, or support if you do any of the following:

• Implement the solution in devices that are not defined in the documentation.• Customize the solution beyond that allowed in the product documentation. • Change any section of the design labeled DO NOT MODIFY.

To contact Xilinx® Technical Support, navigate to the Xilinx Support web page.

Debug ToolsThere are many tools available to address CAM design issues. It is important to know which tools are useful for debugging various situations.

Hardware DebugHardware issues can range from link bring-up to problems seen after hours of testing. This section provides debug steps for common issues.

General ChecksEnsure that all the timing constraints for the core were properly incorporated and that all constraints were met during implementation.

• Does it work in post-place and route timing simulation? If problems are seen in hardware but not in timing simulation, this could indicate a PCB issue. Ensure that all clock sources are active and clean.

• If using mixed-mode clock managers (MMCMs) in the design, ensure that all MMCMs have obtained lock by monitoring the LOCKED port.

• If your outputs go to 0, check your licensing.

Send Feedback






Appendix B: Debugging

Interface DebugAXI4-Lite InterfacesRead from a register that does not have all 0s as a default to verify that the interface is functional. See the AMBA AXI Protocol Version: 2.0 Specification [Ref 1] for a read timing diagram. Output s_axi_arready asserts when the read address is valid, and output s_axi_rvalid asserts when the read data/response is valid. If the interface is unresponsive, ensure that the following conditions are met:

• The s_axi_aclk and aclk inputs are connected and toggling.• The interface is not being held in reset, and s_axi_areset is an active-Low reset.• The interface is enabled, and s_axi_aclken is active-High (if used).• The main core clocks are toggling and that the enables are also asserted. • If the simulation has been run, verify in simulation that the waveform is correct for

accessing the AXI4-Lite interface.

Send Feedback




Appendix C

Application Software DevelopmentThis appendix describes the Application Programming Interface (API) for the CAM SmartCORE IP. The API is a set of functions that provides an easy-to-use interface between the user application and the CAM hardware control and status registers. The API is implemented in the C programming language and conforms to the C99 ANSI standard.

The API library does not have any external dependencies and does not perform file access, I/O access, or memory allocation/de-allocation.

In order to use the API, the user application includes the appropriate header file in the source code and calls the required functions. The API library is delivered as source code and can be compiled and linked together with the user application, or as a separate static or dynamic library. The build system or the compilation scripts should ensure the correct setup of the ‘include’ and library paths.

The API is comprised of the following files.

• CAM.h – header file• CAM.c – function implementation file

Data StructuresThis section describes the data structures used by the CAM API functions to interface with the user application.

Device Contexttypedef struct {

uint32_t max_depth;uint32_t key_width;uint32_t value_width;uint32_t aging_width;uint32_t clock_period;uint32_t base;void(*register_write)(uint32_t addr, uint32_t data);uint32_t(*register_read)(uint32_t addr);int (*log_message)(const char * format, ...);uint32_tlog_level;

} CAM_CONTEXT;

Send Feedback




Appendix C: Application Software Development

The CAM_CONTEXT structure contains device context information used to uniquely refer to a CAM SmartCORE IP instance and provides CAM API functions with pointers to system utility functions. The system can contain multiple CAM instances. Each CAM instance must be initialized separately and assigned a unique CAM_CONTEXT data structure to be validated via the CAM_Init_ValidateContext() API function call.

• max_depth contains the maximum number of entries that can be stored in the CAM.• key_size contains the width of the entry key in bits.• value_size contains the width of the entry value in bits.• aging_width contains the width of the aging tag in bits if the CAM is configured with

aging functionality, zero otherwise.• clock_period contains the period of the system clock (Clk) in picoseconds.• base is the starting address of the memory mapped address space allocated to the

CAM instance. The CAM API adds the base address to an internal offset when calling the provided register_read and register_write function pointers.

• The register_read and register_write function pointers provide platform-specific access to the device memory space and must be initialized by the user code to point to implemented function entry points.

• The log_message function pointer provides the platform-specific wrapper for reporting an informational message for logging. The CAM calls this function when an event occurs, passing a printf-formatted string argument, and a variadic list of arguments. Only %s, %d and %x format specifiers are used. The final string never exceeds 255 characters.

• log_level sets the logging verbosity threshold according to the following settings:

° CAM_LOG_DISABLE = 0

No log messages are printed, log_message can be NULL.

° CAM_LOG_ERROR

log_message is called for error messages.

° CAM_LOG_WARNING

log_message is called for warning and error messages.

Send Feedback





° CAM_LOG_INFOlog_message is called for informational, warning, and error messages.

Aging Modetypedef enum AgingMode {

AGING_MODE_DISABLED,AGING_MODE_AUTO

} CAM_AGING_MODE;

The CAM_AGING_MODE structure enumerated type defines the standard encoding for the GetAgingMode and SetAgingMode API functions.

Note: The actual values are tied to the version of the API and can change in future versions of the CAM.

AGING_MODE_DISABLED means the automatic aging functionality is disabled.

AGING_MODE_AUTO means the automatic aging functionality is enabled. The lifetime of each entry is determined by the AgingTime parameter set via the SetAgingTime function. An entry is automatically removed after a configurable period of inactivity (no lookup hits or updates), unless it is tagged as “static”.

Device Initialization The initialization API provides constants and function for correct CAM instance and software initialization.

CAM_ADDR_SIZE This define specifies the size of the CAM address space in bytes. Each CAM instance must be allocated CAM_ADD_SIZE bytes in the system memory map of the configuration space. This define can be used to statically configure the memory map.

Note: CAM_ADDR_SIZE is tied to the version of the API and can change in future versions of the CAM.

Send Feedback





CAM_Init_GetAddrSize()

This function returns the CAM_ADDR_SIZE and can be called at runtime to dynamically allocate or resize the configuration memory mapping of the CAM instance.

Note: CAM_ADDR_SIZE is tied to the version of the API and might change in future versions of the CAM.

Prototype

uint32_t CAM_Init_GetAddrSize();

Arguments

N/A

Return value

An integer indicating the size of the memory space in bytes.

CAM_Init_ValidateContext()

This function creates the instance context data structure.

Prototype

int CAM_Init_ValidateContext(CAM_CONTEXT* cx, uint32_t base, uint32_t size, uint32_t max_depth, uint32_t key_width, uint32_t value_width, uint32_t aging_width, uint32_t clock_period, void (*register_write)(uint32_t, uint32_t), uint32_t(*register_read)(uint32_t addr),int (*log_message)(const char *, ...),uint32_tlog_level);

Arguments

• cx is a pointer to the CAM_CONTEXT structure to be initialized.• base is the starting offset of the configuration memory address range assigned to this

CAM instance.• size is the size in bytes of the configuration memory address range assigned to this

CAM instance.Note: size must be equal to or greater than CAM_ADDR_SIZE.

• max_depth contains the maximum number of entries that can be stored in the CAM.

Send Feedback





• key_size contains the width of the entry key in bits.• value_size contains the width of the entry value in bits.• aging_width contains the width of the aging tag in bits if CAM is configured with aging

functionality, zero otherwise.• clock_period contains the period of the system clock (Clk) in picoseconds.• register_write is a pointer to the register write function.

CAM API functions calculate the target address as base + internal offset.

° register_read is a pointer to the register read function. CAM API functions calculate the target address as base + internal offset.

° log_message is a pointer to the formatted output log function.

° log_level is the verbosity level.

Return value

Zero (CAM_SUCCESS) indicates successful execution. A non-zero value indicates an error. See the list of error codes for details.

CAM_Init_SetLogLevel()

This function updates the logging level in the device context data structure.

Prototype

int CAM_Init_SetLogLevel(CAM_CONTEXT* cx, uint32 log_level);

Arguments

° cx is a pointer to the CAM_CONTEXT structure to be updated.

° log_level is a new logging level.

Return value

Zero (CAM_SUCCESS) indicates successful firmware image loading and activation. A non-zero value indicates an error. See the list of CAM error codes for details.

Send Feedback





CAM_Init_Activate()

This function performs device self-initialization and activation.

Prototype

int CAM_Init_EnableDevice(CAM_CONTEXT* cx);

Arguments

cx is a pointer to the CAM_CONTEXT structure.

Return value

Zero (CAM_SUCCESS) indicates successful execution. A non-zero value indicates an error. See the list of CAM error codes for details.

Device Management APIThis API provides a set of functions for inserting and removing CAM rules and for configuring operational parameters.

CAM_ Mgt_GetSize()

This function returns the number of entries currently present in the CAM.

Prototype

uint32_t CAM_Mgt_GetSize(CAM_CONTEXT* cx);

Arguments


Return value

An integer containing the number of {key, value} entries currently stored in the device.

Send Feedback





CAM_Mgt_GetAgingMode()

This function returns the current Aging mode.

Prototype

CAM_AGING_MODE CAM_Mgt_GetAgingMode(CAM_CONTEXT* cx);

Arguments


Return value

An integer encoded according to the CAM_AGING_MODE type definition.

CAM_Mgt_SetAgingMode()

This function sets the current Aging mode.

Prototype

int CAM_Mgt_SetAgingMode(CAM_CONTEXT* cx, CAM_AGING_MODE mode);

Arguments

° cx is a pointer to the CAM_CONTEXT structure.

° mode is a new mode encoding according to CAM_AGING_MODE definition.

Return value


CAM_Mgt_MinAgingTime()

This function returns the minimum valid value for the Aging Time setting.

Prototype

uint_64t CAM_Mgt_MinAgingTime(CAM_CONTEXT* cx);

Arguments


Return value

Minimum supported aging time in microseconds.

Send Feedback





CAM_Mgt_MaxAgingTime()

This function returns the maximal valid value for the AgingTime setting.

Prototype

uint_64t CAM_Mgt_MaxAgingTime(CAM_CONTEXT* cx);

Arguments


Return value

Maximum supported aging time in microseconds.

CAM_Mgt_GetAgingTime()

This function returns the current AgingTime setting rounded to the supported precision and expressed in microseconds.

Prototype

int CAM_Mgt_GetAgingTime(CAM_CONTEXT* cx, uint_64t *cycles);

Arguments


° cycles is a pointer to the memory location to be loaded with the read aging time.

Return value


Send Feedback





CAM_Mgt_SetAgingTime()

This function sets the current AgingTime to the specified number of microseconds rounded down to the supported precision.

Prototype

int CAM_Mgt_GetAgingTime(CAM_CONTEXT* cx, uint_64t cycles);

Arguments


° cycles the age of entries (time-to-live) in microseconds for deletion.

Return value


CAM_Mgt_InsertEntry()

This function inserts a new entry into the CAM.

Prototype

int CAM_Mgt_InsertEntry(CAM_CONTEXT* cx, char* key, char* value, bool static = false);

Arguments· cxisapointertotheCAM_CONTEXTstructure.· keyisapointertoanull-terminatedCstringencodingthekey.· valueisapointertoanull-terminatedCstringencodingthevalue.· staticisabooleanflagindicatingthattheentrywillbeexemptfromagingwhentrue.Return value

Zero value (CAM_SUCCESS) indicates successful key insertion or in-pace update. A non-zero value indicates an error. See the list of CAM error codes for details.

Send Feedback





CAM_Mgt_RemoveEntry()

This function removes an entry from the CAM.

Prototype

int CAM_Mgt_RemoveEntry (CAM_CONTEXT* cx, char* key);

Arguments


° key is a pointer to a null-terminated C string encoding the key.

Return value

Zero (CAM_SUCCESS) indicates successful key deletion. A non-zero value indicates an error. See the list of CAM error codes for details.

CAM_Mgt_LookupEntry()

This function performs a lookup for an entry.

Prototype

int CAM_Mgt_LookupEntry(CAM_CONTEXT* cx, char* key, char* value, bool* static);

Arguments


° key is a pointer to a null-terminated C string encoding the key.

° value is a pointer to an array that can hold a null terminated C string representation for the value associated with the key. Loaded by the API upon successful lookup.

° static is a pointer to a boolean flag. Loaded by the API with the static flag associated with the key upon successful lookup.

Return value

Zero (CAM_SUCCESS) indicates successful key lookup. A non-zero value indicates an error. See the list of CAM error codes for details.

Send Feedback





ErrorsThis section details the error conditions, error code values, and related utility functions.

CAM_Error_Decode()

This function provides the runtime description for each error code.

Prototype

const char* CAM_Error_Decode(int error);

Arguments

error is a non-zero error code returned by the CAM API function.

Return value

null-terminated string pointer containing a short description of the error code.

Error Codes

° CAM_SUCCESS = 0Successful completion of the operation. The value of this code is zero and is guaranteed to be fixed in all future versions of the API.

° CAM_ERROR_INIT_SIZEthe size argument is less than CAM_ADDR_SIZE.

° CAM_ERROR_INIT_NULL_FUNCPTRregister_write, register_read, or log_message function pointer is NULL.

° CAM_ERROR_INIT_READ_MISMATCHregister read to CAM instance that does not return the expected data.

° CAM_ERROR_INIT_LOGlog_message returns the expected number of arguments on output of init messages.

° CAM_ERROR_NULL_CONTEXT_PTRContext pointer is NULL.

° CAM_ERROR_INVALID_CONTEXTContext magic number mismatch.

° CAM_ERROR_INIT_SIZEContext size too small for this instance version.

° CAM_ERROR_INIT_NULL_FUNC_PTRContext function pointer is NULL.

Send Feedback





° CAM_ERROR_INIT_READ_MISMATCHRegister read data does not match previously written value.

° CAM_ERROR_INIT_LOGlog_message function return value does not match expected value.

° CAM_ERROR_KEY_NULLkey string pointer is NULL.

° CAM_ERROR_VALUE_NULLvalue string pointer is NULL.

° CAM_ERROR_KEY_FORMATinvalid key string format.

° CAM_ERROR_VALUE_FORMATinvalid value string format.

° CAM_ERROR_AGE_TOO_LOWAging time is too low.

° CAM_ERROR_AGE_TOO_LARGEAging time is too large.

° CAM_ERROR_ACCMiscellaneous device access error.

Send Feedback




Appendix D

Additional Resources and Legal Notices

Xilinx ResourcesFor support resources such as Answers, Documentation, Downloads, and Forums, see Xilinx Support.

Documentation Navigator and Design HubsXilinx® Documentation Navigator provides access to Xilinx documents, videos, and support resources, which you can filter and search to find information. To open the Xilinx Documentation Navigator (DocNav):

• On Windows, select Start > All Programs > Xilinx Design Tools > DocNav.• At the Linux command prompt, enter docnav.

Xilinx Design Hubs provide links to documentation organized by design tasks and other topics, which you can use to learn key concepts and address frequently asked questions. To access the Design Hubs:

• In the Xilinx Documentation Navigator, click the Design Hubs View tab.• On the Xilinx website, see the Design Hubs page.Note: For more information on Documentation Navigator, see the Documentation Navigator page on the Xilinx website.

Send Feedback


https://www.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://www.xilinx.com/cgi-bin/docs/rdoc?t=docnav





Appendix D: Additional Resources and Legal Notices

ReferencesThese documents provide supplemental material useful with this product guide:

1. AMBA AXI and ACE Protocol Specification (ARM IHI 0022E)2. P4-SDNet Translator User Guide (UG1252)3. SDNet Functional Specification User Guide (UG1016)4. SDNet Packet Processor User Guide (UG1012)5. SDNet Compiler Installation, Release Notes, and Getting Started Guide (UG1018)6. Ternary Content Addressable Memory (TCAM) Search IP for SDNet SmartCORE IP Product

Guide (PG190) 7. Longest Prefix Match (LPM) Search IP for SDNet SmartCORE IP Product Guide (PG191) 8. WireShark website (wireshark.org)9. Graphviz DOT website (graphviz.org)10. P4 Consortium website (p4.org)11. Vivado Design Suite User Guide: Logic Simulation (UG900)12. Vivado Design Suite User Guide: Designing with IP (UG896)

The following table shows the revision history for this document.

Revision HistoryDate Version Revision01/29/2019 1.0 Updated Latency section (under Performance); updated Table 3-1.

11/10/2017 1.0 Initial public release. The lounge version was titled Self-managed Content Addressable Memory SmartCORE IP Product Guide.

Send Feedback


https://www.wireshark.org/

http://www.graphviz.org/

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=tcam;v=latest;d=pg190-tcam.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=lpm;v=latest;d=pg191-lpm.pdf

http://p4.org/

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug900-vivado-logic-simulation.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1252-p4-sdnet-translator.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/UG1012-sdnet-packet-processor.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/UG1012-sdnet-packet-processor.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug1018-sdnet-installation.pdf

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0022e/index.html



Appendix D: Additional Resources and Legal Notices

Please Read: Important Legal NoticesThe information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of Xilinx’s limited warranty, please refer to Xilinx’s Terms of Sale which can be viewed at https://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx’s Terms of Sale which can be viewed at https://www.xilinx.com/legal.htm#tos.AUTOMOTIVE APPLICATIONS DISCLAIMERAUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOT WARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONS THAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS A SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262 AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USING OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TEST SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION WITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TO APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT LIABILITY.© Copyright 2013-2019 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners.

Send Feedback


https://www.xilinx.com/legal.htm#tos

https://www.xilinx.com/legal.htm#tos


exact match binary cam search ip for sdnet …...exact match binary cam search ip for sdnet 7 pg189...

Documents