( ESNUG 351 Item 4 ) ---------------------------------------------- [5/4/00]
Subject: Three Letters Correcting Cooley's SystemC vs. Cynlib Comparision
> Here is an example for an adder that adds a + b then registers the output
> to register c in both Synopsys SystemC and CynApps CynLib:
>
> a --->|--| temp -----
> |+ | ------>|reg|----> c
> b --->|--| -----
> |
> clock -------------
>
> Synopsys SystemC CynApps Cynlib
> ---------------- --------------
>
> #include "systemc.h" #include "cynlib.h"
>
> struct adder_reg : sc_module { Module adder_reg (
> sc_in> a; In<8> a,
> sc_in> b; In<8> b,
> sc_out> c; Out<9> c,
> sc_in clock; In<1> clk )
>
> // internal signal Always (Posedge(clk))
> sc_signal> temp; c <<= a + b;
> EndAlways
> // adder process EndModule
> void add() {temp = a + b;}
>
> // register update process
> void reg() {c = temp;}
>
> // Constructor
> SC_CTOR(adder_reg) {
> SC_METHOD(add);
> sensitive << a << b;
>
> SC_METHOD(reg);
> sensitive_pos << clock;
> }};
From: [ A Synopsys SystemC CAE ]
Hi John,
Since you are comparing SystemC with CynApps, please compare apples to
apples and not different style, as you did in your example. Please
publish the following correction:
Synopsys SystemC CynApps Cynlib
---------------- --------------
#include "systemc.h" #include "cynlib.h"
SC_MODULE(adder_reg) { Module adder_reg (
sc_in> a; In<8> a,
sc_in> b; In<8> b,
sc_out> c; Out<9> c,
sc_in clock; In<1> clk )
void add() {c = a + b;} Always (Posedge(clk))
SC_CTOR(adder_reg) { c <<= a + b;
SC_METHOD(add); EndAlways
sensitive_pos << clock; EndModule
}
};
I'd like to point out the flexibility of the coding style with SystemC
in terms of data types and modeling hierarchy. This flexibility comes of
course with the problem that one can use different styles to model the
same thing. However if we compare to other libraries, we should make
an effort to show the same style. Otherwise any comparison looses
credibility in my eyes.
And I found another even worse mistake in your email. The following is
simply wrong:
> Both C-based design systems require their own special pre-processors to
> make the macros they use actual true GNU gcc compile-able; it just appears
> that CynApps pre-processor "Cyn++" is more adapted to having engineers
> write C psuedo-code that's very Verilog-like. See http://www.cynlib.com
SystemC doesn't need a preprecessor. Where did you get this information?
It is wrong!!! Only CynApps needs their own proprietary preprocessor.
SystemC can be compiled as is with a standard C++ compiler.
- [ A Synopsys SystemC CAE ]
---- ---- ---- ---- ---- ---- ----
From: Kurt Schwartz
Hi, John,
I was amused by the comparison given of SystemC to Cynlib. In the interest
of providing a little more realistic comparison, I'd like to make two
points:
1) The SystemC example gratuitously used two processes where one would
have been sufficient.
2) Download the free Cynlib software and try to compile the Cynlib
example: OOPS - it won't compile. Why? Because it uses a special
Verilog-like syntax that requires a proprietary ($$) pre-processor
to translate the code into C++.
Note that SystemC does use macros to hide C++ implementation details, but
these macros come with the free download and do not require a proprietary
pre-processor.
- Kurt Schwartz
Willamette HDL, Inc.
---- ---- ---- ---- ---- ---- ----
From: David Chapman
John,
Great review, even if I couldn't understand some of it - I work mostly in
low-level physical design these days.
I'd like to point out what looks like a typo in your SystemC example:
> Synopsys SystemC CynApps Cynlib
> ---------------- --------------
> ...
> struct adder_reg : sc_module { Module adder_reg (
> sc_in> a; In<8> a,
If in fact SystemC is to use ANSI C++, the line on the left should be:
sc_in > a;
Notice the extra space! Because of the way compilers work, the closing
brackets for the template in the original example will be read as a
"shift" operator instead of template brackets. The line can be formatted
most any old way as long as '<' or '>' template specifiers are not
concatenated. Not being an official "promoter" of SystemC (i.e. I
haven't downloaded anything from them), I don't know if this was a typo
on the part of the transcriber or was in fact in the original computer
readable text.
The ANSI C++ committee argued about that extra space for a long time
before finally agreeing that it had to be there. It's an artifact of
the somewhat clunky way of specifying templates in C++. If the current
SystemC preprocessor accepts this non-C++ syntax, they'll be setting
their users up for a maintenance nightmare and will need to stop this
non-ANSI "feature" now while they have a chance.
(I'm hopeful that it was just a transcription error, which would look
quite harmless and be easy for a non-C++ programmer to make, but it's
potentially too important an error just to assume that.)
- David Chapman
Chapman Consulting Santa Clara, CA
|
|
