Custom Lattice MachXO2 1200HC Board

[iMo]

Black circles.
It is not a problem electrically (it is actually as you did fragment the GND plane - not good for fast circuits).
Your router did not include the tracks into the GND plane, only the A and B vias and the track will act as an antenna.
Most probably you forgot to name the vias 'GND'..
If you do then all the excessive tracks will disappear (will be included into the GND plane) and you get a nice not fragmented GND plane..

[iMo]

When the vias were called 'GND' then the vias would be incorporated into the GND plane like this:

[iMo]

Back to the major issue:

I tried a fresh, new board from OSH-Park and I still get short circuits no matter what I do.

Where you see the shorts?

[soFPG]

I don't see any shorts I just measure them with my continuity tester between 3V3 and GND (only FPGA soldered to the board - no caps or resistors).
Maybe my pinname assignment is wrong (I created the MachXO2-footprint myself) - but I think I also double checked that.

[David Chamberlain]

Perhaps you routed the grounds as traces first and then added the ground fills. Just delete those ground traces and drop vias to the ground plane from each topside ground pad then refill the fill.

Does your router have a Design Rule Checker? It will find shorts and other issues.

[iMo]

Maybe my pinname assignment is wrong

Double check that again, and also double check your chip has been positioned properly during soldering (because I miss the usual PIN1 silk mark on the PCB).

[soFPG]

Does your router have a Design Rule Checker? It will find shorts and other issues.

It has - no shorts only silk-screen issues (I don't think they add anything to this problem).

(because I miss the usual PIN1 silk mark on the PCB).

It somehow is directly placed on a via - that's probably the reason why it is missing on the actual PCB from OSH-Park.

Perhaps you routed the grounds as traces first and then added the ground fills. Just delete those ground traces and drop vias to the ground plane from each topside ground pad then refill the fill.

I actually created the GND plane first but a few pieces didn't get any GND connection so I had to create traces / vias to get them connected to the plane. So you say the badly designed GND could be a potential problem?

and also double check your chip has been positioned properly during soldering

I also did that.

[iMo]

So you say the badly designed GND could be a potential problem?

For the purposes of checking the JTAG programming and running a blinking LED alike demos, not a problem.
The UPduino v1 does not have any GND plane/fill and it works.

For purposes of a mass production of your board I would highly recommend to fix it.

Still the Q is what are the other issues with your JTAG signals integrity..

a) are the JTAG signals routed at the Mach's JTAG pins properly?
b) are there correct voltages at the Vxx pins?
c) are all gnds routed at respective pins?
d) what is the board's current consumption (no clock applied) in the 5V rail?

[soFPG]

The short-circuit signal does not come from my soldering but from the FPGA. I checked VCC and GND inputs (QFN-Pads) and they are somehow connected (continuity tester is beeping).

a) are the JTAG signals routed at the Mach's JTAG pins properly?

I think so. I attached a picture of pin to signal name mapping and they are equal to mine. Because I testet the QFN pads directly and VCC and GND pins matched up with my schematic I guess my pin mapping is correct.

b) are there correct voltages at the Vxx pins?

Yes

c) are all gnds routed at respective pins?

Yes

d) what is the board's current consumption (no clock applied) in the 5V rail?

How do I check that?

[iMo]

As I wrote above do NOT use the continuity tester but the OHMmeter. The 'ohm' values are important in understanding the issues..

Vcc and GND is of course connected inside the FPGA. There are ESD protection diodes at each pin (2-4pieces/pin) connected with anodes to GND (lower side diode) and with cathodes to Vcc (higher side diode).

[soFPG]

As I wrote above do NOT use the continuity tester but the OHMmeter. The 'ohm' values are important in understanding the issues..

Oh, okay. There is just a single '1' if I connect GND and 3V3 - I guess that means infinity?

[iMo]

Test your ohmmeter - shorting the leads - 0.000ohm, 4k7 resistor - 4700 or 4.700, open leads "0.L" or "0L", or "1", for example.

[soFPG]

The 220Ohm resistors for LEDs are measured correctly as well as shorting resistance. But the TCK pulldown is only 60Ohm even though it is a 2.7kOhm resistor (2701 marking)

[iMo]

    d) what is the board's current consumption (no clock applied) in the 5V rail?
How do I check that?

+5V_power------> +Ampermeter Ampermeter- ----> +5V_board board_GND -----> GND_power

When measuring Ampers always start from the highest range. After the measurement always switch to Voltmeter (otherwise you may blow the protection fuse inside).

[soFPG]

d) what is the board's current consumption (no clock applied) in the 5V rail?

9.34 mA

[iMo]

That is much more I would expect. Does an LED lite ON when powered?
What is your voltage regulator type?
Hopefully you do not apply +5V directly on the chip's Vcc (you must have voltage regulator from 5V to 3.3V wired in).

PS: according to the datasheet the static current of your chip is 3.5mA.
That would mean the voltage regulator's current is ~5.8mA (provided the LED does not lite).

[iMo]

In 2013 Lattice indicated an intention to include FT232H into DProgrammer (re MachX02)
https://www.mikrocontroller.net/topic/300043#3236988
As I wrote JTAG over the FT232H works here with Radiant Analyzer (a part of Radiant IDE for iCE40UP).
Radiant is a 2018 product.
The other discussions I've seen indicate the flashing the eeprom with FTxxxx settings does not help with 232H either. Could you check whether your Mach IDE includes the Analyser?

PS: while digging in the Lattice's knowledge base I've found following hints:

