( ESNUG 484 Item 3 ) -------------------------------------------- [03/12/10]
Subject: No SNPS SystemC monopoly because CoWare & VaST are proprietary
> The recent Synopsys acquisitions of CoWare & VaST are interesting. While
> consolidation in the virtual platform segment is probably needed there is
> a hidden scary part of this story that is critical to understand; it's
> not about the products, it is about the models. Each of these companies
> has significant investments in C and SystemC models and now (with their
> past Virtio acquisition) Synopsys will have a lock on that space!
>
> - Brett Cline
> Forte Design Systems Acton, MA
> http://www.deepchip.com/wiretap/100215.html
From: [ An Anon Japanese EDA User ]
Hi, John,
The million dollar question now is if Synopsys will continue on the SystemC
road. Synopsys will need to synthesize all those CoWare SystemC models in
order to keep its costumers locked into the Synopsys world. With Mentor
and Cadence already providing SystemC synthesis tools, their only options
are either developing their own SystemC synthesis tool or buying Forte.
I guess the Forte people should get prepared to finally now cash in.
- [ An Anon Japanese EDA User ]
---- ---- ---- ---- ---- ---- ----
> CoWare owns $20M SPW market.
>
> Synopsys COSSAP only took $10M of same market.
>
> SNPS buys CoWare for $20M, gives SNPS $30M majority in Virtual Platform
> plus Sony, Freescale, NXP and Toshiba which are SPW customers that
> Synopsys didn't have before.
>
> This plus VAST buyout gives SNPS a near monopoly in SystemC models.
From: Shabtay Matalon <shabtay_matalon=user domain=mentor not mom>
Hi, John,
A "monopoly in SystemC models" is an oxymoron, John. Here is why:
Up until two years ago, we had no modeling standards, so the virtual
prototyping solutions were all proprietary. You couldn't simply take a
CoWare model and plug it into VaST, or plug a VaST model into the Synopsys
Virtio product. Modeling services were heavily used for building models
into each environment using their own proprietary simulation API (such as
CoWare N2C).
SystemC becoming an industry standard modeling language for creating
transaction level models (TLMs) plus OSCI approving SystemC-based TLM 2.0
as a very fast intra-model communication layer changed all this.
Models can now be used interchangeably between virtual prototyping tools
and run on any SystemC simulator -- killing any monopoly potential by a
single SystemC model supplier.
- The standard model communication layer allows TLM2-compliant models
to be plugged into a Virtual Prototype where communication between
models is required.
- In addition, core models built using C/C++/SystemC can be run on any
of the SystemC compliant simulators offered by Cadence, Synopsys and
Mentor. Users will be able to pick and choose off-the-shelf ESL models
representing standard design IP and plug them into their ESL design and
Virtual Platform tool. So with this standardization, the need for
services to support proprietary modeling approaches is dropping.
- Most virtual prototyping models built by companies such as CoWare and
VaST were not even based on SystemC up to 2008-2009, and did not use
the TLM2 style guide for timing and communication.
- What these companies have been doing is trying to make their proprietary
models TLM 2-compliant.
- In some cases, they will just throw a TLM 2 wrapper around the model,
but in many cases, the models will have to be rewritten for issues with
speed or scalability or SystemC language compliance. Synopsys must
continue on the SystemC TLM2 path as users will not invest money in
models locking them to one EDA Vendor tool -- just look at what happened
to the Specman "e" testbench language. It's supported only by Cadence.
In his keynote during SystemC Day at DVCon'10, Gary Smith said that "Virtual
Platform" represents only 23% of the ESL market:
Gary Smith's 2009 ESL Segments
Virtual Platform : ########## 23%
Architect's workbench : ######### 21%
High Level Synthesis : ###### 14%
Silicon VP : # 1%
Other (mostly ESL Verification) : ################## 41%
So what will differentiate models moving forward is their ESL scope coverage
and core capabilities. ESL models will not be created just for Virtual
Prototyping, but will instead need to serve ALL the major ESL segments that
Gary mentioned: ESL verification, architecture design, and high level
synthesis. It is simply not scalable to create a different model for each
one of these ESL segments. Many of the legacy models that Synopsys just
acquired were created primarily for virtual prototyping, which greatly
limits their use in the other ESL segments.
With SystemC and TLM 2.0, connecting models to create a virtual prototype is
piece of cake; however a proper virtual prototyping platform will no longer
be a bunch of C models stitched together. It must have much more automation
and integration involved. Let me explain.
- There is a wide spectrum of what ESL models can describe. Some just
describe the raw hardware interface presented to the software side,
and some represent more accurate hardware functionality. But if you
want to analyze and optimize your software to meet your design
performance and low power goals, you need your models to also describe
both timing and power.
- A key requirement is for a single model to tradeoff timing accuracy vs.
speed. This is needed to verify and optimize real-time software. It's
a careful balance, as putting too much timing information (such as
clock-cycle accuracy) in the model can slow down performance to a crawl.
- You also want to be able to have the same model run for speed in one
mode and for accuracy in another one and to be able to switch between
modes even in the same simulation session.
- In order to verify your system, you'll need to verify system level
scenarios with the hardware and software interacting with each other.
To do this, you need to have the debug and analysis tools to debug
software running on multi-core -- while at the same time viewing the
hardware concurrent processes and events over time. You also will
need the controllability to run and stop the simulation on software
and hardware errors.
- When you build your virtual prototype, a higher level of abstraction
above RTL is used to obtain the speed. However, as you create your
hardware in RTL, you still need to validate that the software will run
against the accurate RTL. You'll need to be able plug these ESL models
in your RTL verification environment (such as OVM) or even use your
virtual prototype models as a testbench for validating your RTL running
on an emulator/prototype.
So why is this consolidation happening in the virtual prototyping segment?
As only 23% of the ESL market, Virtual Prototyping simply could not provide
the integrated ESL/RTL flows that users are looking for.
But one thing is certain: Synopsys will now need to deal with reconciling
their overlapping Virtual Prototyping products and incompatible legacy
models -- which will distract them from focusing on what really matters.
Remember that Synopsys is not the only game in town for SystemC models; ARM
is also providing ESL Fast Models, too.
- Shabtay Matalon
Mentor Graphics Corp. San Jose, CA
Sign up for ESNUGs! Fun!
Index
Next->Item
|
|
