WO2010004572A2

WO2010004572A2 - An innovative method of implementing embedded systems with increased design speed and efficiency

Info

Publication number: WO2010004572A2
Application number: PCT/IN2008/000439
Authority: WO
Inventors: Ajit Narayanan; Preetham Shivanna Kariyaiah
Original assignee: Invention Labs Engineering Products Pvt. Ltd.
Priority date: 2008-07-09
Filing date: 2008-07-09
Publication date: 2010-01-14
Also published as: WO2010004572A3

Abstract

The present invention relates to a new computing paradigm for controlling embedded systems, which allows a designer to focus on the design specifications, from which the software and hardware can be automatically extracted. In order to do this, one needs a new kind of computer, a new kind of programming paradigm, and a new class of printed circuit boards, where all of which are capable of synthesizing from the system specifications directly. The present invention broadly covers aforesaid novel ideas that go into making an embedded system.

Description

AN INNOVATIVE METHOD OF IMPLEMENTING EMBEDDED SYSTEMS WITH INCREASED DESIGN SPEED AND EFFICIENCY

FIELD OF THE INVENTION

The present invention relates to the field of embedded systems and in particular, to a new kind of computer that execute programs; to a new kind of electronics hardware system that can be described in a language that is more accessible to an embedded systems designer; and a new mechanism of expressing computer programs.

BACKGROUND OF THE INVENTION In the Engineering Products industry today, there is a widespread need for intelligent devices, which are able to integrate computing elements such as a processor, memory and I/O ports with external interfaces such as sensors, actuators, display devices, input devices and communication devices, to provide utilitarian gadgets to the customer.

Such devices are known as embedded systems. Embedded systems are widespread in the industry today, with examples from industrial applications, entertainment devices, communication systems, consumer electronics, automotive subsystems, security and safety devices, and many other fields. The widespread penetration of embedded systems in daily life has made it an extremely lucrative industry.

Embedded systems design is typically done by a team consisting of engineers from different disciplines. At the basic minimum, an embedded systems team may consist of a software team, an electronics hardware team, and a domain-specific team that has expertise in a field such as mechanical, chemical, automotive or communication technology. Due to the fact that all of these disciplines have their own design paradigms and design processes, the task of integrating all the teams to build a common engineering product is a challenging one.

This problem, of interdisciplinary integration of design goals, is the primary reason that even cutting-edge embedded systems are typically an order of magnitude less complex than modern software systems, and embedded systems design cycles are several times longer than the design cycle of purely software systems with comparable complexity.

To a large extent, the problem of co-design of multiple interdisciplinary systems is acute because of legacy design paradigms that still pervade the design of each individual system. This makes it difficult for a small team of architects to be able to create a detailed design description of the system as a whole, without getting into the nitty-gritty of software, electronics or mechanical designs.

The field of embedded software is a good example of how the embedded design community has not been able to adapt away from traditional 'pure' software techniques.

Most computers today work by executing instructions one after another. Consequently, almost all computer programs are written in a manner of instructions that are executed sequentially. The execution of these instructions is assumed by the programmer to be performed in equal and continuous time-slices. This is a paradigm of programming that has been very effectively deployed in millions of computer applications that are purely software systems. These systems include operating systems, compilers, graphical interfaces, internet applications and most other programs running on existing personal computers.

However, the paradigm of thinking of programming logic in terms of an entirely temporal flow of operations is not a natural or convenient way to describe real-world devices that are controlled by computers in embedded systems today. For example, in a mechanical gadget, the operation of the system as a whole may be more conveniently described in terms of geometry and a set of equations, or in terms of open- loop or closed-loop systems. As another example, the operation of a digital electronic circuit may be more conveniently described in terms of a finite state machine. In both of these examples, the description of how the system operates is not in equal and continuous time-slices, but in terms of relationships between abstractions which are more domain-specific.

In the above contexts, a program could be used to instruct a micro-controller as to how to control the device in question. Therefore, a more natural description of the system also leads to a more natural computer to control the system. It also leads to the ability of a systems architect being able to specify the overall design of the system in a more natural and cohesive manner, without having to get into artificial specifics of how the software implementation must be done.

An analogous argument also holds for electronics hardware design sub-components of an embedded systems design. In a typical hardware design cycle, the processes that a designer goes through include selection of components, creation of schematics, performing the layout, and creating a prototype board. Each of these stages involves a description of the system in design language that is uniquely suited for electronics systems, such as voltages, currents, footprints, components and connectors.

At the embedded systems design level, however, it often makes more sense to describe the system as an interconnection of blocks of objects having different desirable functionalities. For instance, a portable music player may be described by an embedded systems architect as a combination of a signal-processing unit that decodes the music, an audio output unit that plays it, a storage unit that stores music, and a power supply unit that provides power to all of the above sub-systems. The electronics engineer who is ultimately tasked with designing the electronics sub-system cannot think at this abstract level, but instead, is forced to think about what components to use, how to connect their power and ground lines, how to design the printed circuit board, how to lay out the components on it, where to provide decoupling capacitors or series terminations, and several other considerations that are purely electronics-related.

It is undeniable that any embedded systems design must ultimately be reduced to its component sub-systems. It is also undeniable that the most efficient utilization of resources, and the highest performance systems, will have to be designed by engineers skilled in each individual disciple as described above, and integrated by a very specialized and skillful architect who has wide interdisciplinary expertise.

However, in the current milieu of product design, there is a vast market for a class of devices that are neither optimal in their utilization of resources nor optimal in their delivery of performance, but are, rather, easier to design and implement. This market comes about because of reducing product lifecycles and decreasing component costs, and it has been shown that there is a substantial financial incentive in coming out with a product in rapid response to a customer's needs, and being able to rapidly customize it based on customer feedback.

There is great value in being able to describe an embedded system in a more natural, familiar and concise way. By establishing a (nearly) one-to-one mapping between real world devices, the electronics that interfaces with them, and the logic that controls the electronics, it is possible to write designs and programs that can be proved to be correct. It is also possible to greatly reduce the time taken to write and maintain these designs, and it becomes easy to communicate such designs between engineers.

