INTER: A closer look

Defects of traditional debugging tools for hardware and software systems

The main defect of traditional debugging tools for hardware and software systems is the impossibility to link microprocessor model (hardware model or software model) to models of other system devices (peripherals, for example) as well as to models of external environment behavior (controlled objects, transducers etc). So in every such a case it is necessary to make physical model of the system being designed that increases its cost and time-to-market. Besides microprocessor family development results in putting new peripherals (timers, DAC and ADC, additional functional units) immediately on the microprocessor chip. It implies inadequacy on old debugging tools and new microprocessor.

Another drawback of traditional debugging tools for hardware and software systems is the difficulty of the "search and eliminate errors" process as against the best integrated development environment (IDE) for high level programming languages (Turbo Pascal or Borland C, for example). Moreover there are may be new microprocessors that appear in the designers' schedules and design time constantly shortens. While developers create standard possibilities in debugger tools for new microprocessor (breakpoints, view of memory and registers, execution commands), that microprocessor is already designed and it is need to begin the new debug tools developing. In addition, new processors are more complex, they may contain pipe-line and cache of data and instructions, interruptions,circular and bit-reversed addressing, delayed branches, parallel operation instructions, looping without any overhead, etc.

Use of CAD-systems based on VHDL or Verilog models simulation (or any other HDLs), in hardware & software systems design is unsatisfactory in cost and time for all design is performing on register transfer level.

A new proposed approach essence

We propose powerful declarative-algorithmic metalanguage for processor describing on level "instruction set and assembler" as well as comprehensive IDE for the processor description debugging. Proposed metalanguage allows to describe designed/designing microprocessor system including microprocessor, peripherals and external environment very quickly and easily (from one day to one month depending on difficulty). Then one can develop and investigate software for the designing system simultaneously modifying and researching different variants of architecture.

Processor memory elements (registers, flags, stack, etc.) are described declaratively by special metacommands. Algorithms for most processor instructions are also described declaratively with special metainstructions. The metainstructions' set includes almost all known processor operations: fixed-point, float-point and decimal arithmetic, logical actions and shifts, data moves and converting, compares and branches etc. Processor instruction that has not analog in the metainstruction set may be described as a sequence of metainstructions that is called metafunction.

Processor assembler can be described using Backus notation for nstruction mnemonics definition, definition of instruction groups with the same operand combinations, description of operand syntax and conversion from assembler operands to metaoperands for transfer into metafunctions as parameters of current simulated instruction.

The designed processor system peripherals (on-chip or off-chip) may be described with the same metalanguage, marking this metafunctions as called before or after each processor instruction execution, before or after operand calculation, before or after program execution, or with processor description loading. Moreover, external environment of designed microprocessor system may be described by the same metalanguage using special metainstructions for random number generating and "shadow commands" for probabilistic setting of variables values.

IDE supports work with whole description as well as with separate metafunction that reduce time of the description compilation to one second.

In such a way we have comprehensive IDE with possibility to load processor system and assembler description and than to execute and debug its assembler program.

So processor system development may be supported by the description development and (as result) development of its IDE.

In addition, the IDE's indepedence from concrete processor involve that IDE development is very useful as it is developed for ALL PROCESSORS SIMULTANEOUSLY (for described processors as well as for undescribed processors or even for future processors!).

Efficacy of proposed approach (on our opinion) well illustrated by the following facts.

1. List of processor descriptions that already executed includes:
1. Digital signal processors from Texas Instruments TMS320c30, c40, c50 c80 (Master Processor) and from Analog Devices ADSP-21000 family
2. Transputers T414, T800
3. Popular 8-bit microcontrollers and microprocessors Intel 8051, PICxxx, TMS370xxx, Intel 8080, Z80
4. Popular 16-bit microprocessors: Intel 8086/8087, Intel 8096
5. "Old" processors: PDP-11, IBM 360/370, Apple (6502)
6. Diverse hypothetical processors ( to research power of a meta language for processor description )
• Processor, controlled by flows of data
• Database processor
• Processor for language FORTH
7. Programmed microcalculators îC-61, îC-64
2. IDE has standard multi-window interface (menu, window resizing-removing, mouse support, context-sensitive help, colour tuning, service etc) and comprehensive debug commands set. Moreover, the IDE has non-traditional possibilities, that essentially reduce time for search and correction of errors in the software as well as in the hardware.

