GB2336224A

GB2336224A - Hardware register access and database

Info

Publication number: GB2336224A
Application number: GB9807417A
Authority: GB
Inventors: Balbir Singh; Matthew Spencer Balchin; Christopher John Chambers
Original assignee: Northern Telecom Ltd; Nortel Networks Corp
Current assignee: Nortel Networks Ltd; Nortel Networks Corp
Priority date: 1998-04-07
Filing date: 1998-04-07
Publication date: 1999-10-13
Also published as: GB9807417D0

Abstract

A system (202) for managing the interfacing of electronic devices (105) containing I/O registers (such as peripheral components on a computer PCB) to one another, in which a data storage means contains information that relates to the data structure of the registers or the functions that may be used to access them. In one embodiment a database, called a common parameter interface file (CPIF), is created which contains data describing each device present on a board of electronic components: the CPIF contains data describing the registers and attributes of each device. Such a database may also be used to aid in the generation of test or initialisation software and/or device documentation. An advantage is that hardware abstraction is achieved making it easier for development of software (201) which accesses the peripheral devices without the programmer needing a specialist knowledge of the registers present in the peripheral devices.

Description

2336224 HARDWARE REGISTER ACCESS AND DATABASE

Field of the Invention

The present invention relates to a hardwarelsoftware interface, and in 5 particular although not exclusively to accessing registers present in a hardware device.

Background to the Invention

Many items of equipment include processors which control functioning of individual devices within the hardware equipment. Fig. 1 of the accompanying drawings illustrates an example of an item of hardware 100. Hardware 100 comprises An embedded processor card 101, having a processor 103 and a storage unit 102. Storage unit 102 may be used to store instructions controlling operation of processor 103. Hardware 100 further comprises a bus which can connect processor board 101 with at least one device, for example device 105, on the item of hardware 100.

Device 105 may include a plurality of registers 106. Registers 106 may be used to control functioning of device 105, for example writing a particular value to a particular register may trigger a particular function of the device, possibly producing an output which may be stored in another of one of the registers 106. Thus processor card 101 may control device 105 by reading to or writing from registers 106 of device 105 over bus-104 in order to execute certain functions.

Typically when the hardware device, such as hardware 100, is used for the first time, the processor card's storage units 102 may be substantially empty, thus allowing the functioning of the hardware to be programmed. Conventionally programming such hardware devices can be a slow and laborious process, typically requiring low level code to be written. It is therefore known for a processor card on an item of hardware to include an inputloutput (110) unit 107 used to interface with an external general purpose computer, this high level code may be written on the computer and cross complied into code suitable for use by processor card 101 and transferred to storage unit 102 via 1/0 unit 107.

Hardware devices such as hardware 100 can be produced by a variety of different manufacturers, and configuration of individual devices produced by the same manufacture can vary considerably, so programming different hardware equipment usually requires specialized knowledge of the individual item of hardware. Thus, when presented with a new item of hardware, programmers have to spend a considerable amount of time familiarizing themselves with the configuration of the new hardware. In some cases, individual devices within a single item of hardware can be significantly different or be manufactured by different suppliers, thereby increasing complexity of programming the hardware. Usually, internal structures of registers in hardware devices is defined on an ad hoc basis within different departments or sites of a manufacturer, features such as which registers are dedicated to particular functions are usually specified by a manufacturer. A programmer who wishes to read from or write data to such registers has to remember what functions or purpose of each register serves in each device. Thus, the length of time spent by programmers familiarizing themselves with new items of hardware can be considerable, which can increase costs and delays in producing products utilizing the new hardware. Programmers typically have to refer to reference manuals in order to discover information relating to the particular devices, for example the reference manuals may contain data describing functions of each register within a certain device. Such information describing registers usually comprises numerical values, thus there is a significant risk that the data may be entered incorrectly by programmers, again leading to increased time and costs being spent on developing products utilising the hardware.

Accessing registers on hardware devices may require several lines of code and different code may be needed to read or write data from/to different registers. Memory locations corresponding to registers to be accessed may have to be calculated by programmers in order to write new lines of code which access the registers. The length of code and the calculation of memory addresses means that developing the programs can be a slow process.

Furthermore, software which initializes and software to test functioning of devices often has to be written. Using conventional methods to write software of this type can be time consuming and difficult.

SummM of the invention

According to one aspect of the present invention there is provided a machine accessible data storage means configured for storing machine readable data describing a physical device having at least one register, said data storage means comprising:

an interface definition file containing a data structure definition of said physical device, said interface definition file comprising a plurality of variables describing characteristics of said at least one register; and a function definition file containing definitions of a plurality of functions for accessing said at least one register.

Preferably, said data storage means comprises means for logically grouping a plurality of registers together.

Preferably, said data storage means comprises means for specifying if a register or field is read only, write only or read and write.

Preferably, said data structure describes a field of a register.

A said variable may comprise a field information variable describing a field within said register.

Said data storage means may comprise a name which can be used to identify a register or a field.

Said data storage means may comprise an access variable describing whether a register is read only, write only or read and write.

Said data storage means may comprise a register help variable, operating to store help text describing help information relating to said register.

Said data storage means may comprise a field help variable operating to store field help text describing help information relating to least one field of said register.

According to a second aspect of the present invention, there is provided a machine accessible data storage means configured for storing machine readable data describing a register of a physical device, said data storage means comprising:

an arrangement of register variables configured for describing a data structure of said register.

According to a third aspect of the present invention there is provided a machine accessible data storage means configured for storing machine readable data describing a plurality of physical devices, each said device having at least one register, said data storage means comprising:

means for describing a data structure of a said device, said means comprising an arrangement of device variables configured for describing a data structure of a said device.

Preferably, a said device variable comprises a name variable used to identify a device.

Preferably a said device variable comprises a data structure defined by a plurality of register variables.

According to a fourth aspect of the present invention there is provided a machine accessible data storage means configured for storing machine readable data describing a plurality of physical devices on a physical board, each said device having at least one register, said data storage means comprising:

an arrangement of board variables configured for describing a data structure of said plurality of devices.

Preferably, a said board variable comprises a name variable used to identify a board.

According to a fifth aspect of the present invention there is provided means for creating a program for acceg at least one register of a physical device, said means comprising:

an interface definition file containing a data structure defining said physical device, said interface definition file comprising a plurality of variables describing characteristics of said at least one register; and a definition file containing definitions of a plurality of macros for accessing said at least one register.

According to a sixth aspect of the present invention there is provided a configuration means for configuriing a data storage device for storing data describing a physical device comprising at least one register, said configuration means comprising:

a set of instructions for configuring said data storage device to store data identifying a said at least one register of said physical device; a set of instructions for configuring said data storage device to store data describing a size of a said at least one register of said physical device; and a set of instructions for configuring said data storage device to store data describing an internal structure of a said at least one register of said physical device.

Said configuration means preferably further comprises:

a set of instructions for configuring said data storage device to store data describing field characteristics of a said at least one register.

According to a seventh aspect of the present invention there is provided data storage means configured for storing data describing a physical device having at least one register, said data storage means configured as:

a data storage area for storing data identifying a said at least one register in said device; a data storage area for storing data describing a size of said at least one register; and data storage area for storing data describing an internal configuration of a said at least one register.

Preferably, said data storage means further comprise:

means for storing data describing field characteristics of at least one said register.

Said data storage means may be configured as an hierarchical arrangement of a plurality of variables.

According to an eighth aspect of the present invention there is provided a method of creating a program for accessing at least one register of a physical device, said method comprising the steps of.

creating an interface definition file which contains a data structure definition of a device, said device having at least one register, said interface definition file comprising a plurality of variables describing characteristics of said at least one register; using a function definition file containing definitions of a plurality of functions for accessing said register, and wherein said created program contains at least one function call which calls a function, said function being defined within said function definition file.

A said function call may have parameters comprising said variables describing characteristics of said at least one register.

The method may comprise the step of creating a register map using said interface file.

A said variable may comprise a name variable identifying a register.

A said variable may comprise a name variable used to identify a register or 5 a field.

A said variable may comprise an access variable describing whether a register is read only, write only or read and write.

A said variable may comprise a register help variable which stores help text describing help information relating to said register.

A said variable may comprise a field help variable which stores help text describing help information relating to a field of a said register.

According to a ninth aspect of the present invention there is provided a method of accessing a physical device capable of being configured with a logical data structure said method comprising the machine executable steps of:

creating and storing a database containing data describing said device; and executing a program containing instructions which use said database to access said device.

Preferably, said database comprises instructions written in a high level programming language containing data structure definitions.

Preferably, said high level programming language comprises an American National Standards Institute C compatible programming language.

Preferably said database contains hierarchical data structure definitions describing at least one register present in said device.

Said database may contain hierarchical data structure definitions describing a plurality of fields in at lest one register present in said device.

Said database may contain hierarchical data structure definitions describing groups of registers present in said device.

Said instructions may contain function calls to functions written using macro substitution.

Said functions may provide means of reading data from specified registers present in said device.

