What is the effect of nCE on passive serial configuration

[eMagii]

We have a board with two Cyclone 10LP FPGAs connected to a processor.

The processor runs u-boot/linux.

The configuration will be done in u-boot.

We would like to configure the FPGAs in any order,

and we might reconfigure an FPGA in a running system.

Each FPGA has unique nCONFIG, nSTATUS and CONF_DONE pulled up by 10kOhm

They share an SPI bus MOSI and SCLK, but has separate nCS signals connected to the nCE signal of the FPGA.

We do not use the nCEO pins.

The way u-boot works is that

* the CONFIG pin is pulsed low

* wait for STATUS

* write using SPI

* wait for CONF_DONE

Since we connect the SPI.CS to nCE, this is inactive during the CONFIG pulse.

I suspect that this means that the CONFIG pulse will be ignored.

Is there a document that describes this setup. I have only found documents where nCE is permanently connected in a chain starting with the 1st at GND and when all FPGAs are programmed with the identical bitstream and all nCE are tied to GND.

What happens when nCONFIG is pulsed low, and nCE is still high?

[NurAiman_M_Intel]

Hi,

Thank you for contacting Intel community.

nCE low= device enable

nCE HIGH= device disable

nCE was used when programming multiple FPGA device. When programming single FOGA device, nCE will be connected to GND(low).

Thank you.

Regards,

Aiman

[eMagii]

Thank You.

Unfortunately, that does not answer the question.

The application notes cover how you either design for a single device

or two devices connected together, forcing you to configure both devices.

We are using the FPGAs in a third way, where we can configure the FPGAs in an arbitrary order.

For this we need to know what happens inside the device when nCE is high, and the nCONFIG is pulsed low.

We suspect that we can do configuring the following way:

Start condition

nCE: high, MOSI: X CLK: low, nCONFIG: high

1. Pulse nCONFIG low and bring back high
2. Wait for nSTATUS high
3. Bring nCE low
4. Send configuration data LSB first and at least one more byte to ensure two more clocks
5. At this point CONF_DONE should go high
6. Bring nCE high (end of SPI transfer)
7. Test CONF_DONE which should be high or error
8. Wait until INIT_DONE is active before using the contents.

This is how the U-Boot and Linux kernel expects the S/W to be written.

The reason we think that this will work is that both our FPGA will see the surrounding signals the same way as the second FPGA in a chain of FPGAs.

[NurAiman_M_Intel]

Hi,

nCE is a input pin, hence it should always tied to low if you have only 1 FPGA connected to 1 flash. Kindly go to the link below for further information:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-10/c10lp-51003.pdf (page116)

Regards,

Aiman

[eMagii]

We are not using active serial, we are using passive serial, where a CPU has the configuration data in its flash and configures the device using an SPI bus where we expect to use standard SPI drivers.

this means that we pulse config, wait for status and then do an SPI transfer. nCE is high until the SPI transfer starts.

We are using TWO FPGAs, and we want to program them independently from each other.

That is why the nCE pin is not grounded.

This means that we are not connecting nCE of the first FPGA to GND and we are not connecting the nCEO of the first FPGA to the nCE of the second FPGA. This is how you do it if you always want to configure both FPGAs at the same time.

The nCE pin of FPGA #1 is connected to a GPIO pin of the MCU.

The nCE pin of FPGA #1 is connected to another GPIO pin of the MCU.

This configuration is not described directly in your datasheets or application notes, but this is how the *SECOND* FPGA works when you do passive serial configuration for more than one FPGA.

So please reread my questions, and please try to answer the question.

Any answer that says that nCE should be tied low fails to understand the question.

The question is what happens in the FPGA if you pulse nCONFIG low while nCE is high?

[NurAiman_M_Intel]

Hi,

Thank you for your explanation. Apologize for providing you the wrong page number, it should be page#122 for passive. I do understand your question.

Below diagram is per Intel recommendation to program the device. Eventhough the nCE pin was grounded, the device were still program independently from each other.

FPGA#1 will be program first before FPGA#2. When FPGA#2 was programmed, FPGA#1 will be disabled. Hence it is recommended to follow Intel's handbook per the diagram and link provided to avoid failure as it has been successfully tested.

