ds791 Axi Can
ds791 Axi Can
© Copyright 2010-2011. Xilinx, Inc. Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Zynq, and other designated brands included herein are
trademarks of Xilinx in the United States and other countries. ARM is a registered trademark of ARM in the EU and other countries. The AMBA trademark is a
registered trademark of ARM Limited. All other trademarks are the property of their respective owners.
Functional Description
Figure 1 illustrates the high-level architecture of the CAN core. The CAN core requires an external 3.3 V compatible
PHY device. Descriptions of the submodules are given in the following sections.
Configuration Registers
Table 6 defines the configuration registers. This module allows for read and write access to the registers through the
external micro-controller interface.
Acceptance Filters
Acceptance Filters sort incoming messages with the user-defined acceptance mask and ID registers to determine
whether to store messages in the RX FIFO, or to acknowledge and discard them. The number of acceptance filters
can be configured from 0 to 4. Messages passed through acceptance filters are stored in the RX FIFO.
X-Ref Target - Figure 1
AXI4-Lite
Xilinx CAN Controller
CAN Protocol
Engine
TX
FIFO CAN BUS
IPIF TX
Priority Bit Stream
Processor TX
Logic
TX
CAN
HPB
PHY
MicroBlaze IPIC
Processor RX
Bit Timing
Configuration
Module
Registers
CAN CLK
RX Acceptance
FIFO Filtering
DS791_01_100701
Protocol Engine
The CAN protocol engine consists primarily of the Bit Timing Logic (BTL) and the Bit Stream Processor (BSP)
modules. Figure 2 illustrates a block diagram of the CAN protocol engine.
X-Ref Target - Figure 2
TS1 TS2
DS791_03_100701
As illustrated in Figure 3, the CAN bit time is divided into four parts:
• Sync segment
• Propagation segment
• Phase segment 1
• Phase segment 2
These bit time parts are comprised of a number of smaller segments of equal length called time quanta (tq). The
length of each time quantum is equal to the quantum clock time period (period = tq). The quantum clock is
generated internally by dividing the incoming oscillator clock by the baud rate pre-scaler. The pre-scaler value is
passed to the BTL module through the Baud Rate Prescaler (BRPR) register.
The propagation segment and phase segment 1 are joined and called 'time segment1' (TS1), while phase segment 2
is called 'time segment2' (TS2). The number of time quanta in TS1 and TS2 vary with different networks and are
specified in the Bit Timing Register (BTR), which is passed to the BTL module. The Sync segment is always one time
quantum long.
The BTL state machine runs on the quantum clock. During the SOF bit of every CAN frame, the state machine is
instructed by the Bit Stream Processor module to perform a hard sync, forcing the recessive (r) to dominant edge (d)
to lie in the sync segment. During the rest of the recessive-to-dominant edges in the CAN frame, the BTL is
prompted to perform resynchronization.
During resynchronization, the BTL waits for a recessive-to-dominant edge and after that occurs, it calculates the
time difference (number of tqs) between the edge and the nearest sync segment. To compensate for this time
difference and to force the sampling point to occur at the correct instant in the CAN bit time, the BTL modifies the
length of phase segment 1 or phase segment 2.
The maximum amount by which the phase segments can be modified is dictated by the Synchronization Jump
Width (SJW) parameter, which is also passed to the BTL through the BTR. The length of the bit time of subsequent
CAN bits are unaffected by this process. This synchronization process corrects for propagation delays and oscillator
mismatches between the transmitting and receiving nodes.
After the controller is synchronized to the bus, the state machine waits for a time period of TS1 and then samples the
bus, generating a digital '0' or '1'. This is passed on to the BSP module for higher level tasks.
I/O Signals
The AXI CAN I/O signals are listed and described inTable 1
Table 1: I/O Signal Description
Signal Initial
Port Signal Name Interface Type State Description
See
High Address of the Xilinx std_logic
G3 C_S_AXI_HIGHADDR Valid address footnotes
CAN Controller (1)and (2) _vector
CAN Parameters
Number of Acceptance
G4 C_CAN_NUM_ACF 0-4 0 integer
Filters used
G5 Depth of the RX FIFO C_CAN_RX_DPTH 2,4,8,16,32,64 2 integer
G6 Depth of the TX FIFO C_CAN_TX_DPTH 2,4,8,16,32,64 2 integer
AXI Parameters
G7 AXI Address bus width C_S_AXI_ADDR_WIDTH 32 32 integer
G8 AXI Data bus width C_S_AXI_DATA_WIDTH 32 32 integer
1. Address range specified by C_S_AXI_BASEADDR and C_S_AXI_HIGHADDR must be at least 0x100 and must be power of 2.
C_S_AXI_BASEADDR must be multiple of the range, where the range is C_S_AXI_HIGHADDR - C_S_AXI_BASEADDR + 1.
Also make sure that LSB 8 bits of the C_S_AXI_BASEADDR to be zero.
2. No default value is specified to ensure that the actual value is set, that is, if the value is not set, a compiler error is generated. The
address range must be at least 0x00FF. For example, C_S_AXI_BASEADDR = 0x80000000, C_S_AXI_HIGHADDR =
0x800000FF.
The width of some of the AXI CAN device signals depends on parameters selected in the design. The dependencies
between the AXI CAN device design parameters and I/O signals are shown in Table 4.
Table 4: Parameter Port Dependencies
Generic Name Affects Depends Relationship Description
or Port
Design Parameters
G3 C_S_AXI_HIGHADDR G2 Address range pair dependency
G7 C_S_AXI_ADDR_WIDTH P3, P13 Defines the width of the ports
G8 C_S_AXI_DATA_WIDTH P6, P7, P16 Defines the width of the ports
I/O Signals
S_AXI_AWADDR[C_S Port width depends on the generic
P3 - G7
_AXI_ADDR_WIDTH- 1:0] C_S_AXI_ADDR_WIDTH.
S_AXI_WDATA[C_S_ Port width depends on the generic
P6 - G8
AXI_DATA_WIDTH - 1: 0] C_S_AXI_DATA_WIDTH.
S_AXI_WSTB[C_S_ Port width depends on the generic
P7 - G8
AXI_DATA_WIDTH/8- 1:0] C_S_AXI_DATA_WIDTH.
S_AXI_ARADDR[C_S Port width depends on the generic
P13 - G7
_AXI_ADDR_WIDTH - 1:0] C_S_AXI_ADDR_WIDTH.
S_AXI_RDATA[C_S_AXI_DATA Port width depends on the generic
P16 - G8
_WIDTH -1:0] C_S_AXI_DATA_WIDTH.
Operational Modes
The CAN controller supports these modes of operation:
• Configuration
• Normal
• Sleep
• Loop Back
Table 5 contains the CAN Controller modes of operation and the corresponding control and status bits. Inputs that
affect the mode transitions are discussed in Configuration Register Descriptions, page 13.
Table 5: CAN Controller Modes of Operation
Configuration Mode
The CAN controller enters the Configuration mode when any of the following actions are performed, regardless of
the operation mode:
• Writing a '0' to the CEN bit in the SRR register.
• Writing a '1' to the SRST bit in the SRR register. The core enters the Configuration mode immediately following
the software reset.
• Driving a '0' on the S_AXI_ARESET_N input. The core continues to be in reset as long as S_AXI_ARESET_N is
'0'. The core enters Configuration mode after S_AXI_ARESET_N is negated to '1'.
The following describes the Configuration mode features.
• CAN controller loses synchronization with the CAN bus and drives a constant recessive bit on the bus line.
• ECR register is reset.
• ESR register is reset.
• BTR and BRPR registers can be modified.
• CONFIG bit in the Status Register is '1.'
• CAN controller does not receive any new messages.
• CAN controller does not transmit any messages. Messages in the TX FIFO and the TX high priority buffer are
kept pending. These packets are sent when normal operation is resumed.
• Reads from the RX FIFO can be performed.
• Writes to the TX FIFO and TX HPB can be performed.
• Interrupt Status Register bits ARBLST, TXOK, RXOK, RXOFLW, ERROR, BSOFF, SLP and WKUP are cleared.
• Interrupt Status Register bits RXNEMP, RXUFLW can be set due to read operations to the RX FIFO.
• Interrupt Status Register bits TXBFLL and TXFLL, and the Status Register bits TXBFLL and TXFLL, can be set
due to write operations to the TX HPB and TX FIFO, respectively.
• Interrupts are generated if the corresponding bits in the IER are '1.'
• All Configuration Registers are accessible.
When in Configuration mode, the CAN controller continues to stay in this mode until the CEN bit in the SRR
register is set to '1’. After the CEN bit is set to '1', the CAN controller waits for a sequence of 11 recessive bits before
exiting Configuration mode.
The CAN controller enters Normal, Loop Back, or Sleep modes from Configuration mode, depending on the
LBACK and SLEEP bits in the MSR Register.
Normal Mode
In Normal mode, the CAN controller participates in bus communication by transmitting and receiving messages.
From Normal mode, the CAN controller can enter either Configuration or Sleep modes.
For Normal mode, the CAN controller state transitions are as follows:
• Enters Configuration mode when any configuration condition is satisfied
• Enters Sleep mode when the SLEEP bit in the MSR is '1'
• Enters Normal mode from Configuration mode only when the LBACK and SLEEP bits in the MSR are '0' and
the CEN bit is '1'
• Enters Normal mode from Sleep mode when a wake-up condition occurs
Sleep Mode
The CAN controller enters Sleep mode from Configuration mode when the LBACK bit in MSR is '0’, the SLEEP bit
in MSR is '1’, and the CEN bit in SRR is '1’. The CAN controller enters Sleep mode only when there are no pending
transmission requests from either the TX FIFO or the TX High Priority Buffer.
The CAN controller enters Sleep mode from Normal mode only when the SLEEP bit is '1’, the CAN bus is idle, and
there are no pending transmission requests from either the TX FIFO or TX High Priority Buffer.
When another node transmits a message, the CAN controller receives the transmitted message and exits Sleep
mode. When the controller is in Sleep mode, if there are new transmission requests from either the TX FIFO or the
TX High Priority Buffer, these requests are serviced, and the CAN controller exits Sleep mode. Interrupts are
generated when the CAN controller enters Sleep mode or wakes up from Sleep mode.
The CAN controller can enter either Configuration or Normal modes from Sleep mode.
The CAN controller can enter Configuration mode when any configuration condition is satisfied. The CAN
controller enters Normal mode upon the following conditions (wake-up conditions):
• Whenever the SLEEP bit is set to '0'
• Whenever the SLEEP bit is '1', and bus activity is detected
• Whenever there is a new message in the TX FIFO or the TX High Priority Buffer
S_AXI_ACLK
The user can specify the operating frequency for S_AXI_ACLK. Using a DCM to generate this clock is optional.
S_AXI_ACLK frequency must be greater than or equal to CAN_CLK frequency.
CAN_CLK
The range of CAN_CLK clock is 8-24 MHz.
The user determines whether a DCM or an external oscillator is used to generate the CAN_CLK. If an external
oscillator is used, it should meet the tolerance requirements specified in the ISO 11898-1, CAN 2.0A and CAN 2.0B
standards.
Reset Mechanism
Two different reset mechanisms are provided for the CAN controller. The S_AXI_ARESET_N input mentioned in
Table 1 acts as the system reset. Apart from the system reset, a software reset is provided through the SRST bit in the
SRR register. Both the software reset and the system reset, reset the complete CAN core (the Object Layer and the
Transfer Layer as shown in Figure 1).
Software Reset
The software reset can be enabled by writing a '1' to the SRST bit in the SRR Register. When a software reset is
asserted, all the configuration registers including the SRST bit in the SRR Register are reset to their default values.
Read/Write transactions can be performed starting at the next valid transaction window.
System Reset
The system reset can be enabled by driving a '0' on the S_AXI_ARESET_N input. All the configuration registers are
reset to their default values. Read/Write transactions cannot be performed when the S_AXI_ARESET_N input is '0'.
Exceptions
The contents of the acceptance filter mask registers and acceptance filter ID registers are not cleared when the
software reset or system reset is asserted.
Reset Synchronization
A reset synchronizer resets each clock domain in the core. Because of this, some latency exists between the assertion
of reset and the actual reset of the core.
Interrupts
The CAN IP core uses a hard-vector interrupt mechanism. It has a single interrupt line (IP2Bus_IntrEvent) to
indicate an interrupt. Interrupts are indicated by asserting the IP2Bus_IntrEvent line (transition of the
IP2Bus_IntrEvent line from a logic '0' to a logic '1').
Events such as errors on the bus line, message transmission and reception, FIFO overflows and underflow
conditions can generate interrupts. During power on, the Interrupt line is driven low.
The Interrupt Status Register (ISR) indicates the interrupt status bits. These bits are set and cleared regardless of the
status of the corresponding bit in the Interrupt Enable Register (IER). The IER handles the interrupt-enable
functionality. The clearing of a status bit in the ISR is handled by writing a '1' to the corresponding bit in the
Interrupt Clear Register (ICR).
The following two conditions cause the IP2Bus_IntrEvent line to be asserted:
• If a bit in the ISR is '1' and the corresponding bit in the IER is '1'.
• Changing an IER bit from a '0' to '1'; when the corresponding bit in the ISR is already '1'.
• Two conditions cause the IP2Bus_IntrEvent line to be deasserted:
• Clearing a bit in the ISR that is '1' (by writing a '1' to the corresponding bit in the ICR); provided the
corresponding bit in the IER is '1'.
• Changing an IER bit from '1' to '0'; when the corresponding bit in the ISR is '1'.
When both deassertion and assertion conditions occur simultaneously, the IP2Bus_IntrEvent line is deasserted
first, and is reasserted if the assertion condition remains true.
Control Registers
Software Reset Register (SRR) 0x000 Read/Write
Mode Select Register (MSR) 0x004 Read/Write
Transfer Layer Configuration Registers
Baud Rate Prescaler Register (BRPR) 0x008 Read/Write
Bit Timing Register (BTR) 0x00C Read/Write
Error Indication Registers
Error Counter Register (ECR) 0x010 Read
Error Status Register (ESR) 0x014 Read/Write to Clear
CAN Status Registers
Status Register (SR) 0x018 Read
Interrupt Registers
Interrupt Status Register (ISR) 0x01C Read
Interrupt Enable Register (IER) 0x020 Read/Write
Interrupt Clear Register (ICR) 0x024 Write
Reserved
Reads Return 0/
Reserved Locations 0x028 to 0x02C
Write has no affect
Messages
Control Registers
Software Reset Register
Writing ‘1’ to the Software Reset Register (SRR) places the CAN controller in Configuration mode. When in
Configuration mode, the CAN controller drives recessive on the bus line and does not transmit or receive messages.
During power-up, the CEN and SRST bits are '0' and the CONFIG bit in the Status Register (SR) is '1'. The Transfer
Layer Configuration Registers can be changed only when the CEN bit in the SRR Register is '0.'
Use these steps to configure the CAN controller at power up:
1. Configure the Transfer Layer Configuration Registers (BRPR and BTR) with the values calculated for the
specific bit rate.
See Baud Rate Prescaler Register and Bit Timing Register for more information.
2. Do one of the following:
a. For Loop Back mode, write '1' to the LBACK bit in the MSR.
a. For Sleep mode, write '1' to the SLEEP bit in the MSR.
See Operational Modes, page 8 for information about operational modes.
3. Set the CEN bit in the SRR to 1.
After the occurrence of 11 consecutive recessive bits, the CAN controller clears the CONFIG bit in the Status
Register to '0', and sets the appropriate Status bit in the Status Register.
Table 7 shows the bit positions in the SR register and Table 8 provides the Software Reset Register bit descriptions.
0–23 Reserved Read/Write 0 Reserved: These bit positions are reserved for future expansion.
Baud Rate Prescaler: These bits indicate the prescaler value.
24 –31 BRP[7.0] Read/Write 0
The actual value ranges from 1—256.
The BRPR can be programmed to any value in the range 0—255. The actual value is one more than the value written
into the register.
The CAN quantum clock can be calculated using this equation:
tq = tosc*(BRP+1)
where tq and tosc are the time periods of the quantum and oscillator/system clocks respectively.
Note: A given CAN bit rate can be achieved with several bit-time configurations, but values should be chosen after careful
consideration of oscillator tolerances and CAN propagation delays. For more information on CAN bit-time register settings, see
the specifications CAN 2.0A, CAN 2.0B, and ISO 11898-1.
The following equations can be used to calculate the number of time quanta in bit-time segments:
tTSEG1 = tq*(8*TSEG1[3]+4*TSEG1[2]+2*TSEG1[1]+TSEG1[0]+1)
tTSEG2 = tq*(4*TSEG2[2]+2*TSEG2[1]+TSEG2[0]+1)
tSJW = tq*(2*SJW[1]+SJW[0]+1)
where tTSEG1, tTSEG2, and tSJW are the lengths of TS1, TS2, and SJW.
Note: A given bit-rate can be achieved with several bit-time configurations, but values should be chosen after careful
consideration of oscillator tolerances and CAN propagation delays. For more information on CAN bit-time register settings, see
the CAN 2.0A, CAN 2.0B, and ISO 11898-1 specifications.
1. In case of a CRC Error and a CRC delimiter corruption, only the FMER bit is set.
Status Register
The CAN Status Register provides a status of all conditions of the core. Specifically, FIFO status, Error State, Bus
State and Configuration mode are reported.
Status Register
Table 19 shows the SR bit positions in the SR and Table 20 provides SR bit descriptions.
Table 19: Status Register BIT Positions
0 — 19 20 21 22 23 — 24 25
Reserved ACFBSY TXFLL TXBFLL ESTAT[1..0] ERRWRN
26 27 28 29 30 31
BBSY BIDLE NORMAL SLEEP LBACK CONFIG
Interrupt Registers
The CAN controller contains a single interrupt line only, but contains several interrupt conditions. Interrupts are
controlled by the interrupt status, enable, and clear registers.
Table 21 shows the bit positions in the ISR and Table 22 provides ISR descriptions.
Table 21: Interrupt Status Register Bit Positions
0 — 19 20 21 22 23 24 25
Reserved WKUP SLP BSOFF ERROR RXNEMP RXOFLW
26 27 28 29 30 31
RXUFLW RXOK TXBFLL TXFLL TXOK ARBLST
Message Storage
The CAN controller has a Receive FIFO (RX FIFO) for storing received messages. The RX FIFO depth is configurable
and can store up to 64 messages.
Messages that pass any of the acceptance filters are stored in the RX FIFO. When no acceptance filter has been
selected, all received messages are stored in the RX FIFO.
The CAN controller has a configurable Transmit FIFO (TX FIFO) that can store up to 64 messages. The CAN
controller also has a High Priority Transmit Buffer (TX HPB), with storage for one message. When a higher priority
message needs to be sent, write the message to the High Priority Transmit Buffer. The message in the Transmit
Buffer has priority over messages in the TX FIFO.
Message Structure
Each message is 16 bytes. Byte ordering for the CAN message structure is shown in Table 27, Table 28,Table 29, and
Table 30.
Table 27: Message Identifier [IDR]
0 — 10 11 12 13 — 30 31
ID [28..18] SRR/RTR IDE ID[17..0] RTR
All 16 bytes must be read from the RX FIFO to receive the complete message. The first word read (4 bytes) returns
the identifier of the received message (IDR). The second read returns the Data Length Code (DLC) field of the
received message (DLCR). The third read returns Data Word 1 (DW1R), and the fourth read returns Data Word 2
(DW2R).
All four words have to be read for each message, even if the message contains less than 8 data bytes. Write
transactions to the RX FIFO are ignored. Reads from an empty RX FIFO return invalid data.
Identifier
The Identifier (IDR) word contains the identifier field of the CAN message. Two different formats exist for the
Identifier field of the CAN message frame: Standard and Extended frames.
• Standard Frames: Standard frames have an 11-bit identifier field called the Standard Identifier.Only the
ID[28..18], SRR/RTR, and IDE bits are valid. ID[28..18] is the 11 bit identifier. The SRR/RTR bit differentiates
between data and remote frames. IDE is '0' for standard frames. The other bit fields are not used.
• Extended Frames: Extended frames have an 18-bit identifier extension in addition to the Standard Identifier.
All bit fields are valid. The RTR bit is used to differentiate between data and remote frames (The SRR/RTR bit
and IDE bit are both '1' for all Extended Frames).
Table 31 provides bit descriptions for the Identifier Word. Table 32 provides bit descriptions for the DLC Word.
Table 33 provides bit descriptions for Data Word 1 and Data Word 2
Reads from RX
FIFO Identifier Extension: This bit differentiates between frames
using the Standard Identifier and those using the Extended
12 IDE 0 Identifier. Valid for both Standard and Extended Frames.
Writes to
‘1’ = Indicates the use of an Extended Message Identifier.
TX FIFO and
‘0’= Indicates the use of a Standard Message Identifier.
TX HPB
Reads from RX
FIFO Extended Message ID: This field indicates the Extended
Identifier.
13–30 ID[17..0] 0 Valid only for Extended Frames.
Writes to
For Standard Frames, reads from this field return ‘0’s
TX FIFO and
For Standard Frames, writes to this field should be ‘0’s
TX HPB
Remote Transmission Request: This bit differentiates
Reads from RX between data frames and remote frames.
FIFO
Valid only for Extended Frames.
31 RTR 0 ‘1’ = Indicates that the message object is a Remote Frame
Writes to
‘0’ = Indicates that the message object is a Data Frame
TX FIFO and
For Standard Frames, reads from this bit returns ‘0’
TX HPB
For Standard Frames, writes to this bit should be ‘0’
Acceptance Filters
The number of acceptance filters is configurable from 0 to 4. The parameter Number of Acceptance Filters specifies the
number of acceptance filters that are chosen. Each acceptance filter has an Acceptance Filter Mask Register and an
Acceptance Filter ID Register.
Acceptance filtering is performed in the following sequence:
1. The incoming Identifier is masked with the bits in the Acceptance Filter Mask Register.
2. The Acceptance Filter ID Register is also masked with the bits in the Acceptance Filter Mask Register.
3. The resultant values are compared.
4. If the values are equal, the message is stored in the RX FIFO.
5. Acceptance filtering is processed by each of the defined filters. If the incoming identifier passes through any
acceptance filter, the message is stored in the RX FIFO.
The following rules apply to the Acceptance filtering process:
• If no acceptance filters are selected (for example, if all the valid UAF bits in the AFR register are '0's or if the
parameter Number of Acceptance Filters = '0'), all received messages are stored in the RX FIFO.
• If the number of acceptance filters is greater than or equal to 1, all the Acceptance Filter Mask Register and the
Acceptance Filter ID Register locations can be written to and read from. However, the use of these filter pairs
for acceptance filtering is governed by the existence of the UAF bits in the AFR register.
Transmitting a Message
A message to be transmitted can be written to either the TX FIFO or the TX HPB. A message in the TX HPB gets
priority over the messages in the TX FIFO. The TXOK bit in the ISR is set after the CAN core successfully transmits
a message.
Receiving a Message
Whenever a new message is received and written into the RX FIFO, the RXNEMP bit and the RXOK bits in the ISR
are set. In case of a read operation on an empty RX FIFO, the RXUFLW bit in the ISR is set.
Design Implementation
Device and Package Selection
• The AXI CAN can be implemented in an FPGA listed in the Supported Device Family field in the LogiCORE
IP Facts Table. Ensure that the device used has the following attributes:
• The device is large enough to accommodate the core, and
• It contains a sufficient number of IOBs.
Location Constraints
No specific I/O location constraints.
Placement Constraints
No specific placement constraints.
Timing Constraints
The core has two different clock domains: S_AXI_ACLK and CAN_CLK. The constraints given in the following
sections can be used with the CAN Controller.
I/O Constraints
I/O Standards
The pins that interface to the CAN PHY device have a 3.3 volt signal level interface. The following constraints can
be used, provided the device I/O Banking rules are followed.
# Select the I/O standards for the interface to the CAN PHY
INST "CAN_PHY_TX" IOSTANDARD = "LVTTL"
INST "CAN_PHY_RX" IOSTANDARD = "LVTTL"
C_CAN_TX_DPTH
LUTs
AXI
FMAX
Table 40: Performance and Resource Utilization Benchmarks for the Spartan-6 FPGA (xc6slx45t-2-fgg484)
Parameter Values Device Resources FMAX (MHz)
C_CAN_NUM_ACF
C_CAN_RX_DPTH
C_CAN_TX_DPTH
LUTs
AXI
FMAX
Table 41 shows example performance and resource utilization benchmarks for the Virtex®-6 FPGA
(xc6vlx130t-2-ff484 device).
Table 41: Performance and Resource Utilization Benchmarks for Virtex-6 FPGA (xc6vlx130t-2-ff484)
Parameter Values Device Resources FMAX (MHz)
C_CAN_NUM_ACF
C_CAN_RX_DPTH
C_CAN_TX_DPTH
LUTs
AXI
FMAX
Table 42: Performance and Resource Utilization Benchmarks for Virtex-7 FPGA (xc7v285t-1-ffg1157)
Parameter Values Device Resources FMAX (MHz)
C_CAN_NUM_ACF
C_CAN_RX_DPTH
C_CAN_TX_DPTH
LUTs
AXI
FMAX
Table 43: Performance and Resource Utilization Benchmarks for Kintex-7 FPGA (xc7k410t-1-ffg900)
Parameter Values Device Resources FMAX (MHz)
C_CAN_NUM_ACF
C_CAN_RX_DPTH
C_CAN_TX_DPTH
LUTs
AXI
FMAX
Table 44: Performance and Resource Utilization Benchmarks for Artix-7 FPGA (xc7a355tdie-3)
Parameter Values Device Resources FMAX (MHz)
C_CAN_NUM_ACF
C_CAN_RX_DPTH
C_CAN_TX_DPTH
LUTs
AXI
FMAX
System Performance
To measure the system performance (FMAX) of this core, this core was added as the Device Under Test (DUT) to
Spartan-6 and Virtex-6 FPGA system as shown in Figure 4.
Because the AXI CAN core is used with other design modules in the FPGA, the utilization and timing numbers
reported in this section are estimates only. When this core is combined with other designs in the system, the
utilization of FPGA resources and timing of the design varies from the results reported here.
X-Ref Target - Figure 4
AXI CDMA
(M_AXI_DP)
Device Under
D_LMB Test (DUT)
I_LMB (Low Speed Slave)
MDM
AXI4-Lite Domain
DS 62 24
Figure 4: Spartan-6/Virtex-6 FPGA System with the AXI CAN Core as the DUT
The target FPGA was then filled with logic to drive the LUT and block RAM utilization to approximately 70% and
the I/O utilization to approximately 80%. Using the default tool options and the slowest speed grade for the target
FPGA, the resulting target FMAX numbers are shown in Table 45.
Table 45: System Performance
Target FPGA Target FMAX (MHz)
S6LXT45-2 90
V6LXT130-1 180
The target FMAX is influenced by the exact system and is provided for guidance. It is not a guaranteed value across
all systems.
Support
Xilinx provides technical support for this LogiCORE IP product when used as described in the product
documentation. Xilinx cannot guarantee timing, functionality, or support of product if implemented in devices that
are not defined in the documentation, if customized beyond that allowed in the product documentation, or if
changes are made to any section of the design labeled DO NOT MODIFY.
Reference Documents
1. ISO 11898-1: Road Vehicles - Interchange of Digital Information - Controller Area Network (CAN) for High-Speed
Communication.
2. Controller Area Network (CAN) version 2.0A and B Specification, Robert Bosch GmbH
3. AXI Interconnect IP Data Sheet (DS768)
See www.xilinx.com/support/documentation/index.htm to find more Xilinx documentation.
Ordering Information
This Xilinx LogiCORE IP module is provided under the terms of the Xilinx Core Site License. The core is generated
using the Xilinx ISE® Embedded Edition software (EDK). For full access to all core functionality in simulation and
in hardware, you must purchase a license for the core. Contact your local Xilinx sales representative for information
on pricing and availability of Xilinx LogiCORE IP.
For more information, visit the AXI CAN product web page.
Information about this and other Xilinx LogiCORE IP modules is available at the Xilinx Intellectual Property page.
For information on pricing and availability of other Xilinx LogiCORE IP modules and software, contact your local
Xilinx sales representative.
List of Acronyms
Acronym Spelled Out
AFIR Acceptance Filter ID Register
AFMR Acceptance Filter Mask Register
AFR Acceptance Filter Register
BRPR Baud Rate Prescaler
BSP Bit Stream Processor
BTL Bit Timing Logic
BTR Bit Timing Register
CAN Controller Area Network
CRC Cyclic Redundancy Check
DCM Digital Clock Manager
DLC Data Length Code
DUT Device Under Test
DW Data Word
ECR Error Counter Register
Revision History
Date Version Revision
First release of the core with AXI interface support. The previous release of this document was
09/21/10 1.0
ds265.
09/21/10 1.0.1 Documentation only. Added inferred parameters text on page 7.
06/22/11 2.0 Updated for core version 1.03.a and 13.2 tools. Added new supported architectures.
Notice of Disclaimer
The 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 the Limited Warranties which can be viewed at
http://www.xilinx.com/warranty.htm; 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 Critical Applications:
http://www.xilinx.com/warranty.htm#critapps.