Recently I was asked this question by a reader: “Is it possible to make a design large enough to make the FPGA melt?”.

I don’t know why you would want to melt an FPGA, but the idea is interesting so its worth writing about. I’ve actually had people tell me rumors that if you made a design that utilized 90-100% of the resources in an FPGA that it would melt itself. Anyone who’s seen how hot FPGAs can get might think that’s feasible at first glance, but its not that simple.

Firstly, if you want to melt an FPGA, you should first understand what makes it heat up. Most of the heat generated by an FPGA is created when flip-flops transition from one-to-zero or zero-to-one. To maximize the heat generated, we need to maximize the number of flip-flops in the design and the frequency at which they transition. This can be done by chaining together a large number of flip-flops one after the other and feeding the chain with a toggling signal. The easy way to code this is with a for loop generate statement. Let me know in the comments if you want this code, and if enough people are interested, I’ll code it and post it.

The bad news is, most FPGAs are made with internal thermal switches that cut the power to the device when the temperature exceeds a certain level (typically 85 degrees). That temperature, if maintained for long periods is enough to cause damage to the device, but not to melt it. Secondly, you probably could come up with a design that uses close to 100% of the FPGA resources without actually melting or damaging it, because the amount of heat generated is not just proportional to the number of resources used, but also the toggle rate of your design. But even if you were to make a design that uses 100% of the resources, it would take hours and hours to build the bitstream, I challenge someone to give it a try.

You might already know I’m interested in the application of FPGAs in the financial markets, a field that has been growing over the last few years. JP Morgan has been working on this over the last 3 years and its paying off.

JP Morgan supercomputer offers risk analysis in near real-time

Prior to the implementation, JP Morgan would take eight hours to do a complete risk run, and an hour to run a present value, on its entire book. If anything went wrong with the analysis, there was no time to re-run it.

It has now reduced that to about 238 seconds, with an FPGA time of 12 seconds.

With the top two FPGA companies taking up 89% of the FPGA market, you can be forgiven for thinking there was no one else out there. Xilinx and Altera have done a good job of defending the duopoly but a few companies are gradually winning market share by targeting specific applications and sub-markets. Here is a list of the top 5 FPGA companies by revenue.

Xilinx

Website: www.xilinx.com

Stock: NASDAQ:XLNX

Market share: 49% ($2,369.45 million) 12 months ending 2011-01-02

The leader in FPGAs for many years, Xilinx has a good range of FPGAs in terms of cost and performance. In recent years, the popular Spartan series has covered the low-to-mid-end market while the Virtex series has covered the high-end. Recently, Xilinx released the “7″ family of FPGAs which are built on 28-nm process and for the first time introduced the Artex-7 and Kintex-7 series which provide better coverage of the lower and mid-end applications previously covered by the Spartan series. The Kintex-7 recently won the “Highly Commended Prize” Semiconductor of the year award for 2011.

Altera

Website: www.altera.com

Stock: NASDAQ:ALTR

Market share: 40% ($1,954.43 million) 12 months ending 2011-01-02

The Altera FPGAs cover the low, mid and upper end markets with the Cyclone, Arria and Stratix series respectively. The most recent offering from Altera is the Cyclone-V, Arria-V and Stratix-V, all build on 28-nm process technology.

Larger than Xilinx in market value, Altera has made great progress in winning market share in recent years. Many people would say that their software tools are much better than those of Xilinx which has likely been an important factor in their success.

Lattice Semiconductor

Website: www.latticesemi.com

Stock: NASDAQ:LSCC

Market share: 6% ($297.77 million) 12 months ending 2011-01-02

Lattice Semiconductor tackles the low-power and low-cost market for FPGAs. They market their products as the “high-value FPGAs” of the industry, providing best performance per cost. With the explosion in portable electronics, this has been a good strategy for Lattice. Lattice claims to have the industry’s lowest power and price SERDES-capable FPGA: LatticeECP3. Obviously they didn’t follow the trend of naming FPGAs after greek mythology or meteorological phenomena (not saying its a bad move!).

Microsemi (was Actel)

Website: www.microsemi.com

Stock: NASDAQ:MSCC

Market share: 4% ($207.49 million) 12 months ending 2011-01-02

