UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
14,090 Views
Registered: ‎01-06-2009

Advance FPGA Design by Steve Kilts

Buy this book.  Read it.  You can absorb the important parts in less than three hours.

 

I am very new to HDL, but I understood everything the author discusses.  Now I know why my design is so bad!

 

1) gated clocks

2) async signals

3) unnecessary resets

 

He even gives a quickie guide to decoupling caps!

 

Now I need a book which clearly explains the application of timing constraints in the Xilinx wonderland.

 

On a humorous note, I noticed that after one of my rants (no cussing or flaming!) my "new message editor" on this forum began to display a message warning me about my language.  I guess I've been a good boy for a while now so it has disappeared.  I feel...so...childish.

 

By the way, when Xilinx holds a training class do they use ISE?  How do they explain the crashes?  Using only known projects?  Lots of RAM? Linux? Chicken bones in a bag around the teacher's neck?

 

0 Kudos
20 Replies
14,057 Views
Registered: ‎07-15-2008

Re: Advance FPGA Design by Steve Kilts

Hi Mike,

 

To be honest I thought that book was terrible, but the though of the chicken bones made me laugh.

 

 

Bobster

0 Kudos
14,044 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts

I liked the book because I needed structural ideas rather than the basics (even though I could use those as well).

 

It reads much like a book I want to write for industrial electronics that reads, "use opto isolation to avoid ground loops and here's how" rather than, "use a transimpedance flooberwuster with a transfer coefficient of .2 us downgraded by the inverse square of the expected distance between electrons in your flutter loop".

 

0 Kudos
Highlighted
11,360 Views
Registered: ‎10-30-2012

Re: Advance FPGA Design by Steve Kilts

In fact I am confused by some questions in that book. But the E-mail he left is not available,i can not even write a email to him.

Do you know some good book about FPGA design ?Could you recommend them to me?Thanks a lot.

Tags (1)
0 Kudos
11,346 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts

 

Nope -- don't have any good books on the fpga design.

 

My buddy does recommend "VHDL for Programmable Logic" by Kevin Skahill as a good book for the VHDL end of it -- and it is important to have a good grasp of VHDL.

 

You would not believe the horror I went through trying to implement a large, complex project as a Xilinx newbie. In the end, I only had four real problems:

 

1) Xilinx software generates a million warning messages -- which ones are important? Not even Xilinx knows. When compiling software, I enforce a "0 Warning" policy because warnings usually mean a problem. I've had to learn to ignore a lot of warning chaff from Xilinx.

 

2) If you have ANY external signals that are not locked to your FPGA clocking, you MUST use double flip flop synchronizers.

 

3) Half the people tell you that you must do post layout timing analysis, half tell you that you do not. It's a LOT of work to set up the analysis and it must be redone for any changes. So far, the most sensible answer has been to test timing by running the hardware under temperature extremes. If you can't find the errors that way, then do the analysis.

 

4) Xilinx recommends letting the software determine where to place the I/O pads to make sure it can meet timing. Ha ha. Ha. Ha. Good luck with that. It will scatter your 32 bit address bus all over the chip. Good luck routing it. I picked sensible pad layout and everything worked out. My more experienced friends agree with this one.

 

0 Kudos
11,343 Views
Registered: ‎10-30-2012

Re: Advance FPGA Design by Steve Kilts

In the book double flip flops synchronizers are only recommended in single signal situation.Does the Xilinx force to use double flip flops all over the external signals?Is it necessary or is it right?

 

 

Since you mentioned that "double flip flop synchronizers"problem.

My questions in that book also relate to that.

Could you take a look?

 

//================================================

"In theory,an output could remain metastable indefinitely,but in reality it will settle due to higher order effects of a real system." on page 90 in <Advance FPGA Design>.
1. Does the words mean: the metastable of the Dsync signal in the picture above on the page is either 0 or 1 in reality?
2. If the answer of the 1th question is true.Do we really need the second flip-flop as the delay synchronizer??Either 0 or 1 do effect the other process?
0 Kudos
11,341 Views
Registered: ‎10-30-2012

Re: Advance FPGA Design by Steve Kilts

That's it90.png

0 Kudos
Teacher rcingham
Teacher
11,333 Views
Registered: ‎09-09-2010

Re: Advance FPGA Design by Steve Kilts

Take a look at:
http://www.edn.com/file/17561-310388.pdf
and
http://www.eetimes.com/General/PrintView/4015243

