For some applications or functionality various types of high level design can be extremely efficient and allow a much faster exploration of the solution space both with respect to algorithms and logic implementation. Typical high level design could be ‘C’, Open CL, Matlab, Filter generators, etc, from which you could automatically generate RTL code or netlists. Some times this could also be a manual translation to RTL – depending on the source and the complexity. Normally verification of the functionality could be handled using the same tool or language as for design. If so, then the verification of the RTL or netlist is normally a very simple testbench just to verify that the generation/translation/synthesis was successful. Platform tools that allow fast connection of IP to generate for instance a micro controller system is often also considered high level design. it could be very fast and efficient, but It would probably be more correct to call it an IP connection tool.

Exactly the same challenges exist for verification architecture as for design architecture. A good testbench structure is the key to readability, overview, maintainability, extensibility, simplicity and reuse, - which of course all are critical for efficient and good verification. A self checking testbench is mandatory whenever possible, and for that you need a good testbench infrastructure like UVVM Utility Library, which is open source and used world-wide. Logging, alert handling, checkers, expectors, BFMs, etc are obvious functionality inside any testbench. For larger or more complex design modules or FPGA, maybe with multiple simultaneously operating interfaces, a proper test harness architecture is required. Our open source UVVM VVC Framework is the only standardised testbench and verification component system in the VHDL world, and it reduces the development time significantly, while of course also improving the quality. Other important elements of structured verification are transaction based interface handling (BFMs and VVCs), direct testing, constrained random, code coverage, functional coverage, corner case coverage, error injection, scoreboarding, etc.

Designers tend to fall into the same pitfalls time after time, but this could really be avoided if the various design and verification challenges were handled in a structured manner. It is again only a question of structure, architecture, methodology, knowledge and experience. Our courses help designers become more aware of the typical pitfalls and best practice design technique.

The FPGA is an important part of many electronic/embedded systems, but is it important to understand the whole picture in order to make a good product. Splitting the system functionality between a board level micro controller, DSP, FPGA logic, FPGA uCtrl, on and off chip software, on and off chip peripherals, etc. could be critical to achieve your goals, whether that is product cost, development cost, schedule, low power, performance, MTBF or size. Sometimes a large FPGA containing almost the complete system is the best solution, but sometimes splitting the functionality between an FPGA and an external CPU could also be the best solution, - and sometimes not using an FPGA at all may also be your best choice. There are lots of issues to consider here.

Sometimes it is important to find out which technology and which device is required to satisfy the specification requirements, and sometimes which will result in the lowest product or development cost. For some product the cost difference of two neighbouring device sizes could be critical, in which case only the combination of feasibility study, specification adaption, design architecture and device selection will give a good result.

It is normally a very good idea to have a sparring partner to discuss everything from specification features, via design architecture, to advanced solutions on complex challenges. The overhead of such a sparring partner could be anything from 5% to 15%, but this is easily saved when reaching a better solution or avoiding a time consuming or error prone pitfall. Many companies have reviews that are close to useless. It is important that sufficient time is allowed for the reviewers to do a proper job, or otherwise it will be just scratching the surface. The level of ambition could of course vary a lot from one application to another, so this should be agreed upon up front. For FPGAs we typically differentiate between a functional review and a structural review, again typically depending on application and the required quality level.

Quite a few FPGA designs are being made by designers who are not familiar enough with FPGA design. Typically SW, DSP or HW designers, or someone just doing occasional FPGA design – and thus maybe not fully understanding all the aspects of an advanced technology. This could result in strange, “unexplainable” bugs, in error prone products, schedule delays, etc. For these designers it could be extremely useful to have someone to discuss architectures, solutions, code, synthesis, etc. with, and maybe also attend our design, verification or methodology courses.