Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-03-17T15:01:00Z

From reading the webpage (annoying it's https without a certificate, but anyhow)
I seriously doubt that SystemCass could get even remotely close
to the performance of Verilator, which does much more than what they optimize

• the code Verilator generates in the internal model is not SystemC.

Anyhow, how large is your design? Very large (>>10M gates) designs can
have a SystemC shell to instantiate separately verilated modules. See
[[http://www.veripool.org/boards/2/topics/show/84-Verilator-Verilator-best-practice-flow-Large-designs-bottom-up]]

I would like to have Verilator generate such shells, but as with all things, time limits.
If you want to look at implementing hierarchical compiles I'll give you pointers.

Original Redmine Comment
Author Name: joe barjo
Original Date: 2010-03-17T16:08:08Z

Thanks for your response

For systemCass, the internal model can also be something different from system C.

The test design we used was about 1.5M gates.
Our flow actually generates vhdl, and we are actually switching to verilog.

For the test (I know this is a bad test...), we synthetised the vhdl (with synDc), and tried to simulated the generated structural verilog.
Verilator simply blew out the memory (more than 3Gb) and never went through.
Then we post processed the generated verilog and transformed gate instances into equations.
It took verilator about 1h to generate 1000 cpp files.
Then it took about 1 hour per cpp file to compile. (We haven't compiled this)

With icarus verilog, it took about 18h to generate a binary.

Today we are generating native verilog code that is much more compact.
We will keep you posted with the test results.
We are currently evaluating verilator, icarus verilog and gpl cver.

I don't fully understand how to use the system perl shells, and how they integrate with verilator.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-03-17T16:16:40Z

Oh, you're simulating gates, not RTL?

For that large a gatesim, you'll want a commercial simulator. That's not what
any of the open source tools are designed for (to my knowledge), the "market" is
just too small.

Converting it to RTLish is interesting though... I'm surprised it goes that
slowly, though the memory isn't a surprise - that's fine. Can you run with --stats and send the resulting file? I'm guessing your outputter needs to remove more hierarchy.

Original Redmine Comment
Author Name: joe barjo
Original Date: 2010-03-17T17:05:10Z

Gate simulation is not our goal. This was just a test
gplcver eats this gate level verilog instanly...
But it is slow...

We now do output rtl level verilog. But it currently has interfaces with vhpi or vpi.
So we will use a much smaller design without vpi for a new verilator test.
I'll keep you updated with results

Thanks

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-03-17T20:14:00Z

BTW, I suspect you already thought of this, but make sure your system isn't paging.
I ran our whole chip, it's 7.3 GB but only 18 minutes.

#2182 is addressing this issue.