October 22, 1998

• Design reuse and the weather—Jim Lipman, Technical Editor

• It's time to stop fighting, kids—Dan Strassberg, Senior Technical Editor

• Open books: another look—Brian Dipert, Technical Editor

Design reuse and the weather

Jim Lipman, Technical Editor

During the recent Wescon show, I attended an excellent panel on system-on-chip (SOC) trends in the electronics business. All of the panelists agreed that SOC is a major driving force behind technological and economic changes throughout the industry. Not surprisingly, the panelists also agreed that design reuse is a critical part of SOC-based systems. However, a problem exists in SOC design: how to make reusability part of a standard chip-design methodology.

"Design reuse" refers to the development of a piece of a design that you or other designers can use in additional designs. For chip designers, reusability means designing cores or intellectual-property (IP) blocks that someone can use in other chips. Cores can be soft; designed in an HDL or netlist; or hard, actual physical representations of a portion of a chip. Making both soft and hard cores truly reusable requires much more design work than it takes to create a piece of a design that you will use only once.

Chip designers are under tremendous pressure to meet ever-shrinking time-to-market goals. SOC designs, particularly those for consumer applications, may have design cycles as short as six months. If you're a chip designer, your goals are to finish your design on time and have your chip meet perform-ance specifications; design for reusability (DFR) is not high on your priority list as you develop the various chip blocks. This mindset is a key inhibitor to designing reusable chip cores.

Design reuse is like the weather: Chip vendors are doing little to make DFR part of their chip-design procedures. Currently, designers have little or no incentive to make reusability one of their chip-design goals. Making a block reusable means spending extra design time generating additional documentation, verifying that the block meets certain I/O requirements, and doing other time-consuming design functions. Some chip vendors tackle DFR by having a separate design team develop reusable cores. The teams don't worry about designing the cores for specific time-critical chips. These teams design cores to put in an IP library for use on future chip designs. Other companies have a "shadow" design group that works in parallel with the chip-design team. The shadow group modifies the chip- design team's core designs to make them reusable. Unfortunately, both separate reusable core-design and shadow core-design efforts are only expensive workarounds for the problem of chip designers having no incentives for designing reusability into their own chip cores.

It's time for chip companies to tackle the DFR problem head-on. These companies need to change the procedures that their designers use and make DFR part of a standard chip-design methodology. If you successfully make your designs reusable, your manager should reward you, even if it means slightly stretching your chip's design time. The future of SOC-based systems is DFR. This future depends on DFR's being an integral part of SOC design.

You can reach Technical Editor Jim Lipman at fax 1-925-606-1563, or ednlipman@mcimail.com.

It's time to stop fighting, kids

Dan Strassberg, Senior Technical Editor

A fight is going on in the test-and-measurement industry, and it's time to bring it to a halt, not just because it's childish and unseemly, but because it's not accomplishing anything. Moreover, as fights usually do, it's creating fear, uncertainty, and doubt (FUD) among the bemused bystanders. FUD produces only one thing: delays.

The subject of the fight and the FUD is the speed of the IEEE 488 general-purpose instrumentation bus. Interested IEEE members had been scheduled to vote on a proposal to modify the IEEE 488.1 standard to allow communication as fast as 7.5 Mbytes/sec. Currently, the maximum bus speed is 1 Mbyte/sec. (The vote has yet to occur, however, because of squabbles among T&M companies and even international standards agencies.)

What IEEE members would have voted on was a working-group proposal based on a proprietary scheme called HS-488. HS-488 was first suggested by Capital Equipment Corp (www.cec488.com) and was named and commercialized by National Instruments (www.natinst.com). The proposal does not have the support of the world's largest T&M company, however. Hewlett-Packard (www.hp.com) says the working group's proposal is ill-conceived and inadequately tested.

In Europe, where IEEE 488.1 is known as International Electrotechnical Commission standard IEC 625.1, the proposal has also met with resistance. Until recently, IEC members had vowed to keep IEC 625.1 in lock-step with IEEE 488.1, but when the working group made its proposal public, the European community was up in arms. European engineers said, in effect, that the IEEE would make the proposed changes over their dead bodies.

Among the critics' complaints was the suggestion that a higher speed version of the bus was unnecessary and would simply confuse prospective users. In addition, the critics pointed out that achieving higher bus speeds depended on carefully controlling cable lengths. If someone were to replace a cable with a longer one, a system that had previously worked well might no longer work reliably.

Now, DKE, the German Electrotechnical Commission, an organization that some call the German counterpart of the IEEE, is recommending IEC adoption of a different speed-up proposal. This proposal is curious for several reasons. First, only a few months earlier, some of the people advocating it were vocal opponents of any speed-up proposal. Their argument was that so few users took advantage of the existing 1-Mbyte/sec transfer capability that a faster version of the bus was unnecessary. Second, the maximum reliable operating speed of a bus modified in accordance with the DKE proposal also depends on the cable length.

One of the suggestions that the proponents of the DKE proposal are making is that the modified bus not be called IEEE 488 or IEC 625. Yet, DKE is not proposing any changes in the bus connectors or pinouts. So, regardless of what the bus is called, few users will know the difference—especially the less knowledgeable users that proponents of the DKE proposal worry will misuse a faster bus.

