-
Notifications
You must be signed in to change notification settings - Fork 52
Description
I am working on a new "Design Configuration" idea to move away from the current way HLSFactory does its design flow automation.
In the current approach, flows like HLS synthesis and implementation use specifically named TCL files assumed to be present in the root of a design directory as the entry point to be able to run. The user is responsible for implanting inside the TCL file the right commands needed for that partial flow, but the flows assume these files exist and call them using Vitis HLS to then run that flow.
Clearly, this approach is quite brittle and not applicable to other flows. This approach also doesn't address ways to store design metadata or even say for a given design which flows are supported or whether a design is abstract or concrete or only works with certain vendors or tools.
Therefore, the new design configuration approach tries to address this with each design having a single design configuration file in its root with all the design information, including design metadata, supported flows, and flow entry point information or flow parameter information. This approach is simpler with a single file the user really has to worry about when pointing over designs, and allows for extensibility in the future to support more flows and metadata. This also makes it easier and faster when adding new designs as we begin to scale that effort.
Currently, I am working toward a prototype that uses TOML as the file format and possibly Pydantic to parse and validate the data according to a schema as well as write design configuration files.
This is very much a work in progress, but it is planned to completely replace the current approach in the future.