This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 EVM reset via PCIe

Other Parts Discussed in Thread: TMDXEVMPCI

We would like to reset the C6678L EVM board over PCIe from our Root Complex processor.

 

The only software-controlled board reset seems to be via the PLL Reset Control Register (SPRUGV2A Section 4.14), at address 0x023100E8, by first writing the key value, then writing a 0 to the SWRST bit.

 

But the above sequence does not seem to work over PCIe, and the manual SPRUGV2A cautions in section 3.1 not to write to the PLL registers via PCIe.

 

So how can the RC reset the C6678 EVM via PCIe? Our RC and C6678 EVM are on separate boards, and there are no GPIO that we can use.

 

We are looking for a reasonably reliable solution, which does not rely on software running in the C6678.

 

I look forward to your advice.

  • The short answer: Unfortunately, it is not possible to directly reset the C6670/C6678 device when using the TMDXEVM6678 or TMDXEVM6670 EVMs together with the TMDXEVMPCI.

     

    The long answer:

    The TMDXEVM667X EVMs are actually MicroTCA/AMC compatible cards.  This form factor does not use the PCIe PE_RST line so a passive adapter between MicroTCA/AMC and PCIe cannot exist.

    Thus, when designing a production PCIe card, it is suggested to connect the PE_RST line on the PCIe connector to some logic that can sequence the POR and RESETFULL lines on the device.

     

     

  • Thanks for your answer, which I understand and agree with, but I need to rephrase my question.

     

    We are plugging the TMDXEVM6678L (as a PCIe Endpoint) directly into a MicroTCA/AMC system, so there is no TMDXEVMPCI adaptor involved.

     

    We understand that there is no hardware mechanism for our PCIe Root Complex to reset the C6678 via AMC/PCIe.

     

    But we note that the C6678 software can reset the C6678 by writing to the KEY and then the SWRST bit of the PLL Reset Control Register (RSTCTRL), see my original email.

     

    Since the RSTCTRL register is visible via PCIe, it might be possible to write to the RSTCTRL register from the Root Complex (RC) over PCIe.

     

    But the manual advises against the writing to any PLL registers via PCIe.

     

    My question is, even though it may be inadvisable, can it work in practice (even if not 100% reliable). Since it would be a posted write, I don’t see why is wouldn’t work, but my experiment did not work.

     

    This is only for lab use during the next 6 months. We will not go commercial with the EVM.

     

    So my real question is this: Does the PLL controller prohibit PCIe writes to RSTCTRL, or did I just get the KEY sequencing wrong?

     

    Thanks again for your advice.

  • I attempted to implement exactly the same behaviour last week, and found your post after my attempt had failed. If the KEY sequencing in both our code is wrong, it's likely that the documentation of the key sequence is wrong or writes from the PCI controller are blocked. It's a good thing the Linux host can rescan the PCI bus after a press of the hard reset button on the EVM.

     

  • Hi Jonathan and Adrian,

    First of all, it is not recommended to change the PLL registers via other masters (e.g. PCIe).

    But the external host can still access the PLL configuration registers (or other device registers) through PCIe link, by changing the PCIe transaction as "supervisor mode" on the target PCIe device. 

    Basically  we need to change the “MST_PRIV” bit to 1 in PRIORITY register on the target PCIe device (0x2180003c, section 3.1.14 in PCIe user guide) first, then the PCIe port will be configured as "supervisor mode" and is able to access the PLL registers. And external host can access those registers through PCIe link. 

    The default "MST_PRIV" bit is set to 0 as "user mode", which is not allowed to access the device registers but OK for the memory access. The details of the PRIORITY register will be added in the next release of  PCIe user guide. 

     

    Sincerely,

    Steven

  • Hi Steven, thanks for the solution you have given. I was able to change the "MST_PRIV" bit to 1 (even via PCIe), and then do the reset.

    My coworkers are asking why it's not recommended, although personally I'm just happy that it works ;^)  My own conjecture is that doing a hardware reset (via software write) over an interface that may then become hung (due to the reset) may be a bad idea.

    Regards (and thanks again), Jon

  • Hi Jonathan,

    There are some statements from the PLL specification that may be helpful to explain the risk of changing PLL by external host. 

    "Clock stretching: Beware that clocks are paused when coming out of reset, changing divider ratios, coming out of clock gating, or changing mux selection. This is not an issue in most cases—but may cause issues if during the time of clock stretching an external host tries to access the DSP. The external host does not comprehend this divider stretching and therefore may continue to send commands when the DSP cannot respond because of the stretched clock. "

    So in the user’s guide, it is clearly indicated that the host should not be used to directly program the PLL Controller registers to avoid this issue.

    Hope it helps.

     

    Sincerely,

    Steven

  • Thank you Steven, that is very clear.

     

    We would not touch any PLL register except RSTCTRL from our external host. After writing the SWRST bit via posted PCIe write, we would not issue any more PCIe commands until a very long time later. And this is only for internal lab use.

     

    So I think we will be OK, and can consider the question closed.

     

    Thanks again.

     

    Regards,  Jonathan