Marty Stanquist
2011-10-09 19:50:21 UTC
With next generation Fortran development underway, I would like to request
your inputs on the possibility of extending the Open Watcom platform to
include support for Hardware Description Languages, also known as HDL's,
particularly for the languages Verilog, VHDL, and Ada. Ada is not
technically an HDL, but it is an effective language for embedded systems
programming and for implementing a VHDL compiler front end. I'd like to
outline a new project to extend Open Watcom to the arena of multi-language
embedded system simulation. In the discussion below, I will outline the
rationale, scope, forum, and timeframe for the project and provide some
useful resource links. I would like to request that you review the
discussion and comment on its nature, usefulness, and implementation.
Marty
Rationale
-------------
As embedded system development progressed throughout the 1970's and 1980's,
much of the product development cycle was spent working in the lab with a
hardware breadboard connected to a logic analyzer and a microprocessor
emulator. After weeks of lab development refining the prototype, many more
weeks were usually spent testing the prototype in the field under real world
conditions. This field testing often resulted in additional changes that
required additional lab testing. As a result, hardware development cycles
were often measured in terms of months and years instead of in terms of
weeks. As technology progressed throughout the 1990's and 2000's, computer
simulation in a number of different areas (circuit, logic, mechanical,
fluid, electromagnetic, etc.) reduced or completely eliminated much of the
required lab work. Designs were simulated, prototypes were fabricated,
verification tests were run, and the final prototypes were sent straight to
the field for real world testing. With designers having access to fast
simulators, the cycle times needed to correct field issues was significantly
reduced. Simulation has helped companies reduce their development schedules
by many months. As we move forward into the current decade, with multi-core
PC's loaded with gigabytes of ram and terabytes of disk, companies are
beginning to do most of the real world field testing right on the computer
using large, highly sophisticated physical models. These physical models
often contain hundreds of thousands (sometimes millions) of lines of C++ or
Fortran. An example illustrating the use of large physical modeling is how
UAV's are simulated flying through windy mountain passes and canyons with
all the engines, propellers, servos, ailerons, radars, and flight processors
actively running. Additionally, cars are now simulated in skid and crash
tests with the engine, drive train, suspension, anti-lock brakes, fuel
injection, and steering systems all fully engaged. These car models often
include a simulated driver or crash dummy as well. And not to be forgotten,
Nasa has simulated every Space Shuttle and deep space mission in this manner
for many years. Full real world system simulation has dramatically reduced
product development times by eliminating the need for extensive lab and
field testing. It is evident that we are entering the age of multi-language,
multi-disciplinary system simulation in which products go straight from the
simulator to a field evaluation unit then right to production. The need for
hardware simulation capability in this process, namely having access to
Verilog, VHDL, and Ada compilers, in addition to support for C, C++, and
Fortran is thus a mission critical requirement. This is the rationale for
pursuing the project.
Scope
--------
I am anticipating three phases of implementation.
The initial phase will have the following objectives:
* Develop individual compiler front ends for Verilog (using C) and VHDL
(using Ada)
* Develop a sufficiently complete Ada compiler for compiling the VHDL
front end
* Integrate Verilog, VHDL, and Ada compilers into the existing OW
framework
* Develop initial C interface libraries (VPI/VHPI) for Verilog and VHDL
Verilog, VHDL, and Ada will be separate, individual compilers that will
generate object files compatible with the existing linker, debugger, and
other tools. Ada has merits of its own, but it is syntactically very close
to VHDL and is an effective language for implementing the VHDL compiler
front end. It would be worthwhile developing a minimal Ada compiler just
capable enough to compile a VHDL front end written in Ada. Verilog is
syntactically close to C. I believe the existing C compiler front end could
be copied and easily modified to parse Verilog. The intent is to have all
three compilers use as much of the existing code generator software as
possible and to have Verilog and VHDL share a common runtime library that
will include a logic simulator. A logic simulator is a program that
evaluates and propagates logic switching events throughout a hardware design
using a data structure called an event wheel, or more technically a circular
event queue. Both Verilog and VHDL will additionally have separate runtime
libraries for C interface functions (VPI for Verilog, VHPI for VHDL) that
will need to be developed. The compiler will parse each HDL design file (.v
or .vhd), converting it directly into an object file (.obj). A simulation
executable file (.exe) is then created by linking all the HDL object files
(.obj) with a common simulator runtime library (.lib). This is what is
referred to as compiled simulation. The resulting simulation executable
(.exe) can be run either by itself to produce text and binary output files,
run along with a waveform viewer to produce real-time signal traces, or run
within the debugger along with the HDL and C/C++/Fortran source files in
what is called source level debugging. Since Verilog and VHDL object files
(.obj) will be compatible with all the other OW tools, C, C++, and Fortran
behavioral models will be able to be linked along with the HDL design files
then simulated and debugged together.
The second phase will have the following objectives:
* Develop a common logic synthesis back end for Verilog and VHDL
* Extend Verilog and VHDL compliance to the latest standards
* Further develop the C interface libraries (VPI/VHPI) for Verilog and
VHDL
* Develop a waveform viewer and a schematics editor for evaluating output
results
In synthesis mode, logic synthesis routines will replace the machine op-code
optimization routines in the existing compiler back end. Logic synthesis
works by generating and manipulating either logic gates or structures called
the configurable logic blocks of field programmable gate arrays, known as
FPGA CLB's. This is in contrast to generating and manipulating the cpu
op-codes that are processed by the existing compiler back end. Logic
synthesis algorithms are somewhat related to the existing op-code
optimization algorithms in that they modify the gates or CLB's generated
under the constraints of size and speed, or more specifically the
constraints of circuit area and logic delay. Synthesis algorithms differ in
that they use a different data structure called a binary decision diagram,
also known as a BDD, during the optimization process. The compiler parses
the HDL source files (.v or .vhd) and presents the synthesis routines with a
list of intermediate symbols representing the HDL design. The set of
existing intermediate symbols will need to be extended to include objects
like modules, processes, and signals that are present in HDL designs but are
not currently supported by the C, C++, and Fortran standards. The synthesis
routines convert these intermediate symbols into BDD's that are then
manipulated based on area and delay constraints provided for the hardware
design. Once optimized, the BDD's are then either converted to object files
(.obj) for gate level simulation or are converted to a hardware net-list for
integrated circuit (IC) or field programmable gate array (FPGA)
implementation. A hardware net-list is a listing of all the logic device
inputs and outputs along with all the logic signals interconnect them. In
the last stage of logic synthesis, referred to as retargeting, one must
choose a specific logic family or FPGA device from a given hardware vendor.
The vendor's specific device, or target library will include all the gate
and/or CLB definitions, the gate and/or CLB pin-outs, and all the
predetermined timing delays for the particular logic family or FPGA device.
In addition to processing the vendor timing delays, the final synthesis
routines will also request physical wiring delays that are generated by an
external IC or FPGA layout tool. This external delay processing, known as
timing back-annotation, is implemented using a timing file called the
standard delay file (.sdf). Gate level simulation takes into account all the
vendor target library delays and all the wiring delays determined by
external physical layout tools. The C interface libraries VPI for Verilog
and VHPI for VHDL will also need further enhancement. Additionally, since
the Verilog, VHDL, and Ada standards are currently in flux, much like those
for Fortran, additional work will be needed to update the compilers to the
latest specifications. Verilog is specified by IEEE 1364, VHDL by IEEE 1076,
and Ada by ISO/IEC 8652.
The third phase will have the following objectives:
* Add code generators and simulation models for embedded microcontrollers
* Add virtual system emulation and debugging support
* Add static timing capability to the logic synthesis routines
* Further enhance Ada language compliance and support
To augment the system's ability to simulate and debug embedded software,
code generators and simulation models will be developed for common embedded
microcontrollers, such as those in the 68K, Mips, and Arm families. Of
these, I suspect that Arm support will be a priority. The goal will be to
cross-compile the real-time source code to a given target cpu then engage
the source level debugger while the machine code executes on a Verilog or
VHDL simulation model of the target microcontroller. Since most embedded
systems have flash memories, UART's, timers, external logic, A/D and D/A
converters, buttons, displays, Ethernet and USB ports, and a real world
external environment, simulation models of these common components and
support for a built-in virtual machine environment (similar to QEMM) would
be both highly useful and desirable. Having all this support inclusive to
Open Watcom would be a major objective. Additionally, further system
enhancements will include adding static timing analysis capability to the
logic synthesis routines and further augmenting Ada language compliance.
Static timing analysis is a back end process that computes the worst case
timing delays through a gate logic network determining if critical set-up
and hold-time requirements are met for the flip-flop storage elements. This
is an analysis technique that eases the workload of verifying timing
requirements for full gate level simulations (most often a daunting
exercise). Static timing analysis has the ability to analyze a full gate
level design for the extremes of voltage and temperature, a technique known
as 4-corner testing.
Forum
--------
As the project moves forward, we are considering establishing a new
newsgroup to facilitate further discussion. This will be the news group:
openwatcom.users.hdl
Moving forward, I expect to be an active participant in the .contributors,
.hdl, and .fortran news groups while being generally available in chat room
#watcom at irc.freenode.net in the evenings and weekends CST US.
Timeframe
--------------
I would like to begin working on the project definition this fall while
coding efforts are underway for Fortran 2012. Phase 1 coding for the Verilog
and VHDL compilers could commence sometime after the OW 2.0 release this
spring. Coding for phase 2 and 3 is probably going to take a full year after
that. The coding priority right now is to complete Fortran 2012 for
integration into RC1 early next year.
Links
-------
Here are a few links that I hope you will find useful.
Hamburg VHDL Archive
http://tams.informatik.uni-hamburg.de/research/vlsi/vhdl
IEEE VHDL P1076 Working Group
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome
EDA Industry Working Groups
http://vhdl.org
GHDL (Gnu VHDL) Project
http://home.gna.org/ghdl
FreeHDL & Savant Projects
http://www.freehdl.seul.org
http://secs.ceas.uc.edu/~paw/savant
IEEE P1364-2005 Working Group
http://www.verilog.com/IEEEVerilog.html
Verilog Dot Com
http://www.verilog.com
Icarus Verilog
http://iverilog.icarus.com
Veriwell Verilog
http://sourceforge.net/projects/veriwell
MVSIS Project (Berkeley)
http://embedded.eecs.berkeley.edu/Respep/Research/mvsis
ABC Project (Berkeley)
http://www.eecs.berkeley.edu/~alanmi/abc
Ada Standards
http://www.adaic.org/ada-resources/standards
Boeing Flies on 99% Ada
http://archive.adaic.com/projects/atwork/boeing.html
-----------
your inputs on the possibility of extending the Open Watcom platform to
include support for Hardware Description Languages, also known as HDL's,
particularly for the languages Verilog, VHDL, and Ada. Ada is not
technically an HDL, but it is an effective language for embedded systems
programming and for implementing a VHDL compiler front end. I'd like to
outline a new project to extend Open Watcom to the arena of multi-language
embedded system simulation. In the discussion below, I will outline the
rationale, scope, forum, and timeframe for the project and provide some
useful resource links. I would like to request that you review the
discussion and comment on its nature, usefulness, and implementation.
Marty
Rationale
-------------
As embedded system development progressed throughout the 1970's and 1980's,
much of the product development cycle was spent working in the lab with a
hardware breadboard connected to a logic analyzer and a microprocessor
emulator. After weeks of lab development refining the prototype, many more
weeks were usually spent testing the prototype in the field under real world
conditions. This field testing often resulted in additional changes that
required additional lab testing. As a result, hardware development cycles
were often measured in terms of months and years instead of in terms of
weeks. As technology progressed throughout the 1990's and 2000's, computer
simulation in a number of different areas (circuit, logic, mechanical,
fluid, electromagnetic, etc.) reduced or completely eliminated much of the
required lab work. Designs were simulated, prototypes were fabricated,
verification tests were run, and the final prototypes were sent straight to
the field for real world testing. With designers having access to fast
simulators, the cycle times needed to correct field issues was significantly
reduced. Simulation has helped companies reduce their development schedules
by many months. As we move forward into the current decade, with multi-core
PC's loaded with gigabytes of ram and terabytes of disk, companies are
beginning to do most of the real world field testing right on the computer
using large, highly sophisticated physical models. These physical models
often contain hundreds of thousands (sometimes millions) of lines of C++ or
Fortran. An example illustrating the use of large physical modeling is how
UAV's are simulated flying through windy mountain passes and canyons with
all the engines, propellers, servos, ailerons, radars, and flight processors
actively running. Additionally, cars are now simulated in skid and crash
tests with the engine, drive train, suspension, anti-lock brakes, fuel
injection, and steering systems all fully engaged. These car models often
include a simulated driver or crash dummy as well. And not to be forgotten,
Nasa has simulated every Space Shuttle and deep space mission in this manner
for many years. Full real world system simulation has dramatically reduced
product development times by eliminating the need for extensive lab and
field testing. It is evident that we are entering the age of multi-language,
multi-disciplinary system simulation in which products go straight from the
simulator to a field evaluation unit then right to production. The need for
hardware simulation capability in this process, namely having access to
Verilog, VHDL, and Ada compilers, in addition to support for C, C++, and
Fortran is thus a mission critical requirement. This is the rationale for
pursuing the project.
Scope
--------
I am anticipating three phases of implementation.
The initial phase will have the following objectives:
* Develop individual compiler front ends for Verilog (using C) and VHDL
(using Ada)
* Develop a sufficiently complete Ada compiler for compiling the VHDL
front end
* Integrate Verilog, VHDL, and Ada compilers into the existing OW
framework
* Develop initial C interface libraries (VPI/VHPI) for Verilog and VHDL
Verilog, VHDL, and Ada will be separate, individual compilers that will
generate object files compatible with the existing linker, debugger, and
other tools. Ada has merits of its own, but it is syntactically very close
to VHDL and is an effective language for implementing the VHDL compiler
front end. It would be worthwhile developing a minimal Ada compiler just
capable enough to compile a VHDL front end written in Ada. Verilog is
syntactically close to C. I believe the existing C compiler front end could
be copied and easily modified to parse Verilog. The intent is to have all
three compilers use as much of the existing code generator software as
possible and to have Verilog and VHDL share a common runtime library that
will include a logic simulator. A logic simulator is a program that
evaluates and propagates logic switching events throughout a hardware design
using a data structure called an event wheel, or more technically a circular
event queue. Both Verilog and VHDL will additionally have separate runtime
libraries for C interface functions (VPI for Verilog, VHPI for VHDL) that
will need to be developed. The compiler will parse each HDL design file (.v
or .vhd), converting it directly into an object file (.obj). A simulation
executable file (.exe) is then created by linking all the HDL object files
(.obj) with a common simulator runtime library (.lib). This is what is
referred to as compiled simulation. The resulting simulation executable
(.exe) can be run either by itself to produce text and binary output files,
run along with a waveform viewer to produce real-time signal traces, or run
within the debugger along with the HDL and C/C++/Fortran source files in
what is called source level debugging. Since Verilog and VHDL object files
(.obj) will be compatible with all the other OW tools, C, C++, and Fortran
behavioral models will be able to be linked along with the HDL design files
then simulated and debugged together.
The second phase will have the following objectives:
* Develop a common logic synthesis back end for Verilog and VHDL
* Extend Verilog and VHDL compliance to the latest standards
* Further develop the C interface libraries (VPI/VHPI) for Verilog and
VHDL
* Develop a waveform viewer and a schematics editor for evaluating output
results
In synthesis mode, logic synthesis routines will replace the machine op-code
optimization routines in the existing compiler back end. Logic synthesis
works by generating and manipulating either logic gates or structures called
the configurable logic blocks of field programmable gate arrays, known as
FPGA CLB's. This is in contrast to generating and manipulating the cpu
op-codes that are processed by the existing compiler back end. Logic
synthesis algorithms are somewhat related to the existing op-code
optimization algorithms in that they modify the gates or CLB's generated
under the constraints of size and speed, or more specifically the
constraints of circuit area and logic delay. Synthesis algorithms differ in
that they use a different data structure called a binary decision diagram,
also known as a BDD, during the optimization process. The compiler parses
the HDL source files (.v or .vhd) and presents the synthesis routines with a
list of intermediate symbols representing the HDL design. The set of
existing intermediate symbols will need to be extended to include objects
like modules, processes, and signals that are present in HDL designs but are
not currently supported by the C, C++, and Fortran standards. The synthesis
routines convert these intermediate symbols into BDD's that are then
manipulated based on area and delay constraints provided for the hardware
design. Once optimized, the BDD's are then either converted to object files
(.obj) for gate level simulation or are converted to a hardware net-list for
integrated circuit (IC) or field programmable gate array (FPGA)
implementation. A hardware net-list is a listing of all the logic device
inputs and outputs along with all the logic signals interconnect them. In
the last stage of logic synthesis, referred to as retargeting, one must
choose a specific logic family or FPGA device from a given hardware vendor.
The vendor's specific device, or target library will include all the gate
and/or CLB definitions, the gate and/or CLB pin-outs, and all the
predetermined timing delays for the particular logic family or FPGA device.
In addition to processing the vendor timing delays, the final synthesis
routines will also request physical wiring delays that are generated by an
external IC or FPGA layout tool. This external delay processing, known as
timing back-annotation, is implemented using a timing file called the
standard delay file (.sdf). Gate level simulation takes into account all the
vendor target library delays and all the wiring delays determined by
external physical layout tools. The C interface libraries VPI for Verilog
and VHPI for VHDL will also need further enhancement. Additionally, since
the Verilog, VHDL, and Ada standards are currently in flux, much like those
for Fortran, additional work will be needed to update the compilers to the
latest specifications. Verilog is specified by IEEE 1364, VHDL by IEEE 1076,
and Ada by ISO/IEC 8652.
The third phase will have the following objectives:
* Add code generators and simulation models for embedded microcontrollers
* Add virtual system emulation and debugging support
* Add static timing capability to the logic synthesis routines
* Further enhance Ada language compliance and support
To augment the system's ability to simulate and debug embedded software,
code generators and simulation models will be developed for common embedded
microcontrollers, such as those in the 68K, Mips, and Arm families. Of
these, I suspect that Arm support will be a priority. The goal will be to
cross-compile the real-time source code to a given target cpu then engage
the source level debugger while the machine code executes on a Verilog or
VHDL simulation model of the target microcontroller. Since most embedded
systems have flash memories, UART's, timers, external logic, A/D and D/A
converters, buttons, displays, Ethernet and USB ports, and a real world
external environment, simulation models of these common components and
support for a built-in virtual machine environment (similar to QEMM) would
be both highly useful and desirable. Having all this support inclusive to
Open Watcom would be a major objective. Additionally, further system
enhancements will include adding static timing analysis capability to the
logic synthesis routines and further augmenting Ada language compliance.
Static timing analysis is a back end process that computes the worst case
timing delays through a gate logic network determining if critical set-up
and hold-time requirements are met for the flip-flop storage elements. This
is an analysis technique that eases the workload of verifying timing
requirements for full gate level simulations (most often a daunting
exercise). Static timing analysis has the ability to analyze a full gate
level design for the extremes of voltage and temperature, a technique known
as 4-corner testing.
Forum
--------
As the project moves forward, we are considering establishing a new
newsgroup to facilitate further discussion. This will be the news group:
openwatcom.users.hdl
Moving forward, I expect to be an active participant in the .contributors,
.hdl, and .fortran news groups while being generally available in chat room
#watcom at irc.freenode.net in the evenings and weekends CST US.
Timeframe
--------------
I would like to begin working on the project definition this fall while
coding efforts are underway for Fortran 2012. Phase 1 coding for the Verilog
and VHDL compilers could commence sometime after the OW 2.0 release this
spring. Coding for phase 2 and 3 is probably going to take a full year after
that. The coding priority right now is to complete Fortran 2012 for
integration into RC1 early next year.
Links
-------
Here are a few links that I hope you will find useful.
Hamburg VHDL Archive
http://tams.informatik.uni-hamburg.de/research/vlsi/vhdl
IEEE VHDL P1076 Working Group
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome
EDA Industry Working Groups
http://vhdl.org
GHDL (Gnu VHDL) Project
http://home.gna.org/ghdl
FreeHDL & Savant Projects
http://www.freehdl.seul.org
http://secs.ceas.uc.edu/~paw/savant
IEEE P1364-2005 Working Group
http://www.verilog.com/IEEEVerilog.html
Verilog Dot Com
http://www.verilog.com
Icarus Verilog
http://iverilog.icarus.com
Veriwell Verilog
http://sourceforge.net/projects/veriwell
MVSIS Project (Berkeley)
http://embedded.eecs.berkeley.edu/Respep/Research/mvsis
ABC Project (Berkeley)
http://www.eecs.berkeley.edu/~alanmi/abc
Ada Standards
http://www.adaic.org/ada-resources/standards
Boeing Flies on 99% Ada
http://archive.adaic.com/projects/atwork/boeing.html
-----------