Said functions may provide means of writing data to specified registers present in said device.

Said functions may provide a means to data access specified fields in registers present in said device.

Said functions may provide means to data access specified indexed registers or specified indexed fields of registers present in said device.

The invention includes a method of generating a documentation describing a device, comprising the machine executable steps of.

creating and storing a database containing data describing said device; executing a program containing instructions which use said database to generate documentation describing said device.

The invention includes a method of generating initialization software for a device, comprising the machine executable steps of:

creating and storing a database containing data describing said device; and executing a program containing instructions which use said database to generate initialization software for said device.

The invention includes a method of generating test software for a device, comprising the machine executable steps of:

creating and storing a database containing data describing said device; and executing a program containing instructions which use said database to generate test software for said device.

The invention includes an apparatus comprising a processor and memory configured to execute a method as described herein.

Brief Description of the Drawings

For a better understanding of the invention and to show how the same may be carded into effect, there will now be described by way of example only, specific embodiments, methods and processes according to the present invention with reference to the accompanying drawings in which:

Fig. 2 illustrates schematically relationships between an hardware device and software intended to use the hardware device; Fig. 3 illustrates schematically a bank of registers which may be used to control a hardware device; Fig. 4 illustrates schematically one of the registers identified in Fig. 3, including a plurality of memory units, a logical group of which may be called a field;

Fig. 5 illustrates schematically steps executed according to a preferred method, including a create small CIPIF step, a create full CP1F step, a generate register map step, a generate test software step, a generate initialization software step and a generate documentation step; Fig. 6 illustrates schematically a board data structure containing device information data structures; Fig. 7 illustrates schematically data structures contained within a device information data structure identified in Fig. 6, including a group data structure, a register information data structure and a field options information data structure;

Fig. 8 illustrates schematically data structures contained within the register information data structure identified in Fig. 7, including a field information data structure, a field options information data structure, a group data structure and an access data structure;

Fig. 9 illustrates schematically a field options information data structure as identified in Fig. 8;

Fig. 10 illustrates schematlically ANSI C data structure type definitions used by data structures contained within a small CIPIF generated at the step identified in Fig. 5; Fig. 11 illustrates schernatically steps executed in order to create the small CIPIF; Fig. 12 illustrates schematicaily ANSI C data structure type definitions used by data structure contained within a full CIPIF generated at the step identified in Fig. 5; Fig. 13 illustrates steps executed in order to complete the generate full CIPIF step identified in Fig. 5; Fig. 14 illustrates lines of code which may be contained within a full CIPIF; Fig. 15 illustrates schematically an example of an generation of a board configuration file step; Fig. 16 illustrates schematicaliy ANSI C data structure type definitions used 15 by data structures which may be contained within a board configuration file; Fig. 17 illustrates schematically steps which may be executed in order to generate a board configuration file; Fig. 18 illustrates schematically steps which may be executed in order to complete the generate register map step identified in Fig. 5; Fig. 19 illustrates an example of a register map file; Fig. 20 illustrates an example of a use register map file; Fig. 21 illustrates example code including functions defined in the files shown in Fig. 19 and Fig. 20; Fig. 22 illustrates steps which may be executed in order to complete the generate test software step identified in Fig. 5; Fig. 23 illustrates schematically ANSI C data structure type definitions used by the test software; Fig. 24 illustrates lines of code which may be included in the test software; Fig. 25 illustrates steps which may be executed in order to complete the generate device initialization software step identified in Fig. 5; Fig. 26 illustrates lines of code which may be included in the device initialization software; and Fig. 27 illustrates an example of documentation created by the generate documentation step identified in Fig. 5.

Detailed Description of the Bust Mode for Cartying Out the Invention

There will now be described by way of example the best mode contemplated by the inventors for carrying out the invention. In the following description numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent however, to one skilled in the art, that the present invention may be practiced without using these specific details. In other instances, well known methods and structures have not been described in detail so as not to unnecessadly obscure the present invention.

Fig.2 of the accompanying drawings illustrates schematically in relationships between software and hardware, as device 105. Conventionally, when application software which utilizes device 105 is written, the application software includes code which is intended to write values to and/or read values from registers of device 105. Thus, when similar applications are written which utilize different devices, the applicaflon software must be re-written completely or substantial parts of it have to be re-written in order to accommodate changes in the different devices' register configuration.

C According to the preferred embodiment, application software 201 is capable of using separate access layer software 202. The access layer software 202 is intended to provide low level functions which may read from and write to registers of a particular hardware device 105. Thus, application software 201 may be written so as to call functions from different functions from software layer 202 in order to utilize different hardware processes. Initialization software 204 may further be provided for use with software application 201. The application software 204 may include specialized register configuration code for a particular hardware device 203. For example, the initialization software 204 may set values of zero to all registers of hardware device 105 then write particular values to the registers in order to set up the device in order for the application to be executed.

Preferably, application 201, access layer 202 and initialization software 204 are cross compiled on a work station and the compiled code is transferred and written to the hardware device's storage. This use of specialized initialization and access layer software for different hardware devices means that application software 201 may need no or only slight modification in order to be used with different hardware devices. For example, different versions of the access layer and initialization software may exist for different hardware devices, the software versions may include substantially similar function names for substantially similar functions to be performed on the different hardware devices. The application software 201 may then comprise substantially similar code for execution on a number of different devices with particular versions of access layer 202 and initialization software 204 being linked to the application software 201. The software may is then be cross compiled for a particular device, the resulting code being downloaded to the device and stored and executed. Thus the present invention provides means for reusing code for use on different hardware devices, and can also make writing the application software simple for the programmer, by including generic/similar function names for similar functions on different hardware devices. The access layer software 202 may further provide means of accessing registers of hardware device 105 by using names for the device's registers, rather than requiring the programmers to remember or look up numerical values in order to write values to or read values from the device's registers.

Fig. 3 of the accompanying drawings illustrates schematically an architecture of a device such as device 105. It will be understood that device 105 is merely an example of a hardware device which may be controlled using applications written according to the preferred embodiment. It will be further understood that in the alternative embodiment, that hardware 100 may comprise a "system on a chip" (SOC), comprising a single piece of silicon, similar to an application specific integrated circuit (ASIC) but which may include storage units, processors and devices which can be programmed according to the application designer's specifications. The device may comprise plurality of registers 106.

Each of the registers may comprise one or more memory unit, such as a Dtype flip-flop, each memory unit capable of storing a single bit of data. For example register 304 comprises 8 memory units so is capable of storing eight bits. Writing particular values to particular registers may cause device 105 to perform certain functions, thus device 105 may be controlled by processor 103 of the processor card 101 writing particular values registers 106 of the device across bus 104.

Fig. 4 of the accompanying drawings illustrates a schematic diagram of register 304. The register comprises eight memory units, the right most of which 401 can represent a least significant M of an 8 digit binary number. A left most memory unit 402 of register 304 may represent a most significant bit of an 8 bit binary number, with 6 memory units between units 402 and 401, each being capable of storing a single bit. The register's memory units are labeled in the diagram with numbers 0 to 7 from right most to left most. A plurality of the memory units may be grouped together logically and called a "field", for example field 403 comprising memory units labeled 2, 3 and 4 shown shaded in Fig. 4.

The registe, 304 may comprise one or more such fields, each field may comprise one or more adjacent memory unit. Each field may be referenced by indicating a field start position which is a count of bits (memory units) from the least significant bit memory unit 401 to a first memory unit of the field, in the case of field 403 the field start position has a value of 2. A width of a field represents a number of memory units (equal to a number of bits) in the field, in the case of field 403 the field width has a value of 3.

According to prior art methods, when programmers write applications utilizing device 105 which require access to a register or a field to control device 105, the programmers may have to write several lines of code to achieve the necessary operation. For example, the programmers may have to calculate a memory location which corresponds to a register or field on device 105. This calculation of addresses can be a slow and tedious procedure which may have to be undertaken each time a register or field on device 105 is accessed. Furthermore, if device 105 is to be tested then a new test program may have to be written for each new device on the hardware in order to test or simulate access to each register or field in each device, which may involve calculating many memory locations and writing several lines of code in order to perform each read/write operation. Every time applications are written for different devices, different code may be required in order to access and read from or write to each new device due to their different configurations.

The present invention attempts to provide a means of simplifying access to registers andlor fields of a new hardware device so that any new hardware may be accessed in a substantially similar (or generic) manner to any other hardware for which a database as described herein below has been created. Additionally, the present invention attempts to provide a means of generating test software for testing registers andlor fields of a new hardware device, as well as device documentation and device initialization software. For any new device data describing the device's features, such as the device's registers and fields, may be saved as a single database, stored in a file called a Common Parameter Interface File (CP1F) which can be used as input to a set of programs which perform functions including generating register maps and providing means of easily accessing registers and fields of the device, generating test software for the device, generating initialization for the device and generating documentation describing the device. The CPIF is intended to eliminate need for creating and entering separate data into each program to obtain, for example initialization software which may provide a framework for initializing devices or for eliminating the need for generating specialized initialization software for each new hardware. A CP1F has a common format for all new devices represented by it so that the same set of programs can be used for all devices described using a CP1F. A CP1F may be considered to perform functions provided by access layer software 202, i.e. the CP1F may be used when writing application software 201 on a workstation in order to provide means of utilising different hardware devices. The application software and functions contained within the CP1F may then be cross compiled within the workstation and transferred to the storage unit of the particular device in order that the application may be executed by the device's processor.

