OpenTitan support #1442
Comments
|
I've tried to lint the It seems that the The I need to double check that against the version of @rw1nkler For now try applying this patch to |
Utilization reportHere you can find vivado utilization report: OpenTitan burndown listHere is the short burndown list for OpenTitan:
It will be good to optimize lookahead generation. Currently, it requires more than 10h to complete the computation. This slows down the working process since every change in architecture or in the tools requires lookahead recomputing. Changes in the OpenTitan designHere is the list of changes introduced for OpenTitan:
Soon I will update the issue with the diff file with all the introduced changes. Current workCurrently, we are in the step of |
|
Currently, the OpenTitan design can be routed with the changes introduced in:
However, the routing process consumes about 90Gb of RAM. The SymbiFlow failes on the frames step with the following error: |
|
I encountered the same error in libxml described above, "Error in xpath expression", at the same place in vpr_io_place.py. It was a large design -- a version of scalable_proc with N=100. I ran into the same xml issue also in vpr_place_constraints.py at line 48: |
Routing issuesAfter reducing the design frequency to 25MHz, I was able to generate bitstream of EarlGrey design that works on hardware. I used old The bitstream was successfully generated using the Here is the table with information about the router iterations: I wanted to rebase the code on the current master but the routing parameters are much worse. Here is the routing table for the design rebased on (5267e78). The most significant change is the routing quality is visible in the critical path delay which increases by Now I am trying to find the commit that breaks the routing process. I'm using Additional informationPlacement problemsRebasing on the (a1f0153) causes the problem with the design placement: The mentioned commit contains a new Yosys version introduced in 206bd56. That is the only change in the flow since (5267e78) passes the placement step. RAM usageAll VPR runs for EarlGrey design consumes a lot of RAM memory. Part of that is related to the size of the routing graph: Nevertheless, a huge amount of RAM (~80GB) and time (~43min) is used for the This has a huge impact on the time required for the tests since the |
|
FYI @litghost |
|
The source code used for the bitstream generation is available in #1590.
and the CLK_HROW_BOT_R bits obtained in: Once the #1419 is accepted, all the required modifications for the EarlGrey bitstream generation will be on the master branch. The only problem now is the routing issue described above. |
|
I have an initial fix for the RAM explosion in verilog-to-routing/vtr-verilog-to-routing#1454 , which will hopefully be merged upstream. However, the RAM explosion usuallly accompanies an enormous runtime. Still working on that |
|
Yes, It works after applying the mentioned changes. Also, the routing is successful. |
|
The diff_fasm step is currently not passing. One issue related to PLLs has been resolved: The second issue is related to wrong constant nets handling in BUFGMUX in Yosys. The error is caused by manual changes to the code and can be fixed. I’m waiting for the bitstream generation here. |
|
@rw1nkler Any update on this? |
|
I believe that the CARRY4 modeling needs to be merged before submitting the PR with the OpenTitan test. |
|
For a concrete progress update on the CARRY4 fixes:
Once #1674 is green, I believe an OpenTitan PR could be added. I'm working on iterating #1673 and #1674 and fixes issues as they are found. |
Here is the branch with the current progress on OpenTitan support:
https://github.com/antmicro/symbiflow-arch-defs/tree/opentitan_earlgray
Currently, I'm struggling with the error in
vpr_io_place.py:However, the same XPath expression works for other designs like button or counter on nexys video. I think that the error is in the wrong
.netor.ebliffile itself. Maybe due to unsupported elements of the design or wrong import in previous importing scripts.The text was updated successfully, but these errors were encountered: