( ESNUG 530 Item 2 ) -------------------------------------------- [07/26/13]
Subject: First user look at Defacto's RTL & gate editing, coding, ECO tool
> NEW! -- DeFacTo Signoff ATPG has some really curious test stuff where
> it can do ATPG on your Verilog RTL *before* you do any synthesis. I'm
> not exactly sure how it works. (booth 409) Ask for Chouki Aktouf.
>
> - from http://www.deepchip.com/gadfly/gad053013.html
From: [ Asterix the Gaul ]
Hi, John,
Please keep me and my company anonymous.
I saw that you were curious about Defacto in your DAC Cheesy Must See List
this year.
We bought Defacto STAR RTL Platform about 3 years ago after a 3 month eval,
and have been using it ever since.
STAR RTL is like a "designer's toolbox", with a lot of different utilities
to help designers create their RTL and connect IP, trace, manipulate, and
modify the RTL -- it even helps with verification.
Before STAR our designers did all this manually using text editors (emac/vi)
and internal scripts.
I've organized my group so that we do our maximum design work at the RTL
level -- to catch problems early -- and it helps to have this additional
automation for RTL code development.
The STAR "toolbox" has an API, where we can use TcL or Perl to create our
own utilities. Plus we have some of Defacto's TcL and non-TcL add-ons.
---- ---- ---- ---- ---- ---- ----
STAR'S CORE FUNCTIONALITY: RTL & GATE-LEVEL EDITING & CODE GENERATION
1. SoC/IP Integration and Generation of new Verilog/VHDL RTL code
STAR automatically creates the necessary connections and generates the RTL
to instantiate the different IPs. Its inputs are:
- RTL or gate-level netlists
- libraries
- a few lines of code for the IP around which we want to build
connections
When our IP changes from time to time, STAR automatically creates the right
hooks to connect them -- much of our IP has wrappers around them plus a set
of standard ports that are always there. This helps with integration when
our IP changes -- keeping things relatively transparent to our designers.
We often integrate 100's IP blocks in our designs. It would take us days to
create each RTL wrapper by hand and verify them. Our problem was not only
the time, but all the dependencies involved -- and the impact of project
delays due to the manual errors. STAR not only automatically creates the
code for our wrappers, it also flags instantly if any of the modifications
we are trying to make are not legal; such as trying to connect an output to
an output, or to connect busses of different lengths, etc...
For RTL language support we use Verilog, System Verilog, and VHDL. Defacto
supports all of them and we've had no issues so far. Defacto claims
mixed-language support, but we haven't needed it nor tried it out.
The kind of IP for which we use STAR to generate connections:
- Design IP; both 3rd party and internal.
- Memory; STAR automatically deals with various memories'
sizes, shapes, and power.
- DFT logic: STAR helps us automatically instantiate and
connects the DFT IPs -- such as JTAG tap controllers, etc.
Fig 1. Defacto STAR connectivity wrapper code automatically generated
(CLICK ON PIC TO ENLARGE IMAGE.)
Defacto has its own internal basic checks to ensure that the RTL is correct
and synthesizable. Once it's complete, we simulate our new RTL netlist in
Cadence NC-Verilog, or VCS or ModelSim. We also run formal verification
(Conformal LEC or Formality) when using STAR to generate our DFT-related
connections to make sure that the functionality of our chip has not been
altered by the addition of DFT logic.
We can use the Defacto API to build additional rules ourselves, or we can
use Defacto's add-on structural verification application, which I discuss
later.
2. Design Exploration
"Design exploration" is STAR's basic bread and butter -- we use it explore
our RTL in the same way that Synopsys DC explores the gate-level netlist.
- We can run basic query commands to find ports and instances; the
search is really fast -- it usually takes just one second or so.
- STAR also supports advanced full design hierarchy queries such
as fanins, fanouts, and paths.
We use this functionality all the time -- it's extremely helpful to be able
to explore our RTL, and access, and query anything.
3. User-Defined Design Rule Checks (DRC)
We use Synopsys MVRC, and Cadence CLP low power tools for RTL and gate-level
power checks. But we are usually ahead of the game, so we also do checks
that EDA vendors don't support yet.
1. We use STAR to trace and identify the design elements we
are interested in.
2. We write TcL and Perl to write custom design rule checks
that we want to apply to those elements.
Examples:
- Low Power rules. For low power verification, we run DRCs for
power switch connectivity. So far, we've always found issues
with them.
- DFT rules. Use STAR to write custom rules for DFT; but for
advanced DFT rules checks we use Defacto's Sign-off DFT rule
checker.
- Memory connection checks -- to guarantee that all memories
are properly connected -- especially for all the low power
and DFT related ports.
4. Pin-to-Pin Tracing
We use STAR extensively to check structural connections on clocks and for
I/O muxing logic without doing lengthy simulations. The main purpose is
to guarantee that 2 nodes are structurally connected after applying a set
of constraints.
Examples:
- The output of a specific block is directly connected to a
specific chip I/O in a particular pin muxing mode.
- A specific clock propagates from a PLL to the input of
a particular block in a defined mode, like DFT.
These pin-to-pin tracing checks (under constraints) have saved us a lot of
time and effort -- especially with its GUI that can pinpoint the exact
location of the blockage, if any. We use Defacto checks as a regression
to make sure our subsequent RTL meets our connectivity intent.
---- ---- ---- ---- ---- ---- ----
STAR'S ADD-ON APPS
The Defacto STAR Platform is expandable by users in the same way people add
functionalities to their iPhones. You add "Modules" or "Apps". Here's a
few that we're currently using:
1. STAR-ECO -- a Full ECO Tool
STAR has automated ECO capabilities, which mostly do connectivity changes
like adding and removing connections, rather than ECOs to the IP itself.
STAR's ECO works at both the RTL and gate-level, but we mostly use it for
gate-level ECOs. If we want to add a set of gates, such as inverters, in a
specific way, we use STAR to search for a particular type of net and add an
inverter. It only takes us only one (or a few) command lines to do an ECO
this way versus doing it by hand -- and having to manually traverse the
hierarchy to add a new netlist.
We also use STAR to do more complex ECOs automatically at gate-level:
- Changing a buffer to an inverter
- Changing a set of buffers to a set of inverters
- Changing an AND gate to a NOR gate
- Stitching in scan chains on the fly; it identifies the
flop, inserts the scan chains, and connects the clocks.
Many of our functional ECOs go through synthesis and LEC. Sometimes we use
STAR to automatically create the gate-level changes we need without needing
to run synthesis or do formal logical equivalency checking.
For example, when we do low power tweaks such as: power-switch connections,
ISO cell connections, level shifter connections and low power connections to
various analog IP and/or memories -- a formal tool won't see the change
because it doesn't affect functionality per say. Synopsys Design Compiler
doesn't know about power-switches nor sees them. Same thing for DFT ECOs.
The changes don't affect the functionality of the device, but they affect
the testability and we can't use the formal methods to implement the ECO; so
instead we use STAR.
Our only alternative to STAR would be to do the ECOs by hand. If we have
node that is 5 hierarchy levels deep, connecting all the ports by hand is
a pain.
- ECO By hand: we must modify Module A, Module C, etc., and then
change the interface, add the ports.
- ECO with STAR: takes only one line.
STAR is fast. To give you an idea of the average times savings we see for
our typical ECOs:
Task Time
---------- ----------
Manual ECO 2-3 days
STAR ECO 2-3 hours
2. STAR-BUILDER -- Verilog/VHDL RTL Structural Verification
We have yet to simulate our RTL without finding at least some problems. We
save a lot of time by using STAR to verify that the IP structure is properly
connected without having to simulating the entire netlist.
Below are the steps involved:
1. Designer inputs the RTL netlist, and the IP structure spec to
be verified from a connectivity point of view into STAR.
- Example IP structures: clocks, low power, padring
2. STAR automatically identifies the start and end points for
that structure
3. Our designer specifies the constraints and inputs them to STAR.
- E.g. we might have a constraint on the structure's input or
output, such as a configuration register set to a specific
value for proper propagation.
4. STAR verifies the structure's connectivity by statically
propagating the constraints through the design hierarchy and
structures.
- E.g. to see if the 1/0 constraints are blocked somewhere,
such as in power mode or test mode.
5. STAR has a special GUI and verification report to show the user
which paths were blocked and why the block occurred.
- E.g. missing settings for a MUX, where we need to switch
a signal to have it pass.
To debug without STAR, we would need to write exhaustive tests; sometimes it
requires 1000's of exhaustive simulations verifications.
Task Time
----------- -----------
STAR for structural verification couple of days
Simulation for structural verification weeks
Fig 2. STAR GUI for structural verification of a clock. The red line
pinpoints the piece of logic with a blocked path. The 0's and
1's on the bottom graph show what is missing.
(CLICK ON PIC TO ENLARGE IMAGE.)
3. STAR-CK -- Clock Testbench Generation
STAR can generate testbenches for deeper analysis/simulation beyond just
connectivity. For example, STAR can create a testbench to verify that your
clocks are running at the right speed. We use this mainly to verify the
clocks in the various DFT modes since we have 100's of clocks to verify.
Fig 3. STAR generated testbench can be analyzed before simulation.
(CLICK ON PIC TO ENLARGE IMAGE.)
The beauty with this is that we can do this verification early on and in
RTL without waiting until we go through the DFT insertion process to run
lengthy simulations usually in gates.
4. STAR-PADRING -- Padring Generation
The latest add-on to STAR is padring generation, which has always been a
complex problem for us and things are becoming even more complicated with
the introduction of power domain in some I/O segments. With STAR-Padring
we can generate the complete padring of a complex chip in minutes and it's
always correct by construction.
Fig 4. STAR's GUI for padring RTL code generation. Can drag and
drop pads to rearrange, with automatic design checks to
make sure its legal. (CLICK ON PIC TO ENLARGE IMAGE.)
STAR supports a variety of pads, it automatically generate the corresponding
UPF based on the various power segments, and it has a GUI that helps the
designer to properly place the pads based on the chip layout. After we test
it some more, we hope to use it extensively on our future devices.
---- ---- ---- ---- ---- ---- ----
WHAT I WOULD CHANGE
A couple of improvements that I would like to see Defacto STAR add:
1. I've asked Defacto to integrate their Sign-off RTL DFT rule
checker into STAR. Once I am already in STAR, it would be nice
to be able to just do 3-4 things and be done. I don't see why
they are not integrated. They should be.
2. One feature that Defacto doesn't support yet is the concept of
'attributes', i.e. "Post-its for designers". Then I could post
the attribute/pointer/key word with the IP, so that later I
could search for that attribute, and link to that IP.
3. Keep adding more apps to the STAR app library.
We used to have a lot of internal scripts, which we have now replaced with
STAR and these add-on utilities. In addition to saving us development time,
Defacto makes our design process more secure if an employee leaves or their
job changes -- we no longer have a big hole we can't recover from. (This
actually happened to us.) When we hired a new engineer to fill the empty
job, a quick training on STAR had the new guy coding in the same way
everyone else on the team was coding. Our company culture is to fund EDA
developers like Defacto so we can focus on design instead.
So we have STAR in place and my team uses it daily. I like having it as one
platform, where we only have to learn one set of commands and can do things
in one shot. The time savings -- days for connecting IPs and weeks for
verification -- adds up. Plus it's one less thing for me to worry about.
It's like having a toolbox in my garage that gives me the right tool for my
job when something comes up.
Except with all the apps you can add, STAR is more like a Home Depot.
- [ Asterix the Gaul ]
Join
Index
Next->Item
|
|
