The high cost of low cost development kits

It's all about finding the right investment-versus-results balance for your needs, making informed choices and aiming towards working in smarter ways. And, for the most part, companies - both large and small - do this balancing act pretty well. So in general, we're only talking business costing nuances here. It's about fine tuning the corporate machine so its performance matches all those squiggly Powerpoint graphs we're so fond of. But in the electronics design industry, the rise of programmable devices such as fpgas has unearthed an aberration in this normally sensible behavior. That quirk is in the selection of fpga development hardware and tools, where the usually thorough considerations of cost versus results, long term implications and workflow efficiency often take a holiday to be replaced by short term expediency. The convenient and often impulsive choice is a basic fpga development board, costing perhaps just $49, which is supported by the free development tools from the fpga device vendor. The cost of convenience The fact that a $49 fpga development board is available is undeniably compelling, but nonetheless a curious and risky choice when placed in the framework of professional product design economics. Let's say that product has a development cost of at least $1million, has potential revenue of more than $10m and an engineer working on the project has a salary of $100k – not uncommon figures in today's industry. If you then consider that an extremely critical part of this multi million dollar development is consigned to a system investment of $49, the figures start to look somewhat misbalanced and disturbing. While it appears that the usual checks and balances have failed in this case, it's likely they haven't. They just never happened, because an engineer – possibly you – has opportunistically decided that the $49 board will do the job, given that it has a suitable fpga device, some useful peripherals and a bunch of external connectors. The matching design toolset is a free download, so by making this quick decision you can get cracking with embedded hardware development, and the embedded software guys are one step closer to testing on real hardware. On the surface this might seem a reasonable solution to an immediate need, but in a professional design project where thousands, or even millions, of dollars are at risk, that unchecked decision carries a sting in its tail. Along with the quality limitations you might expect from a $49 piece of development hardware, the real gotcha is that your range of possible design choices has been vastly reduced by the built in constraints of that system. And these limitations are likely to cause costly design compromises and delays. One constraint is the fixed fpga device on the board, which narrows your design path to that device family and vendor. An initial decision of selecting a device that has excess capacity means you won't run out of gates or I/O, but all other capabilities and features of the device must be accurately predicted before serious design has even been started. If you get that choice wrong – the device turns out to be too slow, uses too much power, needs a hard coded processor or dsp, or has been superseded – there's no option but to look for an alternative devices and a new development board. The new board might only cost you another $49, but little of your existing design work can be transferred to the new device. This forces a substantial redesign and a costly delay in the project development. That scenario assumes that you can source a suitable alternative device from the same vendor, but the situation is even worse if the only viable option is an fpga from a different vendor. In this case, the incompatibility of the new device architecture means a total redesign and even more delay, and cost. And all this time, the embedded software engineers are still waiting for your embedded hardware to arrive. Another, perhaps less obvious constraint is the free proprietary toolchain provided by the fpga vendors. While these tools are developed to support the vendor's products and encourage sales, they are understandably devoid of support for competitors' products. So if you change the fpga device supplier to solve your design's problems, you will also need to adapt to a new set of tools and methodology. All these factors add up to mean that what was an expedient, possible impulsive, choice of development hardware has severely compromised the ability to explore design options for that project. You have much less chance of finding an optimal design solution, a change in device type forces a substantial redesign, and changing vendors means learning new tools and methodologies. And above all, the outcome of a design project that potentially involves millions of dollars is placed as risk. A sticky issue In practice, the creeping truth is that the $49 approach has also created a strong motivation for you to stick with that particular vendor and device family to avoid extra work and delays. And the more you use devices and IP from that supplier in subsequent designs, the more your collective design resources become narrowly locked to the vendor. This means that the lack of design choice within a given project, and the compromises it introduces, has virally spread though future designs. Reusing your vendor centric designs in subsequent projects narrows the possibilities from the beginning, so you tend to adapt the design to suit the fpga rather than selecting an fpga that best suits the design. It's also likely that you've sourced IP cores from the device vendor as a convenient kick start to your design. That IP is only useful with a specific range of fpga devices from that particular vendor, so it is effectively stuck to a reduced range of silicon. This 'sticky' IP compounds the issue of limited design choice by stopping you jumping between devices from different vendors, when exploring design options. The short of it is that by taking the expedient path of a low cost development board, in the face of established equipment selection criteria, you have created a restricted 'vendor sticky' fpga design environment. It's one that automatically constrains your design options before you even start, forces you to design in a fixed and predefined way, and devalues your design IP for future projects. The idea that this is a normal or acceptable way of working probably harks back to the early days of implementing fpgas, which at the time were only regarded as a convenient and efficient host for large amounts of supporting glue logic. In this case the decision to use an fpga was probably made late in the design cycle, the functional value of that logic was low, and the need to reuse it minimal. As fpga design evolved through to an SoC approach, where more functionally critical elements such as processors, memory and data processing are implemented in an fpga, the device and the embedded hardware design became fundamentally important elements. The decision of which device to use was critical and came early in the design cycle, and the design IP it hosted represented a significant and valuable design investment. Design choices and design reuse became important for embedded hardware. Today, the role of fpgas has evolved to a point where they have become the core or central platform for a design. This is the next step beyond a SoC approach, where along with hosting high level functions, an fpga acts as the interfacing fabric for the hard and soft elements of that design. A processor, memory or dsp might be implemented as a soft core or as physical hardware, or both, while reprogrammable layers hosted by the fpga stitch it all together. The key differentiating elements of product designs are now defined in both software and programmable hardware. All of this is critically influenced by the fpga capabilities and the IP it hosts, so an approach that was acceptable in the days when fpga based simple glue logic was added as an afterthought is no longer valid. The need for a free range of choices for design exploration is now critical, and the cost implication of not having those choices is huge. The question is, with hundreds of thousands of dollars, or more, at stake can you afford to take the risk of adopting a cheap fpga development board and all it implies? Investing in design freedom What's needed of course is an fpga development system that does not impose those limitations and design constraints. Ideally, this would be a reconfigurable development board that can host any device through a system of plug in fpga daughter boards. The collection of daughter boards could be added to as needed, progressively increasing the range of device choices that are at hand during the design process. The physical hardware aspect of embedded development is then independent of the type of fpga and its vendor. This concept can be extended to hardware peripheral boards, where the development board also offers a plug in system for common peripheral stages, such as lcd screens, I/O interfaces or audio visual signal conditioning. This can also including matching IP, making it fast and easy to move from one peripheral to another, or to include that hardware in the final design. If that system also offers a healthy range of expansion connectors and is built to a level of quality that reflects its importance, as opposed to built down to a low price, the hardware is then in place for an unrestricted approach to design. The next step is exploiting that device freedom by removing the same constraints in the fpga design tools. This can be done using a system of targeted drivers and 'constraint' files that disconnect the embedded hardware design itself from the device it's hosted on. In this way, a new constraint file is simply loaded when the fpga device is changed, the design source is still valid, and little or no redesign is required. The result is an fpga development system that opens the door to a vastly extended range of device and IP possibilities. The ability to change devices with minimal redesign means the final choice can be made much later in the design cycle, when its requirements are fully known. Sticky IP, while locked to certain devices, no longer constrains your current or future design path. Most importantly, the quality and flexibility and longevity of the fpga development system then reflect the importance and investment of the larger product development process. The financial risk of a restricted design choice is eliminated, and embedded developers are free to explore and choose the best possible design options for what is now a crucial part of project development.