Forum Discussion
Honored ContributorIn-System Programming with Cyclone III
Hello,
I have a custom board that uses the Cyclone III (EP3C40 - 240 pin) FPGA. The board has two headers for connecting to the ByteBlaster II. One of the headers is used for JTAG configuration straight to the FPGA to program the logic. This one works fine. The other uses the Active Serial In-System Programming configuration with a flash device (I have EPCS16). I've been able to program the serial configuration device in Quartus II using AS mode on the 'Programmer' window. I was able to Program/Configure and Verify (two check boxes selected) which programs to completion (100%) in Quartus II. The problem I've come across is that this doesn't seem to program my logic into the FPGA.. The logic design in VHDL is just a serial in parallel out shift register... I just had something simple to start with to test the board basically. So I have tested this logic which appears to work fine under ideal environment (dummy data and low freq clock signal) whenever I program the FPGA on it's own using JTAG mode. When I try out the AS mode with the EPCS16 the logic does not seem to be programmed in the FPGA (as my output from the shift register is all 0's no matter what input is used). Just curious if there are any good tips/other parts of the Quartus II software I should be aware of?? I've tried also setting the MSEL pins to: MSEL[2] = 0, MSEL[1] = 1, MSEL[0] = 0... for active serial mode. I've tried this after programming the EPCS16 device, disconnecting power and programming cable from the board and then resupplying power to the board in hopes that the FPGA will be configured directly from the configuration device. Also, I just read a ditty about SFL (Serial FlashLoader) in an370, I don't know if maybe I need to use this, but it looks like a lot of work to get Quartus II using the SFL files for a workaround.. I am using the free web version of Quartus II v.11 so I'd like to avoid having to buy into any megafunctions or purchase the full software suite just for configuration. I've attached a snapshot of the In-System Programming electronic configuration that the board is using: Ok any help is much appreciated!! Thank you in advance!! ~doddy12 Replies
Altera_ForumHow do you set the MSEL pins to 0 or 1? They need to be hard wired to ground or 2.5V, not controlled through a register or a microcontroller, as the FPGA could get a wrong reading on the MSEL pins when it starts up.
Did you try to see with a scope if the FPGA is trying to read the flash when it starts? What are the levels on the nSTATUS, nCONFIG and CONF_DONE signals?- Altera_Forum--- Quote Start --- How do you set the MSEL pins to 0 or 1? They need to be hard wired to ground or 2.5V, not controlled through a register or a microcontroller, as the FPGA could get a wrong reading on the MSEL pins when it starts up. Did you try to see with a scope if the FPGA is trying to read the flash when it starts? What are the levels on the nSTATUS, nCONFIG and CONF_DONE signals? --- Quote End --- Hi, Yes the MSEL is set using jumpers on the board. Basically the pins are jumpered either to gnd (all ground when I do JTAG mode) or to 3.3V I beleive actually.. I'll have to double check this on my board to see the voltage, but I beleive 3.3 is what was required, and I'll be sure to check the voltage on the board and get back on this. Either way though, yes it isn't controlled by any pins from a register or uC. I'll also have to invest in a scope (been on my wish list for a while now..). Thank you for the suggestions, I'll have to get some proper equipment and get back with results and possible more question! :) ~doddy
- Altera_Forum
The documentation (http://www.altera.com/literature/hb/cyc3/cyc3_ciii51016.pdf) states on page 9-11 that the MSEL pins should be tied to GND of VCCA, which is 2.5V. I can understand the confusion with the "configuration voltage" column in table 9-7,that states the voltage level of the configuration pins (i.e. those connected to the configuration device) and not the voltage level of the MSEL pins themselves. That said IIRC the MSEL pins don't have clamping diodes and only have pull downs, to tying them to 3.3V instead of 2.5V shouldn't damage the FPGA. However you may set the FPGA in a bad configuration mode if the 1.2V and 2.5V supplies start and reach their required voltage level before the 3.3V supply. It is hard to tell because I don't know at what moment exactly the FPGA samples the MSEL pins.
You can also check the nSTATUS, nCONFIG and CONF_DONE pins with a voltmeter, just to check what state the FPGA is in after you powered up the board. And also, the JTAG configuration mode can always be activated, whatever the MSEL pins are. So you can keep your MSEL pins in the AS configuration and still use JTAG to configure the FPGA if you want, there is no need to change the switches settings. - Altera_Forum
Thanks for the feedback again. That is very useful to know that JTAG mode sort of overrides what MSEL has been set to and certainly saves me time from having to switch those darn jumpers every time I go to program the FPGA. Thanks also for clearing up that issue with VCCA and the 'configuration voltage'. I beleive that my configuration device is a 3.3V device but as you pointed out, this is separate from the MSEL voltage itself. I'll have a look at the nSTATUS, nCONFIG and CONF_DONE pins and get back. Unfortunately for this project, it is a home brew thing so my hours dedicated to solving these issues are minimal and my equipment at home is either broken or non-existing. Your suggestions are a great place to start once I get organized! Thanks again,
~doddy - Altera_Forum
I've finally gathered some needed equipment which includes a digital oscope (and finally a decent DMM). Here's what was measured for pins:
-nSTATUS has a 3.4Vpp signal with 80% duty cycle and freq of 3.58 kHz. -nCONFIG floats at 3.3V high shortly after applying power -CONF_DONE stays low (some noise with about 25mVpp centered at 0V) So it looks like the MSEL (and by the way these are set with High at 2.5V, thanks again for clearing up the confusion) does set up the AS mode but the configuration does not complete. I let the board stay on for a good couple minutes just to be sure that I waited long enough to allow configuration to complete, but these signals remained constantly at the states mentioned above. Just to note aside, I checked the trace for the CONF_DONE pin just to be sure there wasn't a lifted trace. It is solid. Any further suggestions to look for? I'll have to read up on the behavior of the nSTATUS pin; does this measurement sound odd at all? Thanks! - Altera_Forum--- Quote Start --- I'll have to read up on the behavior of the nSTATUS pin; does this measurement sound odd at all? --- Quote End --- Yes. Very odd. See this document for examples of the configuration signals. http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf Eg. see p4 for the idealized response of the nSTATUS signal. The document is written for PS mode, but the control signal states are the same for AS mode. The main difference is that the FPGA generates DCLK to the serial memory. You don't have anything driving DCLK do you? Eg., you haven't put a buffer on your Active Serial header? This would cause a driver conflict and configuration would fail. Cheers, Dave
- Altera_Forum
A simple test that should be always done is verifying the EPCS content in Quartus programmer. If it fails, there's most likely a problem with the programming interface, e.g. signal quality issues. Otherwise the EPCS to FPGA interface and related signals should be thoroughly checked. Also in this case, signal integrity might be the problem, e.g. double clocking due to ringing DCLK signal.
Not directly related to the problem, but I don't agree about difficult usage of indirect JTAG programming (SFL). I'm using it since many years for all designs with AS configuration scheme. - Altera_Forum
Thank you both for the replies. There is indeed an issue with the DCLK signal. The high level has some serious ringing (basically no settling on the high level) and there is also a strange element just before the rise of the clock signal. I am getting a short pulse just before each rise of the clock. I'll have to get a snapshot of the signal off my oscope and paste it onto another post here, but it does look like I need to clean up this signal.
I do not have any external circuitry driving the DCLK signal. It is the FPGA that drives this signal though yes? The only circuitry going to the AS header is the diode to 3.3V rail and the 10pf cap to gnd, but the line goes straight from FPGA to EPCS. Would it be advisable at all to use a larger capacitor here? Thanks again for all the help, this certainly narrows down the problem. So for the SFL configuration, is the setup primarily done in Quartus tool to generate a .sof file for programming, and the circuit is just configured as I would for AS mode? My board has two headers, one which is set up for AS mode with the configuration device, and another which is for JTAG mode. So programming indirect JTAG mode, I'd assume that I would still connect my blaster to the header for AS mode yes? And then do the appropriate set up for the .sof file? Or am I way off track? Thank you, I'm learning a lot! Sorry if these are basic questions, I'm still very new to Altera tools and FPGAs. ~doddy - Altera_Forum
The description of DCLK sounds symptomatic of a poorly terminated transmission line. Does the DCLK signal from the FPGA have a series termination or perhaps a 0-Ohm stuff resistor that you can change to a non-zero value?
Cheers, Dave - Altera_Forum
Interesting.. There is no series termination or 0-ohm resistor but I almost wonder if perhaps I botched my soldering job of the EPCS device. I'll also take a look at another test point for the signal, like the pin of the FPGA (pin 23 for DCLK on this one) just to check if there is a more clear signal at the transmission side. I'd think that the reflection will still be apparent at this end since the trace is pretty short, but I'll have a look there anyways.
I guess a couple of things to post back with once I get back home to have a look. Thanks again for suggestions.