Microsemi specializes in low-power and mixed-signal FPGAs.  Here are some of Microsemi’s claims:

• The industry’s lowest power FPGA: the IGLOO.
• The industry’s only FPGA with hard 32-bit ARM Cortex-M3 microcontroller: the SmartFusion.

QuickLogic

Website: www.quicklogic.com

Stock: NASDAQ:QUIK

Market share: 1% ($26.20 million) 12 months ending 2011-01-02

QuickLogic’s focus is on the mobile devices industry meaning ultra-low power, small form factor packaging, and high design security. Rather than selling “FPGA”, they pitch “customizable semiconductors”. You will not find the word “FPGA” on the front page of their website.

“Our patented ViaLink® interconnect technology enables QuickLogic to deliver the lowest power, most routable FPGA in the industry,” Brian Faith, Quicklogic’s Manager of FPGA products.

I’m interested to hear from FPGA developers who have worked on Lattice, Microsemi and QuickLogic FPGAs. Share your experience with us in the comments below. What are their tools like? How do they compare in performance and price to Xilinx and Altera? Can anyone see them breaking the duopoly?

This is the first part of a series of posts I will write on various code structures and examples for HDL designs. Here I want to talk about the generate statement and particularly the for loop.

Most programmers think of a for loop as being a code segment that is repeated during execution of the program. The generate for loop is similar in concept however the difference is that the code segment is repeated on compilation time. For example, I could write the code:

for(i = 0; i < 8; i++)
  printf("hello world");

To achieve the same functional effect, I could have written the printf statement 8 times. Of course you wouldn’t do this because it’s not good coding practice and likewise you would not do this in HDL. But what does the compiler do with the for loop? In reality, the C compiler will not replace your for loop with 8 copies of the printf statement, but in the case of the generate for loop, the synthesis program will do that! That is precisely the point of the generate for loop: to save you writing the same code segment multiple times, preventing you from making errors and making for cleaner code.

The example below shows a generate for loop that generates 8 regional clock buffers (BUFR) using the same chip enable (CE) and clear (CLR) signals but with their own clock input and output signals. The separate clock input and output signals are referenced to different bits of a signal vector using the variable called index.

VHDL generate for loop:

gen_code_label:
  for index in 0 to 7 generate
    begin
      BUFR_inst : BUFR
      generic map (
        BUFR_DIVIDE => "BYPASS")
      port map (
        O => clk_o(index),
        CE => ce,
        CLR => clear,
        I => clk_i(index)
      );
  end generate;

Verilog generate for loop:

genvar index;
generate
for (index=0; index < 8; index=index+1)
  begin: gen_code_label
    BUFR BUFR_inst (
      .O(clk_o(index)), // Clock buffer ouptput
      .CE(ce), // Clock enable input
      .CLR(clear), // Clock buffer reset input
      .I(clk_i(index)) // Clock buffer input
    );
  end
endgenerate

Now you might ask why you would want to write the same code segment multiple times so here are a couple of examples where you would want to use the generate for loop:

• Instantiating multiple RocketIO, HDL modules, buffers, etc. Using the generate for loop makes your code cleaner and is easier to check and debug later on. Going up a notch, when you have to instantiate hundreds of thousands of something, the generate loop becomes absolutely necessary, not just convenient.
• Making a large number of connections between several signals. Writing out the connections for a hundred signal vectors can be made easier by grouping the vectors into an array and writing a generate for loop to make the connections.

So if you have written code that contains lots of repetitive stuff, try using the generate loop to clean it up. If you’ve got questions about the generate for loop, leave them in the comments below.

Recently, what looks to be the first open source FPGA bitcoin miner was released on GitHub. The code is based on the Terasic DE2-115 development board featuring the Altera Cyclone IV, however the author says the design should be applicable to any other FPGA. Maybe we should make it work on a Xilinx FPGA? Here is what they say about its performance:

Project is fully functional and allows mining of Bitcoins both in a Pool and Solo. It also supports Namecoins.

Current Performance: 109 MHash/s On a Terasic DE2-115 Development Board

Note: The included default configuration file, and source files, are built for 50 MHash/s performance (downclocked). This is meant to prevent damage to your valuable chip if you don’t provide an appropriate cooling solution.