OBJECTS OF THE INVENTION The primary object of the present invention is to develop novel improved computer architecture.

Yet another object of the present invention is to provide an innovative method of implementing embedded systems with increased design speed and efficiency.

Still another object of the present invention is an implementation of the improved computer architecture in hardware as well as in software as a library.

Still another object of the present invention is to provide a novel way of writing programs for the novel computer and new way of debugging such programs.

Still another object of the present invention is to create embedded systems with more than one controller and also to generate schematics of the PCB from the software specification.

STATEMENT OF THE INVENTION

Accordingly, the present invention provides for a An improved computer architecture comprising real device interfaces having device capabilities, device events and device state, configured to communicate and to control external pins and devices or external pins or devices that drive the corresponding devices in real world, which produce plurality of events; virtual device interfaces, configured to instantiate higher-order objects, namely state machines and control equations, which produce various events: and an event queue to process events from plurality of said real and virtual device interfaces, with listeners to initiate plurality of real and virtual device operations and stage change operations, also provides for a program execution mechanism within the said computer architecture, said mechanism comprising acts of: instantiating and initializing each real device having device capabilities, device events and device state; instantiating linkages between events and listeners of the instantiated real devices in device blocks and establishing linkages between the events and listeners of virtual devices with device events; initializing the device blocks using the computer, generating events from the initialized device blocks, and entering the initial state of the programmed state machines; activating listeners for all the real and virtual device objects; transforming the overall state of the computer by matching events with listeners, executing various transitions, and causing new events and listeners to be generated; and processing subsequent execution including debugging of all state machines and equations that constitute program by the execution model, further the present invention provides for a method of implementing an improved computer architecture, said method comprising acts of: describing the target application on a general-purpose computer, preferably the synthesis computer, as a hierarchy of real and virtual device, a plurality of state machines, and a plurality of declarative equations relating the state variables of the application mathematically; reading the target program and storing it in said synthesis computer's memory; parsing the stored program to extract meaningful information in the form of a tree; generating device and/or state dependency graph of an embedded system using the extracted information; extracting the computer architecture with synthesis software on the synthesis computer using the generated graph; and passing the extracted architecture through a plurality of output filters to obtain the improved computer architecture in a readily implementable form, and also provides for a method for designing embedded system board layout using improved computer architecture, said method comprising acts of: inputting system description into a system synthesizer; combining the inputted description with design library to determine whether the description is completely specified; generating schematics or netlist or components list from the determined description; and executing the generated netlist through CAD tool to perform placement and routing operations to obtain the board layout. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

The features described in this disclosure are set forth with particularity in the appended claims. These features and attendant advantages will become apparent from consideration of the following detailed description, taken in conjunction with the accompanying drawings. One or more embodiments are now described, by way of example only, with reference to the accompanying drawings wherein like reference numerals represent like elements and in which:

Figure 1 shows the architecture of a contemporary computer, and depicts why it is unsuitable for representing embedded systems.

Figure 2 shows the design of a new computer that circumvents the problems of the computer shown in Figure 1.

Figure 3 shows the internal construction and flow diagram of the novel computer of Figure 2.

Figure 4 shows a typical program that will be executed in the computer shown in Figure

3.

Figure 5 shows how the computer shown in Figure 3 executes the program shown in

Figure 4. Figure 6 shows the stages in creation of the design of the new computer of Figure 3 from its specifications and programs shown in Figure 5.

Figure 7 shows how the computer shown in Figure 3 may be designed as a software module in a high-level language.

Figure 8 shows the manner in which the software programs generated in Figure 7 are executed in a host processor running an emulator of the computer shown in Figure 3.

Figure 9 shows an innovative approach to debugging software problems in the new computer shown in Figure 3.

Figure 10 shows a manner in which state machines can run on more than one computer in a cooperative fashion if the computers are of the form described in Figure 3. Figure 1 1 shows the components that comprise the present invention, and how they interact with each other to completely specify the design of an embedded system. Figure 12 shows how the system shown in Figure 1 1 may be split into multiple sub- modules that are closely reflected by the computer implementation shown in Figure 5. Figure 13 shows a description of the embedded hardware system in a language that will allow it to be synthesized by a tool. Figure 14 shows the process of synthesizing the design of the embedded hardware system from the language shown in Figure 13.

DETAILED DESCRIPTION OF THE INVENTION

The primary embodiment of the present invention is an improved computer architecture comprising: real device interfaces having device capabilities, device events and device state, configured to communicate and to control external pins and devices or external pins or devices that drive the corresponding devices in real world, which produce plurality of events; virtual device interfaces, configured to instantiate higher-order objects, namely state machines and control equations, which produce various events; and an event queue to process events from plurality of said real and virtual device interfaces, with listeners to initiate plurality of real and virtual device operations and stage change operations.

Yet another object of the present invention the computer implements plurality of device objects.

Still another object of the present invention said external device is connected to_. the computer through said device object, and any state change of the external device results in an event generation.

Still another object of the present invention said listener belongs to a device object and the device object preferably be a real object or a virtual object.

Still another object of the present invention the listener belonging to said real object or said virtual object listens to one or more events generated either by the real objects or the virtual objects.

Still another object of the present invention the computer directly execute descriptions of state machines as programs fed to the computer that defines plurality states of embedded system as a whole. Still another object of the present invention the computer directly executes a declarative equation that relates various state variables associated with embedded system. Still another object of the present invention a listener is associated with each state variable found on right hand side or left hand side of the equation.

Still another object of the present invention the computer is turned into a low- power mode or sleep mode, whenever the event queue is empty. Still another object of the present invention is a program execution mechanism within the said computer architecture, wherein said mechanism comprising acts of: instantiating and initializing each real device having device capabilities, device events and device state; instantiating linkages between events and listeners of the instantiated real devices in device blocks and establishing linkages between the events and listeners of virtual devices with device events; initializing the device blocks using the computer, generating events from the initialized device blocks, and entering the initial state of the programmed state machines; activating listeners for all the real and virtual device objects; transforming the overall state of the computer by matching events with listeners, executing various transitions, and causing new events and listeners to be generated; and processing subsequent execution including debugging of all state machines and equations that constitute program by the execution model.

