Tag Archives: fpga

Arty – XADC Hardware Build


Like all Seven series device the Artix on the Arty board contains a 1 MSPS 12 bit XADC which is capable of monitoring not only its internal voltages and die temperature but also up to 16 external inputs. This makes the XADC a very useful device within a embedded system, as it allows you to monitor your system health and perform low speed signal processing without the need for a separate ADC.


To show the ease with which we can implement and use a XADC we will add one in to the MicroBlaze system we have been using previously. This will provide the fastest way to configure and report output of the XADC. In fact as we have been using the Memory Interface Generator we already been using the XADC without knowledge as it is used within the MIG to compensate for temperature effects to ensure the DQS is kept centred.
As such if we were to add in another XADC to our block diagram in Vivado we will fail implementation as there would be two XADC instantiations called up when there is only one within the device.
Therefore before we can place the XADC and use it as we wish within our design to monitor the Arty temperature and voltage supplies we need to adjust the configuration on the MIG to not call up the XADC as shown in the image below.


Instead this will create a new port at the top level of the MIG which is supplied the temperature from the XADC we wish to instantiate.
With this complete we can now open the IP library and place and connect the XADC to the AXI bus, we can make the VP/VN signals connected to the external ports (J5 on the Arty board) by right clicking on the VPVN port on the XADC and selecting make external.
With the XADC connected into the system we need to configure it to provide the temperature output bus needed by the MIG such that it can provide temperature compensation.
To do this we need to tick the Temp Bus option within the basic tab of the XADC wizard, there are a few software switches we need to set when we write the software.


This should result in a block diagram which looks like below when the XADC and the MIG are connected together as required.


We can drive the XADC in either a polled or interrupt fashion depending upon our application needs, to ensure interrupt support we need to make some connections in the Vivado block diagram.
The first thing we need to do is add a third input to the concatenation block which creates the interrupt vector, we need to increase this from two to three inputs. With this completed we can connect the ip2intc_irpt output signal from the XADC to the new input on the concatenation block.
I also decided the block diagram was getting congested and hard to read so I group up a number of blocks and created a hierarchy. This is easy to do select the blocks you wish to group together, right click and select create hierarchy, enter the block name and a new block will be created with that name. other blocks within your design can then be dragged into that hierarchy block if you wish to add them to it or removed by expanding the block (+ sign in top left) and dragged out. This enables us to create very net looking diagrams. Do not forget to click the re draw option once you have implemented your blocks.


Next time we will look at how we can drive the XADC using C in SDK.


Arty – Interrupts Part Two – AXI Timer


In the last blog we had successfully instantiated the interrupt controller and demonstrated it functioning as intended by simulating the timer interrupt.

The next step is to configure the timer and demonstrate that the interrupts can be handled properly from the timer in reality.

What I want to be able to do using the AXI Timer is measure the interrupt latency of the MicroBlaze. Interrupt latency—the time between the interrupt being raised and the interrupt being serviced—plays a large role in performance. A number of issues impact interrupt latency, two of these issues are the presence of an operating system and the complexity of the ISR (Interrupt Service Routine).

However the underlying hardware and processor architecture will also have an impact on the interrupt latency time. We can use the AXI Timer to help us measure this time however, first we need to get the AXI Timer up and running.

The AXI Timer contains two 32 bit timer which can be configured in the following modes

  • Generate – The counter counts up or down as selected from a reset value, once the terminal count is reached the generate output is pulsed and the interrupt if enabled is generated. This mode is used to generate a signal or interrupt at a predefined time interval
  • Capture – The assertion of the external trigger signal stores the value of the counter when the signal is asserted. This can be used to measure the duration of external events.
  • PWM – Uses both timers to create a PWM signal – timer 0 defines the overall period and timer 1 defines the high time of the period.

As you can see the AXI timer is a very useful component to our embedded system, what is important for measuring the interrupt latency is the ability to assert the freeze input which stops the counter.


