( ESNUG 476 Item 9 ) -------------------------------------------- [10/29/08]
Subject: George is wrong; SystemC/C/C++ tools play nicely with each other
> By only highlighting Bluespec's solution as proprietary, you seem to be
> implying that the ANSI C-to-RTL and SystemC-to-RTL solutions are not.
> While I'm sure that's the perception that these solutions would want you
> to have by wrapping themselves with words like ANSI, C/C++ and SystemC,
> they are indeed proprietary. If you develop IP for any one of these
> vendors, you cannot move it to another without tremendous rework.
>
> - George Harper of Bluespec
> http://www.deepchip.com/wiretap/080606.html
From: Bryan Bowyer <bryan_bowyer=user domain=mentor not calm>
Hi John,
Here's my answers to the questions George Harper's Wiretap post raised:
> Can you name a single other vendor that can synthesize designs that
> have been developed in conjunction with your tools? (That is, without
> rewriting the code and the constraints file?)
Standardization isn't only about second sourcing your synthesis, it's
about verification. CatapultC uses a synthesizable subset of C++ that
is supported by QuestaSim, NC-Sim and VCS as well as standard ANSI C++
compilers such as GCC and Microsoft Visual C++.
A broad group of HLS tools are based on the same ANSI C/C++ and SystemC
standards. Every major verification environment supports these standards
and can be used to verify the design. Each vendor has selected a different
synthesis subset, but much of it overlaps.
> Do you adhere to an industry standard style guide for the way your C must
> be structured and an industry standard synthesizable subset specification
> or are they proprietary? (That is, can you synthesize any and all
> SystemC/C and/or C++ code with your tools? Or, do you have to adhere to
> a style guide (that is, write your code in a particular stylized way) and
> a synthesizable subset specification (that is, only use a prescribed
> subset of the language)?)
The style for HLS is less about syntax and more about design. If you want
to learn about good "design style" find yourself a good book about realizing
your design in hardware, such as "VLSI Digital Signal Processing Systems"
by Keshab Parhi. Another good reference is all the material out there about
the best architectures to use for different types of designs.
> Do you require a constraints file or similar to accompany designs you
> synthesize? If so, is that proprietary?
If we were to use the scripts for the tool as a test for proprietary,
then every EDA tool on earth is proprietary. Let's stick to languages
and verification.
> As you inevitably must interpret how your SystemC/C/C++ interfaces
> behave and work in RTL, is this proprietary?
For Mentor CatapultC, the protocol for the interfaces is primarily defined
as a synthesis constraint. An example constraint would be to map an array
to a single-port static RAM. Other tools approach this differently, but
the core C code is going to generally be the same between the tools.
> Cycle-by-cycle simulation behavior is important for verification. How
> do you guarantee that the design that you simulate will behave the same
> in a system as any other vendor's solution?
The ability to target a specific cycle-by-cycle behavior is a fundamental
guarantee of HLS. If you ask the tools to build RTL to the same timing
and interface specification, then you will get designs that are built to
that specification.
- Bryan Bowyer
Mentor Graphics Wilsonville, OR
---- ---- ---- ---- ---- ---- ----
> By only highlighting Bluespec's solution as proprietary, you seem to be
> implying that the ANSI C-to-RTL and SystemC-to-RTL solutions are not.
> While I'm sure that's the perception that these solutions would want you
> to have by wrapping themselves with words like ANSI, C/C++ and SystemC,
> they are indeed proprietary. If you develop IP for any one of these
> vendors, you cannot move it to another without tremendous rework.
>
> - George Harper of Bluespec
> http://www.deepchip.com/wiretap/080606.html
From: Brett Cline <bcline=user domain=forteds not calm>
Hi John,
I'm sorry for the delay in getting back to you. We've been pretty busy with
customers at DAC and following up with them this week. It is interesting to
see that George seems to have had plenty of free time on his hands. ;)
George is just wrong that all tools are proprietary like Bluespec's.
Specifically, the implication that Forte's Cynthesizer is a proprietary
solution 'wrapped' in a SystemC label is incorrect. The input to Cynthesizer
is standard SystemC/C++. There are no mandated requirements for IP,
"extensions," or other proprietary code that would make our input unusable
by other SystemC tools. ANY tool that supports standard SystemC will handle
Cynthesizer's SystemC input AS IS, and the SystemC ecosystem has already
developed as such. Furthermore, while Cynthesizer can be controlled using
tool directives to improve results, these are command line switches or
standard C++ statements that don't interfere with other tools. The input to
Cynthesizer can be fed directly to standard g++, linked with a standard
SystemC 2.1v1 library and simulated as-is, and is used and processed by a
number of independent third-party SystemC tools. I'm sure that the other
vendors that supply these SystemC tools and work with our customers around
the world will support me on this.
As you astutely noted, Bluespec requires all kinds of proprietary stuff. The
language construct most central to their approach, the rule, doesn't exist
in the SystemC or SystemVerilog languages. This means that any other tool
that wants to work with the BS tools has to support a language that is
fundamentally different from standard SystemC/SystemVerilog. Good luck.
John, as I've said before, we're happy to compete in real accounts on real
designs where it matters. As George mentions, there are no free passes - but
clearly the "whine" is free...
I've answered George's questions below.
> 1. Can you name a single other vendor that can synthesize designs
> that have been developed in conjunction with your tools? (That
> is, without rewriting the code and the constraints file?)
Absolutely not! Forte's Cynthesizer is more advanced than the other
synthesis products and can synthesize designs - such as datapath and control
- that the others cannot handle. Let's be clear on this: George is trying to
argue that because a tool such as Cynthesizer can uniquely handle a more
complete set of designs while other vendors cannot, the solution must be
proprietary. Again, our input is standard SystemC and C++, and Cynthesizer
requires NO proprietary IP or non-standard language constructs to produce
RTL.
Cynthesizer does include a specific set of directives that can be used to
control the synthesis process. An appropriate analogy would be the dc_shell
script or the '//synopsys full case" (and the like) style directives. We
also license our CynWare IP library to customers that can provide additional
benefits - but it is not required to use Cynthesizer.
> 2. Do you adhere to an industry standard style guide for the way your
> C must be structured and an industry standard synthesizable subset
> specification or are they proprietary? (That is, can you synthesize
> any and all SystemC/C and/or C++ code with your tools? Or, do you
> have to adhere to a style guide (that is, write your code in a
> particular stylized way) and a synthesizable subset specification
> (that is, only use a prescribed subset of the language)?)
In general, Cynthesizer can handle any SystemC or C++ code that is given to
it - excluding obvious things that have no correlation in real hardware like
dynamic allocation of memory. It requires that modules to be synthesized
have a clock pin, a reset pin, and be written using the standard SystemC
SC_CTHREAD and SC_METHOD constructs. Input/output protocols are specified
using SystemC allowing the exact pin and cycle-accurate details to be
defined using the language semantics. This allows the designer to synthesize
what they simulate - something not possible with ANSI-C.
Cynthesizer currently adheres to the JEITA synthesizable style guide defined
by JEITA, a Japanese industry organization with over 500 members with
cooperation from Forte. It also adheres to the draft OSCI Synthesis Working
Group standard.
> 3. Do you require a constraints file or similar to accompany designs you
> synthesize? If so, is that proprietary?
No, Cynthesizer does not require a constraints file to get results. We do
provide synthesis directives as an option to greatly improve the quality of
results - there is no standard available today to cover these high-level
synthesis directives. We use command line switches and embedded directives
expressed using standard C++ constructs.
These directives allow designers to direct the tool to meet a certain
performance or throughput target, create a custom datapath component, etc.
There are plenty of tools that can read Cynthesizer's input without any IP
or special code from Forte - this includes Calypto's SLEC formal equivalence
checker, Actis' AccurateC analysis product, CoWare's Platform Architect
design environment, Jeda Technologies' code coverage and assertions, OSCI's
open source simulator, SystemC simulators from other vendors, and more.
> 4. As you inevitably must interpret how your SystemC/C/C++ interfaces
> behave and work in RTL, is this proprietary?
Interfaces in Cynthesizer's world are created in SystemC - just using the
plain and simple standard.
> 5. Cycle-by-cycle simulation behavior is important for verification.
> How do you guarantee that the design that you simulate will behave
> the same in a system as any other vendor's solution?
As I explained above, with Cynthesizer this is done with plain ol' SystemC.
Any SystemC-compliant tool will interpret the code in the same way. During
the Cynthesizer process, we optimize the RTL to meet the strictest
performance and area criteria. To maintain the cycle accuracy of an
interface it can be identified as a "protocol" block. This guarantees the
protocol accuracy of the input SystemC and output RTL will be the same - and
can be tested by the same testbench. Cynthesizer uses a non-invasive inline
directive expressed using only standard C++ constructs for this purpose. It
doesn't require any language extensions for other tools to use Cynthesizer's
input.
- Brett Cline
Forte Design Systems Acton, MA
---- ---- ---- ---- ---- ---- ----
From: Andrea Kroll <andrea=user domain=jedatechnologies.net>
Hello John,
Interesting perspective about what is standard and what is proprietary. To
me the definition from George is not to even holding up for some Verilog
source code in most of the Verilog simulators. And I am sure that no
one defines those are proprietary tools.
Jeda tools validate of system level models in C/C++ and SystemC. We have
currently multiple joint customers with Forte's Cynthesizer. Our users can
use Jeda's model validation tools, which instrument SystemC code, without
any modifications on their SystemC models. So far, none of our joint
customers have had to change their code, while following the SystemC
language standard, to benefit from our collective tools.
- Andrea Kroll
Jeda Technologies Los Altos, CA
---- ---- ---- ---- ---- ---- ----
From: Pat Sheridan <psheridan=user domain=coware not calm>
Hi John,
Users can directly simulate and debug the SystemC input of Cynthesizer at
the source code level and as a block within our CoWare Platform Architect
TLM platform, without needing anything special from Forte... it's really
just SystemC!
Using HDL cosimulation or tools such as Carbon Model Studio, the output RTL
can be brought into the CoWare SystemC simulation for validation of
platform performance, too.
- Pat Sheridan
CoWare San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Mitch Dale <mdale=user domain=calypto not calm>
John,
Our SLEC comprehensively verifies RTL generated by HLS tools such as Forte
Cynthesizer and Mentor CatapultC. SLEC reads standard SystemC and C/C++.
SLEC support for these languages goes beyond the synthesizable subset to
include dynamic memory allocation (as long as the limits can be determined
at elaboration), pointer arithmetic, virtual functions and recursion.
- Mitch Dale
Calypto Design Systems, Inc. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Joan Bartlett <joan=user domain=actisdesign not calm>
Hi John,
I'm president of Actis Design and we have a SystemC static analysis tool,
a very fancy lint tool, called AccurateC. It reads in SystemC designs and
finds potential code defects prior to compilation, simulation and synthesis.
It is our business to support C++ and SystemC coding standards.
I am familiar with Forte's Cynthesizer product since we have some mutual
customer engagements in Japan. My experience has been that Forte's tool
uses OSCI standard SystemC code. Of course there are some C++ pragmas they
add, as do most tools, but nothing that prevents their code from running on
the OSCI SystemC simulator. In the SystemC world you don't get any more
standard than that.
- Joan Bartlett
Actis Design LLC Portland, OR
Index
Next->Item
|
|
