Forum Discussion

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

EP1C3T100C8N FPGA configuration problem

Hi everybody,

In my design I use an EP1C3T100C8N cyclone which gets configured from an EPCS1 serial device.

EPCS1 is programmed from an external microcontroller that gets the data stream from a PC which reads an .hex file (generated with quartus II).

The configuration device seems to be correctly programmed because during verification, every byte of data reads OK.

But the FPGA cannot configure from the device. It is toggling DCLK, I can see what seems to be the first 128 bytes of configuration data going out at DATA pin (of EPCS1 device), but after that, the cycle repeats indefinitely.

CONF_DONE never goes high but nSTATUS is toggling which probably means an error is detected...

I have this particular thing in my system:

FPGA's nCE pin is driven from the microcontroller and nCONFIG is not(nCE). (a 74HC04 inverts nCE pin, so I only need one I/O at µC side).

So whenever FPGA should be started, the µC puts a '0' on nCE, the same time nCONFIG goes high, which should start the FPGA configuration process.

This means the delay between nCE is '0' and nCONFIG goes high is only the propagation delay through the HC04 gate. (a few ns...)

Can you help me find out what is wrong with my system??

Thank you very much

Whitebird

8 Replies

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

    I made some further investigation by looking at the signals involved in serial configuration.

    Now I know exactly when the cycle repeats:

    The first 128 bytes of my configuration file are:

    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6ADEFF4000682F03006ADEFF4000682F03006ADEFF4000682F030000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4455544455557475577775577675567675577765566665563625522225D2E3551A1551111551111551111551

    After receiving the first 44 bytes of data, FPGA switch nCS back to high level and DCLK stops to run.

    It seems there may be something wrong in the first 44 bytes (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6ADEFF4000682F03006ADEFF4000682F03006ADEFF4000682F030000)

    Perhaps this header (if we can call this header) is not matching the one of EP1C3T100C8N device??

    In Quartus II I have specified EP1C3T100C8 without N (it seems it is not possible to specify N)

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

    Hi Whitebird,

    You can omit suffix 'N' when you specify the device in Quartus II. The 'N' suffix indicate lead-free part. Can you program the EPCS1 device through FPGA's JTAG port using *.jic file? - Just to confirm that support for AS mode is wired correctly on the board.

    -BD
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Thank you for your answer BD SLS,

    I have no JTAG connexion on my board and cannot test EPCS1 programing through JTAG)

    Here is my wiring:

    MSEL0=GND

    MSEL1=GND

    INIT_DONE left not connected

    DATA0 (FPGA) <=> DATA (EPCS1)

    DCLK (FPGA) <=> DCLK (EPCS1)

    nCS0 (FPGA) <=> nCS (EPCS1)

    ASDO (FPGA) <=> ASDI (EPCS1)

    nSTATUS&CONF_DONE tied to 3.3V VCC through 10K resistor.

    nCE (FPGA) receives a '0' from µC I/O

    I tried to disconnect nCONFIG from 74HC04 and connect it directly to 3.3V VCC through 10K resistor (to be as the schematics in datasheet), but the problem is the same.

    Hope I have not omitted some pins involved in configuration, but as per my understranding, the AS mode is selected by grounding MSEL1-MSEL0??

    On my board, FPGA's CLK0 pin is constantly fed by a 16MHz 3.3V clock signal. Hope this cannot "disturb" FPGA during configuration process.

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

    Are you sure you converted HEX data into BIN correctly? I'd suggest to use *.RBF file (convert with quartus).

    Also, please check bit order when you are programming EEPROM. At least in PS mode, FPGA expects LSB first.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hi Vakaras,

    I think I am OK with HEX=>BIN conversion because after generating an RBF, (or RPD file, which contains all 131072 bytes of EPCS1) if I open the binary file with an HEX editor I can see all the bytes as they appear in PC memory where INTEL HEX file is loaded.

    But what your are pointing out about bit order is very interesting:

    If FPGA expects LSB first, because the read bytes instruction outputs MSB first, it means I have to program all bytes in inverted bit order...

    Thanks,

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

    I had a look at cyclone's datasheet.

    Unfortunately in AS mode, MSB is emitted first (see figure 13-1 AS Configuration Waveform).

    Whitebird.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    For those of you that got an EP1C3T100C8 equiped evaluation board, is it possible that you download my design to see if configuration runs well?

    The design is a simple 4 bits synchronous binary counter which receives clock on CLK2 pin and outputs on Pins 78, 79, 86, 87.

    It can be downloaded from http://musanek.free.fr/altera/

    The zip archive contains two programming files one in pure binary, the other is intel HEX format.

    Thanks a lot.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I have solved my problem!

    Your idea about bit order was right Vakaras.

    In fact cyclone datasheet is not very clear about that because in AS mode, waveform shows bit 0 going out last and in PS mode bit 0 is the first byte being passed to FPGA.

    I had a look inside configuration handbook mainly the chapter about configuration file formats (volume II). For .rpd files it is written "the LSB of each byte in the RPD should be written to the configuration device first".

    This is for RPD but same rule will apply to hexout file because the content is same (in terms of information, not encoding). (always the same strings 6AD7FF4000B0920900 in header)

    So I simply reverted bit order for every byte and now everything is OK.

    Thanks a lot.