AnsweredAssumed Answered

PCIe analyzer not storing traffic from both directions

Question asked by torr on Aug 26, 2013
Latest reply on Sep 2, 2013 by algoss

Like • Show 0 Likes0
Comment • 9

I'm debugging a PCIe link training problem with the U4301A analyzer and the version 05.60.000 of the logic and protocol analyzer (LPA) software.

If I run one training sequense I get up(endpoint tx) and down(root complex tx) trafic as expected, but if I re run the training sequence until i fails I only get Down trafic on the werry end. in the LTSSM i se the up state maching going trough the right states(exept for the failing run) so there mush have been down traffic. But all I see on down is polling state at the verry end.

Any ideas? I use the stop butten as trigger.

No one else has this question

Outcomes

9 Replies

algoss Aug 27, 2013 4:37 AM
Mark Correct
Correct Answer
What?

What speed are you running?

Are you using the LTSSM Viewer, or are you looking at the LTSSM some other way? How do you know what's happening on the link?

Do you reset in between running the training sequences?

Which direction, upstream or downstream is missing traffic?

What happens when you use TS1 or TS2 as a trigger?

Have you looked at the link with an oscilloscope? Do the eyes look good? What about jitter? When a system can't link reliably it is quite often an electrical issue.

Al

Disclaimer: For more reliable response, you should consider calling your local Agilent Technical Call Center. The Agilent Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.
Like • Show 0 Likes0
Actions
- torr @ algoss on Aug 27, 2013 5:12 AM
  Mark Correct
  Correct Answer
  > {quote:title=algoss wrote:}{quote}
  > What speed are you running?
  
  This is a normal PCIe gen2 training sequence so starts at 2.5GHz and goes to 5gHz in the speed.recovery state of the training.
  
  > {quote:title=algoss wrote:}{quote}
  > Are you using the LTSSM Viewer, or are you looking at the LTSSM some other way? How do you know what's happening on the link?
  
  I'm using the LTSSM viewer
  
  > {quote:title=algoss wrote:}{quote}
  > Do you reset in between running the training sequences?
  
  The analyzer doe's not get a reset inbetween training sequenses no.
  
  > {quote:title=algoss wrote:}{quote}
  > Which direction, upstream or downstream is missing traffic?
  
  I'm missing traffic from downstream(root complex tx)
  
  > {quote:title=algoss wrote:}{quote}
  > Have you looked at the link with an oscilloscope? Do the eyes look good? What about jitter? When a system can't link reliably it is quite often an electrical issue.
  
  the eye looks fine and the the link is ok when it trains correctely, even if it is not captured on the analyzer.
  
  > {quote:title=algoss wrote:}{quote}
  > What happens when you use TS1 or TS2 as a trigger?
  
  I need to lock at this, but as I said when I only run one training sequence everything seems to be ok.
  Like • Show 0 Likes0
  Actions
  - algoss @ torr on Aug 27, 2013 5:38 AM
    Mark Correct
    Correct Answer
    I wouldn't call this a Gen2 training sequence. I would call it a training sequence, followed by a speed change. Yes, it just semantics, but I want to be clear and make sure we're talking about the same thing.
    
    When you say, "when I only run one training sequence everything seems to be ok", do you mean just the Gen1 training?
    
    Do you go through the normal startup sequence between training and speed change, including InitFCs, and Config accesses?
    
    What depth is the analyzer set to? Do you have any storage filtering turned on? It is possible that you are running out of trace memory. The 2 directions are stored independently and may start and stop at different times.
    
    I don't have an analyzer available, but it is possible to trigger on the speed change, by using a sequential trigger. It's generally a TLP followed by a TS. If that works, look closely at the TS to verify that it's a speed change.
    
    Al
    
    Disclaimer: For more reliable response, you should consider calling your local Agilent Technical Call Center. The Agilent Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.
    Like • Show 0 Likes0
    Actions
    - torr @ algoss on Aug 27, 2013 7:36 AM
      Mark Correct
      Correct Answer
      > {quote:title=algoss wrote:}{quote}
      > I wouldn't call this a Gen2 training sequence. I would call it a training sequence, followed by a speed change. Yes, it just semantics, but I want to be clear and make sure we're talking about the same thing.
      
      both root complex and endpoint are PCIe gen2 so the objective is to get the link up as PCIe gen2. But you are apselutely correct that what happens is a training sequence with speed change.
      
      > {quote:title=algoss wrote:}{quote}
      > When you say, "when I only run one training sequence everything seems to be ok", do you mean just the Gen1 training?
      
      No.
      I meen that If I start the the analyzer with trigger on stop button, take the link down and up again so that the training is run.
      Press the stop buttom to generate trigger.
      calulate the LTSSM states in the LTSSM viewer.
      I get the correct state transitions both on up and down strem. from detect -> L0(gen1) -> recovery -> L0 (gen2) in the LTSSM viewer.
      
      but if I run several consecutive training sequenses by taking the link up and down. Forcing to rerun the linktraining. With stop buttom set as trigger.
      calulate the LTSSM states in the LTSSM viewer.
      I get training states on the up stream reaching L0 in both gen1 and gen2, but all I get in the down stream is a polling state all at the end.
      
      > {quote:title=algoss wrote:}{quote}
      > Do you go through the normal startup sequence between training and speed change, including InitFCs, and Config accesses?
      
      no. But as I can understand from the PCIe rev 2.01 this is not nessasery, as the speed change is signaled by the configuration state of the linktraining.
      
      > {quote:title=algoss wrote:}{quote}
      > What depth is the analyzer set to? Do you have any storage filtering turned on? It is possible that you are running out of trace memory. The 2 directions are stored independently and may start and stop at different times.
      
      the depth is set to 4GB.
      I may be running out of memory but then the analyzer prioretice addly as I have a long trace from the up stream bu only a littel bit from the down stream.
      
      > {quote:title=algoss wrote:}{quote}
      > I don't have an analyzer available, but it is possible to trigger on the speed change, by using a sequential trigger. It's generally a TLP followed by a TS. If that works, look closely at the TS to verify that it's a speed change.
      
      I havent tryed this but the link comes up fine in gen2 at the root complex so it should be ok.
      Like • Show 0 Likes0
      Actions
      - algoss @ torr on Aug 29, 2013 12:17 PM
        Mark Correct
        Correct Answer
        So, is the problem that the target doesn't run properly if you bring it down then back up, or is the problem that the analyzer isn't correctly capturing data when you do that?
        
        Al
        Like • Show 0 Likes0
        Actions
        torr @ algoss on Aug 30, 2013 2:22 AM
        Mark Correct
        Correct Answer
        the problem is that the analyzer dosent capture data when bringing the link up and down. or it does not store data from both ways.
        Like • Show 0 Likes0
        Actions
        algoss @ torr on Aug 30, 2013 5:39 AM
        Mark Correct
        Correct Answer
        OK, from what you have told me, the analyzer captures data just fine if you bring your system up just once, but it doesn't if you bring it up, down, and up.
        
        The analyzer has no way of knowing what's going on in the system, except by capturing traffic, which is dependent on seeing valid voltage levels and speeds. It doesn't see the reset line or anything except the lanes. If it is operating differently based on what you are doing with your target, then the target must be doing something different.
        
        Have you tried using a valid trigger, with a sequence? Relying on the "Stop" button just doesn't seem like the right thing to do.
        
        BTW, since the LTSSM viewer doesn't have access to anything except captured traffic, it makes a lot of guesses and inferences from what it sees. Unless you have a valid trigger, and valid data in both directions, it may be wrong.
        
        You need to work your way through the process using more and more complex triggers to see what's happening.
        
        There's something I just thought of... We haven't talked about lane width. Is there a possibility that your target is changing lane width? I have seen targets that, incorrectly, sometimes have different lane widths in the 2 directions. That will definitely cause havoc with the analyzer.
        
        Al
        
        Disclaimer: For more reliable response, you should consider calling your local Agilent Technical Call Center. The Agilent Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.
        Like • Show 0 Likes0
        Actions
        torr @ algoss on Aug 30, 2013 9:07 AM
        Mark Correct
        Correct Answer
        as long as I can see the voltage levels and the eye opening is ok.
        
        > {quote:title=algoss wrote:}{quote}
        > The analyzer has no way of knowing what's going on in the system, except by capturing traffic, which is dependent on seeing valid voltage levels and speeds. It doesn't see the reset line or anything except the lanes. If it is operating differently based on what you are doing with your target, then the target must be doing something different.
        
        there is only some down packages at the end of the package window as well so it's not only the LTSSM decoder.
        
        > {quote:title=algoss wrote:}{quote}
        > Have you tried using a valid trigger, with a sequence? Relying on the "Stop" button just doesn't seem like the right thing to do.
        > You need to work your way through the process using more and more complex triggers to see what's happening.
        
        I have not found a trigger that can trig on timeout from polling.configuration trainign state. but I'm looking to find what is unike here.
        
        > {quote:title=algoss wrote:}{quote}
        > There's something I just thought of... We haven't talked about lane width. Is there a possibility that your target is changing lane width? I have seen targets that, incorrectly, sometimes have different lane widths in the 2 directions. That will definitely cause havoc with the analyzer.
        
        not seen any evidens of this but I havent been looking.
        Like • Show 0 Likes0
        Actions
        algoss @ torr on Sep 2, 2013 7:48 AM
        Mark Correct
        Correct Answer
        "I have not found a trigger that can trig on timeout from polling.configuration trainign state. but I'm looking to find what is unike here. "
        
        The analyzer knows nothing about any of the states, in real time. Any information about the state of the underlying machine is inferred from captured data. It is possible to trigger on a timeout where no TLPs, or maybe DLLP's occur. You might need to think about doing something like a full set of Config Reads and/or Writes at Gen1, or at least a Config Read Type 0 of register 0 before you switch from Gen1 to Gen2, giving the analyzer some traffic to trigger on.
        
        Al
        
        Disclaimer: For more reliable response, you should consider calling your local Agilent Technical Call Center. The Agilent Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.
        Like • Show 0 Likes0
        Actions

PCIe analyzer not storing traffic from both directions

Outcomes

Related Content

Recommended Content