Breaking News
Break Points

Design Recipes for FPGAs

NO RATINGS
View Comments: Oldest First | Newest First | Threaded View
llandis
User Rank
Author
Free Introductory Software
llandis   5/4/2016 11:31:28 AM
NO RATINGS
Altera offers a free Quartus Lite Edition that supports the smaller FPGA device families. There are numerous design examples on a range of applications. 

Adam-Taylor
User Rank
Author
A Good Book
Adam-Taylor   5/8/2016 4:16:36 PM
I was one of the reviewers for this edition, I wonder if my suggestions made it into print. I looked a good introduction (in the chapters I saw) but it was definitately written from a academic point of view. 

KarlS01
User Rank
Author
FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
KarlS01   5/9/2016 10:00:01 AM
NO RATINGS
And AGAIN the most important step is left out!  LOGIC DESIGN should be first because an FPGA(or ASIC) is a data flow machine and the logic conditions that accept input and steer the data through the data flow then to the output is the heart of the design.


Testbench is to see if the logic design does the correct function(s).  All of the other etc's in Ganssle's article are part of physical design.  No matter how hard the sell, Verilolg and VHDL are still Hardware Description Langusages as Ganssle did imply.

FPGAs do logic with LUTs and ASICs do logic with gates, and logic design does not care.

FPGAs emulate ASICs so both do the same functions as defined by the logic design, but the physical designs are different.

Also everything does not happen AT ONCE!  That is why there are clocks.  Yes pipeline stages do, but input and, output does not except for cases of multi-chip designs using raw signals from other chips   Multiple interfaces may transfer simultaneously as determined by the logic design and availabity of data.

there are usualy protocols associated with interfaces that require sequencing(hand shaking).


Betajet and Elizabeth want synthesis done as the first step so long paths show up early.  Fine if they want to spend time waiting forsynthesis.  Go ahead.

Meanwhile I will do logic design and simulate with my own model ( I cannot find anything else) until it is time to take a cut at physical design.

elizabethsimon
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
elizabethsimon   5/9/2016 12:08:18 PM
NO RATINGS
@KarlS01  Betajet and Elizabeth want synthesis done as the first step so long paths show up early.  Fine if they want to spend time waiting forsynthesis.  Go ahead.

I think you misunderstood what I said... I was contrasting the usefullness of the tools for finding timing problems in FPGAs as opposed to C code. For the most part, I don't write code for FPGAs or MCUs although I know enough about the languages to do so. My job is to make sure that all the bits outside the chips are properly connected (and the interfaces defined) so the the FPGA guy and the MCU guy can make them do something useful.

You are absolutely right, good logic design comes first and simulation is an excellent way to check the implementation of the design.

 

 

KarlS01
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
KarlS01   5/9/2016 12:53:04 PM
NO RATINGS
@elizabethsimon:  Thanks, there was some misunderstanding.  You just menmtioned another hot button .. interconnection and iknterface definition.  That is a big important thing.  As far as I know, the "tools" ignore the issue. I am writing a program that connects things by name and whether it is binary(Boolean) or arithmetic.


Then it is easy to create a logic "test bench" to exercise the logic.  L:ots of fun.

betajet
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
betajet   5/9/2016 2:03:24 PM
NO RATINGS
KarlS01 wrote: Betajet and Elizabeth want synthesis done as the first step so long paths show up early. Fine if they want to spend time waiting for synthesis. Go ahead.

I like doing synthesis as early as possible, since if there are going to be long path problems I want to find out about them as early as possible so that if I need to add pipeline states I can incorporate them into the logic design early instead of trying to patch them in later. Also, it may be necessary to come up with a major design reörganization to make it work. By finding this out early, I'll have less rework.

In addition, I want to do synthesis early so I can get a quick idea of how many LUTs the design is going to need. A client typically wants to know ASAP how large (and expensive) an FPGA is going to be needed, and whether the design will fit into a "economy" FPGA like a Xilinx Spartan. The logic doesn't have to be 100% correct -- it just needs to be close to the final size.

Synthesis doesn't take that long for a module of reasonable size. When doing this kind of investigation I'm usually synthesizing modules rather than the whole FPGA design.