Still another object of the present invention the process of debugging comprises Logging the state of the state machine along with the exact time whenever change occurred in the machine by listening to all state variables; activating test bench mode of software in which an external and/or internal timer is hooked up and fed to a state-changer virtual device, if a bug in the state machine is found or if a particular user scenario is to be monitored; and reading the log and performing the state change operations in the state machine using the state-changer virtual device, depending on time at which the log specifies the change to occur, depending on the ticks from timer, as part of the test bench mode.

Still another object of the present invention said device listens to events on its own.

Still another object of the present invention the events extend and replace functionality of interrupts in a traditional computer.

Another important embodiment of the present invention is a method of implementing an improved computer architecture, said method comprising acts of: describing the target application on a general-purpose computer, preferably the synthesis computer, as a hierarchy of real and virtual device, a plurality of state machines, and a plurality of declarative equations relating the state variables of the application mathematically; reading the target program and storing it in said synthesis computer's memory; parsing the stored program to extract meaningful information in the form of a tree; generating device and/or state dependency graph of an embedded system using the extracted

, information; extracting the computer architecture with synthesis software on the synthesis computer using the generated graph; and passing the extracted architecture through a plurality of output filters to obtain the improved computer architecture in a readily implementable form.

Still another object of the present invention the information is selected from a group comprising plurality of devices, their properties and inter-connections; a list of states, each states' s actions and transitions; a list of declarative equations and the variables on the left and right hand side of the equations; and the different listeners attached to plurality of events when a new state is entered.

Still another object of the present invention the output filter is selected from a group comprising filters that generate hardware and software designs;, or the emulator model of execution, where the hardware design is simulated on a general-purpose computer; or the application description in a human readable form. Still another object of the present invention the human readable form is a set of graphical state diagrams, state maps, equations, descriptive text, and/or descriptive icons. Still another object of the present invention the synthesis software in hardware and software filter outputs a description of a portion of the computer in a hardware description language, and a software program that can be executed by the said computer as state machines, equations and device relationships.

Still another object of the present invention the method assigns which portions of design are to be implemented in hardware.

Still another object of the present invention the emulator model of execution generates a set of higher-level language files that simulate the hardware computer on a general purpose computer, as an output of the synthesis program. Still another object of the present invention the files are compiled in conjunction with a library that emulates processor event loop and a library that provides necessary hooks for plurality of real device block to generate stand-alone file that is executed on top of a preexisting processor. Still another object of the present invention the emulator model of execution comprises process emulator consisting of hardware features that define the computer as event list and event loop, objects list, device drivers, and any trace or debug functionality provided by the computer; Device library configured by implementation of real devices for the architecture of the processor hosting the emulation; and Virtual device library configured as state machines and/or active variables.

Still another object of the present invention the processor emulator initializes all the devices, sets up the state machines by entering their initial states, and loads the active variables comprising the left-hand sides of the declarative equations by queueing their listeners and evaluating their right-hand-sides and assigning the value to left-hand-side to start the execution of the embedded system in the emulator mode.

Still another object of the present invention the output filters shares common general device data structure, wherein said structure consists of a general object portion, list of pointers to events and device-specific portion. Still another object of the present invention the general object portion contains basic features consisting of object name and object type; and device-specific portion consisting of state variables, events and listeners that are associated with the device. Still another object of the present invention the general device data structure comprises architecture-specific implementation of interfaces for real devices. Still another object of the present invention the architecture provides for event channel to facilitate execution of state machine in a system containing plurality of processor.

Still another object of the present invention the architecture comprises device module that enables communication between the pluralities of processor by translating events generated on a processor into a local event. Anther important embodiment of the present invention is a method for designing embedded system board layout using improved computer architecture, said method comprising acts of: inputting system description into a system synthesizer ; combining the inputted description with design library to determine whether the description is completely specified; generating schematics or netlist or components list from the determined description; and executing the generated netlist through CAD tool to perform placement and routing operations to obtain the board layout. Still another object of the present invention the schematics preferably hardware schematics or netlist is automatically generated from software description of device functionality to assemble each module independently from the library containing a reference design of the module.

Still another object of the present invention the system description comprises design- specific description of a processor, architecture-specific description of the peripherals to determine mode of interconnection between the processor and the peripherals.

The present invention describes a novel class of embedded systems that are characterized by a greater integration of design concepts, and are therefore simpler to design and implement. The class of embedded systems described in this invention may be designed in as little as l/5^th of the time it takes to design a traditional embedded system of comparable functionality. The class of embedded systems described in this invention is also amenable to being designed by an architect with far less domain-specific knowledge in the fields of software and electronics as compared to a traditional embedded system of comparable functionality.

The invention described in this document comprises of three interlocking components: a new kind of computer which may execute programs that are described in a language that is more accessible to an embedded systems designer; a new kind of electronics hardware system that can be described in a language that is more accessible to an embedded systems designer; and a new mechanism of expressing computer programs that allow an embedded systems designer to describe it completely, more on the basis of its functionality than on the basis of its implementation.

The new kind of computer described in this invention may be implemented as a chip, as a processing element in a larger chip, or as an emulator running as software on an existing computer. This document describes the novel computer in sufficient detail to implement the invention as any of the above mechanisms.

The new kind of computer program described in this invention may be either executed directly as the machine language of the new computer or its software emulator, or translated into an existing language (such as C) and executed in conjunction with the software emulator of the new computer on existing systems.

The new class of electronics hardware systems described in this invention may be implemented as a digital or mixed-signal Application-specific IC, implemented in a Field-programmable Gate Array (FPGA) or Programmable System-on-Chip (PSOC), or actualized as a combination of schematic and layout for a printed circuit board of discrete electronic components. The electronics hardware system may also be implemented as a combination of the above mechanisms.

This invention not only covers the class of computers, programs and electronics subsystems that are described above, but also the set of tools that allow a designer to create the above sub-systems in a simple and elegant manner.