Fig. 5 of the accompanying drawings illustrates steps typically executed and data used according to a preferred embodiment of the present invention. At step 501 a small version CP1F 502 may be created for a device on new hardware. At step 503 a full version CPIF 504 may be created from the small CP1F 502. Steps 505, 506 and 508 may be executed any number of times after the full CP1F 504 has been created. Normally, step 507 will only be executed once after the full CP1F 504 has been created. At step 505 the full CP1F 504 may be used to generate register maps for devices associated with full CPIF 504. At step 506 the full CP1F 504 may be used to generate test software for testing the device associated with the full CP1F. The test software may be executed on a work station which programmers can use to create this EPIF. The test software may simulate functioning of hardware device 105, for example a graphical user interface may display the device's registers, the test software may then illustrate what effect writing certain values to certain registers may have. The test software may also include on-line help for explaining functions of certain registers. The test software may allow users to interrogate contents of certain registers after certain values have beenwritten to the registers. Thus, the test software may be used to debug application software utilizing the hardware device. At step 507 software may be generated for initializing the device so that it may be ready for use. At step 508 documentation relating to the device associated with full CP1F 504 may be generated.

Fig. 6 of the accompanying drawings illustrates schematically a data structure which may be used to describe new hardware. The data structure may be arranged as a hierarchy of data structures, that is, each data structure can contain other data structures andlor pointers to other data structures. A highest level board data structure 601 may contain data describing the hardware's devices. Board data structure 601 may contain at least one device information data structure 602 containing data describing a device, for example device 105 on an item of hardware, such as hardware 100, described by data structure 601.

In the example shown in Fig. 6 two device information data structures 602 and 603 are contained within the board data structure 601. Device information data structure 602 contains substantially identical data structure types but will contain different instances of the data structures to device information data structure 603, so that two different devices on the same board can be described by the two device information data structures. Board data structure 601 preferably contains at least one device information data structure 604.

Fig. 7 of the accompanying drawings illustrates schematically data structures preferably contained within a device information data structure such as data structure 602. The device information data structure 602 preferably comprises data describing a single device on a board, substantially equivalent to the data contained in a full CP1F 504. The device information data structure 602 may contain a group data structure such as data structure 701 which contains at least one register information data structure storing data about registers in the device which may be logically grouped together, for example registers which are associated with a single function. In the example shown in Fig. 7 a group data structure 701 contains two register information data structures 702 and 703 describing two different registers belonging to a group described by data structure 701. Device information data structure 602 may also comprise one or more register information data structures not contained within a group data structure, for example register information data structure 704. Device information data structure 602 may also comprise one or more field options information data structures 705 which contain data describing fields of registers contained within the device described by the device information data structure 602.

Fig. 8 of the accompanying drawings illustrates schematically data structures preferably contained within a register information data structure, such as register information data structure 702. The register information data structure contains a field information data structure 801, which contains a field options information data structure 804. The field related data structures 801 and 804 describe fields within the register described by register information data structure

702. Register information data structure 702 also contains a group data structure 802 which contains data denoting that register information data structure 702 is contained within group data structure 701. If a register information data structure is not contained within a group data structure (eg register information 304)then the group data structure 802 may be omitted from that register information data structure. The register information data structure 702 preferably contains an access data structure 803. The access data structure contains data describing attributes pertaining to the register described by register information data structure 702, for example if the register is read-only, write-only etc.

Fig. 9 of the accompanying drawings illustrates data structures contained within a field options information data structure such as data structure 804. The field options information data structure preferabl ontains one or more field option data structure 901. Each field option daU..ucture preferably contains data describing options that a field described by the field options information data structure can have.

In a preferred embodiment the data structures shown in Fig. 6, Fig. 7, Fig. 8, and Fig. 9 and described herein are written and stored as ANSI C data structure definitions. It will be understood that the C programming language is merely an example of how the invention may be implemented. Those skilled in the art will realize that any similar or imperative programming language can be used to implement the invention. Advantages of storing the data structures as C/C++ compatible structures include widespread use across many hardware platforms and workstations. ANSI C compatibility also means that existing C compilers can perform procedures such as syntax checking, eliminating need for a special document parser to be written to interpret andlor check the data structures. Additionally, the data structure definitions may be edited in a substantially conventional manner at any time by a programmer in order to add extra features or customize the data structures in any other way. The C/C++ compatible data structure definitions may be saved as CIC++ header files which may be called by or included in other C programs so that the other programs can access and use the data structures thereby reading/writing data to devices of hardware 105, for example to test or initialize the device. The C language further includes enumerated types which can allow programmers to use more meaningful names for particular numerical values, thus making programs easier to write and read, for example a register which may have conventionally accessed by using a numerical value may be accessed using an enumerated type which may be the register's name or maJescribe the function of the register.

Fig. 10 of the accompanying drawings illustrates schematically ANSI C data structure type definitions which may represent data structures contained within small CP1F 502. Global vadable definitions 1002 contained within the small CP1F may be defined as follows:

char uint32 RegisterInformation uint32 FieldOptionslnformation uint32 device TypeName; deviceRegisterSize; registerinDe vice; numberOfRegisters deviceFieldOptions numberOtDeviceFieldOptions

A Registerinformation data structure type definition 1002 (representing a register information data structure such as data structure 702) for a small CP1F may be as follows:

typedef struct char char uint32 uint32 FieldInformation uint8 FieldOptionsinforTnation

RegisterInformation; registerShortName registerTypeName; offsetFromBase; numberOfindices; registerFieldlnforrnation; numberOfFields; registerOptionlnforrnation registerShortName is preferably a pointer to a string of characters storing an expanded long form name used as a title for a register described by the Registerinformation data structure for device documentation, for example documentation generated at step 508.

registerTypeName is preferably a pointer to a string of characters which identifies the register's type. Preferably, the string pointed to by l$ 1 registerTypeName comprises capital characters with no underscores, no numerical numbers and no joining words.

offsetFromBase is preferably a 32 bit integer numerical value containing actual offset base address for the register.

numberOfindices is preferably a 32 bit integer numerical value indicating a number of registers of the register's type existing in consecutive address locations of the device's memory.

registerFieldln formation is preferably a pointer to an array of

Fieldinformation data structures.

numberOfFields is preferably an 8 bit integer value indicating a number of 15 fields in the register.

A small CP1F FieldOptionslnformation data structure type definition 1003 (representing a field options information data structure such as data structure

804) may be as follows:

typedef struct char FieldOption uint8

FieldOptionsinformation;

TeldOptionTypeName; fteldOptions; numberOfFieldOptions; fieldOptionTypeName is preferably a pointer to a string of characters identifying a type of field described by the FieldOptionsinformation data structure. Preferably the string pointed to by fieldOptionTypeName comprises capital characters with no underscores, no numerical numbers and no joining words.

fieldOptions is preferably a pointer to an array of FieldOption data structures for the field.

numberOfFieldOptions is preferably an eight bit integer value indicating a number of field options associated with the register.

A small CP1F Fieldinformation data structure definition 1004 (representing a field information data structure such as data structure 801) may be defined as follows:

typedef struct char char uint8 FieldOptionlnformation Fieldinformation; fieldShortName; fieldTypeName; fieldWidth; fieldOptionlnformation;

The FieldInformation data structure preferably contains field information of a field within a register. The registerFieldinformation variable of a RegisterInformation data structure points to an array of Fieldinformation data structures, the array is preferably ordered from most significant field to least significant field.

fieldShortName is preferably a pointer to a string of characters identifying the register when generating test software at step 506. Preferably the string pointed to by fieldShortName comprises uppercase characters with underscores, no text numbers and no joining words. The string may include abbreviated names.

fieldTypeName is preferably a pointer to a string of characters which identify the field's type. Preferably the string comprises capital letters with no underscores, no numerical numbers and no joining words.

fieldWidth is preferably an 8 bit integer numerical value indicating the field's width in bits.

fieldOptionsinformation is preferably a pointer to a fieldOptionsinformation data structure.

Preferably, the small CP1F data structure type definitions 1001 to 1003 given hereinabove are written to and saved as an ANSI C compatible code to a file. The file may be given a file name such as "CommonSmaiiCpifTypes.h". The CommonSmaWpifTypes.h is preferably included or called by a small CP1F generated at step 501 for a particular device.

