假设您正在为芯片中的某些基础设施自动生成一些 Chisel 代码。单个文件实例化内存映射寄存器负载，然后实例化 IO 分配。
然后假设有一天您添加了一个额外的寄存器，并且 JVM 崩溃了，并且由于 JVM 中的任意 64k 方法限制大小而不想再构建它:
[error] Could not write class HasRegsModuleContents because it exceeds JVM code size limits. Method scala/Some's code too large!
[error] one error found
[error] (chipBlocks / Compile / compileIncremental) Compilation failed
[error] Total time: 41 s, completed 27/11/2018 2:32:29 AM
HasRegsModuleContents 内部是一堆寄存器的声明，然后是一个大的 regmap 语句，其中包含芯片的一堆寄存器声明。接下来是模块 io 端口的分配。
这对我们来说非常有效，但现在似乎已被最大化，这相当烦人。
有人以前遇到过这个吗？将其分解为多个寄存器 block (以及更多硬件，现在 pbus 上有多个总线接口(interface))将是一项工作，因此如果有人知道解决方法，我将不胜感激。
最佳答案
我相信同样的限制会导致火箭芯片解码表分成 multiple classes .
不幸的是，我认为没有简单的解决方法，因为这是 JVM 本身的历史设计错误。我可以想到两种方法来解决这个问题，但我认为其中任何一个都需要一些工作:
生成器是否将寄存器创建逻辑划分为方法
不是生成Chisel源代码，而是编写Chisel本身来生成必要的寄存器和相关逻辑
#2 可能是正确的方法™，但考虑到您当前的基础设施设置，#1 可能更容易理解。
关于scala - 解决大型 Chisel 文件所触发的 JVM 代码大小限制的任何方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53492027/