( ESNUG 456 Item 5 ) -------------------------------------------- [07/17/06]
Subject: 3 users on Knowlent Opal's SerDes/PCIe/XAUI electrical compliance
> Santa Clara, CA - Knowlent seeks 2 EDA R&D developers. These jobs are
> open only to experienced developers in EDA software such as: Cadence ADE
> or Virtuoso, analog waveform viewers (like Wavescan, EZwave, CosmoScope,
> Awaves, Nwave), Matlab, simulators (Synopsys VCS, Cadence NC-sim, Mentor
> Modelsim) or Spice in any flavor (Hspice, Spectre, Eldo). Knowledge of
> Verilog AMS would be a plus. Requirements: MS with 5+ years or related
> Ph.D. with 2+ years of experience in programming software with C++, C,
> Tcl, Perl, QT, IPC, multithreading, PLI on UNIX/Linux.
>
> - from http://www.deepchip.com/jobs/013.html
From: James Jones <jhjones=user domain=lohan-solutions spot calm>
Hi, John,
In Artisan's 130-nm SerDes development group, we began using Knowlent while
it was still in beta, with their AE helping us bring up the testbenches.
We used Opal to verify the IP for PCIe Gen-1 and XAUI electrical compliance.
Where software such as Denali's PCIe testbench checks the logic in the
communications stack, Knowlent checks the front-end analog/mixed-signal
(A/MS) physical blocks.
A SerDes has 2 basic functions that form a natural architectural partition:
a transmitter function to serialize and transmit data (Tx), and a receiver
function to recover and deserialize the "receive data" (Rx). For design,
the functions that are common to both the Tx and the Rx are typically
grouped into a 3rd partition. The transmitter takes the Tx data presented
on the internal Tx core-side interface, serializes it, and then drives it
across the medium to the far-end receiver. The receiver recovers the clock
from and re-times the received serial data, deserializes it, and then
presents it on the internal Rx core-side parallel interface.
Opal helps verify the A/MS blocks that are the high speed portion of the
SerDes. The industry standard PHYs have long checklists of specs to meet;
Knowlent's engineering team extracted the specs for the high-speed portion
and wrote testbenches to check for compliance with PCIe, XAUI, and SATA.
Most companies prefer independent verification of digital blocks, where the
person who does the verification didn't also write the block; but few
systematically do independent verification of A/MS blocks. Opal provides
testbench IP -- a fully verified set of tests -- to allow independent
verification of analog/mix-sig blocks. It would take an engineer on an
internal team several months to write these same tests. At Artisan, my
design team needed to verify the SerDes by running the full test suite over
a full range of design corners -- Opal helped us automate this verification.
Spec-based automation is a favorite topic of mine -- several years ago I was
a member of the Cypress group that provided input to an EDA start-up named
Antrim to define such a tool. The Antrim tool did not make me happy (some
others liked it) -- eventually, Cadence bought Antrim and is now marketing
that tool (Aptivia), but I have not used the tool since it entered
Cadenceland. In my opinion, Knowlent has a more efficient perspective on
spec-driven automated A/MS verification than Antrim did.
At Artisan we used Opal in two ways, both on the stand-alone SerDes IP, and
on the same SerDes IP instantiated in a specific "Test Chip". Opal runs on
top of a SPICE or other transistor-level simulator -- we used HSPICE as our
simulation engine. We fit our DUT netlist into the testbench and included
our foundry's SPICE models. Opal produced a margin report with whether it
passed or failed, and how much margin we had. We ran the tests for all 3 of
our major foundries: TSMC, UMC, and Chartered, and were able to re-use the
same testbench.
It seems to me that if you are a SerDes IP customer (using SerDes IP from
ARM, Rambus, Synopsys or other), you can use Opal to validate your SerDes
IP provider's claims by verifying that the IP passes the specifications with
your package models. To do this, you would need:
1. Your foundry's SPICE models.
2. Your IP provider's transistor-level netlist (of at least the I/Os).
3. Your own package models.
You would plug all 3 into Opal and run the selected suite of simulations,
and generate the validation report. If the IP is spec-compliant
"out-of-the-box", then your package/board/etc design and how well you
integrate the IP block in your ASIC will determine whether your product
will meet the industry standard PHY specifications.
For us, Opal automated building the corners, running the tests across the
corners, and building summary reports. Our alternative would have been
to do write the scripts ourselves. For example, if we were using Cadence's
Analog Design Environment, we might have written the simulation automation
and measurement scripts in OCEAN, which in my opinion would have been pretty
painful and clunky. Additionally, I think Perl or Tcl scripts are less
clunky and painful to write and maintain (my personal scripts from several
years ago were in csh, but today's engineer probably uses Perl or Tcl), but
it seems that you must use OCEAN to easily access the power inside of
Cadence's A/MS development tools. I've seen that Synopsys is talking-up Tcl
scripting with their tools, so maybe Cadence will move that way, too. In
any case, the most recent version of Opal that I've seen allowed for Tcl or
Perl.
Some specific comments on Opal functionality:
1. Opal does exhaustive verification of all electrical spec parameters.
Without Opal, we would have tested the same parameters, but used a more
manual approach and had less sophisticated scripts. In my opinion, the
ideal is for the set of simulation tests and the measurement methods to
match the way in which the specs will be tested post-Si on the lab bench
as closely as possible and practical. This ideal is rarely reached.
It's not always reasonable, but the testbench that comes with Opal
contains some fairly sophisticated scripts that are much like the ones
used by lab equipment, and, of course, the tests and measurements are
constrained to avoid un-warranted run times.
2. With Opal, after we complete the design of a block and a model update or
small modification for a DRC change after a new run-deck comes in from
the foundry, we can automatically kick-off the full verification rather
than having to redo several manual steps. This saves time and hassle in
getting to an updated verification report that allows us to see if the
model update or layout changes caused any significant change to the sim
results -- new spec failures and other unwanted surprises are obvious
when the new Opal verification report is reviewed.
3. If we have the same block for multiple technologies, and it has the same
pin-out, we can plug it into the same testbench and run it by just
pointing to the different SPICE models (might require a wrapper around
the models in some cases depending on how your flow is implemented).
Aside from the testbench reuse time saving, this is also great for
getting a first-pass look at how easy/hard from a performance perspective
it will be to port the block to a second-source foundry.
4. If we have a configured SerDes block and are checking it for XAUI spec
compliance, for example, we can also quickly see how well that same
block will do for other standards just by using a different testbench
module from Knowlent. At Artisan we had the Opal PCIe, SATA and XAUI
testbench modules.
5. As one of Knowlent's first customers, we influenced their verification
reports, which I am now happy with. For example, Opal's report can be
ported into Excel. You can also use the data out of Opal for the
"margin report" that foundries like TSMC require from IP providers.
6. Opal has both a framework piece, meaning the ability to create and
automate testbenches, plus a number of prepared testbenches for
different SerDes standards. I've heard that they've added PCIe Gen 2
and several others since I last used the tool.
7. At Artisan in San Diego, we had a rack of Linux machines, so it only took
a few seconds to run many of the HSPICE sims that Opal uses. Some of the
sims took longer -- it varies, depending on your hardware and the design
complexity. You can also select the subset of sims that you want to run,
so you do not have to run the longest sims each time that you run the
testbench.
What was missing from Opal? There were a few new features that we requested,
which Knowlent claims are in their 4.0 release, though I have not personally
verified it:
1. We wanted more visibility into exactly how the measurements are being
taken.
2. We wanted to be able to edit their scripts to make custom modifications.
3. Ease of use ... we wanted to be able to set-up the initial Opal run more
quickly. Admittedly, the first time we were just learning the tool and
working with beta software so it took several hours. It got a lot
quicker after we learned how to use the tool and we moved to production
versions of the software. I don't have an estimate of the initial
start-up time that a new user would see using today's production version
of Opal, because we already had our tests setup with the beta tool when
we got the first production release.
The best part about Opal to me is its complete set of verification tests;
overall, having the testbench saved us a few weeks. We didn't have to write
a platform to automate the simulations and we had a fully-formed testbench
already scripted for us -- that saved us a lot of coding and learning time.
Writing the scripts for automated testing -- the framework -- would have
taken several weeks. Opal automated the simulation and measurement of all
our parameters over the desired design corners.
When we used Opal, we found several violations which we subsequently fixed
before we released our IP. In one case we modified the driver and re-ran
Opal to verify that the fix worked and did not affect passing any of the
other specs.
I am satisfied with the results I got from using Opal, and I intend to use
it again for my next SerDes design.
- James Jones
Lohan Solutions Austin, TX
---- ---- ---- ---- ---- ---- ----
From: [ El Pollo Grande]
Hi, John,
Please keep me anonymous on this.
I run the ASIC physical design group at a fabless semiconductor start-up.
We use 3rd party IP for our IO buffers and other PHY layer needs, including
SerDes. After selecting the IP, we must of course integrate and verify it.
Verification of the IO buffers, though messy, worked out as expected.
However, verification of the SerDes and serial links was completely new to
us and we were in for a rude awakening.
My team was too small to handle all the required compliance work, so we
gave our designs to Knowlent to run in "taxicab mode" for us using their
Opal analog verification IP. The Knowlent people returned with the sim
results summarized and tabulated them into a single spreadsheet for all
checklist items, with all the failures highlighted. Opal is also capable
of generating detailed data documenting any failures in the form of eye
diagrams, return loss plots and signal waveforms showing excessive
crosstalk.
Once the initial simulation models were created and connected up in a basic
HSPICE deck, it was trivial to re-run the analysis to perform what-if
analysis such as how the model behaved across corners, with a different
package, with blind PCB vias, etc.
The thing I like best about Opal is it automatically and comprehensively
checks whether I am meeting every single compliance checklist item or not.
I don't have to read any specifications, understand any of the complicated
test set-ups implied in those documents, or worry about making mistakes in
transferring those checks into a circuit simulation model or in interpreting
the simulation results. (We were new to serial link protocols and did not
know all the electrical specifications.) Also, it was easy to extract
information from the simulation runs. For example, we were very interested
in confirming the power dissipation numbers from the vendor's datasheet.
The results that Knowlent showed us with Opal gave us a good starting point
on how to program our SerDes for different applications (IO voltages, drive
levels, pre-emphasis and equalization settings, etc.) prior to entering the
lab to do characterization. It also allowed us to set the correct
expectations on whether our XAUI compliant PHY would also be CX4 and KX4
compliant.
At the end of the day, Opal showed us 3 design shortcomings:
1. There was a biasing issue at the receiver inputs which led our PHY
vendor to change the design to isolate the common-mode voltage of
the receivers from that of the transmitters.
2. The return loss performance of the PHY in the absence of any
channel whatsoever was marginal.
3. There was no hope of running a link across a cable or a backplane.
Opal is not perfect.
- Opal does not model anything in the PHY except for the channel
interface logic (the output driver and input receiver). I would
prefer that Opal included more circuitry in some of their sims.
For example, simulating the operation of the CDR would be a logical
next step, especially considering that in our case relying on our
SerDes IP vendor to be responsible for the correctness of the CDR
turned out to be a bad idea. Integrators like us need the ability
to verify the internals of the PHY at least to some degree.
- The Opal results are only as good as the models which go into them.
There needs to be an easy way to validate the models used for the
channel components.
Opal runs on top of a SPICE simulator, and should be seen as a productivity
enhancement tool rather than a must-have tool. In summary, I recommend
Opal to two groups of engineers:
1. Engineers designing PHYs who already know what the goals are, but
might like some productivity enhancement.
2. Engineers integrating PHYs into larger designs who sort of know the
goals but don't have the resources (in time or expertise) to know
for sure, and would like the ability to easily verify complete
compliance to one or any number of industry standard serial link
protocols.
Knowlent is like a Denali for analog electrical compliance verification.
- [ El Pollo Grande]
---- ---- ---- ---- ---- ---- ----
From: [ One of the 47 Ronin ]
Hello, John,
Please keep me anonymous.
We used Opal analog verification for our PCIe interface. We needed to
verify that:
1) The SerDes + PCIe IP was compliant to the standard.
2) The SerDes + PCIe IP worked with our specific package configuration
and target boards for our chip.
Opal automated the SI HSPICE runs, and was especially useful for simulations
with many variations. After running the simulations, Opal had a summary
spreadsheet with the pass-fail status of each electrical compliance check.
This PCIe compliance report, with some tweaking by Knowlent, was quite good.
It nicely summarized multiple weeks of work. For results, Opal caught a bug
in our PCIe HSPICE netlist and it detected an error in the package model
that we had created for our ASIC.
Our alternative to Opal would have been to create custom scripts or worse,
spent many hours manually running the checks. The number of different spec
parameters that Opal tested automatically was far more than what we would
have been able to do manually.
Opal has pre-configured, extendable adapters for testbench setup. The ones
that relate to basic PCI Express compliance are provided. However, their
number of pre-configured real system level topologies is somewhat limited,
which I see as a shortcoming. Technically, we could have created these
system topologies ourselves, but reality and deadlines intrude. It would
be more efficient for Knowlent to generate them once and have all their end
users all benefit. Additional topologies would be a nice enhancement for
the future, since running extra simulations with Opal is cheap in that they
are mostly just a matter of CPU time. We are a start-up, so our project
times and resources are more or less fixed.
- [ One of the 47 Ronin ]
Index
Next->Item
|
|
