Generate VHDL or Verilog

[MichaelMcDonnell]

Have you considered adding an option to generate VHDL or Verilog from the hardware description?

[YJDoc2]

Hey, Thanks for your interest!

As of now it does not have any support for VHDL generation. It might be possible in future, but the problem would be that the processing logic of the chip is normal Rust code, so for porting that to HDL, this will need to parse it and then convert it accordingly to HDL. I'm not sure how that can be done without essentially having to write a VHDL backend for LLVM IR or substantially restricting what can be done in the processing function, so parsing it and converting it to HDLs is easy.

I don't have any other ideas right now for how this can be achieved, but would be interested to hear if you have any suggestions.

Thanks :)

[MichaelMcDonnell]

Thanks for responding! It does sound like a lot of work but would be great to have. Maybe there's a student out there who could do it as a thesis?

Maybe rust-gpu could be used as a starting point? They say they're using the "rustc compiler backend to generate SPIR-V, plugging in via -Z codegen-backend".

[YJDoc2]

Hey, Thanks!

Maybe rust-gpu could be used as a starting point? They say they're using the "rustc compiler backend to generate SPIR-V, plugging in via -Z codegen-backend".

This seems a good point to start looking, thanks for pointing me to that!

I myself am interested in seeing if this can generate VHDL, as that would be really useful and cool, but also, that would be a proportionally big task to be done, so the progress, if any will be slow 😅

Another thing is that this is pretty new library in itself. Even though I have tried my best to make sure it works, the best way would be people actually using it and seeing if this does solve their use cases. For example, currently there is no way to specify if something is edge or level triggered, or to specify different clock frequencies. As someone had suggested there can be a fixed sensible-default for everything, and an option to override it if needed ; or not consider that at all, and have only one way to do things. I feel the best way to judge would be seeing how this is used. Otherwise, finalizing how something generates VHDL and later finding out there is some issue with it can be problematic to back-resolve.

So I might be looking at how the generation can be done, but it will mostly progress at a slow pace, if at all 😅

Irrespective, Thanks a lot for your insights :)

[MichaelMcDonnell]

You're welcome! And thanks for releasing your project as open source! I look forward to seeing the progress over the next couple of years :-)

[YJDoc2]

I finally got to check the codegen of rust-gpu in a bit more detail, and on giving it more thoughts, I do not think going that way would be much useful for generating vhdl from this. The primary reason is that such backend would be run on a complete project and would be expected to compile it to target as a whole crate. However, we do not want that, we only want to convert the pcb code to vhdl. Which means we only need to "compile" the pcb-specific stuff . If we go on the codegen route, we will need to account for all possible things that rust (as a language) can throw at the compiler and handle them, wither by ignoring it or something.

What we want to actually do is on-demand(?) compile the pcb macro generated structs and its tick method to its vhdl/verilog compatible format, and save that as respective files. As far as I have considered, this cannot be done as a cargo/rust target, and would be a method, somewhat like pcb.compile_to_vhdl("root_path_for_generated_files");. This will run as a part of the binary, and would generate the files. Not particularly friendly, but this is primarily a simulation library, so I guess ok-ish.

This would, in some sense simplify the implementation considerably, as we need to generate the compiled stuff at the macro level, in the same way we are generating the impls, and when called the compile function on any pcb, we can recursively call it on each components, maybe with passing a context struct, so that each unique component will generate its own vhdl file, and link/import them as needed according to vhdl / verilog convention. This will be basically a reduced-scope compiler, just for pcb stuff.

Of course, the main thing here is the tick function, which currently is done completely as rust trait impl, and we do not have access as macro. As we will need to process that as well for generating vhdl, we will need get access to that and inevitably to restrict what can be done in it : for eg, currently we can store any Rust type (including Fn trait) as the pcb struct member, and use anything that is valid Rust in tick function. However, we will not be able to "compile" all that to vhdl, and thus will need to restrict what can be done in such function.

One way is to use cargo-features , so that instead of modifying tick, we add another method, and ask user to implement the tick functionality they want in some custom language, if the feature is enabled. Then this will be parsed/compiled and used for generating vhdl, eg

#[cfg(vhdl-gen)]
vhdl_logic!(MyPcb,{
// logic in some custom language 
this.a = this.b + this.c;
});

This will restrict what operations are permitted, and we can add another macro-param to skip un-supported structs members in vhdl generation. That way we can use full power of rust including debugging and all other bells-and-whistles for tick logic, and use restricted functionality in vhdl. This would mean user would have to write the logic twice, once for tick and once in our custom lang. However, we can provide another macro which will generate rust code and vhdl code/ custom lang, provided the logic fits the restrictions.

I still have some more ideas which I will think on and update in this issue.

NOTE : I haven't really seen anyone using this library, so I will be doing anything here in my spare time as I can. If anyone is actually using this , even for hobby projects, and want to help/ interested in this vhdl issue, feel free to comment, add ideas/suggestions, open issues etc. I would like to hear if you are using this library!