If you are taking a bus between clock domains, use a 2-clock (sometimes called 'asynchronous') FIFO.

There are (many) other threads on this topic...

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Advisor eilert
Advisor
11,338 Views
Registered: ‎08-14-2007

Re: Advance FPGA Design by Steve Kilts

Hi,

there are many threads explaining the 2-FF thing.

 

In short: Its all about probability.

If a FF goes metastable there is a (small) chance that this hits the next FF to go metastable too (and so on...)

Now, if the next FF is not a single one but a number of system relevant function FFs the probability for that event is increased.

 

Calculations and practical research show that the probability for the third FF to become metastable too is close to nothing while for the second FF it can not be neglected..

(You can find the detailed calculations and actual numbers in some Xilinx white paper or application note).

 

Have a nice synthesis

   Eilert

 

 

0 Kudos
11,325 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts / Using double flip-flop synchronizers for asynchronous signals

1. Does the words mean: the metastable of the Dsync signal in the picture above on the page is either 0 or 1 in reality?
 
I read a lot of pages on the web to understand this one. My design kept locking up until I applied the double flip-flop syncing technique. Below is the synopsis:
 
You are on the right track! As any signal goes from 0 to 1, it must pass through a "dead" zone where it is neither zero nor one.
 
In most systems this is usually only a problem where we are latching that data (trying to capture its state in a flip-flop). If you try to latch it when it is in the "dead" zone, the latch can get stuck half way between 0 and 1 for a little while before it falls either to 0 or 1. Unfortunately, the latch can be stuck like that for an indeterminate amount of time. Even a fraction of a second can be deadly.
 
