| [ Abstract |Version | People | Images | About ] |
|
|
AbstractAs
embedded systems become increasingly complex, designers are turning to
Model-Driven Engineering (MDE) approaches to manage the complexity. MDE
approaches promise decreased design time, reduction in implementation
errors, and improved portability. However, an MDE approach does not
yield an implementation that is easily portable and is efficient in
terms of performance and power consumption. This is primarily due to a
fundamental mismatch between the specification used in the MDE design
and the target microprocessors. The target abstraction for a
microprocessor is an instruction set architecture that executes a set
of instructions sequentially. This target has little relation to the
inherently concurrent stream based nature of a large set of embedded
system application area.
To address this issue, researchers have previously proposed new abstractions, based in software to represent a better match between the design specification and the implementtaion target. However, these abstractions incur costs in terms of power and performance.Further, for each new procesor, the abstraction must be ported. The variants of every single processor must be characterized with respect to power and performance in sufficient detail to allow for the tools to make implementation decisions : this turns out to be a daunting task given that there are hundreds of variants of the PIC architecture alone. This project typically encompasses the embedding computing space served by low-cost 8-bit microprocessors, such as the PIC processor. The focus is to develop a new computer architecture family that presents an abstraction that is well-matched to the type of representation used in the typical MDE-based design. The new architecture is not a traditional ISA. It is an event based design that has similarities to dataflow and coarse-grain reconfigurable architectures. The architecture presents an abstraction that includes the precise timing of events as well as the energy cost of operation. The architecture is structures to take advantage of modern, power-efficient deisgn strategies such as asynchronous circuits, subthreshold-voltage circuits and leakage-aware design. Back to top |
VersionArchitectureVersion 1.0
of the architecture consists of hardware modules such as an
A2D or
a statemachine
that communicate via single or multiple bus(es). The hardware blocks
are configurable and once configured, they continue the operation until
it is reconfigured or powered off. The design of the hardware module is
such that every module has two parts : the wrapper and the internal
block. The wrapper structure is typically the same for all the hardware
modules. The internal block contains the specifics with respect to a
particular hardware module. In this way, the design of any new hardware
module is simplified because only the internal module needs to be
modified. Every
hardware module puts data onto the bus only in the predefined time
slots to avoid bus contention. The wrapper has configuration registers
that contain the destination address and the delay for every output of
the hardware module. The scheduling of the architecture ensures that
delay values for every output of a hardware module avoids bus
contention. Version 1.0 is targeted, but not restricted, to an
8-bit architecture. The
packet width for inter-module communication is 12 bits and the bus
width can be any divisor of the packet width 1,2,3,4,6. The packet
width of 12 imposes limitations on number of wrapper registers and
their maximum value. For example, the maximum delay value that any
module can be configured with is 31.
FrameworkApart from the design of the basic architecture modules, an architecture exploration framework is being developed for the same. The primary aim of the framework is to identify the most suitable architecture (or a set of architectures) for the given set of applications. Thus, if the range of applications for which the processor will be used is given as input, the framework will output the optimal architecture for the set of applications. This is achieved by scheduling the application, binding it to a particular architecture, and, analysis of simulation and synthesis results through an automated tool-chain. All the results are managed in a database. The entire framework was implemented in python with the core algorithms implemented in C language to speed up the process. The framework generates the initial programming (configuration) bytes directly from the high-level graph of the application. Included in the framework is the automatic generation of the top level HDL design for a given architecture and automatic test stimulus generation for the simulations (pre-synthesis, post-synthesis and post-layout). In version 1.0, the framework takes two primary inputs. The first one is a single application which will run on the architecture. The second input is a template architecture description defined using the ADL. From the template architecture, different architectures are created by varying the bus width. The design files for these architectures are automatically created using the code generation module. The application is represented as a graph which is scheduled and bounded to each of the generated architectures using a backtracking algorithm. Then, through the automated tool-chain, simulation and synthesis results are generated. In version v1.0, these results have to be analyzed manually. FocusAlex Turcu
Karthick Lakshmanan
Ramya P Narayanaswamy
|
PeopleDr. Tom Martin Dr. Mark Jones Karthick Lakshmanan Ramya P Narayanaswamy Alex Turcu Back to top |
Images[Click on the thumbnails to view the image]  Figure 1: Example instance of the proposed architecture that is designed to sample a set of analog inputs, filtering the results, and transmitting them over a network.  Figure 2: Graph representation of a Thermostat application, where, based on the comparison between a user input and the current temparature, a state machine controls a heater.  Figure 3: Schematic of the generated Architecture(obtained through Synopsys Designvision tool).  Figure 4: Pictorial representation of the automatically generated schedule. (Red boxes indicate execution of a block, yellow boxes indicate writing onto bus and black boxes indicate reading from bus)  Figure 5: Physical Layout of the synthesized Architecture. (Obtained using Cadence SoC Encounter tool)  Figure 6: Post-layout simulation output of the application on a particular architecture. (Obtained using Synopsys VCS tool) |
AboutThis material is based upon work supported by the National Science Foundation under Grant No. CNS-0834490. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. Back to top |
|
This website
was designed by Karthick and Ramya using KompoZer
v0.7.10 on Ubuntu
GNU/Linux
(C) E-Textiles Lab, Virginia Polytechnic and State University, Blacksburg, VA |