原因#

比较容易想到的原因，一方面是语料太少，尤其是这方面私有程度很高，优秀的私有设计并不开放；并且大量私有设计也附带了大量私有工具链。 比如几家典型处理器巨头的一些工具链产品都是从自家研发体系中催生出来的。

另一方面，也是更为重要的方面，硬件设计方面可连续循环调用读取的反应太少了。AI写出代码后无法有效地用工具检查，检查结果也未必会直接指导 AI如何修改代码。通常只有一些基本的verilog语法检查工具使用，这对于实际优化设计并没有什么帮助； 相对有帮助一些的是sta之类的，但是过程也是完全的黑盒，AI只拿得到一个结果、路径，但是拿不到具体代码应该如何修改。 更进一步的，综合过程，但是这里也和sta一样，不会直接指导AI设计，也就是说对于AI优化设计，没有什么真正有效的反馈。

何至于斯#

这不是要让AI用才有的问题，对于没有AI的时候，对于人也是一样的。硬件设计与软件设计在模式上最大的差别之一，就是硬件设计的 规则或者说最佳实践，基本上是以知识的形式存在，更形象的说，“口口相传”的形式。 与软件对比，软件方面则是用丰富的语法来约束设计，用语法的限制来使得人遵从实践。拿编译器公认牛牛牛的rust来说。不但有详细的报错和警告，甚至 还有help、hints。而verilog有什么？能指望AI用这一套烂玩意儿生成大项目吗？

说白了，在当前给AI提供的工具下，根本无法与当前Agent的发展良好接轨，AI写出的硬件项目跟AI做出的docx一样烂甚至还要更烂（后者至少约束起来更容易也就更容易产出相对可用的玩意儿）。 根本就是原始的chat在Agent时代搞出了不用复制粘贴的快捷方式罢了。

根本来说是反馈信号太稀疏。你能在没有cargo test情况下写出好rust吗？能在没有gtest的情况下写出好cpp吗？

现在还有一些好的尝试，比如UCAgent，这能够改善问题到什么程度呢？我并不持根本解决的态度。

就得走编译的方法。

实话说，除了CIRCT之外，还有真正的硬件编译器吗？（HLS的就不说了

Verilator、VCS这类的，只是要仿真，不是直接为了优化而来的；综合器则太底层了，指望它产生什么信息帮助AI判断呢？

只有CIRCT目前把硬件设计当成可编程语义对象来尝试，它可能具备这样的潜力，真正将硬件设计软件方法化。

关键在于建设一种基础设施，将硬件设计规则转化为语法的基础设施，并且要有足够的反馈。

说到规则，就不得不提BSV，这可太他妈规则了，可是不够优化。

唔，怎么又走回bsv，我到底在写什么玩意儿。

我知道了，如果我想要的是规则化地描述，那么我实际上要的是一种所谓的逻辑综合，似乎是这样的东西。

到这里果然超出能力范围了。说到底我没什么能力，由此导致产生的想法也大部分不能实现。甚至因为想法不能实现而怀疑想法是否正确，这是错误的循环。

回归问题#

那么这就是说，这归根结底是并发语义规则调度的问题。

果然又回到了这里。啊啊。你妈的为什么，虽然可以理解就是了。

那么就到此为止吧。今后读研如果有机会的话，会继续的。