Aforementioned features will hereinafter explained in detail with reference to drawings and examples.

Figure 1 shows the mechanism of operation of a traditional computer. Computer operation codes are stored in the computer's main memory, where they are executed sequentially except on branch instructions. This single path of execution can also temporarily change due to software or hardware interrupts, which are serviced by interrupt service routines. Such interrupt service routines are asynchronous to the execution of the program that is running in the computer's main memory.

The execution model of a traditional computer, therefore, may be thought of as a single thread of execution that is suspended while executing interrupts, and after whose execution it resumes again. In a primarily 'imperative' programming model, where the designer creates a computer program by requesting the computer to perform several actions in sequence, this execution model is convenient to follow.

In embedded systems, however, a large number of branch operations depend, not only on the internal state of the processor, but rather on the state of various external devices. Similarly, the program itself modifies, not only the internal memory, but also the state of these external devices.

Since many of these operations may need to be executed asynchronously. and since many notifications of external state changes are received through interrupts, the process of designing a computer program for an embedded system is more complicated than designing it for a traditional computer. The typical flow of an embedded systems program interleaves the main thread of execution with interrupt handling, thereby constraining the programmer to the execution model of a traditional computer without giving any of the benefits of such an abstraction that could be obtained in a piece of 'pure' software.

Figure 2 shows the structure of the new computer being proposed in this invention. In such a computer, there is no single thread of execution that is sequentially run. Instead, the computer executes by reacting to a set of 'events'. The computer implements several 'device objects' that expand on the role that interrupts play in a traditional computer. Any state change of an external agency connected to the computer through a device object, results in an event being generated.

Each event has one or more listeners associated with it. A listener is a strand of code that is executed when an event is raised. A listener may initiate various state change operations, or may raise further events at a higher layer of abstraction.

A listener also typically belongs to a 'device object', though such a device object may be a virtual object as opposed to a real device. For example, a stepper, motor device object may attach a listener to a hardware timer device object, and drive the appropriate step signals depending on the timer's ticks. In this case, the stepper motor and the hardware timer are both 'real' devices. As another example, a stopwatch device object may attach a listener to a hardware timer device object, and may raise an event of its own when a certain number of time ticks have elapsed. In this case, a listener belonging to a virtual object, namely the stopwatch, is listening to an event generated by a real object, namely a timer. It is also possible to have a listener of a virtual device object listening to an event of another virtual device object.

This novel execution model of events and listeners replaces the traditional execution model of a single computer program which is asynchronously changed by interrupts. By itself, this new execution model permits an embedded systems designer to capture relationships between real-world objects through a much simpler abstraction when compared to the traditional execution model.

The novel computer described in this innovation provides two more layers of abstraction inherent to its design that allow a designer to conceptualize a design at a yet higher level. Building on top of the event and listener model described above, the computer may also directly execute descriptions of 'state machines' as programs fed to the computer. This execution model coexists and is built on top of the event/listener execution model described above.

In the state-machine execution model, the computer is fed a program that defines various states of the embedded system as a whole. Each state is associated with a number of entry and exit actions, and a number of state transition conditions that cause the state machine to move from one state to another. Such state machines are well-known in the field of computer science, and are traditionally implemented as a software abstraction. In most common implementations of state machines in traditional computers, a loop keeps checking the state of the system at a certain pre-defined time granularity, and depending on the state, various actions are taken. The state changes usually happen through asynchronous interrupts.

In addition to state machines, the computer described in this invention also supports the direct execution of another method of program specification, viz. declarative equations that relate various state variables associated with the system. For instance, in the PID control of an inverted pendulum, the velocity of the base of the pendulum (controlled through PWM of a DC motor input) is related to its position, velocity and acceleration. The computer described in this invention allows this relation to be specified directly as a equation relating the PWM duty cycle of a PWM device to the input received from an analog-to-digital converter that measures the position. To process such an 'program fragment¹, the computer sets up the input received from the analog-to-digital converter as an 'active variable'. An active variable is one whose change triggers an event.

The computer also queues a listener to the analog-to-digital converter on behalf of the PWM device. The trigger function of this listener computes the appropriate PID value of the PWM duty cycle and applies it to the PWM device. This operation is performed whenever the analog-to-digital converter value changes.

The computer described in this invention allows state machines and equations to be directly implemented as the execution model. The structures of the state machines and/or equations are stored in the main memory and replace the 'program' found in traditional computers. Each state, or variable found on the right-hand-side of an equation, is associated with a listener that monitors any events that may cause a transition into that state.

Figure 3 is a flow-chart that describes the program execution model of the computer. The entire operation is driven by the 'event queue'. Events are posted to the event queue by any state changes that occur on the external interfaces of the computer; the events extend and replace the functionality of interrupts in a traditional computer.

The computer is, for all intents and purposes, inactive unless the event queue becomes non-empty. When an event is posted to the event queue, the computer is activated and processes the event. The mechanism of processing the event takes the form of executing the listeners associated with the event.

The process of executing an event's listeners may, by its own accord, generate further events. For example, a stepper motor device may be listening to a timer device's tick event to control the speed of its stepping. Whenever the motor steps, it may also generate a step event. In this manner, the listener of the timer device also generates events of its own.

This process is repeated for all listeners on the event, and the event is then removed from the event queue.

The above steps are repeated for each event that is present in the event queue. When the event queue becomes empty, the computer again becomes idle until the next event is posted.

The fact that an event queue has become empty may be utilized by the computer for going into a low-power mode or sleep mode. This innovation allows the creation of computers that consume substantially lower power.

The process described above can be seen to be considerably different and novel compared to the standard execution model of a computer, in which statements are sequentially executed except for branch statements and interrupts. In the new execution model, all computer operations are reactions to real-world events. In this way, the execution model of the new computer accurately mimics the real world, allowing an embedded systems designer to design a substantially simpler program to control the computer, and through the computer to control external devices.

