Tag Archives: fpga

More things to consider for your prototype


Three things to consider for your prototyping

One of the most exciting stages of an engineering project is when the hardware arrives in the lab for the first time ready for commissioning before integration testing. This typically can mean long hours for all the engineers on the project so how can we try and reduce this time and minimize the issues which may arise.

  1. Think how you will test it from day one – All engineers know the cost of implementing fixes increases as the development progresses. It is more expensive to fix a pin out error once the design has been fixed and manufactured than during an early design review for example. This is the same for testing, thinking of how you will test it from day one and what test equipment you might need.
  2. Think about what to include in the design – During the design of the hardware several design features and functions may need to be included to allow testing of the board with greater ease. The most simple and often implemented test provision is placing test points on all voltage rails Being able to monitor the outputs of clocks and resets is also important, for this reason it is good practice to place test points on the reset line and correctly terminate an unused clock buffer and add test points allowing the clock to be probed with ease. Many modern high performance devices also have on die temperature diodes which can be used during your testing to determine the junction temperature of the die is acceptable, provided you can access these points.
  3. Simple RTL – If you have a complicated design at both the hardware and FPGA level it can be best to develop a more simplified cut down version of the RTL to aid in the testing of the board and the interface between the FPGA and the peripheral. This is especially the case if you are designing high speed interfaces. This cut down RTL could be used in conjunction with chip scope to capture data and block rams which have been pre loaded with data patterns to act as stimulus. This can especially be the case when using ADCs and DACs connected to a FPGA the reprogrammable nature of the FPGA should be utilized to the maximum to develop designs which will allow parametric testing of the ADC and DAC for instance Noise Power Ratio, Spurious Free Dynamic Range and effective number of bit calculations. You should also aim to capitalize on the resources provided by the FPGA  especially system monitor and XADC which can be very useful for monitoring the voltage rails on die and hence helping verify the power integrity analysis

What if it does not go to plan? The first thing to do is not panic, for many issues you will probably not be the first person to face this issue(s) though it may feel like it. Revisit the design schematics, layout and read the data sheets and any errata’s again also have a look on some of the very helpful websites like All Programmable Planet or the Xilinx Forums there are plenty of helpful ones out there.


Hardware Considerations – Power Architectures Part One


One of the more interesting aspects to start looking at is the power architecture of a design, and how we go about powering FPGA’s (and other devices) on the board. Normally the system will have an intermediate voltage which comes from an AC/DC convertor or other DC supply which powers the system. The first stage of the design is to correctly specify this interface in terms of voltage and current required by the design. Determining this intermediate voltage is the easier task of the two, as the current required will have to take into account the downstream convertor efficiencies.

The first stage in defining power architecture is the determination of all the voltage rails and currents drawn by each of these rails. For example when considering a FPGA based imaging system as shown below you may have a number of voltage rails


For this example all of the power supplies have a requirement to be within +/-5%.


As can be seen from the table above the highest voltage required is 3.465V which is the 3.3V at its maximum acceptable tolerance. Knowing this value allows us to determine the voltage supplied by the AC/DC or other DC supply within the system, the sensible thing to do here is to select a convertor which has an output compatible with the 3.3V required and save a conversion stage (increasing the overall efficiency).

The next stage is to determine the power required by each of the rails. The requires that you use power estimation tools such as Xilinx XPE and read the datasheets for other devices to ensure you can determine the power required, I tend to collate all of this in a spread sheet as this comes in useful later on once we are determining the conversion architectures.


As you can see above when I have calculated the power required by the board I have performed two calculations the nominal and the maximum power, this is because at this point in time I have not calculated the maximum rail voltages provided in the worse case by the convertors therefore I have assumed they will be at maximum voltage. This is important as it is needed to determine the power required in the worse case by the AC/DC convertor (You should always design to address worse case requirements) while the difference above 146.5 mW is not large it could be in a larger system.

However having determined the load power we need to determine the overall power required including loses in the power convertors before we can specify the power required from the AC/DC convertor or DC Supply.

Having determined the power required by each device the next step is to determine the power required by each rail, this can then be used to determine the conversion architecture, although of course other requirements also come into play to determine this.

Regarding power architecture there are two main types of convertors

Switching regulators, generate the regulated output voltage by switching storage inductors into and out of the circuit to maintain a regulated output voltage when this switching is controlled via either an analogue or digital control loop. With a switching regulator theoretically 100% efficiency is achievable, however sadly the real world intervenes as components are not ideal however efficiencies greater than 90% can be achieved and GAN FET’s promise even better performance.