Why? Because each part of the circuit which uses the latched signal may have a slightly different threshold for what is a 0 and what is a 1. So one part of your circuit sees the latched signal as a 0 and another part sees it as a 1 (because it's hovering somewhere near the middle). This can be disastrous because they both may try to activate logic which should normally not be active at the same time.
 
Normally, in a truly synchronous system, everything is designed such that any latched signal makes its transitions well before the clock signal which is intended to latch that signal. That way, the latch doesn't occur during the "dead" zone. In fact, if you do the post route simulation timing analysis, one of the major things you are looking for is whether or not all signals have time to make their transitions and travel to the next flip-flop well before the next clock transition for that flip-flop arrives. By the way, as the temperature of the chip changes, the timing changes. If performing simulation timing analysis, you can specify the temperatures. If running on actual hardware, test it when cold and then cover it up and let it get hot and test it some more to find out your safe range.
 
So, in a truly synchronous design, all signal transitions are tied to the same clock which is used to clock the flip-flop which will be latching those signals. The signal transitions might occur on the up-down clock while the flip-flop is triggered by the down-up clock. So the signals have half a clock to make the complete transition, settle down, and travel down the connection to the next flip-flop where they are expected to be stable before being latched. If your design does not allow for all signals to be settled in time, you must either slow down the clocking altogether or just for problem latches, redesign to allow shorter paths, add intermediate flip-flop stages, specify timing restrictions on certain paths, etc. This is the whole crux of FPGA design -- the logic is the easy part.
 
The reason you have to address the issue in your FPGA design is because it is probably not truly synchronous. Every thing inside the chip might be, but usually you will have to interface to the outside world and those inputs can come at any time and might be in transition when the signal is latched -- such as a write strobe from a computer trying to write a byte into one of your design's registers. Even pulses from a sensor have to be synced.
 
So, feeding asynchronous signals through dual flip-flops virtually removes the problem -- or reduces it so much that it is very, very unlikely to occur. It has been proven mathematically that it is IMPOSSIBLE to solve the problem 100%, but this method has proven to work well enough. After all, it is theoretically possible for the first flip-flop stage output to get stuck in the "dead" zone forever! It has been shown empirically that adding a third flip-flop stage does not add any significant benefit.
 
The reason it works for the most part is because the first flip-flop might latch the signal in the "dead" zone, but it doesn't go into your design where decisions are made -- it stops at the second flip-flop until that flip-flop is clocked again. During the time between the two latchings, the signal has time to slide either down or up to a solid 0 or 1. When the second flip-flop gets clocked again, it passes on the now solid signal to the rest of your logic as a stable 0 or 1.
 
So, if you have an external device trying to write a byte into one of your FPGA design's registers do you have to sync every signal? Nope. If the external write sequence is slow enough (say 1/4th of your FPGA clock speed), you only have to sync the write strobe. The sequence works like this:
 
data byte applied by external device (signals are in transition)
data byte transitions are seen by the register latch inputs, but do not go further into the design
data byte transitions settle down
external device applies write strobe
write strobe is double flip-flop into the FPGA (takes two FPGA clocks before it is used)
clean, synced, write strobe is applied to the register latches
the data byte has already settled down so it is cleanly latched
the register latching is synced with the rest of the FPGA clocking due to the double flip-flop of the write strobe
 
Note that in this scenario, the write timing must be longer than the FPGA clocking so that everything has time to settle and, in the case of the write strobe, be synced through the double flip-flops. The external device itself can be running very fast -- it must only slow down the FPGA write process.
 
I made the mistake of including my double flip-flop code inside my main modules. Kilts points out that it is better to put synchronizers in their own little modules so that it is easily seen which signals are synchronized. I agree.
 
There are some example synchronizer modules in the Xilinx library. Some of the options they use cause warnings in a typical design. I tweaked their module, added some comments, and will post it in my next comment.
 
Enjoy!
 
2. If the answer of the 11th question is true.Do we really need the second flip-flop as the delay synchronizer??Either 0 or 1 do effect the other process?
 

Yep, I had this same question, "Who cares if the signal is stuck halfway?". Here's why:
 
As explained above, if your latch catches a signal in a halfway state and feeds it on to your logic, some of your logic will see that halfway point as a 0 and some will see it as a 1 due to slight differences in thresholds (nothing is perfect). Thus two different pieces of your design may activate at the same time when you were only wanting one part to activate on a 0 signal and the other part to activate on a 1 signal. Bad things happen when mutually exclusive logic becomes active simultaneously.
 
0 Kudos
9,530 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts -- VHDL example of a double flip-flop synchronizer

----------------------------------------------------------------------------------
-- Company: MKSystems
-- Engineer: Mike Schoonover
--
-- Create Date:    18:04:56 03/01/2009
-- Design Name:
-- Module Name:    Synchronizer - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:
--
-- This component synchronizes the asynchronous input signal "async" to the
-- input "clk" using the double flip flop method.
--
-- The appropriate signals are tagged with directives which prevent the
-- timing analysis tools from flagging them when they violate timing constraints.
--
-- The original code was copied from the Xilinx example libraries, accessed in
-- ISE 10.1 by:
--
-- Edit/Language Templates/VHDL/Synthesis Constructs/Coding Examples/Misc/
--        Asynchronous Input Synchronization (Reduces Issues /w Metastability)
--
-- The following are the comments from the original code:
--
-- NOTE from MKS: HBLKNM does not work, and TIG is no longer allowed to be
-- specified here if using ISE 10.1.
--
-- --------------------------------------------------------------------------
--
-- The following code is an example of double registering an asynchronous input
-- of a design to reduce the probability of metastability affecting a circuit.
-- Several synthesis and implementation attributes are added to the code in
-- order improve the characteristics of the implementation:
--
--  TIG="TRUE" - Specifies a timing ignore for the asynchronous input
--  IOB="FALSE" = Specifies to not place the register into the IOB allowing
--                both synchronization registers to exist in the same slice
--                allowing for the shortest propagation time between them
--  ASYNC_REG="TRUE" - Specifies registers will be receiving asynchronous data
--                     input to allow for better timing simulation
--                     characteristics
--  SHIFT_EXTRACT="NO" - Specifies to the synthesis tool to not infer an SRL
--  HBLKNM="sync_reg" - Specifies to pack both registers into the same slice

-- clk, async_in are inputs and sync_out is an output

-- Insert the following before the 'begin' keyword

-- signal sreg : std_logic_vector(1 downto 0);

-- attribute TIG : string;
-- attribute IOB : string;
-- attribute ASYNC_REG : string;
-- attribute SHIFT_EXTRACT : string;
-- attribute HBLKNM : string;

-- attribute TIG of async_in : signal is "TRUE";
-- attribute IOB of async_in : signal is "FALSE";
-- attribute ASYNC_REG of sreg : signal is "TRUE";
-- attribute SHIFT_EXTRACT of sreg : signal is "NO";
-- attribute HBLKNM of sreg : signal is "sync_reg";

-- Insert the following after the 'begin' keyword
-- process (clk)
-- begin
--    if clk'event and clk='1' then  
--       sync_out <= sreg(1);
--        sreg <= sreg(0) & async_in;
--    end if;
-- end process;
--
-- --------------------------------------------------------------------------
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Synchronizer is
    Port (
        clk : in  STD_LOGIC;    
        async_in : in  STD_LOGIC;    
        sync_out : out STD_LOGIC :='0'
        );
end Synchronizer;

architecture Behavioral of Synchronizer is

signal sreg : std_logic_vector(1 downto 0) := "00";

attribute IOB : string;
attribute ASYNC_REG : string;
attribute SHIFT_EXTRACT : string;

attribute IOB of async_in : signal is "FALSE";
attribute ASYNC_REG of sreg : signal is "TRUE";
attribute SHIFT_EXTRACT of sreg : signal is "NO";

-- NOTE: The TIG on async_in above did not prevent the simulator from
--       reporting timing violations.  A TIG on the input net was placed
--            in the constraints file to solve the problem.
--

begin

process (clk)
begin
   if clk'event and clk='1' then  
      sync_out <= sreg(1);
       sreg <= sreg(0) & async_in;
   end if;
end process;

end Behavioral;

0 Kudos
9,529 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts -- VHDL example of a double flip-flop synchronizer -- notes

 

It might be confusing since I included the original Xilinx code in the comments so it looks like the code is in there twice.

 

That code at the top is commented out -- that is the Xilinx example.

 

My revised code is at the bottom.

 

I did have trouble getting the timing analyzer at the time to not give error messages for the asynchronous first flip flop. I tried everything. I just gave up, looked at each warning, and ignored it if it was for the first stage of any sychronizer. Xilinx LOVES warnings.

0 Kudos
Historian
Historian
9,508 Views
Registered: ‎02-25-2008

Re: Advance FPGA Design by Steve Kilts


@mike@folsomvillage.com wrote:

 

Nope -- don't have any good books on the fpga design.

 

My buddy does recommend "VHDL for Programmable Logic" by Kevin Skahill as a good book for the VHDL end of it -- and it is important to have a good grasp of VHDL.


 

 

That book was originally written to support Cypress CPLDs, I think -- and when I last looked it it, it was horribly out of date. So while it's a good starting point, look for something more recent. The language, the tools and the devices have all evolved since that book was published.

 

 


3) Half the people tell you that you must do post layout timing analysis, half tell you that you do not. It's a LOT of work to set up the analysis and it must be redone for any changes. So far, the most sensible answer has been to test timing by running the hardware under temperature extremes. If you can't find the errors that way, then do the analysis.


 

