From the industry-insider viewpoint, there appear to be two standards vying for supremacy in the wireless connectivity space. One being the emerging 802.11 wireless Ethernet standard, the other being the Bluetooth standard. To the casual observer the two standards appear to be in competition.

However, as figure 1 reveals, the fundamental difference is Bluetooth is designed for the truly portable market while the 802.11 wireless Ethernet standard was designed to be much more of a replacement for existing Ethernet networks. So, in reality, we might find the two technologies satisfying different market spaces. Indeed, some experts predict that the two technologies will eventually form a symbiotic relationship with 802.11 providing the wireless high-speed backbone for multiple local Bluetooth connection points. This is a usage paradigm very similar to current technology with high-speed OC-48-type optical backbones and much slower 10/100 Mbps local device connections.

With the different roles of Bluetooth and 802.11 better defined, the remainder of this article will deal with them largely as a single entity, a wireless connection medium, with examples being pulled from both technologies to highlight some of the challenges facing the designer wishing to implement either one.

Once the decision to include a wireless connection capability into a device has been made, the next logical step is to pick the technology to use. Using the guidelines detailed above, one technology will often suggest itself from the market requirement specification. Armed with a decision on the chosen technology the next logical step for system designers is to understand what they have let themselves in for. This will most likely start with an examination of the specification for the chosen technology. For either Bluetooth or 802.11, simply picking up a copy of the standard may be sufficient to stretch the most battle-hardened designer. Both standards run to hundreds of pages and detail highly complex hardware and software requirements.

The complete solution to the problem will be a combination of hardware and software. A closer look at the hardware portion of the design reveals that there are two major areas of design required in this space. With the high frequencies involved (2.4 GHz for both technologies) it is clear that a significant amount of analog design will be required to implement the actual transmitter in today's technology.

Taking a look at the case of Bluetooth, designers will soon find that the technology is based upon frequency hopping techniques to spread the spectrum of the transmission and avoid the radiation limits imposed by the FCC in this unlicensed band. This further complicates the analog design, requiring the implementation of a precise and rapid switching frequency synthesizer. It becomes more and more obvious that there is a very large and complex piece of analog circuitry to be designed.

The solutions available to the problem are controlled by two main factors, time and skill. The consumer market progresses so rapidly that the next new product must be ready seemingly before the last new product has even hit the store shelves. This means that, more than ever, the design time has decreased to a point where any significant, unknown technology places the delivery date, and hence the whole product, in severe jeopardy. There is also the skill set issue to consider. Traditional product development teams may well have consisted of independent hardware and software development teams. However, the new high-complexity protocols feature a significant blurring of the boundaries between the software and hardware responsibilities and both are now largely dependent on the other. So, a possible solution would be a complete in-house designed hardware/software package. Due to the time crunch issues already raised, and further troubled by NRE costs, this solution will often not be acceptable.

A second option is to modify existing silicon, making it possible to connect external chips to add the functionality. This is the least risky approach to the design problem since (one would hope) the external chipset will have been through some form of standards compliance test. This means that with correct interfacing, integration should be straightforward. All that then remains is to integrate the supplied software stack into the existing software package. The drawback to this type of solution is in the expense of the hardware required to implement it. External chips will inevitably lead to extra cost, both in the purchase of the chipset itself and in the additional board area required to integrate the new hardware. While this cost may be acceptable in a low volume scenario, it is unlikely to work in markets where production runs are measured in the hundreds of millions.

The third option takes the middle road to solve the problem with the use of a third party intellectual property solution.

Given some careful examination of the requirements in the initial stages of the specification, adoption of third-party IP can have a dramatic impact on the system design cycle. However, the designers need to undertake some serious investigation before they select the actual IP for their design. There are a large number of factors in choosing IP, some of which will make one solution stand out in a sea of many options.

Consider the fundamental reasoning behind the IP decision. The designers are looking to add a complex technology to their system without having all of the knowledge required to implement it. Take the example of designers given the task of adding a Bluetooth connectivity solution to an existing (or completely new) product. The reality of the situation is that this is a very large and complex problem with the long and steep learning curve associated with the adoption of a new technology. This alone is in conflict with the shortening design cycle requirement, which accompanies the time-to-market pressure. By choosing to work with IP, designers can push the learning curve onto someone else. The use of fully tested, commercial IP can reduce the need for — and, therefore, time spent on — expensive verification cycles and silicon re-spins. This has the added benefit of allowing designers to focus on their core competencies.

