Cours Fpga
Cours Fpga
On
Programming FPGA's
Using Handel-C
Submitted By
Introduction 01
SPLD
CPLD
FPGA
Classes of FPGA
Different Technologies Used
Static RAM(SRAM) Technology
Anti-Fuse Technology
EPROM Technology
EEPROM Technology
Handel-C 06
The Language
Similarities with ANSI-C
Design Procedure
Comparison between Handel-C and VHDL
A C-based Language Approach
The Deign Environment
-DK1 Design Suite
Predefined Hardware Libraries
Benefits of using Handel-C
Implementations 13
A Real-World FPGA Design Example
Converting MP3 Software to Hardware
Hardware Implementation of Communications
Protocol in a “Voice Over IP” Phone
Conclusion 22
References 23
Introduction
Programmable logic is loosely defined as a device with configurable logic and
flip-flops linked together with programmable interconnect. Memory cells control and
define the function that the logic performs and how the various logic functions are
interconnected. Though various devices use different architectures, all are based on this
fundamental idea.
There are a few major programmable logic architecture available today. Each architecture
typically has vendor-specific sub-variants within each type. The major types include:
Simple Programmable Logic Devices (SPLDs),
Complex Programmable Logic Devices (CPLDs), and
Field Programmable Gate Arrays (FPGAs)
Field Programmable InterConnect (FPICs)
SPLD - Simple Programmable Logic Device
Also known as:
PAL (Programmable Array Logic, Vantis)
PEEL
The FPGA
The FPGA has three major configurable elements: configurable logic blocks
(CLBs), input/output blocks, and interconnects. The CLBs provide the functional
elements for constructing user's logic. The IOBs provide the interface between the
package pins and internal signal lines. The programmable interconnect resources provide
routing paths to connect the inputs and outputs of the CLBs and IOBs onto the
appropriate networks.
In all of these FPGAs the interconnections and how they are programmed vary.
Currently there are four technologies in use. They are: static RAM cells, anti-fuse,
EPROM transistors, and EEPROM transistors. Depending upon the application, one
FPGA technology may have features desirable for that application.
In the Static RAM FPGA programmable connections are made using pass-
transistors, transmission gates, or multiplexers that are controlled by SRAM cells. This
technology allows allows fast in-circuit reconfiguration. The major disadvantage is the
size of the chip required by the RAM technology and that the chip configuration needs to
be loaded to the chip from some external source (usually external non-volatile memory
chip). The FPGA can either actively read its configuration data out of external serial or
byte-parallel PROM (master mode), or the configuration data can be written into the
FPGA (slave and peripheral mode). The FPGA can be programmed an unlimited number
of times.
Anti-Fuse Technology
EPROM Technology
This method is the same as used in the EPROM memories. The programming is
stored without external storage of configuration. EPROM based programmable chip
cannot be re-programmed in-circuit and need to be cleared with UV erasing.
EEPROM Technology
This method is the same as used in the EEPROM memories. The programming is
stored without external storage of configuration. EEPROM based programmable chips
can be electrically erased but generally cannot be re-programmed in-circuit.
Commerical FPGAs
Company Architecture Logic Block Type Programming Technology
Actel Row-based Multiplexer-Based anti-fuse
Altera Hierarchial-PLD PLD Block EPROM
QuickLogic Symmetrical Array Multiplexer-Based anti-fuse
Xilinx Symmetrical Array Look-up Table Static RAM
Int n x;
This defines a variable x of type int and size of n
bits.
When expressions are evaluated in parallel, communication between the parallel
branches becomes a problem due to synchronization. Handel-C provides a design
construct known as a channel to get around this.
double
float
Chan enum
interface void
const
union
Design Procedure
Handel-C provides a simulator to test the program implementation before
implementing it in Hardware. The simulator can step through each cycle of execution,
and display the values of the variables after each cycle.
Once the designer is satisfied with his/her design, it can be compiled in to
hardware. When compiling in to hardware the designer can target a specific hardware
platform. Handel-C compiler currently produces net lists for Xilinx and Altera devices.
The following design procedure is followed in Handel-
Comparison Between Handel-C And VHDL
Prototyping new concepts or building first generation electronic devices is time
consuming and costly, and in some cases high risk. Most algorithms are prototyped in C
and then translated into VHDL or Verilog—a process that introduces risks and errors.
Handel-C avoids this problem because it is a language based on C and
designed to describe algorithms, which are subsequently compiled down to
hardware. Changes to the Handel-C code produce predictable changes in the
resulting hardware. By targeting FPGAs directly, Handel-C provides a fast route
for hardware prototyping and development of first generation electronic products.
The development process is carried out in a single software environment, with
debug/edit/build loop measured in minutes rather than weeks and months. This
provides the ideal tool for evaluating performance trade-off decisions and validating
the final designs. Handel-C supports a software methodology of design reuse.
Functions can be compiled into libraries and used in other projects, with a simple
declaration providing the interface to other code. Cores written in Handel-C can be
exported as EDIF or VHDL “black boxes” for design reuse.
Features Benefits
High level language solution Allows rapid development of multi-million
gate FPGA designs and system-on-chip
solutions
Based on ISO/ANSI-C Allows application engineers to migrate
concepts directly to hardware, for rapid
prototyping and first generation electronics
products
Well defined timing Fast external I/O
Simplifies pipeline
Explicit parallelism ‘par’ statement
Simultaneous assessment
Supports complex C functionality Shallow learning curve for software
including structures ,pointers and engineers, allows rapid implementations of
functions(shared and inline) very complex, modular systems
Includes extended operators for bit Allows rapid translation of DSP
manipulation, and high level mathematical Algorithms to efficient hardware
macros(including floating point)
No state machines to design, control flow Simplifies design of complex sequential
comes from C statements like if, case and control flows, intuitive to software
while engineers
Simple and consistent syntax extensions for Enables efficient use of available hardware
specific hardware features like without cumbersome syntax
RAMs/ROMs, signals and external pin
connections
Automatically deals with clocks, clock Abstracts away much of the complexity of
enables, and data transfers across clock hardware design
domain boundaries
As systems increase in size and complexity, designers will benefit from a new
breed of tools that complement those they use today. These new tools simplify the
process of describing functionality in hardware through the application of a high level
approach to EDA that is inspired by the software world. Fusing software and hardware
methodologies, these tools introduce three aspects of software development to the
designer: a C-based language for describing functionality; a design system with
symbolic debugging; and libraries of predefined functions including access to
peripherals and processors in hardware via common APIs.
Predefined libraries much like the standard libraries of ANSI-C and other
software environments to hardware design create opportunities for simplifying the
development of new functionality as well as encouraging design reuse. Handle-C has
capabilities for accessing internal and external memory as well as registers. Via libraries
of predefined functions, common APIs shield users from low level interfaces to ease the
integration of FPGAs to physical resources including both peripherals and processors –
the latter enabling hardware/software co design. It is an approach that can mean
significant time savings, giving the designer more time to concentrate on core
functionality.
The Benefits of Using Handel-C
Apart from the obvious benefit of using a high level language based design
method to a low-level language based method. Handel-C provides a very powerful
method of Hardware implementation, which is very useful especially in Custom
Computing applications.
Since Handel-C supports a large set of ANSI C constructs ,easy porting between
the two languages is possible.
The Application
Routers are critical components of Internet Protocol networks. In order to handle
the increasing demands on performance, modern routers are increasingly based on
hardware implementations of the protocol stack. For transfer of real-time information
such as voice over the Internet, the payload-to-packet size ratio is unsatisfactory in terms
of both real-time characteristics and bandwidth utilization. IPv6 has accentuated this
problem further. In order to alleviate this for point-to-point links, schemes to represent
unchanging parts of the headers in a packet stream by an 8 to 16-bit number (CID) have
been devised. The compressed header contains this number and absolute or delta
representations of non-constant data fields of the headers in the stream. The reverse
operation is called decompression and is performed at the receiving end of the link. On
each Internet link, many sessions are transmitted simultaneously. Each session payload-
to-packet ratio.
The idea behind header compression is to enable the transmitting and the
receiving router to agree on a short representation of the headers. The headers are
compressed to the short form when transmitted and decompressed to the original form
when received. This reduces the required bandwidth of the link and improves real-time
characteristics of the data stream. As an example: Compressing IPv6, half-rate voice
packets will lead to a 65% bandwidth saving. Consists of a stream of IP packets with
almost identical headers and often a poor payload-to-packet ratio. The idea behind header
compression is to enable the transmitting and the receiving router to agree on a short
representation of the headers. The headers are compressed to the short form when
transmitted and decompressed to the original form when received. This reduces the
required bandwidth of the link and improves real-time characteristics of the data stream.
As an example: Compressing IPv6, half-rate voice packets will lead to a 65% bandwidth
saving.
The Results
Two designers comprised the team using Handel-C.One had some experience
using an earlier version of Handel-C and some design experience in the application area,
while the other, a college graduate, had no experience with Handel-C or the
application.The table below summarizes the results of the Handel-C implementation
compared to the results in the parallel project.
Overview
MP3 encoding is normally implemented in software, but in the search for higher
performance and lower cost encoders, moving to hardware is increasingly attractive.
Taking advantage of the boost to performance this approach generates, the designer has
greater freedom to reduce the encoding time, improve the final music quality or fix an
optimal trade-off between the two.
In this example, the design team already had available an existing software based
implementation of the MP3 encoding algorithms, comprising over 40,000 lines of C
code. The objective was to convert this software implementation to hardware to yield
significant improvements in performance.
During this process, it was essential to evaluate the effects of the different trade-
offs possible in the encoding process. This would enable both optimisation of the
encoding and also the opportunity to review the feasibility of producing several variants
for different markets.
Taking the conventional route of converting the existing C code to an HDL
environment would have been cumbersome and time-consuming. Instead Handel-C was
used. This took the large body of IP and evaluated multiple variants before producing
netlists for prototype silicon place and route, all within a single environment and without
requiring translation to HDL. A prototype of an MP3 hardware implementation using
Handel-C demonstrates how the integrated software environment speeds development
and provides the efficiency and flexibility to optimise a design.
What Is MP3?
MP3, MPEG Audio Layer 3, is the world-wide standard for audio compression of
complex sources, such as music. It is used for the audio channel in digital television, for
streaming audio across the Internet and for capturing music from CDs and other sources
for use in small, low-cost personal players or on personal computers.
The standard provides compression in excess of 10 to 1 while maintaining CD
sound quality. The approach is deliberately lossy but, by using a psycho-acoustic model,
the result appears transparent and lossless to the listener.
The two richest areas for optimisation are the filtering and the application of the
psycho-acoustic model. In order to improve encoding speed, software implementations
have tended to use a very simplified psycho-acoustic model, which can produce a quality
drop in the final signal.
MP3 Encoding
A simplified MP3 encoding flow is shown in figure below. The sound source is
transformed from the time domain to the frequency domain as 32 frequency bands. These
are filtered using a Modified Discrete Cosine Transform (MDCT). In the software
implementation this is an extremely compute intensive activity. The psycho-acoustic
model is applied to the frequency bands to produce a simplified representation of the
signal, which undergoes a quantization process, before being Huffman coded. Finally, the
Huffman coding is converted to the MP3 bitstream. MP3 decoding is the reverse of
encoding, although without the psycho-acoustic model.
The Result
The project took a two man team less than eight weeks to produce a working silicon
prototype, including implementing a CD-ROM controller to allow management of the
input data stream.
Hardware Implementation of Communications >: Author
Protocol in a “ Voice Over IP” Phone
Overview
Internet Protocol (IP) telephony uses multiple algorithms to convert a voice signal
into the correct form for transmitting across the Internet. The Celoxica™ DK1 design
suite was used to implement these algorithms quickly and flexibly in silicon to make an
IP telephone, without using a hardware description language (HDL). DK1 provides an
ideal environment for enhancing the algorithms and creating new applications for the IP
telephone, such as MP3 music decoders. These new features can be downloaded using
the Internet to increase functionality of the IP phone.
What is IP Telephony?
A normal voice telephone call is purely analogue and requires a dedicated end-to-
end connection between two instruments, which is set up for the conversation and then
torn-down when it is finished. (Although, for parts of its journey, traffic may be digitized
and multiplexed).
IP telephony takes the voice signal, digitizes and packetises it before entering it
into a packet-switched network such as the Internet. The packets share the network with
all the other traffic, of whatever kind, before undergoing a reverse process at the
receiving end.
For customers, IP telephony is seen as effectively free and, as such, users are
prepared to put up with lower sound quality caused by lost packets. Within businesses, it
allows telephony to use the infrastructure of the corporate Intranet, without the need for a
corporate telephone service.
Requirements of IP Telephony
An IP telephone call goes through multiple stages, that involve different protocol
levels.The initial voice is captured and then compressed through a codec. This outputs a
bit stream optimized to run over a conventional telephone network at 48/56/64 kbps. C
implementations of audio codecs are available from a number of sources, including some
public domain software.
The next stage is conversion of the bitstream into RTP packets. This is an industry
standard protocol widely used by many applications, such as Microsoft’s NetMeeting
audio-conferencing software. The RTP packets are then passed up the TCP/IP stack using
UDP (User Datagram Protocol).
Finally, an IP header added before the package goes through an Ethernet or other
technology interface to enter the network. The initial call connection is handled by H323,
which uses TCP. This establishes the two one-way logical channels, one in each
direction, for the UDP that carries the RTP packets. Receiving a call is a straight reversal
of the sending process. Additionally, a telephone unit requires peripherals such as a
keypad or equivalent for setting up the call, a handset with microphone and speaker and
possibly hands-free operation through a speaker and microphone. An advanced IP phone
might also have a screen for information display.
Implementation of the Phone
The IP phone uses a pair of FPGAs with shared RAM and flash memory. Using
two FPGAs allows new versions of the telephony application, or totally new applications,
to be downloaded as TCP/IP traffic under the control of one FPGA and targeted onto the
other, while the phone is in field service. Peripheral circuitry controls the handset and
touch-screen for entering data.
Algorithms for protocols such as RTP, TCP, IP and UDP were derived from a
range of public domain sources available as C source code.
The source code is adapted to exploit the features of Handel-C, such as its ability
to support parallelism. For example, in some telecoms protocols a series of fields in the
packet header are read in succession and actions taken based on the field values. This can
be structured as a pipeline, with each clock tick advancing a packet one stage through the
pipe. Once parallelism is implemented, then the code can be compiled for simulation or
for passing to hardware place and route tools.
The different algorithms were each implemented and tested by simulation and
then in hardware before integration. The overall flow of messages through the different
layers of the protocols determined the structure of the implementation and the output and
input of these layers effectively defined the interfaces between layers. The RAM is
shared between different modules.
Additional Handel-C code was written to take care of the interfacing to the
peripherals and to take care of housekeeping tasks, like generating a ringing tone when an
incoming call arrived. While most of these elements can be handled in software, the
overall computing load can become quite heavy and transferring them to silicon becomes
an attractive way of improving performance.
The Result
An IP telephone prototype was able to take and send voice calls within 3 months.
The development team was then able to begin a process of optimization and tuning,
merely downloading the latest version of the implementation through the Ethernet port
onto one of the FPGAs in the phone. The IP telephone used algorithms that were
available in C with others that were developed specifically for the phone.
These were integrated, simulated and tested within a single Handel-C
environment, without the need to translate into another language. The same environment
is being used to optimize the core application and to develop other applications that can
run on the phone unit.
.
CONCLUSION