ucsc-vama / essent Goto Github PK

View Code? Open in Web Editor NEW

126.0 8.0 12.0 1.02 MB

high-performance RTL simulator

License: Other

Scala 98.19% C++ 1.72% Shell 0.09%

firrtl rtl chisel scala

essent's People

Contributors

Stargazers

Watchers

Forkers

krishnakpandian nijssen ekiwi dercury mspdutta twobnumber1 haoozi jaypiper cong-x-p maerhart keshavaspanda

essent's Issues

Instruction number is different from verilator when we run Nutshell(OSCPU/NutShell).

Long time to compile complicated processor

Hi. We encounter scalability issue when we try to use essent to compile the MinimalConfig of XiangShan (a complicated open-source high performance RISC-V processor). We use a low firrtl file as the input of essent. But the size of the low firrtl file is 140MB, and it contains about 1.5 million lines. This low firrtl file is attached in the zip file at the end of this post. It takes about 13 hours for essent to generate a header file on a server with i9-9900k and 64GB memory.

To profile essent, we use option -ell Debug -fll Debug and save the log into essent.log, which is also attached. We find that the small step took about 11 hours.

$ grep "took" essent.log 
[mffc] took: 29577
[single] took: 3210
[siblings] took: 491903
[small] took: 40090142
[down] took: 5801425
[small2] took: 1273610

Besides, the size of the generated header file is 688MB, and it contains about 5.5 million lines. This huge header file is also attached. It takes days for g++ to compile this huge header file.

Note that the MinimalConfig of XiangShan is dual-issue. But the DefaultConfig of XiangShan is six-issue and the design is much more complicated. Before we try DefaultConfig with essent, we think that we must address the scalability issue of essent.

Below are some suggestions.

From firrtl to .h: We are not familiar with the internal of essent. We hope that the log file attached can help you to analyze the performance.
From .h to elf:
- To enable parallel compilation of g++, we write a python script to split the huge header file into multiple source files. We only keep the class definition in the header file, and move all constructors and functions into source files. Currently there are no more than 100 functions in a source file. The python script splits the huge header file into about 300 source files. We think that essent can support such file splitting feature, with the file granularity configurable by user.
- But it still takes about 2.5 hours for g++ to compile a single split source file with size 2MB. After profiling g++, we find that g++ spends 98% of the time to parse struct body, among of which 80% of the time is cost for name lookup. This is because there are 0.4 million member variables in the class definition of the top module. However, users do not care about the name of these variables. One suggestion is to merge all variables into a big vector. Then essent allocates and manipulates each individual signal in this big vector. To keep readability, essent can generate comments to record the original semantics of signal allocation and manipulation. For example,

// defined in the struct
UInt<1000000> all_signals;
/* 2: cache_real_hit
  4: valid
  5: hit
  ...
*/


// in the function body
all_signals(2) = all_signals(4) & all_signals(5); // cache_real_hit = valid & hit;

essent-XiangShan.zip

Supporting new version of FIRRTL

Hi. I have a project using FIRRTL 1.3.2. essent reports the following errors:

line 5:18 mismatched input 'Reset' expecting {'UInt', 'SInt', 'Fixed', 'Clock', 'Analog', '{'}
line 8:45 no viable alternative at input 'undefined@[SRAMTemplate.scala 76:26]'
line 101:18 mismatched input 'Reset' expecting {'UInt', 'SInt', 'Fixed', 'Clock', 'Analog', '{'}
line 104:45 no viable alternative at input 'undefined@[SRAMTemplate.scala 76:26]'
......

For reference, below is the first module in the fir file.

