This is an incredibly difficult question to answer for a number of reasons. The Chisel community is attempting to unify on one concrete answer that is easy to understand. There are two main angles:
这是一个难以置信的难以回答的问题，原因有很多。凿子社区试图统一一个易于理解的具体答案。有两个主要角度：
- Improved productivity through new language features and availability of libraries
通过新的语言功能和库的可用性提高生产力
- Improved specialization due to the hardware-compiler structure
由于硬件编译器结构改进了专业化
Language Feature/Power Answer
语言功能/电源答案
Think about the following similar question, "What utility does Python provide over C?" A response indicating no utility would likely bring up the following points:
想想以下类似的问题，“Python在C上提供了什么实用程序？”指示没有实用程序的响应可能会引发以下几点：
- Everything I can write in C I can write in Python. Both have
for, while, etc. and the code I write looks the same: printf("hello\n") vs. print("hello")
我可以用C写的所有东西我都可以用Python写。两者都有 for 、 while 等，而且我写的代码看起来是一样的： printf("hello\n") vs. print("hello")
- C has features that Python doesn't like inline assembly
C具有Python不喜欢内联汇编的特性
- Both are Turing complete
两者都是图灵完备的
The problem with this line of reasoning is that it's ignoring the fact that Python provides new programming paradigms that allow you to be more productive:
这种推理方式的问题在于它忽略了Python提供了新的编程范式来提高工作效率的事实：
- Object oriented programming
- Functional programming 函数式编程
- Libraries 图书馆
In effect, Python can be viewed as a more powerful language from a design productivity and code reuse perspective. Language power is notoriously difficult to objectively evaluate. Paul Graham describes this as the "Blub Paradox" in his "Beating the Averages" essay. Graham's thesis is that an engineer proficient in a less powerful language cannot evaluate the utility of a more powerful language.
实际上，从设计生产力和代码重用的角度来看，Python可以被视为一种更强大的语言。众所周知，语言能力很难客观评估。Paul Graham在他的“击败平均值”文章中将此描述为“Blub悖论”。Graham的论点是，精通不太强大的语言的工程师无法评估更强大语言的实用性。
Put differently, the existence of the paradigms listed above does not force you to use them. Hence, it's entirely possible to write Python that looks and feels just like C (and use that for justification to dismiss Python altogether!).
换句话说，上面列出的范式的存在并不强迫您使用它们。因此，完全有可能编写看起来和感觉都像C的Python（并以此为理由完全忽略Python！）。
Chisel is a domain specific language (DSL) for describing hardware circuits embedded in Scala. By it's very nature, it provides equivalent constructs to Verilog like module, Input/Output, Reg, etc. Problematically for your question, this causes both the most basic Chisel examples to look exactly like Verilog and also allows people to write Chisel that looks just like Verilog. This is often used as an argument for dismissing Chisel in favor of Verilog. However, this is analogous to making programming language choice based on the structure of "Hello World" examples.
Chisel是一种特定领域的语言（DSL），用于描述嵌入在Scala中的硬件电路。就其本质而言，它为Verilog提供了等效的结构，例如 module 、 Input 、 Reg 等。对于您的问题，这会导致最基本的Chisel示例看起来与Verilog完全相似，并且还允许人们编写看起来像Verilog的Chisel。这通常被用作拒绝Chisel而支持Verilog的论点。然而，这类似于根据“Hello World”示例的结构进行编程语言选择。
That means that a better question is: "What can I build with Python that is insurmountably hard with C?"
这意味着一个更好的问题是：“我可以用Python构建什么用C无法克服的困难？”
Answering this question requires case studies and is (very quickly) out of the scope of "Hello World" comparisons. Consider building machine learning libraries in C vs. Python, e.g., "How would I build Tensorflow in C?" This would be incredibly difficult due to the abstractions that something like Tensorflow requires.
回答这个问题需要案例研究，并且（很快）超出了“Hello World”比较的范围。考虑用C和Python构建机器学习库，例如，“我将如何用C构建Tensorflow？”由于像Tensorflow这样的东西需要抽象，这将非常困难。
You can think about similar exemplar comparisons by looking at mature Chisel projects. Two prominent examples are Rocket-Chip and Diplomacy. The former is a generator of arbitrary System-on-Chip (SoC) designs. The latter is used by Rocket Chip to deal with the problem of parameter negotiation---in an arbitrary SoC I'd like to have the parameters of the N components I'm connecting together to be a function of what I'm connecting (e.g., address widths, internal logic, coherency protocol). Critically, both Rocket-Chip and Diplomacy can be used as libraries (with some difficulty that will be resolved in the future). Concretely, this means that a user is very close to being able to "just import a RISC-V microprocessor" in the same way that they "just import a graph library".
您可以通过查看成熟的Chisel项目来考虑类似的示例比较。两个突出的例子是Rocket-Chip和外交。前者是任意片上系统（SoC）设计的生成器。后者由Rocket Chip用于处理参数协商问题——在任意SoC中，我希望我正在连接的 N 组件的参数是我正在连接的内容的函数（例如，地址宽度、内部逻辑、一致性协议）。至关重要的是，Rocket-Chip和外交都可以用作库（有些困难将在未来解决）。具体来说，这意味着用户非常接近能够“只需导入RISC-V微处理器”，就像他们“只需导入图形库”一样。
Due to language feature/power coupled with library availability, the real utility metrics become:
由于语言特性/功能加上库可用性，真正的实用指标变成了：
- How many lines of code do I need to describe some component?
我需要多少行代码来描述某个组件？
- How powerful are the abstractions the language allows me to build?
该语言允许我构建的抽象有多强大？
- To what extent does the language enable code reuse?
该语言在多大程度上支持代码重用？
For unsupported constructs, like negative edge triggered things and asynchronous resets (both FIRRTL and Chisel now support asynchronous resets), Chisel always provides an escape hatch kludge via Verilog blackboxes. However, all of these are really just features looking for a developer.
对于不受支持的结构，如负边缘触发的东西和异步重置（FIRRTL和凿子现在都支持异步重置），凿子总是通过Verilog黑匣子提供逃生舱口拼凑。然而，所有这些实际上只是寻找开发人员的功能。
Hardware Compiler Answer
硬件编译器答案
Chisel forms part of a Hardware Compiler Framework that looks very much like LLVM applied to hardware generation. The Chisel-to-Verilog process forms part of a multi-stage compiler. The "Chisel stage/front-end" compiles Chisel to a circuit intermediate representation called FIRRTL (Flexible Intermediate Representation for RTL). "FIRRTL stage/mid-end" then optimizes FIRRTL and applies user-custom transformations. Finally the "Verilog stage/back-end" emits Verilog based on the optimized FIRRTL.
凿子构成了硬件编译器框架的一部分，看起来非常像应用于硬件生成的LLVM。凿子到Verilog过程构成了多级编译器的一部分。“凿子阶段/前端”将凿子编译成称为FIRRTL（RTL的灵活中间表示）的电路中间表示。“FIRRTL阶段/中端”然后优化FIRRTL并应用用户自定义转换。最后，“Verilog阶段/后端”基于优化的FIRRTL发出Verilog。
While subtle, this compiler structure enables the following things:
虽然很微妙，但这种编译器结构支持以下内容：
- The front-end and back-ends are decoupled meaning that other front-ends and back-ends can be written. A Verilog front-end exists through Yosys and other languages can directly target FIRRTL, e.g., Magma is it's own Chisel-like language in Python that can target FIRRTL. New front-ends get all the benefits of existing mid-end optimizations and available back-ends. New back-ends can also be written, e.g., a VHDL back-end just needs one motivated developer to write it.
前端和后端是解耦的，这意味着可以编写其他前端和后端。Verilog前端通过Yosys存在，其他语言可以直接针对FIRRTL，例如，Magma是它自己的Python中可以针对FIRRTL的类似凿子的语言。新的前端获得现有中端优化和可用后端的所有好处。也可以编写新的后端，例如，VHDL后端只需要一个积极的开发人员来编写它。
- The introduction of a circuit IR enables automated specialization/transformation of circuits. This has been exploited to transform circuits into FPGA optimized versions that run faster than unoptimized versions (Midas and FireSim), enable hardware breakpoints/assertions (Dessert), and to add run-time configurable fault injection capabilities (Chiffre). Doing these optimizations directly on the Verilog would be insurmountably complex and brittle.
电路IR的引入实现了电路的自动专业化/转换。这已被利用来将电路转换为比未优化版本（Midas和FireSim）运行得更快的FPGA优化版本，启用硬件断点/断言（甜点），并添加运行时可配置的故障注入功能（Chiffre）。直接在Verilog上进行这些优化将是不可逾越的复杂和脆弱。
From this perspective, the question is closer to "What utility does C++ and LLVM provide over manually written assembly language?"
从这个角度来看，问题更接近于“C++和LLVM比手动编写的汇编语言提供了什么实用程序？”
When discussing compilers, usually the question of Chisel (a hardware construction language) vs. high level synthesis (HLS) comes up. The differentiating factor here is that Chisel is still, fundamentally, a powerful language for describing circuits while HLS is a path for converting programs to circuits.
当讨论编译器时，通常会出现凿子（一种硬件构造语言）与高级综合（HLS）的问题。这里的区别因素是，从根本上说，凿子仍然是描述电路的强大语言，而HLS是将程序转换为电路的途径。
Conclusion 结论
Summarily, a better way of thinking about this question is, "What does Chisel enable beyond Verilog?" That's a difficult question without a pithy answer and requires comparing the set of programming paradigms both languages provide. Currently, and through my own experience, the best way to tackle this is to do deep dives on mature Chisel code bases and try to use it yourself (and withholding judgment for several months). The difficulty with these approaches is that this takes time. Additionally, the requisite skill sets for reading these code bases and making these types of judgments are not commonly prevalent in hardware engineers. Hardware engineers are usually very proficient with C, but may have never seen (in any depth) object oriented programming, functional programming, or written complex projects exploiting modern software engineering principles. This tends to set up biases where people are looking for reasons to dismiss Chisel (or similar languages) as opposed to reasons to use it.
简而言之，思考这个问题的更好方法是，“Chisel在Verilog之外实现了什么？”这是一个没有简洁答案的难题，需要比较两种语言提供的编程范式集。目前，根据我自己的经验，解决这个问题的最好方法是深入研究成熟的Chisel代码库，并尝试自己使用它（并在几个月内保留判断）。这些方法的困难在于这需要时间。此外，阅读这些代码库和做出这些类型的判断所需的技能在硬件工程师中并不普遍。硬件工程师通常非常精通C语言，但可能从未见过（在任何深度上）面向对象程序设计、函数式编程或利用现代软件工程原理编写的复杂项目。这往往会造成偏见，人们在寻找解雇凿子（或类似语言）的理由，而不是使用它的理由。
Further Reading 进一步阅读
