Busses and I/O ports often behave according to a protocol. Such protocols are usefully defined and checked using a formal method.
A bus monitor connects to the net-level bus. It is an instantiated component that looks like any other component. It can be left in for actual fabrication or, more typically, used only for simulation and removed for fabrication.
A bus monitor can keep statistics as well as detect protocol violations. It is useful to know how much data was transferred, as well as other figures, such as the average size of a data block or the percentage of time more than one initiator was contending for the bus.
Can it be synthesised from a formal spec ? Yes, the internals of the bus monitor can be normal RTL that was synthesised from the a formal specification. »www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/transactors and Bus Monitors
For safety violations the monitor can print out an error as soon as it is detected. However, liveness properties cannot be checked as cleanly during simulation: we can only check to see if they have occurred and the number of occurrences printed at the end of simulation. If a liveness property has been satisfied once, it is likely that it might happen infinitely often in the future.
In other words, a checker for a safety property will assert an error output as soon as the property is violated, whereas that for a liveness property will start off flagging an error that will go away once the property has been found to hold at least once.