Figure 4 illustrates a simple program that demonstrates the above claims. In this program, a simple machine is described that achieves the vibration of a fixture by repeatedly rotating a motor in opposite directions with a period of 100 ticks of a clock. A text liquid crystal display (LCD) is attached to the machine, which displays whether the motor is rotating forward or backward.

The program to achieve all of the above functionality may take several hundred lines of code to create in a traditional computer program running on a traditional computer. In the present innovation, it is shown that the entire functionality is specified, completely and clearly, in no more than fourteen lines of code. The program shown in Figure 4 contains two sub-components. The first is a state machine called 'vibration'. The second is an equation that relates what is to be displayed on the LCD with the present state of the state machine.

The state machine is completely described by describing its devices and its functionality. The devices to be used in this state machine include a motor, whose forward and backward rotation achieves the vibration motion that the machine performs, and a timer, whose ticks control the number of steps the motor is to run in each direction before switching. The motor is given the name motor 1 and the timer is given the name timer 1. The state machine's functionality is described using a number of states, within which the state machine moves. In this case, two states are sufficient to describe the system: forward and backward. These are identified in the program as 'state forward' and 'state backward'.

Each state contains actions and transitions. An action is a set of instructions that is performed (without waits or blocking statements) by the computer. The operations of starting and stopping a motor are actions.

An action may be executed either at the entry of a state, or at the exit of a state, or as a response to a particular transition.

A transition is a combination of a condition that evaluates to either true or false, and a destination state that must be entered if the condition evaluates to true.

In the program shown in Figure 4, the 'state forward' contains an action that starts the motor called motor 1, which is executed when the state is entered. It contains a transition to the 'state backward' if the timer known as timer 1 times out.

In addition to actions and transitions associated with a particular state, the state machine may also contain actions and transitions that are associated more generally with more than one state. In the figure, these are depicted under the heading 'all states'. For example, in both states forward and backward, the timer timerl is set to raise a timeout event after 100 ticks. This timeout event is caught by the transitions described in the states forward and backward. Similarly, the action of stopping a motor (before starting it in the opposite direction) is performed in both states as an exit action.

If more than one transition is present from a state outwards, it is also possible to perform an exit action depending on the transition that causes the state machine to leave a particular state.

The above description explains all of the entries that constitute the description of the state machine. The syntactic elements that constitute the language in which the program is written include indentations, colons, and block delimiters that allow generic descriptions in high-level languages to be embedded in the action functions and transitions, so long as they follow the constraints that the action functions may not contain any statements that block program execution, and that the transitions are couched as conditions that return either true or false.

The second part of Figure 4 displays the description of an equation that governs the functioning of the LCD display. In this example, a simple relationship is shown, where the LCD text is the same as the name of the state of the state machine.

To actualize the functionality of the equation shown in Figure 4, the computer creates a listener on every variable that is used on the right-hand-side of the equation. All the variables used in the right-hand-side must be active variables, that is, any change to them must result in an event being raised. These events are caught by the listener, which reevaluates the left-hand-side of the equation and updates the LCD screen.

The process of updating the left-hand-side upon change of the right-hand-side is asynchronous to any timers or clocks (except, of course, the processor clock). This makes it in line with the real-life functioning of systems governed by such equations.

It may be noted that new virtual devices may also be created as state machines and equations, which can be further used in other state machines and equations as building blocks. Figure 5 shows the mechanism in which the program of Figure 4 is executed within the computer in question. Each real device is instantiated as a hardware or software block, which contains the device capabilities, the device events and the device state. This device block is also responsible for ultimately communicating with and controlling external pins that drive the corresponding devices in the real world.

In Figure 5, a timer (timer 1) and a motor (motor 1) are shown to be instantiated as real devices.

The linkages between the events and listeners of real devices are also instantiated in the device blocks directly.

In contrast to the real devices, the state machine and the active variable equation are instantiated as virtual devices. This means that these devices do not have a direct interface to physical devices, but are instead indirectly interfaced to them via real device blocks.

It must be noted that though only one level of hierarchy is shown in this figure, relating the real devices directly to the final abstraction of state machines or active variable equations, it is possible to have multiple levels of virtual devices in the device hierarchy on which the state machine is dependent.

The computer also establishes the linkages between the events and listeners of virtual devices with other device events that they are dependent on.

The computer begins execution by first initializing the device blocks. The initialized device blocks immediately start generating events. The system then enters the initial state of the state machine. If more than one state machine is present in the system, the initial states of each state machine are entered one after the other.

The execution of the initial state automatically causes all of the listeners to various transitions out of the initial state to be attached to their respective events. The computer also queues listeners to the change events of the variables on the right- hand-side of the equation. The computer also performs the evaluation of the right-hand- side of the active variable equation for the very first time.

The subsequent execution of all state machines and equations that constitute the program are automatically handled by the event handling flowchart as described in Figure 3.

It is important to note that the entire setup, of real and virtual device blocks, may be implemented in hardware, in which case the program may be considered as embedded in the hardware. It is also possible to implement some modules in hardware and some in software; for example, the real device control blocks and the event loop alone may be implemented in hardware, and the virtual devices may be instantiated in the computer's memory by software.

It must also be noted that it is possible to execute the entire program purely in software running on a host processor, by relying on the host processor's operating system or kernel device drivers to provide the real device blocks, and implementing the event loop as a software loop. This model of execution has great commercial value, since it may be executed directly on an existing computer without the creation of new hardware. This model of execution, where the event loop is performed in software, is referred to in the remainder of this document as the 'emulation' model of execution, since a small piece of software on the host processor emulates the behaviour of the novel computer being described in this invention.

Another benefit of executing the entire program in emulation mode is that it is possible to simulate and debug a complex embedded system in a PC (on which better debug and development tools are available) before implementing it in hardware.

Figure 6 displays these options graphically. In order to derive the novel computer's functioning as described in this invention, the basic program in the above examples is given as the input to a computer synthesis program. This program may be executed on a different platform compared to the computer under design, and may even be executed on a normal PC. This computer is henceforth referred to as the synthesis computer. Figure 6 shows the stages in creation of the new computer's design from its specifications. First, the target program is read and stored in the synthesis computer's memory. Next, this program is parsed to extract meaningful information, such as the various devices, their properties and inter-connections, a list of states, each state's actions and transitions, and the different listeners that must be attached to various events when a new state is entered. These together constitute the 'device and dependency graphs' of the embedded system.

