FPGA shield alpha
#1
Posted 12 November 2010 - 07:48 AM
Top:
Bottom:
Xilinx XC3S50AN 50,000 gate FPGA
64 IO available on 4 dedicated headers
16 IO available to Netduino (D0-D13, TWD, TWCK)
50 MHz clock oscillator
red/green bicolor LED
momentary pushbutton
JTAG pads available for advanced development (the six-pin right angle header at the top left corner, which would typically not be populated)
Some common questions:
What's an FPGA?
An FPGA is a Field Programmable Gate Array. Think of it as a huge array of logic gates (50,000 in this case), which you can configure to suit your needs. In addition, there are clock generators, dedicated multipliers, RAM, flash, and many other useful digital blocks. The logic is an order of magnitude faster than anything that might commonly be found on a breadboard, and it can be easily reconfigured when you move on to a different project.
What can I do with it?
All sorts of stuff. There are plenty of resources on board for applications ranging from basic glue logic to port expansion (essentially 64 more GPIOs) to PWM to motor control. More advanced applications might include high speed digital signal processing, buffered wireless communications, bus capture and digital waveform analysis.
How do I configure it?
Xilinx has made freely available a toolchain for their smaller FPGAs which they call Webpack. The logic structure can be described either using a Hardware Description Language (Verilog, VHDL) or by using schematic capture, basically drawing your gate arrangement in schematic form. Once the design is complete, a bitstream is generated and downloaded into the nonvolatile memory (flash) on the FPGA.
How is the bitstream loaded?
After the bitstream is generated on the PC, it's processed into a handful of resource files which are then deployed to the Netduino along with a script to program the bitstream into the flash on the FPGA. Once the bitstream is programmed, the FPGA will load that bitstream on every subsequent boot. No further intervention is necessary by either the user or the Netduino. For Netduino Plus users, the bitstream can also be written to a microSD on the PC, then transferred to the Netduino. Once on the Netduino, a script is run to transfer the bitstream from the microSD to the FPGA's flash. The microSD approach is the only option available to Netduino Plus users with the standard (48K) firmware.
Why is this even necessary?
The Netduino is a tremendously capable platform, and it's very well suited to many uses. There are two areas where the FPGA shield is able to supplement the Netduino, however: IO and real-time processing. The FPGA shield can provide an additional 64 IO, and depending on configuration, can do this while making all 14 digital IO pins on the Netduino available. As for real-time processing, some tasks like high-speed motor control, IR remote encoding/decoding, video, and sensitive asynchronous serial communications are beyond the abilities of the C# environment of the Netduino. They're either too timing-sensitive or too processor intensive to be feasible. These tasks could be offloaded to the FPGA, while the Netduino manages state and communications.
How/when can I get one?
If you're interested in being one of the alpha testers, please drop me an email at ward@prototype-eng.com and we'll talk. General availability will depend on the community's response, how the alpha test goes, and whether it looks like a beta's necessary. Within the next 2-3 months is not unreasonable if testing goes well and there's a healthy demand.
So fire away with questions, comments, and criticism...I look forward to hearing what people think. Thanks!
--Ward
#2
Posted 12 November 2010 - 08:08 AM
#3
Posted 12 November 2010 - 08:24 AM
#4
Posted 12 November 2010 - 08:36 AM
#5
Posted 12 November 2010 - 03:12 PM
#6
Posted 12 November 2010 - 05:34 PM
#7
Posted 12 November 2010 - 06:14 PM
#8
Posted 12 November 2010 - 08:41 PM
#9
Posted 12 November 2010 - 09:20 PM
#10
Posted 12 November 2010 - 11:04 PM
#11
Posted 13 November 2010 - 01:44 AM
#12
Posted 13 November 2010 - 02:27 AM
#14
Posted 04 December 2010 - 04:39 PM
#15
Posted 03 March 2011 - 04:26 AM
#16
Posted 04 March 2011 - 12:19 AM
#17
Posted 06 July 2011 - 10:33 PM
#18
Posted 01 August 2011 - 09:33 PM
- Mattster likes this
#19
Posted 01 August 2011 - 10:20 PM
#20
Posted 01 August 2011 - 11:20 PM
Individually control the intensity of 32 LEDs over 256 discrete levels (15mA or less per LED)
Control 32 hobby RC servos and/or ESCs
Control the speed and direction of 8 stepper motors, using external power FETs
Control the speed and direction of 16 brushed DC motors, using external power FETs
Using external RC filtering, generate voltages between 0V and 3.3V with very high resolution (>10 bit effective) on 32 channels.
Any of the above still leave 32 channels available for connection to sensors and actuators
Here's an example to illuminate an LED on channel 7 at 25% duty cycle (50% intensity):
using UberShield.Cores; //SPI config omitted for clarity, but it's pretty straightforward var spi = new SPI(spiConfig); var GP = new GpioPwm(spi); GP.SetPinType(7, GpioPwm.PinType.Pwm); GP.SetPwmParameter(7, GpioPwm.PwmParameter.Rise, 0); GP.SetPwmParameter(7, GpioPwm.PwmParameter.Fall, 2500); GP.SetPwmParameter(7, GpioPwm.PwmParameter.Period, 10000); GP.PwmGo();
Basically, that code instantiates an ÜberShield GPIO/PWM class, sets pin 7 to be a PWM channel (as opposed to input, output, or inverted PWM), sets it up to rise at 0us, fall at 2500us, and sets its period to 10000us (10ms, 100Hz). To make the LED automatically go out after 1.5 seconds, we could add to the end of that snippet, before the "PwmGo":
GP.SetTerminate(1500000);Note that everything's in microseconds, so that's 1500000us, or 1.5 seconds.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users