1. Definitions定义1.1 Boldface type is used to identify defined terms.（a）The Adjudicator（评判员）is the person appointed jointly by the Employer and the Contractor to resolve disputes in the first instance, as provided for in GCC Clauses 24 and 25 hereunder.（b）Bill of Quantities means the priced and completed Bill of Quantities forming part of the Bid.（c）Compensation Events（索赔）are those defined in GCC Clause 44 hereunder.（d）The Completion Date（竣工日期）is the date of completion of the Works as certified by the Project Manager, in accordance with GCC Sub-Clause 55.1.（e）The Contract is the Contract between the Employer and the Contractor to execute, complete, and maintain the Works. It consists of the documents listed in GCC Clause 2.3 below.（f）The Contractor is a person or corporate body whose Bid to carry out the Works has been accepted by the Employer. （g）The Contractor’s Bid is the completed bidding document submitted by the Contractor to the Employer.（h）The Contract Price is the price stated in the Letter of Acceptance(中标函) and thereafter as adjusted in accordance with the provisions of the Contract.（i）Days are calendar days; months are calendar months.（j）Dayworks are varied work inputs subject to payment on a time basis for the Contractor’s employees an d Equipment, in addition to payments for associated Materials and Plant.（k）A Defect (缺陷)is any part of the Works not completed in accordance with the Contract.（l）The Defects Liability Certificate (缺陷责任凭证)is the certificate issued by Project Manager upon correction of defects by the Contractor.（m）The Defects Liability Period(缺陷责任期) is the period named in the SCC Sub-Clause 35.1 and calculated from the Completion Date.（n）Drawings include calculations and other information provided or approved by the Project Manager for the execution of the Contract.（o）The Employer is the party who employs the Contractor to carry out the Works, as specified in the SCC(特殊条款).（p）Equipment is the Contractor’s machinery and vehicles brought temporarily to the Site to construc t the Works.（q）The Initial Contract Price(最初合同价格)is the Contract Price listed in the Employer’s Letter of Acceptance.（r）The Intended Completion Date(拟竣工日期) is the date on which it is intended that the Contractor shall complete the Works. The Intended Completion Date is specified in the SCC. The Intended Completion Date may be revised only by the Project Manager by issuing an extension of time or an acceleration order.（s）Materials are all supplies, including consumables(消耗品), used by the Contractor for incorporation in the Works.（t）Plant is any integral part of the Works that shall have a mechanical, electrical, chemical, or biological function.（u）The Project Manager(监理工程师) is the person named in the SCC (or any other competent person appointed by the Employer and notified to the Contractor, to act in replacement of the Project Manager) who is responsible for supervising the execution of the Works and administering the Contract.（v）SCC means Special Conditions of Contract(特殊合同条款)（w）The Site is the area defined as such in the SCC.（x）Site Investigation Reports(现场考察报告) are those that were included in the bidding documents and are factual and interpretative reports about the surface and subsurface conditions at the Site.（y）Specification（规范）means the Specification of the Works included in the Contract and any modification or addition made or approved by the Project Manager.（z）The Start Date（开工日期）is given in the SCC. It is the latest date when the Contractor shall commence execution of the Works. It does not necessarily coincide with any of the Site Possession Dates.1. Definitions定义1.1 Boldface type is used to identify defined terms.（a）The Adjudicator（评判员）is the person appointed jointly by the Employer and the Contractor to resolve disputes in the first instance, as provided for in GCC Clauses 24 and 25 hereunder.评判员是解决业主和承包商之间纠纷的第一责任人。
Document Title Specification of Module XCP Document Owner AUTOSARDocument Responsibility AUTOSARDocument Identification No 412Document Classification StandardDocument Version 2.0.0Document Status FinalPart of Release 4.0Revision 3Document Change HistoryDate Version Changed by Change Description12.12.2011 2.0.0 AUTOSARAdministration ∙Added parameters for Event Channel and Timestamp configuration∙Added possibility to calculate memory consumption for ODT (DAQ & STIM) ∙ Restructuring configurationparameters for static & dynamic ODT ∙Added support for deactivation of transmission capabilities11.10.2010 1.1.0 AUTOSARAdministration ∙Add chapter 7.8 (Version check), RTE limitation, OS Counter Ref∙Remove InstanceID and known limitation (OS)07.12.2009 1.0.0 AUTOSARAdministration∙ Initial ReleaseDisclaimerThis specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification.The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights.This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only.For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher.The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications.The word AUTOSAR and the AUTOSAR logo are registered trademarks.Advice for usersAUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software).Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard.Table of Contents1Introduction and functional overview (5)2Acronyms and abbreviations (6)3Related documentation (7)3.1Input documents (7)3.1.1Related standards and norms (8)4Constraints and assumptions (9)4.1Limitations (9)4.2Applicability to car domains (9)5Dependencies to other modules (10)5.1AUTOSAR RTE (BSW Scheduler) (10)5.2AUTOSAR FlexRay Interface (10)5.3AUTOSAR CAN Interface (10)5.4AUTOSAR SocketAdaptor (10)5.5AUTOSAR RTE (10)5.6AUTOSAR OS (10)5.7AUTOSAR Diagnostic Event Manager (10)5.8AUTOSAR Development Error Tracer (10)5.9File structure (11)5.9.1Code file structure (11)5.9.2Header file structure (11)6Requirements traceability (13)6.1General Requirements on Basic Software Modules (13)6.2Requirements on the XCP Basic Software Module (15)7Functional specification (16)7.1XCP on CAN (18)7.2XCP on FlexRay (19)7.3XCP on Ethernet (21)7.4Requirements on Debugging (22)7.4.1General Requirements (22)7.5Error classification (23)7.6Error detection (24)7.7Error notification (24)7.8Version checking (24)8API specification (26)8.1Imported types (26)8.2Type definitions (26)8.2.1Xcp_ConfigType (26)8.2.2Xcp_Transmission Mode Type (26)8.3Function definitions (27)8.3.1Xcp_Init (27)8.3.2Xcp_GetVersionInfo (28)8.4Call-back notifications (29)8.4.1Xcp_<module>RxIndication (29)8.4.2Xcp_<module>TxConfirmation (30)8.4.3Xcp_<Lo>TriggerTransmit (30)8.4.4Xcp_SetTransmissionMode (31)8.5Scheduled functions (32)8.5.1Xcp_MainFunction (32)8.6Expected Interfaces (32)8.6.1Mandatory Interfaces (32)8.6.2Optional Interfaces (33)8.6.3Configurable interfaces (33)9Sequence diagrams (35)9.1XCP on FlexRay (35)9.1.1Xcp on FlexRay Transmit (35)9.1.2Xcp on FlexRay Receive Indication (35)9.2XCP on CAN (36)9.2.1Xcp on CAN Transmit (36)9.2.2Xcp on CAN Transmit Confirmation (36)9.2.3Xcp on CAN Receive Indication (37)9.3XCP on Ethernet (38)9.3.1Xcp on Ethernet Receive Indication (38)10Configuration specification (39)10.1How to read this chapter (39)10.1.1Configuration and configuration parameters (39)10.1.2Variants (39)10.1.3Containers (40)10.1.4Specification template for configuration parameters (40)10.2Containers and configuration parameters (40)10.2.1Variants (41)10.2.2Xcp (42)10.2.3XcpGeneral (42)10.2.4XcpConfig (51)10.2.5XcpDaqList (52)10.2.6XcpDto (54)10.2.7XcpOdt (54)10.2.8XcpOdtEntry (55)10.2.9XcpDemEventParameterRefs (56)10.2.10XcpEventChannel (59)10.2.11XcpPdu (61)10.2.12XcpRxPdu (62)10.2.13XcpTxPdu (63)10.3Published Information (64)11Not applicable requirements (65)1 Introduction and functional overviewThis specification specifies the functionality, API and the configuration of the AUTOSAR Basic Software module XCPXCP is a protocol description (ASAM standard) between a master (tool) and a slave (device), which provides the following basic features:- Synchronous data acquisition (measurement)- Synchronous data stimulation (for rapid prototyping)- Online memory calibration (read / write access)- Calibration data page initialization and switching- Flash Programming for ECU development purposes- Every feature is optional and the access can be restricted- Various communications busses are supportedXCP was designed according to the following principles:- Minimal Slave resource consumption (RAM, ROM, runtime)- Efficient communication- Simple Slave implementation2 Acronyms and abbreviationsAcronym: Description:AUTOSAR AUT omotive O pen S ystem AR chitectureA2L File Extension for an ASAM 2MC Language FileASAM A ssociation for S tandardization of A utomation and M easuringSystemsBSW B asic S oft w areCAN C ontroller A rea N etworkCanIf CAN I nter f aceCTO C ommand T ransfer O bjectDAQ D ata A c Q uisition, Data AcQuisition PacketDTO D ata T ransfer O bjectECU E lectronic C ontrol U nitFrIf F lex R ay I nter f aceHIS H ersteller I nitiative S oftwareLPDU Data Link Layer PDUMCD M easurement C alibration and D iagnosticsMISRA M otor I ndustry S oftware R eliability A ssociationODT O bject D escriptor T ablePDU P rotocol D ata U nitRAM R andom A ccess M emoryROM R ead O nly M emorySchM Sch edule M anagerSVN S ub v ersio nSRS S oftware R equirements S pecificationSTIM DataStim ulation packetSW S oft w areSWS S oft w are S pecificationTCP/IP T ransfer C ontrol P rotocol /I nternet P rotocolTS T ime S tampUDP/IP U ser D atagram P rotocol /I nternet P rotocolURL U niform R esource L ocatorProtocolCalibrationXCP UniversalXML E x tensible M arkup L anguageISR I nterrupt S ervice R outineDEM D iagnostic E vent M anager (AUTOSAR BSW module)DET D evelopment E rror T racer (AUTOSAR BSW module)3 Related documentation3.1 Input documents[0] Basic Software Module Description TemplateAUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf [1] List of Basic Software ModulesAUTOSAR_TR_BSWModuleList.pdf[2] AUTOSAR Layered Software ArchitectureAUTOSAR_EXP_LayeredSoftwareArchitecture.pdf [3] General Requirements on Basic Software ModulesAUTOSAR_SRS_BSWGeneral.pdf[4] Specification of RTE (BSW Scheduler)AUTOSAR_SWS_RTE.pdf[5] Specification of ECU ConfigurationAUTOSAR_TPS_ECUConfiguration[6] Specification of Memory MappingAUTOSAR_SWS_MemoryMapping.pdf[7] Specification of FlexRay InterfaceAUTOSAR_SWS_FlexRayInterface.pdf[8] Specification of CAN InterfaceAUTOSAR_SWS_CANInterface[9] Specification of Socket AdaptorAUTOSAR_SWS_SocketAdaptor[10] Requirements on XCP ModuleAUTOSAR_SRS_XCP.pdf[11] AUTOSAR OS Specification:AUTOSAR_SWS_OS3.1.1 Related standards and norms[12] ASAM XCP – The Universal Measurement and Calibration Protocol/index.php?option=com_content&task=view&id=136&Itemid= 18[13] ASAM XCP – Transport Layer Specification XCP on CAN/index.php?option=com_content&task=view&id=136&Itemid= 18[14] ASAM XCP – Transport Layer Specification XCP on Ethernet/index.php?option=com_content&task=view&id=136&Itemid= 18[15] ASAM XCP – Transport Layer Specification XCP on FlexRay/index.php?option=com_content&task=view&id=136&Itemid= 184 Constraints and assumptions4.1 LimitationsThe following XCP features are currently out of scope:- The XCP feature “Flash Programming for ECU development purposes” is currently out of AUTOSAR scope!- The SET_DAQ_ID command according to the XCP CAN Transport Layer Specification is not part of the AUTOSAE XCP module”- Currently, the AUTOSAR RTE does not offer APIs for direct communication with XCP- For further details concerning the supported feature set, please refer to [12] Please note:For the communications bus LIN, no ASAM XCP is specified.4.2 Applicability to car domainsn/a5 Dependencies to other modulesThis section describes the relations to other modules and files within the AUTOSAR basic software architecture. It contains brief descriptions of configuration information and services, which are required by the XCP module from other modules.5.1 AUTOSAR RTE (BSW Scheduler)The BSW Scheduler calls the main functions of the Xcp, which are necessary for the cyclic processes of the Xcp.5.2 AUTOSAR FlexRay InterfaceThe FlexRay Interface is used to transmit and receive XCP PDUs via FlexRay.5.3 AUTOSAR CAN InterfaceThe CAN Interface is used to transmit and receive XCP PDUs via CAN.5.4 AUTOSAR SocketAdaptorThe SocketAdaptor is used to transmit and receive XCP PDUs via Ethernet.5.5 AUTOSAR RTEThe RTE is used for copying calibration parameters from ROM/FLASH to RAM andto use the double pointered method5.6 AUTOSAR OSIn order to be able to use the time stamped feature of XCP, an AUTOSAR OS Counter is used.5.7 AUTOSAR Diagnostic Event ManagerIn order to be able to report production errors, the XCP has to have access to the Diagnostic Event Manager.5.8 AUTOSAR Development Error TracerIn order to be able to report development errors, the XCP has to have access to the error hook of the Development Error Tracer.5.9 File structure5.9.1 Code file structure[Xcp501]⌈The code file structure shall not be defined within this specification completely. At this point it shall be pointed out that the code-file structure shall include the following files named:- Xcp.c – general source code file of the module XCP- Xcp_Cfg.c – for pre-compile time configurable parameters- Xcp_Lcfg.c – for link time configurable parameters and- Xcp_PBcfg.c – for post build time configurable parameters.⌋(BSW00380, BSW00419, BSW00383, BSW00346, BSW158)These files shall contain all link time and post-build time configurable parameters.[Xcp500]⌈The module XCP shall access the location of the API of all used modules for pre-compile time configuration by either using of external declaration in includes of the used modules’ public header files <x>.h or by the code file Xcp_Cfg.c.⌋()5.9.2 Header file structure[Xcp502] ⌈Figure 5-1: XCP Header File Structure⌋(BSW00381, BSW00412, BSW00409,BSW00301)The XCP module shall include the Dem.h file. By this inclusion, the APIs to report errors as well as the required Event Id symbols are included. This specification defines the name of the Event Id symbols, which are provided by XML to the DEM configuration tool. The DEM configuration tool assigns ECU dependent values to the Event Id symbols and publishes the symbols in Dem_IntErrId.h.[Xcp503] ⌈All files related to the XCP module shall follow the naming conventionXcp[_<description>].<extension>⌋(BSW00300)[Xcp505]⌈The implementation of the XCP module shall provide the header file Xcp.h, which is the main module interface file. It shall contain all types and function prototypes required by the XCP module’s environment.⌋(BSW00302)[Xcp506]⌈The implementation of the XCP on CAN module shall provide the header file XcpOnCan_Cfg.h that shall contain the pre-compile-time configuration parameters.⌋()[Xcp507] ⌈The implementation of the XCP on FlexRay module shall provide the header file XcpOnFr_Cfg.h that shall contain the pre-compile-time configuration parameters.⌋()[Xcp508] ⌈The implementation of the XCP on Ethernet module shall provide the header file XcpOnEth_Cfg.h that shall contain the pre-compile-time configuration parameters.⌋()[Xcp509] ⌈The module shall include the Dem.h file.⌋()By this inclusion, the APIs to report errors as well as the required Event Id symbols are included. This specification defines the name of the Event Id symbols which are provided by XML to the DEM configuration tool. The DEM configuration tool assigns ECU dependent values to the Event Id symbols and publishes the symbols in Dem_IntErrId.h.6 Requirements traceability6.1 General Requirements on Basic Software ModulesRequirement Satisfied by BSW00344 Reference to link-time configuration Xcp741 BSW00404 Reference to post build time configuration Xcp742 BSW00405 Reference to multiple configuration sets Xcp803 BSW00345 Pre-compile-time configuration Xcp742 BSW159 Tool-based configuration Xcp102 BSW167 Static configuration checking Xcp103Xcp104Xcp105 BSW171 Configurability of optional functionality n/aBSW170 Data for reconfiguration of AUTOSAR SW-Components n/aBSW00380 Separate C-Files for configuration parameters Xcp501 BSW00419 Separate C-Files for pre-compile time configuration parameters Xcp501 BSW00381 Separate configuration header file for pre-compile time parameters Xcp502 BSW00412 Separate H-File for configuration parameters Xcp502 BSW00383 List dependencies of configuration files Xcp501 BSW00384 List dependencies to other modules Chapter 5 BSW00387 Specify the configuration class of callback function n/aBSW00388 Introduce containers Xcp101 BSW00389 Containers shall have names Chapter 10.2 BSW00390 Parameter content shall be unique within the module Chapter 10.2 BSW00391 Parameter shall have unique names Chapter 10.2 BSW00392 Parameters shall have a type Chapter 10.2 BSW00393 Parameters shall have a range Chapter 10.2 BSW00394 Specify the scope of the parameters Chapter 10.2 BSW00395 List the required parameters (per parameter) Chapter 10.2 BSW00396 Configuration classes Chapter 10.2 BSW00397 Pre-compile-time parameters Chapter 10.2 BSW00398 Link-time parameters Chapter 10.2 BSW00399 Loadable Post-build time parameters Chapter 10.2 BSW00400 Selectable Post-build time parameters Chapter 10.2 BSW00402 Published information Xcp807 BSW00375 Notification of wake-up reason n/aBSW101 Initialization interface Xcp803 BSW00416 Sequence of Initialization n/aBSW00406 Check module initialization Xcp811 BSW168 Diagnostic Interface of SW components n/aBSW00407 Function to read out published parameters Xcp807n/a BSW00423 Usage of SW-C template to describe BSW modules with AUTOSARInterfacesBSW00424 BSW main processing function task allocation Xcp823 BSW00425 Trigger conditions for schedulable objects n/aBSW00426 Exclusive areas in BSW modules n/aBSW00427 ISR description for BSW modules n/aBSW00428 Execution order dependencies of main processing functions n/aBSW00429 Restricted BSW OS functionality access Chapter 5.6 BSW00431 The BSW Scheduler module implements task bodies n/an/a BSW00432 Modules should have separate main processing functions forread/receive and write/transmit data pathBSW00433 Calling of main processing functions Xcp823 BSW00434 The Schedule Module shall provide an API for exclusive areas n/aBSW00336 Shutdown interface n/aBSW00337 Classification of errors Errorclassification BSW00338 Detection and Reporting of development errors Chapter 7.6Chapter 7.7 BSW00369 Do not return development error codes via API Chapter BSW00339 Reporting of production relevant error status Chapter BSW00417 Reporting of Error Events by Non-Basic Software n/aBSW00323 API parameter checking Chapter 8.3 BSW004 Version check Xcp749BSW00409 Header files for production code error IDs Xcp502BSW00385 List possible error notifications Chapter 7.5 BSW00386 Configuration for detecting an error Xcp754BSW161 Microcontroller abstraction n/aBSW162 ECU layout abstraction n/aBSW005 No hard coded horizontal interfaces within MCAL n/aBSW00415 User dependent include files n/aBSW164 Implementation of interrupt service routines n/aBSW00325 Runtime of interrupt service routines n/aBSW00326 Transition from ISRs to OS tasks n/aBSW00342 Usage of source code and object code Chapter 10.2.1 BSW00343 Specification and configuration of time Chapter 10.2 BSW160 Human-readable configuration data Xcp744BSW007 HIS MISRA C Xcp745BSW00300 Module naming convention Xcp503BSW00413 Accessing instances of BSW modules n/aBSW00347 Naming separation of different instances of BSW drivers n/aBSW00305 Self-defined data types naming convention Chapter 8.2 BSW00307 Global variables naming convention Xcp800BSW00310 API naming convention Xcp800BSW00373 Main processing function naming convention Xcp823BSW00327 Error values naming convention Xcp763BSW00335 Status values naming convention n/aBSW00350 Development error detection keyword Xcp753BSW00408 Configuration parameter naming convention Xcp800BSW00410 Compiler switches shall have defined values n/aBSW00411 Get version info keyword Xcp807Xcp808Xcp809Xcp810BSW00346 Basic set of module files Xcp501BSW158 Separation of configuration from implementation Xcp501BSW00314 Separation of interrupt frames and service routines n/aBSW00370 Separation of callback interface from API n/aBSW00348 Standard type header Chapter 5.9 BSW00353 Platform specific type header Chapter 5.9 BSW00361 Compiler specific language extension header Chapter 5.9 BSW00301 Limit imported information Xcp502BSW00302 Limit exported information Xcp505BSW00328 Avoid duplication of code n/aBSW00312 Shared code shall be reentrant n/aBSW006 Platform independency n/aBSW00357 Standard API return type Chapter 8.3 BSW00377 Module specific API return types n/aBSW00304 AUTOSAR integer data types Chapter 8.3 BSW00355 Do not redefine AUTOSAR integer data types Chapter 8.3 BSW00378 AUTOSAR boolean type Chapter 8.3 BSW00306 Avoid direct use of compiler and platform specific keywords n/aBSW00308 Definition of global data Xcp760BSW00309 Global data with read-only constraint n/aBSW00371 Do not pass function pointers via API n/aBSW00358 Return type of init() functions Xcp803BSW00414 Parameter of init function Xcp803BSW00376 Return type and parameters of main processing functions Chapter 8.5 BSW00359 Return type of callback functions Chapter 8.4 BSW00360 Parameters of callback functions n/aBSW00329 Avoidance of generic interfaces n/aBSW00330 Usage of macros / inline functions instead of functions n/aBSW00331 Separation of error and status values n/aBSW009 Module User Documentation n/aBSW00401 Documentation of multiple instances of configuration parameters n/aBSW172 Compatibility and documentation of scheduling strategy n/aBSW010 Memory resource documentation n/aBSW00333 Documentation of callback function context n/aBSW00374 Module vendor identification Xcp807BSW00379 Module identification Xcp807BSW003 Version identification Xcp807BSW00318 Format of module version numbers Xcp807BSW00321 Enumeration of module version numbers n/aBSW00341 Microcontroller compatibility documentation n/aBSW00334 Provision of XML file Xcp751BSW00435 Header File Structure for the Basic Software Scheduler Xcp747BSW00436 Module Header File Structure for the Memory Mapping Xcp7486.2 Requirements on the XCP Basic Software ModuleRequirement Satisfied by BSW429001 Location of XCP within the architecture Xcp701BSW429002 API usage Xcp712, Xcp714,Xcp720, Xcp734 BSW429003 Unique PDU-ID Xcp702BSW429004 XCP Specification Version 1.1 Xcp703BSW429005 XCP on CAN Xcp713BSW429006 XCP on FlexRay Xcp719BSW429007 XCP on Ethernet Xcp733BSW429008 A2L Support n/aBSW429009 Synchronous data acquisition Xcp705BSW429010 Synchronous data stimulation Xcp707BSW429011 Block communication mode Xcp711BSW429012 Interleaved communication mode Xcp710BSW429013 Dynamic data transfer configuration Xcp706BSW429014 Timestamped Data transfer Xcp709BSW429015 Bypassing Xcp761BSW429016 Seed & Key Xcp766BSW429017 XCP Initialization Xcp8037 Functional specificationThe specification of the module XCP shall define all parameters and interfaces, which are required to use the ASAM XCP protocol specification within an AUTOSAR environment.Description:Black arrows: Data Path (Signals/Pdus)Orange arrows: Control Path (FlexRay Interface)[Xcp701]⌈The AUTOSAR XCP Module be located above the bus specific Interfaces in case of FlexRay and Can. In case of Ethernet, the AUTOSAR XCP module shall be located above the Socket Adaptor.⌋(BSW429001)[Xcp702]⌈For transmitting and receiving of XCP messages, unique PDU-IDs shall be used. ⌋(BSW429003)[Xcp703]⌈The AUTOSAR XCP Module shall support the ASAM XCP Specification Version 1.1.⌋(BSW429004)[Xcp705]⌈The AUTOSAR XCP Module shall support the basic feature “Synchronous data acquisition (measurement) “. Please refer to [13]⌋(BSW429009)[Xcp706]⌈The AUTOSAR XCP Module shall support the feature “Dynamic DAQ Configuration”. according to [13]⌋(BSW429013)[Xcp707]⌈The AUTOSAR XCP Module shall support the basic feature “Synchronous data stimulation” according to [13]⌋(BSW429010)[Xcp708]⌈The AUTOSAR XCP Module shall support the basic feature “Online memory calibration (read / write access) “, according to [13]⌋()[Xcp709]⌈The AUTOSAR XCP Module shall support the feature “Timestamped Data Transfer“, according to [13]⌋(BSW429014)[XCP 768]⌈The ECU local time shall be derived from the AUTOSAR OS.⌋()[Xcp711]⌈The AUTOSAR XCP Module shall support the feature “Block communication mode“, according to [13]⌋(BSW42911)[Xcp761]⌈The AUTOSAR XCP Module shall support the feature “Bypassing“, according to [13]⌋(BSW429015)[Xcp766]⌈The AUTOSAR XCP Module shall support the feature “Seed & Key” according to [13]⌋(BSW429016)[Xcp712]⌈For sending and receiving of calibration data, the sending and receiving APIs specified within the AUTOSAR BSW Bus Interfaces (FlexRay Interface, CAN Interface, TCP/IP Socket Adaptor) shall be used. Please refer to chapter 7.1, 7.2 and 7.3.⌋(BSW429002)7.1 XCP on CAN[Xcp713]⌈The AUTOSAR XCP Module shall support the CAN communications bus according to [14]⌋(BSW429005)[Xcp714]⌈XCP data sent and received via CAN, the PDUs have to be transmitted and received using the transmitting and receive APIs provided by the AUTOSAR CAN Interface, according to [9]⌋(BSW429002)[Xcp715]⌈For sending and receiving XCP data via CAN, at least two different CAN identifiers have to be configured to be used by XCP.⌋()[Xcp716]⌈Performance information shall be exchanged between the XCP master and XCP slave using the parameters according to [14]⌋()[Xcp718]⌈The XCP Module shall support the GET_SLAVE_ID command according to [14]⌋()7.2 XCP on FlexRay[Xcp719]⌈The AUTOSAR XCP Module shall support the FlexRay communications bus according to [16]⌋(BSW429006)[Xcp720]⌈XCP data sent and received via FlexRay, the PDUs have to be transmitted and received using the transmit and receive APIs provided by the AUTOSAR FlexRay Interface according to [8].⌋(BSW429002)[Xcp721]⌈All XCP on FlexRay LPDUs always are event driven. Please refer to Chapter 1.1.2 “FlexRay Frame Type” of [16]⌋()[Xcp722]⌈The hardware buffers (of the FlexRay Communication Controller) XCP uses for data transmission and reception are assigned exclusively to the XCP module.⌋()Note:This restriction prevents disturbances of ongoing FlexRay communication.[Xcp723]⌈The usage of FlexRay Communication Controller’s hardware buffers shall be configured by the corresponding parameters according to [16]⌋()[Xcp724]⌈The FlexRay PDU length used by the AUTOSAR XCP module shall be set using the corresponding parameters according to [16]⌋()[Xcp725]⌈LPDU_IDs which shall be routed to the AUTOSAR XCP module (using the AUTOSAR Bus Interface) have to be defined by the system designer. ⌋()[Xcp726]⌈The ASAM MCD 2MC description file (i.e. A2L file) describes to which extent the XCP-dedicated buffers of a specific slave can be configured for XCP communication.⌋()[Xcp728]⌈The XCP master gets the information about the XCP dedicated FlexRay Communication Controller buffers from the ASAM MCD 2MC description file. ⌋()[Xcp729]⌈Limitations due to the usage of multiple XCP slaves on the FlexRay communications bus shall be taken into consideration by the system designer. Please refer to [16].⌋()[Xcp730]⌈Depending upon the requirements on sequencing correctness, alignment and net data throughput, different header types are possible. Please refer to Chapter 1.4.1 ”Header” of [16]⌋()[Xcp731]⌈For XCP on FlexRay, the Tail consists of a Control Field containing optional FILL bytes according to [16].⌋()[Xcp732]⌈The AUTOSAR XCP module shall be able to pack multiple XCP messages into one FlexRay Frame according to [16].⌋()7.3 XCP on Ethernet[Xcp733]⌈The AUTOSAR XCP Module shall support the Ethernet communications bus according to [15]⌋(BSW429007)[Xcp734]⌈XCP data sent and received via Ethernet, the PDUs have to be transmitted and received using the transmitting and receive APIs provided by the AUTOSAR Socket Adaptor according to [10].⌋(BSW429002)[Xcp735]⌈The AUTOSAR XCP slave connected by Ethernet and TCP/IP or UDP/IP is addressed by its IP Address and Port number.⌋()[Xcp736]⌈The AUTOSAR XCP slave only accepts one connection at the time. ⌋()[Xcp737]⌈If the socket is closed while in XCP connected state, the slave device will perform an XCP disconnect, which means that all data acquisition will be stopped.⌋()[Xcp738]⌈The addressing scheme is defined according to [15]⌋().[Xcp739]⌈The header and tail of an XCP on Ethernet message have to be set according to [15]⌋()[Xcp740]⌈The upper performance limit depends on the protocol stack of the host system. The corresponding parameters defined according to [15] have to be set.⌋()[Xcp710]⌈The AUTOSAR XCP Module shall support the feature “Interleaved communication mode“, according to according to [15]⌋(BSW429012)7.4 Requirements on Debugging[Xcp760]⌈Each variable that shall be accessible by AUTOSAR Debugging, shall bedefined as global variable.⌋(BSW00308)[Xcp759]⌈All type definitions of variables which shall be debugged, shall be accessible by the header file Xcp.h⌋()[Xcp762]⌈The declaration of variables in the header file shall be such that it is possible to calculate the size of the variables by C-"sizeof".⌋()[Xcp765]⌈Variables available for debugging shall be described in the respectiveBasic Software Module Description.⌋()[Xcp764]⌈The internal XCP states shall be available for debugging.⌋()In general, it is not necessary/intended for AUTOSAR debugging, that SWS documents define specific variables.7.4.1 General Requirements[Xcp741]⌈Link-time and post-build-time configuration data shall be implemented as read-only data structures. Link-time configuration data shall be immediately referenced by the implementation, the start-address of post-build-time configuration data shall be passed during module initialization⌋(BSW00344)[Xcp742]⌈The XCP module shall support pre-compile time, link-time and post-build-time configuration.⌋(BSW00404, BSW00345)[Xcp744]⌈The description of the configuration and initialization data itself is not part of this specification but very implementation specific. The generated configuration data should be “human-readable”.⌋(BSW160)。
Marvell.Moving Forward FasterDoc. No. MV-S105539-00, Rev. --May 9, 2011Document Classification: Proprietary InformationAlaska ® 88E1116RTechnical Product BriefGigabit Ethernet TransceiverAlaska® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDocument ConventionsNote: Provides related information or information of special importance.Caution: Indicates potential damage to hardware or software, or loss of data.Warning: Indicates a risk of personal injury.Document StatusDoc Status: Advance Technical Publications: 1.00For more information, visit our website at: DisclaimerNo part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose, without the express written permission of Marvell. Marvell retains the right to make changes to this document at any time, without notice. Marvell makes no warranty of any kind, expressed or implied, with regard to any information contained in this document, including, but not limited to, the implied warranties of merchantability or fitness for any particular purpose. Further, Marvell does not warrant the accuracy or completeness of the information, text, graphics, or other items contained within this document.Marvell products are not designed for use in life-support equipment or applications that would cause a life-threatening situation if any such products failed. Do not use Marvell products in these types of equipment or applications.With respect to the products described herein, the user or recipient, in the absence of appropriate U.S. government authorization, agrees:1) Not to re-export or release any such information consisting of technology, software or source code controlled for national security reasons by the U.S. Export Control Regulations ("EAR"), to a national of EAR Country Groups D:1 or E:2;2) Not to export the direct product of such technology or such software, to EAR Country Groups D:1 or E:2, if such technology or software and direct products thereof are controlled for national security reasons by the EAR; and,3) In the case of technology controlled for national security reasons under the EAR where the direct product of the technology is a complete plant or component of a plant,not to export to EAR Country Groups D:1 or E:2 the direct product of the plant or major component thereof, if such direct product is controlled for national security reasonsby the EAR, or is subject to controls under the U.S. Munitions List ("USML").At all times hereunder, the recipient of any such information agrees that they shall be deemed to have manually signed this document in connection with their receipt of any such information.Copyright © 1999–2011. Marvell International Ltd. All rights reserved. Marvell, Moving Forward Faster, the Marvell logo, Alaska, AnyVoltage, DSP Switcher, Fastwriter, Feroceon, Libertas, Link Street, PHYAdvantage, Prestera, TopDog, Virtual Cable Tester, Yukon, and ZJ are registered trademarks of Marvell or its affiliates. CarrierSpan, LinkCrypt, Powered by Marvell Green PFC, Qdeo, QuietVideo, Sheeva, TwinD, and VCT are trademarks of Marvell or its affiliates.Patent(s) Pending—Products identified in this document may be covered by one or more Marvell patents and/or patent applications.Doc. No. MV-S105539-00 Rev. -- Copyright © 2011 Marvell Page 2Document Classification: Proprietary Information May 9, 2011, AdvanceAlaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverCopyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 3O VERVIEWThe Alaska ® 88E1116R Gigabit Ethernet Transceiver is a physical layer device containing a single Gigabit Ethernet transceiver. The transceiver implements the Ethernet physical layer portion of the 1000BASE-T, 100BASE-TX, and 10BASE-T standards. It is manu-factured using standard digital CMOS process and contains all the active circuitry required to implement the physical layer functions to transmit and receive data on standard CAT 5 unshielded twisted pair.The 88E1116R device supports the RGMII (Reduced pin count GMII) for direct connection to a MAC/Switch port.The 88E1116R device integrates MDI interface termi-nation resistors into the PHY . This resistor integration simplifies board layout and reduces board cost by reducing the number of external components. The new Marvell ® calibrated resistor scheme will achieve and exceed the accuracy requirements of the IEEE 802.3 return loss specifications.The 88E1116R device can run off a single 1.8V, 2.5V, or 3.3V supply. Alternatively if the regulators are not used then the 88E1116R device can run off 1.8V and1.2V supply.The 88E1116R device has two regulators to generate all required voltages. The 88E1116R device supports 1.8V, 2.5V, and 3.3V HSTL/SSTL and 2.5V LVCMOS I/O StandardsThe 88E1116R device incorporates the Marvell® Vir-tual Cable Tester ® (VCT™) feature, which uses Time Domain Reflectometry (TDR) technology for the remote identification of potential cable malfunctions, thus reducing equipment returns and service calls. Using VCT, the Alaska 88E1116R device detects and reports potential cabling issues such as pair swaps, pair polarity and excessive pair skew. The device will also detect cable opens, shorts or any impedance mis-match in the cable and reporting accurately within one meter the distance to the fault.The 88E1116R device uses advanced mixed-signal processing to perform equalization, echo and crosstalkcancellation, data recovery, and error correction at a gigabit per second data rate. The device achieves robust performance in noisy environments with very low power dissipation.F EATURES•10/100/1000BASE-T IEEE 802.3 compliant •Four RGMII timing modes - This eliminates the need for adding trace delays on the PCB•Supports LVCMOS, SSTL, and HSTL I/O Stan-dards on the RGMII interface•Integrated MDI interface termination resistors that eliminate twelve passive components•Energy Detect and Energy Detect+ low power modes•Three loopback modes for diagnostics•“Downshift” mode for two-pair cable installations •Fully integrated digital adaptive equalizers, echo cancellers, and crosstalk cancellers•Advanced digital baseline wander correction •Automatic MDI/MDIX crossover at all speeds of operation•Automatic polarity correction•IEEE 802.3u compliant Auto-Negotiation•Software programmable LED modes including LED testing•Supports IEEE 1149.1 JTAG•MDC/MDIO Management Interface •CRC checker, packet counter •Packet generation•Virtual Cable Tester (VCT)•Auto-Calibration for MAC Interface outputs •Coma Mode support•Requires a single 1.8V supply•I/O pads can be supplied with 1.8V, 2.5V, or 3.3V •Two regulators generate all required voltages. Regulator can be supplied with 1.8V, 2.5V or 3.3V.•Commercial grade •64-Pin QFN package88E1116R Device used in Copper ApplicationAlaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 MarvellPage 4Document Classification: Proprietary InformationMay 9, 2011, AdvanceTable of ContentsS ECTION 1.S IGNAL D ESCRIPTION (5)1.1Pin Description...............................................................................................................61.1.1Pin Type Definitions (6)1.264-Pin QFN Pin Assignment List - Alphabetical by Signal Name (13)S ECTION 2.P ACKAGE M ECHANICAL D IMENSIONS (14)2.164-Pin QFN Package (14)Copyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 5Signal DescriptionSection 1. Signal DescriptionThe 88E1116R device is a 10/100/1000BASE-T Gigabit Ethernet transceiver.Figure 1:88E1116R Device 64-Pin QFN Package (Top View)34567891011121314Top ViewC O N F I G [3]C O M A n L ED [0]V D D OL E D [1]L E D [2]R E S E T nA V D D RD V D DD I S _RE G 12D V D D88E1116RT R S T nAlaska ®88E1116R Technical Product Brief Gigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 Marvell Page 6Document Classification: Proprietary InformationMay 9, 2011, Advance1.1Pin Description1.1.1Pin Type DefinitionsPin TypeDefinitionH Input with hysteresis I/O Input and output I Input only O Output only PU Internal pull up PD Internal pull down D Open drain output Z Tri-state output mADC sink capabilityCopyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 7Signal DescriptionPin DescriptionTable 1:Media Dependent Interface 64-QFN Pin #Pin NamePin TypeDescription3031MDIN[0]MDIP[0]I/O, DMedia Dependent Interface[0].In 1000BASE-T mode in MDI configuration, MDIN/P[0] correspond to BI_DA±. In MDIX configuration, MDIN/P[0] correspond to BI_DB±.In 100BASE-TX and 10BASE-T modes in MDI configuration, MDIN/P[0] are used for the transmit pair. In MDIX configuration, MDIN/P[0] are used for the receive pair.“The unused MDI pins cannot be connected to ground. They need to be left floating, because they have internal bias.The 88E1116R device contains an internal 100 ohm resistor between the MDIP/N[0] pins.2526MDIN[1]MDIP[1]I/O, D Media Dependent Interface[1].In 1000BASE-T mode in MDI configuration, MDIN/P[1] correspond to BI_DB±. In MDIX configuration, MDIN/P[1] correspond to BI_DA±.In 100BASE-TX and 10BASE-T modes in MDI configuration, MDIN/P[1] are used for the receive pair. In MDIX configuration, MDIN/P[1] are used for the transmit pair.“The unused MDI pins cannot be connected to ground. They need to be left floating, because they have internal bias.The 88E1116R device contains an internal 100 ohm resistor between the MDIP/N[0] pins.2324MDIN[2]MDIP[2]I/O, D Media Dependent Interface[2].In 1000BASE-T mode in MDI configuration, MDIN/P[2] correspond to BI_DC±. In MDIX configuration, MDIN/P[2] corresponds to BI_DD±. In 100BASE-TX and 10BASE-T modes, MDIN/P[2] are not used.“The unused MDI pins cannot be connected to ground. They need to be left floating, because they have internal bias.The 88E1116R device contains an internal 100 ohm resistor between the MDIP/N[0] pins.1920MDIN[3]MDIP[3]I/O, D Media Dependent Interface[3].In 1000BASE-T mode in MDI configuration, MDIN/P[3] correspond to BI_DD±. In MDIX configuration, MDIN/P[3] correspond to BI_DC±.In 100BASE-TX and 10BASE-T modes, MDIN/P[3] are not used.“The unused MDI pins cannot be connected to ground. They need to be left floating, because they have internal bias.The 88E1116R device contains an internal 100 ohm resistor between the MDIP/N[0] pins.Alaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 Marvell Page 8Document Classification: Proprietary InformationMay 9, 2011, AdvanceThe RGMII interface supports 10/100/1000BASE-T mode of operation.Table 2:RGMII Interface 64-QFN Pin #Pin NamePin TypeDescription60TX_CLK I RGMII Transmit Clock provides a 125 MHz, 25 MHz, or 2.5 MHz reference clock with ± 50 ppm tolerance depending on speed.63TX_CTRLIRGMII Transmit Control. TX_EN is presented on the rising edge of TX_CLK. A logical derivative of TX_EN and TX_ER is presented on the falling edge of TX_CLK.62615958TXD[3]TXD[2]TXD[1]TXD[0]IRGMII Transmit Data.TXD[3:0] run at double data rate with bits [3:0] presented on the rising edge of TX_CLK, and bits [7:4] presented on the falling edge of TX_CLK.In 10/100BASE-T modes, the transmit data nibble is presented on TXD[3:0] on the rising edge of TX_CLK.53RX_CLK ORGMII Receive Clock provides a 125 MHz, 25 MHz, or 2.5 MHz reference clock with ± 50 ppm tolerance derived from the received data stream depending on speed.49RX_CTRL ORGMII Receive Control. RX_DV is presented on the rising edge of RX_CLK.A logical derivative of RX_DV and RX_ER is presented on the falling edge of RX_CLK.55545150RXD[3]RXD[2]RXD[1]RXD[0]ORGMII Receive Data. RXD[3:0] run at double data rate with bits [3:0] presented on the rising edge of RX_CLK, and bits [7:4] presented on the falling edge of RX_CLK.In 10/100BASE-T modes, the receive data nibble is presented on RXD[3:0] on the rising edge of RX_CLK.Copyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 9Signal DescriptionPin DescriptionTable 3:Management Interface and Interrupt 64-QFN Pin #Pin NamePin TypeDescription48MDCIMDC is the management data clock reference for the serial management interface. A continuous clock stream is not expected. The maximum fre-quency supported is 8.3 MHz.45MDIO I/OMDIO is the management data. MDIO transfers management data in and out of the device synchronously to MDC. This pin requires a pull-up resistor in a range from 1.5 kohm to 10 kohm.Table 4:LED Interface 64-QFN Pin #Pin NamePin TypeDescription689LED[0]LED[1]LED[2]OLED/Interrupt outputs.Table 5:JTAG Interface 64-QFN Pin #Pin NamePin TypeDescription43TDI I Boundary scan test data input.41TMS I, PU Boundary scan test mode select input.TMS contains an internal 150 kohm pull-up resistor. 42TCK I, PU Boundary scan test clock input.TCK contains an internal 150 kohm pull-up resistor.11TRSTnI, PUBoundary scan test reset input. Active low. TRSTn contains an internal 150 kohm pull-up resistor as per the 1149.1 specification. After power up, the JTAG state machine should be reset by applying a low signal on this pin, or by keeping TMS high and applying 5 TCK pulses, or by pulling this pin low by a 4.7 kohm resistor.44TDO OBoundary scan test data output.Alaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 Marvell Page 10Document Classification: Proprietary InformationMay 9, 2011, AdvanceTable 6:Clock/Configuration/Reset/I/O 64-QFN Pin #Pin NamePin TypeDescription64CONFIG[0]I Hardware Configuration 1CONFIG[1]I Hardware Configuration 2CONFIG[2]I Hardware Configuration 3CONFIG[3]I Hardware Configuration38XTAL_INIReference Clock. 25 MHz ± 50 ppm tolerance crystal reference or oscillator input.NOTE: If AVDDC is tied to 1.8V, then the XTAL_IN pin is not 2.5V/3.3V tolerant.If AVDDC is tied to 2.5V, then the XTAL_IN pin is not 3.3V tolerant.39XTAL_OUT 0Reference Clock. 25 MHz ± 50 ppm tolerance crystal reference. When the XTAL_OUT pin is not connected, it should be left floating.10RESETnIHardware reset. Active low.0 = Reset 1 = Normal57VREF IRGMII input voltage reference.Must be set to VDDOR/2 when used as 1.8V HSTL, 2.5V SSTL_2, and 3.3V. Set to VDDOR when used as 2.5V LV CMOS.Copyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 11Signal DescriptionPin DescriptionTable 7:Test 64-QFN Pin #Pin NamePin TypeDescription3536HSDACN HSDACPO OAC Test Point. Positive and Negative.These pins are also used to bring out a differential TX_TCLK. Connect these pins with a 50 ohm termination resistor to VSS for IEEE testing and debug purposes. If debug and IEEE testing are not of importance, these pins can be left floating.32TSTPT OTest Point.Table 8:Control and Reference 64-QFN Pin #Pin NamePin TypeDescription33RSET I Constant voltage reference. External 4.99 kohm 1% resistor connection to VSS required for each pin.17CTRL18O 1.8V Regulator Control. This signal ties to the base of the BJT. If the 1.8V regulator is not used it can be left floating.12DIS_REG12I1.2V Regulator Disable. Tie to VDDO to disable, tie to VSS to enable.Alaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 Marvell Page 12Document Classification: Proprietary InformationMay 9, 2011, AdvanceTable 9:Power & Ground 64-QFN Pin #Pin NamePin TypeDescription21222729AVDDPowerAnalog supply. 1.8V 1. AVDD can be supplied externally with 1.8V, or via the 1.8V regulator.1. AVDD supplies the MDIP/N[3:0] pins.3437AVDDCAnalog supply - 1.8V or 2.5V, or 3.3V 2.AVDDC must be supplied externally. Do not use the 1.8V regulator to power AVDDC.2. AVDDC supplies the XTAL_IN and XTAL_OUT pins.1415AVDDR1.2V Regulator supply - 1.8VAVDDR can be supplied externally with 1.8V, or via the 1.8V regulator. If the 1.2V regulator is not used, AVDDR must still be tied to 1.8V.16AVDDXPower1.8V Regulator supply -2.5V,3.3V, (or 1.8V).AVDDX must be supplied externally. Note that this supply must be the same voltage as AVDDC.If the 1.8V regulator is not used, then it means a 1.8V supply is in the sys-tem. AVDDX (along with AVDDC) would be tied to 1.8V in this case.5134047DVDD PowerDigital core supply - 1.2V.DVDD can be supplied externally with 1.2V, or via the 1.2V regulator.746VDDO Power1.8V,2.5V, or3.3V non-RGMII digital I/O supply 3.VDDO must be supplied externally. Do not use the 1.8V regulator to power VDDO.3. VDDO supplies the MDC, MDIO, RESETn, LED[2:0], CONFIG[3:0], TDI, TMS, TCK, TRSTn, TDO, DIS_REG12, CTRL18, HSDAC, and TSTPT5256VDDOR Power1.8V,2.5V, or3.3V RGMII digital I/O supply4.VDDOR must be supplied externally. Do not use the 1.8V regulator to power VDDOR.4. VDDOR supplies the TXD[3:0], TX_CLK, TX_CTRL, RXD[3:0], RX_CLK, and RX_CTRL pins.EPADVSS GNDGround to device. The 64-pin QFN package has an exposed die pad (E-PAD) at its base. This E-PAD must be soldered to VSS.Refer to the package mechanical drawings for the exact location and dimen-sions of the EPAD.182855. Pin 28 must be connected to AVDD in Revision A0. Refer to the Rev A0 Release Notes for Pin 28 connection details.NC NCNo connect. These pins are not connected to the die so they can be con-nected to anything on the board.Copyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, AdvanceDocument Classification: Proprietary InformationPage 13Signal Description64-Pin QFN Pin Assignment List - Alphabetical by Signal Name1.264-Pin QFN Pin Assignment List - Alphabetical by Sig-nal NamePin #Pin NamePin #Pin Name21AVDD 24MDIP[2]22AVDD 20MDIP[3]27AVDD 18NC 29AVDD 28NC 34AVDDC 53RX_CLK 37AVDDC 49RX_CTRL 14AVDDR 10RESETn 15AVDDR 33RSET 16AVDDX 50RXD[0]4COMAn 51RXD[1]64CONFIG[0]54RXD[2]1CONFIG[1]55RXD[3]2CONFIG[2]42TCK 3CONFIG[3]43TDI 17CTRL1844TDO 12DIS_REG1241TMS 5DVDD 11TRSTn 13DVDD 60TX_CLK 40DVDD 63TX_CTRL 47DVDD 58TXD[0]35HSDACN 59TXD[1]36HSDACP 61TXD[2]6LED[0]62TXD[3]8LED[1]32TSTPT 9LED[2]7VDDO 48MDC 46VDDO 30MDIN[0]52VDDOR 25MDIN[1]56VDDOR 23MDIN[2]57VREF 19MDIN[3]EPAD VSS 45MDIO 38XTAL_IN 31MDIP[0]39XTAL_OUT26MDIP[1]Alaska ® 88E1116R Technical Product BriefGigabit Ethernet TransceiverDoc. No. MV-S105539-00, Rev. -- Copyright © 2011 MarvellPage 14Document Classification: Proprietary InformationMay 9, 2011, AdvanceSection 2. Package Mechanical Dimensions2.164-Pin QFN PackagePackage Mechanical Dimensions64-Pin QFN PackageTable 10:64-Pin QFN Mechanical DimensionsDimensions in mmSymbol MIN NOM MAXA0.800.85 1.00A10.000.020.05A2--0.65 1.00A30.20 REFb0.180.230.30D9.00 BSCD18.75 BSCE9.00 BSCE18.75 BSCe0.50 BSCL0.300.400.50θ0°--12°aaa----0.25bbb----0.10chamfer----0.60Die Pad SizeSymbol Dimension in mmD2 5.21 ± 0.20E2 6.25 ± 0.20Copyright © 2011 Marvell Doc. No. MV-S105539-00, Rev. --May 9, 2011, Advance Document Classification: Proprietary Information Page 15Marvell. Moving Forward FasterMarvell Semiconductor, Inc.5488 Marvell LaneSanta Clara, CA 95054, USATel: 1.408.222.2500Fax: 。
