US20030204830A1 - Integrated circuit configuration - Google Patents

Integrated circuit configuration Download PDF

Info

Publication number
US20030204830A1
US20030204830A1 US10/406,229 US40622903A US2003204830A1 US 20030204830 A1 US20030204830 A1 US 20030204830A1 US 40622903 A US40622903 A US 40622903A US 2003204830 A1 US2003204830 A1 US 2003204830A1
Authority
US
United States
Prior art keywords
data
configuration
integrated circuit
memory
bios
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/406,229
Inventor
Jonathan Brawn
James Alphey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ARM Ltd
Original Assignee
ARM Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ARM Ltd filed Critical ARM Ltd
Priority to US10/406,229 priority Critical patent/US20030204830A1/en
Publication of US20030204830A1 publication Critical patent/US20030204830A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4411Configuring for operating with peripheral devices; Loading of device drivers

Definitions

  • This invention relates to integrated circuits. More particularly, this invention relates to integrated circuits including a plurality of data processing circuit elements having a variable configuration.
  • an integrated circuit comprising:
  • configuration logic operable upon initialisation of said apparatus to read said configuration data from said configuration memory and to determine therefrom configuration parameters of said integrated circuit for setting up configuration program software controlling interaction between application program software and said plurality of data processing circuit elements.
  • the invention recognises that there are considerable advantages to be gained by storing configuration data within the integrated circuit hardware itself and having the system use this data to set up the interaction between the hardware and application software when the integrated circuit is initialised.
  • the configuration program software such as BIOS software, can be generic over a wide variety of integrated circuit devices whilst setting up the particular configuration of a device upon which it is to operate from the configuration memory of that device. This considerably reduces the development and testing time needed for the configuration program software to be used on each device and allows changes to be made to the configuration of the device in a much more straightforward manner.
  • system-on-a-chip devices include a processor core responsive to program instructions. Such devices have a high degree of flexibility in the operations they perform.
  • configuration logic operable upon initialisation can be provided in the form of the processor core operating the control of initialisation program instructions. Whilst this may in practice be the most likely way in which the configuration logic is embodied, it would also be possible to provide special purpose hardware to form the configuration logic.
  • configuration data can take a very wide range of forms and include a wide range of levels of detail.
  • particularly preferred data useful in establishing the operation of the integrated circuit is as follows:
  • a capacity value of a data memory present
  • a page size of a data memory present
  • the configuration memory could take a variety of forms. It could take the form of embedded special purpose circuit elements that may be read under software control. However, the configuration memory is preferably provided in the form of a more generic read only memory in which the configuration data is fixed at manufacture. Such an arrangement allows the configuration data to be more easily changed relatively late in the design of an integrated circuit.
  • the configuration data is encrypted.
  • a further problem in developing system-on-a-chip designs is that individual minor variants of the configuration of the system can require considerable effort to be expended in modifying the software that will control that system. Furthermore, there are many different ways in which a highly integrated system may be documented and described which has the result that re-use of previously generated designs is made more difficult.
  • the present invention claims a method of describing an integrated circuit having a plurality of circuit elements and associated configuration parameters, said method comprising the step of:
  • the present invention recognises that by applying a rigorous methodology to the way in which an integrated circuit is described significant advantages may be realised.
  • a human readable description formed in accordance with a predetermined hierarchical syntax allows the possibility for subsequent machine interpretation of that written description in a manner that may be used to automatically generate data or software for controlling the system.
  • minor configuration changes may be made in the human readable description and these changes automatically interpreted (in a process analogous to program compilation) to form configuration data or controlling software for the system.
  • the predetermined hierarchical syntax in which the integrated circuit is described makes the re-use of previously generated designs easier since another designer may more readily understand and appreciate the level of detail they require within a particular pre-existing design without having to search through a description in a individual form produced by a particular author.
  • the hierarchical form allows the possibility for multiple levels within the description with one or more dependent entries stemming from a higher order entry.
  • the depth of the hierarchy may vary depending upon the particular path taken through the hierarchy.
  • a preferred entry form found to be well suited to the description of integrated circuits is one in which each entry specifies order, type and value for an entity at that level.
  • the present invention provides a method of configuring an integrated circuit having a plurality of data processing circuit elements and a configuration memory storing configuration data describing said plurality of data processing elements, said method comprising the steps of:
  • An alternative aspect of the present invention is a computer program storage medium bearing a computer program for controlling an integrated circuit to perform the above described techniques.
  • the human readable description of the system may also be used to control physical configuration of the system, such as controlling the layout or other physical parameters.
  • a design flow may use the description to generate SoC (system on a chip) configuration files and the SoC tools to layout controlling data.
  • the description data could also be passed to debug tools. By passing the SoC description to debug tools, those tools may access the physical SoC using standard mechanisms and then use the description to interpret, format and/or label returned values.
  • FIG. 1 schematically illustrates an integrated circuit including a plurality of data processing circuit elements
  • FIG. 2 schematically illustrates the relationship between software elements within a data processing system
  • FIG. 3 is a flow-diagram illustrating the initialisation of an integrated circuit
  • FIG. 4 illustrates a hierarchical description of an integrated circuit
  • FIG. 5 illustrates a design process for an integrated circuit
  • FIGS. 6 to ? illustrate further features of one example embodiment of the invention.
  • FIG. 1 illustrates an integrated circuit 2 that is of a type referred to as a system-on-a-chip device.
  • the integrated circuit 2 includes a processor core 4 , a data memory 6 , a first peripheral 8 , a second peripheral 10 , a configuration data memory 12 and a software subroutine library memory 14 . These individual data processing circuit elements are all linked by a bus 16 .
  • the processor core 4 has associated identifying data that is included within the configuration data stored in the configuration data memory 12 .
  • the data identifying the processor core may be useful in establishing which instruction set it is operating or which capabilities the processor core 4 has.
  • the data memory 6 has associated configuration data indicating what type of memory it is (e.g. RAM, ROM, Flash, etc), as well as its storage capacity and page size. Memory management data may also be included within the configuration data indicating whether all or parts of the data memory 6 are cacheable, bufferable, and subject to read/write restrictions.
  • the first peripheral 8 and the second peripheral 10 give rise to configuration data within the configuration memory 12 identifying which peripheral they are, their configuration (such as interrupt data and memory address data) as well as other information required for the integrated circuit 2 to properly use the peripheral 8 , 10 . It will be appreciated that there is considerable flexibility in the number and type of the peripheral devices 8 , 10 that may be provided within the integrated circuit 2 and that these peripheral devices 8 , 10 may come from different suppliers and design sources, such that the ability to at least partially abstract their interaction with the other portions of the system into the configuration data is highly advantageous.
  • the software subroutine library memory 14 is indicated as present within the configuration data and configuration data is also included indicating the location and size of a data heap within the data memory 6 that can be used by the software subroutines in the library 14 .
  • the configuration data memory 12 is shown in FIG. 1 in the form of a read only memory.
  • a read only memory can be programmed with the necessary configuration data using standard techniques.
  • special purpose circuit elements such as registers that can be read, may be provided to store the configuration data.
  • the configuration data can be encrypted using various known encryption techniques.
  • FIG. 2 schematically illustrates the relationship between software elements and the hardware within the example device.
  • the device may execute several application programs 18 , 20 , 22 .
  • These application programs 18 , 20 , 22 interact with the operating system 24 .
  • the operating system 24 provides the function of interacting and controlling the various hardware elements of the device 2 .
  • the operating system 24 may communicate directly with the device 2 for some services, but a large number of services will be provided via a basic input/output system software layer 26 .
  • This basic input/output system software layer 26 allows for the possible use of a variety of different operating systems 24 for a given design of device 2 .
  • the initialisation program instructions 28 that control the reading of the configuration data memory 12 and the setting up of the basic input/output system software 26 are embedded within the basic input/output system software 26 itself.
  • the initialisation program instructions are executed to read the configuration data from the configuration data memory 12 and set up appropriate parameters for the various data processing circuit elements of the device 2 in the basic input/output system software 26 .
  • FIG. 3 is a flow-diagram illustrating the initialisation of the device 2 .
  • the device 2 is initialised by the switching on of power or a hardware reset.
  • the configuration data from the configuration data memory 12 is read under control of the initialisation program 28 .
  • the initialisation program 28 uses the configuration data it has read to configure the basic input/output system software 26 with the variable parameters of the data processing circuit elements indicated as being present within the device 2 .
  • the initialisation of the device 2 has been completed and processing control is passed to the operating system 24 . Alternatively, the configuration of the system may not be completed until after handover of control to the operating system.
  • FIG. 4 illustrates a hierarchical description of an integrated circuit.
  • an individual system-on-a-chip (SoC) system forms the highest level within the description. Beneath this highest level the components are first divided into the clock, microprocessor core, memory system, coprocessor and I/O systems. Some of the entries at this high level may not need to be further described and it is sufficient to associate type and value data with these entries in order to rigorously define the system.
  • the core and coprocessor entries may be sufficiently defined by specifying the core as an ARM9 core and the coprocessor as a vector floating point unit. The design tools that will subsequently be responsive to this description do not need any further information regarding these particular entities other than that specified.
  • an entity such as the memory may be further divided into entities describing the presence or absence of an MMU (with associated parameters), a cache memory, a read only memory and a random access memory.
  • the I/O devices may be subdivided into individual types with their particular parameters such as address, interrupt and the like associated therewith. It will be appreciated that the description illustrated in FIG. 4 is highly simplified and that in reality many more entries and levels will be present within a typical system description with a fine level of detail regarding the configuration parameters.
  • FIG. 5 schematically illustrates the design process using the hierarchical syntax.
  • the human readable description 40 is in the form of an editable text file written in accordance with the ASN.1 syntax (it will be appreciated that other description formats, such as XML, could also be used). A designer can modify elements within this editable text simply using a standard text editor to alter the description of the system to suit a particular requirement.
  • a software tool may be used to interpret this description and generate a configuration datafile 42 representing in a compact form the configuration of the system. This configuration data may then be encrypted prior to being stored within the configuration data memory 44 of a system 46 to which it relates.
  • BIOS basic input/output system
  • BIOS basic input/output system
  • SoC BIOS (‘microBIOS’) is an ARM solution to support peripheral input and output (I/O) and abstraction in a flexible manner, so simplifying porting between platforms and reducing time-to-market.
  • driver code includes an encoding of aspects of the system in which the driver lies.
  • SoC BIOS separates the system design and code implementation paths.
  • SoC BIOS incorporates a flexible mechanism for accessing a system description.
  • SoC BIOS supports abstraction of underlying hardware, such as core variants.
  • SoC BIOS adds value with a number of run-time features for I/O support.
  • AFS ARM Firmware Suite a set of board-support components
  • API Application Programmers Interface the interface presented by SoC BIOS to the Implementor.
  • BIOS Basic Input/Output system code controlling initialisation and functionality of peripherals.
  • GPI Generic Peripheral Interface, used to perform peripheral control
  • PDB Peripheral Definition Block This defines the peripherals to be supported.
  • PIB Peripheral Information Block This specifies details of one peripheral.
  • ROM Read Only (non-writeable) storage generally including programmable (Flash) storage
  • SIB System Identification Block A header of on-chip or on-board identification data.
  • HAL micro Hardware Abstraction Layer A low-level abstraction library supplied as freeware by ARM with the Integrator demonstration system. Part of AFS
  • SoC BIOS offers the following:
  • driver code includes an encoding of aspects of the system in which the driver lies.
  • SoC BIOS separates the system design and code implementation paths.
  • SoC BIOS incorporates a flexible mechanism for accessing a system description.
  • SoC BIOS supports abstraction of underlying hardware, such as core variants.
  • SoC BIOS adds value with a number of run-time features for I/O support
  • SoC BIOS will simplify both porting and maintaining the RTOS on a range of platforms.
  • OSDs operating system compatible device drivers
  • the SoC BIOS feature set is designed to function as a stand-alone BIOS, offering a complete package for initialisation and control.
  • the high level abstracted model is intended to reduce design time for an application designer.
  • SoC BIOS supplies a number of features to simplify porting.
  • SoC BIOS Platform independence—SoC BIOS offers a configured and stable platform to the application. This reduces the need for the application to communicate directly with the underlying hardware or to support hardware variants.
  • SoC BIOS will offer a higher level of functionality than AFS, both by including further high level functions and by reducing the need for the application to access the system at a very low level.
  • SoC BIOS will include an interface for generic control of system peripherals, while AFS offers support for the specific functions known to be generally available on development boards.
  • SoC BIOS will be a separate entity, resident on-board or on-chip, rather than a library of control functions. System details are separately specified by the system designer and interpreted at run-time. The application then interacts with SoC BIOS at run-time in a DLL-like manner. This simplifies the design path and helps to ensure that the encoded configuration matches the actual system.
  • Any peripheral driver may be built into the SoC BIOS and its API will then be available. However, to be integrated within SoC BIOS, the driver must be extended to at least the most basic functions of the Generic Peripheral Interface (see below).
  • SoC BIOS build will be designed initially to be built with ADS (ARM Developer Suite). It is intended that the project code will eventually be compatible with other development environments (at least GNU tools), but the first release will be for ADS only.
  • ADS ARM Developer Suite
  • SoC BIOS project will conform to the Software Systems coding standard and will be assigned project identifier ab.
  • SoC BIOS separates the process of specifying the target system from the writing of code, and separates BIOS code from application (or RTOS) code. This gives defined areas of development, which are usually addressed by developers with different skills and knowledge.
  • the system description is an encoded specification of the system and peripherals. It is encoded as a block of data whose format is defined as an ASN.1 abstract syntax structure. This is a formal definition of the structure format and types. The associated value notation is used to present the system description in a human-readable form.
  • the specification data is bound as closely as possible to the system that it describes. It may be available directly from the system (on-chip or in non-volatile memory), but in the absence of this data, an in-build copy (encoded as part of the build procedure) will be used.
  • BIOS functionality is shown as 3-D boxes.
  • the API sits over a number of run-time modules.
  • System configuration draws in data from a range of sources to configure peripherals through the GPI.
  • the implementation communicates with the peripherals through the GPI, or directly through the driver API where required.
  • SoC BIOS is spilt into several parts.
  • the manager code is fully position independent and can be relocated at run-time if required. It is likely that it can be supplied as object code.
  • peripheral drivers which support the GPI (see below) can be integrated into SoC BIOS. These are built as a separate functional block to the SoC BIOS manager.
  • the peripheral driver block includes all drivers to be included in SoC BIOS and so must be rebuilt when the included set of drivers is changed.
  • SoC BIOS is intended to function with both polling and interrupt-driven drivers.
  • PDDs Physical Device Drivers
  • OSD wrapping driver
  • SoC BIOS may access any peripheral to perform a number of generic functions that are (potentially) applicable to all peripheral types.
  • the system used is termed the Generic Peripheral Interface (GPI).
  • GPI Generic Peripheral Interface
  • the GPI is a layer of functionality that is added to a driver to allow that driver to interact with the BIOS.
  • the GPI offers a standardised interface that will support functionality that already exists in the driver.
  • the GPI consists of the functions below. It is not necessary for a driver to implement all of the GPI functions, but there is a dependency tree as shown below. For example, if a driver implements the GPI Self Test function it should also implement the Initialize and Get Memory Requirements functions.
  • peripherals are identified by a file name built from the driver type name and user-specified number (for example ‘UART100’).
  • the number is specified in the system description and may be arbitrary or may reflect the location of the peripheral in the system or the target to which it is attached.
  • SoC BIOS can send generic messages to peripherals by using the tagging and messaging system of GPI.
  • the application may tag and untag all peripherals, one class of peripheral or one peripheral and messages will be distributed to all tagged peripherals.
  • a designated ‘supervisor’ peripheral may be assigned. This will be notified of all messages and their targets. It may intervene to handle messages itself, either in addition to, or instead of, the driver function. For example, on a system with no power controller, ‘power save’ messages would be passed to the drivers. By declaring a power controller in the system description, the messages would automatically be handled there instead.
  • the driver may include a self test function. A number of different levels of test may be supported. The areas tested will depend on the peripheral, but a basic self test will probably not extend beyond writing to, and reading from, certain registers.
  • the self test function will be executed for each peripheral after initialisation. If the peripheral fails self test, it will be marked as unavailable to the system and not used.
  • driver API will be made public to the application, should the application wish to access the driver directly, rather than through standard I/O. This is intended to allow peripheral-specific functions to be used, such as setting data transfer parameters. It is not intended that standard I/O and direct driver API I/O be used in parallel for data transfer from the same peripheral and results will be unpredictable.
  • BIOS BIOS When building development software to use on a SoC BIOS system, the software links against a library in which BIOS or peripheral API calls are replaced by stub functions. These use a SWI mechanism to pass function identifiers to the BIOS.
  • SoC BIOS build can remain system-resident and need not be rebuilt with the application
  • SoC BIOS can itself access GPI functions for the peripheral drivers.
  • the basic stub handling is as below.
  • the stub handler handles StubID calls from SoC BIOS stubs, matching these against routines in a lookup table built into the code.
  • a SoC BIOS system specification may specify a number of Expansion Link Addresses (ELA).
  • ELA Expansion Link Addresses
  • a valid SoC BIOS extension will reflect the addition of extra peripheral hardware, and will include a peripheral data block (PDB) and possibly a stub lookup table (SLT) to add further drivers.
  • PDB peripheral data block
  • SLT stub lookup table
  • BIOS will direct stub calls to the drivers built into the BIOS, or to extension areas, as appropriate.
  • ELAs allow further peripherals to be fully integrated into the BIOS.
  • SoC BIOS (‘microBIOS’) is an ARM solution to support I/O and abstraction in a flexible manner, so simplifying porting between platforms and reducing time to market. This document describes the SoC BIOS run-time data encoding. The SoC BIOS encodes a system description as data, which is retrieved
  • BIOS basic input/output system
  • BIOS basic input/output system
  • SoC BIOS (‘microBIOS’) is an ARM solution to support peripheral input and output (I/O) and abstraction in a flexible manner, so simplifying porting between platforms and reducing time-to-market.
  • This document specifies the encoding used for the SoC BIOS system configuration data. This data is at runtime to identify and configure features of the system being used.
  • Each system will be specified by a set of data in a defined structure.
  • the format currently chosen is the telecommunications standard ASN.1, using ASN.1 ‘value notation’ to describe each system—this may later change, and there has been a proposal to move to XML format. This will be reviewed later in the project.
  • the human-readable data is then encoded into a machine-readable form for access by the BIOS.
  • the Basic Encoding Rules (BER) of ASN.1 define an encoding format for data defined within ASN.1.
  • SoC BIOS will use a modified form of this encoding, to allow for the limited requirements of the BIOS data.
  • BER uses a TLV (Type, Length and Value) encoding system, where each element is encoded with an identifying type, an indication of the length of the element, and then the element value.
  • This value may consist of nested TLV sets (for ‘constructed’ types). This system is ideal for partial decoding, allowing access functions to retrieve and return a single element from the encoded block with relative ease.
  • the decoder in SoC BIOS can locate the elements and return them on request by access functions, avoiding the need for assigning space to decode the entire block (which is the usual method used with ASN.1 encoding).
  • the Type and Length encoding used will be more compact than for BER, since type checking will not be required.
  • the top bit of each byte will be an ‘extension’ bit, indicating that at least one further byte of length encoding data remains.
  • the remaining six bits of the first byte and seven bits of following bytes are concatenated to form the length value.
  • the first byte represents the highest bits.
  • An example is in See Figure, which represents a sequence of length 0011111001011 (binary) or 1995 bytes.
  • SoC BIOS will retrieve all encoded data as word accesses, so avoiding issues of byte endian-ness.
  • ASN.1 encodes data as byte sequences. It requires that the most significant byte of INTEGER values be transmitted first.
  • SoC BIOS is defined to offer four possible formats of encryption of the specification data.
  • the final product may support any one or more of these formats.
  • This format is intended to offer a simple encryption on a word-by-word basis. It has not yet been defined.
  • This format is intended to offer an improved encryption in two word blocks.
  • the TEA algorithm will probably be used. This encodes 64 bit data using a 128 bit key and source code for encryption and decryption is publicly available.

