Backplane buses speed system implementation... unless you encounter a bug. Then their key advantage - one common interconnection highway - becomes a debugging liability, says Anthony Winter.
How STELA could be used to capture data. In this STEbus data transfer operation - a write cycle is shown - data will be latched by STELA after the falling edge of the data acknowledge signal.
The electronics manufacturing world has quickly latched on to the time-saving benefits to be gained by designing systems around buses such as STE. Thanks to word standardisation, you can have a product idea and be half way to implementing it within just a few days.
But there's a catch. Even though your hardware components are, in theory, fully tested and functional, the designer often faces very complex problems when integrating the final system. The software is typically unproven, nearly every board in the system needs to be set up using dip switches or jumpers to function properly, and there is often a small element of custom hardware, perhaps some special interface. Several different highly complex elements - perhaps even multiple processors - are coming together for the first time, and more often than not, the first thing that happens when you switch on is ... nothing. But where's the problem?
You check the power, waggle the cards, but still the system is dead. With everything connected on a common interconnection highway, here starts a problem that could take anything from a few minutes to a few days to resolve. Since the major factor behind buying ready-made computer modules is to speed project completion, it rather defeats the object of the game.
This scenario might seem unusual, but it is in fact, pretty typical. Arcom's STEbus applications engineering desk for instance. deals with probably 25 queries a week on just these kinds of issues, and this situation led us to define a simple analysis tool which fits the style and budget of board-level system design.
What we felt the system builder needed was a low-cost tool that would track activity on the bus, allowing attention to quickly be focussed on the cause of the problem: a logic analyser seemed the ideal instrument, but they are designed primarily for the board development market, and are generally too powerful, costly and cumbersome to set up for the system integrator.
The solution was to design a stripped-down analyser with functions dedicated to bus lines, giving the systems engineer at-a-glance indication of bus status, with features that allow him to quickly track faults down to specific causes. That's the concept behind the development of STELA, a logic analyser for the widely-used STEbus board system.
Just like any other STEbus board, STELA is a plug-in. It performs four basic functions: monitors, latches, triggers and displays. Almost every STEbus line is monitored and converted to a meaningful display on the front panel. It is - in the parlance of logic analysers - a 'state' analyser rather than a timing analyser; it has no means of indicating that a particular STEbus transfer was marginal, but it will tell you, for example, what address you were trying to access.
You can set up the analyser to trigger on any kind of STEbus access for instance, to any specific memory or i/o address, or range of addresses, or combination of these parameters. You can also trigger on particular STEbus cycles qualified with 'bus-acknowledge', and switches allow you to set the instrument to recognise or ignore any command modifier.
Further useful led displays constantly monitor STEbus' special signal lines, allowing an engineer to quickly recognise that an event is tied to say, a power glitch, but time-out, transfer error, system reset or some activity on the attention request lines.
Data capture can be set for single-shot mode, or continuous trigger on every occurence, with results shown on seven-segment displays. And if this level of information is not adequate to resolve the problem, as it may not be in the development environment, a trigger-output signal is provided to activate a more sophisticated analysis instrument such as a timing analyser.
How useful is such a tool in practice? Here's an example of a typical debugging situation, to give you an idea. In this imaginary case, there are two hardware faults.
Problem: the system starts to work and then halts.
Solution: hit the system reset switch; STELA's reset led will flash in response. The 'bus time-out' led lights, indicating that a transfer did not occur within the maximum time allowed. Set STELA to single-shot acquisition mode, press the arm button and reset the system. As the system halts. STELA now indicates that the timeout occurred at address 00FC10. From here it's a simple matter to discover what board ought to reside at this address, remove it, and find that the fault is merely incorrect jumpering.
But the system still does not work. Bus activity takes place, but once again the system comes to a halt. Re-arming STELA, in case there is some useful information on the bus, you discover that one of the 'attention request' leds is on. In our imaginary system, this line is used for DMA, so you conclude that a link on the c.p.u. connecting bus attention requests to DMA inputs has not been made.
The system now runs, but STELA's usefulness does not stop here. In single-shot acquisition mode, the instrument's displays change whenever there is a bus access - unless STELA has triggered. In continuous acquisition mode, the display is updated whenever a trigger occurs. Our imaginary system is operating some code across STEbus. You can find out where this is, by setting the system for continuous acquisition and all the other switches to 'ignore'.
STELA now triggers on every bus access. Starting with the highest order address switch, push the ignore switch upwards (i.e., to the 'do not ignore' position). Then rotate the address switch until the triggered led flashes again. Repeating this simple action for all the other addresses switches, you can quickly find the exact address being accessed. Similarly, by using the 'command modifier' switches, you can tell what type of bus access is taking place.
Once you've proved that the basic hardware works, you can turn your attention to the software. STELA can also be used to debug i/o-intensive programs written in a high-level language. For example, let's assume that you have a C program that seems to he looping on an incorrect status bit in a register on a STEbus i/o board. If you rewrite the C routine to print the value out for inspection, it will take some while to recompile and link. Instead, you set STELA to trigger on accesses to that i/o address and the display immediately shows you the data byte.
These examples give you an idea of the utility and power of a bus-specific logic analyser. At a cost of £355, this simple instrument could pay for itself in a single debugging session. With the fast-accelerating trend toward using bus-based components for systems design, tools like this will find a ready market and fuel further growth. And as the general complexity of systems grows - as is the case with STE - we expect that the availability of such tools will in some cases influence the bus selection process, being a further factor in the demise of the many unstandardized proprietary buses.