Forum Discussion

itzik's avatar
itzik
Icon for New Contributor rankNew Contributor
1 month ago

nSTATUS is sometimes asserted low during Agilex-F configuration when operating in PMBus slave mode

I am using Passive Avalon-ST 16 mode to configure the Agilex-F device.

There is external PMBus master to run the ARA process of the SmartVID protocol immediately after sensing ALERT low signal.

Sometimes when trying configuration after power up (starting the process by asserting nConfig low), nStatus goes low before reaching the point of ALERT signal going low.

Retry of the configuration after such failure always succeeds.

Any idea?

Thanks,

Itzik

Configuration

6 Replies

  • itzik's avatar
    itzik
    Icon for New Contributor rankNew Contributor
    8 days ago

    Hi,

    I apologize it took so long to get to conclusions.  The issue was so confusing...

    The problem is solved by changing all our programming methos from a CPU controlled to a State Machine.

    With the CPU programming we had gaps in the avst_clk. Now with the state machine we have 5Mhz continuous clock,  50% duty cycle.

    I have found an interesting note in a datasheet declares the following:

    Before beginning configuration, do trigger device cleaning by toggling the nCONFIG pin from high to low to high. This nCONFIG transition also returns the device to the configuration state.

    I have tried this and it didn't help.

    Stability was poor until we have decided to power cycle the Agilex device before each new programming.  This solved all problems and now the programming takes 15 seconds and it is very stable.

    Thanks for all the help and support

    Itzik

     

     

    • FakhrulA_altera's avatar
      FakhrulA_altera
      Icon for Regular Contributor rankRegular Contributor
      3 days ago

      Hi,

      I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

      Fakhrul

  • itzik's avatar
    itzik
    Icon for New Contributor rankNew Contributor
    1 month ago

    Hi Fakhrul,

    Thanks for the review.

    We have checked the above list and it is fulfilled.

    Actually we have noticed that after failure there is success and so on : pass-fail-pass-fail-pass-fail...

    The power is stable during the test.  A failing condition occurs before ALERT goes low.  It is always after a specific number of AVST Clocks; the process fails after 4130 AVST_CLK cycles.

    nConfig/nStatus start ok .

    I haven't read STATUS BYTE after nStatus went low because PMBus activity has not started yet.  Please suggest if this can lead to something.

    Thanks,

    Itzik

     

    • FakhrulA_altera's avatar
      FakhrulA_altera
      Icon for Regular Contributor rankRegular Contributor
      17 days ago

      As we haven't received a response to our previous notification, this thread will be transitioned to community support. We hope all your concerns have been addressed. If you have any new questions, please feel free to open a new thread to receive support from Intel experts. Otherwise, community users will continue to assist you here. Thank you.

    • FakhrulA_altera's avatar
      FakhrulA_altera
      Icon for Regular Contributor rankRegular Contributor
      23 days ago

      Hi Itzik,
       

      Thanks for the details. Since the failure is repeatable after a fixed 4130 AVST_CLK cycles and happens before ALERT, this points to the AVST configuration stream rather than PMBus.

       Could please try the following?

      Raise AVST_CLK and verify VALID/READY handling
      Use a faster AVST clock (target ≥1 MHz). Keep AVST_VALID high while streaming; when AVST_READY goes low, send idle clocks with VALID=0. Capture AVST_CLK, AVST_VALID, AVST_READY, and data around the 4130‑cycle point. This fixed similar stall-at-a-fixed-count cases. https://community.altera.com/discussions/boards-and-dev-kits/agilex-3-avst-programming-fails/122255


      Read SDM status immediately after nSTATUS drops
      Use the AN‑936 method or Configuration Debugger to read SDM major/minor codes right after the failure. It will tell whether the drop was due to AVST stream, PMBus, or another SDM check, guiding the next fix. KDB: [community.altera.com]

      Regards,
      Fakhrul
       

  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    1 month ago

    Hi Itzik,

    Thank you for sharing the details. Based on Agilex 7 guidelines, this issue is typically related to configuration handshake or PMBus timing.
    Key checks:


    1. nCONFIG/nSTATUS sequence
    For Avalon‑ST x16 mode, hold nCONFIG low until nSTATUS goes low, then drive nCONFIG high. Only start sending AVST data after nSTATUS is high and AVST_READY asserts. Keep AVST_CLK free‑running.


    2. Power‑up and POR
    Ensure rails ramp in the correct order (Group 1 → Group 2 → Group 3) and meet POR/tRAMP requirements. If POR timing is violated, configuration can fail and nSTATUS may drop.


    3. PMBus slave flow
    PMBus pins are undefined until the device is fully powered. The external PMBus master must:

    • Poll PWRMGT_ALERT at ≤100 ms intervals.
    • Start ARA only after ALERT asserts.
    • Send VOUT_COMMAND within 200 ms of ALERT.
      Sending commands too early or missing this window can cause SDM errors and nSTATUS low.

     

    Why retry works:
    After the first failure, rails and clocks are stable and the SDM resets cleanly, so the next attempt succeeds.

    Recommended actions:

    • Verify nCONFIG/nSTATUS handshake and AVST_READY timing.
    • Confirm power‑up sequence and POR timing.
    • Check PMBus master flow for ALERT polling and VOUT_COMMAND timing.
    • If failure repeats, read STATUS_BYTE to identify PMBus or regulator errors.

    Please refer to Agilex™ 7 Power Management User Guide

    Regards
    Fakhrul