标签: tools

In 1981, two colleagues and I set up the first computer-aided software engineering company with the goal of improving the workflow for IBM mainframe programmers. The opportunity was huge, as were the potential payoffs for us and our prospective customers. The original idea was to develop a series of programming tools in a staged fashion. The ultimate goal was to offer a workstation that provided a closely integrated editor, syntax checker, compiler, and runtime emulation of the behaviour of the IBM mainframe's COBOL environment, coupled with testing tools and full code analysis. The plan was to develop the editor and syntax checker quickly and put them into the customers' hands for feedback. Enter the venture capitalists, who required changes in the development plans. These investors (who dominated our board) insisted that, rather than offering the editor/syntax checker initially as a minimal functional product, we offer only the fully capable, final visionary product. To get the funding, we caved. We gave up the ability to get early feedback for our approach. This single decision significantly stepped up the risk factor. We increased the amount of software that needed to be completed, delayed customer feedback, increased the company spend rate, and suffered the usual delays in delivering a working product. Furthermore, we had to scale up our training staff, documentation staff, and field applications engineering staff. The company eventually failed for a variety of reasons, but the chief cause was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design of experiments), we delayed validating our product ideas. Every validation delay increases risk—disproportionately. Apart from development delays, the single largest product failure was rooted in the original minimal functional product. We had planned a tightly integrated editor-syntax checker. However, we had chosen a more capable editor than the one IBM COBOL programmers used. We selected a better but wrong editor. If the original development and release plan had been followed, we would have discovered the magnitude of that single error within the first year of our existence. Instead, we learned of the error more than two years into the development. I've seen and experienced this general sequence many times in my career. I've taken away one fundamental guiding principle: Design the product so that early testing of a minimal functional product (also called an essential product) can begin early in the development cycle. This is a risk containment and control strategy. You'll see this technique used in agile development methodology, Alex Osterwalder's Canvas business generation system, and other enlightened business and product planning approaches. I've adopted a personal approach to product development that focuses on risk mitigation. You cannot and should not eliminate risk. But you should want to contain the effects of risk and control how you react to problems as they emerge. That business philosophy, practised for close to 30 years, is codified by Osterwalder in his book Business Model Generation and by Ash Maurya in his Lean Stack system. The bottom line is that you shouldn't fall in love so hard with the product or company idea that you can't (or won't) see the risks, along with the opportunities to mitigate those risks. In my previous column , I posed the following trivia question: "What 1957 movie was used to influence people subliminally to buy popcorn and drink Coca-Cola?" The answer was a 1957 showing of the 1955 movie Picnic . The experiment failed. James Vicary, who designed the experiment, admitted that he lied about the results. Nevertheless, the effectiveness of subliminal advertising is still widely accepted by the public. Here's another trivia question for you. Long-distance telephone calls used to be measured in minutes. How much did the first three minutes of a call between New York and London cost in 1927? Henry Davis Independent Contractor

I was recently looking back at my first trip to Europe in 1992. We spent time in England, the Netherlands, Germany, Denmark, Sweden, Norway, and then Germany again and back to England over a three-week period. We slept on planes, boats, and trains. We managed to pull off this trip before we had cell phones or the Internet. It was also before the euro, so we were constantly exchanging money as we left and entered countries. We also fumbled with some language translation books when trying to communicate with the natives; there were no apps yet or devices to use them. The trip went very well. The only hiccup: We once got on a train going in the wrong direction. With the transportation infrastructure there, it didn't take too long to get back on the right track. The trip got me to thinking about communications and standards. (I know, what an engineering nerd thing to do, right?) Actually, I confess that is a little backward. Thinking about the P1687 proposed IEEE standard brought the European trip to mind. Why is that? The complexity of today's ICs is somewhat analogous to the complexities we encountered when planning and executing the trip. We had to deal with different travel methods, languages, currencies, and cultures in a condensed amount of time. Complex ICs contain many different parts and pieces that have to work together. These can include multiple power levels, on-chip clocks, tons of memories, CPUs, protocols, lots of IP (intellectual property and, in some cases, Internet protocol), sensors, and more.   IJTAG lets all IP speak the same language. I work in the design-for-test area, so I can attest that finding a way to access, integrate, and test the different parts and pieces of an IC is quite a challenge. I believe that IEEE P1687 is a great help and enabler for designers and test engineers to accomplish their tasks. P1687, sometimes call IJTAG (the "I" stands for "internal") works along with the IEEE 1149.1 standard JTAG interface prevalent on most ICs. IJTAG is basically an IP and test procedure reuse methodology. It provides a general-access test mechanism to the embedded IP within all levels of the design hierarchy. Having IJTAG compliant IP and test instruments in a design greatly simplifies complex test procedures. Test procedures or sequences written at the IP interface level can be remapped automatically to the top level of the design, regardless of where the IP sits in the hierarchy. All the IP throughout the design can be integrated into a test network that most efficiently completes the testing of all the pieces. In essence, using IJTAG compliant IP in the design means all the parts will speak the same language. Communication and productivity go up in a way similar to how the euro made it easier to travel among many European countries. For a more detailed explanation of how IJTAG works, I encourage you to view this short video. If you really want to know the details of the IEEE P1687 proposed standard, then see the details. Much as IJTAG can make IP access, control, and test easier, I expect my next visit to Europe to be easier now that we have cell phones, the Internet, apps, and the euro. I think I'll head for the southern countries, and it will be more of a relaxing holiday. It should be a breeze with the tools and standards now available. Bruce Swanson Technical Marketing Engineer Mentor Graphics  

