byuccl / bfasst

Tools for FPGA Assurance Flows
Apache License 2.0
12 stars 5 forks source link

Re-adding Legacy Tools #399

Closed KeenanRileyFaulkner closed 4 months ago

KeenanRileyFaulkner commented 10 months ago

It would be nice to complete the transition of all legacy_flows to the new architecture using ninja, and then to remove the old run scripts, flows, and tools from the project. Priority was given to Reilly's tools and flows, but now that all of them are moved over, this could be more doable in the coming semester.

I would propose this transition is done in a set of smaller PRs, where each one is designed to transition over a single flow, and any necessary tools related to it.

It's worth noting that several of these flows including xilinx.py, conformal.py, and xilinx_and_reversed.py have been transitioned over, but the legacy code remains due to the nested nature of flows in the old architecture; it is helpful to remove depended-on flows only after all their dependents have been removed so that we can still run the old flows and see how they work.

KeenanRileyFaulkner commented 9 months ago

@jgoeders it looks like we recently removed run_design.py and run_experiment.py. Does this mean we are not going to support the above legacy flows any more and should just delete them too? It's difficult for me to transition these flows over without being able to run them on the old architecture to see how they work.

jgoeders commented 9 months ago

Let's leave the files for now. I would like to try and migrate those that we can. We can always check out an old commit of bfasst to compare how they run.

I assume we would need to get the icecube tools installed to run most of these flows and try them.

yonnorc42 commented 9 months ago

@KeenanRileyFaulkner run_design.py and run_experiment.py are still there. scripts/scripts_legacy/

yonnorc42 commented 4 months ago

@jgoeders I was looking at moving the gather_impl_data flow over to the new architecture but I'm not sure how it would work. For example, during the flow, it runs the icestorm reverse bitstream tool on netlists created from different synthesis tools, although they all come from the same design. Because of how ninja works, doesn't this mean that all the reversed netlists, except for the last one created, would be trampled?

jgoeders commented 4 months ago

By the name, it sounds like gather_impl_data is just gathering stats from the implementation of runs? If so, we can probably just skip this as we have newer ways of doing this. Since we aren't collecting data using the old legacy tools, this should be fine.