Why would you want to do that?
Is your i/p data signal that is connected to the clk pin toggling (even after long intervals)?
Think about the properties of a flip-flop and the role of the clock pin. A clock signal is just a special data signal. I think you have to put special timing constraints on that clk i/p of the flop.
Logically, no issue.
But almost EDA tools on Implementation or Place&Route steps will give a bad complain.
Clock signals to be treated as a special one and there are a set of rules for it to be sastified, not the same as data signals.
Thanks for your time.
I have a requirement of detecting the edge of my data signal. After detection, I never use that logic until a particular command is received.
For that purpose can I use that logic ? If yes, will it cause any STA violations ?
Doesn't sound like a meaningful timing specification. The important point is how the "data clock" edge is related to your design clock. If it's unrelated or potentially causing setup/hold violations, the FF output needs to be synchronized. If you can be sure that the FF output is never sampled near to the data clock edge, just cut the timing path. In any case, STA expects a clock definition for the data clock.
if your
* data signal high_time is more than your system clock cycle time and
* data signal low_time is more than your system clock cycle time
(= the requested timing specification)
--> Then use two simple DFF and an XOR gate.
This is the clean solution to detect edges, sychronized to your system clock.
it is usually considered bad practice. make sure there is no alternative and you absolutely need this behaviour. and then be prepared to write some SDCs.
Thanks for your time.
I have a requirement of detecting the edge of my data signal. After detection, I never use that logic until a particular command is received.
For that purpose can I use that logic ? If yes, will it cause any STA violations ?
Which clock signal generates your data signal ?
Is it synchronized with clock of detecting side ?
If they are synchronized, and the source clock is equal or slower than the destination one, you can always use edge detection circuit like as FvM said.
I have used a clock signal as data and data as clock while designing I2C block. It's a bad design practice, since we didn't have any other fast clock available so we had to use it. At our end it didn't create any problem but when we delivered it to customer, it created hold violations. Customer synthesized it at lower technology node. Then we proposed the 2 solutions
1. Adding redundant logic in the data path (to delay it)
2. Adding buffers in Placement
both the solutions worked.
Be careful when you going to design something like this.
Can you give us a waveform of behavior simulation including clocks and data of source and edge detecting signal ?
I can not understand only seeing text...