Fig. 11 of the accompanying drawings illustrates an example of steps which may be performed in order to create a small CP1F 503 containing data describing a device on 105, for example steps executed at step 501 of Fig. 5. At step 110 1 data describing registers of device 105 may be created, for example by writing an application which is to be cross compiled and downloaded to hardware 100. The data may include values for variables contained within a Registerinformation data structure, as described above for each register on a device 105. Some of the variables, for example pointers to other data structures may be generated automatically. At step 1102 data describing fields of registers of device 105 which will be stored in variables contained within Fieldinformation, FieldOptionsinformation and FieldOption data structures described above may be created. Values for some variables, for example pointers to other data structures may be generated. At step 1103 a file may be created and open which comprises a small CP1F for the device, possibly using a file name entered by the user. The file is preferably opened on a workstation which programmers may be using to write an application for hardware 100 involving device 105. At step 1104 header information is written to the opened file. The header information can contain comment lines as well as code such as compiler directives to include the data structure type definitions saved in the CommonSmaWpifTypes.h file. At step 1105 Registerinformation data structures containing variables storing data describing the registers created at step 1101 are written to the opened file. At step 1106 Fieldinformation, FieldOptionsinforTnation, and FieldOption data structures containing variables storing data describing the created at step 1102 are written to the opened file. At step 1107 the opened file is closed and saved.

Fig. 12 of the accompanying drawings illustrates schematically ANSI C data structure type definitions which may represent data structures preferably included in full CIPIF 504. Fig. 12 includes a Deviceinforrnation data structure type definition 1201 which is part of a board configuration file data structure definition (which will be described below herein) and not included in a CP1F. A DeviceInformation data structure definition contains variables which are pointers to data structures defined by data structure type definitions 1202 to 1207 of Fig. 12 which are preferably included in a CIP1F.

A Registerinformation data structure type definition 1202 preferably contains definitions of variables used to described characteristics of a register and may represent a register information data structure such as data structure 704. A Registerinformation data structure type definition may be as follows:

typedef struct char char char char uint32 uint32 registerName; registerGuiName; registerShoitName; registerTypeName; offsetFromBase; numberOfIndices; Access Group Fieldinformation uint8 char

Registerinformation; registerAccess; registerin Group; registerFieldinforrnation; numberOfFields, help; registerName is preferably a pointer to a string of characters storing an expanded long form name used a title for device documentation, for example documentation generated at step 508.

registerGuiName is preferably a pointer to a string of characters used to identify a register described by a CP1F from a GUI.

registerShortName is preferably a pointer to a strong of characters which identifies the register, for example when generating test software at step 506.

Preferably, the string pointed to by registerShortName comprise upper case with underscores L), no text numbers and no joining words and may include abbreviations, eg "configuration" may become "config".

registerTypeName is preferably a pointer to a string of characters which identifies the register's type. Preferably, the string pointed to by registerTypeName comprises capital characters with no underscores, no numerical numbers and no joining words.

number,Ofindices is preferably a 32 bit integer numerical value indicating a number of registers of the register's type existing in consecutive address locations of the device's memory.

registerAccess is preferably a pointer to an Access data structure indicating general access type of the register.

registerInGroup is preferably a pointer to a Group data structure indicating a group to which the register belongs to registerinGroup may be used by the GUI in order to perform different sorts on displaying register information.

registerFieldinfonnation is preferably a pointer to an array of fieldinformation 10 data structures.

numberOfFields is preferably a 32 bit integer value indicating a number of fields in the register.

help is preferably a pointer to a string of characters which may contain text describing the register's function and a page number of documentation where further information about the register's function can be found.

A Group data structure type definition 1203 which may represent a group 20 data structure such as data structure 701 may be as follows:

typedef struct char char char char Group; groupName; groupGuiName; groupShortName; GroupEnumName; groupName is preferably a pointer to a string of characters used as a title to explain registers contained within a group described by a group data structure.

groupGuiName is preferably a pointer to a string of characters used to identify the group from a GUI.

groupShortName is preferably a pointer to a string of characters that identify the group at generate test software. Preferably the string pointed to be the groupShortName comphses uppercase characters which may contain underscores L) but exclude text numbers and joining words.

groupEnumName is preferably a pointer to a string of characters used to identify the group in enumerated type definitions used in software that references the group data structure.

A FieldInformation data structure type definition 1204 may define data structures representing a field information data structure such as data structure 801. A Fieldinformation data structure type definition may be as follows:

typedef struct char char char char uint8 uint8 Acces FieldOptionsinformation char

Fieldinformation; fieldName; fieldGuiName; fieldShortName; fieldTypeName; fleldPosition; fieldWidth; fieldAcess; fieldOptioninforrnation; help;

A Fieldinformation data structure contains information describing a field within a register. The registerFieldinformation variable of a Registerinfonnation data structure points to an array of FieldInformation data structures, the arrays are preferably ordered from most significant field to least significant field within the register described by the variable.

fieldName is preferably a pointer to a string of characters containing an expanded long form name used as a tide for device documentation, such as that generated at step 508.

fieldGuiName is preferably a pointer to a string of characters identifying the register from a GUI.

fieldShortName is preferably a pointer to a string of characters identifying the register, for example when generating test software at step 506. Preferably the string pointed to by fieldShortName comprises uppercase characters with underscores, no text numbers and no joining words. The string may include abbreviated names.

fieldPosition is preferably an 8 bit integer numerical value indicating a number of bits from the register's least significant bit to a start bit of the field.

fieldAccess is preferably a pointer to an access data structure indicating actual access type of the field which may be different from the access type of the register which the field is contained within.

fieldOptionsinforrnation is preferably a pointer to a fieldOptionslnformation data structure.

help is preferably a pointer to a string of characters which may contain text describing the field's function and a reference to a page of documentation where further information about the field's function can be found.

A FieldOptionsin formation data structure type definition, representing a field options information data structure such as data structure 705, may be:

typedef struct char char FieldOption uint8 1 FieldOptionslnformation; fieldOptioninfoName; fieldOption TypeName; fieldOptions; numberOfFieldOptions; fieldOptioninfoName is preferably a pointer to a string of characters containing an expanded long form name used as a title to explain a collection of field options (pointed to by the fieldOptions variable) that a field described by a FieldOptionsInformation data structure field can take.

fieldOptionTypeName is preferably a pointer to a string of characters identifying the field's type. Preferably the string pointed to by fieldOption Type Name comprises capital characters with no underscores, no 20 numerical numbers and no joining words.

numberOfFieldOptions is preferably an eight bit integer value indicating a number of field options associated with a register which contains the field.

A FieldOption data structure type definition 1206 may represent a field option data structure such as data structure 901. The Field Option data structure type definition may be as follows:

typedef struct char char char char uint32 FieldOption; fieldOptionName; fieldGuiOptionName; fieldShortOptionName; fieldOptionEnumName; fieldOptionEnum Value; fieldOptionName is preferably a pointer to a string of characters containing an expanded long form name used as a title to explain a field option that a field described by a FieldOption data structure can take.

fieldGuiOptionName is preferably a pointer to a string of characters used to identify a field option the field (or a register which the field is contained within) from a GUI.

fieldShortOptionName is preferably a pointer to a string of characters used to identify the field option when generating test software at step 506.

FieldOptionEnumName is preferably a pointer to a string of characters used as part of an enumerated type definition when assigning values to registers or fields.

fieldOptionEnum Value is preferably an 8 bit integer numerical value assigned to the fieldOptionEnumName of the field option.

An Access data structure may define data structures representing an access data structure such as data structure 803. An Access data structure type definition 1207 may be as follows:

typedef struct char char FieldOption uint8

Access; accessName; accessGuiName; accessShortName; accessEnumName; accessName is preferably a pointer to a string of characters containing an expanded long form name used a title for device documentation, such as the documentation generated at step 508.

accessGuiName is preferably a pointer to a string of characters used to identify Access attributes of a register or field which an Access data structure belong to from a GUI.

accessShortName is preferably a pointer to a string of characters which identifies the Access of a register or field when generating test software at step 506.

accessEnumName is preferably a pointer to a string of characters denoting that access protection is required by code referencing the access data structure.

Preferably, the CP1F data structure type definitions given hereinabove are written to and saved as ANSI C compatible code to a file. The file may be given a file name such as "CommonCpifTypes.h". The common Common C pifTypes. h file is preferably included in or called by a CP1F generated at step 503 for a particular device.

Fig. 13 of the accompanying drawings illustrates steps executed in order to create a full version CP1F 504 from a small CIPIF 502 at step 503. At step 1301 a small version CP1F 502, describing a particular device may be opened and the data structure within the small CP1F are read and stored in a memory of a workstation which may be used to wrfte an application for hardware 100 before the small CP1F is closed. At step 1302 additional data describing the device described by the small CP1F, for example information not stored in a small CP1F such as Group data structures describing logical groupings of registers may be created. At step 1303 a new file for the full version CP1F to be created is opened. The opened file may have a filename with the following format:

<device><version>Cpif.h wherein <device> is a name of the device which the CP1F describes and <version> is an identifier denoting a version of the device.