;buildInfoPackage: chisel3, version: 3.3.2, scalaVersion: 2.11.12, sbtVersion: 1.3.10
circuit NutShellSimTop : 
  module SRAMTemplate : 
    input clock : Clock
    input reset : Reset
    output io : {flip r : {req : {flip ready : UInt<1>, valid : UInt<1>, bits : {setIdx : UInt<7>}}, flip resp : {data : {tag : UInt<29>, _type : UInt<2>, target : UInt<39>, lateJump : UInt<1>, valid : UInt<1>}[1]}}, flip w : {req : {flip ready : UInt<1>, valid : UInt<1>, bits : {setIdx : UInt<7>, data : {tag : UInt<29>, _type : UInt<2>, target : UInt<39>, lateJump : UInt<1>, valid : UInt<1>}}}}}
    
    smem array : UInt<72>[1][128], undefined @[SRAMTemplate.scala 76:26]
    wire resetState : UInt<1>
    resetState <= UInt<1>("h00")
    wire resetSet : UInt
    resetSet <= UInt<1>("h00")
    reg _T : UInt<1>, clock with : (reset => (reset, UInt<1>("h01"))) @[SRAMTemplate.scala 80:30]
    reg _T_1 : UInt<7>, clock with : (reset => (reset, UInt<7>("h00"))) @[Counter.scala 29:33]
    wire _T_2 : UInt<1>
    _T_2 <= UInt<1>("h00")
    when _T : @[Counter.scala 67:17]
      node _T_3 = eq(_T_1, UInt<7>("h07f")) @[Counter.scala 38:24]
      node _T_4 = add(_T_1, UInt<1>("h01")) @[Counter.scala 39:22]
      node _T_5 = tail(_T_4, 1) @[Counter.scala 39:22]
      _T_1 <= _T_5 @[Counter.scala 39:13]
      _T_2 <= _T_3 @[Counter.scala 67:24]
      skip @[Counter.scala 67:17]
    when _T_2 : @[SRAMTemplate.scala 82:24]
      _T <= UInt<1>("h00") @[SRAMTemplate.scala 82:38]
      skip @[SRAMTemplate.scala 82:24]
    resetState <= _T @[SRAMTemplate.scala 84:16]
    resetSet <= _T_1 @[SRAMTemplate.scala 85:14]
    node wen = or(io.w.req.valid, resetState) @[SRAMTemplate.scala 88:52]
    node _T_6 = eq(wen, UInt<1>("h00")) @[SRAMTemplate.scala 89:41]
    node realRen = and(io.r.req.valid, _T_6) @[SRAMTemplate.scala 89:38]
    node setIdx = mux(resetState, resetSet, io.w.req.bits.setIdx) @[SRAMTemplate.scala 91:19]
    wire _T_7 : UInt<72> @[SRAMTemplate.scala 92:47]
    _T_7 <= UInt<1>("h00") @[SRAMTemplate.scala 92:47]
    node _T_8 = cat(io.w.req.bits.data.lateJump, io.w.req.bits.data.valid) @[SRAMTemplate.scala 92:78]
    node _T_9 = cat(io.w.req.bits.data.tag, io.w.req.bits.data._type) @[SRAMTemplate.scala 92:78]
    node _T_10 = cat(_T_9, io.w.req.bits.data.target) @[SRAMTemplate.scala 92:78]
    node _T_11 = cat(_T_10, _T_8) @[SRAMTemplate.scala 92:78]
    node wdataword = mux(resetState, _T_7, _T_11) @[SRAMTemplate.scala 92:22]
    node waymask = mux(resetState, UInt<1>("h01"), UInt<1>("h01")) @[SRAMTemplate.scala 93:20]
    wire wdata : UInt<72>[1] @[SRAMTemplate.scala 94:22]
    wdata[0] <= wdataword @[SRAMTemplate.scala 94:22]
    when wen : @[SRAMTemplate.scala 95:14]
      node _T_12 = bits(waymask, 0, 0) @[SRAMTemplate.scala 95:51]
      node _T_13 = or(setIdx, UInt<7>("h00"))
      node _T_14 = bits(_T_13, 6, 0)
      write mport _T_15 = array[_T_14], clock
      when _T_12 :
        _T_15[0] <= wdata[0]
        skip
      skip @[SRAMTemplate.scala 95:14]
    wire _T_16 : UInt @[Hold.scala 28:87]
    _T_16 is invalid @[Hold.scala 28:87]
    when realRen : @[Hold.scala 28:87]
      _T_16 <= io.r.req.bits.setIdx @[Hold.scala 28:87]
      node _T_17 = or(_T_16, UInt<7>("h00")) @[Hold.scala 28:87]
      node _T_18 = bits(_T_17, 6, 0) @[Hold.scala 28:87]
      read mport _T_19 = array[_T_18], clock @[Hold.scala 28:87]
      skip @[Hold.scala 28:87]
    reg _T_20 : UInt<1>, clock @[Hold.scala 28:106]
    _T_20 <= realRen @[Hold.scala 28:106]
    wire _T_21 : UInt<72>[1] @[Hold.scala 23:81]
    _T_21[0] <= UInt<72>("h00") @[Hold.scala 23:81]
    reg _T_22 : UInt<72>[1], clock with : (reset => (reset, _T_21)) @[Reg.scala 27:20]
    when _T_20 : @[Reg.scala 28:19]
      _T_22[0] <= _T_19[0] @[Reg.scala 28:23]
      skip @[Reg.scala 28:19]
    node _T_23 = mux(_T_20, _T_19, _T_22) @[Hold.scala 23:48]
    wire rdata_0 : {tag : UInt<29>, _type : UInt<2>, target : UInt<39>, lateJump : UInt<1>, valid : UInt<1>} @[SRAMTemplate.scala 98:78]
    wire _T_24 : UInt<72>
    _T_24 <= _T_23[0]
    node _T_25 = bits(_T_24, 0, 0) @[SRAMTemplate.scala 98:78]
    rdata_0.valid <= _T_25 @[SRAMTemplate.scala 98:78]
    node _T_26 = bits(_T_24, 1, 1) @[SRAMTemplate.scala 98:78]
    rdata_0.lateJump <= _T_26 @[SRAMTemplate.scala 98:78]
    node _T_27 = bits(_T_24, 40, 2) @[SRAMTemplate.scala 98:78]
    rdata_0.target <= _T_27 @[SRAMTemplate.scala 98:78]
    node _T_28 = bits(_T_24, 42, 41) @[SRAMTemplate.scala 98:78]
    rdata_0._type <= _T_28 @[SRAMTemplate.scala 98:78]
    node _T_29 = bits(_T_24, 71, 43) @[SRAMTemplate.scala 98:78]
    rdata_0.tag <= _T_29 @[SRAMTemplate.scala 98:78]
    wire _T_30 : {tag : UInt<29>, _type : UInt<2>, target : UInt<39>, lateJump : UInt<1>, valid : UInt<1>}[1] @[SRAMTemplate.scala 99:28]
    _T_30[0].valid <= rdata_0.valid @[SRAMTemplate.scala 99:28]
    _T_30[0].lateJump <= rdata_0.lateJump @[SRAMTemplate.scala 99:28]
    _T_30[0].target <= rdata_0.target @[SRAMTemplate.scala 99:28]
    _T_30[0]._type <= rdata_0._type @[SRAMTemplate.scala 99:28]
    _T_30[0].tag <= rdata_0.tag @[SRAMTemplate.scala 99:28]
    io.r.resp.data[0].valid <= _T_30[0].valid @[SRAMTemplate.scala 99:18]
    io.r.resp.data[0].lateJump <= _T_30[0].lateJump @[SRAMTemplate.scala 99:18]
    io.r.resp.data[0].target <= _T_30[0].target @[SRAMTemplate.scala 99:18]
    io.r.resp.data[0]._type <= _T_30[0]._type @[SRAMTemplate.scala 99:18]
    io.r.resp.data[0].tag <= _T_30[0].tag @[SRAMTemplate.scala 99:18]
    node _T_31 = eq(resetState, UInt<1>("h00")) @[SRAMTemplate.scala 101:21]
    node _T_32 = eq(wen, UInt<1>("h00")) @[SRAMTemplate.scala 101:53]
    node _T_33 = and(_T_31, _T_32) @[SRAMTemplate.scala 101:33]
    io.r.req.ready <= _T_33 @[SRAMTemplate.scala 101:18]
    io.w.req.ready <= UInt<1>("h01") @[SRAMTemplate.scala 102:18]

