Forum Discussion

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

Set configuration with PS mode by other MCU

Hello,

I have some problems with PS mode configuration.

I used to use AS mode as configuration solution for years.

And this time , I want to config the FPGA with other MCU with PS mode.

First, I changed the hardware ,that I can config FPGA with PS mode setting by download cable and PC.

And I use .sof file as the configuration file.

When I monitor the waveform, I have no idea how the data0 work.

I through it should be part of content of .sof file, but I can't find out what's the starting point of the file.

The start of the file are 01010011, 01001111, 01000110(seen by Ultraedit), so I through I should see 11001010, 11110010, 01100010 in the start of waveform.

But I saw total different data that I don`t know how to explain it (a lof FF and FE, AD, DF).

Here's my questions, should I send "all" of .sof file byte-reversed to FPGA by the waveform generated by other MCU, and it just work fine?

I read documents, and it seems there are other file type can be set as configuration file, ex: .rbf.

what is the different with .sof file ?

Should I use .sof or .rbf if I want to config FPGA with other MCU ?

waiting for your kindly reply.

thank you

4 Replies

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

    Thanks for the reply.

    I tried the .rbf file, and it works ,too.

    So, .sof and .rbf both work well in download cable with Quartus.

    Next, I change the first one byte and the last one byte of .rbf.

    And waveform changes in the first waveform and last one.

    I am convinced that I just send the whole .rbf data to FPGA by MCU, and it will work.

    But the waveform of the combination of data0 and DCLK is little odd.

    The following shows the waveform I capture during configuration

    http://www.alteraforum.com/forum/attachment.php?attachmentid=10110&stc=1

    The CONF_DONE raise before the last data was sent.

    But it seems it goes all right.

    Thanks for the helping. I think I can take care of the last.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    thanks for the reply.

    I tried the .rbf file, and it works , too.

    The .sof and .rbf both work well in download cable with PC.

    I changed byte of .rbf and I found the waveform changed, too.

    I am convinced that sending all data into the FPGA will config the FPGA well.

    There is something odd among the waveform.

    The CONF_DONE raised before the last byte of .rbf was sent.

    It's different form the document.

    Anyway, I think I can take care of the last.

    Thanks for the help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    There is something odd among the waveform.

    The CONF_DONE raised before the last byte of .rbf was sent.

    It's different form the document.

    --- Quote End ---

    If you look at figure 1 in the document I linked to, CONF_DONE goes high, and then if you have enabled it, INIT_DONE. If you read the data sheet for the device you are using, there is sometimes a note about sending additional clocks after CONF_DONE goes high, so that the device enters "user mode". Those extra clocks are implemented as extra bytes in the .rbf file, so when you trace configuration of an FPGA, you will see DCLK continue after CONF_DONE asserts. Look at the logic analyzer traces in Figure 31 on p60 - note how the FPGA configuration data bus goes to FFh, but DCLK continues to toggle, and then CONF_DONE asserts. In other devices, it might be that CONF_DONE asserts before DCLK stops toggling. I would not be concerned if that is what you are seeing. The main thing is that if CONF_DONE has asserted, your FPGA is configured correctly.

    Cheers,

    Dave