Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

Embedded Jam STAPL Player, long programming time

Hello,

I have ported the Jam STAPL bytecode player to my embedded processor in order to program MAX 10 devices. So far the programming works fine. However, it takes ages for the player to get the MAX 10 programmed. The .jbc file has a size of about 120 kBytes and the programming takes approximately 5 minutes. I have verified that the ported routine jbi_delay() works as expected and delays for the desired time. Scoping the JTAG signals showed pulse packets on the TCK line with a length of about 500 microseconds. Between the pulse packets there are gaps of 1 to 1.5 milliseconds.

Now I'm wondering whether I have missed something in the porting process.

Is there a chance to speed up the programming?

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hi Marko,

    I assume that a verify part of the programming action brings the significant portion to the pgm time. The player has to compare read and expected data bits from the actual data shift and evaluate the result. This is the gap I suppose. I would recommend to generate a SVF file for the same device and check it as it is much easier to understand what is going on.

    Best regards,

    Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hi m,

    I have the similar experience with programming via JAM STAPL. Can you increase TCK frequency? This should help a little bit. But the main problem is in a division of a STAPL file code into small parts. For the STAPL player is possible to execute only small portion of a STAPL code typical a single JTAG transition or one data/instruction shift. Yes, there is a chance to speed up the programming significantly with using of a POF file with any 3rd party programmer or USB blaster. Because with help of an appropriate programming algorithm it is possible to produce the optimal algorithm for faster programming.

    Best regards,

    Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hello Martin,

    thank you for the response.

    Speeding up the TCK frequency would mean I would disobey the timing the Jam player dictates. Surely this could work inside reasonable bounds. I agree with you that this would bring only a small improvement. The real problem is the duration of the inter-packet gaps. Maybe they originate from the internal structure of the STAPL file and how the player processes the file as you described it.

    But what is the player doing in this gaps? Is there another delay function or is it waiting for an external signal?

    Since I need an embedded update functionality using an external programmer is not an option.

    Best regards,

    Marko
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hello Martin,

    the Jam STAPL byte code player documentation states the three steps erase, program and verify during the device programming process. But as I could see on the scope there is no difference in the duration of the inter-packet gaps between this steps.

    Since we are in the development phase and time is scarce I can live with the long programming time for now. When we go productional a five minute delay will hardly be acceptable. So I will look at this again soon.

    Thank you for being part in this discussion.

    Best regards,

    Marko