For more information about bitcoins: http://bitcoin.org/

I wonder what performance we could get on the ML505/XUPV5? If anyone has done it, let us know. More importantly, I wonder if anyone is making money with this…

Here is a recent presentation I made on outsourcing FPGA design work.

Not long ago I discovered GitHub, the social coding website. Basically its a place where you can share your code and manage open source projects online. I think it’s mainly used by non-HDL programmers but the concept is not language specific so I figured it would be a good place to share FPGA designs. Gradually I will bring all the source code of all our tutorials onto GitHub so that people can more easily share it, modify it and contribute to it.

To start things off, I’ve uploaded the most popular project (at this time): Microblaze 16×2 LCD Driver.

Here’s the GitHub repository: Microblaze 16×2 LCD Driver on GitHub

Here’s how it’s organized:

1. Each project will have its own repository.
2. The first folder within the repository will be the name of the hardware platform (eg. ML505, XUPV5, XUPV2P, etc).
3. The second folder will be the name of the software and the version number (eg. edk10-1, ise10-1, etc).
4. After that, we will use the same folder structure as used by the software used, whether it be EDK, ISE or whatever.

As a new GitHub user, I admit that this might not be the best layout and I’m open to suggestions so by all means let me know in the comments if you see any problems with this.

Here’s what I want you to do:

1. Get on GitHub if you are not already.
2. Share FPGA developer projects with your friends and colleagues.
3. Contribute to FPGA developer projects. What can you contribute?

• If you make a project work on a different hardware platform, add your code to the repository.
• If you make a project work in a different version of EDK/ISE/etc, add your code to the repository.
• If you can improve on a project, fork it and start a new one.

In general, I want you to share, learn and enjoy!

Back in 2009 I did a presentation on why companies needed to be using FPGAs in their high frequency trading:

1. Stop competing in the arms race

Profits for being first to the game are over. Hardware will advance more quickly than you can develop strategies to run on it. Don’t compete in the arms race unless you can buy out Xilinx or Altera.

2. Stop focusing on speed of execution

Trying to get your order out faster than anyone else is a crowded game. Find intelligent strategies rather than fast and stupid strategies. Use FPGAs for what they are good at: fast parallel number crunching. Focus on processing market data to find trade opportunities, not on crunching protocols to save 2 microseconds.

3. Leverage existing hardware

Don’t waste your time developing your own custom hardware. The kind of hardware used in high frequency trading costs too much money to develop and involves too much risk (ironically). But the main problem is the development lead time which means that by the time you can trade on it you can buy something else which is cheaper and faster.

4. Use more data

The next profits will come from FPGA trading platforms that process data streams coming from everywhere and everything. Bring together data from a multitude of sources that are not yet being looked at and find the intercorrelations that can only be exploited by the speed of an FPGA.

For the occasions that you find yourself with a netlist file and you don’t know where it came from or what version it is, etc. this post is about how you can interpret the netlist file (ie. convert it into something readable).

Today I found myself with two netlists and I needed to know if they were the same. Yes of course you can try comparing the two files with a program such as Beyond Compare, but if the netlists were compiled on separate dates, you will have trouble recognizing this from the raw binary data. The best thing to do in this case is to convert the netlists to EDIF files, a readable, text file version of the netlist. Another option is to convert the netlists into VHDL or Verilog code. Here is how you can do this:

To convert a netlist (.ngc) to an EDIF file (.edf)

1. Get a command window open by typing “cmd” in the Start->Run menu option in Windows. If you use Linux, open up a terminal window.
2. Use the “cd” command to move to the folder in which you keep your netlist.
3. Type “ngc2edif infilename.ngc outfilename.edf” where infilename and outfilename correspond to the input and output filenames respectively.
4. Open the .edf file with any text editor to view the netlist.

To reverse engineer a netlist with ISE versions older than 6.1i

1. Convert the netlist to an EDIF file using the above instructions.
2. Type “edif2ngd filename.edf filename.ngd” to convert the EDIF file into an NGD file (Xilinx Native Generic Database file).
3. To convert the netlist into VHDL type “ngd2vhdl filename.ngd filename.vhd“.
4. To convert the netlist into Verilog type “ngd2ver filename.ngd filename.v“.

