YASEP news

To content | To menu | To search

Electronics

Entries feed

Friday 2 October 2009

When you connect the power supply, it works...

As one can guess from the past messages on this "*log", I have been slowly preparing custom FPGA boards as a background activity. It's not an easy thing and can be quite expensive. So I patiently gathered the necessary parts through online stores and eBay, looking for interesting deals.

Finally I have all the necessary parts for a cheap and repeatable prototype. Among others :

* A bunch of A3P250VQG100 : I got them from a really nice Canadian guy and I'll use this specific reference as the main target for the future works. I originally intended to target the A3P125 but I got more powerful for less money so why refuse ? :-D The A3P250 has enough logic for moderately complex stuff (though SRAM is really TIGHT) and can replace microcontrollers in many cases.

* QFP100 adapter boards : FUTURLEC has cheap and good proto boards. The tin makes soldering easy, just add some liquid flux, no need for aditional solder.

With the help of Actel's docs and the schematics of other boards, including ACME's Colibri, I easily wired the power rails. The board is not recommended for high-speed signals but the goal is only to check the schematics for more ambitious boards (probably manufactured through FUTURLEC too, as their PCB pooling service looks great).

I created a small dumb VHDL design (8-bit counter with clock, reset and increment/decrement inputs) backed by a small board. The additional board also provides 3.3V from a battery, so I could avoid long wires from power supplies.

And in order to be programmed, the FPGA needs a JTAG interface. I soldered everything correctly but the JTAG/USB interface would refuse to work. After a small nap and many hypothesis, the problem was obvious : the JTAG signals were correctly wired but I forgot to wire the power supplies :-/ Obviously, when it's fixed, the things work considerably better... I'm amazed that it is the only error, considering my sleep deprivation :-D

First Actel proto board \o/

No, really, it just works as expected. I may have finally become good at this, after all the failures and false starts of the past :-D It even reproduces the strange behaviour that I had seen in other designs : the pins are REALLY sensitive ! Don't forget the pull-down's ! I made a basic/passive anti-bounce (just a RC filter) but it is useless : a single clock push creates many strobes and the counter advances unpredictably. But I half-expected it and I did not even register the inputs in VHDL so it is naturally glitch-prone, so I don't care. It "works".

What does this mean ?

* When enough resources are gathered, complex things become easier. I have invested a lot of money and time in the past years just to get to that point and ... it feels good !

* Great things that were "possible" now become "available" for future projects. This includes YASEP and other (commercial ?) designs.

* FPGA are damn cool ! Actel's chips are certainly slower and less capable than other makers but their products make this little board possible and easy : once the power supplies and the JTAG are (hum, correctly) wired, the board can be plugged in other cheap prototypes. No need of external Flash chip, bootstrapping EPLD, or whatever...

Next in line : a parallel port interface (hooked to a computer) then the SRAM chips :-D Then I'll try to develop an embedded CPU design with Ethernet that could replace the Rabbit, PIC and AVR. Finally, I wish to create an Ethernet-based JTAG programmer that will replace the proprietary and USB-bound FlashPro3. This proprietary probe is not extremely expensive (Actel has wisely created even cheaper versions) but USB is such an annoyance !

Saturday 4 July 2009

Probable new features

When a project has practical uses and implications, it is interesting to see how it evolves and better fill de gaps that a purely theoretical design would address. For YASEP, the modifications have been very deep, while many of the neat original ideas remain. Lately, there have been a few new ideas that may or may not be implemented.

  • A new CRIT instruction :

This is a method to perform atomic instruction sequences. It opens a HW-garanteed CRITical section, that lasts a few and constant number of instructions (1 to 16 depending on the imm4 argument). After/before this, IRQs and other things are checked, to prevent the system from hanging because of back-to-back CRIT instructions...

  • External bus expansion with off-chip buffers

In the case where the number of FPGA pins is low, a lot of them are used by external SRAM. The address and data bus could be used to expand the I/O count, by adding a few 74LVC574 and 74LCV245. In this case, a few specific instructions are required because the GET and PUT instructions work only with internal resources. Another issue is the bus loading that might affect the timings and/or speed. The Inputs and outputs could be easily separated, the output latches can be tied to the address bus (because it is unidirectional) while the Input buffers can only be tied to the data bus. Voltage translation is also a desired feature.

  • CRC32 accelerator

As the need for a zlib port arises, the necessity to check CRC32 signatures becomes a problem. I have already designed CRC routines and... well... they can become quite heavy. OTOH, it is rather straight-forward to do in hardware. I don't want to make yet another instruction here because this would make the pipeline more complex (and the number of registers is already too small) but a small set of SR will do the trick.

  • DMA for SPI

SPI is used when booting the CPU from a SPI Flash memory, or when communicating with Ethernet or 2.4GHz interfaces. Adding a simple DMA capability would save a lot of cycles and latency.

Other things will certainly come later...

Friday 24 April 2009

First Layout of a custom FPGA+SRAM board

I have not been fully satisfied by all the boards that I have seen. There are always details that don't match a project or requirements that are not met (size, price, features, whatever). So I finally decided to start my own board(s).

Firt route of a TSOP-2 SRAM to a A3P125 FPGA in VQ100

It seems that YASEP could easily replace microcontrollers that I already use. The flexibility offered by FPGAs and the ability to strip a thing down to the minimum, then expand on that depending on the needs, makes this solution more and more attractive. No difficult selection of features and package (as with fixed-function chips), put the FPGA on the board and route the pins...

I can't solder BGA package, or even build suitable PCBs myself, but I'm already able to make double-sided PCBs that can be fitted with a FPGA in 100, 144 or 208 pin in QFP package. I'll be able to reuse these designs in the future, or make my own cheap modules.

Friday 19 December 2008

How to double the SRAM capacity of a FPGA board ?

The FoxVHDL and the Colibri boards from ACME Systems come with 2 SRAM chips of 512K Bytes, so one application can benefit from one megabyte of 32-bit low-latency access. But even 1 megabyte may be too small for some uses. Some time ago, I found a way to extend the capacity : piggy-back soldering of another SRAM chip.

2 FoxVHDL FPGA boards from ACME Systems (modified by YG)

To keep the chips identical and avoid timing unbalance, I had to take the SRAMs from another board, but it is not a concern since this second board will be used for some purpose that does not need SRAMs.

I should stress of course that not only unsoldering, but also re-soldering is difficult, but it went well, thanks to special, adapted tools.

Of course, there is a trick : memory is not simply expanded this way. One has to reserve a new address bit, or both memories will be mapped to the same addresses. I have chosen to not connect the Chip Select pins of the additional chips, so they will be wired later to another unused FPGA output.

Two SRAM chips soldered on the footprint of one

If you want to attempt this hack on your board (whether ACME's or any of the other FPGA boards with static RAM), don't forget that adding pins on a bus adds capacitance, and slows the signals. The clock frequency won't be as fast as before, so make extensive tests to assert the new working parameters.

One way to keep the frequency high is either to use a larger SRAM chip (like Cypress or IDT 512x16b or 1Mx16 but they are difficult to find and expensive), or faster SRAMs : ACME uses 12ns chips, but other compatible chips are available with 10ns and 8ns access times (try Farnell). Also, you can control the rise/fall times with the I/O current options of the ProASIC3 pads, they can be set to several values.

Next step : using even higher-frequency, synchronous Static RAM, because they have a much higher bandwidth. However I don't know yet how to control the tight timings...