What will you do?
We will extend the Allo programming model to represent stateful hardware accelerators. Allo is a Python-embedded Domain Specific Language capable of both designing and programming hardware accelerators. Allo has attractive features as a hardware description language, such as productivity and modularity, but currently the hardware it models is stateless, i.e., the driver cannot assume a persistent state across invocations. This critically limits the practicality of Allo, since many accelerators are stateful. For instance, we need the state of partial sum, to compute dot products of large vectors using a smaller, fixed-sized dot product accelerator. Hence, our project will be a critical bridge to model practical ASICs in Allo.
How will you do it?
We will implement the notion of state in Allo programming model, by extending Allo types, Allo IR, and the backend codegen targeting Vitis HLS. Concretely, we will add the followings. First, prev(n) field to Allo types to store past states (history) and access one of them. Second, using MLIR features to represent global variables to extend the Allo IR for stateful objects. Lastly, the lowering pass to Vitis HLS, targeting the static keyword in Vitis HLS to implement the state at the actual hardware level.
Our current task is to develop tractable HLS designs, more detailed weekly roadmap to implement all components and division of labor. We plan to deliver the exact code-level targets by EOD Nov 11.
How will you empirically measure success?
We will concretely scope our target hardware in 3 milestones: scalar accumulator, vector accumulator, then something more practical (TBD, for instance outer-product GEMM engine or the dot product engine; we'll define a case which involves more past states and achievable with Vitis HLS). We will build target representation in HLS first, verify the design with the target invocation scenario in a simulation or on a FPGA board (to check the design is not absurdly inefficient), before we decide to target that.
We will implement by extending the existing Allo and MLIR infrastructure. We will unit-test the type to IR pass and IR to Vitis HLS passes utilizing the existing infrastructure as well.
We will evaluate our progress in a weekly basis to make adjustments.
Team members:
@Fangtangtang
As we discussed with Prof. Sampson, we are doing this for another course project as well (ece6775). There are 3 other students in that project team, and we'll clarify the individual contributions in both our roadmap due Nov 11 and the final deliverables, as necessary.
What will you do?
We will extend the Allo programming model to represent stateful hardware accelerators. Allo is a Python-embedded Domain Specific Language capable of both designing and programming hardware accelerators. Allo has attractive features as a hardware description language, such as productivity and modularity, but currently the hardware it models is stateless, i.e., the driver cannot assume a persistent state across invocations. This critically limits the practicality of Allo, since many accelerators are stateful. For instance, we need the state of partial sum, to compute dot products of large vectors using a smaller, fixed-sized dot product accelerator. Hence, our project will be a critical bridge to model practical ASICs in Allo.
How will you do it?
We will implement the notion of state in Allo programming model, by extending Allo types, Allo IR, and the backend codegen targeting Vitis HLS. Concretely, we will add the followings. First, prev(n) field to Allo types to store past states (history) and access one of them. Second, using MLIR features to represent global variables to extend the Allo IR for stateful objects. Lastly, the lowering pass to Vitis HLS, targeting the static keyword in Vitis HLS to implement the state at the actual hardware level.
Our current task is to develop tractable HLS designs, more detailed weekly roadmap to implement all components and division of labor. We plan to deliver the exact code-level targets by EOD Nov 11.
How will you empirically measure success?
We will concretely scope our target hardware in 3 milestones: scalar accumulator, vector accumulator, then something more practical (TBD, for instance outer-product GEMM engine or the dot product engine; we'll define a case which involves more past states and achievable with Vitis HLS). We will build target representation in HLS first, verify the design with the target invocation scenario in a simulation or on a FPGA board (to check the design is not absurdly inefficient), before we decide to target that.
We will implement by extending the existing Allo and MLIR infrastructure. We will unit-test the type to IR pass and IR to Vitis HLS passes utilizing the existing infrastructure as well.
We will evaluate our progress in a weekly basis to make adjustments.
Team members:
@Fangtangtang
As we discussed with Prof. Sampson, we are doing this for another course project as well (ece6775). There are 3 other students in that project team, and we'll clarify the individual contributions in both our roadmap due Nov 11 and the final deliverables, as necessary.