The tooling and the operating discipline are deployed into your flow, integrated against your releases, and taught in a live session built from your artifacts. For a small company that is a four-week quick start. A larger company that wants to enable many teams gets a custom plan. Three deployment tiers cover every IP verdict your legal team can return.
Your flow keeps its shape. The plug-ins land stage by stage; the decisions never move.
The decisions stay off the list: limits, waivers, corner acceptance, ship-versus-redesign. They stay with the engineer at every stage, by design.
Hand-built stimulus becomes a generated, parameterised behavioural harness, checked against the simulator.
Larger teams keep their system-validation engineers; the bottleneck moves. Small teams with no modeling staff get covered anyway: the project lead carries system modeling, the AI does the drafting, and the deterministic bench does the deciding.
SystemVerilog is demonstrated in the worked example, a correction block checked against its model over every input code. Verilog-AMS applies and is not yet demonstrated here; it runs on your simulator, in week two.
No design data leaves the building. Your hardware runs the finished deterministic tooling plus a modest local model, 30B-class, context length prioritised over speed. My own workstation runs the deterministic tooling and the test harness today. The local model is chosen from the screening on the Metrics page, where every model so far ran on hosted machines.
A frontier model inside your own cloud account, such as Claude through AWS Bedrock or GCP Vertex, or OpenAI's models through Azure. Inference runs in your account, and data does not go to a vendor API. The hosted measurements on this site used OpenAI's models. Where most mid-size teams land.
For the least sensitive work: generic tasks with nothing foundry-covered or design-identifying in them.
A routing and sanitisation gate classifies foundry-covered and design-sensitive content and keeps it in tier 1; generic tasks flow to tiers 2 and 3.
Tiers 2 and 3 need no capital. At our measured usage a hosted frontier model costs $28 to $230 per engineer a year, where the cheapest on-site fleet we can recommend costs $42,000 up front for a team of up to 25 engineers. The bottom line is on the Metrics page.
No architecture answers whether your foundry NDA permits any of this. Your legal team decides. The ladder's value is an answer for every verdict, including "no to all cloud."
The local tier holds up. Its top failure mode, hallucinated tool functions, is fixed by retrieval over the documentation of the release you have installed, which a bigger model does not have. Local retrieval over PDK docs, design docs and tool manuals ships in every tier. For tool-specific work, the local tier is the more reliable one.
Which open-weight model to use, and what it costs in cards, is measured. Thirteen models were screened on analog and mixed-signal material, with the finding that a sandbox mattered more than the choice of model. The measurements are on the Metrics page.
I hold no Cadence or MATLAB licence, no PDK and no foundry NDA, and I have no access to anyone else's design data. The engagement is built that way on purpose.
The tooling and the operating discipline are mine, and they are portable. The tools and the data are yours, and they stay on your machines. The engagement connects the two inside your environment, against your installed releases.
So anything demonstrated before an engagement runs on my own equipment, either in the worked example you can run yourself or on the simulators I license, and anything needing your commercial tool is generated, checked statically, and run on your side. Those two categories are listed on the worked-example page. There is no third category where you have to take my word for it.
The evidence on this site runs on SIMetrix/SIMPLIS, Python and SystemVerilog, because those are the tools I license or that need no licence. A Cadence shop will want to know what happens to SKILL, OCEAN, Spectre and ADE.
I have automated Cadence flows before, writing SKILL and the OCEAN scripts that drive the simulator, under agreements that keep that work with the client. None of it appears on this site, and that is the rule I would apply to yours.
What does appear is the method, and it is the same whatever the tool. A generator writes the script. A checker validates it without running the tool: every function against a whitelist built from the documentation installed on your machines, every call's argument count against real usage in your own scripts, and a script that fails the check never reaches your simulator. That does not make generated code correct. It makes it not hallucinated, which is the failure that bites. In week two it is built and proven against your installed release and your PDK, on your licence.
Three reasons, and they all point the same way.
The API surface is release-specific. A generator's whitelist has to come from the documentation installed on your machines, not from a model's recollection of a different version. That is why retrieval has to run where your docs live.
The data cannot leave. PDK-adjacent work is foundry-covered. That is a legal fact, not a preference, and your legal team decides where the line sits.
Architecture exploration is where the time goes. A yield-versus-trim-depth sweep is nine simulation campaigns, and each campaign in a real flow is a generated testbench. Making generation cheap and checkable is what turns a week of setup into an afternoon, and that only works next to the tools.
None of it requires a frontier model on your side. It requires a modest local model, grounded by retrieval over documentation already on your disk.
Week one starts at your site. I come to you for a kickoff to meet the team and set priorities, and after that I travel as often as the work needs.
With your legal and IT: data-sensitivity map, tier verdict per content class, an inventory of your flow. Tiers 2 and 3 stood up in your tenancy. Tier 1 designed and specified now, installed when your GPU procurement lands. IT and security review routinely outruns the engagement, and the plan assumes it.
Week one also measures your baseline. Without it, week four has nothing honest to compare against, and neither do you.
Sweep and corner campaign scripting, guarded requirements-database writes, the deck and figure pipeline, the QA render loop, against your flow, your releases, your naming.
Deeper integration on whatever week 2 surfaced, and the training material is written from the artifacts your environment just produced. This is why it cannot be canned.
A live session with your team, taught from your own material, hands on your own tools. The operating discipline, the standing rules, the verification gates, the claim-tagging practice, is written down and stays with you.
Week four is where the checks come from. The failure list on the Evidence page is eight real defects and the eight mechanical checks that now catch them. Writing that kind of check against your own flow is what the training is for.
What worked, what failed, what got built and never used, what the next week changes as a result. Written down, shared with you, and applied immediately.
This is the same discipline the engagement teaches, turned on the engagement itself: no claim survives without evidence, and a failure is treated as data. You get a written record of exactly what was done in your environment and why. It also means each engagement is measurably better run than the last, and you see that record.
Optional pre-work, free, about three to four hours.
Teams get more out of week 1 when they arrive with shared vocabulary. None of this is required and none of it costs anything.
The pre-work leaves out your flow, your tools and your ground truth, because weeks 1 through 4 are for those.
Two ways in, and which one fits depends mostly on the size of the company.
For smaller companies
It is a broad brush across your flow that enables one or two teams, with less documentation to work through than a larger company carries. A fixed fee, because a smaller company needs to know the number before it starts. The tier-2/3 engagement end to end. What you get:
A $5,000 deposit holds a four-week window and comes out of the $30,000 fee. Cancel at least 30 days before the window starts and the deposit is refunded. The open windows from October 2026 to April 2027 are on the Contact page.
For larger companies
A larger company that wants to enable many teams starts with a conversation about the goal of the training. From that goal I develop a custom plan for your teams, priced by the hour. Three reasons for the hourly rate, stated so nobody has to guess at them.
Customised work on the same rate: additional blocks and teams, new benches, deeper integration, standing advisory. Also the overflow path after a pilot.
This offering is new and the first engagement is worth more to me than the margin. If the fixed fee is what stands between us and a start, say so. The first client can take the work by the hour at $175.
Book a scoping conversationA deployment is not a delivery. Tool releases change function signatures and move menus. PDK updates shift model cards and corner definitions. Local models improve every six to twelve months. An API whitelist built from an installed release goes stale the day you upgrade.
Maintained, $1,000 a month. Release tracking against your installed versions. Whitelist and retrieval index rebuilt when your tools or PDK move. Regression tests run against the tooling that was delivered. Bug fixes. Plus access to the recipe library described below, as it is built.
Maintained and extended, $2,500 a month. Everything above, plus two days a month of development against your own priorities: new benches, new generators, extending what exists to blocks the pilot did not cover. Also early access to new recipes, and the ability to ask for a specific one. If the task is general enough to be worth building, yours is the flow it gets built against. It also keeps you current on AI. The reference cards are updated for each new tool version, a model worth considering goes through the tests on the Metrics page when it is released, and you hear from me when something changes what your team should use.
Annual prepayment attracts a discount. Twelve-month minimum on either tier. Larger pieces of work stay on the hourly rate.
Corp-to-corp through PJ Crawley LLC. On site for the kickoff and as often as the work needs, remote in between, with the week-four training delivered on site or live remote as you prefer.
The recipe library is planned and not yet shipping. The first recipes are being built now. Nothing here is available on day one of an engagement, and support pricing does not assume it is. It is described here because it is where the support tiers are going, and you should know what you are buying into.
Each recipe is a short worked example of one automation task, structured so you can adapt it. The first is placing and auto-routing a matched capacitor array: a converter array in the worked example, but the same problem as an R-2R ladder, a current-steering unit-cell array, a thermometer array, or a resistor string. One recipe covers a family, which is the point.
Every recipe has the same five parts, in the same order.
Recipes are recorded on open PDKs and generic structures, never on a client's array, never with client naming or dimensions. The pattern travels between clients; the design never does. That constraint is why the library can be shared at all.
No release cadence is promised. A recipe takes a day or so to build properly, and a promised release rate produces filler. You get the library as it exists and as it grows.
Support buys a maintained and growing library.
Tracking a tool release, rebuilding whitelist logic, working out how to reliably automate a recurring task: each is done once and every client on support gets it. The work compounds across engagements, which is why the monthly number is a fraction of what the same effort would cost billed hourly to one team.
That arrangement only works if the boundary is explicit, so here it is.
Between clients, only generic material flows: method, verification patterns, tool-API handling for a public EDA tool release, and prompt and recipe structures, meaning anything that would be equally true at any company using the same software.
Your designs, data, specifications, results, naming and process details never flow. Anything that identifies your work or your silicon stays inside your engagement and inside your infrastructure. Recipes derived from work on your flow are rebuilt on generic structures before they enter the shared library, and if a pattern cannot be de-identified it does not leave.
This is the same rule the delivered tooling enforces on its own outputs. It would be strange to sell you a discipline and not run the practice on it.
The tooling and every recipe delivered to that point are yours to keep and use, with no further payment and no expiry. Support keeps them current; it does not hold them hostage. Nothing in the deployment phones home, requires a licence check, or stops working when an invoice does.
No cadence is promised, because a promised cadence produces filler. What continues is the weekly post-mortem discipline from the pilot: what changed, what failed, and what it means for you, written down for you to read before any renewal.
Counted from the day access to your tools and databases is granted. Getting that access is usually the slow part, and week one plans for it.
Data reduction, document and figure generation, read-only requirements dumps.
Sweep and corner campaign scripting, deck pipeline, QA render loop.
Version-specific work (GUI paths, function signatures) and anything needing your project's own ground truth.