Is there a plan to support the new version of FIRRTL?

Where is the logger definition?

essent/src/main/scala/Compiler.scala

Line 338 in 9d1db80

logger.info(sg.makeStatsString)

I build the source code but bloop complains that object info is not a member of package logger. But it is interesting that it passes compilation by sbt.

I traced the code, it seems that firrtl provides pacakage logger, and the package provides object Logger and class Logger. Only the class Logger defines info, which means the logger in the source code is not the package logger nor the object Logger, but an instances of the class Logger. And I didn't find the instance.

To repeat the process.

# open with vscode and import sbt build with metals, to generate .bloop
bloop compile essent # or the error shows up in vscode.

Any plan for multi-threading?

verilator supports generating multi-threading C++ models by giving -thread option. Servers can benefit a lot from multi-threading. Is there any plan to support generating multi-threading C++ code?

Using essent with Chipyard

Hi,

I would like to use essent with the Chipyard project to speedup simulation (compared to verilator) of some SoC designs. I am using Chipyard v1.10.0 and it seems like the generated .fir files cannot be processed by essent.

> essent chipyard.harness.TestHarness.chipyard.example.simulation.SmallRocket2x2CoreMeshConfig.fir -O0 --parallel 2
line 1:0 missing 'circuit' at 'FIRRTL'
line 1:7 mismatched input 'version' expecting ':'
Exception in thread "main" firrtl.SyntaxErrorsException: 2 syntax error(s) detected

I tried to comment out the first line that errors out, but then something goes wrong with printf and assert statements during parsing. Commenting out those also did not resolve the issu
chipyard.example.simulation.SmallRocket2x2CoreMeshConfig_all_sources.tar.gz
e and some other error popped up.

I am not very familiar with the state of tooling with firrtl, but I noticed that v1.10.0 switched to circt's firtool (as opposed to the original Scala based firrtl).
Does this mean that Chipyard is kind of unsupported for now?

I have attached the generated files in case you wanted to reproduce the error or take a look at the .fir files.
chipyard.example.simulation.SmallRocket2x2CoreMeshConfig_all_sources.tar.gz

Thanks!

If there is a net with a name which happens to be a C++ keyword then this will cause a compiler error

Example:

module Adder : 
    ...
    output io : {..., signed : UInt<1>, ...}

Will cause an output of:

UInt<1> signed;

To which the compiler complains:

error: declaration does not declare anything [-fpermissive]

This is because signed is a C++ keyword, in addition to being the name of that signal.

The behavior should be changed to not emit names that are reserved words in C++.

ucsc-vama / essent Goto Github PK

essent's People

Contributors

Stargazers

Watchers

Forkers

essent's Issues

Instruction number is different from verilator when we run Nutshell(OSCPU/NutShell).

Long time to compile complicated processor

Supporting new version of FIRRTL

Where is the logger definition?

Any plan for multi-threading?

Using essent with Chipyard

If there is a net with a name which happens to be a C++ keyword then this will cause a compiler error

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent