Posts Tagged ‘engineering’

When companies are small, knowledge gets shared naturally in hallway conversations. If a company is a serial design company having only one design team doing parts sequentially, then knowledge sharing occurs naturally in the project meetings. As companies grow and multiple designs are going on simultaneously by multiple design groups then these communication paths break down.  As companies grow even larger, they develop silos. Most often these form along product line boundaries. This isn’t anything new and it isn’t some hidden issue. A lot of companies make valiant attempts to reduce the problem and some do it with good effect. One of the most common methods is the use of internal conferences. An example might be an engineering conference where different engineers present what they have been working on. Usually the focus is on new design techniques or new products ideas. Sometimes support groups will be brought in to  discuss new tools that are available or how to get problems resolved. A good example might be having IT discuss new customer tracking tools at an internal sales conference. Another useful idea is to have different areas give insight into what is going on in the company. Marketing and sales might present at an engineering conference and explain what they are hearing from the customers. Engineering might present at a sales conference and discuss why some aspect of a product is special and should be highlighted to customers. One often overlooked aspect of these conferences is the need for lots of social interaction. Probably the most important thing that can happen is for engineers in different groups to get to know each other and get comfortable helping each other. Everything from the length of breaks, how snacks are set up, and seating arrangements should be done with this in mind

Another method, seminars, is related to the conference idea.  These can be small, lunch time, seminars on a narrow topic or larger, day long seminars on something of major interest. An example of a major seminar might be a presentation on electrostatic discharge protection and the resources available within the company. A  smaller topic might be equalization used on a specific serial I/O.

A less often use method is having people change departments for periods of time. You read a lot about this when it comes to growing executives. The importance of top talent seeing various aspects of the company are stressed. There might be a stint running operations in a foreign country. For all that this gets stressed in books, the same people seem to ignore it when it comes to people not on track to get to the corner office. Some companies have done this in the past but it seems to have fallen out of favor. At one time several companies had programs where new hires would spend several months in one area and then several months in another. Mostly this involved college new grads. I have no direct experience with this method so I can’t comment on its effectiveness.

More recently, intellectual property (IP) reuse has become a major topic. The idea is that a large corporate database of IP will reduce design times and disperse knowledge throughout the company. Rarely do these efforts work but that’s because people don’t understand the issues involved. In the cases where this has been effectively implemented, the returns have been huge. The list of reasons for failure is large and will be the subject of another post. For this post the main point to understand is that even when this works it is better at sharing work product than it is at sharing internal corporate knowledge.

The final method I want to discuss is something I stumbled upon in my career and have since used to good effect. It involves a central group acting as a pollinator of ideas i.e. a group which, as a natural part of its operation, disperses ideas throughout the company. At a previous employer I had been part of a team putting together a remote design center. This design group was a general corporate resource and, as such, was not aligned with an individual product line. Work was done for whatever group needed the extra resource. While there were some other experienced people at the site, I found myself managing mostly new college graduates. These engineers were very bright but green. There were difficulties jumping into totally new designs but we did well on follow-up designs. We had been doing a lot of memory chip design, which was my specialty at the time, and we had gotten pretty good at it when we were asked to do a PLD. We had never done a PLD before but it was a follow-on part. It was the third member of a product family and the simplest family member. This was a boring design project for the main design team associated with the PLD product line but it was new and interesting to my group. As we started working on the design we found a lot to be excited about. This was our first encounter with high voltage routing and also our first experience with single ended sensing. Previously all of our work had involved differential sensing. I had expected this and the design was playing out as expected until one of the young engineers asked a question. He said he had been looking at the data path so he could learn from the more experienced engineers and he didn’t understand the reasons for the device sizes use.  I took a look. Crud. I didn’t understand why either. I started thinking about how I would size things. The young engineer and I decided to run some simulations. The end result was that my sizing was faster. As you might expect, the next step was to redesign the speed path based on the way a memory designer would do it. The end result was that the part done by my junior team was a full speed grade faster than other members of the product family. In the end the main PLD design team redesigned the other members of the product family with the changes my group had put in. When I looked back on the project I realized what was happening. We were cross pollinating ideas. My team had brought high speed SRAM design techniques to the PLD group. In return, my team had learned about high voltage charge pumps, high voltage routing, single ended sensing and PLD architecture. Knowledge was being transferred across the corporate silos. As time has passed i have seen this happen again and again. Usually it is much less dramatic but the transfer is there just the same. An additional side effect is that the central group transforms from an immature, green group to a flexible group with broad skill sets capable of getting the company into new product areas and better able to take on tasks in new product areas.

I need to explain what the central group mentioned above isn’t. It isn’t the main design group for a product line. It is never meant to be the main design resource of the company. Rather, it is a smaller group of flexible engineers having diverse skills and able to augment the central teams where most needed. It also, over time, becomes a great group for initial design work in new product areas. This allows going into new areas in a rapid fashion without the startup delays that come from having to first hire a new team.