At step 1304 header information is wiritten to the open file. The header information can contain comment lines as well as code to include the data structure type definitions saved in the CommonCpifTypes.h file and additional code (containing compiler directives for example). At step 1305 Group related data structure definitions, based on the Group data structure type definition 1203 are written to the opened file. The Group related data may be based on data entered at step 1302. At step 1306 FleldOption related data structure definitions based on the FieldOption data structure type definition 1206 corresponding to the device to be described by the CIPIF is written to the opened file. At step 1308 the opened file is closed and saved, preferably using a file name as described hereinabove.

Fig. 14 of the accompanying drawings illustrates an example of data, in the form of ANSI C code, which may be stored in a full CP1F 504. Header information lines 1401 written to the CP117 at step 1304 may be as follows:

#ifndef AAE CP1F H #define AAE CP1F H #include "CommonCpifTypes.h" #include "CommonCpif7ypes.c" The header information lines comprise comments including a copyright message, compiler directives intended to avoid multiple inclusion of the CP1F file and compiler directives to include the full CP1F data structure type definitions 1202 to 1207.

Lines 1402 of the CP1F file comprise Group data structure definitions based on the Group data structure type definition 1203. The lines Group generalControlStoresAae Group 1 # Group "generalControlStores", # "generalControlStores", # "generalControlStores", # "generalControiStores", # groupName groupGuiName groupShortName groupEnumName j define a group (of registers belonging to a device described by the CIPIF) and may be omitted if it is not desirable to group a set of the device's registers together logically. The above GroupG eneralControlStoresA a e Group data structure definition defines a single group of registers. The lines GroupAaeGroup [1 = generalControiStoresAaeGroup, interruptMasksAaeGroup define a Group data structure comprising an array of Group data structures defined in the CP1F, and would preferably be omitted if no groups had been defined in the CP1F. GroupAaeGroup is an array of pointer variable pointing to defined Group data structures for the device described by the CP1 F.

Lines 1403 of the CP1F comprise data structure definitions relating to field options, based on the FieldOption data structure type definition 1206 and the FieldOptions information data structure type definition 1205. The lines:

FieldOption modeFieldOpfion "Reset Mode", "Reset Mode ", "Reset Mode", "Reset Mode", 0000 ' llfieldOptionName I,MeidOptionGuiName 1MidOptionShortName liWeldOpfionEnumName IffieldOpfionEnum Value

