Web-Enabled DSP/Microcontroller
Simulator
Project Literature Survey
Chuanjun Wang
chjwang@cs.utexas.edu
http://www.cs.utexas.edu/users/chjwang/
Embedded Software Systems
Dr. Brian Evans
Abstract
Web-Enabled Electronic Design (WELD) at the University of California
at Berkeley aims to construct the first operational prototype of a national-scale
CAD design environment enabling Internet-wide IC design for the U.S. electronics
industry. The Web-Enabled Simulation (WEDS) framework from the University
of Texas at Austin complements WELD by adding support for the simulation,
debugging, and design of software for embedded processors. WEDS is
a client/server framework that current offers interfaces to one microcontroller
simulator, two digital signal processor (DSP) simulators, and one DSP board.
WEDS consists of GUI Java applets running on the client side, a multi-threaded
TCP/IP communication server (Java application) running on the server, and
a group of simulators and debuggers for DSPs and microcontrollers.
WEDS relies on sockets, multiple threads, and Unix interprocess communication,
but does not offer Internet privacy and security. In this project,
we will expand WEDS by adding another DSP simulator, abstracting the protocol
between Java clients and server, enhancing security and privacy, and exploring
its integration into WELD.
1 Introduction
Computer-Aided Design (CAD) tools are essential for designing integrated
circuits and their importance is increasing as circuit designs become more
and more complex. With the development of microelectronics technology like
deep sub-micron technology, new Electronical Design Automation(EDA) tools
and methodologies to reduce product development time and cost are emerging
all the time. Most of these tools are currently very loosely coupled.
However, increased chip densities and the design of higher performance
systems have outgrown the current era of loose collections of EDA tools.
Designs across the next decade will demand integrated and highly inter
operable systems that allow the designer to traverse back and forth among
sophisticated CAD tools at all levels of design from architecture through
implementation. Keeping pace with this advancement and the required designer
productivity improvements will necessitate cooperative work across the
industry toward creating a highly scalable and robust environment in order
to meet EDA system needs in the area of designer productivity and design
complexity management.
Distributed computing, Client/Server technology, Object Oriented paradigm,
and the tremendous growth of Internet bring us opportunities to solve this
problem. Now the World Wide Web(WWW) has changed and is continuing changing
many aspects of our life. The natural features of the web like scalability,
platform independence, portability, timely distribution, robustness, and
flexibility are perfect fits for the new needs of EDA. The great advantages
of putting system level design tools on the web has already been realized
by some CAD tools vendors and researchers.
For the system level design, there are basically three tasks:
-
Management of complexity and heterogeneity
When different CAD tools are distributed on the web, we will have a
lot of troubles to get/increase the inter-operability, to manage the heterogeneity.
-
Simulation
Simulation is used extensively to evaluate the performance and verify
correctness of digital systems. Correctness, efficiency, and convenience
are definitely the essential goals we need to achieve when the system level
design tools go to the web.
-
Synthesis
System level synthesis is based on a high level specification. Specifically,
the specification is in a high level programming language and a Hardware
Description Language (HDL), like C, Verilog, C++ and VHDL. It is an indispensable
part of the system level CAD tools.
1.1 WELD
Web-Enabled Electronic Design (WELD) project at the University of California
at Berkeley was born in 1996 to solve this great challenge. It is the first
web based circuit design tools environment. The WELD project aims to construct
the first operational prototype of a national-scale CAD design environment
enabling Internet-wide IC design for the U.S. electronics industry. WELD's
goals are dual. In the small, WELD will empower individual American electronics
designers by affording them efficient desktop access to, and seamless interoperability
of, the numerous, heterogeneous resources forming a national scale electronics
design system built upon the National Information Infrastructure. In the
large, WELD will reduce electronics industry market entry barriers to new
entrepreneurs by providing a streamlined pay-per-use design development
environment and a robust software distribution infrastructure. In reducing
the costs, and shortening the time-to-market of new intellectual capital,
WELD is expected to stimulate the whole U.S. electronics industry to dramatic
new growth.
We can see WELD is an extremely ambitious project. Simply speaking,
they want to set up an WWW based design environment which can
-
provide platform independence
-
leverage existing software, systems and tool kits
-
build consistent and intuitive user interfaces
-
provide highly scalable system architecture
-
support a wide range of computing resources
-
provide innovation and collaboration with large user base via Internet
-
build in implicit parallelism
-
provide on-demand access.
By doing the above, WELD will
-
allows people to rapidly integrate and deliver complex design components
-
enables true world wide collaboration
-
provides tools and user scalability
-
helps manage intellectual property in the form of designs, tools and services.
The system of WELD consists of three parts: remote servers, network services,
clients. The architecture of WELD is illustrated in the following picture.
The clients communicate with communication server which provides network
services. And the communication server dispatches the requests of clients
to remote servers over the the distributed environment or on the same machine.
There are five major fields the WELD project is putting effort in.
The design driver, the user interface, the services, the server technology,
and the decision support are major technologies WELD is based on.
As far as the client end, WELD currently can provide the following Java
tools library functions, including Java Tools for Design and Building Blocks.
-
Java Tools for Design
-
Finite State Machine Editor with Synthesis and Automatic State Assignment
-
DigSim Schematic Editor and Simulator, Modified to Interact with Synopsys
Design Compiler
-
Group Status Applet
-
JavaTime - Real-time package for Java
-
Building Blocks
-
Original DigSim Schematic Editor / Simulator
-
ViewGraph Editor
-
Graph Display Applet
-
Java Math Mode
There are three big challenges for WELD to reach its goals. They are:
-
scalability, including both tools and user scalability
-
security, privacy and fairness
-
reliability, robustness and quality of services.
1.2 PPP
PPP is part of Distributed Tools for Collaborative Research projects co-sponsored
by ARPA as part of a multi-university project, including Stanford University,
called Vela.
PPP is a Web-based environment for Low-Power Design. It is a paradigm
for integrating EDA tools running on distributed platforms under a common
user interface. Its Graphic User Interface is a set of dynamically generated
HTML pages that can be accessed through any Web browser. Three sets of
tools are available: Synthesis for low-power, Power Optimization and Power
Simulation. File Transfer utilities are also available to upload input
files and download results.
Minimum support is required on the user side to access the features
offered by a large and diverse set of tools: the user's WWW browser is
the interface for all interactions. Integrating new tools in the environment
is a straightforward process that do not require any effort from the end
users. So it is quite scalable. The learning curve is extremely short,
no time is required to familiarize with new graphical user interfaces because
the well-known user interface provided by the WWW browser is exploited.
PPP is a prototype implemented to show the feasibility of WWW-based tool
integration.
PPP consists of tools for Synthesis for Low Power, Power Optimization,
and Power Simulation. Its user interface is a set of dynamically generated
HTML pages that can be accessed through any Web browser. File transfer
utilities allow users to upload the input files on the server and download
the final results or the status logs.
The Low Power Synthesis tool in PPP performs automatic Gated-Clock generation,
using the algorithms presented by Benini. Starting with a FSM specification
in the kiss2 format, the tool finds idle conditions for which the clock
can be stopped, thus saving power, without sacrificing functionality. The
output after synthesis is a mapped verilog netlist using the gate level
simulator in PPP.
The Power Optimization tool starts with a circuit specified in the slif
format, and targets the minimization of the peak current for sequential
circuits based on edge triggered flip flops (with a single clock). This
minimization is based on the algorithms presented by
Vuillod et. al. A mapped circuit and the clock skew values are the
outputs of the tool.
The Power Simulation tool embeds an accurate simulator for power and
current estimation that operates at the gate level, based on the symbolic
model of CMOS gates proposed by A. Bogliolo et. al. The outputs of the
simulator are power statistics, current waverforms and average/instantaneous
power/energy dissipation data.
Design Flow of PPP
The design flow of PPP is represented in the diagram below.
Description of The Main Tools
Four major tools are integrated in PPP: File Transfer, Synthesis, Optimization
and Simulation.
The file transfer in PPP is based on the FTP protocol. The user can upload
the input files on the server and download the final results or the status
logs. Recent browsers (such as Netscape v.2 and above) fully support upload
and download based on anonymous FTP. If the browser does not support bi-directional
FTP connection, the traditional Unix' ftp command can be used to perform
file transfer. Notice that each user in PPP has a disk quota. If the quota
is exceeded on the server the user session will be terminated. This is
a form of protection against excessive usage of servers' disk space. The
default user quota is 20Mb.
The synthesis tool in PPP performs automatic Gated-Clock generation, using
the algorithms presented by Benini et. al. The starting point for synthesis
is the FSM specification in kiss2 format. The tool finds idle conditions
where the clock can be safely stopped without compromising the functionality
(while saving power). If the FSM is a Mealy machine, it is automatically
transformed in a functionally equivalent FSM for which self-loop extraction
is more profitable. A complete path from synthesis to accurate
power estimation is implemented in PPP. The power dissipation of the
gated clock implementations is automatically estimated, and the best solution
is chosen. The output provided by synthesis is a mapped verilog netlist
that implements the specification with reduced power consumption. The user
can simulate the netlist using the gate-level simulator in PPP.
The optimization embedded in PPP targets the minimization of the peak current
for sequential circuits based on edge-triggered flip-flop (with a single
clock). The circuit is initially specified in slif. The peak current minimization
is based on the algorithms presented by Vuillod et al.: clock skew is constructively
exploited to reduce the number of events (and dynamic current) synchronized
with the clock. It is possible to specify the number of clock drivers allowed
in the circuit and generate a clustered solution (only NP
different skews are allowed, where NP is the number of clock drivers).
A mapped circuit and the clock skew values are the final outputs of the
optimization phase. The quality of the results is estimated and validated
exploiting the accurate current estimation capabilities of the gate-level
power simulator within PPP.
PPP embeds an accurate simulator for power and current estimation that
operates at the gate level. It is based on the symbolic model of CMOS gates
proposed by A. Bogliolo et. al.. The simulator has accuracy close to electrical
simulation and speed similar to traditional gate-level simulators. The
input of PPP is a mapped verilog netlist. Hierarchical verilog descriptions
are supported as long as the leaf cells are pre-characterized library elements.
The output of the simulator are power statistics, current waverforms and
average/instantaneous power/energy dissipation data. Currently only one
library has been fully characterized and can be used for power estimation.
The simulator is used for estimation and validation during gated-clock
synthesis and clock skew optimization, the other two main features embedded
in PPP.
1.3 Chipwise Tutor
Chipwise Tutor is an integrated, network based, Computer Based Learning
(CBL) system for Very Large Scale Integration (VLSI) design. This system
is based around the bi-directional interface of the WWW browser, to the
Chipwise VLSI design system. Chipwise Tutor provides the user with interactive,
hypermedia based courseware from which the design tools can be controlled
and with context sensitive help pages integrated with the courseware and
application. The University of Kents CHIPWISE Web Pages are at the URL:http://eleceng.ukc.ac.uk/chipwise/index.html.
1.4 CyberCut
CyberCut is a web based design-to-prototype or design-to-fabrication project
in University of California at Berkeley. Cybercut allows users to quickly
design and manufacture prototypes for mechanical parts. A series of interactive
web pages act as an on-line CAD tool linked to a 'computer machinist',
which restricts the user to the sign of manufacturable parts. When the
design is completed, the part specifications are sent directly to a computer
controlled three axis milling machine, and fabrication can begin immediately.
1.5 Tech-On-Line DSP Debuggers
Tech-On-Line provides DSP debuggers for two C30 and two C50 boards. In
order to use this services, you need to reserve time slots first. Then
you telnet to their server at reserved tim. The connection is quite slow.
It's basically for demonstration purpose only. They provide now clean way
to transfer files.
2 Objectives
In our proposed project, Web-Enabled Simulation(WEDS), we aim to
establish a scalable and secure client/server framework on the web that
can offer interfaces to some microcontroller simulators, digital signal
processor (DSP) simulators, and DSP board simulators. First of all, why
we need standalone DSP/microcontroller simulators?
2.1 DSP/microcontroller Simulator
The DSP/microcontroller Simulator is a software tool for developing programs
and algorithms for DSP/microcontrollers. The simulator exactly duplicates
the functions of supported DSP/microcontroller chips, usually including
all on-chip peripheral operations, all memory and register updates associated
with program code execution, and all exception processing activity. The
device's pipelined bus activity is exactly simulated. This enables the
Simulator to provide the user an accurate measurement of code execution
time, which is so critical in DSP applications.
The Simulator executes object code which can be generated using either
the device Macro Assembler program or the Simulator's internal single-line
assembler. The object code is loaded into the simulated device's memory
map. The entire internal and external memory space of the DSP/microcontroller
is simulated. During program debug the user can display and change any
of the device's registers or memory locations. Instruction execution can
proceed until a user-defined breakpoint is encountered, or in single-step
mode, stopping after a specified number of instructions or cycles have
executed.
From what a DSP/microcontroller simulator can do we can see the advantages
of why we need Standalone DSP Simulators.
First, it supports system level design tools.
-
Leverage existing simulators or disassemblers
-
Validate them to be cycle-accurate and bit-true
-
Extend them to support different boards and hypothetical configurations
-
Return implementation cost estimates
-
Make portable across computer platforms
-
Report pipeline hazards
Second, it supports control by a parent process.
-
Separate the user interface from the kernel
-
Add hooks to configure the parent process(es) that controls it
-
Support pipes by flushing all output
2.2 Web-Based DSP/microcontroller Simulators/Debuggers
Web-Based DSP/microcontroller Simulator/Debuggers provides web access to
DSP/microcontroller simulators/debuggers. It has the following advantages:
-
profile and validate embedded software
-
learn DSP/microcontroller architectures
-
evaluate different DSP/microcontroller architectures
-
access latest technology immediately since it is on the web
-
can simulate the whole system
-
reduce the workstation expenses for dedicated DSP/microcontroller simulators.
All you need is a desktop machine, a Java enabled browser and Internet
connections.
In order to make the Web-Based DSP/microcontroller Simulators/Debuggers
system to be scalable, portable, secure and efficient, we need to provide
portability, authentication, privacy, security to both the client users
and the server.
The Web-Based DSP/microcontroller Simulators/Debuggers system consists
of GUI Java applets running on the client side, a multithreaded TCP/IP
communication server(Java application) running on the server, and a group
of simulators and debuggers for DSPs, microcontrollers and/or other boards.
For the consideration of portability and user friendliness, we choose
Java for most the programming. As long as the users have Java-enabled web
browser, the client side program can be executed. For the server side,
it is also very easy to port the server program to other platforms as long
as they support Java Virtual Machine. So by choosing Java, the code itself
will be quite portable.
For scalability, first, on the server side, it is easy to expand the
set of DSP/microcontroller simulators/debuggers being supported since all
the simulators/debuggers are standalone and separate from the communication
server. Second, on the client side, since we will develop a protocol to
configure the services available on the server and communicate this information
the client side at the beginning, the client program doesn't need to do
anything. It will be automatically configured.
For security and privacy, we will need authentication for client connection
requests, encryption for user files, protection of user files and setting
up quota/limitation for users.
2.3 Challenges
Web-Based DSP/microcontroller Simulator/Debuggers system has the following
challenges:
-
portability limited by Java. Java itself is always changing. The current
version is not even compatible with the previous versions.
-
efficiency limited by Java Virtual Machine and web browser.
-
security also limited by Java's security architecture. Java applets do
not have privileges to access local file system. So we either have to develop
our proprietary file transfer(upload/download) by HTML form based file
upload (specified in RFC1867) in Java for the Java server program, or we
have to ban the transfer of files from local file system to the server.
-
privacy. We will provide protection between user files. Besides authentication,
encryption is also evolved.
3. Implementation Proposal and Innovation
To enhance the current system, I plan to do the following things.
-
Clients dynamically configure themselves by communicating with the server
what kind of services available. This is done every beginning by a protocol
between the client and the server.
-
Subscription of server service. Authenticated user can add/drop the services
they want by sending the subscription/unsubscription requests. This will
be useful for auditing or charging by usage.
-
Add another DSP simulators in the system.
-
Provide authentication for usage, data encryption for user files. Since
all the files are stored on and owned by the server, we need to enhance
the file system to provide protection among our clients. All these files
should be protected from web browser or FTP. Only the owner can retrieve
them. So, the following tasks need to be done:
-
client authentication
-
users' source file encryption and decryption
-
enhanced file system
-
file transfer protocol between client and TCP server
-
More functionalities for the DSP simulator(Unix process), say to generate
the binary code.
-
Possibility of integrating into WELD.
References
[1] Richard A. Newton, "Web-Based Electronic Design (WELD) Project,'' http://www-cad.eecs.berkeley.edu/Respep/Research/weld/,
Dept. of Electrical Eng. and Comp. Sciences, The University of California,
Berkeley, CA, 94720.
[2] C. S. Smith and P.K. Wright, ``Cybercut: a World Wide Web based
design-to-fabrication tool,'' Journal of Manufacturing Systems,
vol. 15, no. 6, pp.432--442, 1996.
[3] L. T. Walczowski, W. A. J. Waller, and D. Nalbantis, ``VLSI design
training with the help of the World Wide Web,'' in IEE Colloquium on
Learning at a Distance: Developments in Media Technologies, (London,
UK), June 1996.
[4] L. Benini and A. B. G. D. Micheli, ``Distributed EDA tool integration:
the PPP paradigm,'' in Proc. IEEE Int. Conf. on Computer Design,
(Austin, Texas), pp.448--453, Oct. 1996.
[5] B. L. Evans, "Web-based Simulators of Embedded Software for Programmable
Digital Signal Processors," http://www.ece.utexas.edu/~bevans/talks/WebSimulatorTools/,
March 14, 1997.
[6] Tech-On-Line, http://www.techonline.com, March, 1998.