I have following logic in the designalways @(posedge clkA, posedge clkB) begin if (clkB) //this is like chip select line so it is not nearly as fast as clkA resetAllSignals() else doTheWork The design worked well in a certain environment, but when moved to another environment where clkB input is coming from a new device I am seeing funky stuff. To be more precise I can see on the scope the situation in which clkB goes high but the logic executes doTheWork part. clkA is not changing when this is happening. I am no signal expert and am wondering is it OK to use clkB to clock the logic and make a decision what will logic do? If this is OK any idea on why this might be happening? Thanks Ogi
If it is a clock - then no, its not a good idea.If clkB is really slow compared to clkA, then you may be able to get away with it if you treat it as an asynchronous signal, so you synchronise it to ClkA properly, it should be ok.
Hi Tricky,Thank you for your response. Could you please elaborate, or point me to the article that explains it, why is it not a good idea? People will ask me why for sure :). The thing is that the clkB in this case is chip select line so it has to be low before clkA will be turned on for data transfer (regular SPI protocol) so it is not possible to sync clkB with clkA. Thanks Ogi
As this is an SPI protocol, then it is usually much easier to treat clkA as any other logic signal and sample it at a much higher frequency. The Clock_enable is not in any way a clock, so should not be treated as a clock.