Build firrtl simulator by related components

[itviewer]

Implement all Primitive Operations in Firrtl spec Then we can parse firrtl, dynamically build the circuit by components, then we can simulate the firrtl circuit. How do you think it?

[mortbopet]

Coupling VSRTL with some other HDL; preferably an IR like Firrtl has been on the roadmap for a while, so I think it would be a very exciting undertaking.

Implementing the primitive operations of Firrtl should be no big task, given that most of the capability is already within the components of VSRTL Core. The VSRTL Core layer relies on templating most components for defining ie. port widths which has been a helpful feature in detecting circuit bugs at compile time - Ie. this functionality can detect port size mismatches between connected ports at compile time.

However, this obviously also limits us when trying to dynamically instante components. So we would either have to modify VSRTL Core to not use templated ports, or we may create a new VSRTL backend solely dedicated for simulating Firrtl circuits, wherein port sizes are dynamically defined. Personally, I'd be more inclined to make port-sizing a runtime definition (as in, modify VSRTL Core) and forego the compile time check for a runtime check of port compatability.

I think the larger (non-trivial) task is to perform the actual circuit building wrt. remainder of the Firrtl spec. As in, inferring registers and memories - and ofcourse parsing the spec itself. I guess one could come up with a quick prototype to test the idea, using https://github.com/SiliconSemantics/firrtlator

[itviewer]

Thank you for the reminder about template ports. Regarding the parsing of the firrtl file, I don't know about the firrtlator project before, I will study it further.

However, since we have firrtl antlr4 grammar definition, antlr4 can automatically generate code that parses the file into an abstract syntax tree. so I think build a simple c++ version firrtl parser is not too difficult.(I have use the antlr4 java target to develop a firrtl Intellij plugin). the generated code provide us with a Visitor which we can traverse the circuit or tree.

So, do you have any plans to refactor VSRTL Core recently? I don’t know how much work it will takes. while I really want to build a firrtl simulator right away!:smile:

[mortbopet]

Cool! Well, given that you've authored that plugin, i assume you already know your way around Firrtl and ANTRL better than I, so i'll focus on the VSRTL-core aspects.

Currently i am a bit pressed for time wrt. other obligations, but those should be taken care of at the latest the 9th of June. Which then frees up a bit of time for development. I will try to get a prototype running of dynamically instantiated VSRTL circuits as soon as possible, and let you know when i have an example for you to try out and base your work off of.

[itviewer]

Thank you very much! now I will take the time to dive into the firrtlator project or directly use ANTRL to implement a simple firrtl parser, so that I can integrate with your work later.

[mortbopet]

So - I couldn't help my self and gave it a quick shot to see how bad a refactoring would be. And it turned out to not be as bad as i thought!

You can find the prototype on this branch - that will be the development branch on my part. I only added a few operators, but it should be enough to be able to get started on your end. For an example dynamically specified circuit, see the app.cpp file. The VSRTL UI compiles and simulates the circuit as expected.

Also, a bit unrelated but it might be relevant in your testing; I know that there is a bug in the code for detecting combinational loops so please be vary if (dynamically) trying to instantiate such a design. Ofcourse, that is something that should be looked at aswell at some point.

[itviewer]

The basic work of file parsing has been done, see fircpp. I am now trying to convert the parsed AST into a scala-like IR representation.

After learning more about VSRTL, I think some things may need to be reconsidered. It's just my immature idea:

• temporarily focus on simulation and waveform, rather than circuit visualization (may be long-term consideration)
• explore whether we can use this project as the basic data type of the simulator instead of c++ original int
• improve simulation capabilities, such as asynchronous reset, multiple clocks, pure combinational logic, multi-threaded simulation, etc.

maybe we need a dedicated firrtl simulation engine based on the spec.

[mortbopet]

I fully agree with, that if we are to support the full spec and capabilities of firrtl then VSRTL Core has quite a way to go. Until now, I've mainly been developing the capabilities of VSRTL Core to suit what i needed for Ripes and so some of the more elaborate simulation features have yet to be needed.

Ideally we should be able to leverage a preexisting firrtl simulator (does there exist any good multithreaded C++ implementation?), fork it and modify it to fulfill the requirements of being a simulator backend for VSRTL. If there does not, then we should consider whether to extend VSRTL Core or use the lessons learnt there as the basis of a new simulator backend (which could be a separate project from VSRTL).

With regards to the use of firrtl-sig i foresee that we would run in to the same issue as what was just fixed with regards to templated ports in VSRTL - namely that signal widths are compile-time defined. If we want to be able to dynamically load and construct circuits then we, as far as i see it, must not have compile-time defined signal widths. However, we should be able to fork the project and make signal width a constructor parameter - then it would be very applicable to use as the base simulator datatype.

In any case, while evaluating what to do in terms of long-term simulator/VSRTL backend development, i think that the operators implemented so far in VSRTL should be sufficient to get some reasonable prototyping underway, in terms of creating an initial flow from firrtl IR to a visual simulator. I've added various additional operators on the dynamic_circuits branch.