Linear Regulators generate the regulated voltage by dissipating the excess power across the pass transistor. This is dissipation is controlled via a control loop to adjust for fluctuations, as there is no switching involved the LR is often used where quieter power supplies are required however that does not mean all ripple on the voltage rail is rejected. As can be seen in the image below as the frequency increases the ripple rejection decreases.



Euromicro Conference on Digital System Design (DSD) 2007



Safety-critical systems nowadays include more and
more embedded computer systems, based on different hardware
platforms. These hardware platforms, reaching from microcontrollers
to programmable logic devices, lead to fundamental
differences in design. Major differences result from different
hardware architectures and their robustness and reliability as
well as from differences in the corresponding software design.
This paper gives an overview on how these hardware platforms
differ with respect to fault handling possibilities as fault avoidance
and fault tolerance and the resulting influence on the safety
of the overall system.



A Comparative Survey




From the functionality point of view, FPGAs became
very interesting for industrial applications. Reasons are the
constantly decreasing costs of microelectronics and improvements
in the corresponding design tools as well as the increasing need
of complex real-time functionalities in these applications. However,
other non-functional requirements have to be considered.
Therefore, the potentials of FPGAs for industrial applications
are considered in this paper on basis of hardware attributes
representing the contribution of these systems to system qualities
as for example performance, reliability and marketability.


Systematic Considerations for the Application of
FPGAs in Industrial Applications


DASIA 2013



This paper describes a proposal for a
space flight demonstration of a low
power, compact Dynamically
Reconfigurable Programmable Board
(DRPB) based upon a minor evolution
of the Astrium Janus payload for
UKube 1.



ZedBoard Part 5 Configuration 2


As I explained in my previous column, the configuration of the Zynq is a little different from that of traditional FPGAs. At the end of the previous column, we were poised to begin using SDK to generate the boot image. So far in this series of blogs, I have created the PS (programmable system) and PL (programmable logic) sides of the device, created a simple C program, and demonstrated everything working using the JTAG interface.

The next step in creating a “boot image” is to create a first-stage boot loader (FSBL). Thankfully, the folks at Xilinx are kind enough to provide us with an FSBL that will load our application and configure our FPGA (you can, of course, customize the code provided to alter the boot sequence). Within the current SDK workspace (the one containing your C project), use “New > Application Project” to create a new project as illustrated below



Select whether you want to use C or C++, the board support package defined for your system, and the name of the project, which is “zynq_fsbl_0” in this case. On the next tab select the “Zynq FSBL” option, as illustrated below and your FSBL project will be created, at which point we are nearly ready to create the boot image



f you have “Compile Automatically” selected then the FSBL will be compiled; if not, it will be compiled on-demand later on.

However, we actually need to make a small change to the linker script provided with the FSBL, as it has no idea where the DDR memory is located in the processor address space. Therefore, we need to open the “lscrip.ld” file and add the DRR memory location into this file. This can be found in the linker script we created for the C application in Part 3 of this mini-series (it can also be found in the “system.xml” file under the hardware platform definition).

The following screenshot shows the FSBL “lscript.ld” file with the DDR address for the system added in. If you forget to do this, you will find that the boot loader will run and the FPGA will, but the application will not run because in Part 3 we configured the application to run from the DDR



Looking under the “Project Explorer,” you should hopefully now have the following modules (each should have a slightly different symbol identifying the type of module):

  1. proc_subsystem_hw_platform — named after the processing subsystem you created in PlanAhead, this is the hardware definition of your file
  2. zed_blog_0 — This is the board support package created in Part 3 of this mini-series
  3. zed_blog_C — The C application created earlier in Part 3 (a simple “Hello World” and LED flashing application)
  4. zynq_fsbl_0 — The first stage boot loader we have just created and modified

As we are creating a “bare metal” application (i.e., no operating system), we need the following files — in this specific order — to create a boot image:

  1. First-stage boot loader (as created in this column)
  2. FPGA programming bit file (created in Part 2)
  3. C application (created in Part 3)

We are now ready to generate the boot image, which can be created using the “Create Zynq Boot Image” option under the “Xilinx Tools” menu as illustrated below



This is where we need to select the ELF files (resulting from the compilation of the software projects) and the bit file for the FPGA as illustrated below



It is important to stress that the FPGA bit file must always follow the FSBL. Clicking on “Create Image” will create *.bin and *.mcs files, which can be programmed into the target device.