The quality of the IP is also a major factor in the decision process. The IP designers need to feel confident that their chosen IP provider has produced a high quality, portable solution. This places a number of constraints on the IP design. First, the chosen solution needs to be completely tool-and-technology independent. What this really means is that the RTL code must not contain any tool-specific commands, which may works for one tool but not for another. For simplicity, verification suites will also follow the same pattern. A test environment, which requires compiled extensions to the standard simulator, will very likely not work if designers use a different simulator.

However, it is not always realistic to expect that IP will be process-independent. While it is possible for purely digital logic to be technology independent, any analog circuitry is, by definition, highly process-specific. This means it is impossible for analog IP to be truly portable. The reality here is that most providers of analog IP will offer a hard netlist targeted to common process technologies and will offer consulting to port their IP to another technology.

Providing sufficient research is undertaken during the initial stages of IP acquisition, there is also a major risk-mitigation benefit to be gained. It is a simple fact of life that even given the most thorough design guidelines, specification reviews and verification processes, very few designs are completely correct the first time. These days such problems are often reduced by producing FPGA system prototypes, and other verification techniques, but many cycles of design effort may still be expended during this critical phase of the project. The addition of complex, standards-based IP blocks into the design complicates this further, unless they have already undergone rigorous testing by the IP provider. The use of fully tested, commercial IP can reduce the need for — and, therefore, time spent on — expensive verification cycles and silicon re-spins. Users are well advised to use IP suppliers that build and test prototype systems containing their own IP.

If users were to assume that there are never issues with the selected IP, and its integration into the system, then all IP companies are alike. In reality, what separates the front-running IP providers from the rest of the field is post-sale support. Without fast and adequate support, the IP integration process could be long and painful. With current economic conditions, the selection process should also include an assessment of whether the selected IP provider will be around to honor its support contract. This is becoming a more serious problem amongst the smaller design companies as the market slowly converges around a number of leading suppliers, leaving smaller companies struggling. Companies with high annual revenue, possibly including sources other than pure IP sales, are considerably more likely to be around for the duration of a given project.

Having chosen the optimal IP solution for their system, the designers will then move their focus to the actual implementation.

Clearly, designers would like to treat third party IP as a black box solution to a given problem, but, in reality, this is not going to be the case. Some knowledge of the IP will be required for the implementation to progress smoothly. For example, the designer needs to know the required clock frequencies for the core. All of this information needs to be readily available in the design documentation and user guides. Any significant design issues should be noted in the same documentation. For example, if the design requires a special clocking scheme (such as delay lines), or has strict requirements on clock tree insertion, complete descriptions of these requirements, along with, where possible, example scripts, should be provided by the IP supplier.

There are also some risk mitigation issues to be considered. In implementing large analog IP blocks in a predominantly digital system-on-chip (SoC) design, the physical implementation of the device is crucial. Digital design, by its very nature, tends to be noisy in electrical terms. This can cause some serious issues when trying to integrate complex sensitive analog circuitry onto the same piece of silicon.

Consider a Bluetooth radio implementation. The radio operates in the 2.45 GHz ISM band and is expected to transmit between 1 mW and 100 mW of power with a receive sensitivity of -70 dBm. This obviously means that on the receiver side, great care has to be taken to ensure that the signals are not corrupted by high frequency digital noise induced on the power supply, as well as cross coupling from the high-speed digital signal traces, and through the silicon substrate. Some of the risks can be reduced with traditional, well known design practices. However, the first time success rates of mixed-signal chips are much lower than digital-only chips.

One solution to the analog design issue is to utilize external components. During the early stages of technology adoption, this is proving to be a popular choice. Designers are seeing little extra risk from the inclusion of the pure digital portions, but they do see issues with the analog portions. So it makes logical sense to cleanly separate the two portions and implement the radio portions using an external chipset that has already been well proven. This approach does minimize the risks, and does offer the shortest low risk design path, but not the optimal cost solution.

Another solution being adopted is to build in a fallback option. The complete SoC chip is built using on-board radio circuitry, but, crucially, the digital radio interface is also bonded out of the chip. This allows for the use of an external radio in the event there are issues with the on-chip version. This is possibly the safest route, and does allow for an elegant solution, although there are some additional IO pin requirements. This leads to a sub-optimal SoC packaging implementation that results in some additional cost. The flexibility gained from allowing for the external chip is seen as a worthwhile trade-off to make, however, since the pin cost is actually quite low. Crucially, this approach allows the first chip to be used in early devices, using an external radio, while the silicon is re-spun for the single chip implementation in the second generation of products.

