• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 101 subscribers
  • Views 602 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.

AM625: GPMC Burst Write Extra Cycle

Stuart Baker
Genius 10630 points
Part Number: AM625

I'm working with a customer on setting up the GPMC to connect to an FPGA in synchronous burst write mode. We are seeing that when a burst occurs, the control signals (nCS, nWE, and nADV) are unexpectedly being held an extra clock cycle. In the example below, a 32-bit write is performed (2 x16 word burst), and the control signals get extended by an unexpected extra cycle. If a single 16-bit word transaction is performed, the control signals look correct, and are not extended by an external cycle.

The customer has tried adjusting the WeOffTime, CsWrOffTime, and WriteCycleTime, and these adjustments have not resulted in the extra cycle being removed. Please have a look at the configuration and resulting waveform.

CONFIG1 = 0x79401200

  • WrapBurst = 0
  • ReadMultiple = 1 (burst)
  • ReadType = 1 (synchronous)
  • WriteMultiple = 1 (burst)
  • WriteType = 1 (synchronous)
  • ClkActivationTime = 0 (continuous)
  • AttachedDevicePageLength = 2 (16 words)
  • WaitReadMonitoring = 1 (enabled)
  • WaitWriteMonitoring = 0 (disabled) [edited/corrected from original posting]
  • WaitMonitoringTime = 0
  • WaitPinSelect = 0
  • DeviceSize = 1 (16-bit)
  • DeviceType = 0
  • MuxAddData = 2 (mux address and data)
  • TimeParagranularity = 0 (x1)
  • GpmcFclkDivider = 0 (GPMC.CLK = GPMC.FCLK / 1)

CONFIG2 = 0x00030400

  • CsWriteOffTime = 3
  • CsRdOffTime = 4
  • CsExtraDelay  = 0 (disabled)
  • CSOnTime = 0

CONFIG3 = 0x11010100

  • AdvAadMuxWrOffTime = 1
  • AdvAadMuxRdOffTime = 1
  • AdvWrOffTime = 1
  • AdvRdOffTime = 1
  • AdvExtraDelay = 0 (disabled)
  • AdvAadMuxOnTime = 0
  • AdvOnTime = 0

CONFIG4 = 0x02018422

  • WeOffTime = 2
  • WeExtraDelay = 0 (disabled)
  • WeOnTime = 1
  • OeAadMuxOffTime = 4
  • OeOffTime = 4
  • OeExtraDelay = 0
  • OeAddMuxOnTime = 2
  • OeOnTime = 2

CONFIG5 = 0x01030204

  • PageBurstAccessTime = 1
  • RdAccessTime = 3
  • WrCycleTime = 2
  • RdCycleTime = 4

CONFIG6 = 0x02010000

  • WrAccessTime = 2
  • WrDataOnAdMuxBus = 1
  • Cycle2CycleDelay = 0
  • Cycle2CycleSameCsEn = 0
  • Cycle2CycleDiffCsEn = 0
  • BusTurnAround = 0

CONFIG7 = 0x00000F50

  • MaskAddress = 0xF
  • CsValid = 1
  • BaseAddress = 0x10

The customer is recording the following result in the FPGA. Note:

  • s_ad[15..0] = GPMC_AD[15..0]
  • s_wr_n[0] = nWE
  • s_adv_n[0] = nADV
  • s_cs_n[0] = nCS

Thanks,

