ProAsic3-Stamp

Details

One predecessor of the #DIPSY is this Actel-based prototyping/OEM board.

It may look trivial to build, but it uses the CN132 package of the Actel (Microsemi) ProASIC3 FPGA family. This is one of the worst packages: it is 3 row staggered QFN style package with 0.5mm pitch.

This is near to imposible to get it routed for 2 layers using PCB technology for low cost manufacturing. To my surprise the factory in Taiwan had almost 100% yield with this board.

The trick is that not all the pins are available. Only those that can be "escaped" have external pads. The small size limits the number of pads anyway and 30 GPIO is already more than necessary for many simple applications. Why use a microcontroller when you can reconfigure any pin to do anything at 50MHz ?

The FPGA was pre-programmed with soft-processor based on AVR Instruction set. Of course that was only the "demo" image, the FPGA was reprogrammable in system, the small holes are JTAG.

IMPORTANT: This is completed project, and it is not possible to produce any more 100% same PCB any more as the FPGA in this package is no longer available.

@Yann Guidon / YGDES still has some boards left (for his own prototyping needs) and uses this page to keep the documentation online, now that Mirifica (the last distributor) has shut down the archives.

Files

ST32PA3.pdf

STAMP60 User Manual

Adobe Portable Document Format - 1.00 MB - 04/28/2016 at 05:48

Preview

ST32PA3-AP8.pdf

Manual of the provided AVR-compatible microcontroller

Adobe Portable Document Format - 1.07 MB - 04/28/2016 at 05:43

Preview

Components

1 × A3P060 CN132 Logic ICs / Programmable Logic: FPGAs

1 × LDO 1.5V LDO 1.5V

1 × 50MHz Integrated Oscillator 50MHz

1 × SMD LED, Red 0402 sized SMD LED

1 × 100nF ceramic capacitors

Project Logs

Collapse

Power supplies and JTAG programming
Yann Guidon / YGDES • 09/04/2017 at 18:53 • 2 comments

Antti has "optimised" the design to use the as few pins as possible, for example the TRST signal is not routed (Antti justified this because the JTAG protocol always starts with a reset sequence). A pull-down resistor on the TCK pin would be great, but I don't have the detailed schematic of the board... Which becomes problematic because I don't know what's going on with the VPUMP and VJTAG pins. I can only suppose they're internally tied to 3.3V because TDO gives this voltage.

I've had quite a few weird problems with this board : first, I think it's preprogrammed so the initial configuration creates conflicts on I/O pins andthis increases the current draw (until a new configuration is flashed).

The connections are not great but I managed to solder them.

Another gotcha is related to chaining : one FPGA's TDO goes to the next FPGA's TDI. However, the JTAG signals do not invert the names ! The probe's TDO signal goes to the FPGA's TDO output, and the FPGA's TDI input is tied to the probe's TDI. Go figure.

But something more troubling happens with my FlashPro3 JTAG probe : connecting the probe to my circuit, where the VPUMP and VJTAG are connected to the FPGA's 3.3V supply rail, drops the 3.3V rail to about 1.8V. During the connection event, the scope shows a short-like drop with a slow recovery but that never reaches the expected 3.3V.

The short-like condition occurs even when the circuit is running, after programming, which creates weird behaviours. The probe must be removed, disconnected, to allow the circuit to work right again. I'm not able to measure the currents but I suppose it would be in the hundreds of mA, which can make my LDO warm...

I tried to "isolate" the VPUMP signal, through a 2K resistor : it's enough to "sense" the target's 3.3V supply yet prevent the FlashPro3 from drawing current. But it didn't work so VJTAG is causing this too.

This does not make sense, considering the data provided by Actel in Actel_ISP_HBs.pdf in Table 2 • Power Supplies :
VJTAG : 1.5 V / 1.8 V / 2.5 V / 3.3 V < 20 mA
VPUMP : 3.0 V to 3.6 V, < 80 mA

VJTAG shouldn't draw so much current that the 500mA-capable LDO drops don't to 1.5V...

I can't isolate VJTAG with another resistor because that signal is used to power the drivers that talk to the FPGA chain.

Is it a problem caused by the newer version of FlashPro v9 software ?

I couldn't test with the FlashPro4 probe (which is at home).

The couple of Stamps are programmed anyway so I don't need to solve this ASAP but it's still a burning issue...

Still battling the power supply issues.

I found that the next generation device : FlahsPro4 uses the last free pin to toggle the power supply:

https://www.microsemi.com/document-portal/doc_view/130804-flashpro4-device-programmer-quickstart-card

I haven't found yet the schematics of the FP3 circuit though. I just found this mention though :

I'm wondering if the problems appear because there are 2 chained FPGA. I'll split the JTAG chain to see if it solves the problem.

I hooked a lame "loopback" circuit to the FP3 and the FP3 still works (I feard I burned something). Something else must be going wrong. But the loopback works : on it, VJTAG is directly fed by VPUMP, which is 3.3V and can source 80mA. So this might be the key !

Instead of just isolating VPUMP from my VCC, through a resistor to allow autosense, let's just keep VPUMP and VJTAG tied together, isolated from the rest (and no resistor to prevent autosense).

The only problem is : chain scan fails with the loopback circuit...

"Vjtag is diconnected or shorted. Please check that the target board is powered"

It appears that VJTAG is tested before VPUMP is applied. So VJTAG must be pre-powered, but it sinks quite a lot of current, and VPUMP can't be powered as well because this would prevent VPUMP from providing the power for the rest of the sequence.

Anyway : Loopback testing is a good starting point.

So now what are the electrical properties ?

VPUMP : inactive : 17K ohms toward 0V.

VJTAG : disconnected:...
Read more »
USB to Anything adapter
Antti Lukats • 07/25/2015 at 12:39 • 0 comments

FT245 + Actel Stamp + RJ45 Connector, all designed to fit low cost plastic enclosure, 2 layer PCB.
Actel FPGA was programmed with AVR Compatible soft-core that loaded its program from I2C eeprom. FT245 protocol conversion was done by the embedded firmware.