WP_Term Object
(
    [term_id] => 30
    [name] => Fractal Technologies
    [slug] => fractal-technologies
    [term_group] => 0
    [term_taxonomy_id] => 30
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 36
    [filter] => raw
    [cat_ID] => 30
    [category_count] => 36
    [category_description] => 
    [cat_name] => Fractal Technologies
    [category_nicename] => fractal-technologies
    [category_parent] => 14433
)
            
WP_Term Object
(
    [term_id] => 30
    [name] => Fractal Technologies
    [slug] => fractal-technologies
    [term_group] => 0
    [term_taxonomy_id] => 30
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 36
    [filter] => raw
    [cat_ID] => 30
    [category_count] => 36
    [category_description] => 
    [cat_name] => Fractal Technologies
    [category_nicename] => fractal-technologies
    [category_parent] => 14433
)

CEO Interview: Rene Donkers of Fractal Technologies

CEO Interview: Rene Donkers of Fractal Technologies
by Daniel Nenni on 11-28-2016 at 7:00 am

Fractal is another one of those very successful emerging EDA companies that you don’t read a lot about, except on SemiWiki. Rene Donkers is co-founder and CEO of Fractal Technologies, a company addressing IP quality assurance. This is a niche in the SoC tooling market that deserves some justification. Why not use an IP as-is if it comes from a trusted vendor? And if IP needs to be checked – why would you need yet another tool to do so?


What does Fractal do?
We help our customers make sense of IP they receive before they include it in their design flow. With any component you use to build your SoC, you want to make sure that everything you need is there and is consistent. Regardless of whether it came from an external supplier or an in-house design group, you cannot afford to take quality for granted. Think of trivial issues like missing pins in a Milky Way view or SPICE file. But also of trends in power and timing arcs in the terabytes of .lib files that library IP typically is made of these days. You don’t want to find something’s missing there when you’re running your final design-validation. At that stage debugging is both very hard as well as mission-critical, so catching IP issues before the IP is completely integrated is vital to our customers.

All this doesn’t sound very new, design teams have been running incoming inspection on IP for years?
We have seen all our customers transition from some form of home-grown validation scripts to a dedicated tool like Crossfire. The scripts and maintenance that used to be sufficient a few process generations ago all started to break in several places. The need for including yet another database or format was often the trigger for engaging with Fractal. The reason is that it wasn’t only the parsing and some extra checks: the checks to be run on for example CCS are far from trivial, on top of that the amount of data is huge. And then you get to fix things in a radical cost-cutting regime that leaves no resources left for proprietary tooling development. CAD-groups are simply not coping anymore without bringing in dedicated QA tooling.

There’s another aspect of IP data volume I’d like to point out, which is that you have to engineer your tools from the ground up to cope with it. Within Crossfire we have a distributed data-management framework where the different formats are managed by dedicated servers in the computing infrastructure. Once that is established, checks can be run in parallel, requesting different parts of the data when needed without being concerned with data management. This allows an extensive Crossfire check-set to be passed within a couple of hours.

More data sure, but Moore’s law is also giving us faster computers isn’t it?
Moore’s law is completely not catching up with the increase in IP data. In node-transitions during the last 2 years we have observed a 4X increase of IP data – that’s 4 TB. landing in your ‘Inbox’ to be inspected these days. Following Moore’s law, 2 years at best only doubles the amount of transistors. And that increase is mostly driven by economics, speed increases for next generation process nodes are only there in history books.

IP comes in many flavours, does Crossfire support them all? And what do you check?
In fact we do, as that is exactly how the tool has grown and matured. We started out 10 years ago with standard-cell library qualification, then added IO cells, and then moved into analog and digital Hard IP- think of memories, AD converters and physical interfaces like USB cores. Checking synthesizable IP is of course also included.

