Unlike a new tool inserted into a settled stack, Skycore fits around the flow an RF design team already runs. Cadence Virtuoso handles schematics, Spectre handles simulation, and Genus or Design Compiler may handle synthesis, with Xcelium or VCS for RTL simulation and formal tools for properties. That flow took years to establish and is stable enough to pass DRC and LVS without surprises. No team wants a new tool in the middle that forces a different signoff method.
That concern is valid, so Skycore was built without that requirement. This post maps its place in a typical EDA flow, what it replaces, what runs beside it, and where files change hands.
The Gap Skycore Fills
In a typical RF IC flow, an engineer manually writes HDL between the specification and synthesizable RTL. They turn a noise figure requirement, gain specification, and interface description into structural and behavioral Verilog for simulation, synthesis, and eventual place and route. A first RTL draft for a moderately complex block usually takes half a day to two days, and longer with a rich control interface or complex timing requirements.
From a block specification, written in natural language with a structured parameter object, Skycore produces a first RTL draft and starter testbench. The output is a .sv file that drops into your existing simulation flow without changes to simulator configuration, project Makefiles, or synthesis constraints. It is simply another file in the RTL source tree.
Skycore does not perform synthesis, place and route, analog simulation, DRC, LVS, parasitic extraction, or signoff. Those tools remain unchanged. The boundary is the RTL file: Skycore writes it, and downstream tools read it.
Where Teams Insert It
In practice, teams add Skycore at two points:
New block development. For a new RF block, an engineer describes the block to Skycore, reviews and edits the generated RTL, then commits it to the RTL repository. The block follows the usual simulation and review cycle. The engineer refines a draft instead of starting with blank HDL.
Control interface generation. An analog designer may still write the core behavioral model manually, while the digital control interface, including register map, SPI/I2C decoder, and power sequencing logic, is repetitive and suited to generation. Teams can generate that RTL and its testbench with Skycore, then connect the hand-written behavioral model. Skycore covers structural digital logic; the analog engineer covers the behavioral model.
Handoff to Xcelium or VCS
Generated RTL and testbench files use standard SystemVerilog syntax compatible with IEEE 1800-2017. There is no proprietary simulation library, custom preprocessor, or non-standard pragma. Point your simulator to the generated file just as you would for any other module in the project:
# Xcelium example -- generated files drop in alongside existing RTL
xrun \
-sv \
-timescale 1ns/1ps \
rtl/lna_ctrl.sv \
rtl/skycore_gen/lna_ctrl_tb.sv \
-top lna_ctrl_tb \
-access +rwc \
-covfile coverage.ccfSkycore's testbench includes a coverage model derived from the block's specification parameters. If the project already has a coverage database, generated coverage groups take names from the block's module name and register map. They appear as a new section in the report without clashing with groups from other blocks.
Formal Tool Support
Skycore's verification agent generates assertions usable in formal property verification and simulation. Its SVA properties work with Cadence JasperGold and Synopsys VC Formal without edits.
For teams applying formal checks to control interfaces, as is common for SPI and I2C decoders, the sequence is simple: generate assertions with Skycore, point the formal tool to the same module and SVA file, then run the proof pass. A formal pass gives more assurance than simulation for the bounded state space covered by those properties. A failed property produces a counterexample trace that can be read against the register map description supplied to Skycore.
This remains the standard SVA workflow with formal tools. Skycore removes the manual effort of writing the SVA.
Changes to Your Flow
The practical changes are one added block-creation step, run Skycore and obtain an RTL draft, plus adding generated .sv files to source control like hand-written files. The rest stays unchanged.
Teams sometimes worry that generated RTL will differ from their coding style and complicate review. That concern is reasonable. Skycore lets you set module naming, parameter prefixes, port order, and comment density. These settings live in a project configuration file with the other EDA project files. Once aligned with your style, the output reads like part of the same codebase.
For example, if synthesizable modules use a chip_ prefix and verification-only modules use a tb_ prefix, add both to the configuration and the generator applies them consistently. A reviewer sees the expected naming style, plus a top-of-file comment noting that Skycore generated the file from a specified block description revision.
Licensing and Signoff
A common question is whether Skycore changes signoff tool licensing. It does not. Skycore does not run EDA tools; it creates files they consume. The license server does not see Skycore, and Skycore uses no tokens from Cadence or Synopsys seat pools. Downstream tools treat the files like hand-written files.
The engineering signoff process also stays intact. Skycore RTL receives the same code review, simulation signoff, and synthesis timing closure as other project RTL. The requesting engineer reviews and signs off the result. Skycore changes the source of the first draft, not responsibility for its output.
A Practical Integration Test
The lowest-risk evaluation is to take a block already taped out and regenerate its control interface RTL from scratch. Compare it with the hand-written file. Check whether it simulates correctly with the existing testbench, produces the same synthesis result, and covers the same register map.
A passing comparison gives direct evidence that the output meets your flow's quality bar. That supports a go/no-go decision more reliably than any broad claim about Skycore.
Early-access teams have used this method to test integration before applying Skycore to a live project. The block regeneration usually takes a few hours and exposes edge cases in register map conventions or interface patterns before they affect a real tape-out schedule.