Stuart

  • 0
    TI__Guru**** 192489 points

    Hello Stuart

    Thank you for the query.

    I am checking internally.

    It would help if you could describe the setup customer is using - EVM vs custom board and any other information.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Genius 10630 points

    It is a custom board connected to an Intel Cyclone 10 LP FPGA.

    Thanks,

    Stuart

  • 0 in reply to Stuart Baker
    TI__Guru**** 192489 points

    Hello Stuart

    Does this happen on s specific board or multiple boards.

    Has customer verified the hardware to ensure there are no function of signal integrity issues.

    Let me check internally if there are any additional points that could be checked.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru* 86940 points

    Stuart, a few things to check

    -Can you confirm the setting for CONFIG1?  You have WaitWriteMonitoring decoded as 'disabled', yet it is set to 1, which is enabled.  But the CONFIG1 register has it set to 0.  Can you confirm WaitWriteMonitoring = 0 ?

    -can you try with WEOnTime = ADVOnTime and ADVWrOffTime = WEOffTime

    What is your GPMC_CLK frequency?

    If you "spread out" the timing for writes (eg, add extra cycle for all of the write parameters) does the extra cycle go away?  If you cut the GPMC_CLK frequency in half, does the extra cycle go away?  

    Regards,

    James

  • 0 in reply to JJD
    TI__Genius 10630 points

    JJD,

    The raw register values are the values directly from the customer. The descriptions are my own decoding. You are correct in that I made a mistake in decoding the WaitWriteMonitoring from the raw register value. The value being used (from the raw register value) is 0, disabled. I have corrected the original posting, including an inline note about the correction.

    For the rest of your questions, I need to consult with the customer.

    Thanks,

    Stuart

  • 0
    Prodigy 140 points

    Setting WEOnTime = ADVOnTime and ADVWrOffTime = WEOffTime makes no sense.  Aren't those two events required to be separate as the data bus is outputting an address for one case and data for the other?

    We are using a GPMC_CLK of 100 MHz.

    Spreading the timing out did not appear to affect the behavior.  The extra cycle was still present.

  • 0 in reply to John Booth64
    TI__Guru* 86940 points

    John, can you try with this configuration to spread out the cycles?

    CONFIG1 0x79401200
    CONFIG2 0x00040400  Increased CsWriteOffTime by 1 cycle
    CONFIG3 0x11010100
    CONFIG4 0x03018422  Decreased WeOffTime by 1 cycle
    CONFIG5 0x01030504  Increased WriteCycleTime by 3 cycles
    CONFIG6 0x02010000  WriteAccessTime=2, WrDataOnADMuxBus = 1
    CONFIG7 0x00000F50

    The relationship should look something like this:

    WrDataOnADMuxBus <  WriteAccessTime < WeOffTime < CsWriteOffTime < WriteCycleTime

    We might be able to combine some of these parameters to reduce the total cycle count, but ultimately the WriteCycleTime needs to encompass the whole write cycle for the first word of the burst.  See if this works and let me know.  

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 140 points

    James,

    That still has an extra cycle.  The only difference from before is CS_N stays low an extra cycle and ADV_N stays high an extra cycle.

    John

  • 0 in reply to John Booth64
    TI__Guru* 86940 points

    Ok, thanks John, this may be an expected synchronization with the burst access.

    So just to confirm, for a single 16-bit access, you see 2-cycles:  Addr->Data

    But for a 32-bit access which requires a 2 word burst, you see 4 cycles: Addr->Data->Data->Extra Cycle

    Is that correct?  

    Can you try a couple of things:

    1.  WrDataOnADMuxBus <  WriteAccessTime < WeOffTime < CsWriteOffTime = WriteCycleTime

    2.  WrDataOnADMuxBus <  WriteAccessTime < WeOffTime = CsWriteOffTime = WriteCycleTime

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 140 points

    I'm not following your comment about this may be expected.  No timing diagrams show it.  Having it also makes it impossible to use the WE directly.

    Correct,

    16-bit access 2-cycles: Addr->Data

    32-bit access 4-cycles: Addr->Data->Data->Extra

    Trying your suggested tests:

    1.

    16-bit access: Addr->Data->Extra->Extra_CS

    32-bit access: Addr->Data->Data->Extra->Extra_CS

    2.

    16-bit access:Addr->Data->Extra

    32-bit access: Addr->Data->Data->Extra

  • 0 in reply to John Booth64
    TI__Guru* 86940 points

    John, we are looking into this further.  What is the full system address you are writing to?  It appears that the address bus shows an offset of 0x6.  Are you writing to address 0x50000006?  Does the issue occur at 32-bit aligned offsets such as 0x0 or 0x4?

    Regards,

    james