I was pondering my past experiences working on various cost-savings projects. I've worked in a product cost reduction group and a company expense cost reduction group. With that experience in mind, I'm looking at many companies that are going through the motions of cost cutting, saving a few hundred dollars here and there. At the same time, they are spending more money on projects and issues because of the way they tried to eliminate costs or save money. I know that no matter what position we hold, we'll come across a cost cutting activity that just makes no sense. Sometimes to a point where you just drop your jaw and raise your hands and cannot find a single word to express your combination of confusion and frustration—what I call a case of frusfusion . Have you ever been frusfused? . Here is my experience, followed by an example I have seen elsewhere. In the days when I was involved in laying out PC boards (PCBs), I regularly asked our managers to OK the purchase of a couple of Altium Designer licences for our engineering team. We had no layout tools. We still lived in the old days of drawing schematics by pencil. I always joked to management that we should buy some lanterns and candles to place in the lab for when we work late at night. . I would send off about 10 to 15 PCBs per year to have layouts and modifications done. I always spent about $10k or sometimes a bit more per year on having a third party do our layouts. Even though it was only about $6k for a couple of licences, I could not convince management that spending $6k was cheaper than spending perhaps $10k to $15k per year on layout and Gerber file creation. . I could lay out the boards myself just the way I needed them and get them more quickly than sending out. Instead, I sent out the schematic, paid more money, and twiddled my thumbs for a week or two waiting on my boards. And hoping they were laid out correctly. I just never understood the justification on why not to buy. . I put up the fight for about four years. On the fourth year, someone must have opened his eyes—I was allowed to purchase one licence for three people. Sharing the one licence was a struggle, but the biggest struggle was having to take six months to learn the program instead of paying for the two-week training. . Another example is watching engineers passing the opportunity to buy $500 evaluation boards at the front end of a project because they don't want to spend the money and think they have a better way to do the design. But then, when it is two weeks before production is supposed to start, and the design is not working, and issues are arising one after another... Woops! Should have spent $500 nine months earlier instead of delaying production and spending thousands now, just to put a big bandage on a design.. I always say that trying to save $50 will cost you $500. However sometimes spending $500 will save you $10,000. Has anyone else had similar issues on cutting costs that cost you more?   James Bowden Design Engineer  