To reverse engineer a netlist with ISE versions 6.1i and up

1. To convert the netlist into VHDL type “netgen -ofmt vhdl filename.ngc“. Netgen will create a filename.vhd file.
2. To convert the netlist into Verilog type “netgen -ofmt verilog filename.ngc“. Netgen will create a filename.v file.

Now you should have all the tools you need to read an NGC netlist file.

Let’s say we want to be able to switch dynamically between two (or more) clocks. In the Virtex FPGAs we have a primitive which allows us to do just this, it’s called the BUFGCTRL. The BUFGCTRL is a global clock buffer (like BUFG) which has two clock inputs and a series of control inputs that allow you to select between the two clocks. The great thing about the BUFGCTRL is that it allows you to switch between clocks “glitch free”.

If you have two clock inputs and you want to switch between them without glitches at the output, use this code:

  BufGCtrlMux_l : BUFGCTRL
  generic map (
    INIT_OUT     => 0,
    PRESELECT_I0 => FALSE,
    PRESELECT_I1 => FALSE)
  port map (
    O       => ClkOutputMux,
    CE0     => not ClkSel,
    CE1     => ClkSel,
    I0      => ClkInput0,
    I1      => ClkInput1,
    IGNORE0 => '0',
    IGNORE1 => '0',
    S0      => '1', -- Clock select0 input
    S1      => '1' -- Clock select1 input
  );

One problem with using the BUFGCTRL in “glitch free” configuration is that it requires that both clocks be running at all times. If the selected clock suddenly drops out, you will not be able to switch to the other clock. If for example, your clocks come from external sources that come and go, you will not be able to use the BUFGCTRL in “glitch free” configuration and instead you will have to use it in asynchronous mode. In this mode, you can switch between the clocks as you like and it will never get locked into one or the other.

Use this code for the asynchronous clock MUX if you don’t care about glitch free operation:

  BufGCtrlMux_l : BUFGCTRL
  generic map (
    INIT_OUT     => 0,
    PRESELECT_I0 => FALSE,
    PRESELECT_I1 => FALSE)
  port map (
    O       => ClkOutputMux,
    CE0     => '1',
    CE1     => '1',
    I0      => ClkInput0,
    I1      => ClkInput1,
    IGNORE0 => '1',
    IGNORE1 => '1',
    S0      => not ClkSel, -- Clock select0 input
    S1      => ClkSel -- Clock select1 input
  );

What if you have four clocks to choose from? Well you can use 3 BUFGCTRLs to implement a 4-to-1 clock multiplexer. Obviously, your select signal becomes a 2-bit signal. Use this code for a 4-input asynchronous clock MUX:

  BufGCtrlMuxA_l : BUFGCTRL
  generic map (
    INIT_OUT     => 0,
    PRESELECT_I0 => FALSE,
    PRESELECT_I1 => FALSE)
  port map (
    O       => ClkOutputMuxA,
    CE0     => '1',
    CE1     => '1',
    I0      => ClkInput0,
    I1      => ClkInput1,
    IGNORE0 => '1',
    IGNORE1 => '1',
    S0      => not ClkSel(0), -- Clock select0 input
    S1      => ClkSel(0) -- Clock select1 input
  );

  BufGCtrlMuxB_l : BUFGCTRL
  generic map (
    INIT_OUT     => 0,
    PRESELECT_I0 => FALSE,
    PRESELECT_I1 => FALSE)
  port map (
    O       => ClkOutputMuxB,
    CE0     => '1',
    CE1     => '1',
    I0      => ClkInput2,
    I1      => ClkInput3,
    IGNORE0 => '1',
    IGNORE1 => '1',
    S0      => not ClkSel(0), -- Clock select0 input
    S1      => ClkSel(0) -- Clock select1 input
  );

  BufGCtrlMux_l : BUFGCTRL
  generic map (
    INIT_OUT     => 0,
    PRESELECT_I0 => FALSE,
    PRESELECT_I1 => FALSE)
  port map (
    O       => ClkOutputMux,
    CE0     => '1',
    CE1     => '1',
    I0      => ClkOutputMuxA,
    I1      => ClkOutputMuxB,
    IGNORE0 => '1',
    IGNORE1 => '1',
    S0      => not ClkSel(1), -- Clock select0 input
    S1      => ClkSel(1) -- Clock select1 input
  );

 