... You can try to increase TCK pulse width through programmer, you can change this value from 1-30 in Diamond programmer at RHS of Diamond Programmer 3.8 from "TCK Divider Setting (0-30X)" settings.

h) Have you provided proper pull-up and pull-down on JTAG pins?
- The TCK of the JTAG port must be pulled down using an external 4.7K resistor and the TDI/TDO/TMS must be pulled HIGH...

You may try to add the 3x 1k-3k3 pull-ups at those TDI/TDO/TMS.

Finally I've found the JTAG and ispEN, PROGRAMN, TRST, TCK clock, etc. settings in the Diamond Programmer -> Download Debugger - Cable and I/O Port Setup (or Options too)

[soFPG]

Does an LED lite ON when powered?

No, I don't use a power LED even though it would be nice to have one, but I forgot to implement it.

What is your voltage regulator type?

HT7133 (https://img.ozdisan.com/ETicaret_Dosya/354460_2643812.pdf)

That would mean the voltage regulator's current is ~5.8mA

The datasheet I linked above does mention power consumption, but it is max. 5µA, so basically 1000 times lower.

As I wrote JTAG over the FT232H works here with Radiant Analyzer (a part of Radiant IDE for iCE40UP).
Radiant is a 2018 product.
The other discussions I've seen indicate the flashing the eeprom with FTxxxx settings does not help with 232H either. Could you check whether your Mach IDE includes the Analyser?

I don't think that the FT232H is the problem - it is properly recognized by the IDE and it produces a JTAG signal.

Lattice Radiant only supports iCE40 Ultra plus (http://www.latticesemi.com/latticeradiant). Also Lattice Radiant and Lattice Diamond are two separate products - I don't think one of it is integrated in the other one.

The Diamond Help file is talking about a "Reveal Analyzer" to trace signal data from the FPGA. I don't see a Radiant Analyzer in the Tool-Section.

You can try to increase TCK pulse width through programmer, you can change this value from 1-30 in Diamond programmer at RHS of Diamond Programmer 3.8 from "TCK Divider Setting (0-30X)" settings.

I already tried that option - didn't help.

The TCK of the JTAG port must be pulled down using an external 4.7K resistor

I use an 2.7K resistor but that shouldn't matter too much (I guess)?

TDI/TDO/TMS must be pulled HIGH

They don't say that this should be done with an external resistor so I guess this is part of the JTAG device?

Finally I've found the JTAG settings in the Diamond Programmer -> Download Debugger - Cable and I/O Port Setup (or Options too)

Are you referring to this menu?

Edit: Yes, you are.

[iMo]

Quote

    What is your voltage regulator type?

HT7133 (https://img.ozdisan.com/ETicaret_Dosya/354460_2643812.pdf)

Quote

    That would mean the voltage regulator's current is ~5.8mA

The datasheet I linked above does mention power consumption, but it is max. 5µA, so basically 1000 times lower.

Hmm, while reading the datasheet it is 30mA reg only (no info on abs max current). The 5uA is for no load. Your load is at least 3.5mA. But still it must be much less than 5.8mA.
What could be an issue is the 30mA output current only. It is not much, frankly. The UPduino is a low power iCE40UP and it uses LM1117 800mA regs. There are transients at the power-up (in-rush currents into capacitors, etc)) thus the proper power-up sequence of the fpga could be in danger..

When you lit ON your three LEDS it is + 15mA.
When the fpga will run at 100MHz it is + 30mA easily
In total 9.3+15+30mA.

Programming current is 22mA.

[soFPG]

I also have an AMS1117 here but unfortunately the Vin and Vout pins are reversed

http://www.advanced-monolithic.com/pdf/ds1117.pdf

thus the proper power-up sequence of the fpga could be in danger..

I don't know how fast the FPGA boots up and my voltage meter is rather slow in updating measurements but the current consumption climbs from 8.4mA to 9.3mA and never goes above that.

When you lit ON your three LEDS it is + 15mA.
When the fpga will run at 100MHz it is + 30mA easily
In total 9.3+15+30mA.

Programming current is 22mA.

I guess I underrated the power consumption
(But I also used the HT7133 on a custom ESP8266 board, which draws around 150mA while transmitting data via WiFi).

[iMo]

You must rethink the voltage regulator's current ratings. I would definitely not go below 100mA for the MACH fpga only.
It may work, but it would not be a good engineering practice to put a 30mA regulator (as per datasheet header info) onto a pcb which may consume 50mA when blinking the leds, or 22mA when programming the fpga..

MachX02 power consumption estimator: search for "TN1198 - Power Estimation and Management for MachXO2 Devices"

[soFPG]

I just desoldered the voltage regulator and used the 3.3V from a USB/UART converter - didn't help.

[iMo]

Reveal Debug: The Lattice Reveal debug tool is an embed-able logic analyzer tool. It allows you to analyze the logic inside the MachXO2 in the same fashion as an external logic analyzer permits analysis of board level logic. Reveal access is only available via the MachXO2 JTAG port.

Try to run the RD, whether it recognizes the FT232H.
The actual debugging will not work as you have to insert a piece of verilog into your design.

Also you have to confirm the JTAG pins are ok, to move forward.

[soFPG]

Try to run the RD, whether it recognizes the FT232H.

It does recognize the FT232H but it is unable to detect the debug device (it sends a JTAG signal to the FPGA - and that's not working of course).

[iMo]

Yes, in case of RevealDeb the JTAG device is "soft" and created by a chunk of verilog source added to your design.. It uses user defined JTAG pins.
PS: in Radiant IDE you create the soft JTAG and LA by the "Reveal Inserter" and then you run the Reveal Analyzer