Embedded processors are everywhere. Almost everything powered by electricity has an embedded processor for the control or processing functions (or both) required by the application. The proliferation and the ever-increasing sophistication of these processors over more than three decades have been driven by decreasing costs and increasing processing and controlling power.
Moore's law, competitive pressure, and rapid innovation in consumer devices have led to everyday devices incorporating machines that have the same processing power that mainframe enterprise computers delivered not so long ago.
Much of this innovation has been driven by human consumer behavior that, after a while, tends to ignore linear improvements but responds strongly to exponential advances, thus driving the push to more powerful systems with more features and more complexity. As a consequence, it is now common for consumer devices to incorporate embedded processors with processing power in triple-digit MIPS,
Gigabytes of storage, and access to all kinds of commonly used communication protocols is not a problem with respect to the hardware available (the processors themselves) nor to the software development tools, operating systems, or compilers. In addition, the embedded designers themselves have the capacity to understand the evolving hardware and software and to use them to build marketable applications.
Rather, the problems that complexity brings are related to the fact that human design bandwidth has not grown at the same rate as processing power. As a result, ever-increasing complexity brings inevitable delays and simply adding people is not the answer as many well-known books on productivity (The Mythical Man-Month is perhaps the best known) have shown.
The current situation
Designing a modern embedded system is a complex multi-tiered activity. First comes the need to define the behavior required of the system by its potential customers and to understand the competitive landscape and how to leverage it.
Next comes determining if the needed competence exists in the organization, and reducing/relating the system specifications to the software, tools, processors, and other components required. All of these major tasks need to be completed before the actual task of designing hardware and writing code can begin.
Once all the background work to get a design underway is done, the hard, repetitive work of hardware and software design begins. Typically, embedded designs consist of selections from three major categories of blocks: Processing, digital (peripherals and logic), and analog (the physical interface for sensing and controlling).
A system is generally assembled of various components from the three major categories based on the hardware interfaces required by the system, and the software must be built to make the system perform the processing and control functions required. Once a particular design is “set” in software and hardware, it is difficult, costly, and time-consuming to change because of interactions between software and hardware within the classes of blocks.
Embedded designers need to get to market ahead of their competitors. To have an early market advantage and re-use their investments in knowledge and tools as much as possible, their selected architectures and design platforms have to be flexible and adaptable.
These tools and components must enable significant last minute changes (indeed, continuous changes), as well as be able to utilize industry standard eco-systems to take advantage of a large developer community and standard tools.
Compounding these challenges is the fact that the longer the design cycle, the higher the probability of the design requirements changing, which, of course, makes the design cycle even longer, and so on. Rapid product development therefore not only provides a financial advantage but reduces uncertainty and offers the possibility of earlier customer feedback and market leadership.
A new way of designing
Given that a typical embedded system is a combination of processing anddigital and analog blocks, and that the embedded system consists of thewhole of the combining these blocks with the appropriate software,developers need to ask the following key questions:
1. How do we make sure we're speeding up the total design process? Amdahl's law, paraphrased, states that it is the sequential portion ofthe total processes that determine the overall potential improvement.As applied here, some basic processes must change.
2. How do we accelerate the learning phases in order to convergemore quickly on the marketable design? Experience teaches us thatit's far better to go through a process of stepwise refinement andconvergence than to push system testing out to the end. A corollary ofthis is that the earlier bugs are found, the cheaper they are toaddress.
3. How do we reduce overall design effort ? Put another way,which parts of the system can be provided for in terms of reusablemodules or generated intelligently to save time and effort.
4. How do we allow for rapid change in all phases of the designprocess? Design changes made earlier in the design process areeasy to implement. Because of interdependencies across a design, it'snot at all easy to make rapid changes once a design has firmed up.
5. How do we allow for updating both hardware and software in thefield? It's relatively easy, given that some means ofcommunications exist, to update embedded software. Additionallysoftware updates have become quite common and are accepted by manyconsumers as part of the ownership experience of certain electronicdevices. The difficulty is in updating hardware functionality as well.For example, what if the behavior of a certain state machine needs tobe changed, or if the machine has to perform different tasks atdifferent times?
6. How do we allow for standard tools to be used? Ascompilers and debuggers evolve over time, there is much learning andimprovement (and at many users' expense) embodied in standard tools.New embedded design techniques must support the use of industrystandard tools to maximize improvement gains while minimizing designerlearning investment.
7. Are we providing a Platform? It is essential that ascalable platform, in terms of well-defined hardware and softwarearchitectural features, be provided so that designs may be scaled,depending upon the application, and previous efforts can be reused(whether hardware or software).
The ideal embedded platform would therefore have a basic functionalstructure that is highly flexible and dynamically modifiable. It wouldalso automate all steps of the development cycle other than creatingthe code the embedded systems designer develops for the particularapplication.
The architecture would be highly scalable to support reusability ofknowledge and tools and be based on the use of standard developmenttools supported by a large ecosystem. In addition, it would incorporatesystem-level integration and low power and size by being incorporatedin silicon built using advanced processes so as to optimize value tothe customer and reduce overall power consumption.
A new design flow
Such an architecture calls for an approach vastly different from thoseemployed in building an embedded design using microcontrollers withfixed functionality and external components and developing software andfirmware manually. This design approach would be based on an integratedembedded solution with well-defined hardware and software.
The hardware would consist of a scalable silicon platform consistingof a processing subsystem (including memory); an analog subsystemconsisting of various functional blocks and commonly usedfixed-function peripherals; and programmable digital blocks, allconnectable via a true switched fabric.
The software would consist of a development environment which,starting with a blank canvas, allows the user to construct a completesystem consisting of:
Commonly used peripherals
Serial Communication Blocks
Standard Analog blocks
Hierarchically created components (in other words, created by theuser)
The software tool would embody several complex functions:
A blank canvas for the user to place and connect components fromthe list above.
A comprehensive list of common prebuilt configurable componentsfor users to select from and place on the canvas
The ability to place Boolean primitives, create componentsembodying other functions, and specify the behavior of components viaRTL.
Fixed-function and/or programmable resources that would beselected as required.
Synthesis of user RTL, placement of components in the design andfitting functionality to programmable digital logic resources.
Placing and routing components on the silicon platform using aswitched fabric including connections to the user's choice of I/O pins.
Generating APIs (including APIs for user-defined components) anddevice drivers for prebuilt components. APIs created for theuser-defined components would allow passing of parameters toconstituent blocks.
Allowing the functionality of blocks to be dynamicallyreconfigured based on software commands, if so required.
Generate datasheets for component blocks and the chip-level entity.
Once all the above are completed, the user would then be able to addapplication code, working with the compilers and debuggers of hischoice, to the now-optimized device. This process may be,simplistically, represented in a flow-chart in Figure 1 .
Some examples of configuring various subsystems are shown below.
Clocking: The user is given the following menu to selectclock sources from. Selection of a clock source is as easy as selectingand clicking; all connections on-chip, control register set-up, andinitial clock configuration is done automatically.
Interrupts: An ISR (Interrupt Service Routine) editorallows any digital signal to be connected to an interrupt input. Suchtools would allow assigning a particular Interrupt priority and vectornumber to a signal.
DMA: DMA is another example of a global resource (likeclocking and interrupts) that many blocks may choose to use (in otherwords, it is up the user). The DMA editor would show all peripheralsconnected to the DMA request inputs and will allow priority settings soas to guarantee optimum throughput for all its clients.
What does it take to do this?
In our Programmable SoC architecture, Cypress has implemented a precursor of this new design flow. Experiencegathered over several years of implementing and refining that flow withthe help of thousands of customers has provided invaluable insight inthe new directions the design flow can take. A new embedded design flowsuch as this cannot be defined in one area. It must encompass thefollowing elements:
1. A Silicon platform that can be scalable and reusable in terms ofboth hardware and software.
2. A Software development environment that automates componentselection and generation as much as possible with the goal of creatingsoftware interfaces (APIs) for all customer-specified blocks so thatdesigners can focus on developing their value-added application code.
3. The use of standard tools and debuggers. In this way, designerscan leverage reusability and take advantage of the learning curve thatstandard tools have benefited from, as well as tap into the largeecosystems that grow around industry standard tools.
Ata R. Khan , vice president of technical staff at CypressSemiconductor Corp., is responsible for strategic marketing andarchitecture for new Programmable System-on-Chip products. He joinedCypress in November 2006 from NXP (formerly Philips Semiconductors).Ata has an MSEE degree from UC Berkeley, an MBA from the University ofSanta Clara, and a BSEE from the NED Engineering University.