Obviously not all checks apply to all IP categories. Basics like presence-checks or terminal-equivalence are pretty universal and provide a good sanity check to start with. If timing models are provided, we make sure all arcs are present so that back-annotation will always work. Timing and power models need extensive trend checks across the 100’s of process corners for which a typical Hard-IP is characterized these days. Netlist related checks are particularly rewarding– like checking bulk connections for the different power domains. Finally we see double patterning manufacturing driving all kinds of layout specific checks that typically affect formats like LEF, layout views and GDS.

It’s important to note that all these checks and different IP formats were made for and requested by our customers. The good news is that they’re not customer exclusive in any way. By supporting and enhancing Crossfire, Fractal accumulates QA demands from the industry and is able to deliver a more complete solution with every release of Crossfire.

Does Crossfire enforce a one-size-fits-all quality standard?
That’s now how it works. it’s always the user that decides which checks to be applied to which IP. This is what we call a ‘standard’: a collection of checks to be applied, for which we have our own format called Transport. In Transport, IP users specify their QA requirements which they then communicate to their IP providers. During designing the IP, the provider already may use Crossfire to make sure the final shipment fulfills all the Transport requirements.

You can compare it to exchanging a DRC-deck between foundry and design-team: these are the rules the design-team needs to stick to if they want their GDS processed properly. For a DRC-deck, designers and foundry can have a conversation on the interpretation of certain rules. Similarly, Transport provides a communication handle between IP-designers and IP-integrators. Because of the easy-to-read descriptions in Transport and the unambiguous implementation of the rules in Crossfire it’s now possible for the first time to discuss and improve QA requirements, so parties can jointly develop improved formulations that better serve their needs. Both sides have a vested interest here, IP integrators want properly qualified IP, but overly rigorous checks do not help their suppliers in providing efficient IP releases in time.

Getting back to those design-teams that have internal qualification tools, how do you get them on board?
First of all by pointing out that we embrace and not compete with internal solutions. These internal checks have been developed to serve the specific needs of the design-flow and the application area the customer focuses on. What we’re proposing is to integrate those dedicated checks into the Crossfire framework. Not by re-writing but by simply calling the existing code and making sure the checks show up in our index and that errors can be debugged from within Crossfire. This way the experts working on these checks can dedicate themselves to adding corporate-specific value, rather than having also to spend time on infrastructure-related subjects like format-parsing, visualization and parallelized data access – all areas where Crossfire excels, but which can take 70% or more of your time. So by working with Crossfire, the experts become a lot more productive.

This opportunity to focus on adding unique value is the way to engage customers, knowing that they will also benefit from a “QA-subscription” as Crossfire is continuously extended with new QA requirements from the entire industry.

That implies Fractal already has an industry-wide adoption, who are your customers?
You find our customers in all categories, we have system companies but also foundries, IDMs, independent IP design houses and fabless companies. All use Crossfire either during their design-flow, to have an end-of-line check before IP shipment or as an incoming inspection tool. I can’t disclose names, but half of the top-20 semiconductor companies already use Crossfire, and we expect the rest to come on board in the near future.

We support them preferably through local AE’s that speak their language and can be on-site quickly to deal with any issues or train new users.

What do you see as the next challenges for Fractal?

Managing growth is of-course key. We organically grow the engineering and AE teams so we get the right, qualified people on board and can make a proper investment in training them in our way of working. At the same time without compromising on the timing and quality our deliverables.

For our customers Fractal’s position as an independent QA tool provider is of prime importance. After all, who would buy a QA tool from either an IP provider or an EDA company? Absolutely no-one: in such a scenario a lack of test-coverage would only be the least suspicion. In essence, Crossfire would no longer have the authority it now has as an independent QA certification tool. The adoption of Crossfire and the Transport formalism by the industry is allowing us to continue with this strategy.

Also Read:

CEO Interview: Albert Li of Platform DA

CEO Interview: Mike Wishart of efabless

CEO Interview: Chouki Aktouf of Defacto Technologies

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.