Abstract

An integrated circuit containing a plurality of data processing circuit elements 4, 6, 8, 10, 12, 14 and 16 is provided with a configuration data memory 12. Upon initialisation of the integrated circuit 2, configuration data is read from the configuration data memory 12 and used to set up configuration program software 26 that controls the interaction between application program software 18, 20, 22 and the integrated circuit 2. The configuration data is automatically formed from a human readable hierarchical description of the integrated circuit 2 in the form of an ASN.1 description.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0001]
  • This invention relates to integrated circuits. More particularly, this invention relates to integrated circuits including a plurality of data processing circuit elements having a variable configuration. [0002]
  • 2. Description of the Prior Art [0003]
  • The trend towards higher levels of integration within data processing systems has led to many more data processing circuit elements being included on a single integrated circuit. For example, so called system-on-a-chip integrated circuits may typically include a processor core, on-chip memory, several peripheral devices, timers and the like such that few additional components are required outside of the integrated circuit to make a functioning device. It will be appreciated that there are many possibilities for different data processing circuit elements that may be included within a single integrated circuit and that these data processing data elements may be configured in a variety of different manners to suit the particular device being produced. [0004]
  • At the same time as the trend towards system-on-a-chip designs, there is also a strong desire to reduce the development time for new devices. A significant amount of time in the development of a new device may be expended in writing and testing software, such as, for example, BIOS software, that controls the low-level interaction between the various hardware elements with the specific parameters of a particular system-on-a-chip design. It will be further appreciated that if a mistake is made in the way in which an integrated circuit is configured for manufacture, then this can be extremely expensive to rectify. [0005]
  • SUMMARY OF THE INVENTION
  • Viewed from one aspect the present invention provides an integrated circuit comprising: [0006]
  • (i) a plurality of data processing circuit elements; [0007]
  • (ii) a configuration memory storing configuration data describing said plurality of data processing elements; and [0008]
  • (iii) configuration logic operable upon initialisation of said apparatus to read said configuration data from said configuration memory and to determine therefrom configuration parameters of said integrated circuit for setting up configuration program software controlling interaction between application program software and said plurality of data processing circuit elements. [0009]
  • The invention recognises that there are considerable advantages to be gained by storing configuration data within the integrated circuit hardware itself and having the system use this data to set up the interaction between the hardware and application software when the integrated circuit is initialised. The configuration program software, such as BIOS software, can be generic over a wide variety of integrated circuit devices whilst setting up the particular configuration of a device upon which it is to operate from the configuration memory of that device. This considerably reduces the development and testing time needed for the configuration program software to be used on each device and allows changes to be made to the configuration of the device in a much more straightforward manner. [0010]
  • It will be appreciated that the provision of the configuration memory within the integrated circuit runs counter to the technical prejudice within the integrated circuit field of reducing the circuit element and gate count of an integrated circuit as much as possible. However, the advantages of the present invention more than justify the increased gate count of providing such an on-chip configuration memory. [0011]
  • It will be appreciated that the divisions between the functionality provided by different software elements in a system are often not clear cut, but in many preferred embodiments of the invention the configuration program software is basic input/output system software. [0012]
  • Many system-on-a-chip devices include a processor core responsive to program instructions. Such devices have a high degree of flexibility in the operations they perform. Within such systems the configuration logic operable upon initialisation can be provided in the form of the processor core operating the control of initialisation program instructions. Whilst this may in practice be the most likely way in which the configuration logic is embodied, it would also be possible to provide special purpose hardware to form the configuration logic. [0013]
  • It will be appreciated that the configuration data can take a very wide range of forms and include a wide range of levels of detail. However, particularly preferred data useful in establishing the operation of the integrated circuit is as follows: [0014]
  • Data identifying a processor core [0015]
  • Data identifying type, manufacturer or variant of a system component [0016]
  • Data controlling a Memory Management Unit [0017]
  • Data identifying a type of data memory present [0018]
  • A capacity value of a data memory present [0019]
  • A page size of a data memory present [0020]
  • Access parameters for all or parts of a data memory present [0021]
  • A memory address associated with a data processing peripheral circuit [0022]
  • An interrupt associated with a data processing peripheral circuit [0023]
  • An indication of whether a library of software of routines is present, and [0024]
  • Data heap configuration data for such software routines [0025]
  • The configuration memory could take a variety of forms. It could take the form of embedded special purpose circuit elements that may be read under software control. However, the configuration memory is preferably provided in the form of a more generic read only memory in which the configuration data is fixed at manufacture. Such an arrangement allows the configuration data to be more easily changed relatively late in the design of an integrated circuit. [0026]
  • In order to protect proprietary information regarding how a particular device is configured, it may be preferred that the configuration data is encrypted. [0027]
  • A further problem in developing system-on-a-chip designs is that individual minor variants of the configuration of the system can require considerable effort to be expended in modifying the software that will control that system. Furthermore, there are many different ways in which a highly integrated system may be documented and described which has the result that re-use of previously generated designs is made more difficult. [0028]
  • Viewed from another aspect the present invention claims a method of describing an integrated circuit having a plurality of circuit elements and associated configuration parameters, said method comprising the step of: [0029]
  • (i) generating a description of said integrated circuit using a predetermined hierarchical syntax to form a human readable hierarchical description. [0030]
  • The present invention recognises that by applying a rigorous methodology to the way in which an integrated circuit is described significant advantages may be realised. A human readable description formed in accordance with a predetermined hierarchical syntax allows the possibility for subsequent machine interpretation of that written description in a manner that may be used to automatically generate data or software for controlling the system. Thus, minor configuration changes may be made in the human readable description and these changes automatically interpreted (in a process analogous to program compilation) to form configuration data or controlling software for the system. In addition, the predetermined hierarchical syntax in which the integrated circuit is described makes the re-use of previously generated designs easier since another designer may more readily understand and appreciate the level of detail they require within a particular pre-existing design without having to search through a description in a individual form produced by a particular author. [0031]
  • It will be appreciated that the hierarchical form allows the possibility for multiple levels within the description with one or more dependent entries stemming from a higher order entry. The depth of the hierarchy may vary depending upon the particular path taken through the hierarchy. [0032]
  • A preferred entry form found to be well suited to the description of integrated circuits is one in which each entry specifies order, type and value for an entity at that level. [0033]
  • Viewed from another aspect the present invention provides a method of configuring an integrated circuit having a plurality of data processing circuit elements and a configuration memory storing configuration data describing said plurality of data processing elements, said method comprising the steps of: [0034]
  • (i) upon initialisation of said apparatus, reading said configuration data from said configuration memory; [0035]
  • (ii) determining from said configuration data configuration parameters of said integrated circuit for setting up configuration program software controlling interaction between application program software and said plurality of data processing circuit elements. [0036]
  • An alternative aspect of the present invention is a computer program storage medium bearing a computer program for controlling an integrated circuit to perform the above described techniques. [0037]
  • The human readable description of the system may also be used to control physical configuration of the system, such as controlling the layout or other physical parameters. Thus, a design flow may use the description to generate SoC (system on a chip) configuration files and the SoC tools to layout controlling data. The description data could also be passed to debug tools. By passing the SoC description to debug tools, those tools may access the physical SoC using standard mechanisms and then use the description to interpret, format and/or label returned values. [0038]
  • The above, and other objects, features and advantages of this invention will be apparent from the following detailed description of illustrative embodiments which is to be read in connection with the accompanying drawings.[0039]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 schematically illustrates an integrated circuit including a plurality of data processing circuit elements; [0040]
  • FIG. 2 schematically illustrates the relationship between software elements within a data processing system; [0041]
  • FIG. 3 is a flow-diagram illustrating the initialisation of an integrated circuit; [0042]
  • FIG. 4 illustrates a hierarchical description of an integrated circuit; [0043]
  • FIG. 5 illustrates a design process for an integrated circuit; and [0044]
  • FIGS. [0045] 6 to ? illustrate further features of one example embodiment of the invention.
  • DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • FIG. 1 illustrates an [0046] integrated circuit 2 that is of a type referred to as a system-on-a-chip device. The integrated circuit 2 includes a processor core 4, a data memory 6, a first peripheral 8, a second peripheral 10, a configuration data memory 12 and a software subroutine library memory 14. These individual data processing circuit elements are all linked by a bus 16.
  • The [0047] processor core 4 has associated identifying data that is included within the configuration data stored in the configuration data memory 12. The data identifying the processor core may be useful in establishing which instruction set it is operating or which capabilities the processor core 4 has. The data memory 6 has associated configuration data indicating what type of memory it is (e.g. RAM, ROM, Flash, etc), as well as its storage capacity and page size. Memory management data may also be included within the configuration data indicating whether all or parts of the data memory 6 are cacheable, bufferable, and subject to read/write restrictions.
  • The first peripheral [0048] 8 and the second peripheral 10 give rise to configuration data within the configuration memory 12 identifying which peripheral they are, their configuration (such as interrupt data and memory address data) as well as other information required for the integrated circuit 2 to properly use the peripheral 8, 10. It will be appreciated that there is considerable flexibility in the number and type of the peripheral devices 8, 10 that may be provided within the integrated circuit 2 and that these peripheral devices 8, 10 may come from different suppliers and design sources, such that the ability to at least partially abstract their interaction with the other portions of the system into the configuration data is highly advantageous.
  • The software [0049] subroutine library memory 14 is indicated as present within the configuration data and configuration data is also included indicating the location and size of a data heap within the data memory 6 that can be used by the software subroutines in the library 14.
  • The [0050] configuration data memory 12 is shown in FIG. 1 in the form of a read only memory. Such a read only memory can be programmed with the necessary configuration data using standard techniques. Alternatively, special purpose circuit elements, such as registers that can be read, may be provided to store the configuration data. The configuration data can be encrypted using various known encryption techniques.
  • FIG. 2 schematically illustrates the relationship between software elements and the hardware within the example device. At the highest level the device may execute [0051] several application programs 18, 20, 22. These application programs 18, 20, 22 interact with the operating system 24. From the point of view of the application programs 18, 20, 22, the operating system 24 provides the function of interacting and controlling the various hardware elements of the device 2. The operating system 24 may communicate directly with the device 2 for some services, but a large number of services will be provided via a basic input/output system software layer 26. This basic input/output system software layer 26 allows for the possible use of a variety of different operating systems 24 for a given design of device 2.
  • The [0052] initialisation program instructions 28 that control the reading of the configuration data memory 12 and the setting up of the basic input/output system software 26 are embedded within the basic input/output system software 26 itself. When the device 2 is initialised (e.g. the power is switched on or the system is reset), then the initialisation program instructions are executed to read the configuration data from the configuration data memory 12 and set up appropriate parameters for the various data processing circuit elements of the device 2 in the basic input/output system software 26.
  • FIG. 3 is a flow-diagram illustrating the initialisation of the [0053] device 2. At step 30, the device 2 is initialised by the switching on of power or a hardware reset. At step 32, the configuration data from the configuration data memory 12 is read under control of the initialisation program 28. At step 34, the initialisation program 28 uses the configuration data it has read to configure the basic input/output system software 26 with the variable parameters of the data processing circuit elements indicated as being present within the device 2. At step 36, the initialisation of the device 2 has been completed and processing control is passed to the operating system 24. Alternatively, the configuration of the system may not be completed until after handover of control to the operating system.
  • FIG. 4 illustrates a hierarchical description of an integrated circuit. In this example, an individual system-on-a-chip (SoC) system forms the highest level within the description. Beneath this highest level the components are first divided into the clock, microprocessor core, memory system, coprocessor and I/O systems. Some of the entries at this high level may not need to be further described and it is sufficient to associate type and value data with these entries in order to rigorously define the system. As an example, the core and coprocessor entries may be sufficiently defined by specifying the core as an ARM9 core and the coprocessor as a vector floating point unit. The design tools that will subsequently be responsive to this description do not need any further information regarding these particular entities other than that specified. Conversely, an entity such as the memory may be further divided into entities describing the presence or absence of an MMU (with associated parameters), a cache memory, a read only memory and a random access memory. Similarly, the I/O devices may be subdivided into individual types with their particular parameters such as address, interrupt and the like associated therewith. It will be appreciated that the description illustrated in FIG. 4 is highly simplified and that in reality many more entries and levels will be present within a typical system description with a fine level of detail regarding the configuration parameters. [0054]
  • FIG. 5 schematically illustrates the design process using the hierarchical syntax. The human [0055] readable description 40 is in the form of an editable text file written in accordance with the ASN.1 syntax (it will be appreciated that other description formats, such as XML, could also be used). A designer can modify elements within this editable text simply using a standard text editor to alter the description of the system to suit a particular requirement. Once the editable text 40 has been finalised, a software tool may be used to interpret this description and generate a configuration datafile 42 representing in a compact form the configuration of the system. This configuration data may then be encrypted prior to being stored within the configuration data memory 44 of a system 46 to which it relates.
  • There follows a further description of a software system embodying one example of the present invention: [0056]
  • Abstract [0057]
  • The BIOS (basic input/output system) is the program a microprocessor uses to get the computer started after you turn it on. It also manages the data flow between the computer's operating system and attached peripheral devices. [0058]
  • [source-Intel][0059]
  • Reduction of time-to-market can be a key feature of code development. It has been suggested that a reduction in code efficiency of 10% is acceptable when balanced against improved design flow. [0060]
  • SoC BIOS (‘microBIOS’) is an ARM solution to support peripheral input and output (I/O) and abstraction in a flexible manner, so simplifying porting between platforms and reducing time-to-market. [0061]
  • In many systems, driver code includes an encoding of aspects of the system in which the driver lies. By encoding system descriptions as data, rather than as code, SoC BIOS separates the system design and code implementation paths. [0062]
  • To allow porting to be performed with minimal changes to code, SoC BIOS incorporates a flexible mechanism for accessing a system description. [0063]
  • SoC BIOS supports abstraction of underlying hardware, such as core variants. [0064]
  • Track state and availability of peripherals is performed transparently by the BIOS. [0065]
  • SoC BIOS adds value with a number of run-time features for I/O support. [0066]
  • Terms and Abbreviations
  • This document uses the following terms and abbreviations.[0067]
  • AFS ARM Firmware Suite—a set of board-support components [0068]
  • API Application Programmers Interface—the interface presented by SoC BIOS to the Implementor. [0069]
  • ASCII Standard character encoding [0070]
  • ASN.1 Abstract Syntax Notation One. Standard notation for specifying data structures at a high level of abstraction. [0071]
  • ATPCS ARM/Thumb Procedure Calling Standard [0072]
  • BER Basic Encoding Rules for ASN.1 [0073]
  • BIOS Basic Input/Output system—code controlling initialisation and functionality of peripherals. [0074]
  • ELA Expansion Link Address—location examined by the BIOS for extension information [0075]
  • GPI Generic Peripheral Interface, used to perform peripheral control [0076]
  • ID Abbreviation for ‘Identifier’[0077]
  • Implementation An application or OS utilising the SoC BIOS [0078]
  • Implementor The individual writing a BIOS-aware implementation [0079]
  • I/O Input and/or Output [0080]
  • MMU Memory Management Unit [0081]
  • MOD Generic identifier for a peripheral module [0082]
  • MPU Memory Protection Unit [0083]
  • OS Operating System [0084]
  • OSD Operating System Device Driver Model [0085]
  • PDB Peripheral Definition Block. This defines the peripherals to be supported. [0086]
  • PERSISTENT Data which is maintained by the Implementation across multiple calls to the BIOS [0087]
  • PIB Peripheral Information Block. This specifies details of one peripheral. [0088]
  • RAM Random Access (writeable) storage [0089]
  • ROM Read Only (non-writeable) storage, generally including programmable (Flash) storage [0090]
  • ROPI Read Only Position Independent code [0091]
  • RWPI Read/Write Position Independent code [0092]
  • SIB System Identification Block. A header of on-chip or on-board identification data. [0093]
  • SWI Software Interrupt, also ARM processor Software Interrupt mode [0094]
  • TBD To Be Determined (incomplete area of specification). [0095]
  • μHAL micro Hardware Abstraction Layer. A low-level abstraction library supplied as freeware by ARM with the Integrator demonstration system. Part of AFS[0096]
  • Introduction [0097]
  • Objectives
  • The objectives of the SoC BIOS software are to make it easier, faster and cheaper for customers to use ARM-based solutions. There is a growing understanding that the faster development time offered by generic code can balance any efficiency reduction. Within the automotive industry, an acceptable efficiency loss of 10% has been suggested if balanced by enhanced development speed. [0098]
  • SoC BIOS offers the following: [0099]
  • In many systems, driver code includes an encoding of aspects of the system in which the driver lies. By encoding system descriptions as data, rather than as code, SoC BIOS separates the system design and code implementation paths. [0100]
  • To allow porting to be performed with minimal changes to code, SoC BIOS incorporates a flexible mechanism for accessing a system description. [0101]
  • SoC BIOS supports abstraction of underlying hardware, such as core variants. [0102]
  • Track state and availability of peripherals is performed transparently by the BIOS. [0103]
  • SoC BIOS adds value with a number of run-time features for I/O support [0104]
  • Usage
  • 1. Supporting an RTOS [0105]
  • An high percentage of RTOS vendors support the ARM platform. We wish to ensure that this continues and furthermore that new ARM platforms, including changes in processor type, peripheral set and configuration, are supported quickly and reliably. [0106]
  • By abstracting the configuration and presenting a generalised peripheral model, SoC BIOS will simplify both porting and maintaining the RTOS on a range of platforms. For peripheral control, operating system compatible device drivers (OSDs) can be written to conform to the RTOS requirements and to interface through SoC BIOS with low-level physical device drivers. [0107]
  • 2. With no RTOS [0108]
  • For those of ARM's customers who don't use an RTOS, the SoC BIOS feature set is designed to function as a stand-alone BIOS, offering a complete package for initialisation and control. The high level abstracted model is intended to reduce design time for an application designer. [0109]
  • Porting
  • SoC BIOS supplies a number of features to simplify porting. [0110]
  • Platform independence—SoC BIOS offers a configured and stable platform to the application. This reduces the need for the application to communicate directly with the underlying hardware or to support hardware variants. [0111]
  • Peripheral identification—SoC BIOS will track the peripherals in the board specification and initialise them. Changes in board design therefore require less redesign of code. [0112]
  • Relationship with μHAL/AFS
  • Although AFS and SoC BIOS both present a layer of abstraction to an application, there are several differences in target and scope between the two products. The main differences are: [0113]
  • SoC BIOS will offer a higher level of functionality than AFS, both by including further high level functions and by reducing the need for the application to access the system at a very low level. [0114]
  • SoC BIOS will include an interface for generic control of system peripherals, while AFS offers support for the specific functions known to be generally available on development boards. [0115]
  • SoC BIOS will be a separate entity, resident on-board or on-chip, rather than a library of control functions. System details are separately specified by the system designer and interpreted at run-time. The application then interacts with SoC BIOS at run-time in a DLL-like manner. This simplifies the design path and helps to ensure that the encoded configuration matches the actual system. [0116]
  • Relationship with Primecell Drivers
  • All Primecell drivers will be extended to be compatible with the SoC BIOS Generic Peripheral Interface (see below). This will be by addition of a GPI layer to each driver, and does not preclude the use of these peripherals in isolation. [0117]
  • Support of non-Primecell Drivers
  • Any peripheral driver may be built into the SoC BIOS and its API will then be available. However, to be integrated within SoC BIOS, the driver must be extended to at least the most basic functions of the Generic Peripheral Interface (see below). [0118]
  • Development Tools
  • The SoC BIOS build will be designed initially to be built with ADS (ARM Developer Suite). It is intended that the project code will eventually be compatible with other development environments (at least GNU tools), but the first release will be for ADS only. [0119]
  • Software Systems Coding Standard
  • The SoC BIOS project will conform to the Software Systems coding standard and will be assigned project identifier ab. [0120]
  • Development with SoC BIOS [0121]
  • The Development Process
  • SoC BIOS separates the process of specifying the target system from the writing of code, and separates BIOS code from application (or RTOS) code. This gives defined areas of development, which are usually addressed by developers with different skills and knowledge. [0122]
  • See FIG. 6—SoC BIOS development process [0123]
  • System Description
  • The system description is an encoded specification of the system and peripherals. It is encoded as a block of data whose format is defined as an ASN.1 abstract syntax structure. This is a formal definition of the structure format and types. The associated value notation is used to present the system description in a human-readable form. The specification data is bound as closely as possible to the system that it describes. It may be available directly from the system (on-chip or in non-volatile memory), but in the absence of this data, an in-build copy (encoded as part of the build procedure) will be used. [0124]
  • BIOS Structure [0125]
  • Overview
  • An overview of the SoC BIOS structure is shown below (BIOS functionality is shown as 3-D boxes). The API sits over a number of run-time modules. System configuration draws in data from a range of sources to configure peripherals through the GPI. The implementation communicates with the peripherals through the GPI, or directly through the driver API where required. [0126]
  • See FIG. 7—SoC BIOS overview [0127]
  • SoC BIOS Structure
  • The SoC BIOS is spilt into several parts. [0128]
  • 3. SoC BIOS Manager [0129]
  • This contains the basic SoC BIOS code to initialise the system, handle interrupts and control the Generic Peripheral Interface, and supply a set of extended functionality. The manager code is fully position independent and can be relocated at run-time if required. It is likely that it can be supplied as object code. [0130]
  • 4. Peripheral Drivers [0131]
  • Any peripheral drivers which support the GPI (see below) can be integrated into SoC BIOS. These are built as a separate functional block to the SoC BIOS manager. The peripheral driver block includes all drivers to be included in SoC BIOS and so must be rebuilt when the included set of drivers is changed. [0132]
  • Peripheral Control [0133]
  • Drivers
  • SoC BIOS is intended to function with both polling and interrupt-driven drivers. [0134]
  • These are considered Physical Device Drivers (PDDs) in that they directly control the hardware registers. Functionality is likely to include initialisation and control functions and servicing interrupts to transmit or receive a data buffer. [0135]
  • It is anticipated that a driver will be OS-independent, with OS-specific features being added in a wrapping driver (OSD) which adheres to the desired OS model. [0136]
  • Peripheral Control with GPI
  • SoC BIOS may access any peripheral to perform a number of generic functions that are (potentially) applicable to all peripheral types. The system used is termed the Generic Peripheral Interface (GPI). [0137]
  • The GPI is a layer of functionality that is added to a driver to allow that driver to interact with the BIOS. In general, the GPI offers a standardised interface that will support functionality that already exists in the driver. [0138]
  • The GPI consists of the functions below. It is not necessary for a driver to implement all of the GPI functions, but there is a dependency tree as shown below. For example, if a driver implements the GPI Self Test function it should also implement the Initialize and Get Memory Requirements functions. [0139]
  • See FIG. 8—GPI functions [0140]
  • Peripheral Identification
  • Under GPI, peripherals are identified by a file name built from the driver type name and user-specified number (for example ‘UART100’). The number is specified in the system description and may be arbitrary or may reflect the location of the peripheral in the system or the target to which it is attached. [0141]
  • Tagging and Messaging
  • SoC BIOS can send generic messages to peripherals by using the tagging and messaging system of GPI. The application may tag and untag all peripherals, one class of peripheral or one peripheral and messages will be distributed to all tagged peripherals. [0142]
  • This system allows generic code to be written which is not dependent on precise system configuration. For example, during data transfer, other peripherals may not be required, and the following commands might be sent: [0143]
  • Tag all peripherals [0144]
  • Ontag the current output stream [0145]
  • Send ‘power save’ message [0146]
  • Power Control
  • A designated ‘supervisor’ peripheral may be assigned. This will be notified of all messages and their targets. It may intervene to handle messages itself, either in addition to, or instead of, the driver function. For example, on a system with no power controller, ‘power save’ messages would be passed to the drivers. By declaring a power controller in the system description, the messages would automatically be handled there instead. [0147]
  • Self Test
  • The driver may include a self test function. A number of different levels of test may be supported. The areas tested will depend on the peripheral, but a basic self test will probably not extend beyond writing to, and reading from, certain registers. [0148]
  • The self test function will be executed for each peripheral after initialisation. If the peripheral fails self test, it will be marked as unavailable to the system and not used. [0149]
  • Driver API
  • The driver API will be made public to the application, should the application wish to access the driver directly, rather than through standard I/O. This is intended to allow peripheral-specific functions to be used, such as setting data transfer parameters. It is not intended that standard I/O and direct driver API I/O be used in parallel for data transfer from the same peripheral and results will be unpredictable. [0150]
  • SoC BIOS Linking [0151]
  • Overview
  • When building development software to use on a SoC BIOS system, the software links against a library in which BIOS or peripheral API calls are replaced by stub functions. These use a SWI mechanism to pass function identifiers to the BIOS. [0152]
  • The SoC BIOS build can remain system-resident and need not be rebuilt with the application [0153]
  • The application will run with any build of the SoC BIOS, which would not be the case if directly linked to a pre-built BIOS. [0154]
  • SoC BIOS can itself access GPI functions for the peripheral drivers. [0155]
  • Extensibility is straightforward. StubIDs not handled by SoC BIOS directly are passed to extension systems (see §[0156] 0) for management.
  • By routing all calls through one location, tracing and debugging possibilities become available. [0157]
  • Implementation
  • The basic stub handling is as below. The stub handler handles StubID calls from SoC BIOS stubs, matching these against routines in a lookup table built into the code. [0158]
  • See FIG. 9—SoC BIOS stub handling [0159]
  • Extensions
  • When generating the final executable, the system configuration will be fully specified. However, when working on a development system, it is anticipated that the basic configuration may be extended. [0160]
  • A SoC BIOS system specification may specify a number of Expansion Link Addresses (ELA). On initialisation, the SoC BIOS code will examine each of these locations, looking for an identification pattern indicating the start of a data block. If this pattern is present at this address, it will be taken as confirmation that the following data is a valid SoC BIOS extension area. [0161]
  • A valid SoC BIOS extension will reflect the addition of extra peripheral hardware, and will include a peripheral data block (PDB) and possibly a stub lookup table (SLT) to add further drivers. [0162]
  • See FIG. 10—Accessing Modules with SoC BIOS ELAs [0163]
  • At run-time, the BIOS will direct stub calls to the drivers built into the BIOS, or to extension areas, as appropriate. Thus ELAs allow further peripherals to be fully integrated into the BIOS. [0164]
  • See FIG. 11—Passing calls to extension drivers [0165]
  • Abstract [0166]
  • SoC BIOS (‘microBIOS’) is an ARM solution to support I/O and abstraction in a flexible manner, so simplifying porting between platforms and reducing time to market. This document describes the SoC BIOS run-time data encoding. The SoC BIOS encodes a system description as data, which is retrieved [0167]
  • 1 Introduction [0168]
  • The BIOS (basic input/output system) is the program a microprocessor uses to get the computer started after you turn it on. It also manages the data flow between the computer's operating system and attached peripheral devices. [source-Intel][0169]
  • SoC BIOS (‘microBIOS’) is an ARM solution to support peripheral input and output (I/O) and abstraction in a flexible manner, so simplifying porting between platforms and reducing time-to-market. [0170]
  • 2 Scope [0171]
  • This document specifies the encoding used for the SoC BIOS system configuration data. This data is at runtime to identify and configure features of the system being used. [0172]
  • 3 Data Encoding [0173]
  • 4 Introduction
  • Each system will be specified by a set of data in a defined structure. [0174]
  • This will be produced and stored in human-readable text form (initially by hand, but later by a software tool). [0175]
  • The format currently chosen is the telecommunications standard ASN.1, using ASN.1 ‘value notation’ to describe each system—this may later change, and there has been a proposal to move to XML format. This will be reviewed later in the project. [0176]
  • The human-readable data is then encoded into a machine-readable form for access by the BIOS. [0177]
  • 5 Basic Encoding
  • The Basic Encoding Rules (BER) of ASN.1 define an encoding format for data defined within ASN.1. [0178]
  • SoC BIOS will use a modified form of this encoding, to allow for the limited requirements of the BIOS data. [0179]
  • BER uses a TLV (Type, Length and Value) encoding system, where each element is encoded with an identifying type, an indication of the length of the element, and then the element value. This value may consist of nested TLV sets (for ‘constructed’ types). This system is ideal for partial decoding, allowing access functions to retrieve and return a single element from the encoded block with relative ease. [0180]
  • The decoder in SoC BIOS can locate the elements and return them on request by access functions, avoiding the need for assigning space to decode the entire block (which is the usual method used with ASN.1 encoding). [0181]
  • The Type and Length encoding used will be more compact than for BER, since type checking will not be required. [0182]
  • The top bit of each byte will be an ‘extension’ bit, indicating that at least one further byte of length encoding data remains. [0183]
  • The second highest bit of the first byte (only) will indicate that this item is a sequence which will contain other elements. [0184]
  • The remaining six bits of the first byte and seven bits of following bytes are concatenated to form the length value. The first byte represents the highest bits. An example is in See Figure, which represents a sequence of length 0011111001011 (binary) or 1995 bytes. [0185]
  • See FIG. 12—Modified BER encoding [0186]
  • 6 Byte Ordering
  • SoC BIOS will retrieve all encoded data as word accesses, so avoiding issues of byte endian-ness. [0187]
  • ASN.1 encodes data as byte sequences. It requires that the most significant byte of INTEGER values be transmitted first. [0188]
  • Within SoC BIOS, the first bytes are always encoded into, and retrieved from, the lowest bytes of the encoded word (little-endian). [0189]
  • 7 Encryption [0190]
  • SoC BIOS is defined to offer four possible formats of encryption of the specification data. The final product may support any one or more of these formats. [0191]
  • 8 Plain Data
  • In this format, the data is encoded as described earlier. [0192]
  • 9 Obscured
  • Since the plain format leaves ASCII characters unchanged, the encoded data can be read using a debugger. The obscured data will modify this by applying a simple bit operation to each data word. [0193]
  • 10 Light Encryption
  • This format is intended to offer a simple encryption on a word-by-word basis. It has not yet been defined. [0194]
  • 11 Full Encryption
  • This format is intended to offer an improved encryption in two word blocks. [0195]
  • The TEA algorithm will probably be used. This encodes 64 bit data using a 128 bit key and source code for encryption and decryption is publicly available. [0196]
  • Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. [0197]

