3 PRESENTATION OF THE TECHNOLOGIES .............................................................................................6
3.1 OPEN CORE PROTOCOL ........................................................................................................................................................... 6 3.2 SPIRIT IP-XACT...................................................................................................................................................................... 7
4 OVERVIEW OF THE ACTIVITY .....................................................................................................................7
4.1 GROUP A - OCP DESIGN ......................................................................................................................................................... 7 4.2 GROUP B - SPIRIT IP-XACT.................................................................................................................................................. 8 4.3 DEVELOPMENT FLOW............................................................................................................................................................... 8
5.1 SELECTION OF OCP SOCKETS............................................................................................................................................... 10 5.1.1 Introduction to OCP Configurability........................................................................................................................................ 10 5.1.2 Requirements for the Sockets to select........................................................................................................................................ 10 5.1.3 OCP Socket close to AHB: “H-Socket” ................................................................................................................................. 11
5.1.5 Comparison between AMBA and the OCP Sockets selected..................................................................................................... 16 5.2 DEVELOPMENT OF SPACEWIRE-OCP .................................................................................................................................. 17
5.2.1 Design .................................................................................................................................................................................... 17 5.2.1.1 Performance Comparison with Spacewire-AMBA.................................................................................................................... 18
5.2.3 Synthesis ................................................................................................................................................................................. 20 5.3 DEVELOPMENT OF LEON2FT-OCP................................................................................................................................... 22
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
5.3.1 The LEON processor ............................................................................................................................................................. 22 5.3.2 Design .................................................................................................................................................................................... 23
5.3.2.1 Performance Comparison with LEON2FT-AMBA ................................................................................................................. 27 5.3.3 Verification............................................................................................................................................................................. 27
6.2.5 Verification of the Generators .................................................................................................................................................. 43 6.3 LEON2FT IP-XACT PACKAGING ....................................................................................................................................... 43
6.3.1 Analysis and Specification ....................................................................................................................................................... 45 6.3.2 Development of the Descriptions and Generator ........................................................................................................................ 45 6.3.3 IP-XACT Component Descriptions ........................................................................................................................................ 45
Table 4 : Concise parameter list for the P-Socket..................................................................................................16
Table 5 : IP-XACT Components of the LEON2FT IP-XACT distribution....................................................47
Table 6 : Bus definitions of the LEON2FT IP-XACT distribution ...................................................................48
LIST OF FIGURES
Figure 4-1: Development flow of the activity...........................................................................................................9
This document is the Final Report of the “OCP-IP Building Blocks for Space-SoC” activity initiated by the European Space Agency, ESTEC contract 21393/08/NL/JK. The work has been performed between July 2008 and February 2010, by a consortium led by EADS Astrium Satellites, located in Elancourt (France). The sub-contractors were Magillem Design Services, located in Paris, and Aeroflex Gaisler, located in Gothenburg (Sweden).
1.1 TERMS & ACRONYMS
AHB Advanced High-Performance Bus (part of the AMBA specification) AMBA Advanced Microcontroller Bus Architecture APB Advanced Peripheral Bus (part of the AMBA specification) API Application Programming Interface ASIC Application Specific Integrated Circuit CCSDS Consultative Committee for Space Data Systems CODEC Coder-Decoder DMA Direct Memory Access ECSS European Cooperation on Space Standardization ESA European Space Agency ESTEC European Space Research and Technology Centre FPGA Field Programmable Gate Array FSM Finite State Machine HDL Hardware Description Language (e.g. VHDL) IEEE Institute of Electrical and Electronics Engineers IP Intellectual Property IP-XACT Specification for meta-data and tool interfaces. Provides an XML schema that documents
characteristics of IP Cores to allow automation of configuration and integration LVDS Low Voltage Differential Signaling OCP Open Core Protocol, protocol for on-chip communication RTL Register Transfer Level, a form of hardware description, usually in a specific language (HDL),
which allows automated translation (‘synthesis’) to the target FPGA or ASIC technology. SEU Single-Event Upset SOC System On-a Chip SPIRIT Structure for Packaging, Integrating and Re-using IP within Tool flows. Consortium of companies
that have developed the IP-XACT specification. SpW SpaceWire TGI Tight Generator Interface, API part of the IP-XACT specification VHDL Very High Speed Integrated Circuit Hardware Description Language XML Extensible Mark-up Language XSL Extensible Stylesheet Language. XSL is a language for expressing stylesheets. XSL can be used to
transform XML data into HTML/CSS documents. XSLT Extensible Stylesheet Language Transformation. A language for transforming XML documents
into other XML documents
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The relentless advancement of IC manufacturing technology (now with sub-micron and deep sub-micron processes) enables the integration of an ever-increasing number of gates on silicon. It is now feasible to implement entire digital systems comprising buses, processors, memories and other components, on a single chip. Such devices are referred to as Systems-on-Chip (SoC). They can have a complexity of several millions of transistors and provide significant performance gains in terms of processing speed, mass and power consumption.
Due to their complexity, the design of such systems within a set of constraints (time, budget, quality) cannot be achieved without reusing previously developed and already verified components, referred to as “IP cores” or “building blocks”. This is the “design reuse” principle, leveraging the previous developments to accelerate the design and verification of new SoCs. The ESA IP library provides such building blocks, which are used in a number of SoC developments performed through various ESA contracts.
Nevertheless, while significantly improving design and verification time, design reuse also brings an issue of heterogeneity. The integration into a single design of IP cores developed in different contexts and by different teams is not always straightforward. Their interfaces may differ and therefore need to be adapted (both at the physical and at the protocol level). The documentation of these building blocks may not be sufficient, requiring the understanding of their internal machinery for a successful integration. The reuse aspect implies that there is a know-how transfer, from the designer to the user, so that the code not only has to be functional, but it also has to be understandable to the IP core user. In particular, the integration of third-party IP cores into a single design is often challenging, because it requires merging of synthesis scripts and constraints, mapping of technology specific macro cells such as memories and pads, harmonizing bus and signal interfaces and possibly adapting interface protocols. The merging of third-party IP cores is often a time-consuming and error-prone task.
Those issues obviously limit the benefits which could be gained from the design reuse of IPs from the ESA portfolio or from other sources. Nonetheless, two technologies address those problems: Open Core Protocol (OCP) and SPIRIT IP-XACT. It was therefore of great interest to investigate the use of these novel technologies in this activity.
3 PRESENTATION OF THE TECHNOLOGIES
3.1 OPEN CORE PROTOCOL
The Open Core Protocol (OCP) is a protocol for on-chip communication between IP Cores, specified by the OCP-IP consortium. It defines standard and core-centric interfaces, termed “Sockets”. These sockets are highly configurable: the "core-centric" concept consists in tailoring each socket to the core’s particular needs. The configuration options are wide: some OCP interfaces support only basic transfers while others use many extensions such as security levels, complex burst types, out-of-order operation and threads (for concurrency). The OCP sockets enable point-to-point connection, either directly between two IP Cores, more usually with an OCP interconnect which can be a shared bus or implement a more elaborate
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
architecture (crossbar, multi-layers, or even packet or circuit-switched network-on-chip). The connection of two different sockets is possible under certain conditions, using tie-off rules, otherwise OCP interconnects enable the connection of incompatible sockets. The OCP interface is bus-independent and does not contain circuitry specific to a particular bus or interconnect architecture. It therefore enhances IP reusability. The Open Core Protocol is also non-proprietary and openly licensed.
3.2 SPIRIT IP-XACT
IP-XACT is an industry and IEEE standard defined by the SPIRIT consortium. It defines an XML schema to describe IP Cores, with information such as the list of ports, the list of parameters, the register map, the source code file set. These IP-XACT descriptions act as a common metadata description of the IP Core. They are tool and vendor-independent. They can be viewed as a standardized mechanism to express and exchange information about an IP Core, from the IP designer to the SoC integration team, through tools or company borders. These descriptions ease the configuration and integration of IP Cores. Besides, the IP-XACT standard specifies an API to work with the IP-XACT descriptions in a tool-independent way: this is the TGI API, which can be used to write TGI generators. This enables automating configuration or integration tasks within the development flow.
4 OVERVIEW OF THE ACTIVITY
The general aims of this activity were to prepare the grounds to investigate the use of OCP sockets as a method of interfacing IP cores in Systems-on-Chip, and to examine the use of XML IP-XACT descriptions for packaging IP cores and for automating the process of interconnecting several IP cores while designing Systems-on-Chip.
The work is split in two main groups: Group A contains OCP design tasks and Group B contains IP-XACT packaging tasks.
4.1 GROUP A - OCP DESIGN
The objectives of Group A / OCP-related tasks were:
• to develop OCP sockets for two synthesizable VHDL IP cores from ESA IP library: the SpaceWire CODEC and the rad-hard version of the LEON2 microprocessor
• to develop OCP-to-AMBA and AMBA-to-OCP adapters, as synthesizable VHDL IP Cores
The development started by defining the configuration of the OCP interfaces to use, among the various possibilities. A review of the needs and of the OCP specification led to the selection of two OCP Sockets.
Then the IP Cores have been designed, tested and verified in RTL simulations, and synthesized in one FPGA and one ASIC technology. For Spacewire and LEON2FT, the synthesis results have been compared with the AMBA versions. The functional performance and functionalities have also been compared.
The appropriate documentation (Architectural description manual, Verification Plan & Report, User Manual) has been issued.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The objectives of Group B / IP-XACT packaging tasks were:
• to develop IP-XACT XML descriptions for the LEON2FT and SpaceWire Codec ESA IP Cores, including the OCP-compliant versions of these cores developed in Group A
• to develop IP-XACT XML descriptions for the OCP-to-AMBA and AMBA-to-OCP adapters developed in Group A
For each of these IP-XACT descriptions, their validity and compliance to the SPIRIT specification has been verified by running XML-schema checks and comparisons against the SPIRIT consortium schema.
TGI Generators to configure and setup the IP parameters have also been written.
The appropriate documentation (User Manual, Verification Plan & Report) has been issued.
4.3 DEVELOPMENT FLOW
The development flow of the activity is presented below. EADS Astrium was in charge of the management of the study and of the Spacewire-related tasks (development of the Spacewire-OCP and IP-XACT packaging of the Spacewire). Magillem Design Services was in charge of the development and IP-XACT packaging of the AMBA-OCP bridges. Magillem Design Services was also in charge of the development of the OCP socket for LEON2FT. Aeroflex Gaisler was in charge of the IP-XACT packaging of the LEON2FT distribution.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Before beginning the development of the OCP-compliant IP Cores (Spacewire-OCP, LEON2FT-OCP, AMBA-OCP Bridges), it was necessary to define the OCP sockets to use, among the many possibilities. This choice has been performed after a review of the communication needs of the Spacewire-AMBA, LEON2FT-AMBA and OCP-AMBA adapters and a review of the OCP specification.
5.1.1 Introduction to OCP Configurability
The OCP socket is highly configurable. It is a structured but flexible architecture, allowing many different configurations. Each socket is defined by 99 different parameters what leads to a very huge number of different possible sockets. For example, valid OCP interfaces can contain from 2 to 66 different signals, and the width of several of these signals is also configurable.
From a protocol point of view, some OCP interfaces support only basic transfers while others use many extensions such as security levels, data handshake phase, complex burst types (such as “two-dimensional block” or “exclusive OR” address sequences), but also tags (for out-of-order operation) and threads (for concurrency).
Some of these extensions are useful for some cores and applications. However, adding an extension in a socket is performed at the expense of complexity and impacts the number of gates and the validation effort. Therefore, extensions shall only be implemented when they are indeed useful. According to the OCP philosophy, each socket should be tailored to match its core’s particular needs and should not be over-designed.
A master and a slave are compatible only if they have identical or similar interfaces. The point-to-point connection of two similar (non-identical) OCP interfaces is possible through a set of rules defined in the specifications (signal tie-off rules and protocol behaviours). Besides, OCP systems are generally built around an OCP interconnect which supports different sockets: it is possible to connect different cores with different sockets, thanks to an interconnect.
5.1.2 Requirements for the Sockets to select
The OCP-related activities of this study are divided in two parts:
• The purpose of the first part is to turn AMBA AHB and APB interfaces into OCP ones, on existing IP cores (the Spacewire codec and the LEON2FT processor).
• The second part consists in producing AHB-OCP and APB-OCP bridges.
For the first part (transformation of AMBA interfaces into OCP ones): existing AMBA IPs have two kinds of communication needs, which correspond to and are fulfilled by AHB and APB. Therefore, the
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
requirements for the sockets to choose are that they shall correspond to these communication needs, provide as much performance as AMBA, and minimize the complexity (both in terms of gates and in validation effort).
For the second part (AMBA-OCP bridges), the choice shall maximize the performance of the final mixed AHB-OCP system.
The sockets chosen shall obviously be the same for the two parts. They shall also be close to widespread OCP configurations and compatible with commercial interconnects.
The conclusion of these requirements is that two sockets shall be defined:
• one socket close to AHB: it has been called the "H-Socket"
• one socket close to APB: it has been called the "P-Socket"
5.1.3 OCP Socket close to AHB: “H-Socket”
The OCP Specification defines some OCP Profiles, which are commonly used OCP sockets. One of these profiles is identified to be a bridging profile to the AMBA AHB protocol: this is the “Simple H-bus Profile”.
However, the “Simple H-bus Profile” can’t be used as is for this activity because it lacks the possibility of issuing imprecise bursts. Imprecise bursts are bursts whose length is not known at the beginning of the burst, and it is possible to issue imprecise bursts with AHB. The support of imprecise bursts has therefore been added in the "H-Socket".
Two other useful signals have been added to the socket: MReqLast and SRespLast. They provide redundant information that indicates the last request and response phase in a burst. They have been added since the OCP Specification states that “to avoid separate counting mechanisms to track bursts, cores that have the information [MReqLast/SRespLast] available internally are encouraged to provide it at the OCP interface”.
The following sections describe the functionalities of the "H-Socket" OCP socket selected.
5.1.3.1 Signals
The resulting signal list of the “H-Socket” can be found below: Master outputs/Slave inputs:
There are five constants used in this signal list, listed below.
Constant name Allowed values Preferred value
ADDR_WDTH 32 32
DATA_WDTH 8, 16, 32, 64, 128, 256, 512 or 1024
Natural data width of the core
BURSTLENGTH_WDTH All positive integers (minimum 1)
9
CONNID_WDTH All natural integers (0 included)
6
REQINFO_WDTH All natural integers (0 included)
Core-dependent
Table 1 : H-Socket Constants
Note that ADDR_WDTH is fixed to 32 since the AHB address width is fixed to 32. The allowed values for DATA_WDTH also come from the AHB specification.
The H-Socket has a signal named MConnID. This is used to transmit the system ID of the initiator, similarly to the HMASTER field of an AHB interface. In the case of a system composed of different AHB buses and OCP interconnects, this field will enable an OCP target to know the system ID of the initiator addressing it (whether this initiator is an OCP or an AHB one).
The H-Socket also has a signal named MReqInfo, defined as “core-specific” by the OCP Specification. In our case, it will be used by complex cores such as processors, to transmit information such as cacheability, bufferability, etc.
5.1.3.2 Commands and Burst types supported
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The commands supported by the H-Socket are IDLE, WR (classic/posted write), WRNP (WriteNonPost), RD (read) and RDEX. The RDEX (ReadExclusive) command is used to generate locked/atomic load-store sequences.
The burst types supported are INCR and WRAP, as in AHB.
5.1.3.3 Sub-word accesses
Some OCP configurations can be much more permissive than AHB about sub-word accesses. They can allow, for example, issuing a sub-word access concerning only 3 bytes out of a 32-bit word, in a single transfer. However, there is no need to issue such accesses for cores using H-Socket. Besides, such accesses are unusual and the systems generating or supporting them are rare. Those accesses are therefore not allowed in H-Socket and byte enable patterns are limited to be power-of-two in size and aligned to that size, as in AHB.
5.1.3.4 Responses
The responses allowed with H-Socket are NULL, DVA (Data Valid Accept) and ERR (Error).
5.1.3.5 Write completion model
In OCP, it is possible to configure the socket:
• either to provide responses only to read accesses (that is to provide no response to write accesses)
• or to provide responses for both read and write accesses.
For the H-Socket, it has been chosen to enable responses for write accesses, as in the “Simple H-bus profile”, so that a master can know the status of the write requests it has issued (in progress/completed successfully/failed).
Besides, write accesses can either be posted or not-posted. OCP provides the choice to enable or not the "WriteNonPost" command, additionally to the classic "Write" command:
• When the “WriteNonPost” command is enabled, additionally to the default “Write” command, the cores can specify, dynamically, which of their write accesses should be posted and which shouldn’t be posted. In this case, the “Write” command, which is the default and most-used write command, corresponds to a posted-write.
• When the “WriteNonPost” command is disabled, as for the “Simple H-bus profile”, initiators have only one type of write, and the policy about posting or not write accesses is defined at system level (in the interconnect configuration, for example).
Although cores using H-Socket do not a priori need to specify, dynamically, the write completion model of each write access (cores requiring this functionality would a priori use more complex sockets), the WriteNonPost command is allowed, as a provision for potential future needs. Besides, the fact to allow WRNP commands does not increase the complexity in terms of gates for initiators which issue only one type of write and for slaves which treat both writes in the same way.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
An OCP socket is defined by a list of values for the 99 OCP parameters.
Some parameters are the direct translation of the socket’s signal list (for example, parameter addr=1 means that signal MAddr is present, and its width is defined by parameter addr_wdth). Other parameters are kept to their default value, defined in the OCP Specification. The rest of the parameters constitutes information about the socket that is not included in the signal list, but only defined by OCP parameters. It has been chosen to issue a "concise parameter list", to describe the H-Socket only with these relevant parameters (i.e. parameters which are not included in the signal list and which have a value different from the default one).
writeresp_enable 1 Responses shall be provided for write accesses
Table 2 : Concise parameter list for the H-Socket
5.1.3.7 Endianness
An OCP interface also contains a parameter describing the endianness of the core. This parameter can be: big, little, both or neutral.
OCP is nearly endian-neutral, since when two OCP sockets are connected together directly, they have necessarily the same data width, and addressing is performed on an OCP-word granularity (MAddr is a byte address but must be aligned to the OCP word size) and “byte enables are tied to byte lanes (data bits) without tying the byte lanes to specific byte addresses” (OCP Specification).
But this endian parameter will be useful in particular when connecting cores which have different data widths (what will necessarily be done through an interconnect). This endianness information will be used for example when connecting a socket whose data width is 32 bits to an 8-bit socket, through an interconnect: the “endian” parameter of the 32-bit core will be used to determine which 8-bit words are mapped to which 32-bit byte lanes.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The OCP Specification defines an OCP Profile (commonly used OCP socket) for programmable register interfaces: this is the “Register Access Profile”. This standard profile is close to an APB interface and addresses the same functionality (register interface). It has been chosen as the P-Socket. The “Register Access Profile” has some options to configure however. The options chosen for the P-Socket are:
• No possibility to delay the response (as in APB, because it reduces the complexity of such interfaces)
• No sub-word accesses (as in APB and as recommended in the “Register Access Profile” description)
• No sideband signals (such as interrupts, etc.)
5.1.4.1 Signals
The resulting signal list is: Master outputs/Slave inputs:
MCmd : std_logic_vector(2 downto 0);
MAddr : std_logic_vector(ADDR_WDTH-1 downto 0);
MData : std_logic_vector(DATA_WDTH-1 downto 0);
MReset_n : std_logic;
Master inputs/Slave outputs:
SResp : std_logic_vector(1 downto 0);
SCmdAccept : std_logic;
SData : std_logic_vector(DATA_WDTH-1 downto 0);
SReset_n : std_logic;
The two constants have the same allowed and preferred values than for the H-Socket:
Constant name Allowed values Preferred value
ADDR_WDTH All positive integers (Minimum 1)
32
DATA_WDTH 8, 16, 32, 64, 128, 256, 512 or 1024
Width of the core’s registers/Natural data width of the core
Table 3 : P-Socket Constants
5.1.4.2 Commands supported
The commands supported by the P-Socket are IDLE, WR (classic/posted write), WRNP (WriteNonPost) and RD (read).
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Similarly to the H-Socket, the P-Socket configuration is such that:
• responses shall be provided for both read and write accesses
• the WriteNonPost command is allowed, as a provision for potential future needs, since it does not increase the complexity in terms of gates for initiators which issue only one type of write and for slaves which treat both writes in the same way
5.1.4.4 OCP parameters
An OCP socket is defined by a list of values for the 99 OCP parameters.
Some parameters are the direct translation of the socket’s signal list (for example, parameter addr=1 means that signal MAddr is present, and its width is defined by parameter addr_wdth). Other parameters are kept to their default value, defined in the OCP Specification. The rest of the parameters constitutes information about the socket that is not included in the signal list, but only defined by OCP parameters. It has been chosen to issue a "concise parameter list", to describe the P-Socket only with these relevant parameters (i.e. parameters which are not included in the signal list and which have a value different from the default one).
writeresp_enable 1 Responses shall be provided for write accesses
Table 4 : Concise parameter list for the P-Socket
5.1.4.5 Endianness
The “endian” OCP parameter of the P-Socket is necessarily “neutral”, because this socket has no sub-word access capability and therefore works only with full words.
5.1.5 Comparison between AMBA and the OCP Sockets selected
Compared to an AHB interface, the H-Socket provides the same maximum throughput (data_width bits per clock cycle). However, the H-Socket provides the possibility to send multiple requests before receiving the first response, what is interesting for high-latency networks-on-chip.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The minimum latency is 0 for H-Socket (response in the same cycle as request), instead of 1 for AHB. This can be used for some point-to-point connections with short timing paths.
From a design point of view, the main difference between AHB and H-Socket is that there is no notion of bus arbitration in OCP: the "request/grant phase" and the AHB Request and Grant signals have no equivalent in OCP. Similarly, the SPLIT and RETRY responses have no equivalent in the H-Socket since equivalent mechanisms in OCP would handle this directly in the OCP interconnect and in the SPLIT-capable slave interfaces, without involving the design of all the master interfaces. The advantage is that the OCP interfaces are made more simple: the arbitration logic and the management of SPLIT-equivalent services are centralized in the interconnect instead of being distributed over all the IP Cores, what reduces bug risk and design cost.
The difference between P-Socket and APB is that APB transfers always take 2 cycles (latency = 1, throughput = data_width bits every 2 clock cycles) whereas P-Socket slaves can provide 0-latency responses (response in the same cycle as request, for cores which have short timings paths on their register interface) or insert wait states. P-Socket can also support 1 transfer per clock cycle, what provides twice the throughput than APB. Additionally, P-Socket slaves can issue ERROR responses (APB slaves cannot).
5.2 DEVELOPMENT OF SPACEWIRE-OCP
5.2.1 Design
‘Spacewire’ is a high-speed serial link defined as an ECSS standard. The ESA IP library already contained a Spacewire CODEC with AMBA interfaces, developed by Astrium under another contract. This IP Core will be referred to as 'Spacewire-AMBA'. The aim of this activity was to re-use the existing Spacewire-AMBA IP Core to produce an OCP-interfaced Spacewire Core, with the requirement to remove the existing AMBA interfaces before replacing them, in order to obtain native OCP interfaces and not bridged ones.
The AMBA interface of the Spacewire-AMBA has been modified and turned into an OCP interface: the AHB interfaces have been replaced by "H-Socket" OCP Sockets, and the APB interface by a "P-Socket" OCP Socket. Since the OCP Sockets chosen are close to their AMBA counterparts, it was possible to re-use the Finite State Machines from the AMBA interfaces. These state machines have been simplified since there is no notion of bus arbitration in OCP: the AHB Request and Grant signals have no equivalent in OCP and more importantly, there is no "request/grant phase" in OCP.
The resulting Spacewire-OCP shares 25 out of 32 VHDL source files with Spacewire-AMBA. The parts modified are highlighted in yellow in the block diagram below.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Note that the difference between Spacewire-OCP and Spacewire-AMBA is only the on-chip interface (AMBA/OCP). Both cores are equivalent in terms of functionalities and have the same register map, in particular. The interest is that drivers and software applications are compatible with both cores, and that the simulation scenarii can be re-used.
The OCP interface chosen (H-Socket) has the possibility to issue either classic/posted write commands or non-posted write commands. For the Spacewire-OCP, it has been chosen to always issue the same type of write commands; this is configurable through generics (one per master interface). The slave interfaces interpret both write commands the same way.
5.2.1.1 Performance Comparison with Spacewire-AMBA
The functional performance of Spacewire-AMBA was expressed in terms of maximum RX and TX frequencies, minimum packet size to avoid NULL insertion during transmission and number of clock cycles necessary to build and write a word received.
Spacewire-OCP and Spacewire-AMBA provide equivalent functional performance, except for the TX master interface, where Spacewire-OCP performs better.
The TX master interface fetches packets in memory, through the AMBA or OCP interface, and sends them on the Spacewire link. The data fetched includes the packet size, the data address and the data itself. When the packet size is too small, fetching the packet on the AMBA or OCP side takes longer than the transmission on the Spacewire side, because of the packet size and data address overhead. The minimum packet size without NULL insertion therefore represents the rapidity of the AMBA/OCP interface. Due to the suppression of the bus request phases in the state machine, Spacewire-OCP manages not to insert
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
NULL characters with packet sizes as low as 2, instead of 6 for Spacewire-AMBA, with identical interconnect conditions.
5.2.2 Verification
The Spacewire-AMBA IP Core was already well validated, and comes with a testbench and a set of test sequences. The purpose of the Spacewire-OCP verification was therefore to focus on the OCP interfaces. The objective was to reach 100% functional and statement code coverage on the OCP parts.
The Spacewire-AMBA testbench has been re-used: the Spacewire-OCP testbench has been built replacing the Spacewire-AMBA IPs by Spacewire-OCP IP cores wrapped with AMBA-OCP bridges. The structure of the testbench is shown below. It is composed of two Spacewire-OCP blocks connected together, with several test blocks.
Spacewire-OCP1
Spacewire-OCP2
d_in
d_in
d_out
d_out
s_out
s_out
s_in
s_in
SoftMem
Arbiter
emu_set_sig
emu_test_sig
clk,clk_tx,rstn,test_mode_hard,tickin_ctm
err_int,nom_int,tickout_ctm
emu_ahbslv_sm
emu_ahbslv
emu_ahbmst
emu_mem_spy
AHB BUS
emu_apbmst
APB BUSemu_controleur
character generator
gen_char
emu_spwr
AHB-OCPBridges
APB2OCP Bridge AHB-OCP
Bridges
APB2OCP Bridge
Figure 5-2: Spacewire-OCP testbench
This testbench enables checking the TX OCP master and slave interfaces and the RX OCP master interface. Checking the TX OCP master/slave of one Spacewire is done by verifying that the data received by the other Spacewire block is correct. The RX OCP master is checked for normal operations and for
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
operations performed when the host memory area limit is reached. A Spacewire character generator can generate error characters to simulate transmission errors. The testing of the Write/WriteNonPost commands is performed through an appropriate static configuration of the Spacewire instances. Besides, in order to improve the functional and statement coverage, two possibilities have been added in the Spacewire-OCP testbench:
• the possibility to modify the timing of the “SCmdAccept” signal provided to Spacewire H-Socket Master interfaces, to cover the two protocol possibilities
• the possibility to generate OCP commands not supported by the H-Socket (such as the “Read Linked” OCP command)
The test sequences from Spacewire-AMBA have been re-used. They have been extended and completed to reach the functional and code coverage objectives.
5.2.2.1 Verification Results
The statement code coverage reached is 100% for the OCP-specific parts.
The Spacewire-OCP functional coverage provided by the simulation scenarii reaches an equivalent level as for Spacewire-AMBA, since the test sequences are the same, even with some additions.
Concerning protocol coverage, the SpW OCP interfaces are tested using the Magillem bridges, whose compliance to the OCP protocol has been established using specific eVC’s (Verification Components for the e language).
The OCP interfaces of Spacewire-OCP are simple: they do not need to issue bursts, they do not need to use RespLast/ReqLast information, they only issue/receive the same type of command (only write for RX master, only read for TX master, only write for TX slave). The different possible protocol options are therefore limited. All these options are tested. The simulations also perform numerous accesses on the TX slave interface, resulting in the test in various conditions (FIFO full or not) of the OCP slave interface and of the associated TX FSM.
Therefore, given the functional coverage of the Spacewire simulation scripts, the 100% code coverage and the above points, the Spacewire-OCP is considered compliant to the OCP protocol with a good level of confidence.
5.2.3 Synthesis
The Spacewire-OCP has been synthesized in one ASIC and one FPGA technology. The ASIC technology is ATMEL MH1RT. The FPGA technology is ACTEL RTAX2000. The synthesis has also been performed on Spacewire-AMBA with similar conditions (for example, the I/O delays were set to the same percentage of the clock period for AMBA and OCP).
The results are summarized below:
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Clock Frequencies Requested frequency Estimated frequency for
Spacewire-OCP Estimated frequency for
Spacewire-AMBA
RX clock 110.0 MHz 145.7 MHz 145.4 MHz
System clock 50.0 MHz 59.5 MHz 58.2 MHz
TX clock 110.0 MHz 121.8 MHz 131.6 MHz
The timing results are equivalent for Spacewire-OCP and Spacewire-AMBA. The greatest difference is 7% for the TX clock.
• Maximum ASIC clock frequency
Worst slacks (in ns) Spacewire-OCP Spacewire-AMBA Difference
(OCP-AMBA)
Worst slack for RX clock at 110MHz
0.05 0.05 0.00
Worst slack for System clock at 100MHz
0.00 (+) 0.00 (+) 0.00
Worst slack for TX clock at 110MHz
0.77 0.77 0.00
The timing results are very similar between Spacewire-AMBA and Spacewire-OCP (identical worst slacks, in particular).
• FPGA Resource usage
Number of FPGA cells Spacewire-OCP Spacewire-AMBA
Combinational Cells 1933 1982
Sequential Cells 1206 1215
Total Cells 3139 3197
Spacewire-AMBA is a little bigger than Spacewire-OCP (+1.84%). This is due to the fact that an H-Socket interface is slightly simpler than an AHB one (no request/grant phase or arbitration signals, no services such as SPLIT or RETRY).
• ASIC Area
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Area of Host interface (contains AHB/H-Socket interface)
17848 17945 -97
Area of SW module (contains APB/P-Socket interface)
13348 13324 24
Spacewire-AMBA is a little bigger than Spacewire-OCP (+0.8%). This is due to the fact that an H-Socket interface is a little simpler than an AHB one (no request/grant phase or arbitration signals, no services such as SPLIT or RETRY). We can remark that the P-Socket register interface is slighlty bigger than APB (a response signal has to be generated for the P-Socket - there is no response signal in APB). However this increase is lower than the gain from the H-Socket interface.
As a conclusion, Spacewire-OCP is a little better for clock frequencies and design size, since H-Socket is a little simpler than AHB.
5.3 DEVELOPMENT OF LEON2FT-OCP
5.3.1 The LEON processor
The LEON project was started by ESA in late 1997 to study and develop a high-performance processor to be used in European space projects. The objectives of the project were to provide an open, portable and non-proprietary processor design, capable to meet the identified requirements for performance, software compatibility and low system cost. Another objective was to be able to apply a Single Event Upset (SEU) sensitive semiconductor process. To maintain correct operation in the presence of SEUs, extensive error detection and error handling functions were added. The goals have been to detect and tolerate one error in any register without software intervention, and to suppress effects from SEU errors in combinational logic.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The LEON family includes the first LEON1 VHDL design that was used in the LEONExpress test chip developed to prove the fault tolerance concept. The second LEON2 VHDL design was used in the new processor device AT697E from Atmel (F). These two LEON implementations were developed by ESA. Gaisler Research developed the third LEON3 design and Aeroflex Gaisler has recently developed the next generation LEON processor, the LEON4.
The LEON2FT distribution, sometimes referred to as the LEON2FT processor model developed by the European Space Agency has the following features:
• SPARC V8 compliant Integer Unit with 5-stage pipeline
• Hardware multiply, divide and MAC units
• Interface to the Meiko FPU and custom co-processors
• Separate instruction and data cache (Harvard architecture)
• 8/16/32-bits memory controller for external PROM and SRAM
• 32-bits PC133 SDRAM controller
• On-chip peripherals such as UARTs, timers, interrupt controller and 16-bit I/O port
• Advanced on-chip debug support unit and trace buffer
• Power-down mode
The LEON2FT model is based on AMBA and comprises the following main (AMBA) elements:
• Processor (Integer Unit with caches) (AMBA AHB master, APB slave)
• Debug Support Unit (AMBA AHB slave)
• Debug UART (AMBA AHB master, APB slave)
• Standard peripherals (UARTs, Interrupt Controller, General Purpose Input/Output, Timers, Status Register, etc. (all APB slaves)
• Memory controller (AMBA AHB slave, APB slave)
The LEON2FT processor (Integer Unit with caches) will be referred to as "LEON2FT-AMBA".
5.3.2 Design
The LEON2FT-AMBA processor, described in the previous chapter, is a SPARC V8 Integer Unit with caches and AMBA interfaces. The aim of this activity was to re-use the LEON2FT-AMBA processor from ESA to produce an OCP-interfaced LEON2FT processor, with the requirement to remove the existing AMBA interfaces before replacing them, in order to obtain native OCP interfaces and not bridged ones.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The Integer Unit is interfaced with two separate caches (ICache for the instructions and DCache for data). The caches communicate with the memory system through two AMBA interfaces (AHB and APB). ICache and DCache share a single AHB master interface. This is done to perform the arbitration internally rather than on the AHB bus; in case of simultaneous access requests from both caches, instructions have the priority. The APB interface is used to control the processor registers (cache behavior, power down mechanism, etc). There is an additional interface, used for data cache snooping, which is an AHB slave input. Between the caches and the AHB interface, an optional Memory Management Unit (MMU) can be instantiated. In this case, a specific AHB interface layer is used.
The AMBA cache interfaces are grouped in the ACACHE module. This module has three primary functionalities:
• Translate requests coming from the caches into AHB accesses
• Control the caches behaviour (CCR, flush, freeze)
• Perform the arbitration in case of simultaneous accesses from both caches
To achieve these tasks the ACACHE module needs to retrieve enough information from the caches and from the IU pipeline. This is why ACACHE is interfaced to both caches and to the integer unit.
Designing LEON2FT-OCP therefore consisted in rewriting the cache interface: ACACHE has been replaced by OCACHE, standing for "OCP Cache interface". The single AHB master interface has been replaced by two master H-Socket interfaces, and the APB register interface has been replaced by a P-Socket OCP interface. The resulting block diagram is shown below.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Figure 5-4: LEON2FT-OCP Block diagram with OCACHE module
It has been chosen to implement two separate master sockets, one for each cache, instead of a single master interface as in LEON2FT-AMBA, because it enables investigating more elaborate interconnect structures, multi-layered in particular. The best performance of this bi-socket LEON would be delivered in SoCs able to feed simultaneously both interfaces, that is either with two memory controllers, or with similar possibilities (with on-chip memory for example). But even with a single memory controller, the performance is better than mono-socket with a multi-layered interconnect: while the Instruction socket accesses the memory controller, the Data socket accesses registers of on-chip IP Cores, or on-chip memory.
The implementation of the data cache snooping and of the MMU support was beyond the scope of the project.
It has not been possible to implement burst accesses: it would have required modifications beyond the cache interface. Indeed, the LEON only performs AHB imprecise bursts (bursts whose length is not
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
known at the beginning of the burst), and the cache interface does not know if a request is the last of a burst when it issues the command.
The locked accesses are correctly translated in OCP: on SWAP or LDSTB instructions, the OCP interface issues a RDEX command, indicating a locked transfer.
5.3.2.1 Performance Comparison with LEON2FT-AMBA
Since no native OCP system (interconnect and memory controller) was available, the LEON2FT-OCP testbench, described in next chapter, has been used for the performance comparison. This is a system based on an AHB bus with AHB/OCP bridges to interface the LEON2FT-OCP. The performance cannot therefore be compared to a LEON2FT-AMBA system, since the OCP cache requests need to transit from OCP through the bridges and then collide on the shared AHB bus where the arbitration is performed. This is worsened by the fact that this version of LEON2FT-OCP does not issue bursts. However, with a commercial multi-layered OCP interconnect and a native OCP memory controller, a far better performance evaluation of LEON2FT-OCP could be performed.
5.3.3 Verification
The LEON2FT-AMBA processor is already well validated, and comes with a testbench and a set of test sequences. The purpose of the LEON2FT-OCP verification was therefore to focus on the OCP interfaces. The objective was to reach 100% functional and statement code coverage on the OCP cache interface.
The LEON2FT-AMBA testbench is a full AMBA platform with an AHB decoder and arbiter, a memory controller, a timer, an interrupt controller, etc. The LEON2FT-AMBA processor is connected to the AHB and APB buses. This LEON2FT-AMBA testbench has been re-used: the LEON2FT-OCP testbench has been built replacing the LEON2FT-AMBA by a LEON2FT-OCP processor wrapped with AMBA-OCP bridges. The structure of the testbench is shown below. This testbench enables running "as is" the existing test programs.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
In the LEON2FT-AMBA distribution, the test sequences are run by the LEON processor, in the form of C test programs. There are two types of tests: functional or memory integrity. These tests are listed below:
• multest
• divtest
• wp_test
• extra
• fpu_test
• memtest
• edac_test
• cache_test
• irq_test
• uart_test
• timer_test
• ioport_test
• ramfill
• ramtest
These test programs have been re-used for the LEON2FT-OCP verification. They enable generating accesses through the OCP interfaces of the LEON, in order to test the OCACHE module which corresponds to the OCP cache interface. These tests also ensure that the functionality of the entire subsystem is preserved, since they test various system components such as the interrupt controller, the timer, etc. In this activity, these tests have been used as a golden reference for the LEON2FT-OCP verification.
Two additional tests have been written by Magillem for functional and code coverage purpose:
• Write_error test, which performs errors during instruction reads and data writes
• Access_test, which performs different accesses with various characteristics (data width, locked transfers, ...)
5.3.3.1 Verification Results
The statement code coverage reached is 100% for the OCP cache interface. The functionality has been extensively verified, with the original LEON2FT-AMBA testsuite plus additional tests. The OCP compliance has been established through the AMBA-OCP bridges.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Additionally to the work foreseen in the contract, Magillem has set up a platform based on an OCP interconnect from the SONICS company. The block diagram of the platform is presented in Figure 5-6. The interconnect used is the "Stingray" one. The AHB memory controller is connected to this interconnect with an AHB-OCP bridge (no native OCP memory controller was available). The main LEON2FT-OCP verification test program was run successfully on this platform. This platform also demonstrated the compatibility of some of the cores developed during this study with a commercial OCP interconnect.
Figure 5-6: LEON2FT-OCP Platform based on an OCP interconnect from SONICS
5.3.4 Synthesis
The LEON2FT-OCP processor has been synthesized in one ASIC and one FPGA technology. The ASIC technology is ATMEL ATC18RHA. The FPGA technology is ACTEL RTAX2000. The synthesis has been performed at processor core level (Integer Unit with caches), and not at microprocessor level (Integer Unit + AMBA buses + Timer, Interrupt Controller, Memory Controller...), in order to compare the LEON2FT OCP and AMBA versions.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Note that the I/O delays were set to a fixed percentage of the clock period.
Design Size LEON2FT-OCP LEON2FT-AMBA
Number of FPGA cells 13090 12876
ASIC area (mm²) 4,74 4,58
In terms of maximum clock frequency, both implementations are close, but LEON2FT-OCP is a little faster. This can be explained by the fact that the H-Socket interface is a little simpler than an AHB interface (no request/grant phase or arbitration signals) and by the fact that the OCP Cache Interface does not contain an internal arbiter, as in the AMBA version, since it has two separate master sockets.
In terms of design size, the results are close, but LEON2FT-OCP is a little bigger (3.36% maximum, for ASIC). This is due to the fact that the two master sockets require two interface FSM, instead of one for the single AHB master socket.
5.4 DEVELOPMENT OF AMBA-OCP BRIDGES
5.4.1 Design
The AMBA-OCP Bridges or Adapters have been developed by Magillem. There are actually four bridges: AHB2OCP, OCP2AHB, APB2OCP and OCP2APB. These bridges enable the connection of OCP-interfaced IP Cores to an AMBA AHB/APB system. Their development has been based on existing cores already available and verified at Magillem.
These bridges feature a full AMBA support: OCP2AHB manages correctly SPLIT and RETRY responses, all the bursts types are translated between AHB and H-Socket, etc. The clock is synchronous between AHB and OCP.
The OCP Sockets of the AHB-OCP Bridges are H-Sockets, and the OCP Sockets of the APB-OCP Bridges are P-Sockets.
An illustration of an AHB to OCP translation is given below, for a read burst:
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Figure 5-7: Timing diagram of an AHB to OCP translation
The architecture of the AHB-OCP bridges is summarized in the figure below: there are two independent state machines, one for each side (AHB/OCP); they communicate using a specific internal protocol.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Figure 5-8: Architecture summary of the AHB-OCP Bridges
Concerning the APB-OCP bridges, they are much more simple since APB/P-Socket are similar and simpler than AHB or H-Socket. An illustration of an APB to OCP translation is given below, for a write access:
Figure 5-9: Timing diagram of an APB to OCP translation
Note however that the ability to delay the response cannot be disabled in OCP. It is possible to disable other protocol options with OCP parameters (for example, bursts and sub-word accesses have been disabled in the OCP P-Socket), but not the ability to delay the response. Therefore there is a constraint on the APB2OCP protocol conversion, which is that the OCP Slave shall not delay its response (this constraint is due to the protocols, and does not apply on OCP2APB).
5.4.2 Verification
The verification of the bridges has been performed with the use of random traffic generation. eVC (Verification Components for the e language) have been used to generate random OCP accesses, according to a set of constraints specifying the type of accesses to be generated, in order to reach a full
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
functional coverage. These eVC also embed OCP checkers, which implement OCP checking rules from the OCP-IP consortium. These assertion checks are applied to all the OCP accesses. The OCP2AHB testbench is given as an example below:
eVc OCP
2.2 Master
AHB Slave
Test environment platform
ocp2ahb wrapper
Figure 5-10: OCP2AHB testbench
Additionally to the full functional coverage, 100% statement code coverage has been reached.
5.4.3 Synthesis
The four AMBA-OCP bridges have been synthesized in one ASIC and one FPGA technology. The ASIC technology is ATMEL MH1RT. The FPGA technology is ACTEL RTAX2000. The results are summarized below:
Clock Frequency FPGA synthesis (MHz) ASIC synthesis (MHz)
AHB2OCP 55.0 100.0
OCP2AHB 55.0 109.8
APB2OCP 166.0 119.4
OCP2APB 189.0 196.0
The I/O delays were set to a fixed percentage of the clock period.
Design Size Number of FPGA cells ASIC area (µm²)
AHB2OCP 245 2924
OCP2AHB 359 4807
APB2OCP 71 273
OCP2APB 69 1082
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Before beginning the development of the IP-XACT packages, the IP-XACT version to use has been chosen. The version chosen is IP-XACT v1.4 since it was the most up-to-date and had the advantage over v1.2 to specify the Tight Generator Interface, used for the development of the generators. Then tools and bus definitions required have been identified. Magillem provided its SPIRIT Design Environment for the activity. The IP-XACT descriptions and generators have then been produced, verified and documented.
6.1 TOOLS AND BUS DEFINITIONS REQUIREMENTS
In order to exploit the IP-XACT descriptions and TGI generators, a SPIRIT Design Environment supporting IP-XACT version 1.4 and implementing the TGI API is necessary. The Magillem SPIRIT Design Environment has been used for the activity.
Besides, AMBA and OCP bus and abstraction definitions are necessary to work with the descriptions. The AMBA bus and abstraction definitions are copyright by ARM Limited and can be obtained freely on the ARM website. However, since the license associated with these ARM IP-XACT files is non-transferable, they cannot be delivered as part of the IP-XACT packages. Similarly, the OCP bus and abstraction definitions are not delivered as part of the IP-XACT packages and must be obtained from the OCP-IP Consortium.
6.2 SPACEWIRE IP-XACT PACKAGING
The Spacewire IP-XACT package is composed of IP-XACT component descriptions for the Spacewire-AMBA and Spacewire-OCP, and of two TGI generators to configure the Spacewire cores: "SpW Configurator" and "Swap_AMBA_OCP".
Note that since the different views of a component must be pin-consistent in IP-XACT, it was not possible to package both Spacewire-AMBA and Spacewire-OCP as two different views of the same component description. This is why two different component descriptions had to be issued for Spacewire-OCP and Spacewire-AMBA, instead of one configurable component description. To compensate, the "Swap_AMBA_OCP" generator has been written to provide an easy way to switch between Spacewire-AMBA and Spacewire-OCP.
6.2.1 IP-XACT Descriptions
The Spacewire IP-XACT descriptions contain the following information:
• The IP ports list
• The bus interfaces list
• The connections between the IP ports and the bus interface signals
• The hardware parameters (those defined in VHDL packages, and the VHDL generics)
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
• The different views on which the design environment can work
• The different file sets (source code, documentation, synthesis scripts & constraints, etc.)
6.2.1.1 IP Ports
The ports of the Spacewire IP Cores are defined using VHDL records. Since the VHDL records are not supported natively in IP-XACT, the “Ports” sections of the IP-XACT descriptions list all the ports as std_logics or std_logic_vectors (for example: tx_ocp_slv_in_Sresp, tx_ocp_slv_in_Sdata, ... for the tx_ocp_slv_in record), and Magillem Vendor Extensions have been used to indicate that these sets of signals correspond to a record, with a mention of the record type (OCP_H_Slv_In_Type for example).
6.2.1.2 Bus interfaces
The Spacewire-OCP/AMBA descriptions define 4 bus interfaces, which correspond to the 4 OCP/AMBA interfaces.
6.2.1.3 Parameters
The Spacewire-OCP has three different types of parameters: it has VHDL generics, it has VHDL configurable constants expressed in the Spacewire VHDL package, and VHDL configurable constants expressed in the AMBA or OCP package. The Spacewire IP-XACT parameters have therefore been organized in the three following configuration groups: AMBA/OCP_CONSTANTS, SPW_CONSTANTS and GENERICS.
6.2.1.4 Register map
The ‘register map’ section of the IP-XACT descriptions contains all the information present in the specifications concerning the registers. It also contains additional information about the volatility of the registers.
Concerning a specific register whose reset value depends on a parameter (part of the SPW_CONSTANTS configuration group), it is possible to indicate the dependency of the reset value to the parameter directly in the XML. However, it was not well supported by the tools used during the development of the descriptions (erroneous value output from the XPATH equation). It has therefore been decided to use the TGI generator “SpW Configurator” to update this reset value, what ensures that the reset value will be updated correctly and that it will not be replaced by an erroneous value (as it could be the case with some tools).
6.2.1.5 Views and File Sets
The views and file sets have been organized so that:
• a file set references a consistent set of files (for example, all the VHDL source code, all the simulation or synthesis scripts, ...)
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The Spacewire IP Cores are equipped with two TGI generators, described in the following sections. The IP-XACT descriptions contain a link to the executable entry point of the generators, what enables launching the generators on instances of these IP-XACT components.
6.2.2 Verification of the IP-XACT Descriptions
The well-formedness and the validity of the XML descriptions has been successfully checked with respect to the SPIRIT IP-XACT schema v1.4, using a commercial XML tool.
Further checks have successfully been performed using the checkers built-in the Magillem SPIRIT Design Environment.
6.2.3 “SpW Configurator” TGI Generator
6.2.3.1 Purpose
The “SpW Configurator” TGI generator provides a graphical interface for configuring the AMBA and OCP Spacewire blocks. It enables configuring parameters such as the sizes of the FIFOs, the counter widths and the gating or not of the TX clock. These parameters correspond to the SPW_CONSTANTS configuration group.
Indeed, the generics of component instances can easily be configured with a SPIRIT Design Environment, but it was not possible to change the Spacewire VHDL constants from the SPIRIT Design Environment where the IP-XACT components are configured and assembled. The advantages of using the SpW Configurator are therefore that:
• it enables configuring the Spacewire VHDL constants
• it checks and ensures that the new parameters’ values are within their allowed range
• it ensures that the VHDL source code and the IP-XACT descriptions are kept consistent
6.2.3.2 Description
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The “SpW Configurator” TGI generator is written in Java. It performs calls to the IP-XACT TGI API, implemented by the Magillem SPIRIT Design Environment. The generator is based on Java Swing components for the graphical interface.
Note that the generator is the same for Spacewire-OCP and Spacewire-AMBA, since it extracts most of its information from the IP-XACT descriptions.
When launched, the generator displays the main GUI window below:
Figure 6-1: SpW Configurator main GUI window
The user can read the descriptions of the parameters and change some values. If these values are allowed, the user can apply them. The generator asks for a confirmation and clearly indicates the VHDL file (with its absolute path) which is about to be modified. The success or failure of the operation is also summarized in the console log (additionally to the dialog windows), with details about the changes performed and the file modified.
In case invalid values are set for the parameters, they are highlighted in red in the GUI window and it is not possible to apply the changes. The two checks performed are:
• a check that the type is correct (boolean or integer, depending on the parameters)
• a check that the values chosen for the integer parameters are within the allowed ranges
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Figure 6-2: Main SpW Configurator GUI when invalid parameter values
6.2.4 “Swap_AMBA_OCP” TGI Generator
6.2.4.1 Purpose
The purpose of the “Swap_AMBA_OCP” TGI generator is to replace a Spacewire-OCP instance by a Spacewire-AMBA, and vice-versa. Since the different views of a component must be pin-consistent in IP-XACT, it is not possible to package both Spacewire-AMBA and Spacewire-OCP as two different views of the same component description. This is why two different component descriptions had to be issued for Spacewire-OCP and Spacewire-AMBA, instead of one configurable component description. To compensate, this generator brings an easy way to switch between Spacewire-AMBA and Spacewire-OCP.
6.2.4.2 Description
This TGI generator is written in Java. It performs calls to the IP-XACT TGI API, implemented by the Magillem SPIRIT design environment.
The “Swap_AMBA_OCP” generator is the same for Spacewire-OCP and Spacewire-AMBA.
The following figure represents the IP-XACT design used for generator testing. It is composed of:
• one Spacewire-AMBA instance, with an AHB connection to an AHB2OCP bridge
• one Spacewire-OCP instance, with an OCP connection to an OCP2AHB bridge
Both Spacewire IP Cores instances have their Spacewire signals (data and strobe) connected together.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Figure 6-4: Test design after applying the “Swap_AMBA_OCP” generator
The instance named ‘spacewire_amba_inst_0’, which was a Spacewire-AMBA instance, is now a Spacewire-OCP instance.
The “Swap_AMBA_OCP” generator preserves the existing connections, when relevant (the generator will preserve clocks, interrupt and Spacewire signals connections, and will remove AMBA or OCP connections). In this case, the AHB connection between ‘spacewire_amba_inst_0’ and the AHB2OCP bridge has been removed, but the Spacewire signals connection has been preserved.
The console log indicates whether the operation completed successfully or not. It also issues a warning notice when the instance name refers to the bus type (OCP or AMBA), and when this bus type is not consistent anymore with the type of component (for example, when an instance named ‘spacewire_amba_inst_0’ is a Spacewire-OCP instance).
6.2.5 Verification of the Generators
The verification of the generators consisted in performing functional verification tests in the Magillem SPIRIT environment. These tests are described in the Verification Plan in the Spacewire IP-XACT package documentation.
6.3 LEON2FT IP-XACT PACKAGING
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The LEON2FT IP-XACT package contains meta-data IP-XACT descriptions for the following cores of the LEON2FT distribution:
• LEON2FT-AMBA processor
• Debug Support Unit (DSU)
• Debug Serial Link
• Memory controller (MCTRL)
• Interrupt controller
• Timers
• UART
• I/O port
• AHB/APB bridge
• AHB controller
• Clock generator
• Reset generator
• Write protection unit
The package also includes a meta-data description of the LEON2FT-OCP processor. In addition to this, the package contains HDL for descriptions for bus fabric that is needed to use IP-XACT to connect the cores together and IP-XACT bus definitions that are utilised to define the interconnections between components in a LEON2FT SoC. Finally, the package also contains a TGI generator which generates the LEON2FT configuration HDL file.
The development flow of the LEON2FT IP-XACT package can be summarised as follows:
• analysis and specification
• development of the descriptions and generator
• verification
The initial part of the activity focused on the partitioning of the LEON2FT components into manageable blocks that were appropriate to use with meta-data descriptions. This part also investigated alternatives on how to configure the RTL system based on a XML meta-data description of an assembled system.
In a second step the IP-XACT XML descriptions were developed with help from an IP-XACT packaging tool from Magillem Design Services. A generator, a plug-in application for IP-XACT design environments, to create the LEON2FT HDL configuration file was also developed.
The final step included the validation of the XML descriptions and of the generator and production of a user's manual. Validation was performed by using checkers and validation functionality in IP-XACT tools from Magillem Design Services and Synopsys.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
Depending on the intended usage scenario of the LEON2FT XML descriptions, certain structures and packaging may be more appropriate than others. During the analysis and specification phase three alternatives to dividing a LEON2FT system into manageable blocks, and two alternatives of configuring the system based on the XML meta data were evaluated.
The selected granularity of the XML descriptions was to describe each core in the LEON2FT distribution with a separate XML description. This allows a designer to tailor the contents of a system and it also simplifies extracting IP cores from the LEON2-FT distribution and re-using them in other designs. The unit compromising the LEON2FT processor was specified to be described as one single entity as it is improbable that parts of the processor will be reused in new designs with the help of automated assembly due to the tight coupling between blocks in the LEON2FT processor.
6.3.2 Development of the Descriptions and Generator
Development of the descriptions was done with the division of blocks identified during the analysis and specification phase. Initial versions of the descriptions were automatically generated with the help of an IP-XACT packager tool from Magillem Design Services. The generated descriptions were then edited to remove parameters that had been detected as configurable and replacing these parameters with the parameters applicable to each component in the LEON2FT configuration HDL file. This also included added documentation of all parameters in the XML descriptions.
During the development phase a preliminary review was held. The review resulted in design comments that were incorporated in the final version of the descriptions.
In parallel with the production of the XML descriptions, an IP-XACT generator that produces the LEON2FT HDL configuration file was developed.
6.3.3 IP-XACT Component Descriptions
The IP-XACT component descriptions produced are listed in the table below. Each component is presented by a short description of its use together with notes about the IP-XACT description. An IP-XACT component description is an IP-XACT representation of an IP core described in VHDL. The IP core in question can either be an IP core from the LEON2FT VHDL distribution or an IP that contains bus fabric that is needed to use the IP cores in an IP-XACT design environment.
Component Description
AHBBUS The AHBBUS component contains the LEON2FT AHBARB core. The AHBARB core reads its address map from the LEON2FT HDL configuration file and therefore a design can only contain one instance of the AHBBUS component.
AHBRAM The AHBRAM core is an AHB slave. Its address is set via parameters that are read out by the LEON2FT configuration generator and are used for generating the address map in the bus fabric.
AHBSTAT The AHB status register does not have any component specific configurable parameters (apart from the settings for fault tolerance). This means that any number of instances of the
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
APBBUS The APBBUS component represents the APBMST core together with bus fabric for connection 16 APB slaves. The APBMST core reads its address map from the LEON2FT configuration HDL file and therefore a design can only contain one instance of the APBBUS component.
CLKGEN The CLKGEN component represents the LEON2FT clock generator. The clock generator core receives its clock scaling factors from the LEON2FT configuration HDL file and therefore a design can only have one type of clock generator. All instances will have the same characteristics.
CLOCKBUS The CLOCKBUS component describes bus fabric for clock distribution. The included logic only contains interconnections.
DCOM Describes the Debug Communications Unit / Debug Serial Link. The DCOM component does not have any component specific configurable parameters (apart from the settings for fault tolerance). This means that any number of instances of the DCOM component can be present in a design.
DEBUGBUS The DEBUGBUS component contains bus fabric for clock distribution. The included logic only contains interconnections. The component has one interface that should be connected to a IRQCTRL component and two interfaces that should be connected to the processor, PROC, and the Debug Support Unit, DSU.
DSU Describes the Debug Support Unit. To reduce the number of parameters that need to be set for each core, the DSU description does not have parameters to set target technology and the choice infer RAM. It is assumed that the DSU will only be instantiated when the LEON2FT processor is present and the configuration file can be built using the parameters set for the processor. The DSU component has component specific configurable parameters that are propagated from the LEON2FT configuration HDL file. This means that all instances of the DSU component in a design will have the same characteristics.
INTPROCBUS The INTPROCBUS component contains bus fabric for connecting interrupt related signals between the components IRQCTRL, PROC and DSU. The included logic only contains interconnections. The component has one interface that should be connected to a IRQCTRL component and two interfaces that should be connected to the processor, PROC, and the Debug Support Unit, DSU.
IOPORT Describes the LEON2FT general purpose I/O port core. The IOPORT component does not have any component specific configurable parameters (apart from the settings for fault tolerance). This means that any number of instances of the IOPORT component can be present in a design.
IRQCTRL The interrupt controller component has 15 interrupt slave interfaces. The IRQCTRL component does not have any component specific configurable parameters (apart from the settings for fault tolerance). This means that any number of instances of the IRQCTRL component can be present in a design.
IRQCTRL2 The extended interrupt controller component has 32 interrupt slave interfaces. All instances of the IRQCTRL2 component will use the same configuration since the core's configuration is specified in the LEON2FT configuration HDL file.
LCONF Describes the LEON Configuration register core. This component does not have any configurable parameters. Any number of instances can exist in a design.
MCTRL Describes the LEON2FT memory controller core. The MCTRL component has component specific configurable parameters that are propagated from the LEON2FT configuration HDL file. This means that all instances of the MCTRL component in a design will have the same characteristics.
MCTRLIOBUS The MCTRLIOBUS component contains bus fabric for connecting signals from MCTRL to AHBSTAT and IOPORT components. The included logic only contains interconnections.
PROC The PROC component describes the LEON2FT processor. Since the processor reads its
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
configuration from the LEON2FT configuration HDL file it is not possible to have two instances of the processor component with different configurations.
PROC-OCP The PROC-OCP component describes the LEON2FT processor with an OCP interface. The component's configurable parameters are identical to the PROC component's parameters with the exception of the setting for AHB snooping. LEON2FT-OCP does not support snooping and therefore the configuration option has been removed.
RESETBUS The RESETBUS component describes bus fabric for clock distribution. The included logic only contains interconnections.
RSTGEN Describes the LEON2FT reset generator core. The reset generator has a number of signals that must be connected although they are not included in any of the component's bus interfaces.
TIMERS Describes the LEON2FT timer unit. The TIMERS component has component specific configurable parameters that are propagated from the LEON2FT configuration HDL file. This means that all instances of the TIMERS component in a design will have the same characteristics.
UART Describes the LEON2FT 8-bit UART. The UART component has component specific configurable parameters that are propagated from the LEON2FT configuration HDL file. This means that all instances of the UART component in a design will have the same characteristics
WPROT Describes the LEON2FT write protection unit. This component does not have any component specific configurable parameters. Any number of instances can exist in a design.
Table 5 : IP-XACT Components of the LEON2FT IP-XACT distribution
All components that represent a LEON2FT core requiring information from the LEON2FT HDL configuration file have the LEON2FT TGI Configuration Generator associated with them. Due to difficulties in determining if the generator should be run, the generator will be run once for each type of component that is instantiated. This does not pose a problem since the generator does not change any state in the design and will only result in a delay when creating the design. The generator is described in the following section.
Since most of the LEON2FT cores receive their configuration via the LEON2FT HDL configuration file, it may not be possible to have multiple instances with different parameterization. In many instances the only characteristic that may differ is the address map. The table above indicates if multiple instances of a component are allowed.
The views and file sets have been organized following the same organization as for the Spacewire descriptions (one view per usage, one file set per consistent set of files).
6.3.3.1 Bus Definitions
The LEON2FT IP-XACT distribution requires a number of bus and abstraction definitions. The following definitions have been developed for the LEON2FT IP-XACT descriptions:
AbstractionDefinition/BusDefinition
Description
CLOCK_rtl/CLOCK Interface specification used for clock distribution.
DEBUG_rtl/DEBUG Interface specification allowing the DSU, DCOM and TIMERS components to be connected together using the DEBUGBUS component.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
INTERRUPT_rtl/INTERRUPT Specifies interface that allows components to be connected to the interrupt controller.
INTPROC_rtl/INTPROC An INTPROC interface is present on the IRQCTRL, PROC, PROC-OCP and DSU components. The IRQCTRL component can be directly connected to a processor component, or to a processor and DSU via the MCTRLIOBUS component.
IO_rtl/IO IO is used in the IOPORT component to group the PIOL signal and the PCI_ARB_REQ_N vector.
IU_rtl/IU IU is used in interfaces on that connect the PROC and PROC-OCP components to the DSU component.
MCTRLIO_rtl/MCTRLIO This definition is used in interfaces so that MCTRL can be connected to the AHBSTAT component or the IOPORT component, or both via a MCTRLIOBUS component.
MEMORY_rtl/MEMORY The memory interface is present on the MCTRL component and is used to group signals that are used to connect to a off-chip memory device together
MEMPROT_rtl/MEMPROT The MEMPROT bus contains the signals that connect the WPROT component to the MCTRL component.
PIO_rtl/PIO The PIO bus contains signals that connect the IOPORT and MCTRL components.
RESET_rtl/RESET The RESET bus describes two ports, a reset signal and a reset vector, and is intended to be used with a bus component that distributes the designs reset signal from the LEON2FT reset generator to all LEON2FT cores.
SDRAM_rtl/SDRAM The SDRAM definitions are used in the LEON2FT MCTRL component to group the signals that are specific for connection SDRAM devices.
SERIAL_rtl/SERIAL The SERIAL definitions contain ports for the LEON2FT UART's serial communications. Bus interfaces that use SERIAL is present on the UART and IOPORT components.
Table 6 : Bus definitions of the LEON2FT IP-XACT distribution
6.3.4 LEON2FT Configuration TGI Generator
The LEON2FT Configuration TGI Generator is interfaced via the Tight Generator Interface (TGI). This generator reads parameters from the design and creates a LEON2FT configuration HDL file. The generator will check if there are any LEON2FT IP-XACT components in the design, read out their parameter settings and create a LEON2FT configuration HDL file that contains the configuration data for the system. The LEON2FT configuration HDL file will be created in the design environment's working directory.
The LEON2FT Configuration TGI generator is associated to each component that requires configuration data from the LEON2FT configuration HDL file.
To generate the AHB and APB memory maps, the generator asks the design environment (DE) for a list of all interconnections in the design. For each connection it checks if one of the active interfaces belongs to the AHBBUS or APBBUS component. If a component is connected to a mirrored slave interface on either bus, the generator will ask the DE for the component's memory map settings (however, the generator will disregard the interfaces intended for snooping on the AHBBUS component). If a memory
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
map named AHB_MMAP is found for a component connected to the AHBBUS, or a memory map named APB_MMAP is found for a component connected to the APBBUS, the generator will look at the memory map's addressBlock identifier. The base address and range of the addressBlock will be used together with the index of the bus interface, to build the slave address map in the LEON2FT configuration HDL file.
6.3.5 Verification
The validity and compliance of the models to the SPIRIT specification was verified by means of running schema compliance checks, general checkers and validation functions in tools from Magillem Design Services and Synopsys. Violations and warnings from both tools resulted in modifications of the XML descriptions. Remaining warnings and violations reported by the tools are described and explained in the LEON2FT IP-XACT package documentation.
Validation of the generator was performed by generating configuration HDL files based on XML descriptions of designs containing a subset of the components included in the LEON2FT distribution. The generated HDL file was then inspected and compile tested.
6.4 AMBA-OCP BRIDGES IP-XACT PACKAGING
The AMBA-OCP Bridges IP-XACT package contains four IP-XACT descriptions (one per AMBA-OCP Bridge) and two TGI generators: "CheckOCPParameters" and "info".
6.4.1 IP-XACT Descriptions
The IP-XACT descriptions contain the following information:
• The IP ports list
• The bus interfaces list
• The connections between the IP ports and the bus interface signals
• The hardware parameters
• The different views on which the design environment can work
• The different file sets (source code, documentation, synthesis scripts & constraints, etc.)
The bus interfaces correspond to the AMBA/OCP interfaces (namely: AHB, APB, H-Socket and P-Socket).
Concerning the memory map, no registers are present inside the bridges, however there is a routing table specifying the routing table from a slave interface to a master. This information enables linking memory interfaces such as register maps through the bridges.
The views and file sets have been organized following the same organization as for the Spacewire descriptions, so that:
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
• a file set references a consistent set of files (for example, all the VHDL source code, all the simulation or synthesis scripts, ...)
• a view is related to a particular usage or activity (Documentation, Simulation, ASIC/FPGA synthesis)
• a file set can be included in multiple views (for example, the VHDL source code is used for simulation but also synthesis)
Thus, the AMBA-OCP Bridges descriptions views and file sets are organized as follows:
• Documentation View
o Documentation File Set
• Compilation View
o VHDL_source File Set
• Simulation View
o VHDL_source File Set
o Testbench File Set
o Simulation_scripts File Set
o Simulation_logs_reports File Set
• ASIC_synthesis View
o VHDL_source File Set
o ASIC_synthesis_scripts File Set
o ASIC_synthesis_reports File Set
• FPGA_synthesis View
o VHDL_source File Set
o FPGA_synthesis_scripts File Set
o FPGA_synthesis_reports File Set
6.4.2 TGI Generators
Two TGI generators have been produced during this activity for the bridges. The first generator is "CheckOCPParameters". It checks that all the OCP interfaces of the component are connected to a compatible OCP socket. Indeed, since the OCP socket is highly configurable, different sockets with different parameters can be used in a design. To avoid mistakes, the compatibility between two connected OCP sockets must be checked. This is the purpose of the "CheckOCPParameters" generator.
CharNb 71838 WordNb 12920 FileName R&D DCO RP 01253 E ASTR 0-0.doc
The second generator is named "info". It prints details about the core in the console.
6.4.3 Verification
The Magillem SPIRIT Design Environment includes a checker, which implements all the semantic and syntactic checks defined by the SPIRIT consortium. The IP-XACT descriptions of the AMBA-OCP Bridges have been checked with this checker. The generators have been verified functionally in the Magillem SPIRIT Design Environment.
7 CONCLUSION
The outcomes of this activity provide ESA with building blocks: OCP sockets and IP-XACT packages for key IP Cores used in space applications (LEON2FT and Spacewire CODEC), and also AMBA-OCP protocol converters. This study also provides preliminary performance and design overhead assessments for further work on the OCP and IP-XACT technologies.
OCP interfaces proved to be less complex than AMBA for equivalent communication functionnalities, since arbitration and similar bus-specific services are centralized in the interconnect instead of being distributed over all the IP Cores. This reduces bug risk and design cost. However, there are a lot of different OCP configurations possible, and AMBA is more widespread.
An original implementation of LEON2FT with two master sockets (one for each cache) has been issued, for use with multi-layered interconnects.
SPIRIT IP-XACT, which was an emerging industry standard, recently became an IEEE standard. It seems to be a very promising technology for packaging, exchanging and integrating IP Cores. This activity focused on the packaging stage. With the packages produced, the utility of IP-XACT can be demonstrated by assembling and configuring these cores within a graphical SPIRIT Design Environment, by generating the corresponding top-level VHDL file, and also by generating the SW description of the registers and the register documentation (the advantage being that the various register descriptions/documentations are kept consistent at a minimum cost).
