What to Look for When Selecting Third-Party IP, Part 5

In my previous column, we discussed the concept of hardware-assisted debuggers. As usual, an interesting discussion ensued, and this provided a good opportunity to share our experiences. Now, let's proceed with our "10 Commandments" and move on to consider Question No. 4 as follows:

No. 4: What's your (the vendor's) experience with IP cores?
For many of us, our hair is not so long as it used to be, and our trousers are not as roomy as they once were, all of which means... we’re getting more experienced. Similarly, I won’t be revealing any secrets if I say that the more experience a third-party IP core vendor has, the better. Only experienced engineers can develop robust and reliable IP core products that are verified and silicon-proven.

Now, some may say, "These words are just slogans; where are the facts?" Well, I think it's fair to say that experience almost certainly equates to having worked on interesting projects. Do you remember our previous discussions in which we considered the pros and cons of designing everything oneself? And if we were to ask ourselves how many projects we've worked on in our lives, what would be the answer?

All of this forms the basis of today’s blog: Experience -- in the context of a third-party IP core developer -- means having an experienced engineering team that has successfully implemented a wide variety of different and demanding projects. In the case of my company, Digital Core Designs (DCD), let me briefly mention a few such projects as follows:

• How about a microcontroller core that can execute instructions in a single clock period and is able to run at over 310MHz in a worst-case 180nm process technology? In this particular project, the technology timing was a real issue for the customer. In order to fulfil the requirements, we had to duplicate some of the processor resources so as to enable the whole system to run at these extremely high (for this process technology) frequencies.
• Many times, the most challenging projects involve developing IP cores for devices with synchronous core functions, when these devices have traditionally been asynchronous (latch-based) or even of an analog nature. A really good example of such an IP core would be the HC11 microcontroller. The 68HC11 originally had on-chip ADCs (analog-to-digital converters) and EEPROM memory, but most FPGA devices don’t offer modules that can be used as replacements for this functionality. Moreover, the users of such systems require full software compatibility with the original devices.

  In order to fulfill such requirements, we replaced the ADC from the original HC11 with an external serial ADC. The resulting D68HC11 IP core has a built-in dedicated ADC controller, which automatically communicates with the external ADC and lets the user/programmer control the entire ADC module exactly as it was done in the original HC11. Similarly, in the case of the EEPROM, the D68HC11 core contains an EEPROM controller, which communicates with an external serial EEPROM and controls it fully in the hardware.

• In some cases, systems with a slow-running clock source can present interesting challenges. On a number of occasions, for example, we have been presented with customer applications that required the microcontroller to run at a very low frequency -- perhaps around 1kHz. The problem was that these customers also wanted to have access to a built-in, real-time, on-chip debugger. As you can imagine, debugging code using a debugger running at 1kHz would provide what could only be described as a traumatic experience.

  The solution was to create a system that employed two separate clocks -- a slow clock to drive the CPU and a fast clock for communication with the host PC. Although this may sound simple, it does involve some complexities, such as the CPU and the hardware-assisted debugger both requiring control over the same internal CPU resources. In this particular case, we had to implement a handshaking mechanism in order to make sure that all the commands of the debugger would be executed.

• Why not couple an 8051 MCU with a DFPMU-DP? A few years ago (2004, to be precise) we designed our DP8051XP core connected to a double-precision coprocessor (DFPMU-DP) in a GPS system. The whole package was cleverly designed to work both with a standard 8051 C compiler and with double-precision numbers (64-bits in size). This particular example proved that an 8-bit CPU embedded with a double-precision coprocessor could be used in a GPS system implemented in a 130nm ASIC process technology.

  The main advantage of this approach was that the system consumed extremely low power and utilized an extremely small amount of area on the silicon die. It's worth mentioning that this project occurred in the electronic equivalent of the Late Middle Ages when GPS devices were nowhere near as popular as they are today.

So, just to summarize this topic, an experienced third-party IP core vendor will always encourage its customers to discuss their specifications. Doing so, the vendor can configure its IP cores to provide the most adapted solution and to deliver reusable IP cores that can be integrated seamlessly into the final design. A knowledgeable and skilled IP core development team will always be able to adapt to new requirements based on their previous experiences.

Related posts:

• What to Look for When Selecting Third-Party IP, Part 1
• What to Look for When Selecting Third-Party IP, Part 2
• What to Look for When Selecting Third-Party IP, Part 3
• What to Look for When Selecting Third-Party IP, Part 4
• IP for FPGAs: Where Have We Been?
• IP for FPGAs: What Are Today's Challenges?
• IP for FPGAs: What Does the Future Hold?
• Is the 8051 MCU Still in the Game?
• Redesigning the Architecture of the 8051