Tag Archives: vhdl

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

ZedBoard Part 4 Configuration

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

FPGA Forum 2015 Key Note

Facebooktwittergoogle_plusredditpinterestlinkedinmail

ff

The last 20 years have seen the explosion of FPGA technology used in many different end applications, including those within harsh environments. It therefore follows that system developers wish these devices to operate correctly and safely regardless of environment. When engineers design for a space flight mission, there are a number of environmental factors that may impact mission performance: radiation; temperature; and the dynamic environment. How much weighting each of these environmental factors has depends upon the end space application which are typically grouped into one of three categories Launcher, Science / Exploration or Telecommunication.  Regardless of the end application the engineer must consider FPGA technology, Mitigation strategies at both the FPGA and System level along with lessons learned from previous missions. However, these techniques and mitigation strategies are not just limited to space applications but can also be applied to terrestrial applications

Slides 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Calculating Mathematically Complex Functions Issue 87

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinx87_2

Thanks to their flexibility and performance,
FPGAs have found
their way into a number of industrial,
science, military and other
applications that require the calculation
of complex mathematical problems
or transfer functions. It is not uncommon to
see tight accuracy and calculation latency
times in the more critical applications.
When using an FPGA to implement mathematical
functions, engineers normally
choose fixed-point mathematics (see Xcell
Journal issue 80, “The Basics of FPGA
Mathematics,” http://issuu.com/xcelljournal/
docs/xcell80/44?e=2232228/2002872).
Also, there are many algorithms, such as
CORDIC, that you can use to calculate transcendental
functions (see Xcell Journal issue
79, “How to Use the CORDIC Algorithm
in Your FPGA,” http://www.xilinx.com/
publications/archives/xcel l/Xcell79.pdf).
However, when confronting functions that
are very mathematically complex, there are
more efficient ways of dealing with them than
by implementing the exact demanding function
within the FPGA. To understand these
alternative approaches—especially one of
them, polynomial approximation—let us first
define the problem.

Link here

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to use Interrupts on the Zynq SoC Issue 87

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinx87

In embedded processing, an interrupt is
a signal that temporarily halts the processor’s
current activities. The processor
saves its current state and executes
an interrupt service routine to address
the reason for the interrupt. An interrupt can
come from one of the three following places:
• Hardware – An electronic signal connected
directly to the processor
• Software – A software instruction loaded by
the processor
• Exception – An exception generated by the
processor when an error or exceptional
event occurs
Regardless of the source, interrupts can also
be classified as either maskable or non-maskable.
You can safely ignore a maskable interrupt
by setting the appropriate bit in an interrupt
mask register. But you cannot ignore a
non-maskable interrupt, because these are the
types typically used for timers and watchdogs.
Interrupts can be either edge triggered or
level triggered. The Xilinx® Zynq®-7000 All Programmable
SoC supports configuration of the
interrupt either way, as we will see later.

Link here

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Ins and Outs of Creating the Optimal Testbench Issue 86

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinxx86

Verification of an FPGA or RTL module can be a time-consuming process as the engineer strives to ensure the design will function correctly against its requirement specification and against corner cases that could make the module go awry. Engineers traditionally achieve this verification using a testbench, a file that you will devise to test your design. However, testbenches can be simple or complicated affairs. Let us have a look at how we can get the most from our testbench without overcomplicating it.

Link here

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to Boost Zynq Performance by Creating Your Own Peripheral issue 84

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinx84

 

One of the real advantages of the Xilinx® Zynq™-
7000 All Programmable SoC is the ability to
increase the performance of the processing system
(PS) side of the device by creating a peripheral within
the programmable logic (PL) side. At first you might
think this would be a complicated job. However, it is surprisingly
simple to create your own peripheral.
Adding a peripheral within the PL can be of great
help when you’re trying to speed up the performance
of your processing system or when you’re using the
PS to control the behavior of the design within the
programmable logic side. For example, the PS might
use a number of memory-mapped registers to control
operations or options for the design within the programmable
logic.

Link here

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to Configure Your Zynq SoC Bare-Metal Solution Issue 83

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinx83_2

 

Because of its unique mix of ARM processing
clout and FPGA logic in a single device, the
Zynq™-7000 All Programmable SoC requires a
twofold configuration process, one that takes into
account both the processor system and the programmable
logic. Engineers will find that the configuration
sequence differs slightly from that of traditional
Xilinx® FPGAs. Nevertheless, the methodology is
familiar and it’s not at all difficult to generate a boot
image and program the configuration memory.
Where standard FPGA configuration practices normally
require only the FPGA bit file, you will need to
add a second type of configuration file to get the maximum
benefit from your Zynq SoC: the SW Executable
and Linakble Format (ELF) file. The FPGA bit file
defines the behavior of the programmable logic section
of your design, while ELF file is the software program
that the processing system will execute.
So let’s have a look at how to implement a baremetal
(no operating system) software application on
your Zynq SoC.

Link here 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to Implement State Machines in Your FPGA Issue 81

Facebooktwittergoogle_plusredditpinterestlinkedinmail

xilinx81

FPGAs are often called upon to perform
sequence- and control-based actions such as
implementing a simple communication protocol.
For a designer, the best way to address
these actions and sequences is by using a state
machine. State machines are logical constructs that transition
among a finite number of states. A state machine will be in
only one state at a particular point in time. It will, however,
move between states depending upon a number of triggers.

Link here

Facebooktwittergoogle_plusredditpinterestlinkedinmail