I was chatting with the guys and gals from Kozio the other day, when something they said made my ears stand to attention and set me quivering with excitement. Now, I don’t know if you've ever been involved in a project that involves bringing up a new circuit board and then handing it off to the software developers for them to create, port, and integrate their applications, but if you haven’t, then take it from me that this is a process that is fraught with frustration.
Imagine the scene... You are part of a hardware design team in charge of creating a new circuit board. In addition to off-the shelf components, the system will probably include one or more custom ASIC/SoC devices and FPGAs. Your team has captured a board-level schematic, created the board layout, and handed everything off to manufacturing. You then wait anxiously, twiddling your thumbs and biting your nails, until you eventually receive the first batch of prototype boards. The software developers are clamoring for access to these boards, but before you hand them over you have to make sure that everything works as planned.
A modern circuit board is going to contain all sorts of "stuff." In addition to one or more processors, there will almost certainly be Flash memory and SDRAM. Very often there will be a bunch of sensors, audio devices, cameras, and displays. Also, there may be numerous interfaces, such as Ethernet, I2C, CAN, USB, UARTs, and the list goes on...
As an example, consider the Blaze mobile development platform (MDP) from Texas Instruments. The first in a family of OMAP 4 processor-based development tools, the Blaze is of interest to us here for several reasons, including the fact that it includes a camera, display, audio, and so forth.
The Blaze mobile development platform (MDP).
Suppose your team has created a circuit board similar to that used in the Blaze. No one really wants to get involved in the board verification process, but let's assume that the task has been dumped on you and your colleagues. How are you going to verify the board? Who will be in charge of writing the test software? And, if (when) something fails, how do you know whether it's a problem with the hardware or if it's the software that's at fault?
A very common approach is to boot up the application operating system (OS) -- say Linux or Android. Unfortunately, this OS may be ~100MB in size and have a boot time of 40 to 60 seconds (on a good day). Furthermore, the OS doesn’t come equipped with any functional tests, so you are going to have to create these yourself, which will require a lot of expertise and can be incredibly time-consuming. As part of this process, it will probably be necessary to create some device drivers, which is a complex undertaking in its own right. And nothing is simple when using the application OS to create tests; for example, things like device programming and peeking and poking registers have to be performed indirectly.
In order to address this problem, the folks at Kozio have created a Verification and Test OS (VTOS), which is less than 6MB in size and boots in less than 10 seconds. With VTOS, things like device programming and peeking and poking registers can be performed directly, and simple device drivers can be quickly and easily (relatively speaking) created using a scripting language. Furthermore, VTOS is backed up by a comprehensive library of sophisticated functional tests that cover memory, buses, displays, Ethernet, cameras, and so forth. For example, a memory test suite will be comprised of walking 0’s/1’s, address bus, marching, burst, noise, and simultaneous switching output tests.
Now, I can hear you saying to yourself "OK, this is all very interesting, but what on earth does it have to do with FPGAs?" Well, take a deep breath, settle down, and I shall explain...
Next page >
Tweet This