On the ZedBoard we have the option of booting from the QSPI (Queued Serial Peripheral Interface) or the SD (Secure Digital) card. I think QPSI is more likely to be used for robust applications than an SD card, so we will store our application there.

The QSPI interface was defined all the way back in Part 2 of this mini-series in the “System Assembly” view of Xilinx Platform Studio as illustrated below (click here to see a larger version of this image); hence, the hardware definition will contain the QSPI IP core and the location in the processor address map at which the QSPI resides.atzb-0016-06-lg


Connect the ZedBoard to the PC via the JTAG interface and ensure the mode pins on jumpers 7 to 11 are set correctly. Select the “Program Flash” option from the Xilinx tools menu as illustrated below



Navigate and select the MCS file you generated and enter an offset of 0x0 in the dialog box that appears in the middle of the screen as illustrated below


It may take a few minutes for the device to be programmed (and verified if you ticked the “Verify” option). Once the programming is completed, power-down the ZedBoard and disconnect the JTAG cable such that the only connection the board has is the RS232 connection and the power cable. Set Jumpers 7 to 11 to configure from QSPI and power the board back on again. Congratulations! You have now created your very first, standalone, bare metal Zynq application.



ZedBoard Part 4 Configuration


If you read this mini-series, you know that I have reached the stage where I have a simple Hello World program running on my Zynq when it is connected to the software development kit. In reality, however, this is not much good. For a real-world use model, we will want to store our software program and configuration bitstream in nonvolatile memory and configure the device following power-on.

But how do we do this? For those used to a traditional FPGA development and configuration flow, this is a little different from what one might initially imagine. In fact, it will take me a couple of blogs to explain it all, but I promise this will be worthwhile, so please bear with me.

Before I jump into the tools and processes you need to follow to create the boot file, I had better explain the basics of the Zynq configuration. In a Zynq system, the processing system is the master and always configures the programmable logic side of things, unless the JTAG interface is used. This means that the processing system can be powered and operating while the programmable logic remains unpowered (unless secure configuration is used).

The processing system therefore follows a typical processor boot sequence, initially running from an internal nonmodifiable boot PROM. This boot PROM contains drivers for the supported nonvolatile memories, along with drivers for the programmable logic configuration. The boot PROM also loads in the next stage of the boot loader, the first stage boot loader (FSBL), which is user-provided. The FSBL can then configure the DDR memory and other peripherals on the processor before loading the software application and configuring the programmable logic (if desired) using the processor configuration access port. The PCAP allows both partial and full configuration of the programmable logic.  This means the programmable logic can be programed at any time once the processing system is up and running. Also, the configuration can be read back and checked for errors.

The Zynq supports both secure and nonsecure methods of configuration. In the case of secure configuration, the programmable logic section of the device must be powered up as the hard macro. The advanced encryption standard and secure hash algorithm needed for decryption are located within the programmable logic side of the device.

The Zynq processing system can be configured via a number of different nonvolatile memories (Quad SPI Flash, NAND Flash, NOR Flash, or SD). The system can also be configured via JTAG, just like any other device. Like all other FPGAs from Xilinx (this site’s sponsor), the Zynq uses a number of mode pins to determine crucial system settings like the type of memory where the program is stored. These mode pins share the multiuse input/output pins on the processor system side of the device. In all, there are seven mode pins mapped to MIO[8:2]. The first four define the boot mode. The fifth defines whether the PLL is used, and the other two define the voltages on MIO bank 0 and bank 1 during power-up.

The FSBL can change the voltage standard defined on MIO bank 0 and 1 to the correct standard. However, if you are designing a system from scratch, you must ensure that the voltage used during power-up cannot damage the device connected to these pins.

On the ZedBoards, these mode pins can be changed via jumpers to facilitate configuration from the SD, JTAG, or Quad SPI memories that are available.

In my next blog, I will explain how we use the tools to generate the first stage boot loader and then tie everything together to generate the file required to program the Zynq.


ZedBoard Part 3 SDK


For the majority of this blog, we will be using the Xilinx Software Development Kit (SDK). However, there is one last thing we need to do within PlanAhead first, and that is to export the hardware to the SDK. (Note that we will need to do this each time we make a change to the hardware.)

Actually, it might be worth taking a moment to explain this in a little more detail, because this is the sort of thing that can sneak up and bite you on the bottom later if you don’t fully understand what’s going on, so let’s take a small step back…

