Tag Archives: fpga

Arty – Interrupts Part Two – AXI Timer

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

1

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.

2

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – Interrupts Part One

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

1

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.

2

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

3

  • 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.

4

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – SDK Hello World

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

22

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)

23

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

24

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

25

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.

26

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)

27

 

29

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

210

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

211

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

212

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)

213

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.

214

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)

216

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

217

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Arty – Building MicroBlaze in Vivado

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

arty

 

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

1

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

2

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

3

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

Arty_vivado

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

5

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

6

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

7

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

8

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

arty_hello

Below are the MicroBlaze customisations

9

10

11
12

13

Facebooktwittergoogle_plusredditpinterestlinkedinmail

SDSoC Step by Step Example

Facebooktwittergoogle_plusredditpinterestlinkedinmail

sdsoc1

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 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

More things to consider for your prototype

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Hardware Considerations – Power Architectures Part One

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

pwr1

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

pwr2

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.

pwr3

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.

pwr4
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.

pwr5

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Euromicro Conference on Digital System Design (DSD) 2007

Facebooktwittergoogle_plusredditpinterestlinkedinmail

 

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.

dsd

 

A Comparative Survey

Facebooktwittergoogle_plusredditpinterestlinkedinmail

IEEE ISIE 2008

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

isie

Systematic Considerations for the Application of
FPGAs in Industrial Applications

Facebooktwittergoogle_plusredditpinterestlinkedinmail