A Partial paper. --- Sorry, no more details at this time.
Software/Hardware Equivalency in "Software defined Systems"
This paper addresses further developments of a novel Mixed-Signal design concept as presented by Wolfgang Eberle, IMEC senior scientist in Mixed-signal systems design.
(EETimes Oct. 26, 2002, http://www.msmisp.com/futuretest/mixed-signal.htm
(A large file which needs to be printed for easy reading. Maximize size in Page
Setup for top/bottom.) --- While Eberle
demonstrated his findings for a design of a wireless LAN transceiver (Software
Defined Radio), the application here is the design of a digital oscilloscope
(Software Defined Instruments). A first design for this new type of
architecture, and a Software/Hardware Co-design methodology, was done in 1990
for an international design contest sponsored by Harris Semiconductor and Embedded
Systems Programming magazine. This first design used the, then new,
RTX2001A, RISC type Forth chip by Harris, and the present design uses a
Motorola HC12 with lower power consumption, and a patented RIS digitizer.
The main reasons given by Eberle for this new mixed-signal concept is to provide a solution for the unavoidable problems presented by process variations in extreme submicron technology for mixed-signal SoCs. However, there are other advantages to his concepts, and I have discovered an additional method which causes a drastic reduction of the number of hardware components, or a reduction in SoC chip size.
How came this reduction in hardware about? The answer might be my choice of programming language. A language which will induce the designer to minimize the size of his mixed-signal hardware. Of course, all modern languages are "universal" and could work, but for this application the language should also make it easy to inter-mix hardware with software and allow for a painless co-design procedure. FORTH is not only such a language, its very nature helps finding these novel structures which reduce the hardware-content of a system. During the design of the hardware of this "Software Defined Instrument" I was actually "thinking in Forth", just as Leo Brodie recommends it in his book by the same title. One could actually say, "The hardware is designed in FORTH!"
I will not attempt to explain this here in detail; you'll have to read the Brodie book. (And see my circuits) The introduction with the chapter on "Component Programming" is the key. He writes about "decomposing" an application into (Forth) "components", not into "structures" or the conventional modules. For him, a <component> is:
"The smallest set of interacting data structures and algorithms that share knowledge about how they collectively work. --- A Component is a resource, which involves data objects and algorithms. It doesn't matter whether the data object is physical (such as a hardware register), or abstract (such as a stack location)." [ It doesn't matter whether the algorithm is in code or done by a "finite-state machine" in hardware. ]
Another important concept, which is part of the above, is the "uses" hierarchy from a paper by David L. Parnas, who writes:
"Systems that have achieved a certain "elegance" ... have done so by having parts of the system "use" other parts ... The design of the "uses" hierarchy should be one of the major milestones in a design effort. The division of the system into independently callable subprograms has to go parallel with the decision about uses, because they influence each other."
This last (software) concept is very evident in several parts of my hardware design and the "blocks", shown in the block-diagram, are always "combined-components" consisting of a hardware part, and a software part inside the virtual Forth-engine. --- In a complete paper I will attempt to show how these "software concepts" are implemented in "Hardware", and how an excellent flexibility, (a Software defined Instrument) with self-test and self-calibration is being achieved by doing so. I believe that the unprecedented reduction of hardware cost is being achieved by this "combined nature" of the components, because the software part is predominant and basically free.
In conclusion, while the "compactness" of Forth programs has lost its "commercial" advantage in this age of cheap RAM and Flash EEPROM, a basic difference exists between software and hardware. Chuck Moore (Inventor of Forth) at one time said that his ultimate goal was to have software running without any hardware. (Sorry Chuck, not in this physical Universe!) The difference is that Software can be copied for free, but Hardware cannot. Here is where a Forth-Software/Hardware Codesign methodology, with combined Hardware/Software "components", with a predominant Forth-software content, will again provide the "commercial" advantage which Forth had at one time. --- While the best ratio in "compactness", for the amount of hardware needed compared to conventional designs, is only 1 to 5 and not the 1 to 10 of pure Forth programs, this ratio will have significant impact on competitiveness of products on the market.
See the latest paper on this subject. EDN, 3/9/2005
http://www.msmisp.com/futuretest/Unify-Software-Hardware.htm
------------------------------------------Back to Index----------------------------------------