Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Problem with CycloneIII custom board

Altera_Forum
Honored Contributor II
1,184 Views

Hi, 

 

I have a crazy problem with my design and I have no idea what I can do. 

 

I have designed a custom FPGA board. The board has an EP3C120F484 in combination with an EPCS64 config device. 

This board needs only 3,3V from an external power supply. 

The needed voltages 1,2V and 2,5V for the FPGA where generated from onboard power supplies. 

All VCCIO-Banks are connected to 3,3V. 

The board has an JTAG and an AS-interface. 

(MSEL0=MSEL2=MSEL3=GND MSEL1=3,3V -> AS standard POR) 

 

For functional tests of this FPGA board I designed a very simple testboard.  

The testboard has only a 3,3V power supply which powered the FPGA-board and several GPIO-loops for testing if all used GPIOs are connected from FPGA to the connector. 

 

But we need the FPGA board in another environment.  

The destination hardware for the FPGA board consists of many analog and digital parts which will be controlled by the FPGA. 

(This destination hardware has the same DCDC-converter as the testboard.) 

 

 

First part: 

Wherever we wanted, we could mounted the FPGA board on the testboard, on the destination hardware or in a "flying" construction. 

Everytime we could use the JTAG interface and we could configure the config device. 

But when we power up the FPGA board from any power supply (e.g. testboard, destination hardware, ...) the FPGA doesn't read out the configuration so the application doesn't start. 

Round 60µs after nCONFIG goes high nSTATUS goes also high. But we couldn't see any clocks on the CONF_DCLK line. 

 

By coincidence I removed the resistors from all 4 MSEL-pins.  

After that I measured the internal pulldown resistors from these pins. 

And I was surprised because I could measure values from 4R to 1,5Mohm. 

I repeated this measurement on a similar board (also an EP3C120F484) and here all 4 pins had the same values (round 11k). 

With this information I talked to our assembling company and they replaced the FPGA chip. 

We also measured the MSEL-pins on the removed FPGA. All 4 pins had the same values as before (4R to 1,5Mohm). 

The measurement of the new mounted chip shows 4 equal values (round 11k). 

 

Now we hoped that the FPGA starts booting when we power up. 

 

 

Second part: 

Before we replaced the FPGA chip, in every combination we could use JTAG. 

Now we have only one combination to use JTAG. 

But now, in this combination the FPGA reads out everytime the configuration and starts working.  

 

When we mounted the FPGA board on our destination hardware no JTAG is useable.  

But the config device can be programmed, verified and cleared. 

When we power up this hardware, the FPGA doesn't read out the configuration. There are no clocks at CONF_DCLK. 

We checked many and many times where the problem is. 

We had only replaced the FPGA chip, nothing more. 

 

To verify if the problem comes from the destination hardware,  

we made a "flying" connection from the testboard to the FPGA-board. 

For this test we soldered thick cables from power pads of the FPGA-board  

to the output of the 3,3V DCDC-converter from the testboard. 

 

But we was very suprised again. The board shows the same error. No JTAG communication and no boot up. 

We can reproduce this behaviour to 100%. Mounting FPGA-board on the testboard all is ok. 

Mounting in other combination nothing work. 

 

I checked all power lines and I can't see any difference between the combinations. 

Now in the working combination (FPGA-board is mounted on the testboard)  

round 60µs after nCONFIG goes high nSTATUS goes also high. 

But in all other combinations nSTATUS is low for the hole time. 

 

 

I tried also many suggestions from this forum (e.g. smaller resistors for nCONFIG and nSTATUS, removing capacitors from the EPCS-signallines,...). 

I absolutly don't know what I can do to solve this problem. 

 

But perhalps anybody has an idea. 

 

 

skos
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
213 Views

Hi, 

 

after many tests we found the problem. 

In the power plane of the FPGA-board there were some small power islands, which weren't connected with this plane.  

Since I have connected these islands to correct power pads, the board works fine in any combination.
0 Kudos
Altera_Forum
Honored Contributor II
213 Views

Seriously, no forum member would be able to detect this kind of problems from a distance. Unfortunately this things happens.  

 

Apart from a thorough visual inspection of layout and gerber files, PCB connection errors (open and short) can be detected by checking the gerber data against the net list with a full-featured gerber tool. Also the PCB manufacturer should be able to detect these problems, if you supply an IPC-356 net list with the gerber data.
0 Kudos
Altera_Forum
Honored Contributor II
213 Views

Yes, you're right. Nobody could find this kind of error. 

But if I had known that the problem is an layout problem then I had wrote my threat other. 

But we assumed that the design rule checker from our layout tool checked also this kind of errors. Now we know that is not the case. 

Additional to my threat some external experts checked the schematic and the layout data and they found nothing. 

 

By chance the error was found and we are happy. 

Until now we don't use this feature with IPC-356 netlists. 

But this is an very good tip.
0 Kudos
Reply