Hi everyone. My official name is Javier D. Garcia-Lasheras, but you can simply call me Javi. I'm a Spanish electronics hacker who has worked in a wide range of areas in the electronics and computing industries, from microelectronic research to operating systems. Throughout my career, two complementary issues have constantly attracted my attention: How can fundamental science and electronic technology mutually benefit each other, and what can one do to act as a catalyst for this synergy? Once upon a time, a scientist working alone was able to accomplish breakthrough discoveries or develop new technologies with a limited budget. Just think of the way Faraday changed the world by harnessing the power of electricity. Today the complexities associated with fundamental research lead us to use cooperative, multi-disciplinary development teams to cope with the huge budgets imposed by the new challenges we face. A superb example of this is the European Centre for Nuclear Research (CERN), where literally thousands of scientists and engineers from tens of countries work together in massive research facilities. In this environment, the first web server and web pages were developed by Tim Berners-Lee in 1989 for helping scientists share data and documents. This vague but exciting idea, initially intended for a scientific environment, has changed the ways in which we all communicate and live.   SM18, the CERN transnational facility for testing superconducting technologies. Building CERN's Large Hadron Collider (LHC), the world's biggest particle smasher, required the development of a new generation of radiation-hardened electronics, solid state devices, cryogenic superconductors, and big-data processing architectures. The LHC has finally led to the discovery of a candidate for the long-sought Higgs boson, a key piece of the standard model of fundamental particles. Only by pushing state-of-the-art technology to its limits have we been able to test our best theory for describing the quantum world across energies that range from absolute zero to near-Big Bang temperatures. Recently, I had the honour, the privilege, and the pleasure of spending a week at CERN working with a young team of hardware developers. While there, I had the opportunity to discover more about the work they are undertaking. They split their time between developing the electronic building blocks used to perform gargantuan physics experiments and determining the best way to bring this technology to the masses.   Javi at CERN. To give you a quick example, I was able to see a new generation of open EDA tools that rival their commercial counterparts. I also saw a brave new control and timing network protocol that outperforms the accuracy of the best measurement and control systems in the industry by orders of magnitude. But perhaps the most important thing is that all this amazing stuff is being released into the public domain by building a community-based open-hardware ecosystem and developing open licensing setups. To help the EE Times-Asia community become aware of all the opportunities that the big science domain is bringing to the world of electronics, I will be using my future columns to keep you on top of things. In the meantime, do you have any questions about how fundamental research may benefit one's day-to-day job as an electronics or computing engineer? Javier D. Garcia-Lasheras Open Science Activist  

Reading this blog from DesignCon about the special type of screwdriver needed to open the latest iPhone reminded me of a similar incident from my distant past. Many years ago, I was "tasked" with opening up a handheld Nintendo Gameboy . No big deal, I figured , until I looked closely at the Phillips-like tiny screws used. I say "Phillips-like" because the screw-head had the same conical flare, but with three flutes instead of the four of a conventional Philips screw. I assumed this was done to prevent casual hackers from getting into the box. What to do? We could have purchased the required screwdriver by mail (I found out later that it was called a TriWing), but that would take a few days to arrive, and we were impatient (and maybe a little cheap, too). Plus, a "real" engineer doesn't let lack of tools stop him or her, but instead views this as a challenge. We took a standard Philips screwdriver with the appropriate body diameter, and cut the tip off with a hacksaw. Then we used a bench grinder to form the overall "conical" screwdriver-tip shape. Finally, we used a Dremel hand grinder with an abrasive disc to cut away material, leaving the three flutes (wings) we needed; the tool did the job. The whole process took about two hours, and we were quite satisfied and pleased with ourselves. And why shouldn't we have been? We had seen a problem, and improvised a solution: we had done real engineering and tool-making. (Isn't tool-making one of the factors which distinguishes humans from animals? That's a topic for another time.) That final point is what really struck home. Way, way back in the day, engineers and scientists often made their own instruments, tools, jigs, and fixtures. In fact, they also often made the tools needed to make the jigs and fixtures—hard to believe these days, but true. For example, in the recent excellent book "World in the Balance: The Historic Quest for an Absolute System of Measurement" by Robert Crease, there's a long section on the vital role which the diffraction grating has played in advances in physics in general, and precision metrology and standards in particular (also see " The search for ever-better primary standards is a captivating story ").   One thing which struck me was how the leading researchers, often amateurs working on their own, not only ruled their own gratings, but built the ruling engines needed, or enhanced available engines built by other experimenters to reduce their already tiny imperfections. Even earlier, John Harrison, solo maker of the legendary clock of the mid-1700s, not only had to cut his own high-precision gears, but he also had to make the gear-cutting machines (see Dava Sobel's Longitude ). Go to any high-end science, industry, and technology museum, such as Science Museum in London, the Galileo Museum of the History of Science in Florence, or the Collection of Historical Scientific Instruments at Harvard University, and you'll be humbled not only by the instruments themselves, but by the realisation that many were not simply bought by their users, but hand-made by them, often along with the tools and calibration tooling. In addition to tools, engineers often have to build fixtures and jigs for prototype and production test, assessment, and evaluation. When you are pushing the product envelope—whether just slightly or a lot—what you need may not be available or affordable, or is needed right away, so the ability to make that special fixture or jig is just as important to success as a good design and execution of the design. What's the most interesting, challenging, or clever tool, fixture, or jig that you have seen, or made yourself? Was there a simple, clever one that stands out in your recollection?