As we know, the Zynq-7000 All Programmable SoC powering the ZedBoard is composed of two distinct sections: the programmable logic (PL) section and the processing system (PS) section. What we’ve done in my previous blogs is to define the hardware portion of the system — specifically, we’ve established some simple functionality in the programmable logic that will drive some LEDs in the outside world; we’ve specified what we want to use in the processor subsystem (the ARM Cortex-A9, the DDR RAM, the SPI, etc.); and we’ve set up an AXI bus linking the PS and PL sections. Finally, we’ve generated the configuration bit-file that will be used to set up the hardware portion of the system.

When I say that we need to use PlanAhead to “export the hardware to the SDK,” I’m talking about informing the SDK as to the nitty-gritty details of our hardware configuration, including such things as the address ranges of any external memories and the register maps associated with any peripheral functions and hardware accelerators implemented in the programmable fabric (we don’t have any hardware accelerators at this time, but we may add some later).

OK, so we select the “Export Hardware to SDK…” menu item, as illustrated in the screenshot below.

at-0014-01-lg This should result in SDK being opened and the hardware specification being imported, as illustrated in the screenshot below

at-0014-02-lg Once the hardware has been imported, we will need to create a board support package (BSP), as illustrated in the screenshot below


This BSP will be specific to our hardware implementation. In addition to containing drivers for any of the peripherals we are using, it will also include a number of hardware-specific C header files, such as “xparameters.h,” which defines the memory map of the system along with other system configuration parameters. In the case of our example, when creating this BSP, we must make sure to select the target processing system and CPU0.

Now we are at the stage when we can finally start to create our software project, which will use the imported hardware and BSP, as illustrated in the screenshot below.



For the purposes of my first test case, I decided to create a very simple C application to send a message over the UART to the console and flash a pattern on the LEDs connected to the AXI port in the programmable logic side of the device. In order to do this, I selected the “Xilinx C Project” option, as illustrated in the screenshot below



The next step allows you to name the project and select if you want a basic template for a project. Since none of the provided templates offered what I was intending to implement, I opted to go with a blank template, as illustrated below


My goals for this first project were very simple. As I mentioned earlier, all I want to do is to send a message up to the console and flash a pattern on the LEDs, thereby proving to myself that I know how to get PS portion of the Zynq to communicate with its PL counterpart.

If you are unsure of the peripheral drivers within the system — or if you are not sure how to drive them — take a look at the “system.mss” file under your BSP within the project explorer. This also provides a list of helpful links to documentation and examples.

Next, we need to include a number of C header files that contain parameters and functions that can be used by the software developer. The header files I included in my project were as follows:

  • Stdio.h — Defines the standard Input and Output (this should be familiar to anyone who has worked with C).
  • Platform.h — Defines basic functions for the implementation and platform initialization and clean-up.
    Xil_types.h — Defines a number of types needed for Xilinx IP cores.
  • Xgpio.h — Defines the drivers for the AXI bus driving the general purpose input/output (GPIO) module we have connected to the LEDs in the outside world.
  • Xparameters.h — Defines the hardware architecture and configuration for this implementation.

With these files included, I next wrote a small bit of C code to achieve my aims (click here to download a compressed ZIP file containing this C source code). Having written our code and having successfully compiled it, we next wish to download the application into our ZedBoard. In order to do this, we first need to create a linker file script that will specify where the executable is placed in the system memory. My program was tiny and would easily fit in the on-chip memory; however, I decided to place my executable in the external DDR memory so as to demonstrate that this interface was also configured correctly. We can create our linker script by right-clicking on our project and selecting the “Generate Linker Script” option, as illustrated in the screenshot below


We’re almost there. The next task we have to perform is to set up the run configurations using “Project Explorer -> Project -> Run -> Run” in the right-click menu. This is where we can define our STDIO connection to the serial port we are using for the STDIO. Once we are happy, we can apply the configuration and then close the dialog. (Do not click “Run” as we are not quite ready for that.) The final stage is to connect the ZedBoard board to our PC using both the UART USB cable and the programming USB cable. We should now be able to program the ZedBoard via the SDK, as illustrated in the screenshot below


Always make one last check that you are using the correct configuration bit-file (which tells you that I’ve slipped up myself on at least one occasion) and then program the device, as illustrated in the screenshot below


Once the configuration has completed successfully, you will see the “Done LED” illuminate on the ZedBoard. Having completed the configuration, you can now download the ELF file and try out your program. Doing this is as simple as selecting your project within the project explorer, right-clicking “Run As,” and then selecting the “Launch on Hardware” option, as illustrated in the screenshot below.