Home

User`s Manual Reference CAN VHDL

Contents

1. include test routines vhi begin PRESCALER 1 ROPAGATION_SEGMENT ds PHASE BUFFER SEGMENT 1 4 ty RESYNCHRONISATI 4 RMATION PROCESS ME INFORMATION PROCE iE TIMING t of test program ITE TRACE Just a template for a test program wait for 1 BIT TIME nd of t program ITE TRACE End of test program gt gt template lt lt reached assert false report End of Test Program reached Stop Simulation severity failure end process STIMULI end TEMPLATE Figure 26 architecture TEMPLATE of TEST PROGRAM Each new test program requires a specific directory in BOSCH CAN ROOT tests with the same name as the new architecture The new file test vpp starts as a copy of template vpp the architecture s name changed from TEMPLATE to test and the TIMING configuration changed to the BOSCH 77 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 actual values The test program code is inserted between the comments start of test program and end of test program additional constants e g messages to be transmitted signals and variables are defined at the positions shown by the appropriate comments For compilat
2. If the edge lies between sample point and the next Synchronization Segment PHASE ERROR 0 the Phase Buffer Segment 2 is shortened in the following way When the distance of the detected edge from the next Synchronization Segment is less than the resychronization jump width the time quanta counter is set to one COUNT 1 and a new bit time is started Else the number of time quanta for this bit time NTQ_I is decremented by DELTA The generation of TRANSMIT POINT is done only if the detected edge lies Information Processing Time after the sample point BOSCH 43 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 elsif HARD SYNC ENABLE 0 and BUS DRIVE 1 then Edge between SyncSeg and sample point Lengthen Phase Buffer Segment 1 if PHASE ERROR gt 0 then SAMPLE SAMPLE I DELTA NTQ I NTQ I DELTA Edge between sample point and next SyncSeg Shorten Phase Buffer Segment 2 elsif PHASE ERROR 0 then if COUNT gt NTQ I BIT TIMING CONFIGURATION RESYNCHRONIZATION JUMP WIDTH then COUNT 1 Generation of TRANSMIT_POINT only if edge lies Information Processing Time after sample point if DIFF gt BIT TIMING CONFIGURATION INFORMATION PROCESSING TIME then TRANSMIT POINT lt true TX DATA lt BUS DRIVE end if else NTQ I NTQ I DELTA end if end if Figure 10 Resynchronization Node Receiver Node is Transmitter If the node is transmitter there will only be a Resych
3. e Run time information stored in trace files Generation of pattern files supported The following support is provided to assist the user in working with the model and in understanding its functionality Detailed User Manual Example of a correct implementation for fast start up Example of a buggy implementation for the demonstration of the testbench s functionality Well documented source code This model was developed and verified with Synopsys VSS v3 4b Mentor Graphics QuickHDL v8 5 4 6f and with Mentor Graphics ModelSim 5 2b A portation to other VHDL Simulators will require an adaption of the make files Typically a CAN implementation consists of three major parts Interface to the CPU CAN Protocol Controller Message Memory Using the test programs supplied with this VHDL Reference CAN Model only assures the conformity of the CAN Protocol Controller part of an implementation with CAN Protocol Version 2 0 Part A B In order to verify the correct function of the CPU interface and of the message memory the user has to write additional test programs BOSCH En K8 EIS VHDL Reference CAN User s Manual Revision 2 2 2 Installation To install the VHDL Reference CAN Model from the CD ROM please proceed the following way Create a directory where you want to install the database by typing mkdir path to model Bosch CAN Example mkdir projects Bosch CAN 2 Copy the TAR file RefCAN Revision 2 2 tar t
4. PROTOCOL TESTBENCH aoinne penedir e eode one edic o Pd eT i aeaii 29 42 CAN SYSTEM 4 otc WE SEAF S EY ERR EAR MUSEI ET URN UE SAN UNE WEE SA aE 30 4 2 1 configuration SYS I of CAN SYSTEM eeeeeeeeeeeenerenneee ener enne enne 31 4 2 2 configuration SYS_E of CAN SYSTEM eene 3l 4 2 3 configuration SYS_B of C AN SYSTEM s isset PRO PIN erR eps 31 4 2 4 configuration SYS_R of CAN_SYSTEM seesessesessereeseereerersersresressersresrreseese 31 T35 BS SINTER AC a deed nde aut Ma R in eue tb te Ac cali 32 4A CANANTERFACE chinia eo tutus e line ee ed aa 33 44 1 architecture COMPARE eseseeesesesseeesseessersseresssersseesseesseesseeeseessseessresseeesereseeee 34 SATI CHECKER renari a a ai hey inset g ne a ei 35 4 4 2 architecture RBEEBREN GBE a dash I RI IRNUS ot eap dace atuis 38 442 1 process OSCILLATOR nir aa teo irpo t t ESS 39 2422 process PRBSCALBR foutu tas esee INO ROI Ie ee RUE 39 4 4 2 3 process BIT TIMING eese tet ed e n rr reet a Enis 39 n 23t OVV EW der 39 4 4 2 3 2 Structure of process BIT TIMING ee 40 432 35 Synchronization zs ees ciere ea ibas cae teda ae 41 4 4 2 4 process BIT STREAM PROCESSOR esee 46 LU MNEBIT IU Pt CD REED 46 44 2 42 Frame Format sisi ceases teasbesesgsystovaiassecaaacvaied der aner SE Re eua i 47 4 4 2 4 3 Structure of process BIT STREAM PROCESSOR 48 4 4 2 5 Output to the Trace File usato vetu e iuh tet ie sq edse bo
5. BUS INTERFACE and to the message memory by the signals RECEIVED MESSAGE and TRANSMIT MESSAGE The entity has the following ports generic MODEL LABEL Each component of this entity has a particular name generic CLOCK PERIOD is an array of the base time units of the CAN SYSTEM generic RX DELAY used to synchronize Reference and Implementation generic GET RECEIVE ERROR COUNTER FROM MODEL O0 optional only for protocol check in RESET restores the initial state of the entity in RECEIVE DATA is the data input from BUS INTERFACE out TRANSMIT DATA is the data output to BUS INTERFACE in BIT TIMING CONFIGURATION is the definition for the CAN bus bit time out RECEIVED MESSAGE is the last received message in TRANSMISSION REQUEST if true the CAN node is required to transmit in TRANSMIT MESSAGE is the message to be transmitted out TRANSMISSION REQUEST STATUS shows the processing of a requested transmission The functionality of a certain instance of CAN INTERFACE depends on the architecture which is associated to that instance in a configuration The following architectures and configurations are available for CAN INTERFACE COMPARE compares implementation s model with reference model during simulation REFERENCE reference model of a CAN Protocol Controller IMPLEMENTATION model of user s implementation currently substituted by REFERENCE EXAMPLE example of a CAN module including message memory and CPU interface BAD EXAMPLE example of a buggy CA
6. CAN model how to include his own implementation model into the protocol testbench To run the simulation of a single test for the example of an implementation model e g test crc type make crc e The trace information of this simulation run is located in file czc e trace 3 1 3 Simulating the Example of a Buggy Implementation The example of a buggy implementation is identical to example of an implementation with the difference that some faults were inserted in the CAN protocol controller part This buggy version of a CAN implementation demonstrates how CAN protocol error are detected To run the simulation of the example of a buggy implementation model e g test btl type make btl b During the simulation there will appear some messages on the screen like the one below 3493250 NS Assertion ERROR at 3493250 NS in design unit CHECKER BEHAVIOUR from process PROTOCOL TESTBENCH SYSTEM CHECK1 PROTOCOL CHECK CMP RX Protocol Error Invalid BUSMON These messages will give you a hint where the problem may be located The trace information of the simulation run can be found in file bt1 b trace BOSCH _5 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 3 2 Test programs The CAN protocol test programs check the behaviour of a CAN implementation by comparing them with the behaviour of the Reference CAN Model node Their purpose is to check whether the CAN protocol is correctly implemented in the model of the implementation
7. DATA PzBIT TIMING OSCILLATOR PRESCALER P P TIME QUANTA CLOCK BUSMON SAMPLE POINT ul d t a ul o z gt o a tr a I BUS DRIVE Trace Signals MM P BIT STREAM PROCESSOR processes trace information BOND OUT GET RECEIVE ERROR COUNTER HROM MODEL 0 MODEL LABEL CLOCK PERIOD RX DELAY BIT TIMING CONFIGURATION RECEIVED MESSAGE TRANSMIT MESSAGE TRANSMISSION REQUEST STATUS TRANSMISSION REQUEST Figure 5 architecture REFERENCE of CAN INTERFACE BOSCH _ 38 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 The Reference CAN Model architecture shown in figure 5 consists of the following processes OSCILLATOR PRESCALER BIT TIMING BIT STREAM PROCESSOR REQUEST STATUS TRACE MESSAGE TRACING The functions implemented in these processes are described in the following subsections 4 4 2 1 process OSCILLATOR Generates the clock signal CLOCK which is input to process TIME QUANTA CLOCK CLOCK is based on the generic parameter CLOCK PERIOD and has a phase shift of MODEL LABEL ns The phase shift assures that the different instances of the reference model are evaluated in an explicit sequence 4 4 2 2 process PRESCALER The TIME QUANTA CLOCK is derived from CLOCK by dividing it by the prescaler value BIT TIMING CONFIGURATION PRESCALER The TIME QUANTA CLOCK is the clock input for process BIT TIMING 4 4 2 3 process BIT TIMING 4 4 2 3 1 Overview This process
8. Error Flag the RECEIVE DATA input is forced to dominant for another 64 bits After each sequence of additional eight consecutive dominant bits the transmitter detects a form error and increases the error counter by 8 30 Dominant bit at last bit of Error Delimiter Error Passive The last recessive bit of Error Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame 31 Dominant bit at 3rd bit of Intermission Error Passive The last bit of Intermission is forced to dominant The node is Error Passive and becomes receiver The next 5 bits are also forced to dominant The receiver detects a stuff error and sends a Passive Error Flag The receive error counter is incremented by 1 32 Dominant bit at the first bit after receiver s Passive Error Flag The first bit after the Passive Error Flag is forced to dominant The receiver increments the receive error counter by 8 33 Dominant bit at receiver s Error Delimiter Error Passive The 4th bit of Error Delimiter is forced to dominant The receiver detects a form error and increments the receive error counter by 1 34 Dominant bit at the first bit after receiver s Passive Error Flag The first bit after 6 consecutive recessive Passive Error Flag bits is forced to dominant The receiver increments the receive error counter by 8 35 Dominant bit at receiver s Error Delimiter Dominant bit after Passive Error Flag seen as dominant The rece
9. IDE bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 and stuff error after IDE bit The recessive stuff bit after the IDE bit is forced to dominant The transmitter detects a stuff error and sends an Active Error Flag The transmit error counter is increased by 8 Bit O and stuff error after IDE bit The dominant stuff bit after IDE bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Extended Identifier 13 14 15 16 17 18 Bit 1 error at the 4th bit of extended Identifier The recessive extended Identifier bit is forced to dominant The transmitter loses arbitration and becomes receiver After the 9th ext Identifier bit the receiver detects a stuff error and send an Active Error Flag Bit O error at the 2nd bit of extended Identifier The dominant extended Identifier bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 error at RTR bit The recessive RTR bit is forced to dominant The transmitter loses arbitration and becomes receiver After the 4th bit of Data Length Code the receiver detects a stuff error and sends an Active Error Flag Bit 0 error at RTR bit The dominant RTR bit is forced to recessive The transmitter detects a bit error a
10. Identifier Data Length Code or CRC Delimiter POSITION Bit position inside a FIELD The first bit has always the POSITION number 1 The following paragraph lists all valid FIELD names The number in brackets is the range of POSITION Not taking part in message transfer not influencing the bus Reset 1 4 Wait For Bus Idle 1 Bus Idle 1 1 Bus Off 1 Data Frame or Remote Frame Start Of Frame 1 Identifier 1 11 SRR Bit 1 IDE Bit 1 Ex Identifier 1 18 RTR Bit 1 Reserved Bits 0 1 Data Length Code 1 4 Data Field 1 8xNBytes only in Data Frames CRC Sequence 1 15 CRC Delimiter 1 ACK Slot 1 ACK Delimiter 1 End Of Frame 1 7 Error Frame Active Error Flag 1 6 Passive Error Flag 1 6 Error Delimiter 2 8 lst bit is last bit of Error Flag Overload Frame Overload Flag 1 6 Overload Delimiter 2 8 lst bit is last bit of Error Flag InterFrame Space Intermission 1 3 Suspend Transmission 1 8 Each of the fields Reset Wait For Bus Idle Bus Idle and Bus Off implies one special STATUS For example Bus Idle points to IDLE and Bus Off points to BUS OFF RECOVERY All other fields are linked with STATUS RECEIVING or TRANSMITTING In process BIT STREAM PROCESSOR Data Frame and Remote Frame and all the fields in it are calculated in own program sections separated in TRANSMITTING and RECEIVING The Error Frame the Overload Frame an
11. QUANTA CLOCK while synchronization is started with the rising edge of TIME QUANTA CLOCK 3 2 4 crc Cyclic Redundancy Check and Acknowledge NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Test of receiver s error detection in case of Bit Error in the Data Field and in the CRC Field and test of the transmitter s reaction on acknowledge errors The program consists of the following test steps Test of receiver 1 Recessive bit at reserved bit rO The dominant bit at rO is forced to recessive The receiver detects a CRC error sends a recessive ACK bit and an Active Error Flag after the ACK Delimiter The receive error counter is increased by 1 2 Dominant bit at the 2nd bit of CRC Field The recessive bit of CRC Field is forced to dominant The receiver detects a CRC error sends a recessive ACK bit and an Active Error Flag after the ACK Delimiter The receive error counter is increased by 1 The receiver detects a dominant bit after sending its Error Flag and increases its error counter by 8 Test of transmitter 1 Recessive bit at ACK Slot RECEIVE DATA input of RefCANO is forced to recessive The bus state of RefCAN2 is idle because the RECEIVE DATA input is forced to recessive The transmitter RefCANI detects an ACK error and sends an Active Error Flag The transmit error counter is increased by 8 2 Recessive bits after 2nd bit of Active Error Fla
12. SET TRANSMISSION REQUEST START TRANSMISSION RESET TRANSMISSION REQUEST and HOLD TRANSMISSION REQUEST are boolean vectors with one element for each node in the CAN SYSTEM STIMULI or to be more specific its local procedure SEND MESSAGE has three options to control the TRANSMISSION REQUEST input of a CAN node t can control TRANSMISSION REQUEST directly by SET TRANSMISSION REQUEST and RESET TRANSMISSION REQUEST e START TRANSMISSION requires REQUEST to activate TRANSMISSION REQUEST until TRANSMISSION REQUEST STATUS changes to TRANSMITTING HOLD TRANSMISSION REQUEST requires REQUEST to activate TRANSMISSION REQUEST until TRANSMISSION REQUEST STATUS changes to DONE REQUEST WHILE BUSY is a boolean vector with one element for each node in the CAN SYSTEM Its elements are set to true by REQUEST if STIMULI requests a transmission for a particular CAN node while that CAN node is already busy with a transmission Status information about transmission requests of the CAN nodes is written to the simulation s trace file 4 5 3 process SYNCHRONIZE REQUEST This process is part of every protocol test program It sets and resets the TRANSMISSION REQUEST inputs of all CAN nodes The process is controlled by the input signal vector LOCAL TX REQUEST from process REQUEST the bond out signal BOND OUT 0 TXRQST and signal DO ARBITRATION which is controlled by process STIMULI To force a synchronous Start Of Frame for the implementation unde
13. Verification of an Implementation e eeee eee eee eee eene ee eese teens sese eno 69 5 1 Integrating an Implementation s Model into the Reference CAN Model 12 5 2 Configuration of the Testbenchk ono edic eee oed igi ob d ee 75 5 3 Adding Test programs c osi viec ent viai tbt a duda tinto tas uud Des ease at 5 4 Generating Test Vectots cc cisasceiianvecsaseisstotessnecsesapencsuaunse aileteasaatongate ssaeeateannesaanaee PR OU RS 79 LIMES 80 A 2 List of Figures M 83 VM Br a d III mer 83 A 4 Related D c ments aoro eno nin ie bie ento eee dsns edo tea Van EN e eR ER PER ERAN 83 A 5 CAN vil amp arlc d n 83 BOSCH iv K8 EIS VHDL Reference CAN User s Manual Revision 2 2 1 Introduction The VHDL Reference CAN Model is intended for semiconductor designers manufacturers who want to build their own implementation of a CAN device using VHDL as hardware description language It is provided in addition to the existing C Reference CAN Model The user of this model is expected to be familiar with the CAN Specification Revision 2 0 Part A and B The model is supplied together with a testbench supporting the following features CAN Protocol Version 2 0 Part A B Flexible testbench environment e Simulates entire CAN bus system number of nodes defined by user Easy inclusion of user defined implementations Test program set can be extended by user
14. architecture COMPARE The configuration CONFIGURATION BUGGY of architecture EXAMPLE of CAN INTERFACE which is used here is described in section 4 4 5 4 2 4 configuration SYS R of CAN SYSTEM In this configuration only architecture REFERENCE is used for all instances of CAN INTERFACE This configuration not depending on any implementation s model is intended for the development of test programs see section 5 3 BOSCH 81 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 3 BUS INTERFACE BUS INTERFACE is used to connect an instance of CAN INTERFACE to the CAN BUS The entity has the following ports generic TX DOMINANT DELAY delay when driving a dominant bit to the CAN bus generic TX RECESSIVE DELAY delay when driving a recessive bit to the CAN bus generic RX DELAY delay when receiving a bit from the CAN bus in RESET inout CAN BUS model of a CAN bus may be dominant or recessive in BUS_INTERFERENCE forces RECEIVE_DATA to specific values out RECEIVE_DATA output to CAN_INTERFACE in TRANSMIT_DATA input from CAN_INTERFACE In the CAN_SYSTEM the physical layer of the CAN bus is represented by a single bus line which can be driven to the values RECESSIVE and DOMINANT by each of the instances of BUS_INTERFACE connected to CAN BUS The resolution function used for CAN BUS ensures that a single dominant level will override all recessive levels Only one architecture exists for BUS INTERFACE named BEHAVIOUR In
15. controls bit timing and synchronization samples the RECEIVE DATA input and drives the TRANSMIT DATA output The signals below are input to process BIT TIMING RESET TIME QUANTA CLOCK BIT TIMING CONFIGURATION PRESCALER PROPAGATION SEGMENT PHASE BUFFER SEGMENT 1 RESYNCHRONISATION JUMP WIDTH INFORMATION PROCESSING TIME RECEIVE DATA HARD SYNC ENABLE BUS DRIVE The following signals are output of process BIT TIMING BUSMON SAMPLE POINT TRANSMIT DATA BOND OUT MODEL LABEL BUSMON BOND OUT MODEL LABEL TRANSMIT POINT The BOND OUT Signals are defined in package trace package vhd They are used by CHECKER as described in section 4 4 1 1 The generic MODEL LABEL is used to address a certain instance of CAN INTERFACE BOSCH 39 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 2 3 2 Structure of process BIT TIMING In the following paragraph the flow of process BIT TIMING as shown in figure 6 is explained BIT TIMING RESET BIT TIMING CONFIGURATION TIME QUANTA CLOCK if RESET then Initialize signals and variables end if if BIT TIMING CONFIGURATION event or RESET event and not RESET then Recalculation of quasi constants sample point Phase Buffer Segment 2 Number of time quanta in a bit time end if if TIME QUANTA CLOCK event and TIME QUANTA CLOCK 1 then Control of bit timing and bus line Sample bus line Drive bus line Hard Synchronization and Resynchronization end if Figur
16. end for end CFG TEMPLATE Figure 24 Template for a testbench configuration The following generic parameters define the timing of the CAN system s simulation CLOCK PERIOD is an array of time values It ranges from 0 to NUMBER OF CANS 1 providing each CAN node 1 to NUMBER OF CANS in the CAN system with an independent clock source CLOCK PERIOD 0 is reserved for the clock of the implementation under test with CLOCK PERIOD NUMBER OF CANS 1 as an option for the implementation s local CPU In this configuration all nodes use the same clock period of 100 ns RX DELAY is an input delay factor to be multiplied with the implementation model s clock period Used in the architecture COMPARE of CAN INTERFACE to compensate the delay time caused by the syn chronization of the CAN input signal to the implementation model s clock CLOCK PERIOD and RX DELAY have to be the same for CAN SYSTEM and TEST PROGRAM INFORMATION PROCESSING TIME is an intrinsic attribute of the implementation s design The test program needs access this parameter for the configuration of the CAN bit time BOSCH 75 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 INITIALIZATION CYCLES is a parameter that allows to compensate for the time needed to initialise the implementation s model after a hardware reset One cycle is two CAN bit times INIT SETUP isa phase shift factor The evaluation time steps of the test program are shifted with
17. events supporting debugging and documentation To simplify the commenting of the pattern file the procedure WRITE TRACE see section 4 5 1 4 used to write to the trace file can optionally write to the pattern file WRITE TRACE called with a string parameter writes the string into the simulation s trace file An optional second parameter controls whether the same string is copied into the pattern file and the string s print format This procedure has to be adapted to the actual vector reading tool preceding each text string with the tool s comment symbol Since no test vectors are generated in distributed version of the Reference CAN Model the write accesses of WRITE TRACE to the pattern file are disabled by USE SECOND FILE 0 In order to enable those write accesses the vector generating process has to set USE SECOND FILE to 1 Even if no text is written to the pattern file some VHDL simulators may generate the empty file pattern BOSCH _79 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 A 1 List of Files Model Top Directory README RefCAN txt Important information about this version simulate the compilation and simulation environment SSynopsys vss setup Synopsys setup file generated by genmake synopsys sim inc include file for Synopsys VSS simulator generated by genmake quickhdl ini setup file for Mentor ModelSim generated by genmake modelsim ini setup file for Mentor QuickHDL gene
18. if the feature is enabled by CAN INTERFACE s generic GET RECEIVE ERROR COUNTER FROM MODEL O0 The Reference CAN Model that is simulated in parallel to the implementation s model inside architecture COMPARE is the only CAN node for which this feature is enabled see section 4 4 1 Other architectures of CAN INTERFACE ignore this generic with the exception of BAD EXAMPLE The second feature is a freeze function In order to synchronize the Reference CAN Model to external events it is possible to stop its bit processing not its bit synchronization by setting the global signal FREEZE MODEL LABEL to true FREEZE is a global signal that is defined in the package definitions vhd itis an array of boolean range from 1 to MAXIMUM NUMBER OF CANS While the Reference CAN Model is frozen it still synchronizes itself to the bit stream when it is thawed up by setting FREEZE MODEL LABEL to false it restarts its bit processing at the same state when it was frozen The freeze function is provided for the test of implementation s models that need a longer idle time between messages to set up new messages or to read received messages e g implementations with a slow CPU interface it is not used in the existing test programs BOSCH 57 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 3 architecture IMPLEMENTATION The architecture IMPLEMENTATION of CAN INTERFACE is an external shell for the user s model of a CAN imple
19. is forced to dominant setting the node to Error Passive 16 Receive correct frame REC 119 127 The receiver waits for the last bit of Intermission and receives a new frame After the successful reception the receive error counter is set to below 128 17 Receiver sees local bit error in CRC_Field One bit of the received message is falsified causing a CRC Error 18 Receiver with CRC Error sees foreign dominant Acknowledge gt Rec 0 Node does not send a dominant Acknowledge but samples a dominant bit in the Acknowledge Slot 19 Receiver starts CRC Error Flag REC REC 1 Active Error Flag is started after Acknowledge Delimiter because of CRC Error 20 Recessive Bit in Error Flag gt Error Passive A bit Error in Active Error Flag sets the node to Error Passive BOSCH 13 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Test of transmitter 1 2 3 4 5 6 Error Passive Transmitter with TEC lt 128 sees Bit Error at dominant Identifier bit Node sends Passive Error Flag and adds Suspend to Interframe Space Error Passive Transmitter sees 104 consecutive dominant bits after Passive Error Flag Transmit error counter is incremented to 120 Receive error counter is decremented by reception of correct messages Node is Error Active transmit error counter is incremented to 128 Node is Error Passive Receiver sees Stuff Error and 16 consecutive dominant bits after Error Flag Rec
20. is true beginning with Start_Of_Frame or changes the STATUS to IDLE STATUS TRANSMITTING FIELD Suspend_Transmission The Error Passive transmitter sends after Intermission 8 recessive bits on the bus When meanwhile a dominant bit occurs the node interprets this as Start_Of_Frame and becomes receiver After sending the suspend bits the transmitter starts transmitting a message if TRANSMISSION_REQUEST is true or if false change STATUS to IDLE STATUS TRANSMITTING FIELD others The field others contains the transmission of a data frame from the field Start_Of_Frame to End_Of_Frame The first part assigns the actual TRANSMIT_BIT from the BIT_MESSAGE in depend of FIELD POSITION and STUFF_BIT The TRANSMIT ERROR COUNTER is decremented by 1 at the last bit of End_Of_Frame and the STUFF_ENABLE variable is set false at the end of the stuffed area If STUFF CONDITION is true the next bit is a stuff bit Then POSITION is not incremented and FIELD is not changed The stuff bits are not part of BIT_MESSAGE The next part sets the BUS_DRIVE signal BUS_DRIVE is the bit which is transmitted in the next event If the next bit is a stuff bit then BUS_DRIVE gets the complementary value of the actual transmitted bit In the other case BUS_DRIVE gets the value of the next bit from BIT_MESSAGE The next section checks for the error conditions during the transmission First a stuff error at RTR bit in an extended frame is checked because this stuff error
21. like a message memory or a bus interface additional test programs can be included in the testbench The file template vpp defines an architecture TEMPLATE of TEST PROGRAM This architecture can be used as a template when writing additional test programs for the verification of an implementation see section 5 3 The architecture FLEXIBLE of CAN SYSTEM is structural and connects the CAN model to be verified component CHECK1 with a flexible number of Reference CAN Model nodes interacting via the CAN bus Which CAN model is used as component CHECK1 is defined by a configuration of CAN SYSTEM the actual number of Reference CAN Nodes is defined by a configuration of PROTOCOL TESTBENCH BOSCH 28 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 1 PROTOCOL TESTBENCH The protocol testbench as shown in figure 1 is the top level entity It has neither inputs nor outputs and is described by only one architecture STRUCTURAL STRUCTURAL consists of the two components WAVEFORM and SYSTEM These two components are connected by a set of interface signals The interface record signals driven by TEST PROGRAM RESET BIT TIMING CONFIGURATION 1 to MAXIMUM NUMBER OF CANS PRESCALER PROPAGATION SEGMENT PHASE BUFFER SEGMENT 1 RESYNCHRONISATION JUMP WIDTH INFORMATION PROCESSING TIME BUS INTERFERENCE l to MAXIMUM NUMBER OF CANS TRANSMIT MESSAGE to MAXIMUM NUMBER OF CANS FRAME KIND MESSAGE IDENTIFIER KIND MESSAGE I
22. lower priority read status registers and received messages from the message memory see architecture READ WRITE of CPU at page 62 making this internal information visible at the device s pins For those CAN modules on Cs whose CPU interface is only accessible by the local CPU not from the outside a different structure for architecture IMPLEMENTATION is recommended see figure 23 providing the same features as verification of the message memory and compatibility with a hardware tester TRANSMIT DATA RECEIVE DATA E CAN INTERFACE E EMBEDDED WITH CAN Y CAN MODULE MEMORY PERIPHERY E ROM A z OPCODE A IMPLEMENTATION Interface Signals Figure 23 Verification of a CAN module of an embedded microcontroller BOSCH 73 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 For this solution the local CPU has to have the capability at least in test mode to read op codes from an external memory As in EXAMPLE the entire device should be simulated but the other component in the architecture replacing the CPU state machine is a program memory providing op codes to the local CPU This program memory translates the protocol test program s commands into executable code causing the CPU in the device under test to write to the CAN module s registers BOSCH 74 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 5 2 Configuration of the Testbench Figure 24 shows the configuration of the PRO
23. name Naming conventions used with the figures E name of entity P name of process A z name of architecture BOSCH ii K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Contents NEM dier EC 1 PA SAI E A CON e 2 3 Compilation and Simulation sseosseessossseossessssesssossocessessssesssossocesseossoesssossoss 3 3l cStarting the Simulation on Cretae ated doces laci E ee eee 4 3 1 1 Simulating the User s Implementation eeeeeeeeeeeeeeeeene nene 4 3 1 2 Simulating the Example of an Implementation eee 5 3 1 3 Simulating the Example of a Buggy Implementation sese 5 2 27 3DESEDEOSEAITISS oia ae a E E RE TE S ETE E R a c a ected anes 6 S ANNE CI ri onen E EE 6 3 2 25 DIETON c ea ooh netu f edu n lai o S bt ME 6 SA M T 9 SR ME amr 10 SEE shag TEE Nee RE 11 3 00 TUR COUDES dio oe ute Rue ro dab ote nA a cae el one 12 32 sext P CLE 17 Duo POEIBIOET Ue ede o e ete pg oder eet esu cadase aN ce edet matt aN 18 RI NE P E A 20 32 10 overload D E ded 21 3 2 lal SEDDI dete dto node io tS a te aeta que 22 FD SE IUIS ye RDUM P EPA 22 3 2 PAN AMD ihre oeste a Nite ce Ne muon da puncta oA S dcr ut aa vhs 24 4 Model Descriptioh ooo eees reote aepo e torte vnde Eee IS erp Ee eeu e PESO PS PEE E NEP EE sisstin 27 ZI
24. record by concurrent statements otherwise the BOND OUT record elements are assigned inside a process In both cases the assignments to the BOND OUT signal are to be excluded from the design synthesis There are three generic parameters which can be used to adjust the evaluation time of the Reference Model s processes to the evaluation time of the implementation to be verified INITIALIZATION CYCLES time needed to configure the implementation after Reset INIT SETUP adjusts evaluation time of process STIMULI of TEST PROGRAM RX DELAY compensation of the physical input delay of the implementation An architecture as described in EXAMPLE is recommended for all cases of standalone CAN controllers and for those CAN modules on microcontrollers whose CPU interface can be accessed from the outside at least in a test mode The advantage of this solution simulating the whole device compared to other BOSCH 72 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 solutions e g extracting the CAN Protocol Controller from the implementation and simulating without a CPU component in architecture IMPLEMENTATION is that it can produce test vectors for the device s pins With these test vectors the protocol test programs can be transferred to hardware testers Especially for the verification of the message memory the CPU state machine should not be restricted to the translation of the test program s input to the CAN module it also should with
25. respect to the active rising clock edge of the Reference CAN Model by the amount of INIT SETUP CLOCK PERIOD 1 The phase shift provides a setup time between the edges of the interface sig nals driven by the test program and the internal state transitions of the Reference CAN Model Figure 25 shows the configuration of the PROTOCOL TESTBENCH to simulate the test program BAUDRATE see file SBOSCH CAN ROOT tests baudrate cfg baudrate example vhd library CAN LIBRARY This configuration defines the following entity architecture pairs PROTOCOL TESTBENCH STRUCTURAL CAN SYSTEM FLEXIBLE 1 Example Implementation and 3 Ref Models CAN INTERFACE EXAMPLE It is used with configuration EXAMPLE of CAN INTERFACE configuration CFG BAUDRATE E E of PROTOCOL TESTBENCH is for STRUCTURAL for SYSTEM CAN SYSTEM use configuration CAN LIBRARY CONFIGURATION SYS FE generic map NUMBER OF CANS gt 3 CLOCK PERIOD gt 110 ns 110 ns 1118 ns 442 ns others gt 110 ns RX DELAY 0 001 end for for WAVEFORM TEST PROGRAM use entity CAN LIBRARY TEST PROGRAM BAUDRATE generic map CLOCK PERIOD gt 110 ns 110 ns 1118 others gt INFORMATION PROCESSING TI
26. the CAN protocol error The same phase compensation is used for the other compared signals with the exception of the error counters The error counters are compared at the sample point only If the receive error counter reaches the error passive level CHECKER only verifies that both receive error counters are above the error passive limit 127 their actual values are not compared When the receive error counters are decremented again finishing error passive they are set to a value in the range of 119 to 127 The Reference CAN Model node adjusts itself to the value of the implementation s receive error counter see section 4 4 2 7 At the reception of a message CHECKER compares the RECEIVED MESSAGE port signals of implementation and Reference CAN Model The comparision is done at the implementation s RECEIVED MESSAGE events rather than the reference model s in order to allow implementations with a hardware acceptance filtering that do not accept certain messages of the reference testbench In case of restricted implementations only that part of the message that is inside the restriction is checked BOSCH _37 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 3 architecture REFERENCE This architecture implements the functionality of a CAN controller as defined by CAN Specification Revision 2 0 Part A and B It is used to check an user written implementation using the test programs described in section 3 2 RECEIVE DATA TRANSMIT
27. the previous message is lost The reception of a message is documented by printing the content of the message into the simulation s trace file In the TRANSMIT_BUFFER Do_Transmit and Tx_Pending are command and status bits which can be read and written by the CPU The CPU sets both Do_Transmit and Tx_Pending to request the transmission of a message When the transmission has started the message memory resets Tx_Pending BOSCH 60 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 When the transmission is successfully completed and Tx Pending is not set again by the CPU the message memory resets Do Transmit If the CPU resets Do Transmit before the transmission is completed the transmission will not be repeated in case of an error or when it lost arbitration The TRANSMISSION REQUEST signal to the CAN Protocol Controller is active as long as Do Transmit is set Any changes of TRANSMISSION REQUEST are documented by printing a note into the simulation s trace file 4 4 4 1 2 architecture PARALLEL 16 BIT of CPU INTERFACE This architecture connects the external tristate CPU BUS with the tristate INTERNAL BUS both buses being 16 bits wide with a non multiplexed 4 bit ADDRESS bus The direction of the tristate buses is controlled by the signals READ and WRITE The internal control signals READ T and WRITE T for the control register are generated from READ WRITE and ADDRESS The address decoding for the message memory is done in that c
28. they are by no means a production test The programs are not adapted to a specific implementation the success of this test patterns is a necessary not a sufficient condition for the assessment of the implementation In the following the different waveforms are listed in alphabetical order and described in detail 3 2 1 baudrate Test of Prescaler and Oscillator Tolerance NUMBER OF CANS 3 Bit Timing Different Bit Timing for each Node This architecture uses a system configuration with three CAN nodes The first CAN node consists of one implementation CAN model and one Reference CAN Model node working in parallel the other two nodes consist of Reference CAN Model nodes Each node gets a different timing configuration depending on different clock periods The resulting minimum and maximum bit time are in an area of 1 796 around the average bit time In three cycles the three nodes start the transmission of a message In the first cycle the third node wins the arbitration in the second cycle the second node and in the third cycle the first node wins the arbitration As additional handicap the messages transmitted are designed to contain a maximum of stuff bits reducing the number of edges that can be used for resynchronisation Those nodes losing arbitration do that immediately next to a stuff bit After the last transmission when the bus is idle the position of the sample point in the scaled bit time is checked by applying a spike to domi
29. transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 3 23 btl Bit Timing NUMBER OF CANS 1 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 To test Hard Synchronization and Resynchronization an edge from recessive to dominant is generated for each time quanta of a bit time The case of an edge immediately before the sample point is excluded The program runs three configurations of the bit timing 1 Large Phase Buffer Large Synchronization Jump Width NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDDTH 4 2 Large Phase Buffer Small Synchronization Jump Width NT 25 SAMPLE 17 RESYCHRONIZATION_JUMP_WIDDTH 1 3 Small Phase Buffer Small Synchronization Jump Width NT 10 SAMPLE 8 RESYCHRONIZATION_JUMP_WIDDTH 1 BOSCH E K8 EIS VHDL Reference CAN User s Manual Revision 2 2 With each configuration of the bit timing the following tests are performed a Hard Synchronization TX DATA Recessive not Transmitter not Receiver b Resychronization TX DATA Recessive Receiver c Resychronization TX DATA Dominant Receiver d Resychronization TX DATA Dominant Transmitter e Resychronization TX DATA Recessive Transmitter f Hard Synchronization TX DATA Dominant Transmitter Note The edges from recessive to dominant on the RECEIVE DATA input which are used for Hard Synchronization and Resynchronization appear with the falling edge of TIME
30. transmitter detects an overload condition and sends an Overload Frame After sending the Overload Frame the transmitter detects 7 consecutive dominant bits before sending the Overload Delimiter The transmit error counter is not changed 26 Dominant bit at last bit of Overload Delimiter Error Passive 8 dominant bits after Overload Flag The recessive bit of Overload Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame After sending the Overload Frame the transmitter detects 8 consecutive dominant bits before sending the Overload Delimiter The transmit error counter is increased by 8 27 Dominant bit at the 2nd bit of Overload Delimiter Error Passive The recessive bit of Overload Delimiter is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 28 Recessive bit at ACK Slot Error Passive The dominant ACK bit is forced to recessive The transmitter detects an ACK error and sends a Passive Error Flag The transmit error counter is not changed because it does not detect a dominant bit while sending its Passive Error Flag 29 2nd bit of Error Delimiter forced dominant Error Passive 64 dominant bits after Passive Error Flag The recessive bit of Error Delimiter is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 After the
31. vhd architecture parallel 16 bit of cpu interface can control vhd entity of can control timing vhd architecture timing of can control configuration sys e vhd configuration of can system COMPARE REFERENCE buggy example of a buggy CAN implementation Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file bad example vhd architecture bad example of can interface buggy vhd architecture buggy of can module configuration buggy vhd configuration of can interface configuration sys b vhd configuration of can system COMPARE REFERENCE tests test programs with trace files Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file test routines vhi procedures used within test programs signal definition vhi constants and signals to control the test program request process vhi process to set reset TRANSMISSION REQUEST tests lt test gt each test program has its own directory Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file lt test gt vpp architecture lt test gt of test program contains configuration cfg test lt test gt vhd generated by make fro
32. 8th bit of Error Delimiter The recessive 8th bit at Error Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Flag 3 2 11 stuff bit Bit Stuffing NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Reception and transmission of messages with dominant and recessive stuff bits within and at the end of each stuffed field followed by a recessive and a dominant bit In the first part of the test the receiver RefCANI receives 11 predefined messages In this part the reserved bits which have normally to be sent dominant are modified to test whether the receiver accepts dominant and recessive reserved bits in all combinations In the second part the transmitter RefCANI transmits 8 predefined messages 3 2 12 stufferr Confinement of Stuff Errors NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Stuff errors both dominant and recessive are generated in each stuffed field of a message and at the end of each stuffed field The program generates 16 stuff errors at different positions in the data frames The program consists of the following test steps 1 Recessive stuff error at stuff bit after the 8th Identifier position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error coun
33. ACE s port map list they are global signals declared in package trace package vhd Inside CAN INTERFACE s architectures the values of certain internal signals or variables are assigned to corresponding BOND OUT signals making that values externally visible see also section 5 1 In case of a difference in that signals the checker will indicate this difference by a report of severity error as a CAN protocol error The functionality of CHECKER is described in section 4 4 1 1 The TRANSMIT DATA output of COMPARE is the TRANSMIT DATA output of IMPLEMENTATION The TRANSMIT DATA output of REFERENCE is only used by the checker and is not visible outside this architecture BOSCH 94 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 The RECEIVE DATA input of COMPARE is connected directely to the RECEIVE DATA input of IMPLEMENTATION The generic parameter RX DELAY is an input delay factor to be multiplied with the implementation model s clock period The RECEIVE DATA input of REFERENCE is delayed in order to compensate the delay time caused by the synchronization of the RECEIVE DATA input to the implementation model s clock The TRANSMISSION REQUEST input of REFERENCE is connected to BOND OUT 0 TXROST This global signal is set by the implementation under test to assure that the RefCAN running in parallel always starts the transmission synchronously to the implementation see also section 4 5 3 Only one instance of CAN INTERFACE in
34. BEHAVIOUR the state of signal TRANSMIT DATA is converted to a dominant level if it is O or a recessive level if it is 1 on the CAN BUS An assertion of severity error checks whether TRANSMIT DATA has a value different from 0 or 1 RECEIVE DATA depends on the state of CAN BUS and on the state of BUS INTERFERENCE If BUS INTERFERENCE is NONE a dominant level on CAN BUS will be read as 0 and a recessive level will be read as 1 If BUS INTERFERENCE is set to BIT ERROR a dominant level on CAN BUS will be read as 1 and a recessive level will be read as 0 With BUS INTERFERENCE set to STUCK AT RECESSIVE RECEIVE DATA will always be 1 With BUS INTERFERENCE set to STUCK AT DOMINANT RECEIVE DATA will always be 0 The generic delay parameters are provided as an option for the simulation of CAN bus systems In the configurations for the simulation of the protocol test programs no configuration of CAN SYSTEM assigns actual parameters to the generic delay parameters of BUS INTERFACE so in all instances they remain at their default values of 0 ns If a particular implementation requires another kind of physical layer architecture BEHAVIOUR may be replaced in the configurations of CAN SYSTEM BOSCH 32 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 44 CAN INTERFACE The entity CAN INTERFACE is designed as a CAN Protocol Controller which is connected to the CAN bus by a
35. BOSCH VHDL Reference CAN User s Manual Revision 2 2 K8 EIS 1999 VHDL Reference CAN User s Manual Revision 2 2 Copyright Notice and Proprietary Information Copyright 1996 1997 1998 1999 Robert Bosch GmbH All rights reserved This software and manual are owned by Robert Bosch GmbH and may be used only as authorized in the license agreement controlling such use No part of this publication may be reproduced transmitted or translated in any form or by any means electronic mechanical manual optical or otherwise without prior written permission of Robert Bosch GmbH or as expressly provided by the license agreement Disclaimer ROBERT BOSCH GMBH MAKES NO WARRANTY OF ANY KIND EXPRESS OR IMPLIED WITH REGARD TO THIS MATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ROBERT BOSCH GMBH RESERVES THE RIGHT TO MAKE CHANGES WITHOUT FURTHER NOTICE TO THE PRODUCTS DESCRIBED HEREIN ROBERT BOSCH GMBH DOES NOT ASSUME ANY LIABILITY ARISING OUT OF THE APPLICATION OR USE OF ANY PRODUCT OR CIRCUIT DESCRIBED HEREIN BOSCH i K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Conventions The following conventions are used in this User s Manual COURIER BOLD Names of entities architectures configurations processes functions types signals and variables courier bold File names shell commands courier bold Should be replaced by a specific
36. CAN 1 Rx RTR Bi RefCAN2 1 _RTR_Bi Re fCANO Rx RTR Bi Re fCAN Rx RTR Bi RefCAN2 J RTR Bi RefCANO 1 IDE Bi RefCAN 1 Rx IDE Bi RefCAN2 IDE Bit RefCANO 1 Rx Reserved RefCAN 1 Rx Reserved RefCAN2 J Reserved 1 Ce e AUC C QO QO QO QO QO O O O O O O gp p A 3a pa Y pa OoOO0oO0coO0 O Gh et ch ct cr CF ctc OO O0o0rnpnm pa pa OOo H ej Hj Hj HH 03H H HR HH AAA 08H dH HH Ce Figure 16 Example of lost arbitration in a simulation s trace file e g test program emlcount BOSCH _ 55 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 In figure 16 RefCANI and the parallely simulated RefCANO the implementation lose arbitration at the 9th Identifier bit In figure 17 RefCANG2 does not send Acknowledge because of a CRC Error therefore RefCANI and RefCANO see an Acknowledge Error RefCANO 1 RefCAN1 1 RefCAN2 1 RefCANO 14 RefCAN1 14 RefCAN2 14 RefCANO 1 RefCAN1 1 RefCAN2 1 Re fCANO Re fCAN Re fCAN2 i RefCANO 1 Rx ACK Slol RefCAN 1 Rx ACK Slot RefCAN K Slot Tx Rqs f CAN2 changed to Ref fCAN 1 Rx ACK Delimiter RefCAN 1 Rx ACK Delimiter RefCAN 1 tive Error Flag Tx Rqs f CAN2 changed to Re fCAN 1 Rx_Active_Error_Fl
37. CAN Model has been used by Robert Bosch GmbH for the verification of ten CAN implementations and by CAN designers of the licensees including most major semiconductor suppliers In this way the compatibility of all existing CAN implementations is guaranteed The Reference CAN model is represented in two versions the realisation in C as distributed to the CAN licensees and its translation in VHDL an option for the CAN licensees While the VHDL simulator of any designer s CAD environment should be compatible with the VHDL version the C version is provided with a specific and custom simulator kernel and is not connected to a specific IC design tool BOSCH 69 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 The continuous spreading of VHDL Very High Speed Hardware Description Language as a standard design language for IC development urged the conversion of the Reference CAN Model from the customized C simulation environment to a VHDL environment Since a considerable amount of work and know how had been invested in the C model of the CAN Protocol Controller and into the verification test programs that had to be taken into account when developing the strategy for the conversion from C into VHDL For the understanding of the extent of the model it is useful to split existing CAN controller implementations in protocol related and application related sections The CAN Protocol Controller is the kernel of each CAN implementation inte
38. DENTIFIER MESSAGE NBYTES MESSAGE DATA 0 8 TRANSMISSION REQUEST 1 to MAXIMUM NUMBER OF CANS The interface signals driven by CAN SYSTEM TRANSMISSION REQUEST STATUS l to MAXIMUM NUMBER OF CANS RECEIVED MESSAGE l to MAXIMUM NUMBER OF CANS FRAME KIND MESSAGE IDENTIFIER KIND MESSAGE IDENTIFIER MESSAGE NBYTES MESSAGE DATA 0 8 These signals elements of the arrays referencing the CAN nodes in CAN_SYSTEM implement the following functionality RESET is the system reset BIT TIMING CONFIGURATION defines the CAN bit time BUS INTERFERENCE can force the RECEIVE DATA output of an instance of BUS INTERFACE to a certain state TRANSMIT MESSAGE defines a message to be transmitted by the labelled CAN node f TRANSMISSION REQUEST is true the labelled CAN node is requested to transmit a message TRANSMISSION REQUEST STATUS shows the processing of a requested transmission RECEIVED MESSAGE is the contents of the last message received by the labelled CAN node The generic parameter MODEL LABEL distinguishes the different instances of CAN INTERFACE in side CAN SYSTEM Valid values for MODEL LABEL are 0 to MAXIMUM NUMBER OF CANS MODEL LABEL 0 is always used for that instance of the implementation that is to be verified by comparing its function with the function of the reference model working in parallel That implemen tation s input is a copy of the input of the compared reference model For detai
39. DLE The bus is now free and the node waits for a recessive to dominant edge on the bus which is interpreted as Start Of Frame The node becomes receiver with setting STATUS to RECEIVING and HARD SYNC ENABLE to 0 The FIELD of the next bit is Identifier and STUFF ENABLE is true be cause Start Of Frame is part of the stuffed area If no dominant bit appears on the bus the node waits for a TRANSMISSION REQUEST to become transmitter Then STATUS is changed to TRANSMITTING The FIELD of the next bit is Start Of Frame STUFF ENABLE becomes true BUS DRIVE is set to dominant because of Start Of Frame and HARD SYNC ENABLE will be set to 0 BOSCH 49 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 STATUS RECEIVING The status RECEIVING is divided in 7 fields Status is RECEIVING case FIELD is when Active Error Flag gt when Passive Error Flag gt when Error Delimiter gt when Overload Flag gt when Overload Delimiter gt when Intermission gt when others gt end case Figure 13 Structure of RECEIVING status STATUS RECEIVING FIELD Active_Error_Flag The receiver sends 6 dominant bits If a bit error occurs during the Active_Error_Flag then a new Active_Error_Flag is sent and the RECEIVE_ERROR_COUNTER is incremented by 8 After the 6th bit the Active Error Flag has finished and BUS DRIVE is set to 1 The receiver monitors the bus and waits for a recessive bit to change STATU
40. EIVE_DATA input of RefCAN2 is forced to recessive The bus state of RefCAN2 is Idle because the RECEIVE DATA input is forced to recessive The transmitter RefCAN1 detects an ACK error and sends a Passive Error Flag During the Passive Error Flag no dominant bit appears on the bus The transmit error counter is not changed After Passive Error Flag the RECEIVE DATA input of RefCANI is forced to dominant for 113 bit times The transmitter detects form errors at every 8th bit and increases its error counter by 8 TEC 247 7 Recessive bit at ACK Slot dominant bit at the 2nd bit of Passive Error Flag RECEIVE DATA input of RefCAN2 is forced to recessive The bus state of RefCAN2 is Idle because the RECEIVE DATA input is forced to recessive The transmitter RefCAN1 detects an ACK error and sends a Passive Error Flag During the Passive Error Flag a dominant bit appears on the bus The transmit error counter is increased by 8 TEC z 255 8 Recessive bit at ACK Slot dominant bit at the 6th bit of Passive Error Flag RECEIVE DATA input of RefCAN2 is forced to recessive The bus state of RefCAN2 is Idle because the RECEIVE DATA input is forced to recessive The transmitter RefCAN1 detects an ACK error and sends a Passive Error Flag During the Passive Error Flag a dominant bit appears on the bus The transmit error counter is increased by 8 TEC z 263 and the transmitter becomes Bus Off 3 2 5 dlc Data Field Length NUMBER OF CANS 2 Bit T
41. ENCE they are provided to control the trace output of the different parts of an implementation s model BOSCH 54 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Tx Rqst Status of CAN1 changed to Tx Rqst Status of CANO changed to Tx Rqst Status of CAN2 changed to RefCAN2 left Reset State RefCANO left Reset State RefCAN1 left Reset State JOorrctr 00o D 4rHUoc Uu nj rj t cf 00 9 X H Node State Field at SamplePt RefCANO 1 Wait For Bus Idle RefCAN 1 1 Wait For Bus e RefCAN2 1 Wait For Bus e Implementation and refCAN are synchronise RefCANO 2 Wait For Bus Idle 01 J Id Id Q n 13802 RefCAN2 11 Wait For Bus Idle 10 Je dE 0 14050 WAIT FOR STATUS FIELD and POSITION reached 14050 4 14050 Start of Test Receive Error Counter counts up and down 4 4 14050 14800 RefCANO Bus I QI dE 0 0 906800 T tifier 906801 1 mu tifier 906802 RefCAN ES tifier 907600 Tx Rqst St CANO changed 907601 Tx Rqgs CAN1 changed 907800 RefCANO can tifier 907801 RefCAN1 Co tifier 907802 RefCAN2 T tifier 908800 RefCANO 10 Rx I tifier 908801 RefCAN1 10 I tifier 908802 RefCAN2 1 I tifier 909800 RefCANO 11 I tifier 909801 RefCAN1 11 Rx I tifier 9 RefCAN2 11 EN tifier RefCANO 1 Rx RTR Bit Ref
42. ETUP of TEST PROGRAM The default value of INITIALIZATION CYCLES is 1 resulting in only one synchronisation edge after the hardware reset but if a higher value is defined in a configuration of the PROTOCOL TESTBENCH a sequence of dominant and recessive bits gives the necessary time for initialization After the last dominant bit all CAN nodes in CAN SYSTEM are expected to have started their CAN bus activities and all nodes are waiting synchronously for a sequence of 11 recessive bits before starting the reception and transmission of frames INIT SETUP adjusts the evaluation time of the process STIMULI of TEST PROGRAM with respect to the CAN bit time BOSCH 65 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 5 1 2 procedure WAIT FOR CAN LABEL MODEL LABEL TYPE STATUS CAN STATUS TYPE FIELD FIELD NAME TYPE POSITION natural WAIT FOR waits until the CAN node specified by CAN LABEL reaches the sample point of a bit POSITION in a CAN frame FIELD while being in a particular STATUS After this sample point WAIT FOR waits for the the end of Phase Buffer Segment 2 synchronizing the test program to the CAN bus If the desired conditions are not met before a limit of MAXIMUM WAIT PERIODS CLOCK PERIOD 1 is reached the simulation is stopped by an assertion of severity failure This limit is implemented to avoid never ending loops The default value of the natural signal MAXIMUM WAIT PERIODS is 2000 defined in signal_definition v
43. Error Flag and increases its error counter by 8 8 Dominant bit at the last bit of Error Delimiter The recessive bit of Error Delimiter is forced to dominant The receiver detects an overload condition and sends an Overload Flag The receive error counter is not changed 9 Dominant bit at the 8th bit after Overload Flag The next 16 bits after Overload Flag are forced to dominant At the 8th and the 16th bit the receiver detects form errors and increases its error counter by 8 10 Dominant bit at the second bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 11 Dominant bit at the 8th bit after Active Error Flag The next 16 bits after Active Error Flag are forced to dominant At the 8th and the 16th bit the receiver detects form errors and increases its error counter by 8 Test of transmitter 1 Dominant bit at CRC Delimiter The recessive bit of CRC Delimiter is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increased by 8 2 Dominant bit at ACK Delimiter The recessive bit of ACK Delimiter is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increas
44. H 61 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 4 2 architecture READ WRITE of CPU The CPU controlling the CAN MODULE inside the architecture EXAMPLE of CAN INTERFACE serves two purposes First CPU translates the inputs BIT TIMING CONFIGURATION TRANSMIT MESSAGE and TRANSMISSION REQUEST ofCAN INTERFACE into write commands interfacing between the protocol test programs and the CAN implementation s model And second CPU monitors the operation of the CAN MODULE and makes its internal function visible at the entity s ports by reading received messages from the RECEIVE BUFFER and by reading the transmit status bits Do Transmit and Tx Pending Event Reaction of CPU Change of BIT TIMING CONFIGURATION CPU writes Bit Timing Configuration into TIMING REGISTER Change of TRANSMIT MESSAGE CPU updates TRANSMIT BUFFER Change of TRANSMISSION REQUEST CPU updates Do Transmit and Tx Pending Edge of RECEIVE INTERRUPT CPU reads RECEIVE BUFFER and updates RECEIVED MESSAGE port signal TRANSMISSION REQUEST STATUS CPU checks Do Transmit and Tx Pending changes to DONE or to TRANSMITTING No Event No operation NOP Table 3 Features of the architecture READ WRITE of CPU The CPU actions in table 3 are listed in order of priority with writing into TIMING REGISTER having the highest and NOP having the lowest priority Each action of CPU is documented by printing a note into the simulation s trace file Thi
45. Identifier the receiver detects a stuff error and sends an Active Error Flag The receive error counter is increased by 1 4 Dominant bit at the 3rd bit of Intermission The recessive 3rd bit of Intermission is forced to dominant The node interprets this as Start of Frame and becomes transmitter 5 Sending Active Error Flags Passive Error Flag until suspend is reached When sending an Active Error Flag the RECEIVE DATA input is forced to recessive The transmitter detects bit errors and increases its error counter with every bit error by 8 until the node is Error Passive After the Passive Error Flag Error Delimiter and Intermission the transmitter sends Suspend Transmission 6 Recessive bit at the 2nd bit of Identifier The dominant 2nd bit of Identifier is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 7 Waiting for Bus Off The RECEIVE DATA input is forced to recessive The transmitter detects bit errors at every Start of Frame bit and sends Passive Error Flags With every error the transmit error counter is increased by 8 If the error counter is gt 255 the node becomes Bus Off BOSCH 20 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 8 Abort transmission The reset transmission request is set to abort the transmission The node waits now for 128 11 consecutive recessive bits 9 Dominant bit at the 9th position of Bus Off r
46. Intermission recessive bit at first bit of Overload and Error Flag The recessive bit of Intermission is forced to dominant The transmitter detects an overload condition and sends an Overload Frame Then the first bit of the Overload Flag is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 During sending an Active Error Flag the RECEIVE DATA input of the transmitter is forced to recessive for 3 bit times The transmitter detects bit errors at every bit and starts Active Error Flags With every bit error the transmit error counter is increased by 8 Then at the beginning of the last Active Error Flag the transmitter becomes Error Passive but it continues sending the Active Error Flag 17 Send 7 messages decrementing TEC to 128 The transmitter sends 7 messages After the successful transmission of each message the transmit error counter is decreased by 1 18 Error Passive transmitter sees Stuff Error during Arbitration at recessive stuff bit No TEC change on arbitration stuff error 19 Send one successful message Node is set back to Error Active 20 Recessive bit at Start of Frame The dominant Start of Frame bit 1s forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 The transmitter is now Error Passive again 21 Recessive bit at Start of Frame Error Passive The domi
47. ME INITIALIZATION CYCLES IT SETUP RX DELAY end for end for end CFG BAUDRATE __ Figure 25 Testbench configuration for test program BAUDRATE simulating architecture EXAMPLE In this test program three NUMBER OF CANS CAN nodes communicate in the CAN SYSTEM one of the nodes made up of the architectures EXAMPLE and REFERENCE simulated in parallel CONFIGURATION SYS E see section 4 2 2 EXAMPLE is granted time for initialisation INITIALIZATION CYCLES after reset EXAMPLE operates with a clock period of 110 ns same as the parallely simulated REFERENCE and EXAMPLE s local CPU The REFERENCE 2 operates with a clock period of 1118 ns REFERENCE 3 with a clock period of 442 ns The CAN node s baud rate prescaler provide a common bit time regardless of the difference in the clock sources BOSCH 76 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 5 3 Adding Test programs The file template vppinthe directory BOSCH CAN ROOT tests template is intended to be used as a template if a particular implementation requires additional test programs architecture TEMPLATE of TEST PROGRAM is 4 include signal definition vhi declaration of additional constants and signals begin include request process vhi STIMULI process variable TIMING BIT TIMING CONFIGURAT declaration of additional variables
48. N Protocol Controller The architectures COMPARE and REFERENCE are fundamental parts of the CAN protocol testbench and should not be modified The architecture IMPLEMENTATION is a proxy for the user s implementation model that is to be verified by the Reference CAN Model node Since IMPLEMENTATION is not part of the Reference CAN Model the configuration CONFIGURATION IMPLEMENTATION currently associates the architecture REFERENCE whenever the IMPLEMENTATION is instantiated The architecture EXAMPLE describes an entire CAN module including CAN Protocol Controller message memory and CPU interface linked together in CONFIGURATION EXAMPLE It is intended as an example how to integrate the user s implementation model into the Reference CAN Model The architecture BAD EXAMPLE describes a buggy CAN Protocol Controller The configuration CONFIGURATION BUGGY links this buggy CAN Protocol Controller into the architecture EXAMPLE resulting in a buggy CAN module The simulation of this buggy module running in parallel to the architecture REFERENCE inside the architecture COMPARE shows how the test programs of the Reference CAN Model detect CAN protocol errors Besides the entity s port signals the protocol check requires additional internal information on internal signals of the architectures of CAN INTERFACE These internal signals cannot be accessed directely Therefore the architectures are provided with a set of global signals BOND OUT of the record
49. NG is scheduled regularly at the end of the Information Processing Time after the Sample Point For each evaluation of the process BIT STREAM PROCESSOR one line of text is written into the trace file This line starts as before with time stamp and MODEL LABEL Then follow the position of the processed bit in the FIELD the STATUS and FIELD at the last Sample Point the RECEIVE DATA at the last Sample Point whether this RECEIVE DATA was a BIT ERROR the transmitted bit and the values of the RECEIVE ERROR COUNTER and TRANSMIT ERROR COUNTER When the CAN module leaves reset state some header lines are printed into the trace file describing the trace signals Some examples of trace output are described in figure 15 figure 16 and figure 17 In the trace package see file trace package vhd the global signal TRACE CONTROL is declared TRACE CONTROL is an array MODEL LABEL TYPE of std ulogic vectors providing each instance of a CAN model with its own 10 bit TRACE CONTROL vector default value 1111111111 In the architecture REFERENCE TRACE CONTROL MODEL LABEL 0 enables the process TRACING to document the function of the process BIT STREAM PROCESSOR by writing to the trace file at each Sample Point By setting TRACE CONTROL MODEL LABELJ 0 to 0 the CAN model with the generic parameter MODEL LABEL is prevented from writing trace output at each Sample Point The other bits of the TRACE CONTROL vector are not used by the architecture REFER
50. NT is decreased by 1 and if it was greater than 127 it will be set to a value between 119 and 127 At that condition the RECEIVE ERROR COUNT is set to 127 in REFERENCE and to 119 in BAD EXAMPLE the nomenclature of the architectures is not intended to favour either value Simulating the component REFERENCE architecture REFERENCE in parallel to the component IMPLEMENTATION configuration CONFIGURATION BUGGY of architecture EXAMPLE inside the architecture COMPARE demonstrates how a Reference CAN Model node adapts itself to the IMPLEMENTATION s RECEIVE ERROR COUNT value when there is a difference of that values caused by a different application of fault confinement rule 8 If there is a difference of the RECEIVE ERROR COUNT values caused by other reasons the Reference CAN Model node will not adapt itself the difference will be regarded as a CAN protocol error BOSCH 63 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 45 TEST PROGRAM For the verification of CAN Protocol Controllers the PROTOCOL TESTBENCR see chapter 4 at page 27 is provided with a set of test programs Each test program is described by a separate architecture test of TEST PROGRAM test stands for the individual program s name it is linked by a configuration of PROTOCOL TESTBENCH see section 5 2 All test architectures have the same structure shown in figure 20 consisting of the three processes STIMULI REQUEST and SYNCHRONIZE REQUEST
51. S to Error Delimiter The first bit of Error Delimiter is recognized in the Active Error Flag so the POSITION of Error Delimiter must be set to 2 If the first bit after the Active Error Flag is monitored as dominant then the RECEIVE ERROR COUNTER is incremented by 8 The receiver accepts up to 7 dominant bits after the Active Error Flag At the 8th consecutive dominant bit following the Active Error Flag and after each sequence of additional eight consecutive dominant bits the RECEIVE ERROR COUNTER is incremented by 8 At each increment of the RECEIVE ERROR COUNTER during the Active Error Flag the error counter value is checked for ERROR PASSIVE STATUS RECEIVING FIELD Passive Error Flag The receiver waits for 6 consecutive bits on the bus dominant or recessive If a bit error and a transition from dominant to recessive or from recessive to dominant is monitored then POSITION is set to 1 The node looks for a dominant bit after the first 6 bits of the Passive Error Flag If this occurred then the RECEIVE ERROR COUNTER in incremented by 8 After the detection of 6 consecutive bits the PASSIVE ERROR FLAG has finished The next recessive bit changes STATUS to Error Delimiter The first bit of Error Delimiter is recognized in the Passive Error Flag so the POSITION of Error Delimiter must be set to 2 The receiver accepts up to 7 dominant bits after the 6 consecutive Passive Error Flag bits At the 8th consecutive dominant bit following t
52. TOCOL TESTBENCH to simulate the test program TEMPLATE see file SBOSCH CAN ROOT tests template cfg template vhd For this template of a test program provided for the development of new test programs the simplest CAN SYSTEM is chosen consisting only of 2 NUMBER OF CANS CAN nodes No implementation model is referenced CONFIGURATION SYS mR see section 4 2 4 this testbench s configuration is focusing on the CAN protocol functions library CAN LIBRARY his configuration defines the following entity architecture pairs ROTOCOL TESTBENCH STRUCTURAL CAN SYSTEM FLEXIBLE only 2 Reference Models CAN INTERFACE REFERENCE It is used with configuration IMPLEMENTATION of CAN INT configuration CFG TEMPLATE of PROTOCOL TESTBENCH is for STRUCTURAL for SYSTEM CAN SYSTEM use configuration CAN LIBRARY CONFIGURATION SYS R generic map NUMBER OF CANS 2 CLOCK PERIOD gt others gt 100 ns RX DELAY gt 0 00 end for for WAVEFORM TEST PROGRAM use entity CAN LIBRARY TEST PROGRAM TEMPLATE generic ma CLOCK PERIOD gt others gt 100 ns INFORMATION PROCESSING TIME Livy INITIALIZATION_CYCLI d INIT SETUP 0 80 RX DELAY gt 0 00 end for
53. TRANSMIT_ERROR_COUNTER during the Active_Error_Flag the counter value is checked for ERROR_PASSIVE and Bus Off STATUS TRANSMITTING FIELD Passive_Error_Flag First the node looks for a dominant bit during the first 6 Passive_Error_Flag bits If an ACK error has occurred before ACK_Slot then the TRANSMIT_ERROR_COUNTER is incremented by 8 Next the transmitter waits for 6 consecutive bits on the bus dominant or recessive If a bit error and a transition from dominant to recessive or from recessive to dominant is monitored then POSITION is set to 1 After the detection of 6 consecutive bits the PASSIVE_ERROR_FLAG has finished The next recessive bit changes the STATUS to Error_Delimiter The first bit of delimiter is recognized in the Passive_Error_Flag so the POSITION of delimiter must be set to 2 The transmitter accepts up to 7 dominant bits after the 6 consecutive Passive_Error_Flag bits At the 8th consecutive dominant bit following the Passive_Error_Flag and after each sequence of additional eight consecutive dominant bits the TRANSMIT_ERROR_COUNTER is incremented by 8 At each increment of the TRANSMIT_ERROR_COUNTER during the Passive_Error_Flag the counter value is checked for Bus Off BOSCH 59 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 STATUS TRANSMITTING FIELD Error Delimiter The transmitter sends 8 recessive bits on the bus At the end of the delimiter FIELD is changed to Intermission If a dominant bit
54. T_DATA_R_STABLE TRANSMIT DATA N l N M E N N KAA SESS AAA N TRANSMIT DATA DELAYED SMLLISSINSI BMS SLL L LASS ww ll l VIII IIIS ANI IIA LSI LL ATS V4fiy t p44 4t 644htttVb4 Vfi thpt4 64t 644tttt Vb4 YLAMSISSSNMISALLS SSS AA TL Z Figure 4 Tolerable phase shifts between compared signals example for TRANSMIT DATA After RESET CHECKER remains passive as long as the CAN bus remains in the recessive state CHECKER is activated when the IUT sampled the first dominant bit after the start of the simulation If it detects a difference between the relevant signals of the IUT and of the Reference CAN Model node an assertion will cause a report of severity error documenting the CAN protocol error In order to compensate for a possible phase difference between the clocks of the IUT and the Reference CAN Model node the signals of the IUT and the Reference CAN Model node are compared not directly but with the help of some intermediate signals so that small phase differences between the signals are tolerated The IUT is required to follow the Reference CAN Model node within the time window defined by signals MIN and MAX This allows phase shifts to be tolerated if the edges of the compared signals lie within this time window see figure 4 The limits for the tolerable phase shift are MAX Time Quanta 2 MIN If an edge appears at TRANSMIT DATA R the transmit data output of the Referenc
55. The Interface Signals link the test program with the CAN nodes located in the architecture FLEXIBLE of CAN SYSTEM Interface Signals TRANSMISSION REQUEST TRANSMISSION REQUEST STATUS SET TRANSMISSION REQUEST RESET TRANSMISSION REQUEST z t tc o O tc A o Lu HOLD_TRANSMISSION_REQUEST START_TRANSMISSION P STIMUL DO_ARBITRATION E P REQUEST SYNCHRONIZE_REQUEST REQUEST WHILE BUSY REQUEST ACCEPTED P A lt test gt Figure 20 Structure of an architecture lt test gt of TEST_PROGRAM The test program is subdivided into three processes REQUEST and SYNCHRONIZE_REQUEST control the TRANSMISSION_REQUEST inputs of all CAN nodes while STIMULI controls the RESET BIT_TIMING_CONFIGURATION and the TRANSMIT_MESSAGE inputs of all CAN nodes in the CAN_SYSTEM as well as the BUS_INTERFERENCE inputs of all BUS_INTERFACE components The TRANSMISSION REQUEST inputs are driven by a separate process because the TRANSMISSION REQUEST input of one particular CAN node depends on the state transitions of the corresponding TRANSMISSION REQUEST STATUS port while the inputs RESET BIT TIMING CONFIGURATION TRANSMIT MESSAGE and BUS INTERFERENCE are driven as required by the flow of the protocol test program The subdivision allows STIMULI to require REQUEST and SYNCHRONIZE REQUEST to set the TRANSMISSION REQUEST inputs of several CAN nodes at the same time and to continue the program withou
56. YNCHRONIZATION JUMP WIDTH BOSCH 40 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 During each bit time there is the possibility to synchronize on a recessive to dominant edge at the RECEIVE DATA input This can be done by a Hard Synchronization or by a Resynchronization Each synchronization resets the SYNC ENABLE flag to guarantee that only one synchronization per bit time is performed Atthe end of a bit time the time quanta counter is reset COUNT 0 TRANSMIT POINT is set and the TRANSMIT DATA output gets the actual value of BUS DRIVE If the time quanta counter equals SAMPLE I the signal SAMPLE POINT is set to 1 and the output signal BUSMON gets the value of RECEIVE DATA Therefore BUSMON shows the sampled input data stream In addition the SYNC ENABLE flag is set true to enable synchronization For details of the VHDL coding see file can interface reference vhd T EET l PHASE ERROR 0 PHASE ERROR gt 0 lengthen PB1 l PHASE_ERROR lt 0 shorten PB2 IISI RECEIVE_DATA VALS Sg I Vj SAI AL ALL AM LAM LL LL ALS SAI SL ALL AM LAM LL LL ALS Www SSS RSS LI LSI P SAMPLE_POINT REO TQ Sample Bit Time TQ Time Quanta PB1 Phase Buffer Segment 1 SyncSeg Synchronization Segment PB2 Phase Buffer Segment 2 PROP Propagation Segment IPT Information Processing Time Figure 7 Bit Timing and Phase Error 4 4 2 3 3 Synchronization During each bi
57. a bit error and sends an Active Error Flag The transmit error counter is increased by 8 The first bit of the Transmitter Error Flag is forced to recessive The transmitter detects a bit error and starts sending an Active Error Flag again The transmit error counter is increased by 8 3 Recessive bit at last bit of Active Error Flag The last bit of an Active Error Flag is forced to recessive The transmitter detects a bit error and starts sending an Active Error Flag again The transmit error counter is increased by 8 BOSCH 7 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 Dominant bit at first bit of Intermission recessive bit at first bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the first bit of this Overload Flag is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 5 Dominant bit at first bit of Intermission recessive bit at last bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the last bit of this Overload Flag is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 6 Dominant bit at first bit of Data Length Code A recessive bit of Data Length Code is forced to dominant The transmitter detects a bit error and sends an Active Error Flag T
58. aCAN SYSTEMmay be associated with architecture COMPARE Which implementation s model CONFIGURATION IMPLEMENTATION CONFIGURATION EXAMPLE or CONFIGURATION BUGGY is compared to REFERENCE is defined by a configuration of PROTOCOL TESTBENCH REFERENCE is always associated with architecture REFERENCE 4 4 1 1 CHECKER CHECKER compares BOND OUT signals and the TRANSMIT DATA and RECEIVED MESSAGE port signals of an implementation under test IUT with the corresponding signals of the Reference CAN Model node simulated in parallel and notifies differences as CAN protocol errors Entity CHECKER is instanciated as a component of architecture COMPARE of CAN INTERFACE Its functionality is implemented in the architecture BEHAVIOUR of CHECKER The elements of the BOND OUT global signal record used by CHECKER are the following BOND OUT MODEL LABEL BUSMON TRANSMIT ERROR COUNTER RECEIVE ERROR COUNTER BUSOFF The MODEL LABEL is 0 for the implementation and in the range of 1 to MAXIMUM NUMBER OF CANS for the Reference CAN Model nodes The global signals are defined in package trace package vhd BUSMON reflects the state of RECEIVE DATA at the last sample point TRANSMIT ERROR COUNTER and RECEIVE ERROR COUNTER monitor the state of the two error counters BUSOFF is 1 when the transmit error counter has reached 256 BOSCH _ 35 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Sf TRANSMIT_DATA_R Z RSZ PERA TRANSMI
59. ag Ref CAN 1 Rx Active Error Flag RefCAN2 Active Error Flag RefCANO Rx Active Error Flag 1 Error Flag E grep repo ee a Erg mp dorm OOOooOoooooooooooo cOOOOoOooOooooo0o00oo0o0o0 3 pa pa pa p3 pa pa pa dj Om OOOO oOo 3 pa pa pa pa Or t oo OO Eooosgnu nb b nue dus Figure 17 Example of CRC Error in a simulation s trace file e g test program crc 4 4 2 6 CAN Specification and Reference CAN Model In case of some error conditions the CAN node s reaction is left open by the actual CAN protocol specification In these cases the C Reference CAN Model sets a standard which is implemented in every existing CAN controller and in this VHDL Reference CAN Model Reception of Data Length Code 8 The receiver regards the received Data Length Code as 8 Reception of dominant bit at last bit of End of Frame Message is valid no error counter is incremented Overload Frame is started Reception of a dominant SRR bit in an Extended Frame SRR should have been send recessive but actual value is ignored same as for Reserved Bits Hard Synchronisation The Hard Synchronisation is enabled not only for Bus Idle state but also for Suspend state and the end of the Intermission State as required for the reception of a Start of Frame Receive E
60. an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 While waiting for the CRC Delimiter some resynchronisations are tested by generating positive and negative phase errors at edges from recessive to dominant Recessive bit at ACK Slot The dominant ACK bit is forced to recessive The receiver detects a bit error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 Dominant bit at last bit of End of Frame 7 dominant bits after Overload Flag The recessive bit of End of Frame is forced to dominant The RECEIVE_DATA input is forced to dominant for another 13 bits The receiver detects an overload condition and sends an Overload Frame After sending the Overload Frame the receiver detects 7 dominant bits before sending the Overload Delimiter The receive error counter is not changed Dominant bit at last bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The receiver starts sending an Overload Flag The receive error counter is not changed Recessive bit at first bit of Overload Flag recessive bit at Active Error Flag increment the REC to 106 The dominant Overload Flag is forced to recessive The receiver detects a bit error and sends an Active Error Flag The receive er
61. anslated verbatim from C to VHDL producing the same CAN message transfer and the same CAN bus errors enabling the automated verification of the VHDL model by the comparison of the simulation s trace files Main issues of the actual design work have been apart from the detailed verification the independency from any VHDL tool s deviations up to now Synopsys VSS and Mentor QuickHDL have been evaluated and the self containment of the models of the CAN Protocol Controller and of the CAN bus giving the possibility to combine them with other VHDL models of periphery and systems The Reference CAN Model supports the circuit development for CAN implementations by providing a verification tool that can be adapted to different design environments Furthermore the application of the Reference CAN Model is not limited to the test of IC implementations its simulation environment with CAN message transfer between several nodes can be expanded with additional processes simulating peripheral hardware to use it as a design tool for the development of CAN based systems BOSCH LA K8 EIS VHDL Reference CAN User s Manual Revision 2 2 5 1 Integrating an Implementation s Model into the Reference CAN Model In the architecture CAN SYSTEM the interface of a CAN node to the physical layer the CAN bus and to the application layer the message memory is the entity CAN INTERFACE In order to integrate the model of an actual CAN component into the Referen
62. are assigned according to the values of DOMINANT COUNTER RECESSIVE COUNTER and STUFF ENABLE The signals STUFF BIT and NEXT IS STUFF are only used for tracing BOSCH 48 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 ERROR STATUS assignments If TRANSMIT ERROR COUNTER and RECEIVE ERROR COUNTER are less than or equal to 127 the node is Error Active and ERROR PASSIVE is false STATUS of CAN Interface Here the actual state of the CAN node is evaluated STATUS isasignal of CAN STATUS TYPE The five states without RESET are described in the next sections STATUS BUS OFF RECOVERY The node waits for 128 occurrences of 11 consecutive recessive bits on the bus with HARD SYNC ENABLE set to 1 The RECEIVE ERROR COUNTER is used to count these 128 occur rences and the POSITION signal is used to count 11 consecutive bits If a dominant bit occurs on the bus then POSITION is reset to 1 If the RECEIVE ERROR COUNTER is equal to 128 then STATUS is changed to IDLE TRANSMIT ERROR COUNTER and RECEIVE ERROR COUNTER are cleared PO SITION is set to 1 STATUS WAIT_FOR_BUS_IDLE This is the first status after RESET The node waits for 11 consecutive recessive bits which are counted with the RECESSIVE COUNTER with HARD SYNC ENABLE set to 1 If the node has monitored these 11 bits on the bus and TRANSMISSION REQUEST is true then STATUS is changed to TRANS MITTING In the other case the status is changed to IDLE STATUS I
63. assive Receiver Error Flag is forced to dominant The receiver detects a bit error and starts sending a Passive Error Flag again The receive error counter is not changed 7 Dominant bit at last bit of Passive Error Flag The last bit of a Passive Error Flag is forced to dominant The receiver detects a bit error and starts sending a Passive Error Flag again The receive error counter is not changed 8 Dominant bit at first bit of Intermission recessive bit at first bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the first bit of this Overload Flag is forced to recessive The receiver detects a bit error and sends a Passive Error Flag The receive error counter is not changed 9 Dominant bit at first bit of Intermission recessive bit at last bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the last bit of this Overload Flag is forced to recessive The receiver detects a bit error and sends a Passive Error Flag The receive error counter is not changed Test of transmitter 1 Recessive bit at Start of Frame The dominant Start of Frame bit 1s forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 2 Recessive bit at reserved bit recessive bit at first bit of Active Error Flag A dominant reserved bit is forced to recessive The transmitter detects
64. at HI edd 54 4 4 2 6 CAN Specification and Reference CAN Model 56 4 4 2 7 Special Features of architecture REFERENCE for Protocol Check 57 BOSCH iii K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 3 architecture IMPLEMENTATION eeeeeeene eene enne noeh nose tane een dee enne eia 58 4AA arch teeture EXAMPLE eeu aterert pete ea uti earth e adest 58 4 4 4 architecture SIMPLE of CAN MODUDLE eene 59 4 4 4 1 1 architecture BASIC of CAN MESSAGE e 60 4 4 4 1 2 architecture PARALLEL 16 BIT of CPU INTERFACE 61 4 4 4 1 3 architecture TIMING of CPU CONTROL 61 4 4 4 2 architecture READ WRITE of CPU eese 62 44 5 architecture BAD EXAMPLE iiie he onset e e Rn eo RECS ERE RIA UAR Se es ded 63 45 TBST BROGRANL x5 uiositsty estes iom ocu tu Dea ie tfe des oun 64 2 3 T qrocess SE INIU Msc vie teoria E a A Mie tuse IR NA causes sed 65 ADI proced re INITIALIZE morie ie eee phus eo ee ede 65 2 5 1 2 procedure WATE FOR ui ee techo aeta pese pee asi 66 4 5 1 3 procedure SEND MESSAGE cese reine ennt ene stanno enne ee en ase 66 4 5 1 4 procedure WRITE TRACE esit legte tota EUH e neris e rote ted 66 4 5 2 process REQUEST wiisasisisjsccesssccacvicasjadersdaina R eogeaacvesndenta sessed EN te IUe a De ERR ed 67 45 3 process SY NCHRONIZE REQUEST vues iesie e RI e e i be TORIA 67 5
65. at last bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the last bit of this Overload Flag is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 18 Dominant bit at first bit of Data Length Code A recessive bit of Data Length Code is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 19 Recessive bit at last bit of Data Length Code A dominant bit of Data Length Code is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 20 Dominant bit at first bit of Data Field A recessive bit of Data Field is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 21 Recessive bit at 8th bit of Data Field A dominant bit of Data Field is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 22 Dominant bit at first bit of CRC Field A recessive bit of CRC Field is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 23 Recessive bit at last bit of CRC Field A dominant bit of CRC Field is forced to recessive The
66. bit at the 8th bit after Overload Flag The next 16 bits after Overload Flag are forced to dominant At the 8th and the 16th bit the transmitter detects form errors and increases its error counter by 8 10 Dominant bit at the 8th bit after Active Error Flag The next 16 bits after Active Error Flag are forced to dominant At the 8th and the 16th bit the transmitter detects form errors and increases its error counter by 8 3 2 9 idle Reset and BusOff Recovery Sequences NUMBER OF CANS 1 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 8 RESYCHRONIZATION _JUMP_WIDTH The reset 11 consecutive recessive bits and Bus Off at least 128 11 consecutive recessive bits recovery sequences are tested by setting dominant bits at interesting positions of that sequences The detection of Start of Frame is checked the behaviour of the error counters is monitored The program consists of the following test steps 1 Dominant bit at the 9th bit of Wait For Bus Idle The recessive 9th bit of Wait For Bus Idle is forced to dominant The Wait For Bus Idle cycle starts again 2 Dominant bit at the 11th bit of Wait For Bus Idle The recessive 11th bit of Wait For Bus Idle is forced to dominant The Wait For Bus Idle cycle starts again 3 Dominant bit at the second bit of Bus Idle field A recessive bit during Bus Idle is forced to dominant The node interprets this as Start of Frame and becomes receiver After the 6th bit of
67. ce CAN Model s simulation environment the CAN SYSTEM the implementation has to be enclosed in a shell that does all implementation specific type conversions of interface signals and that translates the protocol test program s commands For the CAN protocol verification this shell has to be written as architecture IMPLEMENTATION and configuration CONFIGURATION IMPLEMENTATION of entity CAN INTERFACE In the temporary CONFIGURATION IMPLEMENTATION provided with the Reference CAN Model the architecture IMPLEMENTATION is substituted by architecture REFERENCE The architecture EXAMPLE see section 4 4 4 is an example how to build such a shell for a simple standalone CAN module EXAMPLE consists of the CAN module component and of a CPU component The CPU translates the input signals TRANSMIT MESSAGE TRANSMISSION REQUEST and BIT TIMING CONFIGURATION driven by the test program into write accesses writing the data and commands into the appropriate registers of the CAN module At the reception of a message the CPU reads the message from the message memory and updates the port signal RECEIVED MESSAGE The value of RECEIVED MESSAGE is checked in the protocol testbench The reset and the interface signals to the bus interface RECEIVE DATA and TRANSMIT DATA do not need conversion in this example The protocol test programs do not read the output ports of the implementation s model therefore the signal TRANSMISSION REQUEST STATUS can be left unconnected Fo
68. cluding time stamp If FILES 2 write to both files without time stamp If FILES 3 write to both files including time stamp If FILES 4 write to both files including time stamp alternate format with comment marker If FILES 5 write only to PATTERNFILE without time stamp If FILES 6 write only to PATTERNFILE including time stamp If FILES 7 write only to PATTERNFILE including time stamp alternate format with comment marker BOSCH 66 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Accesses to PATTERNFILE are only enabled if USE SECOND FILE l The format of the PATTERNFILE output may have to be adapted to the actual simulator tool The alternate format for the patternfile assumes that the patternfile reading program treats lines starting with a character as a comment For programs that use different labels to mark comments the string it in FILES 4 or FILES 7 has to be adapted 4 5 2 process REQUEST This process is part of every protocol test program It sets and resets the LOCAL_TX_REQUEST inputs of process SYNCHRONIZE REQUEST The process is controlled by the input signal vectors SET TRANSMISSION REQUEST RESET_TRANSMISSION_REQUEST START_TRANSMISSION HOLD TRANSMISSION REQUEST RESET REQUEST from process STIMULI and by the TRANSMISSION REQUEST STATUS ofthe particular CAN node RESET REQUEST is a boolean signal causing REQUEST to reset all TRANSMISSION REQUEST signals while
69. d the InterFrame Space are divided in the fields which are listed above also separated in TRANSMITTING and RECEIVING STATUS BOSCH 47 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 2 4 3 Structure of process BIT STREAM PROCESSOR Figure 12 shows the structure of process BIT STREAM PROCESSOR The parts of this process are described in the following section See file can interface reference vhd for details of the VHDL coding BIT STREAM PROCESSOR if RESET then INITIALIZATION elsif PROCESS BIT event and PROCESS BIT 1 then TRACE assignments STUFF assignments ERROR STATUS assignments case STATUS of CAN Interface when WAIT FOR BUS IDLE gt when IDLE gt when RECEIVING gt when TRANSMITTING gt when BUS OFF RECOVERY gt when others gt end case elsif ADJUST ERROR COUNTERS event and ADJUST ERROR COUNTERS 1 then RECEIVE ERROR COUNTER adjustment assignments end if Figure 12 Structure of the BIT STREAM PROCESSOR process INITIALIZATION Local signals variables and output signals are set to their default values TRACE assignments Some trace signals PREVIOUS XXX are set before the source signals are changed MESSAGE OK is set to false Its only true during the reception of the last bit of End of Frame CRC OK is set to false It can only be true during the reception of the recessive CRC Delimiter STUFF assignments The stuff variables STUFF BIT and STUFF CONDITION
70. e if you have an installation of the Mentor Graphics ModelSim Simulator proceed with the following commands cd BOSCH CAN ROOT simulate genmake MG ModelSim The shell script genmake will generate the Makefile and setup files for the specified simulator in the Bosch CAN simulate directory It is used by make to analyse the complete model In addition to the Makefile you will find files called Depends in the subdirectories reference implementation example buggy tests and tests They list the dependencies of the files in these directories and are included into the Makefile You are now ready to run the simulations If you have other VHDL Simulators than Synopsys VSS Mentor QuickHDL or Mentor ModelSim you can adapt the script genmake to your simulation environment or you can modify the files Makefile lt tool gt and Depends lt tool gt which are distributed with this model Additionally you have to provide a setup file for your simulator like synopsys vss setup quickhdl ini or modelsim ini If you want to adapt genmake to another VHDL simulator proceed the following way Open the genmake file and copy the case statement for one of the supported simulators and modify it to fit your simulator e Adapt the functions which translate the names of the compiled files to generate the names following the rules used by your simulator e Adapt the command line entries used by make to start compilation and simulation Setth
71. e 6 Process flow of BIT TIMING The process is sensitive to signals RESET TIME QUANTA CLOCK and the signals of BIT TIMING CONFIGURATION Whenever one of these signals has an event the process is evaluated When RESET is active TRANSMIT DATA is set to l recessive and SAMPLE POINT is set to 0 inactive In addition some local variables are set to their default values After RESET and whenever one of the signals of BIT TIMING CONFIGURATION has an event the quasi constants for Phase Buffer Segment 2 PHASE BUFFER SEGMENT 2 sample point SAMPLE SAMPLE I and the number of time quanta in a bit time NTQ NTQ I are calculated SAMPLE I and NTOQ I are used for temporary storage during synchronization On each rising edge of TIME QUANTA CLOCK the following actions are performed The time quanta counter is incremented The difference DIFF of the actual value of the time quanta counter COUNT and the sample point SAMPLE I is calculated This variable is used when resychronizing to determine whether TRANSMIT POINT should be set or not Signals SAMPLE POINT and TRANSMIT POINT are reset one time quanta after they have gone active The PHASE ERROR is calculated Figure 7 shows the relation between bit timing and phase error The number of time quanta DELTA by which Phase Buffer Segment 1 is lengthened respectively Phase Buffer Segment 2 is shortened is calculated as the minimum of the actual PHASE ERROR and the value of RES
72. e CAN Model node the TRANSMIT DATA R STABLE signal is set to false for MIN MAX After this time it returns to true If an edge appears at TRANSMIT DATA I the transmit data output of the IUT the edge of signal TRANSMIT DATA I DELAYED is generated from TRANSMIT DATA I by delaying it for IMINI CHECKER compares the Reference CAN Model node signals with the delayed signals of the IUT while the Reference CAN Model node signals are stable In the example of figure 4 TRANSMIT DATA R is compared with TRANSMIT DATA I DELAYED while TRANSMIT DATA R STABLE is true outside the shaded area If the phase shift between the edges is so small that the edges of the delayed signals lie within the shaded areas the signals of the IUT and of the Reference CAN Model node will be regarded as identical BOSCH _ 36 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 In Case 1 the transmit data output TRANSMIT DATA Iofthe IUT changes after the transmit data output TRANSMIT DATA R of the Reference CAN Model node In Case 2 the transmit data output TRANSMIT DATA I of the IUT changes before the transmit data output TRANSMIT DATA R of the Reference CAN Model node In both cases the phase shift can be tolerated because the generated signal TRANSMIT DATA I DELAYED lies inside the shaded area If the phase difference of the edges of the compared signals is greater than IMINI an error in the implementation is assumed An assertion report shows which signal causes
73. e COMPARE while optional additional Reference CAN Model nodes provide CAN communication to the implementation All test programs described in section 3 2 use this configuration but with different numbers of CAN nodes NUMBER OF CAN NODES 1 btl idle txarb NUMBER OF CAN NODES 2 biterror crc dlc emlcount extd id formerr overload stuff bit stufferr NUMBER OF CAN NODES 3 baudrate The architectures and configurations of CAN INTERFACE which are used here are described in section 4 4 architecture COMPARE in section 4 4 2 architecture REFERENCE and in section 4 4 3 configuration IMPLEMENTATION 4 2 2 configuration SYS E of CAN SYSTEM This configuration is the same as SYS I with only one exception Instead of an instance of CONFIGURATION IMPLEMENTATION of architecture REFERENCE an instance of configuration CONFIGURATION EXAMPLE of architecture EXAMPLE is running in parallel with a Reference CAN Model node inside component CHECK1 architecture COMPARE The configuration CONFIGURATION EXAMPLE ofarchitecture EXAMPLE of CAN INTERFACE which is used here is described in section 4 4 4 4 23 configuration SYS B of CAN SYSTEM This configuration is the same as SYS E with only one exception Instead of an instance of configuration CONFIGURATION EXAMPLE of architecture EXAMPLE an instance of configuration CONFIGURATION BUGGY of architecture EXAMPLE is running in parallel with a Reference CAN Model node inside component CHECK1
74. e EXAMPLE of CAN INTERFACE BOSCH _ 58 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 EXAMPLE is a structural architecture consisting of the components CAN MODEL entity CAN MODULE and CPU MODEL entity CPU In the configuration CONFIGURATION EXAMPLE the component CPU MODEL is associated with architecture READ WRITE the component CAN MODEL is associated with architecture SIMPLE SIMPLE is intended as a prototype for an implementation s model to be verified 4 4 4 1 architecture SIMPLE of CAN MODULE TRANSMIT DATA A RECEIVE_DATA E CAN_MODULE P SYNCHRONIZE __ RECEIVED_DATA SYNCHRONIZED_DATA E CAN_INTERFACE MODEL_LABEL generic A REFERENCE TRANSMIT_ TRANSMISSION BIT_TIMING MESSAGE REQUEST CONFIGURATION E CAN_MESSAGE E CAN_CONTROL A TIMING Internal Control Signals E CPU INTERFACE A PARALLEL 16 BIT SIMPLE A RECEIVE_INTERRUPT TRANSMISSION REQUEST_STATUS Control Sognals INFORMATION PROCESSING_TIME CPU_BUS Figure 19 architecture SIMPLE of CAN_MODULE BOSCH _ 59 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 This is a structural architecture of a CAN module with a basic message memory It can be used as a template showing how a CAN module implementation should look like to be simulated together with the Reference CAN Model node in the CAN protocol testbench In the configuration CONFIGURATION EXAMPLE the component CAN PROTOCOL CONTROLLER i
75. e Overload Delimiter The transmit error counter is not changed Dominant bit at last bit of Overload Delimiter 8 dominant bits after Overload Flag The recessive bit of Overload Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame After sending the Overload Frame the transmitter detects 8 consecutive dominant bits before sending the Overload Delimiter The transmit error counter is increased by 8 Dominant bit at the 2nd bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Dominant bit at the 2nd bit of Error Delimiter The recessive bit of Error Delimiter is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 BOSCH 14 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 15 Recessive bit at ACK Slot 8 4 dominant bits after Error Flag The dominant ACK bit is forced to recessive The transmitter detects an ACK error and sends an Active Error Flag The transmit error counter is increased by 8 After the Error Flag the RECEIVE DATA input is forced to dominant for another 32 bits After each sequence of additional eight consecutive dominant bits the transmitter detects a form error and increases the error counter by 8 16 Dominant bit at 2nd bit of
76. e path for your simulator s CAN LIBRARY to BOSCH CAN ROOT objects e Adda setup file for the compiler and the simulator to BOSCH CAN ROOT simulate e Adda simulation control file to SBOSCH CAN ROOT simulate To compile the model please change into directory BOSCH CAN ROOT simulate and type make all This will cause the VHDL analyzer to compile the source code of the model using the information from the files generated by genmake The files of compiled model can be found in the directory BOSCH CAN ROOT objects BOSCH EN K8 EIS VHDL Reference CAN User s Manual Revision 2 2 3 1 Starting the Simulation Change to the directory BOSCH CAN ROOT simulate The simulation is started by typing make with a specific target The target defines the desired test program s to be simulated and the name of the CAN Protocol Controller configuration to be verified The Makefile supports three configuration names implementation example and buggy The following functions can be performed by make make clean delete all binaries generated by previous runs of the VHDL analyzer make all analyze the complete model make test run the test program specified by test linked with implementation make test e run the test program specified by lt test gt linked with example make test b run the test program specified by lt test gt linked with buggy make traces run the complete set of tests linked with implementation make traces e ru
77. ecovery sequence The recessive 9th bit of Bus Off recovery is forced to dominant The recovery sequence starts again 10 Dominant bit at the 11th position of Bus Off recovery sequence The recessive 11th bit of Bus Off recovery is forced to dominant The recovery sequence starts again 11 Dominant bit at the first position of Bus Off recovery sequence The recessive Ist bit of Bus Off recovery is forced to dominant The recovery sequence starts again The recovery counter is unchanged 12 Dominant bit at the 10 126 11 position of Bus Off recovery The recessive bit of Bus Off recovery is forced to dominant The recovery sequence starts again The recovery counter is unchanged After the next 11 recessive bits the node becomes Bus Idle and Error Active 13 Dominant bit at the 12th position of Bus Idle A recessive 12th bit during Bus Idle is forced to dominant The node interprets this as Start of Frame and becomes receiver After the 6th bit of Identifier the receiver detects a stuff error and sends an Active Error Flag The receive error counter is increased by 1 3 2 10 overload Overload Confinement NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 For receivers and transmitters dominant bits are generated at each position of Intermission at the end of Error Delimiter and at the last bit of a receiver s End of Frame The program consists of the fo
78. ed by 8 3 Dominant bit at the first bit of End of Frame The recessive bit of End of Frame is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increased by 8 4 Dominant bit at the last bit of End of Frame The recessive bit of End of Frame is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increased by 8 5 Dominant bit at the last bit of Error Delimiter The recessive bit of Error Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame The transmit error counter is not changed 6 Dominant bit at the last bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame The transmit error counter is not changed 7 Dominant bit at the second bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increased by 8 8 Dominant bit at the second bit of Error Delimiter The recessive bit of Error Delimiter is forced to dominant The transmitter detects a form error and sends an Active Error Flag The transmit error counter is increased by 8 BOSCH 19 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 9 Dominant
79. eive error counter is incremented to 135 One Successful transmission then Bit Error at dominant Identifier bit Transmit error counter is decremented to 127 then Passive Error Flag A hardware reset is performed both error counters are reset to 0 7 8 9 10 11 12 13 14 Recessive bit at Start of Frame The dominant Start of Frame bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Dominant bit at ACK Delimiter The recessive ACK Delimiter bit is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Dominant bit at the first bit of End of Frame The recessive bit of End of Frame is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Dominant bit at the last bit of End of Frame The recessive bit of End of Frame is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Dominant bit at last bit of Error Delimiter 7 dominant bits after Overload Flag The last recessive bit of Error Delimiter is forced to dominant The transmitter detects an overload condition and sends an Overload Frame After sending the Overload Frame the transmitter detects 7 consecutive dominant bits before sending th
80. entity of checker checker beh vhd architecture behaviour of checker internal trace vhd entity of internal trace component instantiated within architecture reference of can interface internal trace dummy vhd architecture dummy of internal trace default implementation an user defined implementation should be placed here Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file configuration implementation vhd configuration of can interface now REFERENCE configuration sys i vhd configuration of can system COMPARE REFERENCE example example of a CAN implementation Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file message buffer vhd package with definitions used by architecture read write example vhd architecture example of can interface configuration example vhd configuration of can interface can module vhd entity of can module simple vhd architecture simple of can module cpu vhd entity of cpu read write vhd architecture read write of cpu can message vhd entity of can message basic vhd architecture basic of can message cpu interface vhd entity of cpu interface BOSCH 81 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 parallel 16 bit
81. es the model structure and the functionality implemented in the architectures used in the components of the model The testbench PROTOCOL TESTBENCRH shown in figure 1 can be configured to run the different test programs for different CAN models by assigning dedicated architectures and configurations to the components WAVEFORM entity TEST PROGRAM architecture lt test gt and SYSTEM entity CAN SYSTEM architecture FLEXIBLE The components are interconnected by a set of Interface Signals as described in section 4 1 E PROTOCOL TESTBENCH EzCAN SYSTEM CAN BUS Node 1 Node 2 Node 3 Node n optional optional optional COMPARE REFCAN REFCAN REFCAN A FLEXIBLE Interface Signals E TEST_PROGRAM A lt test gt A STRUCTURAL Figure 1 architecture STRUCTURAL of PROTOCOL_TESTBENCH The test programs control the simulation by driving the inputs and strobing the outputs of CAN_SYSTEM Each test program is represented by one dedicated architecture of TEST_PROGRAM and by three dedicated configurations of PROTOCOL_TESTBENCH one configuration for each of the three CAN implementation models CONFIGURATION_IMPLEMENTATION CONFIGURATION_EXAMPLE and CONFIGURATION BUGGY that are provided with the Reference CAN Model The configurations are described in subsections 4 2 1 and 4 2 2 BOSCH 97 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 To check special features of an user defined implementation
82. figuration define the timing of the instantiated components For each instance of CAN_INTERFACE there is one instance of BUS_INTERFACE component DRIVER and one element of the array of interface signals In the architecture FLEXIBLE CAN SYSTEM contains at least one instance of CAN INTERFACE component CHECK1 and a flexible number of additional instances of CAN_INTERFACE component REFERENCE MODEL The actual number of nodes connected to the CAN bus is determined by the generic parameter NUMBER_OF_CAN_NODES of CAN_SYSTEM n NUMBER OF CAN NODES 1 This generic parameter is defined by a configuration of PROTOCOL TESTBENCH BOSCH _ 30 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 The following architectures are available for CAN INTERFACE COMPARE REFERENCE EXAMPLE and BAD EXAMPLE Which CAN model architecture or configuration is associated with component CHECK1 or with the components REFERENCE MODET is defined by a configuration of CAN SYSTEM Only one architecture is available for BUS INTERFACE BEHAVIOUR see section 4 3 For other applications beyond the CAN protocol verification additional CAN SYSTEM architectures and configurations can be defined 4 2 1 configuration SYS I1 of CAN SYSTEM This configuration is designed to simulate an implementation s model configuration IMPLEMENTATION together with a Reference CAN Model node architecture REFERENCE running in parallel inside component CHECK1 architectur
83. g a dominant bit Hard Synchronization can only occur when PHASE ERROR 0 The generation of TRANSMIT POINT is done only if the detected edge lies Information Processing Time after the sample point see figure 7 BOSCH 42 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 if HARD SYNC ENABLE 1 then Transmitter Synchronize only if edge after sample point if BUS DRIVE 1 or COUNT gt SAMPLE I then COUNT 1 end if Generation of TRANSMIT_POINT only if edge lies Information Processing Time after sample point if DIFF gt BIT TIMING CONFIGURATION INFORMATION PROCESSING TIME then TRANSMIT POINT lt true TX DATA lt BUS DRIVE end if Figure 9 Hard Synchronization on recessive to dominant edge Resynchronization When a reception or transmission is in progress there is the possibility to resynchronize on recessive to dominant edges on the CAN bus There are two cases for Resynchronization depending if the node is receiver or transmitter Node is Receiver If the node is receiver there will be Resynchronization on each recessive to dominant edge provided the value of BUSMON is 1 If the edge lies between Synchronisation Segment and sample point PHASE ERROR gt 0 the Phase Buffer Segment 1 is lengthened by a number of time quanta less or equal the resynchronization jump width This is done by shifting the sample point SAMPLE I and the end of bit time NTQ_I by DELTA time quanta
84. g until transmitter is Error Passive RECEIVE DATA input of RefCAN2 is forced to recessive During sending an Active Error Flag the RECEIVE DATA input of the transmitter is forced to recessive for 14 bit times The transmitter detects bit errors at every bit and starts Active Error Flags BOSCH 10 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 With every bit error the transmit error counter is increased by 8 Then the last Active Error Flag is sent and the transmitter becomes Error Passive TEN 120 128 but it continues sending the Active Error Flag 3 Recessive bit at ACK Slot no dominant bit during Passive Error Flag RECEIVE DATA input of RefCAN2 is forced to recessive The bus state of RefCAN2 is idle because the RECEIVE DATA input is forced to recessive The transmitter RefCAN1 detects an ACK error and sends a Passive Error Flag During the Passive Error Flag no dominant bit appears on the bus The transmit error counter is not changed 4 Transmitting a frame successful transmitter is Error Active The transmitter transmits a frame without errors The transmit error counter is decreased by 1 TEC 127 5 Recessive bit at 2nd bit of Identifier The dominant bit of Identifier is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Transmitter is Error Passive 6 Recessive bit at ACK Slot dominant bits after Passive Error Flag REC
85. he Passive Error Flag and after each sequence of additional eight consecutive dominant bits the RECEIVE ERROR COUNTER is incremented by 8 BOSCH _ 50 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 STATUS RECEIVING FIELD Error Delimiter The receiver sends 8 recessive bits on the bus At the end of the delimiter FIELD is changed to Intermission If a dominant bit occurs during the delimiter bits 2 7 then the receiver detects a form error and sends an Error Flag active or passive The RECEIVE ERROR COUNTER is incremented by 1 If a dominant bit is monitored at the last delimiter bit then the receiver detects an overload condition and sends an Overload Flag The first bit of the Error Delimiter is always recessive because it is necessary to detect the end of an Error Flag and to change the FIELD to Error Delimiter STATUS RECEIVING FIELD Overload Flag The Overload Flag has the same form like the Active Error Flag The error actions and conditions during the flag are almost identical The only difference is that a dominant bit at the first bit after the Overload Flag does not change the RECEIVE ERROR COUNTER STATUS RECEIVING FIELD Overload_Delimiter The Overload Delimiter has the same form as the Error Delimiter The error actions and conditions during the delimiter are identical STATUS RECEIVING FIELD Intermission A dominant bit during the first or the second bit of Intermission is interpreted as overload c
86. he transmit error counter is increased by 8 7 Recessive bit at last bit of Data Length Code A dominant bit of Data Length Code is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 8 Dominant bit at first bit of Data Field A recessive bit of Data Field is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 9 Recessive bit at 8th bit of Data Field A dominant bit of Data Field is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 10 Dominant bit at first bit of CRC Field A recessive bit of CRC Field is forced to dominant The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 11 Recessive bit at last bit of CRC Field A dominant bit of CRC Field is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 12 Create Active Error Flags until transmitter is Error Passive When sending an Active Error Flag the RECEIVE DATA input of the transmitter is forced to recessive for 3 bit times The transmitter detects bit errors at every bit and starts Active Error Flags With every bit error the transmit error counter is increased by 8 Then the last Active Error Flag
87. hi the value may be changed in the test program 4 5 1 3 procedure SEND MESSAGE CAN LABEL MODEL LABEL TYPE MESSAGE FRAME TYPE COMPLETION CONDITION COMPLETION CONDITION TYPE SEND MESSAGE assigns MESSAGE to the TRANSMIT MESSAGE input of the CAN node specified by CAN LABEL and triggers the REQUEST process to set the transmission request for the labelled CAN Then the procedure or the process REQUEST see section 4 5 2 waits for the specified COMPLETION CONDITION There are four COMPLETION CONDITIONS REQUESTED SEND MESSAGE just requests a transmission STARTED SEND MESSAGE waits until the requested transmission has started on the CAN bus SUCCEEDED OR ERROR SEND MESSAGE waits until the requested transmission has completed or is interrupted by an error frame SUCCEDED SEND MESSAGE waits until the requested transmission has completed 4 5 1 4 procedure WRITE TRACE WRITE TRACE called with a string parameter writes the string into the simulation s trace file An optional second parameter FILES default natural value 3 controls whether the same string is copied into the pattern file see section 5 4 and the string s print format see file trace package vhd If written to the TRACEFILE the string may preceded by a time stamp default if written to the PATTERNFILE it may preceded by a time stamp or a comment marker If FILES 0 write only to TRACEFILE without time stamp If FILES 1 write only to TRACEFILE in
88. ication by means of a High Level Language reference environment Due to the variety of CAN controller implementations see figure 22 at page 70 the reference must be limited to the modelling of the protocol itself leaving complete freedom to the application specific part of the component The Reference CAN Model environment consists of the golden CAN protocol model and a testbench consisting of test programs and a simulator kernel In the testbench the model of a CAN controller under development can be compared with the concurrently simulated reference model while the test program and other instances of the reference model provide CAN messages For the development of the first CAN controller implementation the only reference was the CAN protocol specification document Therefore a set of test programs had to be developed to simulate all relevant state transitions of CAN message transfer The protocol consistency of the design was ensured by manually checking the simulation results line for line with the protocol specification For the following design the existing set of test programs was adapted to a different CPU interface and to a different message buffer structure Checking of simulation results was partly automated by checking with the simulation results of the first design The disadvantage of that method is that it is closely linked to the structure of the CAN implementation and to the simulation tool In view of time and cost to be i
89. iming CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Reception and transmission of messages with all possible 0 15 Data Length Codes as Data and as Remote Frames In the first part of the test the receiver RefCANI receives all 32 messages In the second part the transmitter RefCAN1 transmits all 32 messages BOSCH 11 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 3 2 6 emlcount Function of Error Management Logic Counters and States NUMBER_OF_CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NTQ 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 2 Receive and transmit error counters are incremented and decremented around the Error Warning Limit the Error Passive Limit and the Bus Off Limit The fault confinement in case of stuck at dominant after sending an Error Flag is tested The program consists of the following test steps Test of receiver 1 2 3 4 5 6 7 Stuff error at stuff bit after 4th bit of Identifier A recessive stuff bit is forced to dominant The receiver detects a stuff error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 Dominant bit at CRC Delimiter some resynchronisations The recessive CRC Delimiter bit is forced to dominant The receiver detects a form error and sends
90. inant standard frame Recessive stuff bit before IDE bit after IDE is recessive 5 IDE dominant standard frame Recessive stuff bit after IDE 6 IDE recessive extended frame Dominant stuff bit after IDE 7 IDE recessive extended frame Dominant stuff bit before IDE bit after IDE is dominant 8 IDE recessive extended frame Dominant stuff bit before IDE bit after IDE is recessive 9 IDE recessive extended frame Illegal dominant SRR bit recessive stuff bit before IDE bit after IDE is dominant 10 IDE recessive extended frame Illegal dominant SRR bit recessive stuff bit before IDE bit after IDE is recessive Transmitter test of stuff bit combinations at IDE 1 IDE dominant standard frame Dominant stuff bit before IDE bit after IDE is dominant 2 IDE dominant standard frame Recessive stuff bit before IDE bit after IDE is dominant 3 IDE dominant standard frame Recessive stuff bit after IDE 4 IDE recessive extended frame Dominant stuff bit after IDE 5 IDE recessive extended frame Dominant stuff bit before IDE bit after IDE is dominant 6 IDE recessive extended frame Dominant stuff bit before IDE bit after IDE is recessive Transmitter test of losing arbitration before at and after IDE 1 IDE dominant standard frame Lost arbitration at RTR standard data frame BOSCH 17 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 2 IDE dominant standard frame Lost arbitra
91. ion and simulation of the new test programs targets have to be defined in the Makefile BOSCH 78 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 5 4 Generating Test Vectors During a simulation the Reference CAN Model writes text into a trace file to document the operation of the test program This text is written by different processes most is written by process TRACING in architecture REFERENCE of CAN INTERFACE see section 4 4 2 and by the processes STIMULI and REQUEST in the architectures of TEST PROGRAM see section 4 5 To enable the access of all processes to the same trace file the package TRACE PACKAGE globally defines the file TRACEFILE to trace This package is used by package DEFINITIONS TRACE PACKAGE is also to be used by all architectures of an implementation s model that are supposed to write to the same trace file see file BOSCH CAN ROOT reference trace package vhd In the same package PATTERNFILE has been defined to pattern Typical applications of this PATTERNFILE would be a process in architecture IMPLEMENTATION writing test vectors for the device s pins to be used for hardware testing or a process inside the architecture of the device writing test vectors to compare the functions of two architectures of the same sub module s entity behavioural description synthesized netlist Most vector reading tools tolerate comment lines in the vector file so comments should be inserted to identify significant
92. is sent and the transmitter becomes Error Passive but it continues sending the Active Error Flag 13 Recessive bit at Start of Frame The dominant Start of Frame bit is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 14 Recessive bit at reserved bit dominant bit at first bit of Passive Error Flag A dominant reserved bit is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 The first bit of the passive Transmitter Error Flag is forced to dominant The transmitter detects a bit error and starts sending a Passive Error Flag again The transmit error counter is not changed 15 Dominant bit at last bit of Passive Error Flag The last bit of a Passive Error Flag is forced to dominant The transmitter detects a bit error and starts sending a Passive Error Flag again The receive error counter is not changed BOSCH 8 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 16 Dominant bit at first bit of Intermission recessive bit at first bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the first bit of this Overload Flag is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 17 Dominant bit at first bit of Intermission recessive bit
93. is different to a RTR stuff error in a standard frame Next the arbitration and the possible errors in the arbitration field are tested The transmitter lost the arbitration when the bit that is monitored is dominant BUSMON 0 and is different to the bit value that is sent BIT_ERROR true Then the ACK error and the bit errors outside the arbitration field are tested BOSCH _ 53 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 2 5 Output to the Trace File The operation of the test program and of the CAN modules is documented by writing text into the simulation s trace file This architecture REFERENCE incorporates three trace processes TRACING REQUEST STATUS and RECEIVE MESSAGE REQUEST STATUS is triggered by each change of TX REQUEST STATUS the internal name of the output TRANSMISSION REQUEST STATUS When TRANSMISSION REQUEST STATUS changes a line is written into the trace file containing a time stamp the MODEL LABEL to identify the source of the trace message and the new state of TRANSMISSION REQUEST STATUS RECEIVE MESSAGE is triggered by each reception of an error free CAN message The received message is written into the trace file together with time stamp and MODEL LABEL The note written into the trace file starts with the information whether a Data or a Remote a Standard or an Extended Frame is received Then follow the Identifier the Data Length Code and if actually received the Data Bytes TRACI
94. it In the second part the actual bit is a stuff bit POSITION is incremented and FIELD is updated for the next bit If a stuff error happened an error frame is sent BOSCH 54 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 STATUS TRANSMITTING The status TRANSMITTING is divided in 8 fields Status is TRANSMITTING case FIELD is when Active Error Flag gt when Passive Error Flag gt when Error Delimiter gt when Overload Flag gt when Overload Delimiter gt when Intermission gt when Suspend_Transmission gt when others gt end case Figure 14 Structure of TRANSMITTING status STATUS TRANSMITTING FIELD Active_Error_Flag The transmitter sends 6 dominant bits If a bit error occurs during the Active_Error_Flag then a new Active_Error_Flag is sent and the TRANSMIT_ERROR_COUNTER is incremented by 8 After the 6th bit the Active_Error_Flag has finished and BUS_DRIVE is set to 1 The transmitter monitors the bus and waits for a recessive bit to change the STATUS to Error_Delimiter The first bit of delimiter is recognized in the Active_Error_Flag so the POSITION of delimiter must be set to 2 The transmitter accepts up to 7 dominant bits after the Active_Error_Flag At the 8th consecutive dominant bit following the Active_Error_Flag and after each sequence of additional eight consecutive dominant bits the TRANSMIT_ERROR_COUNTER is incremented by 8 At each increment of the
95. it of Overload Delimiter is forced to dominant The receiver detects a form error and sends a Passive Error Flag The receive error counter is increased by 1 and its now equal to 136 Then the next 16 bit after the Error Flag are forced to dominant The receiver continues sending Passive Error Flag After each sequence of eight consecutive dominant bits normally the receive error counter is increased by eight however the counter is equal to 136 and not increased 12 Receive correct frame REC 119 127 The receiver waits for the last bit of Intermission and receives a new frame 13 Wait until End of Frame node Error Active again After the successful reception the receive error counter is decremented The receiver is now Error Active 14 Receive correct frame REC REC 1 After the successful reception the receive error counter is decreased by 1 15 Dominant bit at the first bit of Intermission recessive bit at the first bit of Overload Flag and Error Flag The recessive bit of Intermission is forced to dominant The receiver detects an overload condition and sends an Overload Flag Then the first bit of Overload Flag is forced to recessive The receiver detects a bit error and sends an Error Flag The receive error counter is increased by 8 Depending on the value of the REC after finishing Error Passive the actual REC value is above 127 or below 128 Nevertheless an Active Error Flag is sent The first bit of the Active Error Flag
96. layer are the transferred messages consisting of identifier data length code and data bytes without CRC code or stuff bits The acceptance filtering based upon the identifier is done by the application layer The reference model s testbench and test programs are designed to test exclusively the implementation s protocol controller independent of the other functions of the implementation This is done by comparing the function of the implementation s protocol controller with the function of the reference controller during the simulation of CAN message transfer and CAN bus errors Since the CPU interface and the application layer are not defined by the CAN protocol specification an interface is needed between the test programs of the Reference CAN Model and the models of the implementations In the C version that interface is provided by the functions called by the test programs for the initialisation of the models and for the start of the transmission of a CAN message When these functions are adapted to the specific implementation the test programs themselves calling these functions remain unchanged regardless of the type of the implementation Other implementation specific parts of the C version are the functions called for the CAN protocol check process monitoring the implementation s CAN functions and the CAN bus process connecting the implementation to the CAN bus These functions have to be adapted if the signal names for the CAN in
97. lem you will see the following messages on the screen vhdlsim nc i BOSCH CAN ROOT simulate synopsys sim inc CAN LIBRARY cfg baudrate VSS GATE MODEL sim gs for gate level simulation Set stop on FAILURE Start simulation 955680 NS Assertion NOTE at 955680 NS in design unit CHECKER BEHAVIOUR from process PROTOCOL TESTBENCH SYSTEM CHECK1 PROTOCOL CHECK COMPARE RX MESSAGE Received Message checked ok BOSCH sae K8 EIS VHDL Reference CAN User s Manual Revision 2 2 1447710 NS Assertion NOTE at 1447710 NS in design unit CHECKER BEHAVIOUR from process PROTOCOL TESTBENCH SYSTEM CHECK1 PROTOCOL CHECK COMPARE RX MESSAGE Received Message checked ok 3285128 NS Assertion FAILURE at 3285128 NS in design unit TEST PROGRAM BAUDRATE from process PROTOCOL TESTBENCH WAVEFORM STIMULI End of Test Program reached Stop Simulation Quit simulator mv f trace BOSCH CAN ROOT tests baudrate baudrate trace if s pattern then mv f pattern BOSCH CAN ROOT tests baudrate fi The last statement of the test program is an assertion with a certain FAILURE to terminate the simulation because this 1s the only way to stop a simulation that was not started with an explicit run time The user s implementation model which is used here is a copy of the CAN reference model 3 1 2 Simulating the Example of an Implementation The example of an implementation was designed to show the user of this VHDL Reference
98. llowing test steps Test of receiver 1 Dominant bit at 7th bit of End of Frame 8th bit of Overload Delimiter 1st bit of Intermission 2nd bit of Intermission In a test loop the bits described above are forced to dominant At each dominant bit the receiver de tects an overload condition and sends an Overload Flag 2 Dominant bit at the 3rd bit of Intermission The recessive 3rd bit of Intermission is forced to dominant The receiver interprets this as Start of Frame and receives a new message 3 Dominant bit at the 8th bit of Error Delimiter The recessive 8th bit of Error Delimiter is forced to dominant The receiver detects an overload condition and sends an Overload Flag BOSCH 21 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Test of transmitter 1 Dominant bit at 1st bit of Intermission 8th bit of Overload Delimiter 2nd bit of Intermission In a test loop the bits described above are forced to dominant At each dominant bit the transmitter detects an overload condition and sends an Overload Flag 2 Dominant bit at 3rd bit of Intermission The recessive 3rd bit of Intermission is forced to dominant The transmitter interprets this as Start of Frame and starts a message 3 Recessive bit at the 4th bit of Identifier The dominant 4th bit of Identifier is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 4 Dominant bit at the
99. ls of the constants and of the type declarations see packages definitions vhd and trace package vhd BOSCH 29 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 2 CAN SYSTEM CAN SYSTEM comprises the complete CAN environment to be simulated its function is described by the architecture FLEXIBLE see figure 2 This is a structural architecture connecting the CAN model to be verified with a flexible number of Reference CAN Model nodes interacting via the CAN bus It is used in different configurations for all protocol test programs The ports of the entity CAN SYSTEM are described in section 4 1 The architecture FLEXIBLE of CAN SYSTEM instantiates components defined by the following entities BUS INTERFACE CAN INTERFACE These entities and their architectures are described in section 4 3 and section 4 4 E CAN SYSTEM CAN BUS E BUS INTERFACE E BUS INTERFACE RECEIVE TRANSMIT RECEIVE TRANSMIT DATA _DATA _DATA _DATA E CAN_INTERFACE E CAN_INTERFACE MODEL LABEL 1 MODEL LABEL n 1 Ww o z iu tr ul L oc wi E Z o gt m BUS INTERFERENCE A COMPARE A REFERENCE A FLEXIBLE Interface Signals Figure 2 architecture FLEXIBLE of CAN SYSTEM The generic parameter MODEL_LABEL of CAN_INTERFACE is used to distinguish between the different instances of CAN_INTERFACE The generic parameters CLOCK_PERIOD and RX_DELAY associated with their actual values in the testbench s con
100. m lt test gt vpp and include files vhi cfg_ lt test gt vhd configuration cfg test of protocol testbench cfg test example vhd configuration cfg test example of protocol testbench cfg test buggy vhd configuration cfg test buggy of protocol testbench lt test gt trace sav backup of trace file generated by simulation BOSCH 82 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 lt test gt e_trace sav backup of trace file generated by simulation of example lt test gt b_trace sav backup of trace file generated by simulation of buggy Note test stands for any of the reference test programs from section 3 2 objects compiled model After installation of the model this directory is empty BOSCH 83 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 A 2 List of Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 architecture STRUCTURAL of PROTOCOL TESTBENCH see 27 architecture FLEXIBLE of CAN SYSTEM esee nee enne enne neni 30 architecture COMPARE of CAN INTERFACE 0 0 cccesssccssscecseeeecseeeeceeeecseeeeseeesseeeenaees 34 Tolerable phase shifts between compared signals example for TRANSMIT DATA 36 architec
101. mentation providing a standardized interface between the user s model the simulation environment and the test programs The internal structure of IMPLEMENTATION is supposed to be defined by the configuration CONFIGURATION IMPLEMENTATION following the example of architecture EXAMPLE and CONFIGURATION EXAMPLE in section 4 4 4 and the description in section 5 1 In that version of CONFIGURATION IMPLEMENTATION that is distributed with the VHDL Reference CAN Model architecture IMPLEMENTATION is substituted by architecture REFERENCE 4 4 4 architecture EXAMPLE The architecture described here see figure 18 is a combination of a simple CAN module consisting as defined in chapter Introduction at page 1 see figure 19 at page 59 of three major parts Interface to the CPU CAN Protocol Controller with a separate Control Register Message Memory and of an elementary CPU model This model is adapted to the CAN module s specific CPU interface The purpose of the CPU model is to drive the CPU interface of the CAN module performing the functions write data and read data interfacing between the CAN model and the protocol test programs The interposed CPU keeps the protocol test programs independent of particular CAN modules TRANSMIT DATA RECEIVE DATA E CAN INTERFACE E CAN MODULE CPU BUS Control Signals MODEL LABEL generic RECEIVE INTERRUPT A READ WRITE A z SIMPLE Interface Signals Figure 18 architectur
102. ments to the Interface Signals which are output of process STIMULI e g BUS_INTERFERENCE to force the RECEIVE_DATA inputs of specific CAN nodes to particular values wait statements waiting for an integer multiple of CLOCK PERIOD or BIT TIME Procedure call statements invoking INITIALIZE WAIT FOR SEND MESSAGE and WRITE TRACE Assignments to internal signals to exchange information with other processes The statements may be grouped in if or case branches or in loops INITIALIZE WAIT FOR and SEND MESSAGE are local procedures of the architecture and are located in the included file test routines vhi while WRITE TRACE is a global procedure located in the package trace package vhd 4 5 1 1 procedure INITIALIZE CFG BIT TIMING CONFIGURATION TYPE INITIALIZE sets RESET active disables all TRANSMISSION REQUEST signals assigns the actual BIT TIMING CONFIGURATION as wellas the internal signal BIT TIME andsets BUS INTERFERENCE to NONE for all nodes in CAN SYSTEM After the initialization RESET is disabled and the CAN nodes are synchronized by applying an edge from recessive to dominant to the RECEIVE DATA inputs of all CAN nodes Since the time from the end of the hardware reset to the begin of the CAN bus activity is implementation specific depending e g on the extent of the message memory s initialization INITIALIZE adapts to this time controlled by the generic parameters INITIALIZATION CYCLES and INIT S
103. n the complete set of tests linked with example make traces b runthe complete set of tests linked with buggy After the simulation of program test there will be a file test trace in the directory BOSCH CAN ROOT tests test This file contains the complete trace information of the simulation run It can be regarded as protocol and documentation of the simulation To check whether the installation of the model and the setup of the simulator are correct compare the file test trace which is generated by the simulation with the file test trace sav which is distributed with the model The two files have to be with one restriction identical The files may not be absolutely identical because in any VHDL simulation when several processes are triggered by the same event the sequence of evaluation is not predictable For this reason the sequence of trace statements with the same time stamp may be different when simulated with different simulation software or hardware The comparison of two trace files generated by different tools can be automated when the lines of both trace files are sorted alphabetically The files test trace sav have been generated by the tool Synopsys VSS v3 4b 3 14 4 Simulating the User s Implementation To start the simulation of a single test for a user s implementation model e g test baudrate type make baudrate If you are simulating with Synopsys VSS and if the simulation runs without a prob
104. nant Start of Frame bit is forced to recessive The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 22 Dominant bit at ACK Delimiter Error Passive The recessive ACK Delimiter bit is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 23 Dominant bit at the first bit of End of Frame Error Passive The recessive bit of End of Frame is forced to dominant The RECEIVE_DATA input is forced to dominant for another 6 bits The transmitter detects a bit error at End of Frame and sends a Passive Error Flag The transmit error counter is increased by 8 The 6 dominant bits during the Passive Error Flag have no effect 24 Dominant bit at the last bit of End of Frame Error Passive bit error during Passive Error Flag The recessive bit of End of Frame is forced to dominant The transmitter detects a bit error and sends a Passive Error Flag The transmit error counter is increased by 8 Then the 3rd bit of Passive Error Flag is forced to dominant The transmitter continues sending Passive Error Flag and waits again for 6 consecutive bits without changing the error counter BOSCH 15 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 25 Dominant bit at last bit of Error Delimiter Error Passive 7 dominant bits after Overload Flag The last recessive bit of Error Delimiter is forced to dominant The
105. nant at the RECEIVE DATA inputs of the implementation CAN model and of the Reference CAN Model node which is running in parallel to the implementation As long as the spike is not longer than the sum of Propagation Delay Segment and Phase Buffer Segment 1 the dominant bus level is not sampled Note Even if the spike is not sampled it is used for synchronisation 3 2 2 biterror Confinement of Bit Errors NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Transmitters and receivers get bit errors at dominant bits in all fields and all frames transmitters get bit errors at recessive bits in the Control Data and CRC Field Tested while Error Active and Error Passive The program consists of the following test steps Test of receiver 1 Recessive bit at ACK Slot recessive bit at first bit of Active Error Flag A dominant ACK bit is forced to recessive The receiver detects a bit error and sends an Active Error Flag The receive error counter is increased by 1 The first bit of the Receiver Error Flag is forced to recessive The receiver detects a bit error and starts sending an Active Error Flag again The receive error counter is increased by 8 BOSCH Hes K8 EIS VHDL Reference CAN User s Manual Revision 2 2 2 Recessive bit at last bit of Active Error Flag The last bit of an Active Error Flag is forced to recessive The receiver detects a bit error and star
106. nd sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 and stuff error after the 15th bit of extended Identifier The recessive stuff bit after the 15th extended Identifier bit is forced to dominant The transmitter detects a stuff error and sends an Active Error Flag The transmit error counter is not changed Bit O and stuff error at the 11th bit of extended Identifier The dominant stuff bit after the 11th extended Identifier bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 BOSCH 25 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 19 Bit 1 and stuff error after RTR bit The recessive stuff bit after the RTR bit is forced to dominant The transmitter detects a stuff error and sends an Active Error Flag The transmit error counter is increased by 8 because in an extended Identifier RTR stuff bit is not part of the arbitration field 20 Bit O and stuff error after RTR bit The dominant stuff bit after RTR bit 1s forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 BOSCH 26 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 Model Description The top level of the Reference CAN Model design is the testbench consisting of a simulation environment and a set of test programs as described in section 3 2 This chapter describ
107. nvested for designing an integrated protocol controller this verification is insufficient and carries high risk for costly redesign iterations The increasing number of CAN licensees and developments of integrated CAN components made it necessary to standardize and to support the protocol verification for all designs For this purpose and motivated by the aforementioned experience Bosch has developed the C Reference CAN Model While the CAN protocol specification document remains the authentic CAN norm standardized by international organisations the C Reference CAN Model establishes a de facto standard for CAN verification Distributed to the CAN licensees it has been utilized in various designs assuring that all existing CAN implementations are compatible with each other and may be used in the same network For the success of CAN as the generally accepted protocol standard the wide range of versatile compatible CAN implementations of different vendors was important This protocol consistency was significantly supported by the availability of the Reference CAN Model To be independent from simulation tools and from different types of CAN implementations the first version of the model has been written in C language together with a simulator kernel and is limited to the protocol itself the data link layer of the OSI model leaving out the physical layer and the application layer which are implementation specific Up to now the Reference
108. o this directory 3 Untar the database tar xvf RefCAN Revision 2 2 tar 4 Define the environment variable BOSCH CAN ROOT by typing setenv BOSCH CAN ROOT path to model Bosch CAN The setting of the environment variable BOSCH CAN ROOT should be done by your project setup procedure Please check also that your VHDL simulator is set up correctly before proceeding Please check README RefCAN txt in your Bosch CAN directory for additional information about your release of the VHDL Reference CAN model In appendix A 1 of this document you find a list of the files and directories together with a short description The VHDL Reference CAN model was developed and tested on a Sun workstation running Solaris 2 5 If you have another hardware or operating system please contact your system manager or check the documentation of your hardware operating system Up to now the model is available for UNIX systems only Simulations were done with Synopsys VSS v3 4b Mentor Graphics QuickHDL v8 5 4 6f and Mentor Graphics ModelSim 5 2b BOSCH 2 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 3 Compilation and Simulation If you have an installation of the Synopsys VSS Simulator you can now go on with the following commands cd BOSCH CAN ROOT simulate genmake SYNOPSYS If you have an installation of the Mentor Graphics QuickHDL Simulator proceed with the following commands cd BOSCH CAN ROOT simulate genmake MG QuickHDL Otherwis
109. occurs during the Error_Delimiter bits 2 7 then the transmitter detects a form error and sends an Error_Flag active or passive The TRANSMIT_ERROR_COUNTER is incremented by 8 If a dominant bit is monitored at the last delimiter bit then the transmitter detects an overload condition and sends an Overload_Flag The first bit of the Error_Delimiter is always recessive because it is necessary to detect the end of an Error_Flag and to change the FIELD to Error_Delimiter STATUS TRANSMITTING FIELD Overload_Flag The Overload_Flag has the same form like the Active_Error_Flag The error actions and conditions during the flag are identical STATUS TRANSMITTING FIELD Overload_Delimiter The Overload_Delimiter has the same form as the Error_Delimiter The error actions and conditions during the delimiter are identical STATUS TRANSMITTING FIELD Intermission A dominant bit during the first or the second bit of Intermission is interpreted as overload condition and the transmitter sends an Overload_Flag If the 3rd Intermission bit is monitored as dominant the transmitter interprets this as Start Of Frame If then TRANSMISSION REQUEST is true a new transmission is started beginning with Identifier or if TRANSMISSION_REQUEST is false the transmitter becomes a receiver next bit is Identifier At a recessive bit at the 3rd Intermission bit the transmitter sends Suspend_Transmission if ERROR_PASSIVE starts sending a new frame if TRANSMISSION_REQUEST
110. omponent 4 4 4 1 3 architecture TIMING of CPU CONTROL This component controls the BIT TIMING CONFIGURATION input of the component CAN PROTOCOL CONTROLLER entity CAN INTERFACE The CPU writes the values of the parameters Resynchronisation Jump Width Prescaler Propagation Segment and Phase Buffer Segment 1 into the TIMING REGISTER The parameter Information Processing Time is not programmable in a hardware implementation so it is not included in the TIMING REGISTER In this example it is controlled directly by the test program Address TIMING REGISTER 15 downto 0 162004 Resynchronisation Jump Width 1 0 amp 0 amp Prescaler 4 0 amp 0 amp Propagation Segment 2 0 amp 0 amp Phase Buffer Segment 1 2 0 162014 not used Table 2 Address map of the CAN module s control register in architecture TIMING In a hardware implementation Information Processing Time would be an intrinsic attribute of the design requiring the test program to use the same value for the configuration of the parallely simulated reference model To keep the test programs independent of the hardware implementations the actual value of Information Processing Time is not defined in the source code files of the test programs it is defined by a generic parameter of the test program s entity The generic parameter INFORMATION PROCESSING TIME is associated with its actual value in the test program s configuration of the testbench BOSC
111. ondition and the receiver sends an Overload Flag If the 3rd Intermission bit is monitored as dominant the receiver interprets this as Start Of Frame If then TRANSMISSION REQUEST is true the receiver becomes transmitter and a new transmission is started beginning with Identifier or if TRANSMISSION REQUEST is false the receiver receives another frame next bit is Identifier At a recessive bit at the 3rd Intermission bit the receiver becomes transmitter and starts sending a new frame if TRANSMISSION REQUEST is true beginning with Start Of Frame or changes the STATUS to IDLE STATUS RECEIVING FIELD others The field others contains the reception of a data frame from the field Start Of Frame to End Of Frame and is divided in two main parts In the first part the actual bit is not a stuff bit The Identifier KIND STANDARD EXTENDED FRAME KIND DATA REMOTE NBYTES Data Length Code and the maximum number of bits in the frame are calculated Then the items end of stuffed area checksum ACK bit form error at ACK Delimiter and form error at End Of Frame are tested After receiving a recessive bit at the last position of End Of Frame the received message RX MESSAGE is calculated and the node changes FIELD to Intermission If during the reception the next expected bit is a stuff bit then POSITION is not incremented and the FIELD signal is not calculated because a stuff bit has the same POSITION and FIELD value as the preceding message b
112. or counter by 8 3 Dominant bit at the first bit of End of Frame The recessive bit of End of Frame is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 4 Dominant bit at the last bit of End of Frame The recessive bit of End of Frame is forced to dominant The receiver detects an overload condition and sends an Overload Flag The receive error counter is not changed 5 Dominant bit at the last bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The receiver detects an overload condition and sends an Overload Flag The receive error counter is not changed 6 Dominant bit at the second bit of Overload Delimiter The recessive bit of Overload Delimiter is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its error counter by 8 BOSCH 18 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 T Dominant bit at the second bit of Error Delimiter The recessive bit of Error Delimiter is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its
113. put or output signals differ from the names in the reference protocol controller model In the VHDL version the interface between the protocol test programs the Reference CAN Model and the implementation s model is the entity CAN INTERFACE associated with an architecture enclosing the implementation s model All implementation specific type conversions of interface signals and translations of test program commands are done inside this architecture leaving the rest of the Reference CAN Model untouched Test programs reference and implementation s models and the CAN bus system are linked together by a configuration of the PROTOCOL TESTBENCH During a simulation the Reference CAN Model produces a trace file recording all serial data on the CAN bus and the internal activities of the CAN Protocol Controllers as well as the possible occurrence of a protocol error Optionally a similar trace function for the implementation may be added for the manual comparison of the CAN functions If the Reference CAN Model is used for the verification of an implementation s model in a different design environment e g a hardware tester the trace function can be expanded by a pattern generator writing test vectors in any desired format In order to retain the invested know how and to reduce possible design risks the internal structure of model testbench and test program of the C model have been remodelled in the VHDL model The protocol test program set was tr
114. r counter by 1 Dominant stuff error at stuff bit after the 64th Data Field position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Recessive stuff error at stuff bit after the 8th Data Field position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 BOSCH 23 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 13 14 15 16 Recessive stuff error at stuff bit after the 8th CRC Field position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Dominant stuff error at stuff bit after the 1st CRC Field position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Dominant stuff error at stuff bit after the 15th CRC Field position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit er
115. r test and one or more RefCANS the user must set signal DO ARBITRATION true Now the respective RefCAN s will wait with its their Start Of Frame until the implementation has set the global signal BOND OUT 0 TXROST true After arbitration has started signal DO ARBITRATION should be reset This procedure is neccessary to compensate for different speeds of CPU interfaces When the bus is idle a RefCAN node can start to send immediately after the test program defined TRANSMIT MESSAGE while an implementation has to wait until the TRANSMIT MESSAGE has been written into its message buffer BOSCH 67 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Figure 21 shows a section from baudrate vpp where the implementation and three RefCAN s start arbitration synchronously Figure 21 Synchronous Start of Arbitration for an Implementation and 3 RefCANs BOSCH ES I R EQU ESTE Iden tifier 1 68 End Of Frame 2 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 5 Verification of an Implementation The design of integrated protocol controllers generally has to emphasize the verification of completeness and correctness of the protocol For Controller Area Network CAN which is licensed to most major semiconductor suppliers it is of special importance to standardize the protocol verif
116. r the on line protocol check some additional signals are necessary which are not ports of the entity CAN INTERFACE and which usually are internal signals of a CAN module not accessible from the outside The additional signals are the actual values of the error counters the sampled bit and the busoff state To avoid the problems with the design synthesis that would arise if these signals had to be connected to the highest level of the hierarchy for no other purpose than the CAN protocol verification the global signal BOND OUT an array of records is introduced see file trace package vhd A BOND OUT record contains copies of internal signals or variables of a CAN node to be used for protocol verification or for the extraction of trace information the values of the BOND OUT signals may not have any influence on the function of the CAN node Which of the array s elements is used inside a CAN node model is defined by the generic parameter MODEL LABEL For the implementation s model at least the record elements BUSMON the sampled bit TRANSMIT ERROR COUNTER RECEIVE ERROR COUNTER the counter s values and BUSOFF the digital state have to be connected All these elements contain information required by the CAN protocol when a new bit value is to be evaluated so somewhere in the implementation s model this information has to be accessible If the information is available as signals they are copied into the appropriate elements of the BOND OUT
117. rated by genmake genmake generates Makefile Depends files and setup files for the specified simulator genmake sav backup of genmake Makefile SYNOPSYS backup of Synopsys Makefile Makefile MG QuickHDL backup of Mentor QuickHDL Makefile Makefile MG ModelSim backup of Mentor ModelSim Makefile doc documentation Users Manual V pdf Users Manual DataSheet_V pdf Data Sheet can2spec pdf CAN Protocol Specification Revision 2 0 reference testbench Reference CAN Model and packages Depends SYNOPSYS backup of Synopsys Depends file Depends MG QuickHDL backup of Mentor QuickHDL Depends file Depends MG ModelSim backup of Mentor ModelSim Depends file definitions vhd package definitions used by the Reference CAN Model trace package vhd package used for trace output generation protocol testbench vhd entity of protocol testbench protocol testbench struct vhd architecture structural of protocol testbench can system vhd entity of can system can system flexible vhd architecture flexible of can system test program vhd entity of test program BOSCH 80 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 can interface vhd entity of can interface can interface compare vhd architecture compare of can interface can interface reference vhd architecture reference of can interface bus interface vhd entity of bus interface bus interface beh vhd architecture behaviour of bus interface checker vhd
118. rfacing between the physical layer and the application layer The VHDL reference model of the protocol controller is behaviourally structured it is not targeted for synthesis but for the functional verification Different types of CAN implementations are offered by several semiconductor suppliers realized as stand alone device or as module on a uC The differences of those implementations lie in the number of local message buffers in the acceptance filtering in the CAN busline input comparators and output drivers and in the CPU and periphery interface Physical Oscillator Layer Calibrator CAN Protocol CAN Protocol Controller Controller Receive Transmit Buffer 1 i Port Module with Buffer FIFO Digital and Analog Input and Output CPU Interface External Local CPU Port Pins CAN Component with CAN Component with CAN Component Basic Application Layer Full Application Layer of Type SLIO Figure 22 Structure of different CAN Components Common for all implementations is the CAN Protocol Controller whose function is defined by the CAN protocol specification it handles the bit timing the frame coding the bit stuffing the CRC check the frame validation and the fault confinement The interface to the physical layer is the serial bit stream BOSCH 70 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 coded as dominant or recessive bits the interface to the application
119. ronization on a recessive to dominant edge if the edge lies between the sample point and the next Synchronisation Segment PHASE ERROR lt 0 Phase Buffer Segment 2 is shortened by a number of time quanta less or equal the resynchronization jump width If the distance of the detected edge from the next Synchronization Segment is less than the resychronization jump width the time quanta counter is set to one COUNT 1 and a new bit time is started Else the number of time quanta for this bit time NTQ_I is decremented by DELTA The generation of TRANSMIT POINT is done only if the detected edge lies Information Processing Time after the sample point BOSCH 44 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 elsif HARD SYNC ENABLE 0 and PHASE ERROR lt 0 then Edge between sample point and next SyncSeg Shorten Phase Buffer Segment 2 if COUNT gt NTQ I BIT TIMING CONFIGURATION RESYNCHRONIZATION JUMP WIDTH then COUNT 1 Generation of TRANSMIT_POINT only if edge lies Information Processing Time after sample point if DIFF gt BIT_TIMING_CONFIGURATION INFORMATION_PROCESSING_TIME then TRANSMIT_POINT lt true TX DATA lt BUS DRIVE end if else NTQ NTQ DELTA end if end if Figure 11 Resynchronization Node Transmitter BOSCH 45 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 2 4 process BIT STREAM PROCESSOR 4 4 2 4 1 Overview The BIT STREAM PROCESSOR generate
120. ror counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Recessive stuff error at stuff bit after the 15th CRC Field position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 3 2 13 txarb Arbitration NUMBER OF CANS 1 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 A transmitter gets all types of bit errors at different positions in the Arbitration Field Standard Identifier 1 2 3 4 5 6 Bit 1 error at the 2nd Identifier bit The recessive Identifier bit is forced to dominant The transmitter loses arbitration and becomes re ceiver After the 8th Identifier bit the receiver detects a stuff error and send an Active Error Flag Bit 0 error at the 7th Identifier bit The dominant Identifier bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 error at RTR bit The recessive RTR bit is forced to dominant The transmitter loses arbitration and becomes receiver After the 5th extended Identifier bit the receiver detects a stuff error and sends an Active Error Flag Bit 0 error at the RTR bit The dominant RTR bit is forced to recessive The transmit
121. ror counter is increased by 8 Some bits of the following Active Error Flags are forced to recessive therefore the Error Flags start again and increases the receive error counter by 8 Wait until Intermission and receive new frame REC 105 The receiver waits for the last bit of Intermission and receives a new frame successful The receive error counter is decreased by 1 BOSCH 12 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 8 Wait until Intermission and receive new frame REC 104 The receiver waits for the last bit of Intermission and receives a new frame successful The receive error counter is decreased by 1 9 Wait until Intermission and receive new frame REC 103 The receiver waits for the last bit of Intermission and receives a new frame successful The receive error counter is decreased by 1 10 Dominant bit at last bit of End of Frame 4 8 dominant bits after Overload Flag The recessive bit of End of Frame is forced to dominant The RECEIVE DATA input is forced to dominant for another 38 bits The receiver detects a form error and sends an Overload Flag After sending the Overload Flag the receiver detects 8 dominant bits and increases its error counter by 8 After each sequence of additional eight consecutive dominant bits the receive error counter is increased by 8 Receiver is now Error Passive 11 Dominant bit at the 3rd bit of Overload Delimiter 8 2 dominant bits after Passive Error Flag A recessive b
122. rror Count Once the Receive Error Count has reached its Error Passive level it is no longer incremented because then its actual value is of no interest Theoretically the Fault Confinement Rules could increment the Receive Error Count s value over all limits A new revision of the ISO 11898 CAN protocol specification is in preparation that will cover these cases the same way as the Reference CAN Models BOSCH _ 56 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 In the Reference CAN Model the RECEIVE ERROR COUNTER is used to count the Busoff Recovery Sequence a dedicated RECESSIVE COUNTER is used to count the sequences of 11 consecutive recessive bits Both implementations are not obligatory the internal structure of architecture REFERENCE is designed to interface with the protocol check processes it is not intended as an example for hardware implementations of CAN protocol controllers 4 4 2 7 Special Features of architecture REFERENCE for Protocol Check The architecture reference has two special features The first feature is the adjustable Receive Error Counter After the successful reception of a message when the Receive Error Counter is decremented then it will be set to a value of 127 its maximum value is limited to 136 Since the implementation s Receive Error Count may be set to another value in the range of 119 to 127 the Reference CAN Model can adjust itself to the value of BOND OUT 0 RECEIVE ERROR COUNTER
123. s associated with architecture REFERENCE the component MESSAGE MEMORY is associated with architecture BASIC the component CONTROL REGISTER is associated with architecture TIMING and the component CPU ACCESS is associated with architecture PARALLEL 16 BIT This structure is only an example it is by no means a mandatory standard for all implementations e g the control register could be part of a synthesizable protocol controller The internal structure of the CAN module is optional but the user has to be aware that using the testbench and the test programs supplied with this VHDL Reference CAN Model only assures the conformity of the CAN Protocol Controller part of the implementation with CAN Protocol Version 2 0 Part A B In order to verify the correct function of the CPU interface and of the message memory the user has to write additional test programs 4 4 4 1 1 architecture BASIC of CAN MESSAGE This is an example of a CAN module s message memory with basic functions It consists of a receive buffer and of a transmit buffer each buffer consisting of 7 words of 16 bits The receive buffer stores the last received message the transmit buffer stores the message to be transmitted Address RECEIVE BUFFER Address 1 15 downto 0 Address TRANSMIT BUFFER Address 8 15 downto 0 164023 New Data amp Message Lost amp 0 amp 164093 Do Transmit amp Tx Pending amp 0 amp Identifier 28 downto 16 Identifier 28 do
124. s and receives the bit stream Input signals of process BIT STREAM PROCESSOR RESET PROCESS BIT RECEIVE DATA BIT ERROR TRANSMISSION REQUEST TRANSMIT MESSAGE FRAME KIND MESSAGE IDENTIFIER KIND MESSAGE IDENTIFIER MESSAGE NBYTES MESSAGE DATA ADJUST ERROR COUNTERS Functional output signals of process BIT STREAM PROCESSOR BUS DRIVE HARD SYNC ENABLE TRANSMISSION REQUEST STATUS RECEIVED MESSAGE FRAME KIND MESSAGE IDENTIFIER KIND MESSAGE IDENTIFIER MESSAGE NBYTES MESSAGE DATA BOND OUT signals of process BIT STREAM PROCESSOR BOND OUT MODEL LABEL BUS DRIVE BOND OUT MODEL LABEL TRANSMIT ERROR COUNTER BOND OUT MODEL LABEL RECEIVE ERROR COUNTER BOND OUT MODEL LABEL TXROQST BOND OUT MODEL LABEL FIELD BOND OUT MODEL LABEL POSITION BOND OUT MODEL_LABEL STATUS Trace output signals of process BIT STREAM PROCESSOR MESSAGE OK MESSAGE RECEIVED TX REQUEST STATUS STUFF BIT PREVIOUS POSITION PREVIOUS STATUS PREVIOUS FIELD BOSCH 46 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 2 4 Frame Format STATUS The actual state of a CAN node is described by STATUS STATUS can have the values RESET WAIT FOR BUS IDLE IDLE RECEIVING TRANSMITTING BUS OFF RECOVERY FIELD Each bit of a CAN protocol frame can be referenced by its FIELD and POSITION inside the frame FIELD is not equal to the field names in the CAN Specification It is a group of bits with the same function For example
125. s architecture READ WRITE of entity CPU is specifically designed to interface between the protocol test programs and the architecture SIMPLE of entity CAN MODULE Other CAN module implementations will require a different CPU entity interfacing the particular type of data bus of the CAN module s entity Those implementation specific CPU models will have to provide the same features as READ WRITE BOSCH 62 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 4 4 5 architecture BAD EXAMPLE The architecture BAD EXAMPLE of CAN INTERFACE is a slightly modified copy of the architecture REFERENCE see section 4 4 2 It is used in CONFIGURATION BUGGY of architecture EXAMPLE CONFIGURATION BUGGY is a copy of CONFIGURATION EXAMPLE see section 4 4 4 with the exception that the component CAN PROTOCOL CONTROLLER is associated with architecture BAD EXAMPLE instead of architecture REFERENCE This buggy version of a CAN implementation demonstrates when simulated in configuration SYS_B of CAN SYSTEM see section 4 2 3 how the PROTOCOL CHECK in architecture COMPARE see section 4 4 1 1 reveals CAN protocol errors Aside from the deliberately inserted CAN protocol errors BAD EXAMPLE is modified in one other point The value of the RECEIVE ERROR COUNT when it is decreased from Error Passive level to Error Active level In the CAN specification the fault confinement rule 8 states After the successful reception of a message the RECEIVE ERROR COU
126. ssive bit of Error Delimiter is forced to dominant The receiver detects a form error and increments the receive error counter by 1 After the 6 consecutive dominant Passive Error Flag bits the receiver sees another dominant bit and increments the receive error counter by 8 A new transmission is started BOSCH 16 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 36 Dominant bit at first bit of transmitter s Intermission The recessive bit of Intermission is forced to dominant The transmitter detects an overload condition and sends an Overload Flag 37 Recessive bit during transmitter s Overload Flag The second bit of the Overload Flag is forced to recessive The transmitter detects a bit error and increments its error counter by 8 Now the transmit error counter exceeds 255 and the node becomes Bus Off 3 2 7 extd id Test of proper recognition of IDE bit at all stuff conditions and test of losing arbitration at IDE bit NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 The program consists of the following test steps Receiver test of stuff bit combinations at IDE 1 IDE dominant standard frame Dominant stuff bit before IDE bit after IDE is dominant 2 IDE dominant standard frame Dominant stuff bit before IDE bit after IDE is recessive 3 IDE dominant standard frame Recessive stuff bit before IDE bit after IDE is dominant 4 IDE dom
127. t time there is the possibility to synchronize on a recessive to dominant edge at the RECEIVE_DATA input This can be done by a Hard Synchronization or by Resynchronization Synchronization will only be done when the last sampled bus value was recessive i e BUSMON 1 This is necessary to avoid synchronizing on spikes on the bus line The conditions for synchronization are dependent whether the node is receiver or transmitter For additional information about synchronization see also CAN Specification 2 0 Part A B BOSCH 41 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 if RECEIVE DATA 0 and BUSMON 1 and SYNC ENABLE then SYNC ENABLE false if HARD SYNC ENABLE 1 then Hard Synchronization end if elsif HARD SYNC ENABLE 0 and BUS DRIVE 1 then Resynchronization when Receiver end if elsif HARD SYNC ENABLE 0 and PHASE ERROR lt 0 then Resynchronization when Transmitter end if end if Figure8 Synchronization flow Hard Synchronization When the CAN node is in Bus Idle state the signal HARD SYNC ENABLE is set true by the BIT STREAM PROCESSOR Now a recessive to dominant edge on the bus will cause a Hard Synchronization provided that the last sampled value was recessive When the node is receiver and a recessive to dominant edge is detected the value of the time quanta counter is set to one COUNT 1 and a new bit time starts If the node is transmittin
128. t waiting for the proper reset conditions of the separate TRANSMISSION REQUEST inputs STIMULI REQUEST and SYNCHRONIZE REQUEST communicate by means of internal signals of TEST PROGRAM for an example of a test program see section 5 3 BOSCH 64 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 Processes REQUEST and SYNCHRONIZE REQUEST the internal signals of TEST PROGRAM and the procedures used by STIMULI are the same for all architectures of TEST PROGRAM Therefore they are extracted from the test program source code files and stored in separate vhi files The core of the source code the STIMULI process remains in the file test vpp referencing the vhi files by include statements The internal signals of TEST PROGRAM are defined in file signal definition vhi request process vhi contains the processes REQUEST and SYNCHRONIZE REQUEST while the internal procedures of STIMULI are shifted into test routines vhi make uses the C compiler s preprocessor cpp to process the include statements generating the file test vhd from test vpp and the vhi files see section 5 3 4 5 1 process STIMULI Process STIMULI consists of a sequence of statements which form the specific test program It begins with an initialization of the CAN nodes at the end of the process an assertion of severity failure stops the simulation A typical protocol test program consists of the following statements Assign
129. ter by 1 Dominant stuff error at stuff bit after the 2nd Data Length Code position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Dominant stuff error at stuff bit after the 4th Data Length Code position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Recessive stuff error at stuff bit after the 4th Data Length Code position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Recessive stuff error at stuff bit after the 8th Data Field position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Dominant stuff error at stuff bit after the 12th Data Field position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive erro
130. ter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 BOSCH 22 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 2 3 4 5 6 7 8 9 10 11 12 Dominant stuff error at stuff bit after the 4th Identifier position A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag The transmit error counter is not changed because the error occurred during arbitration The receiver sends an Active Error Flag and increases the receive error counter by 1 Dominant stuff error at stuff bit after RTR bit A recessive stuff bit is forced to dominant The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 No arbitration is possible after the RTR bit of an extended Identifier Recessive stuff error at stuff bit after RTR bit A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error counter by 1 Recessive stuff error at stuff bit after the 2nd Data Length Code position A dominant stuff bit is forced to recessive The transmitter sends an Active Error Flag and increases the transmit error counter by 8 The receiver sends an Active Error Flag and increases the receive error coun
131. ter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 and stuff error after the 9th bit of Identifier The recessive stuff bit after the 9th Identifier bit is forced to dominant The transmitter detects a stuff error and sends an Active Error Flag The transmit error counter is not changed Bit O and stuff error after the 5th bit of Identifier The dominant stuff bit after the 5th Identifier bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 BOSCH 24 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 7 8 9 10 11 12 Bit 1 and stuff error after RTR bit The recessive stuff bit after the RTR bit is forced to dominant The transmitter detects a stuff error and sends an Active Error Flag The transmit error counter is not changed because in a standard Identifier RTR stuff bit is part of the arbitration field Bit O and stuff error after RTR bit The dominant stuff bit after RTR bit is forced to recessive The transmitter detects a bit error and sends an Active Error Flag The transmit error counter is increased by 8 Bit 1 error at IDE bit The recessive IDE bit is forced to dominant The transmitter lost arbitration and becomes receiver After the 5th Data Length Code bit the receiver detects a stuff error and sends an Active Error Flag Bit O error at IDE bit The dominant
132. tion at RTR extended data frame with illegal SRR dominant 3 IDE recessive extended frame Lost arbitration at SRR standard data frame 4 IDE recessive extended frame Lost arbitration at IDE standard remote frame 5 IDE recessive extended frame Lost arbitration at extended Identifier 6 IDE recessive extended frame Lost arbitration at RTR extended data frame 7 IDE recessive extended frame Lost arbitration at SRR extended data frame with illegal SRR dominant 3 2 8 formerr Confinement of Form Errors NUMBER OF CANS 2 Bit Timing CLOCK PERIOD 100 ns PRESCALER 1 NT 10 SAMPLE 6 RESYCHRONIZATION JUMP WIDTH 4 Transmitters and receivers get form errors at all fixed format fields of all frames Tested while Error Active and Error Passive The program consists of the following test steps Test of receiver 1 Dominant bit at CRC Delimiter The recessive bit of CRC Delimiter is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects domi nant bits after sending its Error Flag and increases its error counter by 8 2 Dominant bit at ACK Delimiter The recessive bit of ACK Delimiter is forced to dominant The receiver detects a form error and sends an Active Error Flag The receive error counter is increased by 1 The receiver detects dominant bits after sending its Error Flag and increases its err
133. ts sending an Active Error Flag again The receive error counter is increased by 8 3 Dominant bit at first bit of Intermission recessive bit at first bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the first bit of this Overload Flag is forced to recessive The receiver detects a bit error and sends an Active Error Flag The receive error counter is increased by 8 4 Dominant bit at first bit of Intermission recessive bit at last bit of Overload Flag The first bit of Intermission is forced to dominant to create an Overload Flag Then the last bit of this Overload Flag is forced to recessive The receiver detects a bit error and sends an Active Error Flag The receive error counter is increased by 8 5 Create Active Error Flags until receiver is Error Passive When sending an Active Error Flag the RECEIVE DATA input of the receiver is forced to recessive for 11 bit times The receiver detects bit errors at every bit and starts Active Error Flags With every bit error the receive error counter is increased by 8 Then the last Active Error Flag is sent and the receiver becomes Error Passive but it continues sending the Active Error Flag 6 Recessive bit at ACK Slot dominant bit at first bit of Passive Error Flag A dominant ACK bit is forced to recessive The receiver detects a bit error and sends a Passive Error Flag The receive error counter is increased by 1 The first bit of the p
134. ture REFERENCE of CAN INTERFACE ssssssseseeeee emen eene 38 Process flow Of BET TIMING idees enu da aatis adul uio edu Ge 40 Bit Timing and Phase Bator xg accede eode ob telo rie Bee iE eee dun 41 synchronization TIOW secese e eda be E a S PEES EEE Aoo RUN DNE TRE PAP ORE 42 Hard Synchronization on recessive to dominant edge esse 43 Resynchronization Node ReeelVet 4 ree etre annee eed Enea ev RE Seas ee eee ds 44 Resyriclironization Node Transmitter 52er eph hee ees 45 Structure of the BIT STREAM PROCESSOR process eeeeeeeeeeerenee 48 Structure of RECEIVING Status 82 52 2 4 aera Ges gie ir ue e nte PRSE a RR Ha Ui eae 50 Structure of TRANSMITTING status eeeeeeeeeeisee eese etn seen ntn estas tine innen dan 52 Start of a simulation s trace file e g test program emlcount eese 55 Example of lost arbitration in a simulation s trace file e g test program emlcount 55 Example of CRC Error in a simulation s trace file e g test program crc 56 architecture EXAMPLE Of CAN INTERFACE 000 cccssssccsscecssececseeeecsneeeeeeeeeseeessneeeenaees 58 architecture SIMPLE Of CAN MODULE 54 pectet sete b ena stet ie ere A Tea Eee pea aea eiua ed nin 59 Structure of an architecture lt test gt of TEST PROGRAM sese 64 Synchronous Start of Arbitration for an Implementation and 3 RefCANS 68 Struc
135. ture of different CAN Components essere ener eene 70 Verification of a CAN module of an embedded microcontroller 13 Template for a testbench configuration sssesseseseseesessesereererseesesreesresstserssreseeseresressesee 75 Testbench configuration for test program BAUDRATE simulating architecture EXAMPLE 76 architecture TEMPLATE of TEST PROGRAM ccceccccesceessececeeececeececeeeeesaeeeesaeeeeaaees T A 3 List of Tables Table 1 Table 2 Table 3 Address map of the CAN module s message memory in architecture BASIC 60 Address map of the CAN module s control register in architecture TIMING 61 Features of the architecture READ WRITE Of CPU sese 62 A A Related Documents CAN Specification Revision 2 0 Part A and B A 5 CAN Services Actual information about this VHDL Reference CAN model and the CAN IP modules available at Bosch can be found on the Bosch CAN website http www can bosch com BOSCH 84 K8 EIS
136. type BOND OUT TYPE as defined in package trace package vhd BOND OUT is an array of records each architecture drives only elements of BOND OUT MODEL LABEL In the model of the user s BOSCH 33 K8 EIS VHDL Reference CAN User s Manual Revision 2 2 implementation the BOND OUT signals see section 5 1 are to be excluded from synthesis they are intended for the verification simulation only 4 4 1 architecture COMPARE The architecture COMPARE of CAN INTERFACE is a structural architecture as shown in figure 3 It consists of the components IMPLEMENTATION REFERENCE both referencing entity CAN INTERFACE and of the component PROTOCOL CHECK referencing entity CHECKER E CAN INTERFACE RECEIVE DATA RX DELAY TRANSMIT DATA R TRANSMIT DATA I E CAN INTERFACE E CAN INTERFACE BEHAVIOUR BOND OUT BOND OUT MODEL LABEL generic MODEL LABEL 0 Signals Signals CHECKER A E A REFERENCE A z IMPLEMENTATION RECEIVED MESSAGE R RECEIVED MESSAGE A COMPARE Interface Signals Figure3 architecture COMPARE of CAN INTERFACE The IMPLEMENTATION is running in parallel to the REFERENCE meaning they get the same inputs and should generate the same outputs During a simulation some of the BOND OUT signals and the TRANSMIT DATA and RECEIVED MESSAGE port signals of the implementation s model and of the Reference CAN Model node are compared by PROTOCOL CHECK The BOND OUT signals are not part Of CAN INTERF
137. wnto 16 16 03 Identifier 15 downto 0 16 0A Identifier 15 downto 0 16 04 Extended amp Remote amp 0000000000 amp 16 0B Extended amp Remote amp 0000000000 amp Data_Length_Code Data_Length_Code 16 05 Data 1 amp Data 2 16 0C Data 1 amp Data 2 16 06 Data 3 amp Data 4 16 0D Data 3 amp Data 4 16 07 Data 5 amp Data 6 16 0E Data 5 amp Data 6 16 08 Data 7 amp Data 8 16 0F Data 7 amp Data 8 Table 1 Address map of the CAN module s message memory in architecture BASIC The messages are stored as std logic vectors a bit with value 0 corresponds to a dominant bit on the CAN bus a bit with value 1 corresponds to a recessive bit In case of standard frames only the first 11 of the 29 Identifier bits are used Identifier 28 downto 18 is then regarded as Identifier 10 downto 0 In the RECEIVE_BUFFER New_Data and Message_Lost are status bits which can be read and written by the CPU Each time a message is received the message memory sets New_Data the CPU is expected to reset New_Data before reading the message When New_Data is not reset at the reception of the next message the message memory will set Message_Lost Each reception of a message is signalled to the CPU by a pulse of the interrupt line RECEIVE_INTERRUPT The message memory does not do any acceptance filtering each received message is stored into the RECEIVE_BUFFER When a new message is stored

Download Pdf Manuals

Related Search

Related Contents

Wassertester WA – 300  Pour l`École, renforcez le SNUipp-FSU et la FSU. - SNUipp  DE Bedienungsanleitung Trocknungsaggregat  Samsung SH12BWH Manual de Usuario  User Manual-MTB - Dtheatersandcontrols  Hitachi Plasma 42 PD 5200    TECNICA 819 - kleer  

Copyright © All rights reserved. Failed to retrieve file