Once the device and dependency graphs of the system have been extracted, the synthesis software on the synthesis computer may be said to 'understand' the architecture of the computer being described. It now passes this information through one of three different 'output filters', in order to obtain an implementation that is consistent with the design goal of the system's designer.

The first approach, shown in the left-most branch of the figure, is an hardware and software approach, where the synthesis software outputs a description of portions of the novel computer in a hardware description language such as VHDL or Verilog. It also outputs a program that will be executed by the novel computer as state machines and equations. It is possible to synthesize the processor of the new computer from the VHDL or Verilog description, and it is possible to run the program generated by the output filter on the new computer.

It is possible to delegate which portions of the design are to be implemented in software and which are to be implemented in hardware. If all components are implemented in hardware, the ¹ real and virtual devices are hard-coded into the hardware and no reprogramming may be possible. This may be beneficial in situations where a device may not be allowed to be reprogrammed by the user or by unauthorized personnel.

The second approach, shown in the middle branch of the figure, is the emulator model of execution. In this model, a set of higher-level language files (such as C source and header files) are generated as the output of the synthesis program. These files may be compiled in conjunction with a library that emulates the processor event loop, and a library that provides the necessary hooks for various real device blocks. The output of this compilation process is a stand-alone file that can be executed on top of a pre-existing processor.

The third approach, shown on the right side, does not generate a system as such, but instead generates human-readable documentation of the system. This may take the form of graphical state diagrams or state maps, which can be shared, communicated, and checked thoroughly by the system architects before implementation.

Figure 7 describes the emulator model of code execution in some more detail, and specifically describes the output of the synthesis program if the output filter chosen is the C language filter.

On the left side is shown the program controlling the vibration machine described in Figure 3. On the right side are shown specific syntactic elements of the C program that are generated by the synthesis software.

For instance, the state machine becomes a structure that has many of the properties of a general device. (This enables a state machine itself to be used in the composition of a more complex state machine.) Similarly, the various devices that constitute the state machine are also created as structures with the properties of a general device.

The states of the system are stored in an array within the state machine structure. Each state is a structure that contains the actions and transitions associated with it. Common actions and transitions are stored within the state machine structure directly.

The action functions and transition filters are converted into functions, and pointers to these functions are stored in the respective states, or in the state machine structure in the case of common actions and transitions.

Any active variable dependencies, as well as relationships implicit in a state transition condition, are used to derive the events on which they depend. Listeners for these events arc also stored in the device-like container of either the state machine, the active variable or the device block (as the case may be).

The general device structure shared by all three entities mentioned above is also shown in Figure 7. A general device data structure consists of a general object portion, containing basic features such as object name and object type, and also a list of pointers to events that will be generated by it. The structure also consists of a device-specific portion that consists of state variables, events and listeners that are associated with the device.

The general device data structure also contains architecture-specific implementation of interfaces in the case of real devices. For example, a motor device may identify the GPIOs to which it is interfaced. This component of the data structure will vary from board to board.

Figure 8 shows the overall environment in which an emulation model of execution may work. To the left side is the processor emulator. This consists of a simulation of the hardware features that define the new computer, such as the event list and event loop; objects list; device drivers; and any trace or debug functionality provided by the computer. The specific implementations of real devices for the architecture of the processor hosting the emulation constitute the Device Library, shown on the top-right side of the diagram. The virtual device implementations, such as state machines and active variables, are depicted on the lower right side of the diagram.

The processor emulator follows the same stages as the processor itself in order to load state machines, devices and active variable equations into memory. It initializes all the devices, sets up the state machines by entering their initial states, and loads active variables by queueing their listeners and initially evaluating their right-hand-sides, assigning the value to the right-hand-side. These processes kick-start the execution of the system in emulator mode.

Figure 9 depicts another claimed benefit of the invention, which is the capture and replay of state transitions happening within a program. In an embedded system, the capability of being able to debug a system thoroughly is limited due to the limited number of input and output channels. Problems happening on the field may be difficult to reproduce under controlled environments in traditional implementations.

In the invention described in this document, however, the process of debugging may be greatly aided by the knowledge that the state of a state machine may be logged whenever it changes, along with the exact time at which such a change occurred. This log requires minimal storage and processing resources. If a bug is found, or if a particular user scenario needs to be investigated further, a test bench mode of the software is activated, in which an external (or internal) timer is hooked up and fed to a state-changer virtual device. This state changer device reads the log, and depending on the time (which it listens to as ticks from the timer), artificially performs the state change operations in the state machine.

By going through the states in the exact manner in which they were processed while the problem occurred, it is often possible to reproduce mechanical or process-related problems that may have arisen outside the bounds of observation under normal circumstances.

Figure 10 depicts yet another innovative optimization that the new computer described in this invention lends itself to. This figure depicts the concept of an 'event channel' to facilitate the execution of a state machine in a system containing more than one processor.

The processing model described in Figure 2 for the new computer described in this invention does not mandate that the events must be generated purely internally as software abstractions. As shown in Figure 10, it is also possible for events generated on a processor to be communicated to another processor, where there is a device module that translates it into a local event. The channel by which the event is communicated from one processor to another is called an event channel. The event channel may be implemented in a multitude of ways, such as a GPlO pin, a serial or parallel communication bus, shared memory, etc. In this way, an event from one processor may be triggered on another processor, and a state machine may therefore contain events from both processors in its ambit.

Figure 1 1 moves away from the focus on the computer, which has been the main novelty described in the invention so far. to the embedded system as a whole. The computer by itself does not constitute the entire embedded system, but is only the central processor in it. Figure 1 1 shows the way in which the computer described above may form a part of a complete and fully-functional embedded system.

Shown in Figure 1 1 is the processor along with its peripherals. An embedded processor is typically interfaced to external RAM and Flash (if needed), and to several other peripherals such as communication devices (like Ethernet and UART ports), sensors (through analog-to-digital converters), actuators (like motors and solenoids) and user interfaces (such as keyboards and displays).

