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.

GPMC synchronous write datasheet timing

Other Parts Discussed in Thread: SYSCONFIG

Hello, we are using sitara GPMC in synchronous mode to communicate with FPGA.  Could someone please clarify the timing characteristics for a synchronous write, outlined in Table 7-22 in AM335x Datasheet.

The 'F15' timing parameter:  "Delay time, output clock gpmc_clk rising edge to output data gpmc_ad[15:0] transition. is specified as  ' J-2.3 <= F15 <= J + 1.9'.

Since J = 10 ns (constant), does this mean that the gpmc_ad transition will fall on the negative edge of GPMC_CLK if the clock period is set to 20ns?



  • Hi Mikhail,

    I think the correct interpretation of this is -2.3ns to +1.9ns from GPMC_CLK rising edge.

  • Thanks for the prompt clarification. If this is true, then could someone please help understand the significance of 'J' in relationship to F15 timing parameter?  I am confused, because It looks to me like a contradiction.

  • You can report this directly to the documentation team using the "Submit Documentation Feedback" link at the bottom of each PDF document page.

  •  

    Biser Gatchev-XID said:

    I think the correct interpretation of this is -2.3ns to +1.9ns from GPMC_CLK rising edge.

    There seems to be a discrepancy between this statement and what we observe an oscilloscope during burst. I have attached oscilloscope waveforms, capturing Clock->Data transition delays for 25  & 50Mhz during burst.  It looks as though @ 50Mhz, data is changing on the falling edge, and @ 25Mhz, data is changing mid-edge. This behaviour is highly undesirable from the point of view of designing one HW design to handle multiple GPMC frequencies. Are there any  register settings in GPMC that can help ensuring that data always changes on a specific edge (either rising or falling), regardless of selected GPMC_CLK frequency?

  • Mikhail, you should be able to get your desired result by changing some of the timing in the GPMC CONFIG regs.  When you switch between 50 and 25MHz, do you change any of these CONFIG registers?  Note that the timings in these registers are based off of the GPMC_FCLK, not the GPMC_CLK that you see in your scope shots.  So if you are just changing the GPMCFCLKDIVIDER, then all of the control signal timings will not scale.  I would get the timing right for the 50MHz scenario, then change to 25MHz using the divider and change the CONFIG timings accordingly if needed.  If you need to stretch out the timing for the 25MHz case , you can use  TIMEPARAGRANULARITY to change all the control signals, or change them individually.

    Regards,

    James

  • JJD said:
    , do you change any of these CONFIG registers?


    Between 25 & 50Mhz, I use TIMEPARAMGRANULARITY  to achieve the desired frequency scaling. Everything works as expected in single write/read: data and address are changing on the rising edge as expected. The burst behaviour is still a mystery. We are using GPMC in  AAD mode. During addressing, the AD bits are switching on the rising edge of GPMC_CLK, the first data bit (after AD_MUX_BUS) - switches on the rising edge. The remaining data bits in the burst (waveforms above) are switching with this extra 10ns delay. I cannot find any timing parameters in the datasheet that control clock->data delay during burst. Am I missing something?

    Please see register settings for 25MHz:

    GPMC_SYSCONFIG=0x00000011
    GPMC_TIMEOUT_CONTROL=0x00001111
    GPMC_IRQENABLE=0x00000000
    GPMC_CONFIG=0x00000a00
    CSn=2....
    GPMC_CONFIG1_CSn=0x79601113
    GPMC_CONFIG2_CSn=0x000a0c02
    GPMC_CONFIG3_CSn=0x44060604
    GPMC_CONFIG4_CSn=0x0a068c26
    GPMC_CONFIG5_CSn=0x020a0a0c
    GPMC_CONFIG6_CSn=0x08060000
    GPMC_CONFIG7_CSn=0x00000040

    and 50Mhz:

    GPMC_SYSCONFIG=0x00000011
    GPMC_TIMEOUT_CONTROL=0x00001111
    GPMC_IRQENABLE=0x00000000
    GPMC_CONFIG=0x00000a00
    CSn=2....
    GPMC_CONFIG1_CSn=0x79601101
    GPMC_CONFIG2_CSn=0x000a0c02
    GPMC_CONFIG3_CSn=0x44060604
    GPMC_CONFIG4_CSn=0x0a068c26
    GPMC_CONFIG5_CSn=0x020a0a0c
    GPMC_CONFIG6_CSn=0x08060000
    GPMC_CONFIG7_CSn=0x00000040


  • Hi Mikhail, your timing configuration looks good. A couple of ideas to check:
    -is it possible the wait signal is active? I noticed you have wait monitoring enabled. Is the wait signal delaying the access, causing the 10ns delay?
    -You may want to experiment with the PAGEBURSTACCESSTIME (maybe double it to see what behavior you get). I know this should be scaling with TIMEPARAMGRANULARITY, but just change it to see what behavior you get.

    Regards,
    James
  • JJD said:
    -is it possible the wait signal is active?

      

    Wait signal is held high (not active) through the burst. Please see the digital waveform below:

    And corresponding analog waveform, capturing GPMC_CLK & GPMC_AD[4]: Highlighted are the CLK -> AD transitions. Green is ok (rising edge). Red is not ok (rising edge + 10ns)

    JJD said:
    -You may want to experiment with the PAGEBURSTACCESSTIME (maybe double it to see what behavior you get)

    Doubling PAGEBURSTACCESSTIME had made each data word span 2 clock cycles instead of 1.  It had no effect on the clock->data delay of 10ns. Please see the waveform below:

    Any ideas?

  • Ok, here are a few more ideas. Checkout Figure 7-23 in the TRM. I think this is close to what you are attempting to do.

    -That figure shows WRDATAONADMUXBUS one cycle longer than ADVWROFFTIME. There may be some weird synchronization issue going on internal to the GPMC that is causing the delay you are seeing. And then WRACCESSTIME is 3 cycles after that. So you may want to experiment with the relationship of these configurations, using the figure as a guideline.
    -I also noticed that CSONTIME is after ADVAADMUXONTIME. CS should be the first control signal to go active.

    Regards,
    james
  • JJD said:
    CS should be the first control signal to go active.

    Changed the waveform to start from CSON=0.

    JJD said:
    That figure shows WRDATAONADMUXBUS one cycle longer than ADVWROFFTIME

    Did not see any improvement when changing this parameter. In addition, Fibure 7-22 has WRDATAONADMUXBUS = AVWROFFTIME.

    JJD said:
    WRACCESSTIME is 3 cycles after that

    It looks like setting WRACCESSTIME to  1 minus the value I had previously, achieves the desired waveform @ 25 & 50Mhz.  This behaviour aligns with the original datasheet timing parameter of F15 for CLK->DATA transition of having a 10ns delay. By having  WRACCESSTIME = WRACCESSTIME-1, we effectively force the data 10ns earlier, achieving the 'rising edge' effect.

    GPMC @ 50MHz:

    GPMC_CONFIG1_CSn=0x79601101
    GPMC_CONFIG2_CSn=0x00080a00
    GPMC_CONFIG3_CSn=0x22040402
    GPMC_CONFIG4_CSn=0x08044a04
    GPMC_CONFIG5_CSn=0x0208080a
    GPMC_CONFIG6_CSn=0x05040000

    CLK & AD[4]:

    However, 100MHz case is still a mystery. Please see  below:

    GPMC @ 100MHz.

    GPMC_CONFIG1_CSn=0x79601100
    GPMC_CONFIG2_CSn=0x00040500
    GPMC_CONFIG3_CSn=0x11020201
    GPMC_CONFIG4_CSn=0x04022502
    GPMC_CONFIG5_CSn=0x01040405
    GPMC_CONFIG6_CSn=0x03020000

    CLK & AD[4]:

    As before, the CLK->ADDR transition occurs on the rising edge. First data bit is out on the rising edge, then all consecutive data bits transition after a 10ns delay on the falling edge of the GPMC_CLK.  I have tried inserting cycles between  WRACCESSTIME,  ADVOFF, & ADMUX to no avail. 

    Unlike with 25/50Mhz, the behaviour of CLK->DATA @ 100MHz does not follow the  datasheet F15 timing parameter. According to the waveform above, the data transition occurs with 10ns delay on the falling edge, while F15 specifies rising edge. What could be going on here?

  • I'm not sure if using EXTRADELAY here on ADV will help since you're seeing the issue on data, but you may want to try enabling that to see how that changes things. I'm running out of ideas, but i think we are close.

    Regards,
    James
  • At 100Mhz, using EXTRADELAY did not have any effect on the DATA. Just changed ADVn signal to transition on the falling edge of GPMC_CLK.
  • Hi Mikhail, Happy New Year!
    I've been looking at this more to tie up this final issue. Here are some ideas to try.

    -After looking at your 100MHz configuration, I think there may be some overlap in some of the timings which may need fixing. Here is what i decoded

    ADVAADMUXONTIME = 0
    ADVADMUXWROFFTIME = 1
    OEAADMUXONTIME = 0
    OEAADMUXOFFTIME =1
    I think the above is ok, as it defines the first address cycle

    ADVONTIME = 1
    ADVWROFFTIME = 2
    WEONTIME=2
    WEOFFTIME=4
    This defines the timing for the second address cycle. Try changing the above to line up the ADV pulse and WE pulse with each other as shown in the figure in the TRM.

    WRDATAONADMUXBUS=2
    Try changing this to at least 1 cycle beyond WROFFTIME

    WRACCESSTIME=3
    Try changing this to at least 1 cycle beyond WRDATAONADMUXBUS. You can even further adjust this to see if the rising/falling edge behavior changes.

    If possible, can you go back to the logic analyzer waveforms to get a better idea of the timing of the control signals relative to addr/data.

    Regards,
    James
  • Hello,

    This did not help. 

    New configuration:

    GPMC_CONFIG1_CSn=0x79601100
    GPMC_CONFIG2_CSn=0x00060500
    GPMC_CONFIG3_CSn=0x11020201
    GPMC_CONFIG4_CSn=0x02012502
    GPMC_CONFIG5_CSn=0x01040605
    GPMC_CONFIG6_CSn=0x05030000
    GPMC_CONFIG7_CSn=0x00000040

    Burst waveform:

    As evident from above, the behaviour has not changed. ADDR + 1st data are out on rising, later bits come out on falling edge.

    I cannot get logic analyzer view since my FPGA cannot sample fast enough @ 100MHz.  I added WE (orange) and ADVn(blue) to the analog waveform.

    Any other ideas?

  • Mikhail Zakharov1 said:
    It looks like setting WRACCESSTIME to  1 minus the value I had previously, achieves the desired waveform @ 25 & 50Mhz.  This behaviour aligns with the original datasheet timing parameter of F15 for CLK->DATA transition of having a 10ns delay. By having  WRACCESSTIME = WRACCESSTIME-1, we effectively force the data 10ns earlier, achieving the 'rising edge' effect.

    Unfotunately, thats not the full story. The clock and data are aligned for all bursts until the slave asserts gpmc_wait signal during the burst. After that, sitara reverts back to driving the data with 10ns delay.  Please see waveform below (@25MHz):

    GPMC_CONFIG1_CSn=0x79601103
    GPMC_CONFIG2_CSn=0x00141400
    GPMC_CONFIG3_CSn=0x44080804
    GPMC_CONFIG4_CSn=0x14089408
    GPMC_CONFIG5_CSn=0x04101418
    GPMC_CONFIG6_CSn=0x0f080480
    GPMC_CONFIG7_CSn=0x00000040

    Added in blue - WAIT being asserted by the slave.  

    Our use-case mandates the use of WAIT pin on GPMC burst write. It looks like we still don't have a configuration that outputs data on a consistent edge @ 25/50/100MHz. 

  • Hi Mikhail Zakharov1 and Sitara support team,

    I am interested in your post.
    As your report, GPMC_CLK can work at 25MHz and 50MHz, but it can not achive 100MHz.
    Did you find the solution?
    If not, I suppose that there is the limitation for GPMC with sync mode.
    Because I found this post, it was very old post and taking other device; DM814x though.

    e2e.ti.com/.../678465
    >> All the time GPMC works at GPMC_FCLK = 100MHz
    >> Asynchronous mode: All the Assert/de-assert are done with reference to GPMC_FCLK = 100MHZ
    >> Synchronous mode: All assertions/de-assertions are done with reference to GPMC_CLK = 100MHZ / ( 1+ GPMCFCLKDIVIDER)
    >> Normally in Synchronous mode GPMCFCLKDIVIDER = 0x1 ( GPMC_CLK = GPMC_FCLK/2 = 100MHz/2 = 50 Mhz)

    Sitara support team,
    Is the above idea for GPMC on DM814x same as GPMC on Sitara?
    I need to explain to my customer about the fastest GPMC_CLK for Synchronous mode on AM335x.

    Best regards,
    Kanae
  • we were able to get 100MHz sync, to workaround the issues above, had to sample control and data on different polarity (suggested to us by TI in an internal email). Alternatively, you could double control cycle timings, and keep control and data with the same polarity, this however won't scale down to 25MHz with AAD mode (not enough register control bits).

  • Hi Mikhail Zakharov1,
    Thank you for your reply.

    I am glad to hear that you could get 100MHz sync.
    However, I cannot understand how to sample control and data on different polarity.
    Does it set just GPMC_CONFIGx resister properly, or not?
    I am wondering if you could share the solution which was suggested by TI in an internal email.
    Actually, I do not need to scale down to 50MHz or 25MHz.
    I would like to make sure that GPMC_CLK for Synchronous mode on AM335x can achieve 100MHz,
    not like that on DM814x.

    Best regards,
    Kanae