Description of non-traditional debug possibilities

The first non-traditional debug possibility is incremental debug technology. Simulation is executed immediately on source code. Editor and debugger use the same window with source code. So compilation of the source code takes place while user types or edits his program. As a result transition from editing to debugging and back may be done without any overhead. Moreover, the IDE supports "hot start" possibility i.e. if user finds error while executing program, he may not only correct it at once, but also resume the program execution from any line of the program (as source program code editing doesn't change values of program variables and processor memory elements, registers, flags etc.). User may restart program execution as well. It is evidently that such possibilities essentially reduce time for error finding and correcting.

Second non-traditional possibility is powerful system for data visualization, including the following facilities:

• enumerated and float-point types defining by user for data view (together with standard data view as binary, octal, decimal, hexadecimal, IEEE-float-point numbers; ASCII or EBCDIC characters);
• assembler operands in Watch-window of the IDE and replacing of assembler expressions by their logical names ( for example, 'Line length' instead 'Table+3[AX]');
• "picture window" - some text file is read into the window and any assembler operand, any program variable or any processor memory elements value may be displayed in any position of the same window. It (with multi-window capability) supports effective developer's orientation on system design, program debugging and external environment.
• "Device window" - on opening this window developer starts powerful editor for structural and functional scheme of designed devices. Pin names of the schemes are automatically connected with description variables.
• storing and reloading of desktops without program execution resets (where desktops define set and place of windows for source code, registers, flags, memory blocks, "picture windows" etc.)

Third non-traditional possibility is "shadow commands" mechanism. "Shadow commands" begin from comment character so it is transparent for all other tools (assemblers, debuggers). At the same time "shadow commands" is commands for the IDE to do the following useful actions:

• to set value into some program variable or memory elements of processor, peripheral or external environment ($S)
• to compare two values of some program variable or memory elements of processor, peripheral or external environment ($T)

"Shadow commands" $S and $T are very convenient for automatic subroutines and program fragments testing. In addition, one may organize automatic error localization by setting $T commands in base points of the program.

• to set probabilisticly value into some program variable or memory elements of processor, peripheral or external environment after each instruction execution or after defined processor cycles. This shadow command maintenance probabilistic simulation of external environment (external interruption, for example);
• to execute metafunction (remember, that any processor instruction is metafunction and developer may define additional metafunction as consequence of metainstructions). This "shadow command" is useful for powerful test preparing in few lines (by "shadow" cycles, shifts, increment etc.).
• to write onto disk memory fragments of processor, peripherals, external environment. This "shadow command" is useful for forming binary tests for physical models. In addition it may be used to generate machine code of debugged assembler program.

Forth non-traditional possibility is the improved technology of microprogram automaton (MPA) synthesis. It is well known that MPA is the architecture which proved to be very convenient and effective in design of the complex devices. There is developed method for MPA synthesis as union of interacted ALU and control unit on algorithm flow diagram, in which microconditions and microoperations are written in register transfer language (RTL). Control unit that gets at synthesis process is the finite state machine, so it can be easily described by hardware description languages (VHDL, Verilog, or any other). Moreover, modern EDA tools maintain full design cycle from description of ALU and control unit on some RTL to the ready ASIC. The main problem in such approach is the absence of convenient tools for debugging the source RTL description. And this problem is solved by our system. We have developed the assembler language of MPA description. This language excel any RTLs and the programs written on it may be easily debugged in IDE. Special program converts then debugged MPA microprogran into correct description of its ALU and control unit on RTL. Such a way time-to-marked may be seriously cut.

Also may be mentioned less important but useful non-traditional possibilities:

• built-in help not only about IDE but also about processor (instruction set, memory elements etc.), and this help is automatically generated on processor description;
• international approach for menu, help and documentation. Two variants - English and Russian already are supplied. But menu and help may be translated into european languages without IDE recompilation .
• modifiable values of some program variables or memory elements of processor,peripheral or external environment immediately in "picture window" and "device window", that allows developer interactively control the state of extern environment and peripherals, processor memory elements and program variables.
• possibility to count in cycles of execution the time of program or program fragments.

Tools application directions

If ASSEMBLER PROGRAMS ARE DEVELOPING in your organization, our tools may be very useful for your. You may ask: "What do I need your tools for if we already have firm debugger (or own debugger, or third firm debugger)? In addition your tool is program simulator that execute programs slower then our hardware & software debugger! And I don't now how your debugger was verified!" We answered in the following way: "Yes, you can not finally debug your hardware & software system without some hardware debugger. Yes, you can debug your hardware & software system without our tools (that is what you did a number of times already). But you can develop your hardware & software system much more quickly (3 and more times we got on real designs)! For that you need to do 80 percents of your work in our tools and only 20 in your hardware tools. And you can do this 80 percents 10 times more quickly. Why?

Because:

1. You can describe your system with peripherals and external environment (if you want to use processor that is absent in list of described processor placed above call us we'll do it during one or two months depending on processor complexity);
2. You'll can analyze processes in your system, find and correct errors much more quickly with our tools than with your tools, in which error correction involves assembling, linking, debugger loading and repeating program execution until line where the error was detected and in which such powerful data visualization facilities are absent;
3. You can automate control of execution correctness using "shadow commands";
4. You feel convenience working in such friendly IDE.
5. You can enhance IDE in accordance with your own need using the powerful tuning potential of IDE.
6. And, finally, you can use the same IDE when you work with different processors.

What about verifying we have done some real projects (for microprocessor Intel 8051) with summary source code more than 10,000 lines. And difference between our tool debugger and real processor was not detected. In addition, we guarantee to correct immediately any error detected in our description.

If the QUESTION OF TRANSITION ONTO NEW PROCESSOR is studied in you organization, then you may order description of this processor and its possible components. It will help you to study processors more quickly and more qualitatively before you accept decision that may cost tens or hundreds of thousands dollars.

If DEBUGGING TOOLS FOR PROCESSORS OR CONTROLLERS ARE BEING DEVELOPED in your organization then more quick way to do it is to call us and give us information about your processor/controller and get from us powerful comprehensive debugger with set of non-traditional possibilities during one or two months. Also it is possible to cooperate our efforts to create hardware & software debugger. We'll make software simulator and interface for hardware debugger and your organization will make hardware scanning and loading/storing processor memory, registers flags etc.

If SOFTWARE IS BEING DEVELOPED IN PARALLEL WITH HARDWARE in your organization then it is worth calling us for description of your hardware and coding/debugging your software while hardware will be designed and manufactured.

If NEW PROCESSOR/CONTROLLER IS BEING DEVELOPED in your organization then there is need to call us for description of this processor/controller which will give you an opportunity to analyze instruction set, addressing mode, memory and registers exploitation, time for execution of separated instruction and furthermore we may do some iterations of processor/controller description and analysis. The same model may be then used for processor/controller software development as well as to produce control and diagnostic tests for hardware.

If DIGITAL SYSTEMS ARE BEING DESIGNED ON CPLD OR FPGA in your organization you may enhance your CAD systems with microprogram automaton synthesis that essentially decreases time for developing a large number of designs.

If CAD-SYSTEMS FOR DIGITAL ELECTRONICS ARE BEING DEVELOPED in your organization then it is possible that we have common interests. We can do work for automatic generation VHDL-descriptions of processor systems, described and debugged with our metalanguage.

If STUDENTS ARE BEING TAUGHT FOR ASSEMBLER PROGRAMMING OR PROCESSOR SYSTEM DEVELOPING then our tools may essentially increase efficiency and quality of the studying process.