top of page
Adiuvo Engineering & Training logo
MicroZed Chronicles icon

MicroZed Chronicles: Lessons From the Lab

  • 13 minutes ago
  • 4 min read

FPGA Horizons London- October 6th and 7th 2026 - get Tickets here.

The $99 Artix UltraScale+ Explorer Board - learn more here


This week I have been helping a couple of clients with FPGA projects that were not going quite as hoped. While I am not going to explain the exact issues they faced, it did remind me of a few different elements of FPGA design and their importance.


Lesson 1: Do not leave FPGA inputs floating


The first project was a custom-designed board that was not functioning as expected. It was a little odd, timing was clean, the testbenches were pretty comprehensive, and they did not demonstrate any issues. Nonetheless, the hardware behaved differently. The board had been designed to connect to several other units as part of a system, but it was experiencing problems when tested on its own on the bench.


Looking into this, I could see that several I/O signals routed to off-board connectors were not pulled to a safe state when the inter-board connectors were disconnected.


This is important because FPGA I/O is based around CMOS technology. With an undriven input, the signal can drift and sit close to the switching threshold, putting the input buffer into its linear region.


The main concern with floating I/O is therefore on the inputs. When the input buffer is in the linear region, we can see increased static current dissipation because both transistors are partially conducting. Coupled noise can also enter the system, potentially causing the input to oscillate or generate noise internally. If those inputs are sampled by the design, the result can be incorrect behaviour.



Understanding this is critical to ensuring that a design does not experience floating inputs. Ideally, this is handled systematically at board level, for example with physical pull-down resistors. In this case, however, the board design was fixed and expensive to change, so the required pull-down functionality could instead be enabled within the FPGA I/O through the constraints.


This still requires analysis of the design to determine the appropriate input conditioning. Once implemented, though, the incorrect behaviour caused by the floating inputs should be eliminated.


The first lesson is a very low-level one: consider every valid use case for the board, including operation with external connections absent, and make sure the constraints leave each input in a defined state.


Lesson 2: Model-based design still needs hardware verification


The second issue was at a much higher level and focused on a model-based design targeting the ZCU106 development board. This project was implementing an image-processing solution. We had completed the basic design and passed it back to the customer to insert their algorithm. Their engineers were algorithm developers rather than FPGA developers, so there were issues when the design moved into hardware - not unexpectedly - and I drove down to give them a hand.


Model-based design in tools such as MATLAB and Simulink is very powerful. However, at the end of the day you still need to think about the hardware implementation. Integrating the model into the overall design is one part of the process; verification is another. This is where co-simulation and hardware-in-the-loop testing come into their own.


In co-simulation, you can connect your chosen logic simulator to the HDL generated from Simulink and simulate it against the algorithm. This lets you compare the behaviour of the RTL directly with the algorithmic model.



With hardware-in-the-loop, we can use a Simulink-supported board to test the design in hardware without worrying about the remaining functionality of the full system. The same test vectors can be applied to the algorithmic model and the hardware implementation, with the results compared directly.


Both approaches are very useful if you are an algorithm developer who is relatively new to FPGA design and want confidence that the model is working as intended, especially when the larger design is a complex mix of logic and embedded software.


It was an interesting week: one client needed help with a very low-level issue, and the next involved a much higher-level verification problem. Both are useful reminders for the wider FPGA community, hence this blog.


FPGA Conference

FPGA Horizons London- October 6th and 7th 2026 - get Tickets here.


FPGA Journal

Read about cutting edge FPGA developments, in the FPGA Horizons Journal or contribute an article.


Workshops and Webinars:

If you enjoyed the blog why not take a look at the free webinars, workshops and training courses we have created over the years. Highlights include:



Boards

Get an Adiuvo development board:

  • Adiuvo Embedded System Development board - Embedded System Development Board

  • Adiuvo Embedded System Tile - Low Risk way to add a FPGA to your design.

  • SpaceWire CODEC - SpaceWire CODEC, digital download, AXIS Interfaces

  • SpaceWire RMAP Initiator - SpaceWire RMAP Initiator,  digital download, AXIS & AXI4 Interfaces

  • SpaceWire RMAP Target - SpaceWire Target, digital download, AXI4 and AXIS Interfaces

  • Other Adiuvo Boards & Projects.


Embedded System Book   

Do you want to know more about designing embedded systems from scratch? Check out our book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design. We designed and manufactured the board at the heart of the book! The schematics and layout are available in Altium here.  Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.


All words in this blog were written by a human.

bottom of page