Timing model V4#562
Conversation
There was a problem hiding this comment.
I saw you have included the repo of the f4fpga_sdf_timing. See whether we can install that instead. I personally like Lark as the parser, as it is clean and pleasant to use, but building the SDF grammar again is probably a waste of time. If there is a strong desire or the parsing becomes the bottleneck, we can move on later.
Also, the whole timing_model should go under the fabric_cad folder.
|
Regarding to Parsing is not the bottleneck its only done once per Tile and takes around 3s. |
|
Instead of embedding it directly, we could fork it and publish it ourselves with the necessary fixes. Alternatively, you can embed it as a subrepo. Any thoughts @EverythingElseWasAlreadyTaken |
Yes, we should do a fork and maintain it separately. If it's only a python script, we don't even need a subrepo, you can just use it as dependency and specify the git link. |
|
I've created a fork here: Please do a PR there. |
Okay. So its only a python script three, four files. |
9994d0e to
8189422
Compare
79927a4 to
9994d0e
Compare
9994d0e to
46acac9
Compare
|
I rebased it to main. |
|
I have forked https://github.com/FPGA-Research/f4pga-sdf-timing. Can you update to do repo-based install (doc)? Include fixes that you need. I have also done a lark version for fun https://github.com/KelvinChung2000/sdf-timing-lark. |
So i could also use the lark version have you included my changes there? |
The Lark version is with the fixes. If you do decide to go with the Lark version, do a bit more testing. Otherwise just copy your fixes to the F4PGA SDF fork. |
yes i will do it. |
Also your lark version has the exactly the same interface right? |
|
One general Question: So the GDS flow works now by auto detecting But what should i do to point to the correct hash Do i have to do something like: |
|
If you don't specify the PDK, you basically don't get the GDS flow. Also, the auto detect will auto-enable the PDK. You should not need to use the hash at all since ciel will have a symbolic link that links to the current active PDK. So |
mole99
left a comment
There was a problem hiding this comment.
Thanks to the latest patches, the timing model can now be created for the Tiny Tapeout fabric 🎉
To get this to work with my LibreLane plugin and the "tiny" tile library, I had to copy some files to different locations in order for the flow to succeed.
I would appreciate it if the timing model generator did not assume the location of the files, but instead used absolute paths.
This can be achieved by passing a dict with all the file paths for each tile to FABulousTimingModelInterface:
sources = {
"LUT4AB": {
"rtl": [
"path/to/LUT4AB.v",
"path/to/LUT4AB_switch_matrix.v",
"path/to/LUT4AB_ConfigMem.v",
"path/to/primitives.v",
"path/to/models.v",
],
"spef": "path/to/nom/LUT4AB.nom.spef",
"nl": "path/to/LUT4AB.nl.v",
}
...
}You would specify the RTL/SPEF/NL files in fabulous_api.py, and I can do the same in my LibreLane plugin.
This also allows us to change the interconnect corner (nom/min/max) of the SPEF.
Another benefit is that this method only reads the RTL needed for the current tile. Previously, all the RTL for all tiles would be read.
I could do that. |
|
@hausdinge Great! You can still have the same behavior with FABulous CLI. But instead of searching for the files inside of the timing model generator, you do it outside. The idea is that you remove these things from the generator: # Find all the Verilog files for the tile, excluding certain
# directories that are not relevant for synthesis.
exclude_dir_patterns: list[str] = ["macro", "user_design", "Test"]
self.verilog_files: list[Path] = self._find_matching_files(
self.tm_config.project_dir, r".*\.v$", exclude_dir_patterns
)And move them outside to This is not a feature that needs to be exposed to the user. My LibreLane plugin calls the FABulous functions directly, meaning I can pass the file paths to |
Ah okay. {
"project_dir": "/home/timing_model_v4/FABulous/demo_mpw5",
"liberty_files": "./demo_mpw5/sky130_fd_sc_hd__tt_025C_1v80.lib",
"min_buf_cell_and_ports": "sky130_fd_sc_hd__buf_1 A X",
"synth_executable": "/nix/store//bin/yosys",
"sta_executable": "/nix/store/744j2gyd0s7pvww7nm1fw7z9500bh8y5-opensta/bin/sta",
"techmap_files": ["./demo_mpw5/latch_map.v", "./demo_mpw5/tribuff_map.v"],
"tiehi_cell_and_port": null,
"tielo_cell_and_port": null,
"custom_per_tile_source_files": {
"RAM_IO": {
"netlist_file": "./demo_mpw5/Tile/RAM_IO/phys/RAM_IO.v",
"rc_file": "./demo_mpw5/Tile/RAM_IO/phys/RAM_IO.spef",
"rtl_files": [
"./demo_mpw5/Tile/RAM_IO/RAM_IO.v",
"./demo_mpw5/Tile/RAM_IO/RAM_IO_switch_matrix.v",
"./demo_mpw5/Tile/RAM_IO/RAM_IO_ConfigMem.v",
"./demo_mpw5/Tile/RAM_IO/OutPass4_frame_config_mux.v",
"./demo_mpw5/Tile/RAM_IO/InPass4_frame_config_mux.v",
"./demo_mpw5/Tile/RAM_IO/Config_access.v",
"./demo_mpw5/Fabric/models_pack.v"
]
}, ...So every entry overwrites the default paths in the project dir. |
mole99
left a comment
There was a problem hiding this comment.
I've updated my LibreLane plugin to specify the paths, and it works without any problems!
Thanks for implementing the changes, @hausdinge.
There was a problem hiding this comment.
Overall looks good, just a few minor comments.
Would be nice if your test cases could get at least some basic comments.
Also, please rebase when #655 is merged and run pre-commit again.
There are quite a few formatting / lining issues, that will be fixed with this.
Also, there are still quite some open/unresolved comments from others , that might need further discussion.
fix: lint issues and doc strings
|
When i did the commit, pre-commit hooks All the errors for all files can only be seen by typing: |
|
Because by default, it only checks the files that need committing. |
Makes sense. It was just here an issue since pre-commit was not |
fix: timing model tests for pre-commit
09dba97
into
FPGA-Research:main
This is the new timing model.
Its mostly done and the interface wont change much anymore.
Still i want to polish it and add some minor improvements and optimizations.