February 5, 2008

Being on the Level  Comments 

Filed under: Engineering Tools — admin @ 5:34 pm


I recently had a discussion with a development engineer about what makes an ideal development tool.  He responded that he wanted to be able to work at a high level most of the time, but be allowed to dive to lower levels of detail when required.  This highlights the importance of the abstraction level to the effectiveness of a development tool. 


The abstraction levels within a market generally follow the modules or building blocks that are constructed as a market progresses.  As an example in the chip design world the lower levels are transistors, that has been built up to gates, then RTL (register-transfer level) descriptions, then behavioral and higher level descriptions.  Another example is the Seven Layer OSI model that is used throughout the networking industry.  Follow this link to see a description of the OSI model:



Another blog had an interesting post that discusses the progression of abstraction level in software tools. Here is the link: http://softwarejobstofresh.blogspot.com/2007/11/programming-language-to-software.html


To increase their productivity, engineers continually push to work at higher and higher levels of abstraction.  Imagine the difficulty of designing a chip with millions and millions of transistors with tools that work at the transistor level.  It would be a gargantuan task, involving an army of engineers.  This pressure on more productivity for tools has been fueled by the relatively limited supply of engineers and the onward progression of Moore’s Law  (see http://special-sarfunshafi.blogspot.com/2007/11/meeting-man-behind-moores-law.html). 


However, at the higher levels of abstraction certain detailed information is left out, or not readily available.  When something unexpected occurs you often need to dive down a level and look at the more detailed information to determine where the problem is.  It may be in how the abstraction was built (for example, did the compiler create the right code), or it may be a problem that requires the additional detail of a lower level to diagnose.


When a move is made to a new higher abstraction level, the tools typically lag behind.  In software tools when high level languages started being used, the debug tools still worked at the lower level.  The engineer would look at the assembly or machine code generated, and debug using that.  Over time the debug tools improved to where the engineer can debug almost completely at the level of the high level language. 


Using a tool that is at a different level causes situations where the engineer is stuck performing the translation between levels.  This can be tedious, and error prone.  They may even have some additional tools to help with the manual translation such as a hexadecimal calculator.  They may also miss important information because of the shear volume of the data that needs to be scanned at a lower level. 


As an example, in wireless networking there are several lab bench tools that may be used in development depending on the level of the OSI stack that the engineer is working at.  Among the tools and their corresponding level are: protocol analyzer (packet level), software emulator (instruction level), logic analyzer (signal level) and spectrum analyzer (wave level). 


The networking engineer generally wants to work and think at the packet level or above.  Therefore to help the productivity of networking engineers would call for more tools at the packet level and an improved ability to easily move between the different abstraction levels when they need to go lower.


Rick Denker

Packet Plus, Inc.

1 Comment »

  1. [...] Rick’s Wireless Networking Just another WordPress weblog « Being on the Level [...]

    Pingback by Rick’s Wireless Networking » Blog Archive » Tools and the Debug Cycle — April 16, 2008 @ 1:47 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment