• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 366 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM4372: MMCx pin mapping

Peter Schmuckal
Intellectual 350 points
Part Number: AM4372
Other Parts Discussed in Thread: SYSCONFIG

I am attempting to configure the 3 MMC interfaces on our AM4372BZDNA80 board

1. MMC0 - uSD card, 3.3V, 4b, must be bootable
2. MMC1 - eMMC, 1.8V, 8b, must be bootable
3. MMC2 - Radio, 1.8V, 4b

I have set VDDSHV9 = VDSHV10 = 1.8V.  All other VDDSHVx = 3.3V

I can found no direct solution to this problem.  Yes I am using both pinmux & sysconfig tools.

1. MMC0 pin mapping fixed
2. MMC1 pin mapping fixed for clk/cmd & dat0~dat3 to be bootable.  Would like to use B7, A7, C8, B8 for dat4~dat7.  But this causes an IOSET conflict.  Cannot use pure IOSET2 as that conflicts with MMC2 (below)
3. MMC2 Must use IOSET1 (A12, B12, E11, C11, B11, A11) to stay in 1.8V V domain.  Cannot use IOSET2 as that uses SHV11 which = 3.3V.  SHV11 cannot be switched to 1.8V.

My options are:
1. Risk the IOSET timing conflict on MMC1.  
2. Use IOSET2 with MMC2 with voltage translators on dat0~dat3 which will, of course, change the timing significantly as well.

Is the IOSET1/2 conflict in MMC1 acceptable?  Has anyone run timing on this scenario? (I know I'm not the first to ask about this)

This forum post seems to suggest that it might be acceptable, but I would like more assurance.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/968870/am4376-mmc1-rom-boot-pinmuxing-question/3579358?tisearch=e2e-sitesearch&keymatch=iosets#3579358

Please advise.

  • 0
    TI__Genius 9360 points

    Hello,

    We will need to consult with our expert on this topic who is currently out of office. We will follow up as quickly as we can when they return next week. Apologies for any delay.

    Thanks,

    Chris

  • 0
    TI__Guru 62855 points

    The timing closure team only closes SoC timing for valid IOSETs. Therefore, we do not recommend assigning signal functions to any combination of pins not defined by a valid IOSET.

    As you mentioned above, inserting any delay in the signal path could introduce timing violations. You should be performing a timing analysis on all ports to ensure actual PCB delays of your system do not introduce timing violations. You would need to do the same thing with MMC1 and include the additional delay inserted by the level-shifters.

    Regards,
    Paul

  • 0 in reply to peaves
    Intellectual 350 points

    Thanks for the response.

    As IOSET1 & IOSET2 for MMC1 both use the exact same pins for clk & cmd, how could there be a timing issue wrt to dat0~dat3 vs. dat4~dat7 from different "sets" wrt to the same clk?

    I guess I am requesting the timing closure team look at this special case as it appears to be a very useful one.

  • 0 in reply to Peter Schmuckal
    TI__Guru 62855 points

    The MMC1_DAT[7:0] signal functions associated with IOSET1 takes a different path through the pin multiplexing logic to a different set of pins than IOSET2. However, I see your point about the data signals must have similar delays through both paths since their timing is relative to the MMC1_CLK signal signal that doesn't change between IOSET1 and IOSET2. Let me discuss with the timing closure team to get their opinion.

    I do not expect them to be able to do any formal verification as this is a very old design and the original design team was dissolved many years ago.

    Regards,
    Paul

  • 0 in reply to peaves
    TI__Guru 62855 points

    Our timing closure team was able to open the design and confirm all MMC1_DAT[7:0] signal paths defined in IOSET1 and IOSET2 were timing closed to to the common MMC1_CLK signal path. Therefore, you should not have a problem using MMC1_DAT[7:4] from IOSET1 with the MMC1_CLK, MMC1_CMD, and MMC1_DAT[3:0] signals from IOSET2.

    I'm not sure if the SYSCONFIG tool will simply provide a warning or refuse to let you select signals from two IOSETS. You may need to manually edit the output of the SYSCONFIG tool to select this combination of pins for the MMC1 signals.

    I'm investigating the possibility of adding a new IOSET for MMC1 that includes this combination of pins. However, this could take a while before it propagates into a new revision of the SYSCONFIG tool.

    Regards,
    Paul

  • 0 in reply to peaves
    Intellectual 350 points

    Thanks Paul, this is very helpful.