Slashdot Mirror
Want a FPGA Board For Your Raspberry Pi Or Beagle Bone?
New submitter hamster_nz writes "Hot topics for the maker community are things such as embedded vision, Bitcoin mining, autonomous vehicle control, Arduino, Open Hardware, software defined radio, small ARM/Linux boards and reconfigurable computing. A current Kickstarter project, LOGi FPGA, is touching all these bases. Funding has been reached after just a day, and Kicktraq currently has it projected to reach over $133,000. As a long time FPGA enthusiast I'm very interested to see what will happen when a thousand keen users get together to explore programmable logic."
If you need an FPGA then check out the Spartan-6 LX9 MicroBoard. It is sold today for $89. You can synthesize MicroBlaze there, and you will have enough fabric left over to implement quite a few hardware blocks. It may be cheaper than stacking R-Pi or BBB and the add-on board. The kit comes with everything that you need to code for this thing (Xilinx ISE and EDK.)
I would have considered it with an LX45 or better LX75. I'll probably go with a ZTEX http://www.ztex.de/ 1.15b then instead. Is there anything comparable out there that I have missed so far?
If you already have a ARM processor, the FPGA will likely be used for real-time interfacing with the outside world - for example, many robotic applications. If this is the situation you are in then it might be worth looking at the Lattice iCE40 line of FPGA. They're small, cheap, use almost no power, and are programmed via SPI. The high-end versions have around 7500 LUTs so they are reasonably powerful.
There are some very inexpensive iCE40 developer boards on the Lattice website - between $25 and $40 (I believe). Makes for an inexpensive introduction to programmable logic. Just do not expect them to be as large and powerful as other FPGAs on the market. They were designed to compliment a CPU by interfacing and filtering sensor data thereby allowing the CPU to remain asleep for as long as possible. Most other FPGAs were designed to implement CPUs...
I have both the Zedboard and the SoCKit
The SoCKit is definitely the beefier of the two, as the Altera Cyclone V SX series FPGAs are far more powerful than their Zynq-7000 series counterparts.
However, the SoCKit has the most obnoxiously bad documentation that I've ever seen. The reference material from Arrow is extremely thin yet somehow still manages to have spelling mistakes in it that would prevent it from functioning if certain functions were enabled. Terasic's material "works" but Terasic does not include any documentation on the HPS whatsoever, just a prebuilt image and some C code to go with it.
I've spent the better part of the past 3 weeks just figuring everything out on my own. Altera's documentation is rock solid, but that only covers the FPGA itself, not the peripherals. Today was spent figuring out how the various clock sources are connected to the FPGA. Despite offering the exact same board in the exact same configuration, Arrow and Terasic provide conflicting and equally useless documentation. Sometime in the next couple of days I'm going to go probing at it with my scope.
The silver lining though is that I've been documenting that I've done, so I should be able to compile a very comprehensive and updated getting started guide in the near future. The ones on the RocketBoards wiki just don't cut it.
The Zedboard is accompanied by much superior documentation. The board design isn't as nice, but it's not as irritating to work with.
It does in fact have 64Mb or SDRAM (8MB). I wrote a SDRAM controller for it, that also works on the Papilio Pro...
I would think not. Bitcoin mining isn't cost-effective on FPGAs any more.
char*f="char*f=%c%s%c;main(){printf(f,34,f,34);}";main(){printf(f,34,f,34);}
I haven't found any hardware errata yet, just a truckload of missing, poorly written, or conflicting documentation. I'll provide you with a rough workflow that I've followed to get started. Feel free to ask me any questions.
Step1: Grab the Arrow lab material from the following link and work through them on Quartus 13.1. They're written for Quartus 13.0sp1 but they can be followed on Quartus 13.1 without issue. The only additional step is upgrading the IP cores from those packaged with 13.0sp1 to those packaged with 13.1; this will be done automatically when the sopc is opened in Qsys
http://www.arrownac.com/solutions/sockit/files/SoCKIT_Materials.zip
Working through the hardware side will get you a usable sof file to program the FPGA. Working through the software side will get you a usable preloader. Although the SoCKit is heavily based off of Altera's reference development kit (GHRD) the preloader is different in large part due to slightly different SDRAM specifications. Attempting to use the preloader included in Altera's SoCEDS will not work.
The programming stage of the documentation is a bit flawed. The reference configuration assumes a single JTAG device, but there can be more. At a minimum there will be one for the HPS, but a bank of two dipswitches on the board can enable JTAG for the HPS itself and any devices connected via HSMC. Just use autodetect to pick up all JTAG devices and program the SOF file to the FPGA device, it's very clear as to which is which.
Next, grab the github repositories for the linux-socfpga (kernel), poky-socfpga (base filesystem), and u-boot-socfpga (bootloader). Grab the latest version tagged with '-rel'. I used the following:
kernel: socfpga-3.9-rel
u-boot: socfpga_v2013.01.01-rel
poky: danny-altera-rel
The wiki on rocketboards can be followed to install the dependencies and begin compilation. I can verify that everything builds nicely on CentOS 6.5 without much fuss, Ubuntu is extremely problematic so I would avoid it.
If you look at the SD Card image that ships with the SoCKit you'll notice that it has a FAT filesystem with two files on it, socfpga.dtb and uImage. These are the device-tree-blob, and linux-kernel-image respectively. The kernel is in a u-boot image format, which is simply a zImage with an additional header. The bootloader that ships with Terasic's SD card image uses an early 2012 version of u-boot and does not support booting directly from a zImage. Support for this (bootz command) is present in the 2013.01.01 release of u-boot so it is no longer necessary to attach the additional header to the kernel image. Just configure and compile the kernel as a zImage as they do in the wiki.
An additional step is missing in the wiki (at least it was last time I looked). The dtb is tightly coupled to the kernel version. Using a dtb from the terasic reference SD image will work for kernel version 3.7, but it will not work for kernel 3.9 or above. The reference one created by Altera's sopc2dts tool is crap and won't work either. However, a working dtb has been included in the linux-socfpga tree under arch/arm/boot/dts/socfpga_cyclone5.dts. This can be compiled to a dtb either through the dtc tool itself, or in-situ by running 'make ARCH=arm dtbs'. This is good enough to get started with, but if you add additional memory mapped devices to your system you will have to modify it by hand and recompile it.
NOTE: the socfpga_cyclone5.dts file exists in the 3.9-rel tree, but has been replaced and expanded in master by one specifically tailored towards the SoCKit. I haven't looked at this yet, it's on my todo list. You may wish to check it out.
OTHER NOTE:The bootloader will look for socfpga.dtb by default. You can change the name of the file that it looks for by tweaking the bootloader environment settings (this is good practice) or you can change the name of the file when you copy it to the filesystem.
Expand the compiled
I'm curious as to what aspect of Altera's offering you find more powerful than Xilinx? The SocKIT is $1600, although they're practically giving them away if you attend the training ($100 I think for the training and the kit). The MicroZed is $200, the Zed $400. Sure, it's a smaller logic density device, but it works for proof-of-concept. I also like the inclusion of the many PMod adapters on the Zed board as opposed to the SoCKIT.
In general I find the devices are roughly equivalent. I would probably give the advantage to Xilinx for including the on-chip-memory on the processor subsystem side. I haven't looked at Altera as much, since they weren't ready in time for our application. I will say that I am extremely impressed by the Artix and Kintex fabrics. My impression was that Altera made a major mis-step at this node.
In my opinion, any of the above boards is a significantly better choice than an LX9.
Short version: I write FPGA code for a living: don't buy this kit. Get a Xilinx MicroZed, Zed, or Altera SoCKIT. It is a revolutionary improvement over what is offered in this kickstarter at a similar price point.
Long version: If you're interested in HDL and coming from the processor world (ARM), consider the Xilinx Zed, MicroZed, or Altera SoCKIT. The Zed is $400 (slightly less with an academic discount), the MicroZed $200, and I believe you can get an Altera SoCKIT board for $100 if you attend the training (if not, it's expensive at $1600). For a hobbyist, I would probably choose the MicroZed since it's the cheapest to buy straight-out at $200, or Zed if you wanted some of the PMod peripherals.
Any of the above boards offer significant advantages over the LOGi FPGA. The Spartan 6 LX9 is disappointing as a choice, as it's a very small, last-generation device. The current SoC offerings from both Altera and Xilinx pair a processor subsystem (PS) (dual Cortex A9) with a programmable logic (PL) subsystem via an array of standard ARM interfaces (AXI). I believe all of the Xilinx/Altera offerings have between 2,000 and 3,000 built-in connections between the PS and PL. This is a tremendous advantage and offers ridiculous amounts of bandwidth between the PS and PL. It allows unprecedented cooperation between the PL and PS that leads to significantly better performance than is possible with a discrete processor and FPGA combination.
Hi all,
i'am one of the co-founder of the project and i just want to address some of your questions/remarks:
Why buying a LOGI-board when you can get a zedboard/sockit ?
The zeboard/sockit are much more powerful than what the LOGI boards can propose and they will run much higher performance applications ... but they lack support from the software community, and are definitely a no go for a beginner. The Beaglebone and Raspberry-pi benefits of a great support from the software community and kernel development community, with our board we try to bridge a gap between the hardware and software community using the beaglebone/raspberry-pi + LOGI as a collaborative platform for the two. Give a kid a zedboard and raspberry-pi and guess which one he will throw to the bin in the end. The idea of stacking boards is to follow the progress of the user and had complexity when its time to.
Why getting a LOGI-board when you can get a DE0/MicroBoard for the same price ?
The computng power of the raspberry/beaglebone processor is far better than what you can get with a NIOS/Blaze and the linux support is great. Moreover you can program the logic from the processor (i did not say design the logic) while a Blaze can't. With the Linux of these boards, you also have access to a ton of software repositories. The LOGI-boards are designed with co-design in mind, when you use Blaze/NIOS you targets both ends of the co-design problem at the same time. With the LOGI-boards you can separate the concerns.
The price problem is also difficult, DE0 and MicroBoards are subsidized by the chip vendors (Altera/Xilinx) so they can be sold for cheap. We are not subsidized so the price you pay is closer to the price you would pay to build your own product.
Thanks for all your comments, and don't hesitate to ask for more information.
Jonathan Piat
The LOGI-bone is compatible with beaglebone and beaglebone-black. On the Beaglebone-black it will de-activate the eMMC because the lines are shared with the GPMC.
Hi, the Xilinx Web edition toolchain (free of charge) supports the spartan6 LX9. Synthesis time is a bit longer than when you own an "expensive" license but the LX9 is a small FPGA so you'll never wait too long to get the synthesis done. Regards, Jonathan Piat LOGI-team
Not sure its a good idea when you want to get into the game of co-design : dula core CPU + ManyCore + FPGA ... lets learn things one step at a time if you don't want to end up with nice piece of equipment taking dust in your drawer.
I would just like to quickly address a couple of these points that have come up in the previous posts: I would first acknowledge and concede that the current LOGi-Board offerings are not the latest, fastest, sexiest, FPGA boards on the market. There are a great deal of offerings and all having their respective strong points. The LOGi-Boards do not attest to competing with the latest SOC offerings with quad-core ARM A9 processors on-chip. The LOGi-Boards reveal themselves to the world in a humble Sparatan 6 TQFP manner. But, because LOGi is not fastest sprinter on the field, we believe that they have their place, right at the easy to use entry point to using FPGA with ARM. The current LOGi-Board offerings are our entry level with what we found to be the most cost effective per performance entry into the market. With the success of the current offering we hope to begin addressing the Camaro, high horse power offerings in the future! The point of the LOGi boards is to eliminate the time consuming, error prone procedure of creating a discrete, “perf” board, or other unreliable interface to the ARM platform. How long will this process take, what are the chances of getting the connections wrong, how well will it hold together if you decide you want to use in a project for long term usage. Do you have drivers to and API to quickly interface between the FPGA and CPU? If not do you have the skills to write your own interface drivers or API? How long will this take and how many hairs will you lose in trying to make things work? Based on on a previous post of a presumed experience HDL/Embedded user on this thread this is what you might expect “I've spent the better part of the past 3 weeks just figuring everything out on my own.” (See Re:ZedBoard, SoCKIT thread). 1) “Teach coders to be logic designers”. We make no such assertion of making coders logic designers, rather wish make FPGA’s reasonably accessible and workable from a coders perspective. I believe there is a vast contrast between being a “coder” and “logic designer” and we simply want to allow the coder to understand and be able to work with the grass on the other side of the fence. For those do not wish to learn HDL or deal with any “logic design”, we make a usable product for them as well with the LOGi-Apps. Simply download the latest pre-configured application and have it running with any of the above mentioned issues. 2) “Make it easier to learn the FPGA toolchain”. I am not sure where we made the claim of making it easier, but we do eliminate the need to use the toolchain completely if the user wishes. See previously mentioned LOGi-Apps. We do supply all of the existing wrappers and interfaces to make HDL development with said toolchain’s a greatly expedited procedure though. 3) “Enable anybody to do something they couldn't just as easily and affordably do before”. Our current offering may not be perfect, but have hope and goals of making things a little easier for those who may not have been very welcomed to the wide world of FPGA previously. If we are not there yet, well, I would say we are just getting started and will be there shortly! Happy FPGA/CPU to all!
Hi, don't be misleaded by the SATA port on the LOGI-pi, its just a connector for LVDS signals, but we don't have an IP (in the FPGA) that is capable of handling a SATA disk. Someone may work on this at some point, but the SPI bandwidth with the FPGA is limited to 3.8MB/s (rather slow for a SATA disk ...).
Regards,
Jonathan Piat
LOGI-team