In many contemporary systems, the components described above are placed and interconnected on a printed circuit board (PCB). In addition to the components described above, some other components typically found on PCBs include power supplies, connectors and test points.

However, printed circuit boards are by no means the only mechanism of assembling a diverse set of components, including processors and peripherals, together into a circuit. Recent advances in digital electronics indicate an approach where the printed circuit board may be replaced by a programmable logic device, such as an Field-programmable Gate Array (FPGA), or a Complex Programmable Logic Device (CPLD). Recent inventions have also enhanced the domain of such programmable logic into the analog space, with products like Programmable Systems-on-Chip (PSOC).

This invention describes an innovative computer at the center of the above embedded system, and an innovative way of specifying programs that run on the computer. In addition, it also describes an innovative class of digital electronics circuits that can be automatically synthesized from a high-level description of the functionality of different building blocks. This high-level description of the system's functionality can be thought of as a logical extension of the program that runs in the computer described above. Since the first layer of events that impinge upon the computer are originated by actual hardware devices, the computer's design must contain a description of the various devices interconnected to it. From this description, it is possible to derive a description of the printed circuit board (or system-on-chip) on which it will be implemented. This invention also covers the class of systems that can be automatically generated by software means from such a description.

In order to automatically synthesize the hardware governing a chip from its software, the hardware is first broken apart into reusable modules that can be reassembled together to create the embedded system as a whole. This is shown in Figure 12. This breaking-apart of the system neatly mirrors the software architecture mandated by the processor, by dividing the system into three basic components. The first is the controller sub-system, which consists of the CPU, Random-access memory, and Flash or non-volatile storage. The second is the peripheral subsystem, which is derived from the device modules mentioned in the context of the new processor's design. The third is the power and miscellaneous components sub-system, which consists of a handful of common design elements that must be present in any embedded design. This also includes functionalities like reset, decoupling, terminations and test points.

The key idea of generating the hardware schematics, netlist and layout automatically from the software description of the device functionality as described in previous figures, is the fact that each module can be independently assembled from a library containing a reference design of the module, which parametrizes variations in how the module can be used. For example, a CPU will always need to follow the manufacturer's recommendations in terms of interfacing it with memory. However, its GPIO interconnections may be parameterized, since there is leeway accorded to the user about how to use them in a specific design.

Similarly, a motor driver manufacturer will specify how it is to be connected to power rails and a motor's output coils, but will leave the inputs as parameters. By combining the parameters of the motor driver and the parameters of the CPU, it is possible to uniquely spccifiy the interconnection of the CPU and the motor driver. The motor driver's reference design is in itself stored in a design library in a parameterized form, from which it can be embedded into any circuit.

Sometimes the parameter may not be specified as a pin, but as a relationship between an output parameter and a component value. For instance, the frequency of a timer may be related to the value of a capacitor within the timer sub-system. The parameter governing the system may, therefore, be specified as the frequency, from which the component values can be derived.

Figure 13 shows how parameters are typically specified, and also shows how the software requirements of the program in Figure 4 may be used to automatically generate such a recommendation, and still allow the user leeway to fine-tune based on other constraints. From the program of Figure 4, it is possible to identify that the design requires a processor, with a motor and a timer connected as peripherals. After the program has been synthesized, it is also possible to statically calculate the amount of RAM and flash that will be needed to store the program.

From the architecture-specific description of the peripherals, it is also possible to determine their mode of interconnection with the processor. For example, if a device is identified as being memory-mapped, it means that an address decoder is necessary on a device bus. This bus may be the external memory bus, or it may be an auxiliary bus that is created impromptu from GPIOs.

By assembling all of these inputs together, a file such as the one shown in Figure 13 is created. This puts down all of the parameters that are needed to fully specify the interconnection of different components of the system. Standard components, such as power supplies, are also specified in this file.

Figure 14 shows the design flow for how this file will be eventually converted into a schematic and a board layout for a printed circuit board, or a hardware description language and a floorplan for an integrated circuit or FPGA. A detailed design library is maintained of all the components that will be used in the design, such as motors, processors, timers, power supplies, and other components. This may be maintained as netlists with parameters, or as hardware description language fragments (Verilog or VHDL fragments with embedded parameters).

A system synthesizer takes the system description of Figure 13 as an input, combines it with the design library to check if it is fully specified and if so, creates the schematics, netlist and components list from it.

This netlist can then be run through a CAD tool to perform placement and routing to obtain the final board design. This process may be partially manual, or may be made fully automatic by deriving the final board design as a series of engineering change orders (ECOs) of a reference board design. Many CAD tools have extensive and efficient Auto- ECO features.

In this way, it is possible for embedded systems to specify, at the top level, through a series of state machines and equations, the functionality needed for the product as a whole.

The innovative computer architecture proposed in this invention not only implements the specification as a fully-featured software and processor design, but is also able to make substantially time-saving contributions to the hardware design process by generating schematics and parts lists.

This allows designers to focus purely on defining functionality, without going through the nitty-gritty of a design, allowing them to be more productive, efficient and profitable.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

We claim:

1. An improved computer architecture comprising: i. real device interfaces having device capabilities, device events and device state, configured to communicate and to control external pins and devices or external pins or devices that drive the corresponding devices in real world, which produce plurality of events; ii. virtual device interfaces, configured to instantiate higher-order objects, namely state machines and control equations, which produce various events; and iii. an event queue to process events from plurality of said real and virtual device interfaces, with listeners to initiate plurality of real and virtual device operations and stage change operations.

2. The computer architecture as claimed in claim 1, wherein the computer implements plurality of device objects.

3. The computer architecture as claimed in claims 1 and 2, wherein said external device is connected to the computer through said device object, and any state change of the external device results in an event generation.

4. The computer architecture as claimed in claim 1, wherein said listener belongs to a device object and the device object preferably be a real object or a virtual object.