Why worry about all of this? Because execution and excellence matter. In the example above, a product family wound up being a full speed grade faster. That’s huge. In other cases having people mix at design conferences resulted in the sharing of IP and reduced design times. In yet another instance, the insistence by a group that they do things on their own and remain isolated resulted in the reintroduction of a design flaw that had been found and removed in an earlier iteration of a product. The corporate culture must be such that engineers communicate across product line boundaries and that the communication is friendly and supportive rather than competitive.


Earlier I wrote about the need to instill certain core values into new college graduates, NCG’s. It is often during the training review that issues related to core values and expectations show up and where the initial reset occurs. One common issue is the belief that 99 is an A+. IN terns of the NCG, this has been the case for years. Consider a typical college engineering class project. A semiconductor design class might involve the design and physical layout of a small circuit. This must be done within class time constraints. The project will get reviewed to make sure the student understands the basic ideas. Small errors and deviations will be tolerated since time was limited and the student got the main point of the exercise. The business world is different and this is one of several places where expectations must be reset in the mind of the NCG.

To even get to the point of being able to reset expectations, without having prior corporate financial damage done, requires a well designed training program and, in particular, a well chosen training project. The project must be able to be completed in the training timeframe (5 to 7 weeks is a good range) but with some carefully chosen exceptions. In the past I have used an 8 bit register design project with specifications that were mostly easy to meet but with a few challenges. I will reference this project in several future posts since it has proven excellent at bringing out several common NCG issues.

Today’s topic involves meeting all, and I mean ALL, design targets. As the trainee chugs along through his design, most tasks come to completion in a straightforward fashion. He begins to feel that the main point is to show competency with the tools and that is certainly one point of the training exercise. However, there is typically one spec, be it speed or input levels, which is difficult to meet. OK, it isn’t doable for the average NCG. What I will describe next is a surprisingly common occurrence. During the review the NCG explains that he did his best and it’s close to spec. He explains that he met all other targets. The others in the room lower their heads. They know I am about to go on a rant. I start by giving an example of something most NCG’s can understand – buying that first new car. I ask him to imaging getting a new Accord, driving up to a stop sign, and finding out that the car won’t stop. He uses the hand brake to limp back to the dealer where he is surprised to find that the dealer thinks he should be happy. You see, the car is 99.9% perfect. The radio is fine, as are the seats, the engine and the environmental controls. The only issue is a bad seal in the brake system master cylinder. This is an A+ car! I then explain that just like he wouldn’t be happy with that car, our customers won’t be happy with our parts if they are only 99.9% correct. Consider a chip involved in routing data. If only 0.01% of the data gets corrupted, that’s a disaster. The only acceptable grade is 100.

If you have been following my bog (of course you have – right?), you might be thinking I am contradicting myself. Didn’t I say it was about just being good enough? I did and I still do. Read that older post carefully. It mentioned that quality is meeting customer expectations and needs. I wasn’t saying you could fail to meet the requirements. I said great engineering involved deeply understanding what the requirements really are and meeting them in a cost effective manner rather than brute force over engineering.

There are several other topics related to 99 being a failing grade and the training review scenario I have described above. I want to save some of these for later posts so they get their full due. However, I want to touch on the limits of engineering authority. Every now and then, and less than I would like to see, an NCG trainee circumvents my standard way of being able to relate the new car story and my ability to make the point that 99 is a failing grade. He does this in a very simple way. He discusses his inability to meet the target specification with his training supervisor and the supervisor tells him that the present performance is good enough. That is equivalent to getting marketing to change the target datasheet. For the majority of trainees that have not gotten this special dispensation, there is a second lesson, in addition to 99 being a failing grade, that they need to understand. They have exceeded their authority. In the real world, a company will put its name on the parts they design. Organizations will count on them. The company must be confident that changes, even if necessary, will only be done out in the open and with agreement from the corporate parties responsible for setting design targets. Working in partnership with others in the company is an important core value. It is important that we all know what our charters are and what they aren’t. That doesn’t mean being sheep. It does mean bringing issues out into the open and being part of the solution. For most reading this post my comments will sound obvious. To many NCG’s they aren’t.

