Passive Serial Tri-state

Figure 8-16 refers to Passive Serial configuration mode. In that mode, DCLK and DATA are inputs, so there is no need for them to tri-state after configuration. The MSEL setting to select Passive Serial configuration mode essentially fixes those pins as inputs.

Notes 4 and 5 on the figure indicate that DCLK and DATA should be driven to a static high or low once you have configured the device. If the MCU SPI interface SCK and MOSI signals are driven to DCLK and DATA on the FPGA, as well as other SPI devices, then I would recommend using a couple of TinyLogic tri-state buffers to isolate the DCLK and DATA inputs from the MCU SPI bus. The tri-state buffers can be enabled for configuration, and then disabled afterwards. Pull-ups or downs on the buffer outputs can be used to hold the DCLK and DATA pins high or low.

The use of buffered DCLK and DATA signals ensures that you have good signal integrity on these FPGA inputs. I'd recommend including a source termination on the output of each of the TinyLogic buffers.

Take a look at this document for some other ideas;

http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf

Cheers,

Dave

The Data and DCLK are inputs in Passive Serial mode, so unless you specifically change the "Dual-Purpose Pins" setting in Quartus to make them GPIO's they will be inputs or tristated.

Check out: Assignments->Device->Device and Pin Options->Dual-Purpose Pins..

What pins are dual purpose may change from family to family. So make sure you are checking the pin settings for the device you need..

Pete

You suggested 'changing MSEL'. Altera states the MSEL pins should be connected directly to VCCA or GND and therefore should not be connected to any circuitry that can change them.

You won't need to do this to achieve what you need anyway. Ensure both DCLK and DATA are driven to a static level following configuration. Ensure you generate enough DCLKs cycles following delivery of the configuration data to clock the configuration state machine through and kick the device into life.

Cheers,

Alex

Hey Alex,

--- Quote Start ---

You suggested 'changing MSEL'. Altera states the MSEL pins should be connected directly to VCCA or GND and therefore should not be connected to any circuitry that can change them.

--- Quote End ---

I recently submitted a SR asking when the MSEL pins are sampled, and whether I could change the MSEL pin state, whilst holding the FPGA in reset, eg., so I could AS or PS mode configure a Cyclone IV. I was directed to this interesting KB entry:

http://www.altera.com/support/kdb/solutions/rd04032002_3872.html

So you can change the MSEL pins, but only before the FPGA actually configures. Changing the MSEL pins after it has read them will have no effect.

I'm posting this here, since you might find it useful :)

Cheers,

Dave

Hi Dave et al,

Thank you for your help. Very useful!

In our system, we employ a NIOSII processor. So ideally we could create a single RBF composed of SOF and ELF data then load that over the PS interface. Is it possible to do it that way? (I read about the RBF file in section A.2, page 63 of the FPGA CONFIGURATION pdf)

Presently, we do something similar over JTAG with the "nios2-configure-sof" and "nios2-download" command from shell...

--- Quote Start ---

In our system, we employ a NIOSII processor. So ideally we could create a single RBF composed of SOF and ELF data then load that over the PS interface.

--- Quote End ---

No, the PS interface is only for the FPGA configuration data, eg., SOF file.

If you had an ELF image that was supposed to go into on-chip RAM, then that would be part of the SOF image (via a .mif or .hex file).

--- Quote Start ---

Presently, we do something similar over JTAG with the "nios2-configure-sof" and "nios2-download" command from shell...

--- Quote End ---

Right, the first configures the FPGA, and the second downloads code to "somewhere". If that "somewhere" is off-chip SRAM, then it does not make sense to make it part of the RBF file.

Does that make sense?

Cheers,

Dave

Hi Dave,

Yes, this makes sense. Indeed our code is off chip. So we will need to modify our bootloader.

Thank You!

--- Quote Start ---

Yes, this makes sense. Indeed our code is off chip. So we will need to modify our bootloader.

--- Quote End ---

That sounds about right; your RBF is used to PS configure the FPGA, which includes a NIOS II processor that boots from on-chip RAM, that on-chip RAM contains the bootloader that then starts the system. eg, by reading data from some external bus (flash, SRAM that your processor has written to, etc).

Cheers,

Dave

Notes to Figure 8–16 in Cyclone IV Device Handbook, March:

(1)... (2) ... (3) ...

(4) In user mode, drive DCLK either high or low when using the PS configuration scheme, whichever is more convenient.

When using the AS configuration scheme, DCLK is a Cyclone IV device output pin and must not be driven externally.

(5) Do not leave the DATA[0]pin floating after configuration. Drive the DATA[0]pin high or low, whichever is more

convenient.

They didn't say drive staticlly. I think you can connect other pin to these two net directlly.

This should also true for pins nStatus and CONF_DONE.

--- Quote Start ---

They didn't say drive statically. I think you can connect other pin to these two net directlly.

This should also true for pins nStatus and CONF_DONE.

--- Quote End ---

You should *never* drive nSTATUS. If you "read the fine print" you would note that nSTATUS is an input, if this pin is driven low, then the configuration is cleared.

The most conservative approach to interfacing to the configuration pins on an FPGA using a processor is to actively drive them during programming, and then statically deassert the signals. If you cannot statically deassert the processor pins, eg., because you want to use the SPI interface for accessing other devices, then you should *isolate* the configuration pins by using buffers.

Sure, this is conservative, but buffers are cheap, eg., Fairchild and TI LittleLogic and TinyLogic buffers.

Cheers,

Dave