( ESNUG 373 Item 2 ) -------------------------------------------- [06/07/01]
From: [ The Emperor Has No Clothes ]
Subject: One User's Embarassing SystemC vs. SuperLog vs. Verilog Benchmark
Hi John.
Please keep me anonymous.
I have been using Superlog at our company and I am getting quite impressed
it. However I couldn't ignore the hype about SystemC, so I downloaded the
latest version from their ".org" website and made a quick benchmark based
on your old Verilog vs. VHDL design contest from a few years back. As
you did in that contest, I created two up-by-3/down-by-5 9-bit loadable
counters with parity -- one in SystemC and the other in SuperLog.
My SuperLog code:
module upDown ( input bit clk, up, down, bit[8:0] data_in,
output bit parity_out, carry_out, borrow_out,
bit[8:0] count_out );
bit[9:0] cnt_up, cnt_dn;
bit[8:0] count_nxt;
bit load;
always @(posedge clk) begin
cnt_dn = count_out - 5;
cnt_up = count_out + 3;
load = 1;
case ({up,down})
0: count_nxt = data_in;
1: count_nxt = cnt_dn;
2: count_nxt = cnt_up;
3: load = 0;
endcase
if(load) begin
parity_out <= ^count_nxt;
carry_out <= up & cnt_up[9];
borrow_out <= down & cnt_dn[9];
count_out <= count_nxt;
end
end
endmodule
My SystemC code (header):
#ifndef systemc_upDown_h_INCLUDED
#define systemc_upDown_h_INCLUDED
SC_MODULE(upDown)
{
sc_in clk;
sc_in up;
sc_in down;
sc_in > data_in;
sc_out parity_out;
sc_out carry_out;
sc_out borrow_out;
sc_out > count_out;
sc_uint<9> save_count_out;
sc_uint<10> cnt_up, cnt_dn;
sc_uint<9> count_nxt;
sc_uint<1> load;
SC_CTOR(upDown)
{
SC_METHOD(entry);
sensitive_pos(clk);
}
void entry();
};
#endif
My SystemC (body)
#include "systemc.h"
#include "upDown.h++"
void upDown::entry()
{
cnt_dn = save_count_out - 5;
cnt_up = save_count_out + 3;
load = 1;
if (up == 0 && down == 0)
count_nxt = data_in;
else if (up == 0 && down == 1)
count_nxt = cnt_dn;
else if (up == 1 && down == 0)
count_nxt = cnt_up;
else if (up == 1 && down == 1)
load = 0;
if (load) {
sc_bool_vector tmp(9);
tmp = (sc_bv<9>) count_nxt;
save_count_out = count_nxt;
parity_out.write(tmp.xor_reduce());
carry_out.write(up & cnt_up[9]);
borrow_out.write(down & cnt_dn[9]);
count_out.write( (sc_bv<9>) tmp);
}
}
Considering SystemC is compiled C++ code and Superlog is a parsed and
interpreted language, the results were quite astonishing.
Around these design units I prepared a testbench in SuperLog and SystemC,
for 1 and for 10 instances of the counter, running for 1 million clock
cycles. What I obtained on a Sun at 750MHz (in cpu sec):
counter
instances: 1x 10x
---------- -------- ---------
SystemC 13.3 sec 114.4 sec
SuperLog 2.9 12.2
The SystemC results are abysmal. Worse, they scale badly as the number
of instances linearly increased. The cpu times were measured by the Unix
"time" command, so they include the initial parse time of the SuperLog.
They do not include the time taken by the C++ compiler to compile the
SystemC code. This was an additional 20 seconds. In fact, SystemC was
even beaten by old Verilog-XL on the original Verilog RTL version of the
benchmark. Verilog-XL required 101.5 sec for the 10x benchmark, with XL
simulating 0,1,X,Z reg types and SystemC abstract 0,1 sc_bv types.
So what is this hype about SystemC as the future language of design!?!
Speed - not satisfied here - but it is a main issue for system
design for my work.
Readability - much more verbose than Verilog and separating facets of
the design across 2 files doesn't help. C language
issues obscure the system/hardware/RTL design.
Quality - only C++ compiler syntax traps are available to capture
errors in the design semantics. Like trying to write a
compiled program and relying on the linker to hint at program
bugs. Run time traps are used to indicate some semantic
errors in the design - when bad statements are reached.
Superlog, like other HDLs, analyses the design before the
simulation starts and tells you your design errors, rather
than complaining about the syntax of the native language
simulating the design.
Software CoDesign - SystemC should have an advantage as it is running
as native C++. However SuperLog can transparently
invoke C or Verilog or shareable libraries of
compiled C, C++ and other langauges aswell, without
using a PLI unlike other HDL simulators.
IP - seems there is a lot of hype that models for IP vending and
System-on-a-Chip could be tendered in systemC. If that happens
then SuperLog is OK, since it can invoke the systemC C++ model.
However the majority of IP worldwide is Verilog, and it can also
be invoked directly from SuperLog. The converse is NOT true for
SystemC.
Freeware - SystemC is free on the net - but beware of the adage "pay
now or pay later" since apart from the overheads of using
this package in its raw form, SystemC would require
considerable investment to generate a design. With SuperLog
a design can be extracted that is consumable by DC for
synthesis. For systemC there seems to be a lot of effort to
get Behavioral Compiler as the synthesis tool. BC high level
synthesis is not necessarily good for design.
I think SystemC is the free bait to hook users into an expensive toolset.
- [ The Emperor Has No Clothes ]
|
|