The other thing is I detest simulation. I find writing test vectors and expected results to be incredibly tedious and since I detest it I won't be able to do a good job. Simulation is great if you like writing test benches, just like unit tests for software are a great idea too. If you have extra engineers around who like to do this sort of thing, wonderful. If you're a one-man FPGA design shop, you have more limited time.

Most of my FPGA designs interface closely with device-level software, and the interactions are resonably complex. Trying to capture those interactions as a test bench is a major PITA. I'd much rather rig up a development board or use a previous generation of a product as a prototype, and run live software.

KarlS01 also wrote (in another comment): Then it is easy to create a logic "test bench" to exercise the logic. Lots of fun.

To borrow from Hitchhiker's, "this is obviously some strange usage of the word "fun" that I hadn't previously been aware of". Or to quote Mr. Knightley in Emma:
Very well. If the Westons think it worth while to be at all this trouble for a few hours of noisy entertainment I have nothing to say against it, but that they shall not choose pleasures for me.

Chacun a son goût.

elizabethsimon
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
elizabethsimon   5/10/2016 12:38:43 PM
NO RATINGS
You are right that the "tools' ignore the issue but it's hard for them to know what's outside the chip. I suppose that it would be nice to have something where you could say  something like "I've connected a Flash chip on a SPI bus on these pins" and have it produce the interface. On the other hand, some of the interfaces that I deal with are custom so I have to specify them.

When writing testbenches, how much thought do you give to simulating error conditions (including glitches) and corner cases? A couple years ago, I was troubleshooting a problem and found that the testbench used to verify the FPGA module had not included much in the way of error conditions.

KarlS01
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
KarlS01   5/10/2016 2:05:21 PM
NO RATINGS
@elizabethsimon: 

Just meeting the schedule for something that works is tough.  Testbenches and simulatioon are tedious.  Synchronous logiic and static timing analysis solve the glitch problem.  EXCEPT when the chip gets connected to other chips.



Today SoC and IP are facing the interface/bus problems.  Meanwhile the simulator draws a wave for a very short time interval.  My conclusion is that a logic model that gets inputs from and generates outputs according to interfface protocol can be a solution(I doubt there will ever be a total solution because of timing variables and schedules).

The Flash connected via SPI  is a memory array read and written by the logic connected to the SPI and the SPI is logically connected to the MCU.

Well, for whatever reasons the SW folks invented OOP, class objects can model the memory, control logic, etc at a higher level than a circuit simulator and therefore model the HW.

There are system classes in C# for memory arrays, Boolean variable types, and user defined classes to use for Boolean expressions.

Just use logical names for the interfaces and the compiler does all the connecting and then you can run or single step the model with the debugger.

You probably could monitor for race conditions and simultaneous state changes that produce glitches( I have not done this yet).

But it is not command line TCL Linux -- sorry.

 

 

elizabethsimon
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
elizabethsimon   5/10/2016 6:42:54 PM
NO RATINGS
@KarlS01 Just meeting the schedule for something that works is tough.  Testbenches and simulatioon are tedious.  Synchronous logiic and static timing analysis solve the glitch problem.  EXCEPT when the chip gets connected to other chips

Meeting the schedule does tend reduce the time available for testing....

I'm not worried too much about glitches internal to the chip for the reasons you mentioned. Its the glitches coming in from outside the chip that are my concern and the ones that should be checked for if possible. The outside world is NOT a friendly place. Especially when we're doing transient testing. :)

 

KarlS01
User Rank
Author
Re: FPGA design has a number of steps – the testbench, compilation, synthesis, routing, etc
KarlS01   5/11/2016 10:38:27 AM
NO RATINGS
@elizabethsimon: "The outside world is NOT a friendly place".  Amen and time is not always your best friend.

Many glitches are due to events that can logically occur at the same time but physically usually do not. 

One approach in logic simulation is to detect when more than one node changes and to make the changes in every possible combination and verify consistent results.  Another is to detect regs that can change at the same time.

It may be analytically possible so a test bench would not be required. 

When I first started, we were taught that switches, relays, if/else, and really anything with binary values could make a Boolean network.  Analytical verification may have some tools that would help.  (Some work required)

Control flow/graph(whatever) can be extracted by a SW compiler. If we realize that logicaly the if/else is defining an and/or network and the ! in relational expressions is an inverter we can use the compiler for a lot of the grunt work.

I too have dealt with glitches and race conditions.  Metastability, too.

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed