Closed natewise closed 2 years ago
Hi @natewise
Yes, this is expected, but there are workarounds. The reason is that the testbench displays each character from printf as it is received on the network, and it takes multiple simulation cycles, while the INFO messages are printed by the testbench/OS to completion instantaneously.
One workaround is to have all of the tiles synchronize before finishing. This means that the INFO statements will not run until all printfs are complete. That will help this specific case here. It may not generalize well to more complex scenarios.
Another alternative (one I've used) is to use bsg_print_hexadecimal to send a 32-bit value to the host and encode the same information that you're sending via bsg_printf. This is a single packet, which means it won't get spilt by the INFO statements. It ALSO works better for tracking progress in timing critical code without the (substantial) overhead of printf -- which is not your use case here, but hopefully will be in the long run
Another solution is to grab the same lock at the host interface that bsg_printf uses before sending the finish pkt
That's a good one, too.
I implemented the synchronization tactic used in the bsg_transpose example using bsg_barrier, and it worked great. Thanks for the others suggestions, I may need them potentially as the logic and needs of the script change!
So I have a simple program with this main function:
I'm using the pod_1x1_4X2Y machine with x,y=4,1. I've also set NUM_FINISH = $(shell expr $(bsg_tiles_X) \* $(bsg_tiles_Y) ) in my Makefile to get each tile to send it's own finish packet. The output gives the right information but it's all jumbled together in a confusing manner:
It looks like there might be some issue with bsg_printf when the system tries to print things at the same time. Any tips or workarounds would be appreciated