PSoC5LP: How to clean up Warning-1350: Asynchronous Path

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

Hey All,

I have a warning that's suddenly cropping up in a design and I'm hoping I can get some input as to why exactly it is occurring and hopefully how to clear it up.

I have some custom logic to dictate the behavior of a "Fault LED" as well as a status register using a PSoC5LP (CY8C5667AXI-LP040).  The internal logic schematic is below:

KyTr_1955226_1-1659450201654.png

The idea is that I have a FAULT_STAT register to see in firmware which faults have occurred, and a LED connected to FAULT_LED that is sticky so that if any fault occurs the LED will turn ON an remain ON until a power cycle/reset occurs.  Any of the faults firing will cause a rising edge on the DFF and turn FAULT_LED high.

With this setup, I receive the following on build:

Warning-1350: Asynchronous path(s) exist from "FAULT_A(0)_PAD" to "KpdClk".

Warning-1350: Asynchronous path(s) exist from "FAULT_B(0)_PAD" to "KpdClk".

I'm not sure why this is being thrown.  KpdClk is a 100Hz clock I am using mainly as a clock for the status registers that read in an external keypad.  I am also using it in a few other spots such as an Edge Detector and as the source clock for a single-shot timer elsewhere in the design that should have no bearing on the issue here.

KyTr_1955226_2-1659450392097.png

I guess I'm confused as to why this is an issue with FAULT_A and FAULT_B specifically.  My first thought was maybe something about how I have these two signals controlling the CLK line of the DFF, but BN_FAULT is similarly connected as a way of controlling the DFF CLK, but the warning is not thrown for this pin.  I guess I just am not seeing how FAULT_A and FAULT_B can have any relation to KpdClk, but BN_FAULT does not?

Here's a snippet info pulled from the Static Timing Analysis Document:

KyTr_1955226_4-1659450766182.png

KyTr_1955226_3-1659450745608.png

 

So what's actually going on here and how would I go about clearing up this warning?  I can't share the entire project, but I can provide more details as necessary, if necessary.

Thanks!

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Kyle,

Virtually all logic is derived from UDBs.   UDBs are clocked off the MASTER_CLK.

The Clock KpdClk you assigned is 100 Hz.   The PSoC Clock dividers are only capable of up to 65536 as a division.

With the BUS_CLK or MASTER_CLK at 24MHz, it would take a divider of 240000 to obtain 100 Hz.  This is not possible.

There is a good chance that your 100 Hz clock was generated from ILO.  Therefore the ILO derived clock is Asynchronous to the MASTER_CLK used by the UDB for the logic gates and the FAULT_STAT status register (part of a UDB).

The Asynch warning is there in case if the design will have a problem with "metastable" conditions with clocked logic.  During a metastable condition either the setup or hold times to the clock edge are not enough to guarantee a stable input.   In this case, the output might oscillate a few times for a very short time.

Fixes:

  • Use a SYNC component between KpdClk and the input lock of FAULT_STAT.
  • Generate KpdClk by
    • generating a a clock frequency at 24KHz.  (ie div by 1000)
    • using a Freq_Div component place the 24KHz output from above as the clock input.  Set the divider to 240.  Total divider = 240000.
  • Ignore the Async warning.  This is a warning.  It might be true that your design does not have an issue with a metastable oscillation.  Since your design is using a Status register. there is a better than good chance the outputs should be stabilized by the time the CPU reads it.
Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

6 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Kyle,

Virtually all logic is derived from UDBs.   UDBs are clocked off the MASTER_CLK.

The Clock KpdClk you assigned is 100 Hz.   The PSoC Clock dividers are only capable of up to 65536 as a division.

With the BUS_CLK or MASTER_CLK at 24MHz, it would take a divider of 240000 to obtain 100 Hz.  This is not possible.

There is a good chance that your 100 Hz clock was generated from ILO.  Therefore the ILO derived clock is Asynchronous to the MASTER_CLK used by the UDB for the logic gates and the FAULT_STAT status register (part of a UDB).

The Asynch warning is there in case if the design will have a problem with "metastable" conditions with clocked logic.  During a metastable condition either the setup or hold times to the clock edge are not enough to guarantee a stable input.   In this case, the output might oscillate a few times for a very short time.

Fixes:

  • Use a SYNC component between KpdClk and the input lock of FAULT_STAT.
  • Generate KpdClk by
    • generating a a clock frequency at 24KHz.  (ie div by 1000)
    • using a Freq_Div component place the 24KHz output from above as the clock input.  Set the divider to 240.  Total divider = 240000.
  • Ignore the Async warning.  This is a warning.  It might be true that your design does not have an issue with a metastable oscillation.  Since your design is using a Status register. there is a better than good chance the outputs should be stabilized by the time the CPU reads it.
Len
"Engineering is an Art. The Art of Compromise."

Hi Len,

Thank you for the explanation.  I did try the second suggestion, setting the KpdClk frequency to 24KHz (As well as ensuring it is derived from MASTER_CLK), and running it through a Frequency Divider set to 240 to get my kpd_clk signal.  A advantage to this is that my 100Hz clock is actually now more accurate than if I was gating it from ILO.

KyTr_1955226_1-1659535755310.png

 

Unfortunately this did not clear up the Warning-1350, but like you said it's unlikely that it would be an actual problem.  However I still would like to clear it up if possible.

I will note that previously I was running FAULT_A and FAULT_B through a Debouncer before entering any of the logic gates.  We found in testing that the FAULT signals do not bounce and are actually quite stable on their transitions so I removed the debouncer.  This is when the 1350 Warning began cropping up, which makes sense since presumably the debouncer was doing the syncing for me.

I am curious with this explanation though, BN_FAULT is going through a nearly identical path.  I don't see how it would be throwing a 1350 Warning on both FAULT_A and FAULT_B, but not for BN_FAULT.  Perhaps because it is entering into the AND gate with a signal originating from a Control Register before entering the status register?  FAULT_A and FAULT_B by contrast are entering into their AND gates with a signal derived entirely from other logic (a homemade rising edge delay, which does use kpd_clk)  The signal running off the top of the image below goes to the input of the AND gates for FAULT_A and FAULT_B:

KyTr_1955226_0-1659534967568.png

The reasoning to have this is that the FAULT signals are not actually valid until this other "Rail Enable" signal has been high for about 100ms.

Thank you again for the help!

0 Likes
lock attach
Attachments are accessible only for community members.

Kyle,

I tried to reproduce your warning with the info you provided in the original post.

I get NO warnings.

I'm missing something in your configuration.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hmm,

After some experimenting it seems to be tied to the status register setting.  Setting bits to Sticky produces the warning for those signals, while setting to Transparent quiets it down.

Looking at the datasheet schematic:

KyTr_1955226_0-1659543017549.png

 

I think it's basically saying the clear on read can happen async to the actual status register clock signal?  Or am I misunderstanding?

 

In any event, it shouldn't present a problem I don't think?

0 Likes

Kyle,

Setting the FAULT_STAT to sticky I reproduced your issue.

Now try this:

  • Set FAULT_A, FAULT_B and BN_FAULT Input to "Double-Sync".  This solves the Warning.
    Len_CONSULTRON_0-1659545935246.png

     

Len
"Engineering is an Art. The Art of Compromise."

Aha!  That does the trick!

I'll mark your first response as the solution, as it's the most comprehensive information on exactly what was going on.

Thanks again for the help!

0 Likes