Cliches exist because they contain truth in an easy to digest form. There’s an old saying among engineers. “Anyone can build a bridge. It takes a good engineer to do it on time and under budget.”  That one holds the essence of why I consider good engineering more difficult to accomplish than good science. My formal training was as a scientist. I have been around scientific research in both the theoretical and experimental areas and I certainly appreciate the difficulties involved. However, it is the imposition of schedule and budget into engineering that makes it even more difficult than good science. Budget doesn’t just apply to the resources involved in the creation of the item but also involves the cost of manufacture. Great engineering means understanding “Just good enough.” Like many topics in this blog the concept of “Just good enough” is much broader and more important than many people think. It is related to the concept of quality. In his book Quality is Free, Philip Crosby defines quality as “conformance to requirements.” Great engineering meets the customer’s needs in the best manner. Best, in most cases, means finding a solution the customer can afford. For this reason designing a mid sized sedan like the Honda Accord is much more difficult than designing something like a Ferrari Italia. The Accord is in a much more competitive space and has tremendous budget constraints. If you want to upgrade the audio system then you have to find cost savings elsewhere. Many thousands of components have characteristics that must be traded off in order to meet the target price-point. The Ferrari design starts by asking “What’s best?” Just for fun, when it comes to the Accord, you get to layer on tougher customer expectations. The Accord isn’t a showpiece. It is a day-to-day working automobile and must perform perfectly for many years with few service needs. The Ferrari is expected to require some pampering. Even several year old Ferraris usually have just a few thousand miles on them. The Accord is a much tougher design challenge.

One engineer I admire is Steve Wozniak. If you look at the Apple II, the computer that made Apple a real company, you find many examples of awesome engineering. Again and again features are included and performance is achieved with elegant rather than brute force design. The result was a great combination of features at a reasonable price for its day. To highlight what I mean by “just good enough” I am going to single out just one of the many elegant design choices in the Apple II; but first I need to set the stage.

The personal computing era was kicked off in 1975 with the January issue of Popular Electronics. The cover article was on the construction of a computer kit called the MITS Altair 8800. With it came the introduction of the S100 bus. The Altair 8800 was a frame style design where cards were added to increase functionality. While many functions such as main memory have moved to the motherboard, we retain this expansion concept today although the S100 bus has mostly moved into history.

The Altair 8800 was copied by many companies and expanded upon. The S100 bus became an industry standard expansion bus. Lots of companies made cards for the S100 bus. Because of this a lot of computers placed only the basics on the motherboard in an effort to control price. There are problems with this approach. Since there was no game controller (joystick, paddle, buttons) functionality included in the Altair, there was no standardized game interface. I once looked at the cost of adding joysticks to an S100 based computer. The card alone was several hundred dollars. The approach involved expensive analog to digital converters (ADCs). The result was that only keyboard based games evolved for the S100 based machines.

During this time, games like Pong and Breakout were popular. It made sense to bring them to personal computers but they required interactive game controllers i.e. paddles or joysticks. A keyboard used as a controller lacked the same smooth interactivity. Using the keyboard for games was a compromise aimed at satisfying the engineers and accountants and not the customers but it was a compromise most computer manufacturers had adopted. Enter Apple and a few others. In 1977 Apple introduced the Apple II. It came with game paddles along with games like Breakout. To accomplish this in a cost effective manner, Wozniak pushed most of the design into software. Since he had designed Breakout in hardware for Atari, this was a big change in mindset. Great engineers adopt what is best as opposed to just reworking what they did in the past. Simplifying hardware and pushing complexity into software would turn out to be a very important trend. Here was that trend at a very early stage. Look at the schematic below.

This is part of the schematic of the Apple II included in the Apple II Reference Manual dated January 1978. What looks like a 553 integrated circuit (H13) is actually a 558. This is a quad version of the venerable 555 timer chip. The 558 is used to generate four paddle, or two joystick, inputs. Each paddle is just a variable resistor. Hooked into the 558, the resistance of the paddle controller determines the oscillation frequency of a simple RC oscillator. A loop in the code keeps reading the oscillator. The microprocessor can only read a 1 or a 0. If the voltage is above a certain level the microprocessor sees a 1. Below that it sees a 0. The Apple II loops while looking at the game paddle input. By looking at the pattern, for example 111000111000111000, it can determine the frequency of oscillation. This is then related to a game paddle position and the screen paddle is moved to the appropriate screen position. The beauty of this is that the paddle controller doesn’t have to be super linear. The paddles just need to be consistent i.e. all paddles need to act the same way. Nonlinearities can be corrected in software. To the user, using visual feedback as he looks at the screen while turning the paddle, this is all “just good enough.” It is also a high quality solution since it meets the user’s expectations and the requirements for playing games like Breakout. Including games and controllers gave the Apple II great consumer appeal and was a big part of its success and with it the success of Apple Computer.

Today we often see companies just iterating on a theme. These are the so-so companies. Great companies sit back, look at the bigger picture and think about possibilities. Rather than layering expensive, iterative solutions on each other, the great companies rethink the approach and create solutions that are cost effective while meeting user requirements. Exceptional companies go beyond this and create solutions to user requirements that the user didn’t know he had. That, however, is a topic for another post.