The people who tell you that you don't need to do post P&R timing analysis are fools. Full Stop. You "sensible answer" really isn't, because there's more to timing analysis than temperature extremes. Your one device on one board is running with a particular power-supply set-up, and the FPGA is from some particular lot. If you change any of these variables, then your test results are null.

 

So learn how to do the timing analysis. For the simple cases, all that's necessary is a PERIOD constraint on your clock. For more complex stuff, you need the OFFSET IN constraints, which I admit are difficult. (See various threads here, including one I started.) 

 

Consider the case where you have a source-synchronous bus with edge-aligned DDR data. How do you know if your timing is good? How do you know how to set the various clock and data input delays? Well, you run the static timing analysis.

 


4) Xilinx recommends letting the software determine where to place the I/O pads to make sure it can meet timing. Ha ha. Ha. Ha. Good luck with that. It will scatter your 32 bit address bus all over the chip. Good luck routing it. I picked sensible pad layout and everything worked out. My more experienced friends agree with this one. 


The recommendations to let the tools pick the pinouts have been obsolete since the XC4000 series devices went obsolete. In general, you need to specify everything if you want your PCB layout guy to not hate you. At the very least, you must specify clock pins, and which bank signals go in. And you have to specify the IOSTANDARD and all of that stuff.

----------------------------Yes, I do this for a living.
0 Kudos
Teacher rcingham
Teacher
9,492 Views
Registered: ‎09-09-2010

Re: Advance FPGA Design by Steve Kilts

> The recommendations to let the tools pick the pinouts have been obsolete since the XC4000 series devices went obsolete. In general, you need to specify everything if you want your PCB layout guy to not hate you. At the very least, you must specify clock pins, and which bank signals go in. And you have to specify the IOSTANDARD and all of that stuff.

BUT, as some other threads attest, you must do a preliminary build BEFORE sending the PCB design off for fabrication, especially for clock inputs, and DDR I/O (e.g. SDRAMs).

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Historian
Historian
9,477 Views
Registered: ‎02-25-2008

Re: Advance FPGA Design by Steve Kilts