This example assumes that you have the following signals declared somewhere!
 

signal ClkOutputMuxA : std_logic;
signal ClkOutputMuxB : std_logic;
signal ClkOutputMux  : std_logic;
signal ClkInput0     : std_logic;
signal ClkInput1     : std_logic;
signal ClkInput2     : std_logic;
signal ClkInput3     : std_logic;
signal ClkSel        : std_logic_vector(1 downto 0);

Remember that the BUFGCTRL is a global clock buffer, and you only have a limited number of these in any Virtex device, so be aware of the limitation on your device. For more information on BUFG and BUFGCTRL, read the Clocking Resources User Guide for your specific FPGA device.

I’ve left my full-time job to start a business in electronics consulting! It feels good to finally follow my dream.

I’m asking my readers for help in choosing a company name, please vote!

I’m now fully committed to consulting through my new company: Opsero Electronic Design.

I’m offering FPGA design services including:

• HDL Programming
• IP core design
• EDK/ISE project design
• Design modification
• Simulation
• Hardware verification
• Debugging
• Timing closure

I’m also offering electronic hardware design services including:

I was looking around for FPGA based PCIe boards when I came across something interesting from Nallatech. They’ve created two OpenCL compatible PCIe boards designed especially for the finance market. Named rather creatively “Nallatech 385” and “Nallatech 395“, they’re both based on the Stratix V from Altera which is the best of Altera’s high-end FPGAs. Both boards have a PCIe Gen3 x 8 lane host interface that should allow you to transfer data between the FPGA and the host machine at about 7.88 gigabytes per second (985MB/s per lane x 8). For connection to the market, the boards have SFP+ cages into which you can plug modules for 1Gb Ethernet, 10Gb Ethernet, SONET/SDH & OTN. The main differences between the boards seems to be the amount and speed of the on-board memory and the number of network interfaces.

I think the main selling point for these boards is the OpenCL compatibility. OpenCL is a programming language/framework that allows you to write C code and have the execution distributed across an array of hardware devices such as GPUs and FPGA boards. This is important to firms in the finance industry because they don’t typically employ FPGA programmers, but they’ve been employing C programmers for years. Most of their existing trading algorithms are implemented in C code because that was the most efficient way to implement it, unless you were willing to write assembly code. Today, the most efficient way to do it isn’t in C code and it isn’t even by using a computer. The fastest algorithms today are running on specialized hardware. In my opinion, OpenCL is just an intermediate solution created for a market that is not ready to throw their existing technologies away and start from scratch. But of course I would say that, I’m a hardware guy…

I just received the Zynq-7000 based ZC706 development board from a new client and I’m pretty excited to start working on it. This is the first time that I’ll be working on the Zynq FPGA, part of the latest series 7 devices from Xilinx, so over the next few days, I’ll be writing about my experiences while getting familiar with the board, the FPGA and version 14.5 of the Xilinx development tools. If I get time later, I might dive into the new Vivado Design Suite, promoted by Xilinx to be a “revolutionary IP-centric and system-centric design environment for dramatically faster integration and implementation” – we’ll see about that.

So what’s so great about this board? Apart from the Zynq-7000 with integrated ARM dual-core Cortex™-A9 processor (which I can’t wait to run Linux on), the board has all the high-speed interfaces you could want to get your data in and out. Here are the features according to the Xilinx website:

So over the next few days, I’ll need to get some basic designs working so that I can build upon them. For everything I get done, I’ll write a short tutorial so that others can also benefit from my experiences. Here are a few things I need to get going in the short term:

• Get a stand-alone program running on the ARM processor
• Get some basic communications between my PC and the ARM processor via the UART (UART over USB)
• Implement a VHDL peripheral and control it via the ARM processor – I’ll probably just get it to control the LEDs or something simple like that.

By the way, if you were wondering about the image at the top of the page, I made it using a scanner – it didn’t turn out the way I thought it would, but I like how the fan comes through sharp in front of a blurry background.

I ran into a problem on the JTAG boundary scan and after hours of googling and probing with my oscilloscope, I finally came across a solution.