With the hardware portion of the design completed, the next phase of system design is to make the hardware and software work together. At this stage, designers will often have a large pool of well-proven application code, which has been developed for previous product versions and often unrelated products with similar functionality. The challenge at the system level is to leverage all of this existing code, and implement, as seamlessly as possible, software for the new connectivity hardware and any other added functionality.

This is another area where the quality and extent of the IP provider's software solution is of paramount importance. Given the complexity of the software required for either 802.11 or Bluetooth, the IP provider should, ideally, be the main source of code. It is unlikely that the designers could just pick up another third party software stack and use it since the SW/HW interaction is so tightly coupled. It is almost guaranteed that a generic stack will require significant work to function with specific hardware, meaning that the designer is essentially restricted with the software provided with the hardware IP.

If the software has been carefully designed, this is not a major issue, but it does, again, highlight the requirement for careful thought on the selection of the IP provider. There are a number of considerations to be made when designing re-usable software, just as there were when designing portable hardware IP. One of the fundamental principles of embedded software is that it must truly be designed to function in an embedded system. This means that compact program footprint and minimal RAM requirements are a paramount consideration. Retrofitting desktop PC code to the embedded world is always a sub-optimal solution.

Operating system requirements are also another problem area for embedded software designers. Again, desktop software engineers can assume a single operating system, whatever that may be, and are free to utilize the resources provided within that OS. Designers of portable software for the embedded market do not have this luxury. Since there is no clear OS preference in the embedded market, a fact that is especially true in the SoC space, designers cannot assume that a particular OS resource will be available. In many cases, engineers must design with any number of different operating systems as possible final environments for their code. This means that careful design is required to make the software OS-agnostic, often requiring sophisticated OS abstraction layers. The largest side effect of this is that the software will never be plug-and-play in its most basic form — a port to the particular OS concerned will always be required unless this has been implemented previously and made available.

There is also some expectation placed on the platform developers' knowledge of the protocol they are implementing. Whilst the IP provider can provide a software stack capable of implementing all of the transport methods defined by the particular protocol, it ultimately remains the developers' responsibility to know how to use them. This is where the system designers will have to rely on the IP provider to assume a trusted advisor role. The developers will often be looking to use the IP provider's knowledge of the field to come up with the most elegant, and commonly-used, solutions to a given communications problem.

It is clear that for platform integration, as with hardware implementation, the IP provider has a significant role to play in the process. The fundamental design of its software will have a major impact on its usability in the end user's system and its area specific knowledge will help developers solve the system-level issues that will arise during product development.

It is a fact of life that growing system complexity, and shrinking time-to-market windows, are pushing designers into new development areas. To meet these challenges, designers have to face the reality that it is becoming impossible for them to implement every aspect of a design themselves. The adoption of third party IP provides a new design methodology, which allows them to deliver a highly complex, reusable design platform in the shortest timeframe possible.

Having made the IP decision, system designers are faced with a large number of vendors that can supply them with the required blocks. The biggest issue is in choosing the right IP provider, as many vendors will have viable and broadly comparable technologies. One parameter often used for provider selection is the classic question “How many times has this design been implemented in silicon.” This is a fine criterion for well-established products, but in the cutting-edge technologies, such as Bluetooth and 802.11, the answer will often be “none.” It takes a significant time from the introduction of a new technology to the actual implementation of devices using IP in deliverable products. A far more relevant requirement is the IP provider's experience. This article demonstrates the need for the partner to be involved throughout the design cycle — from the hardware design stages through the software/hardware integration phase. That is where where a good partner can provide significant added value, lending its knowledge and design expertise to the whole process.

With the selection of the right IP provider, IP adoption need not be a daunting task. There are many large complex designs available today that demonstrate that this design methodology is a sound and successful one.

Stephen Pritchard graduated from the University of Reading in the United Kingdom with an Honors Degree in Electronic Engineering. After 5 years as a designer, he joined Mentor Graphics and moved into the world of IP design. After a brief sojourn as an IP consultant within Mentor Graphics Corp. (www.mentor.com), Pritchard is now a technical marketing engineer solely focused on promoting Mentor Graphics IP to its customer base. He can be reached at stephen_pritchard@mentor.com.

RSS    Save to Del.icio.us  Digg This