FPGA Design

Call: +44 (0)23 8098 8890
E-mail:

Design

We have experience in designing digital systems from the IP block level through to full multi-device architectures. We have worked with a wide range of FPGA products from small Spartan family chips through to large Stratix and Virtex devices. We also have experience with programmable SoC (System on Chip) families such as Xilinx's Zynq, where our combined software and hardware skills have allowed us to efficiently create high performance bespoke solutions.

Verification

Thorough verification is important in all designs, as identifying and correcting bugs as early as possible lowers their impact, reducing the time spent in lab testing and hardware debug. Different designs lend themselves to different forms of verification and we are able to select and deploy appropriate tools and techniques, such as assertion based verification, functional verification and reference model comparison, to suit the project requirements.

Behavioural Modelling

For effective verification, high quality behavioural models are essential. They allow designs to be tested against everything they interface with, from communications links to analogue components.

The following are examples of some of the behavioural models that we have delivered:

  • Efficient event-driven models of complex analogue control systems for digital simulations
  • Memory-efficient RAM models optimised for specific applications
  • Behavioural models of larger IP blocks to allow efficient device and system-level simulations

Automated Testbenches

In order to ensure high-quality designs, test automation is essential. Our approach to verification starts from the bottom up, with thorough testbenches covering all significant sub-blocks and achieving test coverage that just isn't possible with higher level simulations. Not only does this ensure quality, but having a testbench for each block improves reusability and can greatly reduce time spent debugging.

Higher-level and top-level testbenches are also vital for verifying the interfaces, both within the device, and also to the outside world. These testbenches also allow the higher-level functionality of the design to be tested and can confirm that the implemented behaviour matches that of previous system models and specifications. To manage complexity, we not only put intelligence into our testbenches, but also into the scripts that call them. This allows us to do such things as precondition simulations to avoid repeating the simulation of start-up behaviour that is not effected by stimulus differences and significantly reduce verification time.

An accurate software model of the system can also be a huge asset in some cases. Not only does this allow algorithms to be proven and refined before the hardware is developed, but also provides a ready source of test vectors to control and verify the hardware design. Our designers are experienced at creating this style of testbench and, because we also have a software team in-house, we are also able to develop the software models.

Gate-Level and Back Annotated Simulation

Gate-level simulation allows us to identify mismatches in the behaviour of RTL code (pre-synthesis) and gate-level netlists (post-synthesis). Back annotation involves taking predicted timing values after synthesis or place and route for each cell in the design and applying them to a gate-level simulation. Running simulations with accurate timing information gives the most realistic digital simulations possible and provides a final check that the design was correctly constrained during synthesis. They can also identify problems such as interface timing issues when used in conjunction with timing-accurate behavioural models.

System Simulation

ITDev has experience in the simulation of complete systems. This may include using behavioural models for non-FPGA devices (e.g. RAMs) and allows inter FPGA communication and complex system verification even with multiple FPGA vendors. Using system simulations we are able to thoroughly test device and user interfaces not normally covered by simulation.

Synthesis

Getting synthesis right and checking its results is crucial to achieving a product that is right first time and operates reliably over process, voltage and temperature variations. We always script our synthesis flows in order to ensure quality and repeatability. We adopt techniques to vastly improve detection of problems such as unhandled clock boundaries, which are one of the most common causes of failure not covered by simulation.

To ensure that no important warnings slip through the net when reviewing the synthesis reports and transcripts, we employ an in-house software tool. This tool not only makes the task easier and faster, but also generates documentation to describe why any warnings in the transcript are acceptable.

Latest News

Mentor - the missing piece of the puzzle.
Posted 13th November 2017
As a business, we are committed to the future of engineering in the UK. As part of this commitment, we look to engage with local universities at various levels ...more
Southampton Careers Fair
Posted 26th October 2017
Having reviewed our strategic plans we are pleased to have published our vacancies for graduates and summer internships for 2018. As a company, we invest time ...more
Photo of IBC
Posted 13th September 2017
ITDev is excited to announce that its specialist video technology division, Imicast, is presenting Imicast Impulse™ in the Ruby Lounge, between Hall 8 and Hall ...more
Cyclists
Posted 6th July 2017
The fitness, performance and health of athletes has never been of greater interest to sports fans as it is today. With the range of sports statistics currently ...more

Latest Blog Posts

Posted 26th October 2017, By James H
Even in the most expertly designed critical, real time operating systems have some “gotchas”. The most infamous is “priority inversion”. This article outlines ...more
Posted 19th October 2017, By James H
Disabling interrupts can cripple system responsiveness. This article discusses how RTOSes minimise interrupt disabling to give the best possible response time ...more
Starting line
Posted 12th October 2017, By James H
In the embedded world, the use of a real-time operating system (RTOS) is commonplace, and with the advent of the Internet of Things (IoT) they are becoming ...more
A Google self-driving car at the intersection of Junction Ave and North Rengstorff Ave in Mountain View.
Posted 4th October 2017, By James H
Critical systems must meet deadlines reliably. A driverless car must stop in time to avoid collisions, so how does it try to ensure this? This blog is the ...more