5. The computer architecture as claimed in claim 4, wherein the listener belonging to said real object or said virtual object listens to one or more events generated either by the real objects or the virtual objects.

6. The computer architecture as claimed in claim 1, wherein the computer directly execute descriptions of state machines as programs fed to the computer that defines plurality states of embedded system as a whole.

7. The computer architecture as claimed in claim 1, wherein the computer directly execute declarative equations that relates various state variables associated with embedded system.

8. The computer architecture as claimed in claims 1 and 7, wherein a listener is associated with each state variable found on right hand side or left hand side of the equation.

9. The computer architecture as claimed in claim 1, wherein the computer is turned into a low- power mode or sleep mode, whenever the event queue is empty.

10. A program execution mechanism within the said computer architecture as claimed in claim 1, wherein said mechanism comprising acts of: i. instantiating and initializing each real device having device capabilities, device events and device state; ii. instantiating linkages between events and listeners of the instantiated real devices in device blocks and establishing linkages between the events and listeners of virtual devices with device events; iii. initializing the device blocks using the computer, generating events from the initialized device blocks, and entering the initial state of the programmed state machines; iv. activating listeners for all the real and virtual device objects; v. transforming the overall state of the computer by matching events with listeners, executing various transitions, and causing new events and listeners to be generated; and vi. processing subsequent execution including debugging of all state machines and equations that constitute program by the execution model.

1 1. The mechanism as claimed in claim 10, wherein the process of debugging comprises i. Logging the state of the state machine along with the exact time whenever change occurred in the machine by listening to all state variables; ii. activating test bench mode of software in which an external and/or internal timer is hooked up and fed to a state-changer virtual device, if a bug in the state machine is found or if a particular user scenario is to be monitored; and iii. reading the log and performing the state change operations in the state machine using the state-changer virtual device, depending on time at which the log specifies the change to occur, depending on the ticks from timer, as part of the test bench mode.

12. A mechanism as claimed in claim 10, wherein said device listens to events on its own.

13. The model as claimed in claim 12, wherein the events extend and replace functionality of interrupts in a traditional computer.

14. Λ method of implementing an improved computer architecture, said method comprising acts of: i. describing the target application on a general-purpose computer, preferably the synthesis computer, as a hierarchy of real and virtual device, a plurality of state machines, and a plurality of declarative equations relating the state variables of the application mathematically; ii. reading the target program and storing it in said synthesis computer's memory; iii. parsing the stored program to extract meaningful information in the form of a tree; iv. generating device and/or state dependency graph of an embedded system using the extracted information; v. extracting the computer architecture with synthesis software on the synthesis computer using the generated graph; and vi. passing the extracted architecture through a plurality of output filters to obtain the improved computer architecture in a readily implementable form.

15. The method as claimed in claim 14, wherein the information is selected from a group comprising plurality of devices, their properties and inter-connections; a list of states, each states's actions and transitions; a list of declarative equations and the variables on the left and right hand side of the equations; and the different listeners attached to plurality of events when a new state is entered.

16. The method as claimed in claims 14, wherein the output filter is selected from a group comprising filters that generate hardware and software designs; or the emulator model of execution, where the hardware design is simulated on a general-purpose computer; or the application description in a human readable form.

17. The method as claimed in claim 16, wherein the human readable form is a set of graphical state diagrams, state maps, equations, descriptive text, and/or descriptive icons.

18. The method as claimed in claims 14 and 16, wherein the synthesis software in hardware and software filter outputs a description of a portion of the computer in a hardware description language, and a software program that can be executed by the said computer as state machines, equations and device relationships.

19. The method as claimed in claims 14, wherein the method assigns which portions of design are to be implemented in hardware.

20. The method as claimed in claims 14 and 16, wherein the emulator model of execution generates a set of higher-level language files that simulate the hardware computer as claimed in claim 19 on a general purpose computer, as an output of the synthesis program.

21. The method as claimed in claim 19, wherein the files are compiled in conjunction with a library that emulates processor event loop and a library that provides necessary hooks for plurality of real device block to generate stand-alone file that is executed on top of a pre-existing processor.

22. The method as claimed in claim 16, wherein the emulator model of execution comprises i. process emulator consisting of hardware features that define the computer as event list and event loop, objects list, device drivers, and any trace or debug functionality provided by the computer; ii. Device library configured by implementation of real devices for the architecture of the processor hosting the emulation; and iii. Virtual device library configured as state machines and/or active variables.

23. The method as claimed in claim 21, wherein the processor emulator initializes all the devices, sets up the state machines by entering their initial states, and loads the active variables comprising the left-hand sides of the declarative equations by queueing their listeners and evaluating their right-hand-sides and assigning the value to left-hand- side to start the execution of the embedded system in the emulator mode.

24. The method as claimed in claim 16, wherein the output filters shares common general device data structure, wherein said structure consists of a general object portion, list of pointers to events and device-specific portion.

25. The method as claimed in claim 24, wherein the general object portion contains basic features consisting of object name and object type; and device-specific portion consisting of state variables, events and listeners that are associated with the device.

26. The method as claimed in claim 24, wherein the general device data structure comprises architecture-specific implementation of interfaces for real devices.

27. The computer architecture as claimed in claim 1 , wherein the architecture provides for event channel to facilitate execution of state machine in a system containing plurality of processor.

28. The computer architecture as claimed in claim 27, wherein the architecture comprises device module that enables communication between the pluralities of processor by translating events generated on a processor into a local event.

29. A method for designing embedded system board layout using improved computer architecture, said method comprising acts of: i. inputting system description into a system synthesizer ; ii. combining the inputted description with design library to determine whether the description is completely specified; iii. generating schematics or netlist or components list from the determined description; and iv. executing the generated netlist through CAD tool to perform placement and routing operations to obtain the board layout.

30. The method as claimed in claim 29, wherein the schematics preferably hardware schematics or netlist is automatically generated from software description of device functionality to assemble each module independently from the library containing a reference design of the module.

31. The method as claimed in claim 29, wherein the system description comprises design- specific description of a processor, architecture-specific description of the peripherals to determine mode of interconnection between the processor and the peripherals.