The timer can be configured to operate as either an up or down counter and in our application is clocked from the UI_CLK output from the MIG. This clock frequency is 83.25MHz or ¼ of the DDR Controller rate.
For this example and the interrupt latency we will use the timer in the generate mode such that it generates at a predefined period, we will be using the counter in its default count up mode.

The periodic time is defined by loading in a predefined value

Period = ( 2^32-1 – Reset Value + 2) * Clk Period

We will use a Reset Value of 0xF0000000 with an 83.25 MHz clock results in a period of 3.22 seconds between interrupts.

The interrupt service routine will be configured to print out that the interrupt has occurred and restart the counter. I have added the code example code to the Github repository when I ran the code on my Arty board I got the result below.


In the next blog we will look at how we can use the timer in more detail to determine the interrupt latency and the potential methods we can use to do this.


Arty – Interrupts Part One


When we built the MicroBlaze system we included the ability to handle interrupts by the inclusion of an AXI Interrupt controller. This is connected to the interrupt input on the MicroBlaze controller each AXI interrupt controller is capable of supporting up to 32 interrupts. However, we can cascade the interrupt controllers to support up to 96 interrupts for each MicroBlaze instantiation.

Within the system we created in our first blog  , we had two interrupts one from the AXI UART lite and a second from the AXI Timer.


The interrupt signal from both the timer and UART are concatenated into a bus using the concatenate block as can be seen above. The intr input on the AXI interrupt shown above as intr[1:0] will scale automatically depending upon the size of the buss connected to it. To use all 32 interrupts use a 32 input bit concatenate block, when you next click on validate you will see the intr input width on the AXI Interrupt block update automatically to the correct width.

The AXI controller is very simple then containing a number of 32 bit registers such as interrupt status, pending, enable and clear registers along with interrupt vector addresses to manage the 32 interrupts.

Within the AXI interrupt block we can customise its behaviour, most importantly we can select if we want the interrupts to be level triggered and active high or low.


Once we have configured the hardware as we desire we can build the hardware and export the hardware to SDK if we have not already done this previously.

Within SDK we can create a simple programme which enable us to configure and initialise the AXI interrupt controller and simulate a timer interrupt occurring. Taking this approach allows us to verify in stages our use of interrupts, this stage allows us to demonstrate that we have correctly configured the interrupt controller. Satisfied that this is working OK we can then configure the timer to function and generate interrupts later on.

The first thing we need to do within our software application is include the correct libraries for this example we will need the following


  • stdio.h – Contains the standard input and output functions
  • platform.h – Defines the initialisation and tidy up routines for the MicroBlaze
  • xparameters.h – Contains the address and configurations of need for the system
  • xstatus.h – Contains the status definitions used
  • xintc.h – Contains the API for using the AI interrupt controller
  • xil_exception.h – Contains the API for MicroBlaze exceptions

With the correct libraries included the next stage is to write three functions

  1. Interrupt Example – This one is called from the main() function and controls the demonstration
  2. Interrupt set up – A standalone function which configures the AXI interrupt controller and the microblaze exceptions
  3. Interrupt Service Routine (ISR) – This is the function called when the interrupt occurs

As this is a simulated interrupt the ISR simply terminates the programme after printing a message out over the UART when I ran this I got the following output on my terminal.


I have added the software application I wrote to my GIT Hub   repository for download if you want it. The next blog on the ARTY will look at the using the AXI timer and the determining the interrupt latency.


Arty – SDK Hello World


When we left the hardware build we had just exported the HDF and bit file to SDK, initially this will have exported the required information to a directory local to the Vivado project.

With the project exported we can close down Vivado and open SDK, if this is the first time you have opened SDK you will be asked for the workspace you wish to use. The workspace is the area where your projects and associated software projects like Board Support Packages (BSP) and copies of the hardware definition will be stored.

