2

只是说您正在为芯片中的某些基础设施自动生成​​一些 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 端口的分配或来自模块的 io 端口的分配。

这对我们来说效果很好，但现在似乎被最大化了，这很烦人。

有没有人遇到过这个？将其分解为多个寄存器块（以及更多硬件，现在在 pbus 上有多个总线接口）将是可行的，因此如果有人知道解决方法，将不胜感激。

4

2 回答 2

3

我相信同样的限制会导致火箭芯片解码表分成多个类。

不幸的是，我认为没有简单的解决方法，因为这是 JVM 本身的历史设计错误。我可以想到两种解决问题的方法，但我认为其中任何一种都需要一些工作：

  1. 您是否生成器将寄存器创建逻辑划分为方法

  2. 与其生成 Chisel 源代码，不如自己编写 Chisel 来生成必要的寄存器和相关逻辑

#2 可能是 The Right Way™，但考虑到您当前的基础设施设置，#1 可能更平易近人。

于 2018-11-27T18:38:52.920 回答
1

此问题有多种解决方法。

你得到这个错误的原因是你的方法太大了。通常，有问题的方法是构造函数，这是该问题最常见的情况。通常，原因是过度的模式匹配（尽管它不像过去那样严重）。为了使方法更小，您需要将一些东西提取到单独的方法中。因此更换一些

val x = (huge expression)

与：

def calculate_x = (huge expression)
val x = calculate_x

或者

val x = (() => (huge expression))()

甚至

lazy val x = (huge expression)

选择一个不会破坏或不必要地减慢您的应用程序的应用程序。

于 2019-01-08T01:33:03.063 回答