Claims (21)

We claim:
1. An integrated circuit comprising:
(i) a plurality of data processing circuit elements;
(ii) a configuration memory storing configuration data describing said plurality of data processing elements; and
(iii) configuration logic operable upon initialisation of said apparatus to read said configuration data from said configuration memory and to determine therefrom configuration parameters of said integrated circuit for setting up configuration program software controlling interaction between application program software and said plurality of data processing circuit elements.
2. An integrated circuit as claimed in claim 1, wherein said configuration program software is basic input output system software.
3. An integrated circuit as claimed in claim 1, wherein said plurality of data processing circuit elements include a processor core responsive to program instructions to perform data processing operations.
4. An integrated circuit as claimed in claim 3, wherein said configuration logic comprises said processor core operating under control of initialisation program instructions to read said configuration memory and to determine therefrom said configuration parameters.
5. An integrated circuit as claimed in claim 3, wherein said configuration data includes data identifying said processor core.
6. An integrated circuit as claimed in claim 1, wherein said plurality of data processing circuit elements include a data memory and said configuration data includes at least one of data identifying a type characteristic of said data memory, a capacity value of said data memory, a page size value of said data memory and data specifying access parameters for said data memory.
7. An integrated circuit as claimed in claim 1, wherein said plurality of data processing circuit elements include a data processing peripheral circuit and said configuration data includes at least one of a memory address for said data processing peripheral and interrupt data specifying interrupts used by said peripheral.
8. An integrated circuit as claimed in claim 1, wherein said configuration data includes data indicating whether a library of software subroutines is present and at least one of a data heap size and a data heap location.
9. An integrated circuit as claimed in claim 1, wherein said configuration memory is a read only memory with said configuration data is fixed at manufacture of said integrated circuit.
10. An integrated circuit as claimed in claim 1, wherein said configuration data is encrypted.
11. A method of configuring an integrated circuit having a plurality of data processing circuit elements and a configuration memory storing configuration data describing said plurality of data processing elements, said method comprising the steps of:
(i) upon initialisation of said apparatus, reading said configuration data from said configuration memory;
(ii) determining from said configuration data configuration parameters of said integrated circuit for setting up configuration program software controlling interaction between application program software and said plurality of data processing circuit elements.
12. A computer program storage medium storing a computer program for controlling an integrated circuit to perform a method as claimed in claim 11.
13. A method of describing an integrated circuit having a plurality of circuit elements and associated configuration parameters, said method comprising the step of:
(i) generating a description of said integrated circuit using a predetermined hierarchical syntax to form a human readable hierarchical description.
14. A method as claimed in claim 13, wherein an entry within said human readable hierarchical description can have one or more dependent entries stemming therefrom at a lower level within said human readable hierarchical description.
15. A method as claimed in claim 13, wherein said hierarchical syntax allows different portions of said human readable hierarchical description to have different hierarchical depths.
16. A method as claimed in claim 13, wherein each entry within said human readable hierarchical description has associated variables specifying order, type and value.
17. A method as claimed in claim 13, wherein said human readable hierarchical description is an ASN.1.
18. A method of forming configuration data for configuring an integrated circuit as claimed in claim 11, said method of forming configuration data comprising the steps of:
(i) generating a human readable hierarchical description in accordance with the method of any one of claims 13 to 17; and
(ii) automatically mapping said human readable hierarchical description into said configuration data.
19. A method as claimed in claim 18, further comprising the step of encrypting said configuration data prior to storing said configuration data in said configuration memory.
20. A computer program storage medium storing a computer program for controlling an integrated circuit to perform a method as claimed in claim 13.
21. A computer program storage medium storing a computer program for controlling an integrated circuit to perform a method as claimed in claim 18.
US10/406,229 2000-10-31 2003-04-04 Integrated circuit configuration Abandoned US20030204830A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/406,229 US20030204830A1 (en) 2000-10-31 2003-04-04 Integrated circuit configuration

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0026596A GB2368669B (en) 2000-10-31 2000-10-31 Integrated circuit configuration
GB0026596.7 2000-10-31
US09/984,013 US6918103B2 (en) 2000-10-31 2001-10-26 Integrated circuit configuration
US10/406,229 US20030204830A1 (en) 2000-10-31 2003-04-04 Integrated circuit configuration

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/984,013 Division US6918103B2 (en) 2000-10-31 2001-10-26 Integrated circuit configuration

