stages of programming the fpga for delivering a product.

1. PROGRAMMING FPGAS IN
ELECTRONIC SYSTEMS
MADE BY:
SHARAD PANDEY
MOHD. SHADAB
HUSSAIN

2. PROGRAMMING MICROPROCESSORS AND MICRO
CONTROLLERS
• Using C,C++
• Using IDE like AVR Studio.
• Or directly through assembly language.

3. COMPARISON OF
FIRST
MICROPROCESSORS
TO CURRENT FPGAS

4. Microprocessor FPGA
Architectural design Architectural design
Choice of language
(C, JAVA)
Choice of language (Verilog, VHDL)
Editing programs Editing programs
Compiling programs
(.DLL, .OBJ)
Compiling programs
Synthesizing programs
(.EDIF)
Linking programs
(.EXE)
Placing and routing programs
(.VO, .SDF, .TTF)
Loading programs to ROM Loading programs to FPGA
Debugging programs Debugging FPGA programs
Documenting programs Documenting programs
Delivering programs Delivering programs
STEP-BY-STEP DESIGN PROCESS FOR
MICROPROCESSORS AND FPGAS

5. FPGA PROGRAMING STEP BY STEP:
Simulation Test bench Net list
Synthesi
s
Deliverin
g product

6. SIMULATION:
• Debugging in FPGA design is largely based in simulation because
Emulation, in the context of embedded microprocessor programs,
typically refers to executing programs on special in-circuit emulation
(ICE) hardware designed to
 Run exactly like the target machine and
 Provide visibility, access, and control of the target machine in powerful ways.
• This methodology works because the microprocessor consists of a
fixed array of gates.

7. • The FPGA does not have a "fixed" pattern of gates, in the sense
of the CPU.
• Today the fastest processors cannot be emulated in hardware,
since they already run as fast as possible, and the ICE circuitry
adds additional gate levels, thereby slowing the ICE and
preventing it from keeping up with the processor.

8. Most FPGA systems are
standalone systems
connected to the real
world, and functioning in
interaction with the real
world.
Therefore a large part of
debugging and test is
concerned with
simulating the real world
to which the FPGA will
attach.
In reference to the way
logic circuits were
debugged historically,
this is called the
testbench and is
considered an integral
whole—in other words, it
can be compiled as a
whole.
The simulation process
observes the
transformations and
translations of signals as
they propagate through
the FPGA from the input
pins and provides
responses that eventually
reach an output pin.
TEST BENCH:

9. NET LIST:
• Although it's not really a part of the process, it's is really important to
understand that the output of the FPGA design process is a netlist or
“list of nets” or “wires” that connect gate outputs to other gate
inputs.
• We will assume this netlist as the top level from where every thing
starts, while we are creating a product, many modules are created
until the product is finished. All these modules might be independent
but in the end all are connected to netlist.
• Any module not in the list will have no effect. This is analogous to a
subroutine that is never called. If there is no connection to a module,
the module can't do anything.

10. SYNTHESIS
BIGGEST SURPRISE FOR US----- UNSYNTHESIZABLE CODE!!
What does this mean? It means that you can write "good" functional
programs that are impossible to convert into a netlist that can be
mapped into an FPGA.
Why is this? Primarily because Verilog is a "superset" of synthesizable
syntax.
Historically, Verilog was designed as a simulation language for
simulating logic systems. It was only later that synthesis technology
was able to actually convert the RTL output of the simulation
compiler into netlists based on gate-level structures actually found in
FPGAs. It is therefore understandable that the full simulation
language, designed before synthesis tools, is not fully synthesizable.

11. SHOWING THE DIFFERENCE BETWEEN
SYNTHESIZABLE AND NON-SYNTHESIZABLE
DESIGN:

12. Design
entry
Synthesis
Place and
route
RTL
Simulation
Funtional
Simulation
Gate Level
Simulation
Product

13. IN-SYSTEM PROGRAMMING OF FPGA
SYSTEMS:
• FPGAs are being chosen more and more frequently to comprise
the heart of the modern electronic system.
• There are several possible reasons for this –
1. Low cost
2. Ready availability
3. Increasing sophistication of FPGAs
4. Chief among these must certainly be the ease with which FPGA
hardware can be reconfigured to adapt to potential changes in the
system specification.

14. • The best part of the in system programming is that it can
change the behaviour of the circuit and that too with no extra
cost and within virtually no time.
• The biggest advantage of In-system programming is that it is
sometimes desirable to change the behaviour of the system
when the system has been completely fabricated and then in
that case we use the (ISP) In-System Programming to save time
and cost.
• ISP opens the realm of “fraud” too.
• To avoid it we use “Secure-ISP”

15. REFRENCES:
1. http://en.wikipedia.org/wiki/FPGA
2. http://en.wikipedia.org/wiki/Embedded_System_Design_in_a
n_FPGA
3. http://www.fpga4fun.com/WhatAreFPGAs.html
4. http://en.wikipedia.org/wiki/Reconfigurable_computing
5. http://www.qa-talk.com/news/alt/alt100.html
6. http://en.wikipedia.org/wiki/Vhdl

17. THANK YOU.