Cyclone III configuration

Thank you for the suggestion. Your interpretation was absolutely correct, by the way. I'm happy, that you finally understood my intention and apologize for any inconvenience.

Actually, some boards have problems with Altera Blaster, some with Terrasic, some hadn't ever. They are all using 3.3V IO.

I don't think that the overshoot problem is directly related to failing configuration. It's an additional issue, some kind of overshoot of course may cause double clocking. The overshoot observed with Rev.B USB Blaser is a special one, not cause by cable reflections but the used Maxim level translator, to my opinion. The overshoot has several 10 ns duration, longer than any possible cable delay. I don't have Terasic or Altera Rev. C Blaster at hand, I'll check occasionally how their waveforms look like.

You may be right, that using 2.5 VCCIO could possibly increase double clocking effects. I never used 2.5V VCCIO and didn't consider it yet as a means to get a more reliable JTAG interface.

I recently experienced a JTAG problem, where an onboard signal apparently interfers with TCK. It caused occasional double clocking when both signal edges coincided. The issue could be solved by reducing the interfering signal's drive strength, which was unnecessecary high.

I understand, that you´are generally searching for a reliable JTAG solution, had no bad experience with your own designs yet. This is my situation, mainly.

I can't answer your questions exactly. Fortunately, I'm not in a duty to do, but I would like to know myself. I want to perform some comparative measurements with different JTAG adapters, I have to collect them from customers or friends.

I already checked the Altera Rev. B Blaster. I previously stated, it produces overshoot due to it's special level converter. I fear, the explanation is too simple. Clearly, the level converter had been changed with Rev. C and Terasic Blaster, so one could easily suspect a problem related to this design detail. But Rev. B doesn't show severe overshoots or even double clocking with a lot of boards. There are problems with some designs only. I checked with EP2C35 Nios II Board and it's fully O. K., functionally and also looking at the signal quality.

I believe, the special Rev. B problem is in combining the MAX3378 level translator with a unsual low impedance (around 20 ohms) embedded stripline flex PCB as a cable. Possible impedance matching problems are shifted behind the JTAG board connector this way.

Some users replaced the flex PCB with an IDC cable for different reasons (more robust and flexible, not breaking as easily, needing a longer cable). This totally changes the impedance matching, cause an IDC cable outer conductor has about 150 ohms impedance to an adjacent ground wire, causing serious overshoots with a longer cable.

When I have time to finish the comparative measurements, I'll compile the results and present them at the forum.

Hi everyone,

To add to the confusion, I've made a couple of C3 designs (all with JTAG access, EPCS to be programmed with JIC files via JTAG instead of direct AS to save board space) before this thread was started. Here are the findings.

I made two identical, simple boards, 3.3V VCCIO for all banks including Bank 1. JTAG was referenced to 2.5V. One board worked fine from the get-go, no problems whatsoever. The second board was different. It just didn't want to configure, CONF_DONE stayed low. However, just touching CONF_DONE with a scope probe or even finger was enough to get it going. However, adding capacitance on the 3.3V line changed that, and that method didn't work anymore, neither did small capacitors to VCC etc. on CONF_DONE work. The solution came by shorting out nSTATUS to 3.3V VCCIO instead of the 10k pullup. Not even a 10ohm resistor worked, it had to be shorted. Now everything's fine.

On another design, Bank6 was 2.5V due to an LVDS clock interface and hence that bank's references were all to 2.5V. On that design, one prototype worked fine. On a subsequent revision, which had minimal changes and none to the configuration, it didn't want to access the JTAG. Checking the signals with a scope it's clear that the FPGA is continually trying to configure from the EPCS and after a few seconds "gives up". It boots fine from the EPCS if it's configured upon powerup. However, JTAG is inaccessible in such a steady-state, unless it's shortly after powerup (less than 5seconds). So, whenever I need to access JTAG for debugging or programming the EPCS (via JTAG), I just turn it off and on again, and quickly after powerup access the JTAG. Once the JTAG is accessed it's fine.

Any ideas?

True, it wasn't pleasant - only one design was mine, so it isn't a case of "designer factor". A lot of the clues pointed to voltage issues though, especially since the behaviour was sometimes different between using ByteBlasters or USB Blasters.

Since I use all 8 banks (EP3C40) on a new design and all of them needs to be 3.3V, would it therefore be best to use 3.3V for JTAG along with the clamping diodes and resistor limiter?

--- Quote Start ---

--- Quote Start ---

As lynx said, the e144 package has an exposed pad at the bottom of the package. this exposed pad is a ground pad that must be connected to the ground plane on your pcb.

(EP3C5, Pin-Outs, Note 6).

there is not connection between this pad and gnd. if this pad is not connected, c iii doesn't work correct

--- Quote End ---

--- Quote End ---

Hi, I am testing a new design that uses three Cyclone III devices including an EP3C5E144 part. I neglected to connect the exposed pad on the bottom of the E144 package to GND. The USB-Blaster connected to the onboard JTAG port is unable to recognize any devices. I have determined that the first and second devices in the JTAG chain resond to TDI with a TDO but the last device in the chain (the EP3C5E144) has no activity on TDO. Would this be the expected behavior if the exposed pad on the device bottom is not connected?

Thanks, Craig