Open dzemildzigal opened 3 months ago
Putting it out there that this issue is connected to issue 545 opened some time ago...
@davideschiavone I see you've originally pushed this feature, right?
The sv2v flow unfortunately is still not supported in the main branch - there is a PR that made it till the end of the flow https://github.com/esl-epfl/x-heep/pull/233 but this PR is far from being mergiable and as of today we do not have resources working on this topic - but feel free to help.
Most of the issues are into SystemVerilog interfaces and other things unsupported by SV2V.
Also, @christophmuellerorg is working on using the sv2v front end embedded into FuseSoc to target Yosys synthesis for FPGA which would also solve many issue but again, we are not working on it full time.
If you guys can help it would be nice
I'll see if I can allocate time to get this done. I've already got some of the things in line with that PR so I'll have to revisit this.
thanks a lot - I suggest you use the FuseSoc front end for sv2v @christophmuellerorg maybe can tell you how by copying here the .core target he wrote
Thanks @davideschiavone. I'll try the new .core as soon as it's made available by @christophmuellerorg :)
While going through the X-HEEP ASIC flow I can't seem to run the openroad-sky130 target and get GDS out. I have OpenROAD installed globally on my machine, oss cad suite and I've ran the installations locally as well as per the documents: https://x-heep.readthedocs.io/en/latest/How_to/ImplementASIC.html
I have all of the listed dependencies, installed globally, which is confirmed in the following:
And I've installed openroad locally into the x-heep/flow directory and we see that sv2v is also installed as
Anyways, having activated the correct environment (using Conda), and running make openroad-sky130 we get:
Now, starting to debug the errors out I see that the design.sv has a lot of things sv2v can't handle (things like ( async ), etc) so those things need to be manually taken out.
Later I saw, that there were connected signals to non-existing ports in various modules of the sources (we signal not existing in the obi_inst_req_t packed struct comes to mind but still being connected to obi_inst_req_t despite not existing in its port list) which fails the flow as well.
Changing
assign core_resp_o.wpt_match = 1'b0; // Will be set by upstream wpt-module within load_store_unit
and commenting it out completely inside of x-heep/hw/vendor/openhwgroup_cv32e40x/rtl/cv32e40x_mpu.sv because the flow fails because of it as well.Without going into any more details, I'm pretty sure the target for openroad-sky130 is not flushed out at all, since I've tried multiple approaches, culminating that I have started changing the sources to push the flow through. I would like to ask for some help, and hopefully, zipped sources from the authors where this target is verifiably going through so I can compare to my state and hopefully figure this out. I think this would be the best and fastest way I could debug my issue.
If my complaint is valid, this could be a possible ticket to be opened and this issue can be fixed.