Publications (1)

Publication Number Publication Date
US20030204830A1 true US20030204830A1 (en) 2003-10-30

Family

ID=9902277

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/984,013 Expired - Lifetime US6918103B2 (en) 2000-10-31 2001-10-26 Integrated circuit configuration
US10/406,229 Abandoned US20030204830A1 (en) 2000-10-31 2003-04-04 Integrated circuit configuration

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/984,013 Expired - Lifetime US6918103B2 (en) 2000-10-31 2001-10-26 Integrated circuit configuration

Country Status (3)

Country Link
US (2) US6918103B2 (en)
JP (1) JP2002149627A (en)
GB (2) GB2406416A (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010015262A1 (en) * 2000-02-14 2001-08-23 Kazuki Denpoh Apparatus and method for plasma treatment
US6854046B1 (en) * 2001-08-03 2005-02-08 Tensilica, Inc. Configurable memory management unit
WO2005081496A1 (en) * 2004-02-18 2005-09-01 Honeywell International, Inc. Systems and methods for encoding and decoding data messages
US20070098149A1 (en) * 2005-10-28 2007-05-03 Ivo Leonardus Coenen Decryption key table access control on ASIC or ASSP
US20080184193A1 (en) * 2007-01-25 2008-07-31 Devins Robert J System and method for developing embedded software in-situ
US20110219363A1 (en) * 2008-11-18 2011-09-08 Tencent Technology (Shenzhen) Company Limited Method for dynamically linking program on embedded platform and embedded platform
WO2015099660A1 (en) * 2013-12-23 2015-07-02 Intel Corporation Integrated component interconnect

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4763866B2 (en) * 1998-10-15 2011-08-31 インターシア ソフトウェア エルエルシー Method and apparatus for protecting digital data by double re-encryption
KR100448897B1 (en) * 2002-05-20 2004-09-16 삼성전자주식회사 Chip development system having function library
KR100929143B1 (en) 2002-12-13 2009-12-01 삼성전자주식회사 Computer and its control method
US20040122973A1 (en) * 2002-12-19 2004-06-24 Advanced Micro Devices, Inc. System and method for programming hyper transport routing tables on multiprocessor systems
US8805981B2 (en) * 2003-03-25 2014-08-12 Advanced Micro Devices, Inc. Computing system fabric and routing configuration and description
US7444546B2 (en) 2003-04-17 2008-10-28 Arm Limited On-board diagnostic circuit for an integrated circuit
US8041915B1 (en) 2003-06-11 2011-10-18 Globalfoundries Inc. Faster memory access in non-unified memory access systems
US7185309B1 (en) * 2004-01-30 2007-02-27 Xilinx, Inc. Method and apparatus for application-specific programmable memory architecture and interconnection network on a chip
US7228520B1 (en) 2004-01-30 2007-06-05 Xilinx, Inc. Method and apparatus for a programmable interface of a soft platform on a programmable logic device
US7823162B1 (en) 2004-01-30 2010-10-26 Xilinx, Inc. Thread circuits and a broadcast channel in programmable logic
US7770179B1 (en) 2004-01-30 2010-08-03 Xilinx, Inc. Method and apparatus for multithreading on a programmable logic device
US7552042B1 (en) 2004-01-30 2009-06-23 Xilinx, Inc. Method for message processing on a programmable logic device
JP2008060653A (en) * 2006-08-29 2008-03-13 Matsushita Electric Ind Co Ltd Control device
US7904872B2 (en) * 2008-05-22 2011-03-08 International Business Machines Corporation System-on-chip (SOC), design structure and method
US20100161309A1 (en) * 2008-12-23 2010-06-24 Scaleo Chip Apparatus and Methods Thereof for Configuration and Control of a System-On-Chip Emulation Platform
JP2010187216A (en) * 2009-02-12 2010-08-26 Toshiba Corp Signal processing apparatus, signal processing method, and reproducing apparatus
JP5625858B2 (en) * 2010-12-13 2014-11-19 富士通株式会社 Component management apparatus, management program, and management method
US8938796B2 (en) 2012-09-20 2015-01-20 Paul Case, SR. Case secure computer architecture
US20180004550A1 (en) * 2016-07-01 2018-01-04 Intertrust Technologies Corporation Device integration platform systems and methods
JP6539789B2 (en) * 2016-10-27 2019-07-03 楽天株式会社 IC chip compatible terminal, IC chip setting method, and program

Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5291583A (en) * 1990-12-14 1994-03-01 Racal-Datacom, Inc. Automatic storage of persistent ASN.1 objects in a relational schema
US5473546A (en) * 1991-06-12 1995-12-05 Lsi Logic Corporation Method for flattening hierarchical design descriptions
US5555201A (en) * 1990-04-06 1996-09-10 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5745734A (en) * 1995-09-29 1998-04-28 International Business Machines Corporation Method and system for programming a gate array using a compressed configuration bit stream
US5805860A (en) * 1995-07-05 1998-09-08 Sun Microsystems, Inc. Methods, data structures and apparatus for traversing a hierarchical netlist
US5883814A (en) * 1997-03-13 1999-03-16 International Business Machines Corporation System-on-chip layout compilation
US5970142A (en) * 1996-08-26 1999-10-19 Xilinx, Inc. Configuration stream encryption
US6028445A (en) * 1997-12-30 2000-02-22 Xilinx, Inc. Decoder structure and method for FPGA configuration
US6175626B1 (en) * 1995-09-29 2001-01-16 Intel Corporation Digital certificates containing multimedia data extensions
US6216258B1 (en) * 1998-03-27 2001-04-10 Xilinx, Inc. FPGA modules parameterized by expressions
US6272669B1 (en) * 1997-12-15 2001-08-07 Motorola, Inc. Method for configuring a programmable semiconductor device
US6305005B1 (en) * 1999-01-14 2001-10-16 Xilinx, Inc. Methods to securely configure an FPGA using encrypted macros
US20010034876A1 (en) * 1997-09-16 2001-10-25 Synetry Corporation System for converting hardware designs in high-level programming languages to hardware implementations
US20010037458A1 (en) * 2000-02-08 2001-11-01 Kean Thomas A. Method of using a mask programmed key to securely configure a field programmable gate array
US6333940B1 (en) * 1993-03-09 2001-12-25 Hubbell Incorporated Integrated digital loop carrier system with virtual tributary mapper circuit
US6356950B1 (en) * 1999-01-11 2002-03-12 Novilit, Inc. Method for encoding and decoding data according to a protocol specification
US6360192B2 (en) * 1999-03-04 2002-03-19 Sun Microsystems, Inc. Transaction class
US6438738B1 (en) * 2000-09-19 2002-08-20 Xilinx, Inc. System and method for configuring a programmable logic device
US6438737B1 (en) * 2000-02-15 2002-08-20 Intel Corporation Reconfigurable logic for a computer
US20020133788A1 (en) * 2000-10-16 2002-09-19 Waters Simon Joshua Structured algorithmic programming language approach to system design
US6487648B1 (en) * 1999-12-15 2002-11-26 Xilinx, Inc. SDRAM controller implemented in a PLD
US20030005292A1 (en) * 1998-12-14 2003-01-02 Matthews Donald P. Encrypted download of SRAM-based FPGAS
US6510546B1 (en) * 2000-07-13 2003-01-21 Xilinx, Inc. Method and apparatus for pre-routing dynamic run-time reconfigurable logic cores
US6526558B2 (en) * 1998-12-16 2003-02-25 Lattice Semiconductor Corporation Methods for configuring FPGA's having variable grain blocks and shared logic for providing symmetric routing of result output to differently-directed and tristateable interconnect resources
US6557156B1 (en) * 1997-08-28 2003-04-29 Xilinx, Inc. Method of configuring FPGAS for dynamically reconfigurable computing
US6571381B1 (en) * 1998-02-25 2003-05-27 Pact Xpp Technologies Ag Method for deadlock-free configuration of dataflow processors and modules with a two- or multidimensional programmable cell structure (FPGAs, DPGAs, etc.)
US6581191B1 (en) * 1999-11-30 2003-06-17 Synplicity, Inc. Hardware debugging in a hardware description language
US20030115564A1 (en) * 1998-09-30 2003-06-19 Cadence Design Systems, Inc. Block based design methodology
US6584601B1 (en) * 2000-02-07 2003-06-24 National Instruments Corporation System and method for converting graphical programs into hardware implementations which utilize probe insertion
US6606588B1 (en) * 1997-03-14 2003-08-12 Interuniversitair Micro-Elecktronica Centrum (Imec Vzw) Design apparatus and a method for generating an implementable description of a digital system
US6611946B1 (en) * 1999-10-14 2003-08-26 Synopsys, Inc. Method and system for automatic generation of DRC rules with just in time definition of derived layers
US6631508B1 (en) * 2000-06-07 2003-10-07 Xilinx, Inc. Method and apparatus for developing and placing a circuit design
US6637018B1 (en) * 1999-10-29 2003-10-21 Cadence Design Systems, Inc. Mixed signal synthesis behavioral models and use in circuit design optimization
US6651228B1 (en) * 2000-05-08 2003-11-18 Real Intent, Inc. Intent-driven functional verification of digital designs
US6784903B2 (en) * 1997-08-18 2004-08-31 National Instruments Corporation System and method for configuring an instrument to perform measurement functions utilizing conversion of graphical programs into hardware implementations
US20050010880A1 (en) * 1999-11-30 2005-01-13 Bridges2Silicon, Inc. Method and user interface for debugging an electronic system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2203869B (en) * 1987-04-17 1991-10-23 Apple Computer Computer resource configuration method and apparatus
GB8908470D0 (en) * 1989-04-14 1989-06-01 Smiths Industries Plc Processors
US5790834A (en) * 1992-08-31 1998-08-04 Intel Corporation Apparatus and method using an ID instruction to identify a computer microprocessor
AU6814594A (en) * 1993-12-21 1995-07-10 Taligent, Inc. Automatic hardware configuration
US6948070B1 (en) * 1995-02-13 2005-09-20 Intertrust Technologies Corporation Systems and methods for secure transaction management and electronic rights protection
JP3462956B2 (en) * 1996-04-17 2003-11-05 株式会社リコー Mask ROM data generator
JP3733387B2 (en) * 1997-09-09 2006-01-11 株式会社日立製作所 Control circuit hierarchy description method
WO1999014636A1 (en) * 1997-09-17 1999-03-25 Numerical Technologies, Inc. Method and apparatus for data hierarchy maintenance in a system for mask description
US5999730A (en) * 1997-10-27 1999-12-07 Phoenix Technologies Limited Generation of firmware code using a graphic representation
FR2786901B1 (en) * 1998-12-08 2001-04-27 Schlumberger Systems & Service DEVICE AND METHOD FOR INITIALIZING AN APPLICATION PROGRAM OF AN INTEGRATED CIRCUIT CARD
AU2209301A (en) * 1999-12-22 2001-07-03 Algotronix Limited Method and apparatus for secure configuration of a field programmable gate array
US6769109B2 (en) * 2000-02-25 2004-07-27 Lightspeed Semiconductor Corporation Programmable logic array embedded in mask-programmed ASIC
US6817005B2 (en) * 2000-05-25 2004-11-09 Xilinx, Inc. Modular design method and system for programmable logic devices

Patent Citations (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555201A (en) * 1990-04-06 1996-09-10 Lsi Logic Corporation Method and system for creating and validating low level description of electronic design from higher level, behavior-oriented description, including interactive system for hierarchical display of control and dataflow information
US5291583A (en) * 1990-12-14 1994-03-01 Racal-Datacom, Inc. Automatic storage of persistent ASN.1 objects in a relational schema
US5473546A (en) * 1991-06-12 1995-12-05 Lsi Logic Corporation Method for flattening hierarchical design descriptions
US6333940B1 (en) * 1993-03-09 2001-12-25 Hubbell Incorporated Integrated digital loop carrier system with virtual tributary mapper circuit
US5805860A (en) * 1995-07-05 1998-09-08 Sun Microsystems, Inc. Methods, data structures and apparatus for traversing a hierarchical netlist
US6175626B1 (en) * 1995-09-29 2001-01-16 Intel Corporation Digital certificates containing multimedia data extensions
US5745734A (en) * 1995-09-29 1998-04-28 International Business Machines Corporation Method and system for programming a gate array using a compressed configuration bit stream
US5970142A (en) * 1996-08-26 1999-10-19 Xilinx, Inc. Configuration stream encryption
US5883814A (en) * 1997-03-13 1999-03-16 International Business Machines Corporation System-on-chip layout compilation
US6606588B1 (en) * 1997-03-14 2003-08-12 Interuniversitair Micro-Elecktronica Centrum (Imec Vzw) Design apparatus and a method for generating an implementable description of a digital system
US6784903B2 (en) * 1997-08-18 2004-08-31 National Instruments Corporation System and method for configuring an instrument to perform measurement functions utilizing conversion of graphical programs into hardware implementations
US6557156B1 (en) * 1997-08-28 2003-04-29 Xilinx, Inc. Method of configuring FPGAS for dynamically reconfigurable computing
US20010034876A1 (en) * 1997-09-16 2001-10-25 Synetry Corporation System for converting hardware designs in high-level programming languages to hardware implementations
US6272669B1 (en) * 1997-12-15 2001-08-07 Motorola, Inc. Method for configuring a programmable semiconductor device
US6028445A (en) * 1997-12-30 2000-02-22 Xilinx, Inc. Decoder structure and method for FPGA configuration
US6571381B1 (en) * 1998-02-25 2003-05-27 Pact Xpp Technologies Ag Method for deadlock-free configuration of dataflow processors and modules with a two- or multidimensional programmable cell structure (FPGAs, DPGAs, etc.)
US6216258B1 (en) * 1998-03-27 2001-04-10 Xilinx, Inc. FPGA modules parameterized by expressions
US20030115564A1 (en) * 1998-09-30 2003-06-19 Cadence Design Systems, Inc. Block based design methodology
US20030005292A1 (en) * 1998-12-14 2003-01-02 Matthews Donald P. Encrypted download of SRAM-based FPGAS
US6526558B2 (en) * 1998-12-16 2003-02-25 Lattice Semiconductor Corporation Methods for configuring FPGA's having variable grain blocks and shared logic for providing symmetric routing of result output to differently-directed and tristateable interconnect resources
US6356950B1 (en) * 1999-01-11 2002-03-12 Novilit, Inc. Method for encoding and decoding data according to a protocol specification
US6305005B1 (en) * 1999-01-14 2001-10-16 Xilinx, Inc. Methods to securely configure an FPGA using encrypted macros
US6360192B2 (en) * 1999-03-04 2002-03-19 Sun Microsystems, Inc. Transaction class
US6611946B1 (en) * 1999-10-14 2003-08-26 Synopsys, Inc. Method and system for automatic generation of DRC rules with just in time definition of derived layers
US6637018B1 (en) * 1999-10-29 2003-10-21 Cadence Design Systems, Inc. Mixed signal synthesis behavioral models and use in circuit design optimization
US6581191B1 (en) * 1999-11-30 2003-06-17 Synplicity, Inc. Hardware debugging in a hardware description language
US20050010880A1 (en) * 1999-11-30 2005-01-13 Bridges2Silicon, Inc. Method and user interface for debugging an electronic system
US20030182642A1 (en) * 1999-11-30 2003-09-25 Schubert Nils Endric Hardware debugging in a hardware description language
US6487648B1 (en) * 1999-12-15 2002-11-26 Xilinx, Inc. SDRAM controller implemented in a PLD
US6584601B1 (en) * 2000-02-07 2003-06-24 National Instruments Corporation System and method for converting graphical programs into hardware implementations which utilize probe insertion
US20010037458A1 (en) * 2000-02-08 2001-11-01 Kean Thomas A. Method of using a mask programmed key to securely configure a field programmable gate array
US6438737B1 (en) * 2000-02-15 2002-08-20 Intel Corporation Reconfigurable logic for a computer
US6651228B1 (en) * 2000-05-08 2003-11-18 Real Intent, Inc. Intent-driven functional verification of digital designs
US6631508B1 (en) * 2000-06-07 2003-10-07 Xilinx, Inc. Method and apparatus for developing and placing a circuit design
US6510546B1 (en) * 2000-07-13 2003-01-21 Xilinx, Inc. Method and apparatus for pre-routing dynamic run-time reconfigurable logic cores
US6438738B1 (en) * 2000-09-19 2002-08-20 Xilinx, Inc. System and method for configuring a programmable logic device
US20040143801A1 (en) * 2000-10-16 2004-07-22 Waters Simon Joshua Structured algorithmic programming language approach to system design
US20020133788A1 (en) * 2000-10-16 2002-09-19 Waters Simon Joshua Structured algorithmic programming language approach to system design

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010015262A1 (en) * 2000-02-14 2001-08-23 Kazuki Denpoh Apparatus and method for plasma treatment
US6854046B1 (en) * 2001-08-03 2005-02-08 Tensilica, Inc. Configurable memory management unit
WO2005081496A1 (en) * 2004-02-18 2005-09-01 Honeywell International, Inc. Systems and methods for encoding and decoding data messages
US20070098149A1 (en) * 2005-10-28 2007-05-03 Ivo Leonardus Coenen Decryption key table access control on ASIC or ASSP
US7975151B2 (en) * 2005-10-28 2011-07-05 On Semiconductor Trading Ltd. Decryption key table access control on ASIC or ASSP
US20080184193A1 (en) * 2007-01-25 2008-07-31 Devins Robert J System and method for developing embedded software in-situ
US8234624B2 (en) * 2007-01-25 2012-07-31 International Business Machines Corporation System and method for developing embedded software in-situ
US20110219363A1 (en) * 2008-11-18 2011-09-08 Tencent Technology (Shenzhen) Company Limited Method for dynamically linking program on embedded platform and embedded platform
US8499291B2 (en) * 2008-11-18 2013-07-30 Tencent Technology (Shenzhen) Company Limited Method for dynamically linking program on embedded platform and embedded platform
WO2015099660A1 (en) * 2013-12-23 2015-07-02 Intel Corporation Integrated component interconnect
US20160299860A1 (en) * 2013-12-23 2016-10-13 David J. Harriman Integrated component interconnect
US10423552B2 (en) * 2013-12-23 2019-09-24 Intel Corporation Integrated component interconnect

Also Published As

Publication number Publication date
US6918103B2 (en) 2005-07-12
GB2368669B (en) 2005-06-22
US20020059556A1 (en) 2002-05-16
GB0428002D0 (en) 2005-01-26
GB2368669A (en) 2002-05-08
GB0026596D0 (en) 2000-12-13
JP2002149627A (en) 2002-05-24
GB2406416A (en) 2005-03-30

Similar Documents

Publication Publication Date Title
US6918103B2 (en) Integrated circuit configuration
TWI423040B (en) A method and system for enforcing a security policy via a security virtual machine
JP4050764B2 (en) Compilation system
US6970957B1 (en) Dynamically configuring resources for cycle translation in a computer system
US5325532A (en) Automatic development of operating system boot image
US6345382B1 (en) Run-time customization in object-oriented design
US6434695B1 (en) Computer operating system using compressed ROM image in RAM
CA2082409C (en) Improved system and method for jacketing cross-domain calls in a multi-code execution and debugging system within a multi-architecture environment
US6077315A (en) Compiling system and method for partially reconfigurable computing
US8468333B1 (en) Updating the system management information of a computer system
US6131187A (en) Method and system for translating exception handling semantics of a bytecode class file
US9720704B2 (en) Data driven hardware chips initialization via hardware procedure framework
US7171546B2 (en) CPU life-extension apparatus and method
US20040111707A1 (en) Debugger for multiple processors and multiple debugging types
JP2004503866A (en) Modular computer system and related methods
JP2012516483A (en) Application of platform-dependent routines within a virtual mechanism by embedding native code in a class file
WO2016061016A1 (en) Api versioning independent of product releases
US20070300054A1 (en) Universal BSP tool for porting on embedded systems and an application thereof
US20010049817A1 (en) System developing method, storage medium, information processing apparatus, information terminal apparatus, information processing system, and information processing method
Gibson et al. Device trees everywhere
US7219219B1 (en) Hardware initialization method that is independent of boot code architecture
Daum et al. Implementation correctness of a real-time operating system
US6782523B2 (en) Parallel configurable IP design methodology
US20020004877A1 (en) Method and system for updating user memory in emulator systems
CN116225527A (en) Embedded system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION