Forum Discussion
Honored ContributorCombining AS and JTAG configuration schemes
Hi all !
I am a newbie in FPGA field. I am trying to design very simple Cyclone III FPGA board as follows * FPGA : EP3C10E144C7 * VCCIN : 1.2V * VCCD_PLL1,2 : 1.2V * VCCA : 2.5V * VCCIO (for Bank 1 ~ 8) : 3.3V * VREF of all banks are used as IO ports. * CLK0 ~ CLK8: are fed by 30MHz oscillator * Configuration scheme: AS combining JTAG (Fig 10-29 in Configuration Cyclone III device handbook) * MSEL[2..0] : 010 or 101 (High logic can be 2.5V or 3.3V) * Pin# 6 of JTAG connector can be removed if we do not want to connect to VCCA (2.5V) Unfortunately, I could not configure the FPGA via JTAG due to an error "Can't access JTAG chain". I could easily configure the serial configuration device EPCS64 by AS configuration scheme but the FPGA still did not operate after power on. I guessed that the EPCS64 device was not able to configure the FPGA in this case. Please tell me if there is any mistake in my FPGA setting. I greatly appreciate your help and kindness. Best Regards, http://img380.imageshack.us/img380/5334/f1dd2.png (http://imageshack.us) http://img380.imageshack.us/img380/830/f2im6.png (http://imageshack.us)16 Replies
Altera_ForumAs a simple fact, nearly all cases of "can't access JTAG chain" have a very basic reason, particulary missing supply or ground connections of the FPGA, missing supply voltages, open or shorted JTAG signals.
- Altera_Forum
Can you use an oscilloscope and see what the JTAG signals look like?
- Altera_Forum
Hi all,
I have the same Jtag configuration as that posted in the first thread and i have the same problem can't access JTAG I use EP3C25E144 thanks for your help - Altera_Forum
I had a similar problem. I made it work by simply removing the diodes.
- Altera_Forum--- Quote Start --- Is there anyone consider the ramping time upon power-on for the core voltage --- Quote End --- The said datasheet notice is not addressing overshoots. The point is to avoid I/O voltage drops, particularly when the configuration pins are located in a bank not powered by the same supply as VCCA. The power on reset is released, when VCCINT and VCCA have reached a specified level. If the IO voltage supplying configuration pins (MSEL, JTAG, PS, AS or AP related) isn't stable at this time, the configuration interface may take an unoperational state. That's it. The problem may arise, if 3.3V and 2.5V supply are generated by different voltage regulators and 3.3V is delayed. If you in contrast generate 2.5V by an LDO from 3.3V, the issue should never be seen.
- Altera_Forum
I'm not an expert on this, but I suspect that as long as the rise in voltage is monotonic, the ramp TIME is not very critical. I think what you want to avoid is having the voltage rise above some level, then dip below some threshold, then rise again to its final value.
- Altera_Forum
The main problem is to avoid, during the rise time, an overshoot above the security levels of the supply voltages. That's the main thing to avoid, especially when the "mother" supply voltage comes from a switching regulator.
The use of dedicated linear regulators for the FPGA and the configuration devices is always a good practice. - Altera_Forum
Hi all,
Is there anyone consider the ramping time upon power-on for the core voltage (1.2V), VccIO(3.3V) and VccA(2.5V) ? Altera requests that the VccIO, VccINT and VccA must have monotinic rise the their steady state levels, [refer to Fig. 11-3, Cyclone III device handbook]. Do you think the ramping time causes a serious problem for configuration device ? - Altera_Forum
I knowed, that the exposed pad has to be connected, but I wasn't aware of the consequences if omitting the connection. Considering the known ground-bounce problems of TQFP and PQFP packages, one must regard the connected exposed pad as valuable feature, however.
I agree, that the exposed pad hints in datasheet and pin information should be written in bold letters. - Altera_Forum
No, actually I just discovered the answer on the Altera website. It turns out the the EQFP package has an exposed pad on the bottom that MUST be connected to ground or the device remains in some kind of mysterious reset state. This piece of information is conveniently buried in the fine print in the device pinout documentation. Nice. I'm looking at thousands of dollars in rework costs. Makes me want to take a closer look at Xilinx.
