Ken Smith Jr. is a Senior Engineer with deep expertise in FPGA design and verification, embedded and application software, software-defined radio, and control systems. He earned both his BS and MS in Computer Engineering from the Rochester Institute of Technology (RIT), building a strong technical foundation that supports his multidisciplinary engineering approach. Known for his creativity and ability to simplify complex ideas, Ken excels at bridging technical depth with clear communication. His collaborative mindset and strong communication skills make him an effective problem solver and trusted teammate across diverse engineering environments.
FPGA development tools and processes continue to evolve at a rapid pace. Engineers can now generate RTL from high-level tools, convert algorithms into a HDL automatically, and leverage AI-assisted coding agents to accelerate their development. Tasks that once took days or weeks can now happen in minutes or hours.
But, despite all these advancements, engineers still need to recognize that faster code generation does not automatically create better FPGA designs.
Many of the typical FPGA implementation challenges are still in-play today: RTL that does not synthesize cleanly, designs that behave differently in hardware than they did in simulation, code that cannot be reused across projects, or architectures too tightly coupled to a specific vendor toolchain.
The industry is learning an important lesson: generating HDL is not the same thing as engineering reliable hardware.
That is where HDL craftsmanship becomes critical.
Well-written VHDL, Verilog, and SystemVerilog encapsulate more than functional descriptions of logic. They represent engineering decisions about portability, maintainability, synthesizability, validation, and reuse. Clean RTL design enables teams to integrate IP faster, migrate between FPGA families more easily, reduce hardware costs, and maintain design integrity as systems evolve over time.
After nearly 20 years designing FPGAs across rapid-prototyping, product development, and complex radio systems, I have developed an appreciation for what separates maintainable FPGA platforms from fragile designs that become difficult to evolve. In almost every case, the difference comes back to craftsmanship.
One of the biggest misconceptions I encounter is that HDL development is simply another form of software programming. Engineers sometimes approach RTL the same way they would approach application code, focusing primarily on functionality while assuming synthesis tools will determine the hardware implementation for them.
That mindset creates problems quickly.
HDL is fundamentally different because you are describing physical hardware. Good RTL engineers think about the synthesized result from the beginning. Before writing their first line of code, they are already envisioning registers, combinational paths, state machines, timing relationships, and resource utilization.
Designers who fail to think in hardware terms often create RTL that infers unintended latches, consumes excessive FPGA resources, and/or behaves differently between simulation and physical hardware.
I often see teams spend enormous amounts of time in simulation while rarely checking synthesis results until late in the development process. Simulation matters, but simulation alone is not sufficient. RTL must also be designed from the outset to be hardware-accurate.
A design can appear perfectly functional in simulation while still introducing timing issues, inefficient logic, or unintended hardware structures after synthesis and implementation. To avoid these pitfalls, engineers should synthesize early and often, even when the complete project does not yet exist.
Simple scaffolding around a module or targeting a development board early in the process can reveal valuable information about timing behavior, resource utilization, and synthesis warnings long before integration becomes expensive.
Developing truly portable RTL requires forethought and the discipline to avoid vendor-specific embellishments. FPGA projects evolve over time, and designs that rely too heavily on one vendor’s synthesis behavior can become extremely difficult to migrate later.
Clean coding styles that synthesize consistently across multiple toolchains are essential for long-term maintainability and scalability.
Another major challenge in FPGA development is the lack of reusable RTL.
Compared to software engineering, FPGA teams often reinvent the wheel far too frequently. Many organizations underestimate the value of investing engineering time into reusable IP libraries, parameterized modules, and scalable architectures.
Reusable IP does not happen accidentally. It requires thoughtful abstraction, clean interfaces, defensive coding styles, and parameterization. Generics in VHDL or parameters in Verilog and SystemVerilog allow modules to scale across applications, thereby avoiding being tied to a single implementation.
To be clear, the goal is not infinite flexibility. The goal is practical adaptability that improves reuse without creating unnecessary complexity.
Teams that prioritize reusable RTL can integrate systems faster, reduce engineering duplication, and improve reliability by building on previously validated hardware components.
Many FPGA design problems stem from the same recurring issues:
Documentation also plays a larger role in HDL development than many engineers realize. Signal names become part of how synthesized hardware is debugged, validated, and maintained. Clear naming improves readability and better conveys design intent for everyone who touches the codebase later.
Ideally, the design documentation should focus on higher-level intent: architectural assumptions, interface behavior, timing expectations, and design rationale. Those details become invaluable months or years later when teams revisit designs or integrate them into future products.
AI is fundamentally reshaping FPGA development and I am genuinely excited about the impact that it is having. AI tools are able to accelerate repetitive tasks, help engineers interpret legacy codebases, assist with documentation, and generate initial RTL structures quickly.
But AI still lacks engineering context.
It cannot fully understand why architectural tradeoffs were made, what lessons were learned during earlier iterations, or how a design may need to evolve in future hardware generations.
AI can automate tedious implementation work, thereby freeing engineers to focus on higher-level architecture, validation, integration, optimization, and refinement. If engineers reinvest that saved time into improving portability, synthesizability, documentation, and reuse, then FPGA design quality could improve dramatically.
At the end of the day, HDL craftsmanship is really about long-term thinking. The tools will continue to evolve and improve, but the core design principles remain: think like hardware, synthesize early, avoid unintended inference, design for portability, and build reusable IP that is both simulation-accurate and hardware-accurate.
Those principles are what transform HDL from simple code generation into real engineering craftsmanship.
Fill out the form below and someone from the Re:Build AppliedLogix team will be in touch with you shortly.