Other than Intel's recommendation, Intel will not be responsible for any failure.

To answer your question on what happens in the FPGA if you pulse nCONFIG low while nCE is high?

nCONFIG low: reset

nCE high: device disable

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-10/c10lp-51003.pdf (page122)

Hope this clarify. Thank you.

Regards,

Aiman

[eMagii]

Could you explain how you program FPGA #2, without programming FPGA #1?

As far as we know, this is not possible, but it is a requirement for us.

Our design looks like:

We plan to have a programming cycle like this for Device 1 in our diagram.

As far as we understand, both Device 1 and 2 in our diagram are connected as FPGA Device 2 in your picture.

That is: the device will see nCONFIG pulsed low, while its nCE is high.

So we have the following questions about device #2 in the passive serial programming for multiple FPGAs.

• Can you confirm that device #2 in your diagram is reset when nCONFIG goes low even though the device is disabled (nCE is high)?
• Can you confirm that device #2 in your diagram is not affected by any transitions on DATA0, DCLK while the device is disabled (nCE = high)?
• Can You confirm that once the set number of configuration bytes have been sent on DATA0, DCLK any bytes following that are ignored.
• Can you confirm that once nCE goes low on device #, incoming data is accepted immediatel(no delay)?
• What happens with the I/O pins if nCE goes high after configuration?

We see that this is how it is going to look like for a full configuration.

Best Regards

Ulf

[NurAiman_M_Intel]

Hi Ulf,

Apologize for the delay in response . Please see my answer below:

• Can you confirm that device #2 in your diagram is reset when nCONFIG goes low even though the device is disabled (nCE is high)?

Yes, device #2 in our diagram reset when nCONFIG goes low. This is due to device #1 and #2 are parallel in the diagram, so both are reset if nCONFIG low.

• Can you confirm that device #2 in your diagram is not affected by any transitions on DATA0, DCLK while the device is disabled (nCE = high)?

Yes, device #2 in our diagram is not affected by any transition because the nCEO was connected to device #2 to send signals to nCE while device #1 is running. We program them one by one due to nCONFIG is parallel. Per my understanding, your design is not the same as ours, it is not parallel and does not depend to each other.

• Can You confirm that once the set number of configuration bytes have been sent on DATA0, DCLK any bytes following that are ignored.

Sorry, kindly clarify more on this statement.

• Can you confirm that once nCE goes low on device #, incoming data is accepted immediatel(no delay)?

Yes, incoming data is accepted immediately(no delay). There is only a requirement clock cycle. After device #1 is done configure, nCEO will send signal to nCE in device #2.

• What happens with the I/O pins if nCE goes high after configuration?

Device disable.

Thank you.

Regards,

Aiman

[eMagii]

The devices in our schematics do share the data and clock.

We expect to start the programming by asserting nCONFIG, wait for nSTATUS.

Once we have the first device ready to program

We plan to use a standard SPI driver as part of the programming.

This will, when called, pull the nCE low, transfer the configuration and at the end, it will pull the nCE high.

According to the datasheet, the chip would stop working with this approach.

A colleague of mine has tested this, and she claims that it appears to be OK to puil nCE high after the programming is complete.

We think that what actually happens is that nCE disables the programming of the device.

We also think that once the part is configured, it will ignore data, clock and nCE.

You have to pull nCONFIG low again to make the part react on those pins.

If it is so, then using standard drivers will work. If the device stops working after nCE is pulled high,

this approach does not work.

Right now I am planning to bitbang the configuration.

To maintain speed, I am thinking of having a routine which writes 32-bit words.

The problem is that the configuration memory is not an even amount of 32-bit words.

10CL025 = 5748552 bits = 179642,25 32-bit words.

I'd like to pad the last word with zero and send 179643 words.

This means I am shifting in an additional 24 bits into the device.

So please check again:

• nCE high during an nCONFIG low disables the device, but does pulling nCE high after the configuration is complete affect the device?
• What happens if I shift in 5748576 bits instead of 5748552 bits into a 10CL025?