Firstly I should say that if you are having a JTAG problem with this board, make sure that your DIP switch settings are right. There are two DIP switches (SW11 and SW4) that should be set correctly for your particular JTAG setup. If you are using a USB cable plugged into the slot labelled “JTAG” on the faceplate of the ZC706, you should use the settings 00000 for SW11 and 01 for SW4. If you are using a Platform USB programmer connected to J3, you need to use 00000 for SW11 and 10 for SW4.

So I was going through the getting started guide until it came to downloading and running the BIST, when I get this error:

C:\zc706_bist\ready_for_download>xmd -tcl download_bit.tcl system.bit
Xilinx Microprocessor Debugger (XMD) Engine
Xilinx EDK 14.5 Build EDK_P.58f
Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.
Executing user script : download_bit.tcl
Error:No devices detected while scanning the JTAG chain
Error Executing User Script : download_bit.tcl
Error :: ERROR: Connection to Board Failed

Failed to Scan JTAG Chain
Unknown Error

C:\zc706_bist\ready_for_download>xmd -tcl download_elf.tcl bist_app.elf
Xilinx Microprocessor Debugger (XMD) Engine
Xilinx EDK 14.5 Build EDK_P.58f
Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.
Executing user script : download_elf.tcl
Error:No devices detected while scanning the JTAG chain
Error Executing User Script : download_elf.tcl
Error :: ERROR: Failed to Scan JTAG Chain
Unknown Error

So I try doing a boundary scan from iMPACT and that fails too. I get this error message:

"*********************************************"
"Downloading Bitstream onto the target board"
"*********************************************"
impact -batch etc/download.cmd
Release 14.5 - iMPACT P.58f (nt64)
Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.
Preference Table
Name                 Setting
StartupClock         Auto_Correction
AutoSignature        False
KeepSVF              False
ConcurrentMode       False
UseHighz             False
ConfigOnFailure      Stop
UserLevel            Novice
MessageLevel         Detailed
svfUseTime           false
SpiByteSwap          Auto_Correction
AutoInfer            false
SvfPlayDisplayComments false
INFO:iMPACT - Connecting to TCF agent...
INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.4
INFO:iMPACT - Digilent Plugin: found 1 device(s).
INFO:iMPACT - Digilent Plugin: opening device: "JtagSmt2", SN:210251841232
INFO:iMPACT - Digilent Plugin: User Name: JtagSmt2
INFO:iMPACT - Digilent Plugin: Product Name: Digilent JTAG-SMT2
INFO:iMPACT - Digilent Plugin: Serial Number: 210251841232
INFO:iMPACT - Digilent Plugin: Product ID: 31000154
INFO:iMPACT - Digilent Plugin: Firmware Version: 0105
INFO:iMPACT - Digilent Plugin: JTAG Port Number: 0
INFO:iMPACT - Digilent Plugin: JTAG Clock Frequency: 10000000 Hz
Identifying chain contents...'0': : Manufacturer's ID = Xilinx xc7z045, Version : 2
INFO:iMPACT:1777 -
Reading C:/Xilinx/14.5/ISE_DS/ISE/zynq/data/xc7z045.bsd...
----------------------------------------------------------------------
----------------------------------------------------------------------
'1': : Manufacturer's ID = Unknown
INFO:iMPACT - Using CseAdapterBSDevice
INFO:iMPACT:501 - '1': Added Device xc7z045 successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'2': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'3': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'4': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
.
.
.
.
----------------------------------------------------------------------
----------------------------------------------------------------------
'28': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'29': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
'30': : Manufacturer's ID = Unknown
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
Elapsed time =      4 sec.
Elapsed time =      0 sec.
INFO:iMPACT:501 - '1': Added Device UNKNOWN successfully.
INFO:iMPACT - iMPACT quit the Identify Chain because it detects there are
at least 30 'UNKNOWN' type devices on the chain.
Please check the hardware settings and retry!
ERROR:iMPACT:589 - No devices on chain, can't assign file
make: *** [download] Error 1
Done!

