What are the FlowTracer Barriers?

A design flow is usually triggered by timestamps on files. Whenever a timestamp changes, FlowTracer assumes that the data in the file has changed and hence all jobs consuming the file will become invalid and need to rerun.

In some cases, however, an input file may change, but in a way that does not change the result of a job that uses the file. For example, if an engineer adds or modifies comments in a configuration file that controls a place-and-route job. Such a job could take hours to days to complete, and it would be wasteful to re-do it just because of the comment changes.

In order to avoid re-running those jobs with insignificant input changes, FlowTracer provides a barrier. The barrier incorporates a comparison between the new output of a job and the previous one. This can either be a predefined comparison (md5sum) or a custom comparison, for instance involving sed commands to strip comments and then diff. The jobs consuming this barrier output are not rerun when the output is the same according to the comparison function. 

On a very high level, you can think of a barrier as a way to change this behavior. Instead of checking
the timestamp, you can supply custom functions to determine if a file is still valid. It can compute the md5sum of a file and compare it against the previous md5sum. It can also strip all whitespaces and comments from a file before comparing it.

A barrier also stops promoting an invalidation. The file difference is only computed when the
file with the barrier has been recreated. This is the main reason why it's called a barrier.


 

Did you find this article helpful?