Within SDK to get this up and running we need to do the following

  • Create a hardware definition project
  • Create a Board Support Package for the hardware definition
  • Create our application – in this case a simple hello world
  • Build the application – this is the simple part
  • Define the debug environment such that we can run the application on the Arty board over the JTAG link.

The first step is to import the hardware definition we just exported from Vivado to do this select file->new-> other from the SDK menu this will open a dialog box, beneath the Xilinx folder as shown below select new Hardware Platform Specification

21On the next dialog box enter your project name, I always prefer to call it project_HW to be clear what it is and browse to the directory within your Vivado project which contains the HDF file. Note this is within the .sdk folder under your Vivado project.


This will create the hardware specification which, will appear under the project explorer on the left side of SDK, as shown below (this does show all three of the elements we need to create a project)


We are now in a position that we can create a BSP for the hardware platform, this contains the drivers necessary for the hardware. We can create the BSP by selecting file->new->board support package this will open a dialog box like below


Enter a project name, notice how it has picked up the hardware platform we just created, for this example we will use the standalone operating system.

This will a settings pop up for the BSP there are no changes we need to make here but this is where we can add in additional options if needed e.g. light weight IP stack etc


We can also on the standalone page select the stdin and stdout for the compiler make sure this is set to uart lite as below.


With this verified you can close the BSP settings and you will see a progress box appear while the software generates the BSP files for your system.

At this point we can then create our application, for this example I am going to use the simple hello world template. We can create the application project by selecting file->new->application project this will open a dialog box where we can select the BSP we previously created the hardware definition and the processor we are targeting (in this case there is only one)




This will create a simple application which will output hello world over the USB-UART, selecting build all will then enable us to build the BSP and the application project such that we get an ELF file which can be downloaded and run on the hardware.  The project is built using the project->build all settings and you will see the ELF file appear under your application project as below


The next stage is to run it on the Arty board, this requires that we remove the jumper on J1 on the arty board such that we do not load the design example already loaded within the QSPI flash.

To run the example we need to do the following

  • Programme the FPGA
  • Download the ELF

Before we can download the ELF we need to create a debug environment such that when we click on it we can download the elf. To do this right click on your application project and select Debug As -> Debug Configurations as below


This will open a dialog box where we can create a new debug environment, we wish to create a new GBD debug application


One you have selected new you will see the dialog box below, you should only need to change the information on page one (most should be auto populated)


Provide a name and If not selected select the Rest Processor from the drop down menu close to the bottom, we also need to click on the Debugger applications tab and uncheck the option ”stop at main() when debugging” this ensures the application will run automatically on download finally then click on apply not debug and then close.


With this completed it is time to connect the arty board to the USB of your PC, this will auto detect and install any software required when it is completed we can progress and test our application. Note it should only ever need to install once.

The first thing to do is programme the FPGA we do this under the Xilinx Tools -> Programme FPGA which will open the following dialog box (you should not need to change anything)


Click on program and you will see the FPGA is programmed, you can confirm this on your Arty board as the done LED will illuminate green.

We are now ready to download our ELF file, click on the bug icon on the top menu and this will use the debug configuration we just created to download the application


Once downloaded you will notice the software runs and the message “hello world” will appear in your chosen terminal programme.

You can find part one here


Arty – Building MicroBlaze in Vivado


The Arty board is the next generation of the very useful LX9 MicroBoard however, it takes account of advances in devices and interfacing. I ordered mine just before I recently flew to Japan, and it was waiting for me when I returned.



The Arty is marketed as the perfect development platform for MicroBlaze applications as such when I opened my Arty the first thing I wanted to do was a new build from scratch of a MicroBlaze system. This way I could really understand the ease (or not) with which it could be developed, in the end it was very easy to create both the hardware application and create the simple software to say hello world.

To get MicroBlaze up and running on my Arty I did the following

  • Download and install the most update version of Vivado (remember to install the Vivado Design Edition)
  • Redeem the license for the Vivado SW which comes with the Arty
  • Download the Arty board definitions
  • Create the hardware definition within a new Vivado project
  • Build the hardware definition and export it to SDK
  • Create out SW application – This needs Hardware Definition, Board Support Package and Application SW.