When you google this type of error message, you find a lot of unresolved forum posts, I guess because it must happen for many kinds of reasons like a broken JTAG chain, wrong jumper/DIP switch configurations, bad cables, there was even a guy saying that he traced it down to noise on a power supply. Anyway, so I got out my oscilloscope and traced through the JTAG chain and it seemed completely fine, everything looking like it was supposed to. I checked all my jumpers and DIP switches, everything seemed fine (except jumper J53 which was not in the “default” position, according to the user guide, but in the photo
you find in the getting started guide, it would seem that the user guide is wrong).

Eventually I started trying everything I could, I tried all the SW11 configurations, I tried my Platform USB II programmer, and then I tried using the reset buttons – and that’s when I got it to work! So I had to press the POR (Power on Reset) pushbutton after I powered up the board in order to get the JTAG boundary scan to work. So the problem would seem to be that the Zynq isn’t being reset correctly by the reset circuitry on power-up. Maybe this is a problem with my board, or maybe it’s a problem with all the ZC706 boards. I’ll look into a bit later – for now, I’m just glad that I got the BIST running and all is working fine.

So if you’re having JTAG problems with the ZC706, try pressing the POR pushbutton just after powering up the board. Let me know if you have this problem with your board.

If you’re interested in testing out the Zynq-7000 SoC from Xilinx there are now quite a few options available, so it comes down to a question of features vs price. Below I’ve listed the most important features of the available boards side-by-side to help you make the right decision for yourself or your company. I’ll also go into what I think of each board before we look at the boards in terms of their popularity.

Low-end Zynq boards

The following are what I would consider the low-end boards for those looking at getting their hands on a Zynq with minimal investment. These are perfect for hobbyists, but can also be great for companies interested in integrating the smaller model Zynq into their products.

High-end Zynq boards

These are what I consider to be the high-end Zynq boards for those with extra budget who need the extra features or those who want to test the Zynq at maximum capacity. You’ll notice that I included the ZedBoard in both lists, that’s because I consider it to be versatile enough to compete with the high-end boards, yet low enough in price to compete with the low-end boards.

ZYBO

MicroZed

ZedBoard

ZC702

ZC706

Popularity

Popularity of the board you purchase is important because you will tend to find more support in the online community for boards that more people are using. To compare the popularity of each board, I used Google Trends to compare search patterns for each board. I also used Google Search to find the number of pages on the Xilinx forum and on the web that related to each board.

Number of pages on the Xilinx forum according to Google Search on 2014-03-03:

Number of pages on the web according to Google Search on 2014-03-03:

According to Google Trends, the ZedBoard is 3-4 times as popular as the other boards. Xilinx forum activity would have you think that the ZC702 was more popular but the ZedBoard has its own deticated forum which skews the result here. The general web search showed a result that was more similar to the Google Trends result, showing that the ZedBoard is clearly the more popular board.

One of my most common customer requests is to speed up execution of a software application using FPGA hardware acceleration. If the application runs on a PC or server, you can achieve impressive performance gains by using off-the-shelf FPGA development boards for PCI Express.

Here is a comparison of the available 7 Series FPGA boards for PCI Express applications:

• (*) Note: These HPC FMC connectors are only partially populated which means that they wont be able to support all standard FMCs.
• There are many more FPGA boards for PCIe on the market, but I chose to limit the comparison to those that are more strongly supported by Xilinx.

The reason these types of boards are so useful in the hardware acceleration space is because PCI Express is the highest bandwidth, lowest latency link that you can have between a PC’s CPU and an external FPGA. There’s no use shipping off work to an FPGA if the time it takes the data to get there and back is more than the time saved through improved processing efficiency.

For companies looking at creating their own FPGA based hardware acceleration solution (or any FPGA solution for that matter), my advice is always to first prove that the concept works using off-the-shelf hardware before designing your own custom board. I develop FPGA based hardware acceleration solutions for companies around the world, in applications such as data mining, network security, high frequency trading and more. If you have an application that you would like to speed up using FPGA hardware acceleration, I can help.

Over the last few months I’ve been very busy thanks to the popularity of Xilinx’s Zynq SoC. Here’s the latest project I’ve been working on for Evans Analytical Group, a Zynq based controller for high-power burn-in of ASICs. This custom board uses the Zynq XC7Z020 which contains a Dual Core ARM processor plus FPGA programmable logic. With 1GB DDR3 memory, Gigabit Ethernet and an SD memory card, this board is a powerful System-on-Module that can be connected to a carrier card via 3 wide expansion connectors. The board makes use of the Zynq’s internal XADC and also contains an external ADC and DAC to provide analog I/O through the expansion connectors.

