We are using a Microcontroller to do this. We tested the programming software of the MCU on a Cyclone IV FPGA.
I’m finding this was very much easier to do. There are different MSEL schemes for Passive Serial vs Passive Parallel.
We also used an older version of Quartus to create the RBF file. We were very easily able to develop a software driver
And program this Cyclone IV FPGA many times successfully.
On the newer Cyclone 10, there is nothing to distinguish Passive Serial and Passive Parallel on the MSEL inputs. Why ?
So how does the FPGA know how wide the data is ? I could find this out anywhere and I have been reading many Intel documents.
I also check this out the Cyclone V, which also distinguishes between Passive Parallel and Passive Serial with different MSEL settings for each type.
Another change I noticed is that you previously did not have to adjust settings in Quartus to specify Passive Serial prior to now, it was all done in the MSEL inputs.
This makes me question whether or not the rbf file created has issues. How can we distinguish between and incorrectly created file or hardware issue?
Can you tell us the sequence of steps to successfully create an rbf image specifically for “Passive Serial” for the Cyclone 10 in Quartus 18 ?
I am asking this just in case we missed something. We are seeing nSTATUS go low during the attempted programming to indicate an error.
We have the ability to adjust the speed of DCLK, its currently set to 1 MHz (nice and slow) just for debugging purposes.
I have verified that data is stable during the rising edge of DCLK, and that data changes on the falling edge of DCLK.
Signals appear very clean. I have switched between “Fast Passive Serial” and “Standard Passive Serial” just to see if that would make a
difference. No change. Is there a way to create a known good rbf file passive serial for testing purposes ?
Which Cyclone 10 family are you referring to? Is it Cyclone 10 LP or Cyclone 10 GX device? Since you mentioned the "there is nothing to distinguish Passive Serial and Passive Parallel on the MSEL inputs", I'm assuming you are referring to Cyclone 10 GX family devices. Cyclone 10 GX MSEL pins for PS and FPP modes are the same settings. Where else Cylone 10 LP MSEL pin settings are different between PS and FPP mode. Please do take note that Cyclone 10 family are architecture not the same as Cyclone V or even Cyclone IV family devices.
The Cyclone 10 GX configuration process is similar to the Arria 10 configuration process. The Cyclone 10 GX configuration control block will look for certain data pattern during the passive configuration process. These data patterns are used to decode the data width in the passive modes and to determine if encryption, authentication and compression are enabled. Theses data patterns are not disclose for public use. You can refer to the following KDB for further information on this:
In general, the RBF files for PS and FPP mode are the same for any FPGA devices passive configuration process. Regardless if you set PS or FPP mode in Quartus, the output RBF files are the same. You can simply compare the RBF files and notice the data are exactly the same. Can you provide some screen shots the Quartus Device and Pin option settings and steps you did to generate the .rbf file?
You mentioned that you are using your own controller to perform the PS configuration. Did you follow the Cyclone 10 GX PS Configuration Timing Waveform and the PS Timing Parameters?
a. In Figure 145 "PS Configuration Timing Waveform" from the Cyclone 10GX handbook:
b. In Table 52 "PS Timing Parameters" from the Cyclone 10 GX datasheet:
Here are screen shots of the settings used to generate the RBF file for passive serial.
Any screen shots you may need in addition to these, let me know.
We are following the PS Configuration Guidelines. We are seeing nSTATUS go low during the programming.
I am assuming this is due to a CRC error. Can you tell me what is the size of a “Frame” for the Cyclone 10 ?
How many bytes should be sent before a crc error gets detected on the first frame sent.
Since we are not seeing INIT DONE go low, I have to assume the very first frame sent is not any good. Please let me know your thoughts!
Were you able to program the Cyclone 10 GX with the .sof file via JTAG? Please check on this. When the nSTATUS goes low during the PS configuration process, did the nCONFIG goes low or stays high? Did you check the POR power supply when the nSTATUS goes low? You need to check if any of the following POR monitored power supply goes fluctuate when the nSTATUS goes low.
How did you send the data sequence (.rbf file) during PS configuration? You must send the LSB of each data byte first. For example, if the .rbf contains the byte sequence 02 1B EE 01 FA, the serial data transmitted to the device must be 0100-0000 1101-1000 0111-0111 1000-0000 0101-1111.
We are able to successful program the FPGA using the JTAG port. But we still can't program the processor.
nCONFIG is always high when nSTATUS pulses low. It says high consistently throughout the sequence (except for the initial low pulse to starts the program).
None of the Voltages mentioned appear to fluctuate when nSTATUS pulses low.
The bit sequence is correct, we are testing with software that was already proven and verified to take care of this.
JTAG works by programming SOF directly. Passive serial from microcontroller fails. We don't program flash directly, as its not a dedicated flash. POF file is not an option.
Can you provide your schematic for me to check the dedicated configuration pin connection? You don't need to provide the full schematic, you can just provide the schematic that contains the dedicated configuration pin connection.
Have you got a chance to check the schematic? Here are more information:
The Voltage Level translators are from TI. TXS0104 and TXB0104. The TXB0104 is used only on DCLK and DATA0, because is higher speed.
TXB0104 is used for nSTATUS nCONFIG CFG_DONE and INIT_DONE
The inputs that are no connects, that we are questioning are:
CLKUSR is a no connect, will any of the high speed interfaces work if we do not provide a clock to CLKUSR?
nIO_PULLUP, DEV_CLR, and DEV_OE are also no-connects, hope they are not critical.
I have removed The 3.3V to 1.8V translators and wired in a 10 pin header for passive serial.
All attempts to program this FPGA from Quartus Prime using USB Blaster has failed.
I have tried this with both *.RBF files and also with *.SOF files
I have also tried this with RPD file, both with header removed and with header intact.
Programming with Quartus tools is a problem right now
Did you review my screen shots with settings on how the rbf file was built? did you see any issues with that ?
Please refer to the Cyclone 10 GX Pin Connection Guideline on the CLKUSR, nIO_PULLUP, DEV_CLR, and DEV_OE pin connection:
The pin connection guideline has explained clearly on each pin connection. At least the nIO_PULLUP does require to either be pull up to VCC or pull down to GND. The CLKUSR is used as the clock for transceiver calibration, and is a mandatory requirement when using transceivers. So, if you are not using transceivers, not using EMIF HMC, and not using this pin as a user-supplied configuration clock, then this pin can be use as GPIO. For DEV_CLR, and DEV_OE pin can be use as GPIO pins if you are not using it.
There are no issue with the Quartus setting for the rbf file generation. You can use the Convert Programming File utilities to convert the .sof to .rbf file and compare the data. The auto compilation generated .rbf file content should be the same as the .rbf file converted in Convert Programming File utilities.
From your schematics, I notice that you are using AS_DATA0 pin (Y4) and not DATA0 pin (AE5). The AS_DATA0 pin (Y4) is only use for ASx1/X4 configuration scheme while for PS and FPP configuration scheme you need to use DATA0 pin (AE5) pin. This is clearly explained in the Cyclone 10 GX Pin Connection Guideline. You need to change the connection using DATA0 pin (AE5) pin for PS mode.