While it may seem daunting these stages can be achieved quickly, also I am not going to talk you through how to do the first two points as they are very straight forward.

Which brings us to downloading the board definitions, these are available at the following link https://reference.digilentinc.com/vivado:boardfiles Once you have downloaded the board files you need to extract the Arty board definitions and store it within your Vivado installation <VIVADO DIRECTORY>/data/boards/ on my system the path is C:\Xilinx\Vivado\2015.3\data\boards\board_files

Within the arty directory you will then see the board definition XML and most helpfully a mig.prj this is the settings for the memory interface generator for if we wish to use the DDR on the arty (and we will of course).

This enables us to create a new project and select the Arty board, which is our next step


Once we have the project created the next step is to create the MicroBlaze system, to do this we need to create a block diagram within which we can create our system. You can create a block diagram by selecting Create Block Diagram option under the Flow Navigator on the left of Vivado


Once the block diagram is open we need to add the following things to it

  • MicroBlaze System – See end of blog for customisation
  • Memory Interface Generator – This uses the arty settings so it is just a case of scrolling through and generating the options
  • AXI UART lite – for communication externally – double click on it to set your RS232 options the default is 9600 no parity one stop bit
  • AXI Timer
  • AXI Interrupt Controller – We need a concatenate block to drive the interrupt from the timer and the AXI UART lite
  • AXI BRAM Controller and BRAM for the AXI Data and Instruction Cache
  • Clocking wizard to output a 166.667 MHz Clock and a 200 MHz Clock
  • MicroBlaze Debug Module
  • AXI Peripheral Interconnect to connect to the timer and UART
  • AXI Memory Interconnect to connect to the MIG (DDR) and the AXI BRAM controller
  • Processor Reset System

The clocking of the MicroBlaze and all AXI peripherals should use the output clock from the MIG (ui_clk) while the MCM reset from the MIG block should be fed back to the processor reset system DCM input, the ui_clk_rst goes to the ext_reset_in on the reset block.

The clock wizard outputs connects as below


The rest of the connections are pretty straight forward AXI connections, the only difference is the need to add in a MicroBlaze Local DLMB and ILMB memory we can use the Run Block Automation Option (MicroBlaze) available on top of the block diagram editor.

When it is all complete your diagram will look like the below


The one thing we have not done by this point is to connect up the IO on the design to those on the board. We can do this by selecting on the board tab within the block diagram


We can then right click on a signal we wish to use and select Connect Board Component as below


It is then just a simple case of selecting the existing IP to connect it to


Do this for the following

  • Sys_clk – 100 MHz clock on the Arty
  • DDR3_SDRAM – the DDR on the arty
  • USB_UART – How we will say hello world
  • Reset – Reset input

This saves us from having to write a XDC file with the pin locations needed to ensure we use the correct IO with the board.

With this completed we can validate our design and we should not get any warnings – if you have any address issues see he Address Editor tab mine looked like below when it was validated OK


Once it has validated OK you are in a position that you can build the hardware, and export the hardware definition to SDK.

I will post another blog tomorrow on how to get the SDK side of things up and running but below is the result


Below are the MicroBlaze customisations






SDSoC Step by Step Example



Until the release of the Xilinx® SDSoC™ development environment, the standard SoC design methodology involved a mix of disparate engineering skills. Typically, once the system architect had generated a system architecture and subsystem segmentation from the requirement, the solution would be split between functions implemented in hardware (the logic side) and functions implemented in software (the processor side). FPGA and software engineers would separately develop their respective functions and then combine and test them in accordance with the integration test plan. This approach worked well for years, but the advent of more-capable SoCs, such as the Xilinx Zynq®-7000 All Programmable SoC and the upcoming Xilinx Zynq UltraScale™ MPSoC, mandated a new design methodology.

Link here 


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