J; define a field option (called 'Weset Mode") relating to field options which the device described by the CP117 can have. The lines:

FieldOptionslnformation modeFieldOptionsinfonnation [1

36- 1 llfieldOptioninfoName llfleldOption TypeName ArrayPointerAndSize(modeFieldOption) # > fieldOptions& numberOfFieldOptions

J define a FieldOption data structure describing fields contained within the device described by the CP1 F. The lines:

FieldOptionsinforrnation aaeFieldOptionsinDevice [1 = modeFieldOptionslnformation, define a FieldOptionsinforrnation data structure describing an array of 20 pointer variable pointing to FieldOptionsinformation data structures defined in the CP1F.

Lines 1404 of the CP1F define a register data structure based on the Registerinformation data structure type definition 1202:

#define ntid Registerinformation Worthem Telecom ASIC Idendtification Code",1 registerName WT1Y ' "Ntid", 0000, 2, 1registerGuiName 1registerTypeName 1offsetFromBase 1numberOfindices readAccess, 1registerAccess generalControiStoresAae Group, lregisterin Group NullArrayPointerAndSize 1registerFields & numberOfFields "page 92 Value is 0x000c904 1"lhelp k j Lines 1405 of the CP1F define a Fieldinformation data structure based on the field information data structure type definition 1204:

Fieldinformation fsyncFields [1 =

I1Fieldinformation unUsed, fieldName unUsed, fieldGuiName unUsed, fieldShortName unUsed, fieldTypeName

12, fieldPosition

4, # 17eldWidth unUsedAccess, # J7eldA ccess NULL, FieldOptionsinforrnation "help" help J11 Lines 1406 of the CP1F define a RegisterInformation data structure based on the RegisterlnforTnation data structure type definition 1202 comprising an array of pointers toRegisterinformaflon data structures defined in the CP1F Registerinfonnation aaeRegisters ntid, # Offset 0 x 0000 (2) tsync, 1/Offiset 0 x 0008 equeAslp # 0 x 1c00 (128) Preferably, the section of the CP1F comprising lines 1404, 1405 and 1406 are written to the CP1F at step 1307.

Lines 1407 of the CP1F include compiler directives (eg #endif) written to the CP1F before it is closed and saved at step 1308.

Fig. 15 of the accompanying drawings illustrates an example of creation of a board configuration file 1501. The board configuration file 1501 may define data structures representing a board data structure such as data structure 601. In order to generate the board configuration file, three full version CP1F files may be required for the example of Fig. 15. Each CP1F may represent a different device on hardware 100. For example, CP1F 504 may represent device 105. The output of a generate board configuration process is a board configuration file 1501 which contains data structure definitions containing or pointing to data structure definitions described in the three CPIF's entered as inputs. A board configuration file 1501 may store different versions of boards, for example different versions of hardware 100 may contain different devices.

Fig. 16 of the accompanying drawings illustrates schematically ANSI C data structure type definitions which may represent a board data structure such as data structure 601. A highest level Board data structure can store data describing hardware such as hardware 100, and may comprise a data structure type definition 1501 as follows:

typedef struct char Device Information boardName; device; / Array of devices uint 16 ChipSelect char Board; numberOfdevices; chipSelects; help; A Board data structure may be pointed to by a definedBoards variable 1603. Preferably a DefineBoards variable points to one or more Board data structure(s). Each board data structure's ChipSelects variable should point to an array of ChipSelect data structures. Preferably, each Board data structure contains one or more array of Device variables. Each device pointed to by a Device variable can reference data structures defined in a CP1F which is not referenced by any other Device variable or a CP1F which is referenced by one or more other Device variables. Variable chipSelect comprises a pointer to a ChipSelect data structure which contains configuration data for each device on a board described by a Board data structure. A ChipSelect data structure type definition 1502 may be as follows:

typedef struct uint 32 uint 32 uint 16 bool bool uint 32 uint 32 ChipSelect; baseAddress; baseAddressMask, portSize; writeProtected, valid; orRegister, brRegister; The devices variable in the Board data structure type definition 1501 is preferably a pointer to an array of Deviceinformation data structures, each Deviceinforination data structure containing variable data describing an individual device on a board described by a Board data structure. A DeviceInformation data structure type definition 1201 may be as follows:

typedef struct char char char char uint 32 RegisterInformation uint 32 FieldOptionslnforrnation uint 32 uint 32 uint 32 uint 32 uint 32 uint 32 uint 32 char

DeviceInformation; deviceName; deviceGuiName; deviceShortName; deviceTypeName; deviceRegisterSize; registerinDevice; numberOfRegisters; deviceFieldOptions; numberOfDeviceFieldOptions; deviceBaseAddress; deviceHardwareinterrupt, guix, guiy, guiHeight; guiffidth; help; deviceName is preferably a pointer to a string of characters used as a title for device documentation, such as the documentation generated at step 508.

deviceGuiName is preferably a pointer to a string of characters used to identify a device described by a Device Information data structure from a GUI deviceShortName is preferably a pointer to a string of characters that identify the device at the generate test software step 506. Preferably the string pointed to by deviceShortName comprises uppercase characters and underscores U but excludes text numbers and joining words (eg and, the).

deviceTypeName is preferably a pointer to a string of characters which identify the device's type. Preferably the string of characters pointed to by deviceTypeName comprises capital characters with no underscores, no numerical numbers and no joining words.

deviceRegisterSize is preferably a 32 bit integer numerical value indicating maximum width in 8 bit bytes at which a processor, e.g. processor 103, can access the device.

registersInDevice is preferably a pointer to an array of registerin formation data structures.

numberOfRegisters is preferably a 32 bit integer numerical value indicating a number of registers in the device.

deviceFieldOptions is preferably a pointer to an array of fleldOptions information data structures.

numberOfDeviceFieldOtions is preferably a 32 bit integer numerical value indicating a number of fieldOptions information for the device.

deviceBaseAddress is preferably a 32 bit integer indicating actual base address for the device.

deviceHardware Interrupt is preferably a 32 bit integer indicating actual hardware interrupt level for the device.

guiX, guiY, guiHeight, guiWidth are preferably 32 bit integer numerical values which may be used to identify a VDU screen location via a graphical user interface where details of the device may be displayed.

help is preferably a pointer to a string of characters which may store text containing details of the device such as a version number and a short paragraph describing the device's function.

The Registerinformation data structure pointed to by the variable 10 RegisterinDe vice may be included in a MF for the device.

Fig. 17 of the accompanying drawings illustrates steps which may be performed in order to generate a board configuration file containing a Board data structure based on the Board data structure type definitions shown in Fig. 16. The steps of Fig. 17 may be performed using a workstation which programmers can use to write applications for hardware 100. At step 1701 a string denoting a name of the board is created, this string will preferably be stored in the BoardName variable of the Board data structure to be created. At step 1702 a numerical value denoting a number of devices on the board is stored. Preferably, this numerical value is stored in the Number0Oevices variable. At step 1702 a counter may be set to zero. At step 1704 data to be stored in the array Devices of Device Information data structures indexed by the current value of the counter are entered. This entering of data may involve including data structures defined in a CP1F for a device referenced by the Devices variable, since some variables of the Deviceinformation data structure point to data structures contained within a CP1F. At step 1605 a question is asked whether the value of the counter is:5 the value of the variable NumberOfDe vices. If the question asked at step 1705 is answered in the negative then control is passed onto step 1706 where the value of the counter is incremented by 1 and control is passed back to step 1704. If the question asked at step 1705 is answered in the affirmative then data relating to the ChipSelects variable of the Board data structure may be entered. At step 1708 description text describing the board may be created. Preferably this description text is stored in the Board data structure's help string. At step 1709 a Board configuration file comprising data structure definitions based on the Board data structure data created at steps 1701 to 1708 and the data structure type definitions illustrated in Fig. 15 may be saved, possibly using a file name entered by the user. Preferably, the file is saved to a storage device connected to the workstation.

Fig. 18 of the accompanying drawings illustrates steps which may be executed in order to generate register maps at step 505. A register map comprises data structure definitions describing registers and the registers' attributes (such as their fields) in a device described by a CP1F. A register map is intended to allow generic access to registers and their attributes on any new hardware whose devices are represented by a CP1F. This generic access means that products utilizing the new hardware can be written by programmers experienced in using the generic access method rather than requiring the programmers to familiarize themselves with the new hardware's registers and register attributes which may require specialized code in order to access different registers on each individual device within the new hardware. This advantage means that the time taken to a produce a product utilizing the new hardware can be completed and marketed in a shorter period of time than using conventional means not involving register maps. The steps of Fig. 18 may be performed using a workstation which programmers can use to write applications for hardware 100.

At step 1801 generate register map step 505 may be involved, preferably by entering a Genera teRegisterMap command on the workstation. The command may have the following format:

GenerateRegisterMap [- endian [big] 1 [little] 1 [- help] <filename> The command allows the user to specify whether the register maps generated will contain data structures describing registers with big endian or little endian formats. At step the GenerateRegisterMap command entered may be interpreted by the workstation in order to establish which endian format the register maps it produces will have. The command also allows help messages relating to register maps to be displayed on the workstation's VDU. <filename> is a name of a board configuration file, such as the filed saved at step 1709. The generate register map step 505 invoked by the command may output a message on the workstation's VDU requesting a filename of a Board configuration file. The io generate register maps step preferably generates individual register maps for all devices contained within a Board data structure described within the board configuration file selected. The Board data structure contains Deviceinformation data structure(s) and the CPIF(s) which contain data structure definitions referenced by these De vicein formation data structures are established by at step 1803. At step 1804 a first CP1F referenced by a first Devices array variable in the Board configuration file is selected, opened and its contents read into the workstation's memory and then closed. At step 1805 the read CP1F is checked in order to establish if it complies with the following rules:

0 Address of each register in the CP1F is in incrementing order.

Address difference between two consecutive registers in the CP1F is an exact modulus of the register width.

Sum of all field widths (given by variable fieldWidth) in each register is equal to the register's width.

0 0 No fields overlap each other.

No fields are missing.

At step 1806 files which will contain data structure definitions and additional code comprising the register map for the device described by the read CP1F are opened. A file containing data structure definitions and additional code, such as compiler directives, in ANSI C compatible code is preferably created. The ANSI C compatible file may have a file name: <device name>RegisterMap.h. A C++ version of the file may alsolaltematively be created, and may have a file name:

<device name>RegisterMap.ch.

At step 1807 header lines are written to the opened file(s). The header lines may comprise comments and compiler directives. At step 1808 enumerated type definitions including the device's name are written to the opened file(s). At step 1809 data structure definitions describing register maps for each register and each field contained within the device described by the read CP1F are written to the opened file(s) taking into account index registers, and registers with no fields.

No names are used for data structures representing unused or reserved registers.

* At step 1810 data structure definitions representing a temporary register structure for the device described by the read CP1F are written to the opened file(s). At step 1811 a use register map file is created. The use register file may have a file name as follows: <device name> UseRegisterMap.h. Code within the use register map file attempts to ensure that any program using the register map makes use of the temporary register defined therein when performing bit manipulations. The opened flies are dosed and saved. At step 1812 a question is asked whether any more CIPIFs are to be used to create register maps are contained within the board configuration file. If the question asked at step 1812 is answered in the negative then the generate register map process 505 terminates at step 1813. If the question asked at step 1812 is answered in the affirmative then a next CP1F referenced by the board configuration file is selected at step 1814 and control is passed back to step 1805.

Fig. 19 of the accompanying drawings illustrates an example of a register map file (called AaeRegisterMap.ch). Lines 1901 comprise header information written at step 1807 including comments and compiler directives intended to prevent multiple inclusion of the register map file:

# iffidef AAE REGISTER MAP H # define AAE-REGISTER-MAP-H #include "ControlSoftware Type. h" Lines 1902 comprises enumerated type definitions written at step 1808:

typedef enum Mode is AAE RESET MODE = 0 AAE INITIALIZING-MODE = 1 AAE RAPID WRITE MODE= 3 AAE MISSION MODE= 3 ) Mode; Lines 1903 comprise register and field data structure definitions written at step 1809:

# undef RegisterType # define RegisterType uint 16 typedef volatile struct / typedef name of this structure is Aae / Register + 1, Offset = 000000 (o dec) Register Access = Read Only union Ntid RegisterType all,' ntid [21, uint8 RESERVED 1 [41, / Used to pad out structure / } Aae; / end of device: Aae / Lines 1904 comprise the temporary register definition written at step 1810:

typedef union AaeTemporatyRegisterlltag-name Aae;;Ntid ntid; Aae;; EqueAsip equeAsip JA ae TemporaryRegister, extem Aae TemporaryRegister aaeTemporaryRegister The register map may also comprise additional code such as compiler directive 1905.

Fig. 20 of the accompanying drawings illustrates an example Use Register Map file. The file contains the following C/C++ compatible code:

# undef DEVICE TYPE NAME # undef DEVICE TYPE NAME STRING # undef TEMPORARY REGISTER #define DEVICE TYPE NAME Aae # define DEVICE TYPE NAME STRING aae #define TEMPORARY REGISTER aaeTemporaryRegister The purpose of the above lines is to ensure that constants DEVICE TYPE NAME, DEVICE TYPE NAME STRING and TEMPORARY REGISTER have values which refer to variables/data structures defined in a particular register map file, in this case AaeRegisterMap.ch.

Fig. 21 of the accompanying drawings illustrates C/C++ compatible code which may be used to access and read/write to registers described using a register map file and a use register map file. The code is intended to be used by programmers writing applications for hardware 100 involving device 105. It will be appreciated by those skilled in the art that equivalent code and data structure definitions could be written in other programming languages but the preferred embodiment uses CIC++ compatible code. The code may provide functions which allow generic access to devices described by a full CP1F which have had register maps generated. Functions provided may include:

Read/Write to registers Read[Write to fields Read/Write register index Read/Write field index

Preferably, the functions can be used in following scenarios:

Ideal: where a C compiler generates atomic code for reading and writing to registerlfields and index registerlfields.

Non-ideal but compiler independent: where a C compiler does not generate correct assembly language code for reading and writing to fields.

0 Debug: either ideal or non-ideal are made to call another function which outputs exactly which address location is being written/read.

Co-simulation: either ideal or non-ideal are made to call another function which calls a virtual processor which simulates devices.

In a preferred embodiment functions using Register Map data structures as described hereinabove are used by macro substitution in C/C++ compatible code. The macro substitution means that a C/C++ compiler generates code that would otherwise need to be written by a programmer. A macro substitution may involve expanding short or abbreviated lines of code, such as a function call, into a longer of full definition of the lines, thus allowing shorter applications to be written by programmers (in a shorter time) which require less effort and memorization of lengthy code. The functions and macro expansions may be defined in a GenericAccess.h file which is included in any software which requires access to the registers represented by a register map file. Preferably the software also includes files AaeRegisterMap.c and UseAaeRegisterMap.h (or AaeRegisterMap.ch and UseAaeRegisterMap.ch) in order to access the required register map data structure definitions - see lines 2101. Lines 2102 contain code which may be used to write a value to a particular register:

unit32 aae 1 = (Aae) 0 x 1000 # assign aae 1 device at 0 x 1000 Write Register(bae l, tsync, 22); Any register defined by a register map for a particular device may have a value written to it using a command referencing a device identifier and a register identifier. This compares to the prior art case in which to achieve the same written value would involve a programmer having to work out addresses, looking up proprietary device manuals describing operation of the device and writing a large number of lines of code in order to achieve writing a value to the register.

Writing to a register may be achieved using a WriteRegister function which can have the following format:

WriteRegister (<device name>, <register name>, <value to be written>) <device name> preferably comprises a 32 bit integer numerical value containing an address pointing to a device's register and field data structure definition such as code lines 1903. The function then uses <registemame> in order to reference a particular register of the device pointed to within the data structure and may write <value to be written> to that register. After a pre-process stage (which may be part of the compilation process) the WriteRegister function 10 given in example 2102 may become by means of macro substitution:

RegisterWritten ("Aae", aael, "fsync". & aael) - >fsync, aael - > fsync. all = 22) A workstation used by application programmers may output the following on its VDU when the debug/test software generated device simulates execution of the RegisterWritten function:

Writing 0 x 0018 (22 in hexadecimal) into register fsync at 0 x 1008 (offset 0 x 0008 of Aae device at 0 x 1000) Values may be written to indexed fields by using the function referencing the desired field using a device identifier a register identifier, a field identifier and an index.

It will be understood by those skilled in the art that similar macro expansions may be defined for the functions given below. It will also be understood that the debug/test software generated for a particular device can also include output describing execution of the functions.

Reading a value from a register may be achieved using a ReadRegister function which can have the following format:

ReadRegister (<devicename>, <registemame>) wherein <device name> preferably comprises a 32 bit integer numerical value containing an address pointing to a device's register and data field structure definition. The function then uses <registemame> in order to reference a particular device pointed to within the data structure and may return a value stored in that register.

Writing to a register field may be achieved using the following function:

WriteRegisterField (<devicename>, <registemame>, <fieldname>, <valuetobewritten>) wherein <devicename> <registername> and <fieldname> identify a particular field within a particular register of a particular device; < valuetobe written> is to be written.

Reading a value stored in a register field may be achieved using the 20 following function:

ReadRegisterField (<devicename>, <registemame>, <fleldname) wherein <devicename>, <registemame> and <fieldname> identify a particular field of a particular register of a particular device whose stored value may be returned by the function.

Writing to an indexed register may be achieved using the following function:

WriteindexedRegistered (<devicename>, <registemame>, <index>, <valuetobe written>) wherein <devicenarne> and <registernarne> identify a particular register within a particular device and <index> may be used as an index value for accessing an indexed register to which <valuetobewritten> may be written.

Reading a value stored in an indexed register may be achieved using the following command:

IndexedRegisterRead (<devicenarne>, <registemame> <index>) wherein <devicenarne>, <registernarne> identify a particular register of a particular device and <index> identifies an index used to refer to an indexed register whose value may be returned by the function. Writing a value to an indexed field of a register may be achieved using the following function:

WriteindexedField (<devicenarne>, <registemarne>, <index>, <fieldname>, <valuetobewtitten>) wherein <devicename>, <registernarne>, <index> and <fieldname> identify a particular field in a particular register of a particular device with an index to which <valuetobe written> may be written.

Reading a value from an indexed field may be achieved by the following function:

ReadindexField (<devicenarne>, <registemarne>, <index>, <fieldname>) wherein <devicenarne>, <registernarne> and <fteldname>, identify a particular field in a particular register of a particular device and <index> identifies an index which may be used to refer to a field whose value may be returned by the function.

Fig. 22 of the accompanying drawings illustrates steps executed in order to perform generate test software step 506. The steps of Fig. 22 may be performed using a workstation which programmers can use to write applications for hardware 100. At step 2201 the generate test software step 506 may be involved by entering a Generate TestSoftware command. The command may have the following format:

Generate TestSoftware [ - Board <BoardName> 1 [ - help 1 wherein <BoardName> is filename of a board configuration file, such as the file saved at step 1609. The command also allows help text to be displayed on a VDU used by the workstation giving details of the test software.

At step 2202 the board configuration file specified by the user in the Generate TestSoftware command is opened and read into the workstation's memory and then closed. The CIPIF's referenced by data structures within the board configuration file are established at step 2202. At step 2203 a first CP1F, typically describing a device pointed to by a first element of the board configuration file's Board data structure's Devices array is selected. At step 2204 a new file is created and opened which will contain test software for the device described by the selected CP1F. The opened file may have a filename with the following format:

<BoardName> AutoTestSoftware C At step 2205 header information is written to the opened file. The header information lines may include comments and compiler directives to include data structure type definitions for the test software, the GenericAccess.h file (which is necessary to be able to use the generic register read/write functions) and register map and use register map files for the device described by the read CP1 F.

At step 2206 function definitions defining functions which read and write to each register in the device described by the CIPIF are written to the opened file. Function definitions which define functions which read and write to each register of each field in the device described by the CP1F are written to the opened file at step 2207.

At step 2208 data structure definitions for each field of each register in the device described by the CIPIF are written to the opened file. Data structure definitions for each register in the device described by the CIPIF are written to the opened file at step 2209. At step 2210 a data structure definition comprising an array of devices described by the board configuration file specified by the user at step 2201 is written to the opened file. The opened file is then closed and saved. At step 2201 a question is asked whether another CP1F describing a device for which test software is to be generated is present in the specified board configuration file. If the question asked at step 2211 is answered in the negative then the generate test software process 506 terminates at step 2212. If the question asked at step 2211 is answered in the affirmative then a next CP1F from the specified board configuration file is selected at step 2213 and control is passed back to step 2204.

Fig. 23 of the accompanying drawings illustrates schematically ANSI C data structure type definitions used by the test software. A BoardDevices data structure type definition 2301 may be as follows:

typedef struct ( char device TypeName; DeviceRegisters registerList,) BoardDevices; deviceTypeName is preferably a pointer to a string of characters containing a device described by a BoardDevices data structure name.

registerList is preferably a pointer to an array of DeviceRegister data structures. A DeviceRegisters data structure type definition 2302 may be as follows:

typedef struct ( char registerShortName; RegisterFields TeldList; uint32 registerRead) (void. uint 32); void (registerWrite) (void. uint3Z uint32); 1 DeviceRegisters;

FieldList is preferably a pointer to an array of RegisterFields. A 10 RegisterFields data structure type definition 2303 may be as follows:

typedef struct ( char fieldShortName; uint32 (TeldRead) (void. uint 32); void (TeldWrite) (void. uint3Z uint32);) RegisterFields;

Fig. 24 of the accompanying drErwings is an example of a file saved at step 2210 containing C/C++ compatible test software code. Lines 2401 represent head information written to the file at step 2205:

# include 'AvjModuleTestRoutines.h" #include "GenericAccess.h" #include "AaeRegisterMap.h" # include "UseAaeRegisterMap.h" Lines 2402 comprise function definitions which define functions which read and whte to each register of each device described by the board configuration file:

static uint32 ReadRegister Aae-Ntid (void currentDevice uint 32 index) (return ReadindexedRegister ((Aae) currentDevice, ntid, index),) static void WriteRegister Aae Ntid (void currentDevice, uint 32 index, uint32 value To Write) (writeindexedRegister((Aae) currentDevice, ntid, index, valueToWrite),) is Lines 2403 comprise function definitions which define functions which read/write from/to each field of each register of each device described by the board configuration file:

static uint32 ReadRegisterField Aae-Fsync_Offset (void currentDevice, uint32 index) (return ReadRegisterField ((Aae) currentDevice, fsync, offset),) static void WriteRegisterField Aae-Fsync_ Offset (void currentDevice, uint32 index, uint32 valueToWrite) "titeRegisterField ((Aae) currentDevice, fsync, offset, value ToWrite)j

Lines 2404 comprise data structure definitions (based on the Register Field data structure type definition 2303) describing fields of each register of each device described by the board configuration file, eg:

static RegisterFields Aae-Ntid fields

NULL static RegisterFields Aae-Fsyn_fjelds "OFFSET", ReadRegisterField Aae, c Offset, _Fsyn _ WriteRegisterField Aae Fsync__Offset,

NULL Lines 2405 comprise data structure definitions (based on the Device Registers data structure type definition 2302) for each register of each device described by the board configuration file, eg:

static deviceRegisters Aae-registers WT/D7, Aae-Ntid fields, WriteRegister Aae Nfid, NULL 1; Lines 2406 comprise a data structure definition (based on the

Board Devices data structure type definition 2301) listing all devices described by the board configuration file:

BoardDevice deviceList [1 ("Aae", Aae-registers), NULL j; Fig. 25 of the accompanying drawings illustrates steps which may be performed in order to perform generate initialization software step 507. The steps of Fig. 25 may be performed using a workstation which programmers can use to write applications for hardware 100. At step 2501 the generate initialization software step 507 may be involved by entering a GenerateDeviceinit command followed by a name of a device for which initialization software is to be created on the workstation. At step 2502 a first CP1F, containing data structure definitions describing the device specified is selected, opened and its contents read into the memory of the workstation and then the file is closed. At step 2503 a new file is created and opened which will contain the initialization software. The opened file may have a filename: <DeviceName> Initialize.c.

At step 2504 header information is written to the opened file. The header information may comprise comments and compiler directives. At step 2505 code comprising a beginning of a function definition defining a function which initializes the device is written to the opened file. At step 2506 code relating to creation of a temporary register for all writeable registers in the CP1F is written to the opened file. At step 2507 initialization code for each temporary register created at step 2506 is written to the opened file. At step 2508 code for ending the initialization function definition started at step 2505 is written to the opened file and the file is closed and saved, preferably to a storage device attached to the workstation.

At step 2509 a question is asked whether the device specified by the user at step 2501 has any other CIPIF's associated with it. If the question asked at step 2509 is answered in the negative then generate initialization software step 507 is terminated at step 2510. If the question asked at step 2509 is answered in the affirmative a next CP1F relating to the user specified device is selected at step 2511 and control is passed back to step 2503.

Fig. 26 of the accompanying drawings illustrates an extract of an example initialization software file such as one saved at step 2508. Lines 2601 comprise header information written to the file at step 2504:

# include "RcmpRegisterMap.h" # include "UseRcmpRegisterMap.h" #include "GenericAccess.h" The header information lines comprise comments and compiler directives to include register map files, use register map files and GenelicAccess.h file. The GenericAccess.h file is included because the initialization software's code contains function calls to the generic registerlfield read/write function definitions contained therein. Lines 2602 comprise a partial function definition written at step 2505:

void RMP Initialize (Rcmp rcmpRegisterMap) union MasterReset tempMasterReset; union MasterConfiguration tempMasterConfiguration; Lines 2603 comprise temporary register related code written at steps 2506 and 2507. For example:

/ Register = 1, Offset = 000000 (0 dec) Register Access = Read Write tempMasterReset.all = 0, tempMasterReset. bits. reset= 1; tempMasterReset. bits. type = 0 tempMasterReset. Bits. id = 0; WriteRegister (rcmpRegisterMap, masterReser, tempMasterReset. all); Fig. 27 of the accompanying drawings illustrates an example documentation file created at step 508. The documentation file contains data retrieved from variables within data structures contained within device configuration files and CIPIFs. The documentation gives a summary of device information followed by a summary of each register contained within the device. Information contained within the documentation includes names of registers, width of registers, total number of registers within a device, offset addresses of registers, and whether a register is read or write only.

Claims

Claims:

A machine accessible data storage means configured for storing machine readable data describing a physical device having at least one register, said data storage means comprising:

an interface definition file containing a data structure definition of said physical device, said interface definition file comprising a plurality of variables describing characteristics of said at least one register; and a function definition file containing definitions of a plurality of functions for accessing said at least one register.

2. The data storage means as claimed in claim 1, comprising means for logically grouping a plurality of registers together.

3. The data storage means as claimed in claim 1 or 2, comprising means for specifying if a register or field is read only, write only or read and write.

4. The data storage means template as claimed in any one of the preceding claims, wherein said data structure describes a field of a register.

5. The data storage means as eJaimed in any one of the preceding claims, wherein a said variable comprises a field information variable describing a field within said register.

6. The data storage means as claimed in any one of the preceding claims, comprising a name which can be used to identify a register or a field.

7. The data storage means as claimed in any one of the preceding claims, comprising an access variable describing whether a register is read only, write only or read and write.

8. The data storage means as claimed in any one of the preceding claims, comprising a register help variable, operating to store help text describing help information relating to said register.

9. The data storage means as claimed in any one of the preceding claims, comprising a field help variable operating to store field help text describing help information relating to least one field of said register.

10. A machine accessible data storage means configured for storing machine readable data describing a register of a physical device, said data storage means comprising:

an arrangement of register variables configured for describing a data structure of said register.

11. A machine accessible data storage means configured for storing machine readable data describing a plurality of physical devices, each said device having at least one register, said data storage means comprising:

means for describing a data structure of a said device, said means comprising an arrangement of device variables configured for describing a data structure of a said device.

12. The data storage means as claimed in claim 11, wherein a said device variable comprises a name variable used to identify a device.

13. The data storage means as claimed in claim 11 or 12, wherein a said device variable comprises a data structure defined by a plurality of register 30 variables.

14. A machine accessible data storage means configured for storing machine readable data describing a plurality of physical devices on a physical board, each said device having at least one register, said data storage means comprising:

an arrangement of board variables configured for describing a data structure of said plurality of devices.

15. The data storage means as claimed in claim 14, wherein said lo physical devices and said physical board are included on a system on a chip.

16. The data storage means as claimed in claim 14 or 15 wherein a said board variable comprises a name variable used to identify a board.

17. Means for creating a program for accessing at least one register of a physical device, said means comprising:

an interface definition file containing a data structure defining said physical device, said interface definition file comprising a plurality of variables describing characteristics of said at least one register, and a definition file containing definitions of a plurality of macros for accessing said at least one register.

18. A configuration means for configuring a data storage device for stodng data describing a physical device comprising at least one register, said configuration means comprising:

a set of instructions for configuring said data storage device to store data identifying a said at least one register of said physical device; IQ a set of instructions for configuring said data storage device to store data describing a size of a said at least one register of said physical device; and a set of instructions for configuring said data storage device to store data describing an internal structure of a said at least one register of said physical device.

The configuration means as claimed in claim 18, further comprising:

a set of instructions for configuring said data storage device to store data describing field characteristics of a said at least one register.

20. A data storage means configured for storing data describing a physical device having at least one register, said data storage means configured as:

a data storage area for storing data identifying a said at least one register in said device; a data storage area for storing data describing a size of said at least one register; and data storage area for storing data describing an internal configuration of a said at least one register.

21. The data storage means as claimed in claim 20, further comprising:

means for storing data describing field characteristics of at least one said register.

22. The data storage means as claimed in claim 20, configured as an hierarchical arrangement of a plurality of variables.

23. A method of creating a program for accessing at least one register of a physical device, said method comprising the steps of:

creating an interface definition file which contains a data structure definition of a device, said device having at least one register, said interface definition file comprising a plurality of variables describing characteristics of said at least one register; using a function definition file containing definitions of a plurality of functions for accessing said register; is wherein said created program contains at least one function call which calls a function, said function being defined within said function definition file.

24. The method as claimed in claim 23, wherein said physical device is contained. on a system on a chip.

25. The method as claimed in claim 23 or 24, wherein a said function call has parameters comprising said variables describing characteristics of said at least one register.

26. The method as claimed in claim 23, 24 or 25, comprising the step of creating a register map using said interface file.

27. The method as claimed in any one of claims 23 to 26, wherein a said variable comprises a field intrirnation variable describing a field within said 30 register.

28. The method as claimed in any one of claims 23 to 27, wherein a said variable comprises a name variable identifying a register.

29. The method as claimed in any one of claims 23 to 28, wherein a said variable comprises a name variable used to identify a register or a field.

30. The method as claimed in any one of claims 23 to 29, wherein said a variable comprises an access variable describing whether a register is read only, write only or read and write.

31. The method as claimed in any one of claims 23 to 30, wherein a said variable comprises a register help variable which stores help text describing help information relating to said register.

32. The method as claimed in any one of claims 23 to 31, wherein a said variable comprises a field help variable which stores help text describing help information relating to a field of a said register.

33. A method of accessing a physical device capable of being configured with a logical data structure said method comprising the machine executable steps of:

creating and storing a database containing data describing said device; and executing a program containing instructions which use said database to access said device.

34. The method according to claim 33, wherein said database comprises instructions written in a high level programming language containing data structure definitions.

35. The method according to claim 34, wherein said high level programming language comprises an imperative programming language.

36. The method according to any one of claims 33 to 35, wherein said database contains hierarchical data structure definitions describing at least one register present in said device.

37. The method according to any one of claims 33 to 36, wherein said database contains hierarchical data structure definitions describing a plurality of fields in at least one register present in said device.

38. The method according to any one of claims 33 to 37, wherein said database contains hierarchical data structure definitions describing groups of registers present in said device.

39. The method according to any one of claims 33 to 38, wherein said instructions contain function calls to functions written using macro substitution.

40. The method according to claim 39, wherein said functions provide means of reading data from specified registers present in said device.

41. The method according to claim 39 or 40, wherein said functions provide means of writing data to specified registers present in said device.

42. The method according to claim 39, 40 or 41, wherein said functions provide a,, means to data access specified fields in registers present in said device.

43. The method according to any one of claims 39 to 42, wherein said functions provide means to data access specified indexed registers or specified indexed fields of registers present in said device.

44. A method of generating a documentation deschbing a device, comprising the machine executable steps of:

creating and storing a database containing data describing said device; executing a program containing instructions which use said database to generate documentation describing said device.

45. A method of generating initialization software for a device, comprising the machine executable steps of:

creating and storing a database containing data describing said device; and executing a program containing instructions which use said database to generate initialization software for said device.

46. The method of generating test software for a device, comphsing the machine executable steps of:

creating and storing a database containing data describing said device; and 2 executing a program containing instructions which use said database to generate test software for said device.