Surprisingly absent from either of the proposals is any suggestion of the role that software might play in assuring that a test system can operate reliably at the intended speed. Perhaps I'm missing something, but couldn't a self-test routine assure that the bus was configured to operate reliably? The routine would run whenever you powered up a test system that incorporated a version of the bus meant to operate faster than 1 Mbyte/sec. If vendors of bus controllers and instruments that use such controllers agreed on a routine and furnished a copy with every IEEE 488/IEC 625-compliant product they shipped, wouldn't reliability cease to be an issue?

And wouldn't those who worry about noncompliant implementations (especially of the IEEE's HS-488-based proposal) be reassured if National Instruments agreed to sell the VHDL code for its HS-488 controller chips? The concern is that someone who designs an ASIC that implements an IEEE 488 controller as just one of several functions might inadvertently introduce errors into the controller design. If ASIC designers could buy the controller design from the company that originated it, wouldn't those fears be put to rest?

You can reach Senior Technical Editor Dan Strassberg at 1-617-558-4205, fax 1-617-558-4470, ednstrassberg@cahners.com.

Open books: another look

Brian Dipert, Technical Editor

After years of adopting a generally laissez faire attitude, the US government (specifically, the Justice Department) has decided to keep a closer eye on our "little" electronics industry. The allegations are intriguing: withholding future product information from dependent customers perceived not to be on their best behavior, tying availability or reasonable pricing of one product to a commitment to use another product by the same vendor, adopting business practices designed to lock out competition, and integrating capabilities once sold by other companies into the latest product revision or otherwise offering these capabilities for "free," to name a few.

In all the written words regarding this debate, one topic has barely been mentioned. It concerns timing, specifically when a company reveals information to one partner compared with when it reveals information to any other partner or to another division within the same company. I'll pick on the "big two" first, but you'll soon see that they're not alone in this debate.

Microsoft (www.microsoft.com) has several operating-system divisions, multiple application groups, and even a few hardware sections. How much interaction do you think occurs among OS, application, and hardware personnel, and how long do they interact before Microsoft approaches another vendor whose competing products also run under the Windows platform? How much leadtime does an application group get to solidify its product-line plan and begin development before a third party gets its first "futures" pitch? And how much easier is it for one Microsoft group to fine-tune its product capabilities, availability plans, and development resources in response to real-time information on feature changes and another group's schedule push-outs or pull-ins.

Intel (www.intel.com) isn't immune to examination, either. The company is best known for its PC microprocessors, but it also has a dominant position in core-logic chip sets, networking products, PC motherboards, and systems. Intel recently launched its first graphics chip and is becoming a bigger software player all the time. Although I have no proof it exists, it's not difficult for me to imagine the same sort of interaction among Intel's groups as probably occurs in Redmond. This scenario extends to the embedded-processor and flash-memory divisions as well, whose products turn up in system products.

The upside? All the products end up working well together; they complement each others' capabilities, and, in general, they provide a hard-to-resist bundle. The downside? Each product group deprives itself of alternative perspectives from outside the company at the earliest development stages when key decisions are made, and healthy competition suffers. The lack of dissenting opinions may more quickly advance the platform, but a single-minded vision isn't guaranteed to match an end user's true needs.

"'But," you say, "I don't design PC hardware or software, so this debate doesn't matter to me." I might tell you that you should care if you use a PC in any part of your business or personal life, but I acknowledge your point. However, Intel and Microsoft aren't the only companies that you should keep an eye on. For example, ATI Technologies (www.atitech.ca) makes graphics chips and sells them to board and system manufacturers; it also makes and sells its own graphics boards. Hitachi (www.hitachi.com), Samsung (www.samsung.com), Sandisk (www.sandisk.com), and Toshiba (www.toshiba.com) all sell both flash-memory chips and flash-memory cards based on those chips. And Lucent Technologies (www.lucent.com) and Motorola (www.motorola.com) make a variety of communications equipment, as well as the silicon that goes inside that equipment. See my point?

Does the amount and timing of information transfer depend on your company's size and the impact your business has on a supplier's profit-and-loss statement? I don't care which supplier you choose. Do you think it treats its small "garage-shop" customers who might buy a few hundred parts a year the same way it treats a customer that buys several million units? Do you think both customers get the same data and the same level of support at the same time? Doesn't this favoritism force the start-ups to work unrealistically hard to achieve success and result in the big companies getting bigger while the smaller companies fade away (or get bought up by the big ones)? Is this practice fair?

What's my opinion on this issue and what should be done about it? Frankly, I waffle. My convictions are strongest in the area of equivalent information exchange. If the long-claimed but long-denied rumors that Microsoft's application groups have access to operating-system application-programming interfaces available to any other company are true, well, you'd have to argue persuasively to convince me that such a practice isn't wrong. And if Intel's chip sets can hook into microprocessor features undocumented in the specifications delivered to other core-logic manufacturers (assuming they're even licensed), same story. But as to the timing of this information? I can see both sides of that debate.

Sorry for all the questions and the lack of answers, but I don't have them. This editorial aims to stimulate healthy debate, not to reach a definitive conclusion. What do you think? Drop me a line. I'll share some of the more thought-provoking responses in a future column.

You can reach Technical Editor Brian Dipert at 1-916-454-5242, fax 1-916-454-5101, edndipert@worldnet.att.net.

| EDN Access | Feedback | Table of Contents |