As is common in hardware systems, most sub-modules do not complete on the same clock cycle. Therefore, if two modules (A and B) run parallel so that both output to a common third module (C), you must ensure A and B complete before attempting C. Do not AND the Done signals from A and B since they have little chance of happening on the same cycle; in that situation, the AND will block all Done signals. Instead, use the Sync object.
The SyncClr object will take as an input a list of Done signals and produce from those a single Done pulse when all the Done signals included in the list have fired. It returns a list of Busy signals formatted to the same list structure of Done signals coming in. You can use the ListOut objects to combine your signals for the Done and the ListIn objects to split the Busy signals.
Syncs are built into what is called a SyncRegClr, and SyncRegPair. SynchRegClrs are built into most top-level operators such as Add and Mul, which is why the variant Done and Busy nodes are on most top-level objects.
The $Mul_MinHW (Complex) provides a good example of Synchronizing objects.
Note the following:
· The Busy signals coming off the first group of parallel objects are OR’ed together and before output. That lets objects upstream know that at least one $Mul object is busy; therefore, you don't want their data at the moment. It's tempting to pack those into a list but you’ve only got one Go signal; there is no value in individual Busy signals in this case.
· Remember the Add and Sub have Sync objects built into them, which is why you can plug lists into the Go signals on them.
· Notice the Busy signals are split the same way the Done signals are combined.
· You will see the Sync object at the end. This forces both the Add and Sub to have completed before the data at P is ready. The incoming wait is plugged in there as well, forcing the Add and Sub to output the same data when high and forcing the whole object to propagate a stall.