TL;DR: Faced with an impossible directive—scaling a complex RTL sub-system into a reusable IP for five concurrent ASICs with a team of only eight designers—we hit the limits of SystemVerilog’s parameterization. To survive shifting specs, differing ASIC vendor requirements, and custom memory/DFT rules, we stopped manually designing the IP and instead built a meta-framework using software engineering tools like Perl and Make. This abstraction layer automated the rigid integration tasks, allowing a small hardware team to successfully deliver concurrent 25-to-40-million-gate IPs resulting in fully functional silicon across all product lines.
I was a senior silicon design engineer working on microarchitecture and RTL for a large company that manufactured its own chips across several product lines. Following a massive corporate restructuring, my group was merged with another. I moved from a business unit focused on high-volume, low-cost silicon into a unit dedicated to high-performance products driven by massive, expensive ASICs. The rules of the game changed overnight, and I had to fundamentally relearn the design practices demanded by my new environment.
While working on a highly complex sub-system within one of these massive chips, leadership handed down a staggering directive: this entire sub-system needed to be converted into a highly reusable IP block to serve four to five different ASICs.
These were not simple copy-paste jobs. Each target ASIC had entirely different requirements for performance, channel connectivity, and feature sets. Furthermore, the ASIC projects had overlapping schedules and used different external ASIC vendors. We had to support them concurrently while navigating entirely different vendor rules for memory libraries, Design-for-Test (DFT) handling, and IP integration conventions.
We had a team of exactly eight RTL designers.
The SystemVerilog Ceiling
The math simply did not work. The specifications for the target ASICs were still evolving. There was no conceivable way this small team could brute-force five concurrent versions of a complex IP, make regular deliveries, and offer full support to the verification team using traditional hardware design methods.
We were staring down a catastrophic bottleneck of manual, repetitive toil. If we attempted to manually manage the deterministic grind of renaming signals, swapping memory wrappers, and tweaking vendor-specific protocols across five overlapping branches, the project would collapse under its own weight. While SystemVerilog offers some parameterization, it hits a hard ceiling when you need to seamlessly handle disparate vendor constraints, topological changes, and dynamic protocol generation.
We had to stop designing the IP and start designing the factory that builds the IP.
Applying Software Abstraction to Hardware
We needed a methodology that allowed the team to develop multiple versions of the IP with overlapping features from a single source of truth. Looking across the aisle to software engineering paradigms, we leveraged the text-processing power of Perl, the automation of Makefiles, and customized structural “hooks” to build a highly flexible IP development framework.
We essentially abstracted the hardware integration. The designers continued to write RTL code as they normally would, but they embedded specific hooks that allowed for deep customization. When we needed to spin a release for a specific ASIC, the automated framework took over. The scripts processed the hooks, customized the protocols and interfaces, injected the correct vendor-specific memory libraries, handled the DFT hookups, and generated customized naming conventions for the IP and its internals.
What we created was a meta-workflow. We offloaded the rigid, error-prone integration tasks to the machine.
Scaling Through Automation
Because the automation handled the heavy lifting of code generation and integration, the team could focus their entire bandwidth on high-stakes architectural problem-solving, logic design, and navigating the ambiguous, evolving specifications coming from our internal customers.
The framework proved its worth immediately. We successfully delivered multiple concurrent releases of the sub-system IP, scaling in complexity from 25 to 40 million gates depending on the specific performance levels dictated by the target ASIC. We absorbed relentless specification changes without breaking the development branch, and we supported the verification teams without burning out the designers.
The ultimate proof of this methodology arrived a few months later: successful, working silicon for every single target ASIC that went into production.
Scaling an engineering team is rarely about working harder or adding headcount. When the complexity of a system exceeds human bandwidth, the only path forward is to step back, define the constraints, and build an abstraction layer that lets the machines do the repetitive lifting.
