FPGA development: RTL design, timing closure and verification on the real board

Micro Digital Engineering develops FPGA logic for equipment where programmable logic controls processes, handles fast or deterministic timing, processes signals or connects interfaces. The work covers requirements and architecture, RTL design in VHDL or Verilog, constraints and timing closure, simulation, and verification on the real board — together with the board design and the processor firmware around the FPGA.

Discuss the FPGA task

Confidential task? We sign an NDA before you share technical files.

Can you develop FPGA logic for our board and interfaces?

Yes. We start from what the logic must do, the clocks and timing it must meet, the interfaces it connects and how the result will be verified. These requirements are fixed before RTL design starts and become the basis for the simulation and for the tests on the hardware.

Where FPGA is the right choice

Control and timing logic where a microcontroller is not fast or deterministic enough.
Interfaces between components, boards or equipment that need dedicated logic.
Parallel signal processing or data handling close to the hardware.
Migration of logic from an obsolete programmable device to a current one.
Review of an existing FPGA design before production or further development.

What the work covers

Requirements and architecture

Functions, clock domains, resets, interfaces and the division of tasks between the FPGA and any processor are defined before design starts.

RTL design

The logic is written in VHDL or Verilog, structured into modules that can be simulated, reviewed and reused.

Constraints and timing closure

Clocks, I/O timing and clock-domain crossings are constrained, and the design is brought to meet its timing in the target device.

Simulation

Testbenches exercise the agreed functions and corner cases before the logic is programmed into hardware.

Verification on the real board

The programmed logic is brought up and tested on the board it will run on, with measurements made with calibrated equipment and internal signals captured where needed.

Integration with the board and firmware

Pin assignment is agreed with the PCB design, and the interfaces to processor firmware are defined and tested together with embedded firmware.

Design review and migration

Existing FPGA designs are reviewed for structure, timing and robustness; logic from obsolete programmable devices is migrated to current devices from the existing design files or from its documented behaviour.

FPGA, board and firmware in one engineering team

The FPGA logic, the board around it and the processor firmware are developed by the same engineering team. PCB fabrication is performed by specialised manufacturing partners; prototype assembly, bring-up, debugging and verification are carried out in-house, so the logic is tested on real boards from the first bring-up.

What’s included

Requirements and architecture, RTL design, constraints and timing closure, simulation, programming files, bring-up and verification on the hardware, integration with the board and firmware, and documentation. The board itself is schematic and PCB design; processor firmware is embedded firmware and control.

What you receive

Deliverable	Format	How it is checked
Logic requirements	Document: functions, clocks, interfaces, timing	Review and written approval
RTL source and constraints	VHDL or Verilog, constraints and build scripts	Design review, reproducible build
Simulation testbenches and results	Source and report	Agreed cases simulated
Programming files	Files for the target device, with version	Programming and tests on the hardware
Timing report	Report from the implementation tools	Timing met for the agreed constraints
Hardware test report	Document	Results on the real board against the requirements

Discuss the FPGA task

How the project runs

Functions, clocks, interfaces, timing and the verification method are agreed.
The architecture is defined, including the split between FPGA and processor.
The RTL is designed and simulated.
Constraints are set and the design is brought to meet its timing.
The logic is programmed into the prototype and verified on the hardware.
Corrections are made and verified again.
Source, constraints, programming files and reports are handed over.

See how we work.

What to send us

What the logic must do and the equipment it belongs to.
The FPGA device or the board, if already chosen or existing.
Interfaces, clocks and timing requirements.
For a migration or review: the existing design files or documentation of the device’s behaviour.

Common questions

Which FPGA families and tools do you use?

The device and toolchain are chosen for each project from the requirements, component availability and your preferences, and agreed at the start.

Do we receive the source code?

For newly developed logic, the RTL source, constraints and build scripts are part of the deliverables defined in the project agreement.

Can you migrate logic from an obsolete programmable device?

Yes, from the existing design files or, when they are not available, from the documented behaviour of the device, verified against the original. See also obsolete electronics replacement.

Do you use third-party IP cores?

Only when their licences are agreed with you for the product.

Should our design use an FPGA or a microcontroller?

That is decided in the architecture stage from the timing, interface and cost requirements; sometimes the answer is a combination of both.

Related services

Embedded firmware and control — processor firmware around the FPGA.
Schematic and PCB design — the board around the FPGA.
Obsolete electronics replacement — when legacy programmable logic has to be migrated as part of a replacement.
Electronics troubleshooting and design review — independent review of an existing design.

Discuss the FPGA task

Describe the function of the logic, the device and the interfaces involved.

Discuss the FPGA task

Confidential task? We sign an NDA before you share technical files.