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.

DRA829V: JTAG Configuration Guidance

Part Number: DRA829V
Other Parts Discussed in Thread: DRA829

Hi,

I have some concerns on the JTAG implementation in my design as the DRA829 has the TDI,TDO, and TMS signals at 1.8V and EMU, EMU1, TRSTn, and TCK are all at 3.3V.

I am using a MIPI60 connector (1.8V level) for an external emulator as well as an FT4232H (3.3V level) for an alternate JTAG source. Currently, if the MIPI60 is attached, then the EMU, TRSTn, and TCK signals will be level shifted to 3.3V. Is the added delay to TCK ok if the same delay is not seen by the data lines?

For the FTDI JTAG, I have to level shift TDI, TDO, and TMS to 3.3V. Now there will be a delay on the data lines but not on TCK. Is this an issue?

Thanks,

Donovan

  • Sorry the block diagram didn't attach.

  • Hi Donovan,

    Let me get back to you on this.

    Regards

    Karthik

  • Hey Karthik,

    Any update?

    Thanks,
    Donovan

  • Hello Donovan,

    The JTAG and TRACE interfaces are characterized at 1.8v and 3.3v.  In some of the designs I've seen, both sets are all one voltage or one set is at 1.8 and the other set is at 3.3.   The MIPI-60 header has 2 voltage reference pins, one for the JTAG group and one for the TRACE group.  The JTAG boxes I've used supported this.

    In your case, you seem to have level shifted to a common voltage at the adaptor and are trying to different groups at the SOC.  I would guess that this would result in issues at running at higher JTAG clock speeds.

    If multiple SOCs are daisy-chained together sometimes each CPU will have a different voltage and shifters can help here but some speed degradation is expected.  What you describe is beyond that.   I'll ping someone who does timing analysis at the SOC level to see what kinds of issues might exist in what you have proposed.  Minimally it will be slower than other options, maximally something might be invalid as I don't see split qualification of pin groups like this.

    Regards,

    Richard W.

  • Hi Richard,

    I have my TRACE and JTAG pins both at 1.8V currently. I am referencing the EVM as much as possible, but for this design, I need 1.8V IO on the MAIN domain. The MCU domains are the same as the EVM (MCU_VDDSHV0 and MCUVDDSHV2 = 3.3V) which is why I've run into this issue. Unfortunately, the TCK is on a different IO domain than the TDI and TDO JTAG pins which is why I have to level shift. I could potentially change MCU_VDDSHV0 to 1.8V but then I will have to change quite a bit from the EVM leaving more room for error.

    Regards,

    Donovan

  • Hello Donovan,

    I did discuss this with a JTAG IO timing expert and the feedback was that this arrangement should work but it is likely the max operating speed would need to be dialed back.  Where possible I would suggest following the EVM as that is a well-traveled and well-tested path.  Probably it will work out but there would be a performance margin drop.  Practically, this would be most impacting at corer conditions (temperature and process).  For nominal development (room temp/nom-chip) likely not much impact would be there (unless that margin is ate by other board issues).  Probably corner tests and any RMRs would have more sensitivity.

    The raw comments for more background would be:

    The insertion of level translators will introduce delay in the signal paths and will reduce max operating frequency.  However, timing issues can be resolved by simply reducing the clock frequency.  Both setup and hold timing margins are increased as you reduce the clock frequency since JTAG timing is defined to change outputs on the falling edge of TCK and latch inputs on the rising edge of TCK.  So they will need to decrease the clock frequency enough to compensate for the additional insertion delay of the level translators.

    Regards,

    Richard W.

  • Thanks Richard! 

    I will let the customer know. Unfortunately, we really don't have any other options.

    Regards,

    Donovan