how to constraint the gated clock in the Timequest？

what are the properties of a and b? are they both masked clocks or one is clock and the other - masking signal?

do you intend c to be edge aligned with a/b?

--- Quote Start ---

what are the properties of a and b? are they both masked clocks or one is clock and the other - masking signal?

do you intend c to be edge aligned with a/b?

--- Quote End ---

a and b are both not clock, they are the signals changed between 0 and 1,

the relationship between a and b are uncertain。

the FAQ of altera say i can use"generated clock"command to constraint the output of "and" gate,but i still didn't know how to do this.

If a and b are uncertain, which means the clock waveform at the output of c is uncertain, they TimeQuest (or Classic) won't be able to analyze this design.

For TimeQuest to be effective, you need to properly define the clock waveform characteristics. Even if you define two clocks in input a and b, TimeQuest will simply analyze a as if b does not exist, and b as if a does not exist, but it won't analyze the generated clock in c. In other words, without the proper clock waveform in c, TimeQuest will not do a proper setup and hold analysis.

--- Quote Start ---

If a and b are uncertain, which means the clock waveform at the output of c is uncertain, they TimeQuest (or Classic) won't be able to analyze this design.

For TimeQuest to be effective, you need to properly define the clock waveform characteristics. Even if you define two clocks in input a and b, TimeQuest will simply analyze a as if b does not exist, and b as if a does not exist, but it won't analyze the generated clock in c. In other words, without the proper clock waveform in c, TimeQuest will not do a proper setup and hold analysis.

--- Quote End ---

thanks, my design can work well, even if i don't constraint the c, but just some warnings when compliered.

maybe i will try this using DC, it supports gated clock constraint.

--- Quote Start ---

maybe i will try this using DC, it supports gated clock constraint.

--- Quote End ---

For simple reasons already explained by others, if you can't specify a timing relation between a and b input, no tool will be able to perform a timing analysis. You have to exepect glitches at c. If c is only clocking a single FF as in your example, there are probably no consequences for your design, otherwise you should be cautious.

As an additional remark: The problems brought on by such designs are typically more serious with rare timing violation events. You don't see them in a test, but the system reveals unreliable in operation at customer site.

--- Quote Start ---

For simple reasons already explained by others, if you can't specify a timing relation between a and b input, no tool will be able to perform a timing analysis. You have to exepect glitches at c. If c is only clocking a single FF as in your example, there are probably no consequences for your design, otherwise you should be cautious.

As an additional remark: The problems brought on by such designs are typically more serious with rare timing violation events. You don't see them in a test, but the system reveals unreliable in operation at customer site.

--- Quote End ---

Thank you for reminding, FvM!

In my design,just as you said,the c is only clocking a single FF.

when a or b changed, the "out" must flip,i don't know how to achive it except the way i posted.

--- Quote Start ---

when a or b changed, the "out" must flip,i don't know how to achive it except the way i posted.

--- Quote End ---

The behaviour is different, also without timing violations, cause it's an AND operation. So I don't know, if you intend the above coded or the descripted behaviour.

If a and b aren't too fast, synchronous processing based on sufficient fast system clock would be my favourite solution. Of course, an exact behavioural specification, also considering possible overlappping of both signals, must exist.

--- Quote Start ---

The behaviour is different, also without timing violations, cause it's an AND operation. So I don't know, if you intend the above coded or the descripted behaviour.

If a and b aren't too fast, synchronous processing based on sufficient fast system clock would be my favourite solution. Of course, an exact behavioural specification, also considering possible overlappping of both signals, must exist.

--- Quote End ---

i am sorry ,a and b is as fast as the system clock of my design, 50MHz, and even if a and b delay a period--20ns, this will be cause a control mistake, so i didn't know how to achive it.