For more information, checkout the project on my portfolio page.

If ever you need to modify the BSP code in your Xilinx SDK project, keep two things in mind:

1. Remember to re-build your application after the BSP has finished re-building. If you don’t re-build the software application, the .elf file will still contain the old BSP code and you wont see any change. Just re-save one of your application source files to get SDK to re-build your application.
2. NEVER do a “clean” on the BSP after having modified it because Xilinx SDK deletes the BSP and re-builds them from the repository sources located in C:\Xilinx\14.7\ISE_DS\EDK\sw. If you need to do a “clean” without losing your code, then you will have to create your own BSP in the repository and work with those files, that way when you “clean”, the sources copied over will be your working files.

A couple of related forum posts:

http://forums.xilinx.com/t5/Embedded-Development-Tools/ReCompile-and-ReBuild-BSP-with-SDK/td-p/193982

http://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/How-do-I-keep-the-BSP-source-files-from-being-erased-when/td-p/299861

Since the release of the Series 7 devices from Xilinx in 2011, one member of the family is clearly dominating the others in terms of popularity: the Zynq-7000 SoC. Did Xilinx put all their marketing efforts into the Zynq or is this proof of a new trend in FPGA technology?

To answer that question let me talk about why I think the Zynq SoC has been so popular.

1. The Zynq bridges a gap in the market for high-performance, calculation-intensive devices. In this market, there are generally three types of implementations: microprocessor based solutions (software solutions), FPGA based solutions (hardware solutions) and a combination of both. Most people accept that (at least in theory) the highest performance and energy efficient implementation of most calculation-intensive algorithms is achieved on FPGA technology. The problem is that FPGA designers are hard to find and creating one internally takes a lot of time. Another problem is that the open-source community for IP cores is not very developed, at least in comparison to open-source software. The Zynq SoC bridges that gap by providing a powerful microprocessor based solution, while offering the possibility to accelerate the implementation through hardware offloading to an on-chip FPGA. With the Zynq, a customer can port their existing application to run on the ARM processor, without the need for an FPGA designer. Once the application has been proven on the Zynq, they can then gradually develop the FPGA part of the chip and explore the possibilities for hardware acceleration.

2. The Zynq supports Linux. A lot of calculation-intensive applications run on Linux and many more will continue to be developed for Linux simply because it allows the developer to leverage a ton of existing drivers and libraries, and it frees the software designer from having to know too much about the underlying hardware. Of course, a pure FPGA can also run Linux, you simply have to implement a soft-microprocessor such as the Microblaze in the FPGA fabric – but the performance isn’t great, the Microblaze is a single core processor that you would typically clock at 100MHz. The Zynq in comparison carries an ARM Dual-core Cortex-A9 processor that clocks at 800MHz. When performance is critical, the processor has to be powerful enough to run the OS fast and transparently, and the Zynq delivers.

3. The Zynq has a large community of users. Many companies and people in the open source community have recognized the potential of the Zynq and chosen it as the base for several open-source hardware projects such as the Red Pitaya, the Parallella and the ZedBoard. The huge success of these projects and visibility on Kickstarter.com has created a large community of Zynq users. There’s also the huge Linux community that Xilinx is winning over by maintaining a Linux distribution for the Zynq on Github as well as thorough documentation on their wiki page. The open-source community is overrepresented by early adopters and people who are willing to jump on new technologies and spread the word – and in my opinion, Xilinx is doing a great job at winning them over. More users means more support which is exactly what customers want to see when they’re considering adopting new technologies.

In general terms, I believe the Zynq has been successful because it provides FPGA solutions and benefits to customers who did not previously have the expertise/resources to use FPGA technology. In my opinion, that’s the edge that the ARM + FPGA combos bring to the market and I think we’ll only see more of these devices in the future. Although I think there will always be a place for pure FPGAs, the Zynq and other chips like it are going to open up the gates to more widespread FPGA adoption.

If you’ve got an opinion on the ARM+FPGA architecture, I’d love to hear about it, just leave a comment below.