@rcingham wrote:
> The recommendations to let the tools pick the pinouts have been obsolete since the XC4000 series devices went obsolete. In general, you need to specify everything if you want your PCB layout guy to not hate you. At the very least, you must specify clock pins, and which bank signals go in. And you have to specify the IOSTANDARD and all of that stuff.

BUT, as some other threads attest, you must do a preliminary build BEFORE sending the PCB design off for fabrication, especially for clock inputs, and DDR I/O (e.g. SDRAMs).

By "Specify everything," that means that the FPGA design is essentially done before the board goes out to fab. Because I've run into situations where an incomplete design with pin selections places and routes, but when the blanks are filled in, something breaks (usually with clock connections/restrictions). 

 

So it's iterative. The board layout person gets design rules which state, "THESE pins must not move, these other pins can be swapped among this bank, etc etc." And when the routing is finished, the UCF is updated with the changes and the tools run again.

----------------------------Yes, I do this for a living.
0 Kudos
Teacher rcingham
Teacher
9,461 Views
Registered: ‎09-09-2010

Re: Advance FPGA Design by Steve Kilts


@bassman59 wrote:

@rcingham wrote:
> The recommendations to let the tools pick the pinouts have been obsolete since the XC4000 series devices went obsolete. In general, you need to specify everything if you want your PCB layout guy to not hate you. At the very least, you must specify clock pins, and which bank signals go in. And you have to specify the IOSTANDARD and all of that stuff.

BUT, as some other threads attest, you must do a preliminary build BEFORE sending the PCB design off for fabrication, especially for clock inputs, and DDR I/O (e.g. SDRAMs).

By "Specify everything," that means that the FPGA design is essentially done before the board goes out to fab. Because I've run into situations where an incomplete design with pin selections places and routes, but when the blanks are filled in, something breaks (usually with clock connections/restrictions). 

 

So it's iterative. The board layout person gets design rules which state, "THESE pins must not move, these other pins can be swapped among this bank, etc etc." And when the routing is finished, the UCF is updated with the changes and the tools run again.


Agreed.

 

 


------------------------------------------
"If it don't work in simulation, it won't work on the board."
9,382 Views
Registered: ‎10-30-2012

Re: Advance FPGA Design by Steve Kilts

Sorry for answering this so late.Your answer is excellent!I have already known the reason for the double synchronizers.

 

=================================================

to this :

3) Half the people tell you that you must do post layout timing analysis, half tell you that you do not. It's a LOT of work to set up the analysis and it must be redone for any changes. So far, the most sensible answer has been to test timing by running the hardware under temperature extremes. If you can't find the errors that way, then do the analysis.

 

I think post layout timing analysis is important,because it determine your design's reliability and robustness.But if your system is in a low frequency,(below 100mHz)and the combined logic between 2 reg is very limited and the input and output signal from/to the adjacent ICs are in slow frequency,and so on ...OK,OK,I think doing this is really really possible,and it's boundary between premary and intermidiate engineer.

0 Kudos
9,379 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts

 

Yes, I have to agree with you there.

 

I think I should also clarify that I agree that the first level of timing analysis, i.e. specifying a clock speed and then viewing the Post-PAR Static Timing Report is a must, although 99% of what it says is meaningless to me. It's really the next level -- the PAR simulation that seems to be the cause of much disagreement.

 

At some point, I would have to spend a year (or ten years) of concentrated study with the Xilinx software in order to become comfortable with what it is telling me. I admit that it would be a great source of joy to delve into this jungle of learning, but alas -- the FPGA is only a part of my project. There are SO many people out in the world who are trying to wrestle with FPGA programming without a solid background in the subject.

0 Kudos
9,356 Views
Registered: ‎10-30-2012

Re: Advance FPGA Design by Steve Kilts

Your project?Need not to consider the cost of time? Or an open source project?Why not firstly try to gather some people who are good  at different aspects then begin the project?

0 Kudos
Historian
Historian
9,339 Views
Registered: ‎02-25-2008

Re: Advance FPGA Design by Steve Kilts


@mike@folsomvillage.com wrote:

 

 There are SO many people out in the world who are trying to wrestle with FPGA programming without a solid background in the subject.


True. 

It seems like there are SO many people who think that what we do for a living is easily learned in a forum post.

----------------------------Yes, I do this for a living.
0 Kudos
2,645 Views
Registered: ‎01-06-2009

Re: Advance FPGA Design by Steve Kilts

 

Yep -- that's EXACTLY where I Iearned what little I know. Sometimes, my stuff almost works, too.

0 Kudos