cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
alexis_jp
Explorer
Explorer
811 Views
Registered: ‎09-10-2019

2019.2: Latches infinite slack and infered latches: is there any concerns?

Jump to solution

I'm using a latch with some comb logics before registering the value. The logic is correct, the simulation is correct, the logic seems correct in ILA but with some bit-flips happening.

During my investigation, I saw the slack reported from the LDCE's G pin to the FF is infinite.

image.png

1. I was expecting Vivado to raise an error if a latch is used and can't be analyzed for timing.

2. Why doesn't Vivado constraint with the data used at the D and G pins?

3. I have warnings saying I have inferred latches, should I be concerned about wrong timings for those? Should I really trust Vivado's timing analysis for those?

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
764 Views
Registered: ‎01-22-2015

@alexis_jp 

I can see from your previous posts that you’ve been told that latches are bad – and that you know latches are bad and that you try to avoid them.  So, I won’t give you that speech again.

I can appreciate your questions because Xilinx documentation does not really commit to this “latches are bad” philosophy – and I think they should.

Here is a circuit with a latch, LDCE, that we can talk about.
latch_circuit.jpg

Here’s my understanding of how Vivado handles the above circuit.

  1.  If the G-pin of the latch is driven by a signal/data then all timing paths into and out of the latch as unconstrained (ie. paths have infinite slack).  When a path is unconstrained, we cannot be sure that circuits on the path will operate properly.

  2. If the G-pin of the latch is driven by a clock then the timing paths into and out of the latch could be constrained if the latch clock is related to the clocks for registers that launch/capture data to/from the latch.  AR#56877 seems to support this claim that a latch with a clock input is sometimes timed correctly (ie. paths are constrained).

So, looking for unconstrained paths in your design is a way to determine whether your latch circuits are failing to operate properly.

As noted on page 24 of UG906, the Vivado IDE will by default report unconstrained paths.  However, you may have to use -report_unconstrained to get an unconstrained path report if you are using Tcl commands to report timing.

Now, to your questions:

  1. I was expecting Vivado to raise an error if a latch is used and can't be analyzed for timing.
    I would expect this also.  Perhaps Xilinx considers “unconstrained paths” to be sufficient warning.

  2. Why doesn't Vivado constraint with the data used at the D and G pins?
    Data at the D-pin is OK but data at the G-pin is not OK.  Data on the G-pin creates a strange scenario:  a data input, G-pin, is switching the data output, Q-pin, of the latch.  This is very different from the normal timing analysis relationship between clocks and data.  I suspect that Vivado timing analysis could be redesigned to handle this – but currently it seems unable.

  3. I have warnings saying I have inferred latches, should I be concerned about wrong timings for those? Should I really trust Vivado's timing analysis for those?
    I think you can trust timing for constrained paths into and out of latches.  You cannot trust timing for unconstrained paths into and out of latches.

Mark

View solution in original post

2 Replies
765 Views
Registered: ‎01-22-2015

@alexis_jp 

I can see from your previous posts that you’ve been told that latches are bad – and that you know latches are bad and that you try to avoid them.  So, I won’t give you that speech again.

I can appreciate your questions because Xilinx documentation does not really commit to this “latches are bad” philosophy – and I think they should.

Here is a circuit with a latch, LDCE, that we can talk about.
latch_circuit.jpg

Here’s my understanding of how Vivado handles the above circuit.

  1.  If the G-pin of the latch is driven by a signal/data then all timing paths into and out of the latch as unconstrained (ie. paths have infinite slack).  When a path is unconstrained, we cannot be sure that circuits on the path will operate properly.

  2. If the G-pin of the latch is driven by a clock then the timing paths into and out of the latch could be constrained if the latch clock is related to the clocks for registers that launch/capture data to/from the latch.  AR#56877 seems to support this claim that a latch with a clock input is sometimes timed correctly (ie. paths are constrained).

So, looking for unconstrained paths in your design is a way to determine whether your latch circuits are failing to operate properly.

As noted on page 24 of UG906, the Vivado IDE will by default report unconstrained paths.  However, you may have to use -report_unconstrained to get an unconstrained path report if you are using Tcl commands to report timing.

Now, to your questions:

  1. I was expecting Vivado to raise an error if a latch is used and can't be analyzed for timing.
    I would expect this also.  Perhaps Xilinx considers “unconstrained paths” to be sufficient warning.

  2. Why doesn't Vivado constraint with the data used at the D and G pins?
    Data at the D-pin is OK but data at the G-pin is not OK.  Data on the G-pin creates a strange scenario:  a data input, G-pin, is switching the data output, Q-pin, of the latch.  This is very different from the normal timing analysis relationship between clocks and data.  I suspect that Vivado timing analysis could be redesigned to handle this – but currently it seems unable.

  3. I have warnings saying I have inferred latches, should I be concerned about wrong timings for those? Should I really trust Vivado's timing analysis for those?
    I think you can trust timing for constrained paths into and out of latches.  You cannot trust timing for unconstrained paths into and out of latches.

Mark

View solution in original post

alexis_jp
Explorer
Explorer
719 Views
Registered: ‎09-10-2019

markg@prosensing.com

I agree, unfortunately working in a team, that doesn't mean other people always do so

1. Thank you for your answer and the details about how Vivado handles that.

2. My main problem was located in the inferred non-clocked latches using G-pin for data. Definitely, a redesign is needed to avoid those inferred latches.

3. Understood, for my current project, the Integrated US+ PCIe core gives hundreds of unconstrained paths and latches' ones were lost in those.

That's clear, thank you again Mark.

0 Kudos