Clock-Signal | bus level | Emulator library

Any signal used as X'event and X= 1 or rising_edge.(X) will be treated by the synthesis tool as a clock.

In an FPGA that means the routing tool will try to assign a dedicated clock net to the signal, with all that it entails. e.g. the signal has to be routed to a dedicated clock input which can cause significant delay and skew against the other signals.

Also the signal had better be 'clean'. It means that a FF will clock if there is the tiniest spike on the signal. It also means that if your signal is not 'clean', some FFs may trigger and some may not.

The timing tool will need to know the period and high/low time and try to make the set-up and hold time work against all other clocks. This can cause major problems and/or extra logic in the design. If the signal is totally asynchronous against the other clocks you can have meta stability and may need to add synchronizers after the clocked register(s).

So it comes down to: it is strongly recommended to use only 'real' clock signals for the X'event and X= 1 or rising_edge.(X) constructs.

At the same time there is one rule in digital design which says: all rules are out if there is no other solution.

_{In the ASIC industry, where I come from, you had to talk to some senior designers before you broke the basic rules. Then you had to add some big emphasized comment around the code stating "Yes this breaks the rule but there was no other way because we had this and this and this and it has been reviewed and signed of by X and Y " And yes, I once used a latch in a design.}