Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 145650

Article: 145650
Subject: Re: How a state machine is constructed using latches?
From: Andy <jonesandy@comcast.net>
Date: Wed, 17 Feb 2010 08:11:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 9:48=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> Now I ask how the next state latch is generated.
>

The latch is not just for S0, it is for the entire state. S0 is a
value for the state register, not a register or latch itself (unless
the FSM is one-hot encoded, but even then, the other state bits would
have a corresponding latch, with the same control, but with their
normal logic as the input).

It is only latched when in S0 (with other conditions: CO1 =3D '0' and
CO2 =3D '0').
The input to the latch is the all the normal next state logic.

Andy



Article: 145651
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 08:11:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Hi,
> > Sometimes, when an if statement misses a "else" statement part in a
> > two-process
> > method for a state machine, a latch-type state machine would be built.
>
> > I always wondering how the state machine is built: using all latches
> > for the state machine
> > or using only one latch for the state which misses a "else" statement
> > part.
>
> A latch type state machine is not built; the latch is only inserted
> into the next state logic. A flip-flop still holds the current state.
>
> I know the following is not the point of your post, but your example
> implies that missing "else" statements generate latches.
>
> This is not true.
>
> Missing assignments generate latches. If a driven signal in a
> combinatorial process is not assigned a value in a given execution of
> the process, then the simulator has to remember what the last
> assignment was. The synthesis tool generates a latch to create that
> memory.
>
> Similarly for a variable in a combinatorial process, if the variable
> is read before it has been written in any given execution of that
> process, a latch is created to remember the last assignment.
>
> If I use a combinatorial process (extremely rarely in RTL), I make a
> default assignment to every signal & variable driven by the process,
> right up front, where it is always executed (and before any variables
> are read). In the case of the next state logic, it would simply be
> "state_ns <=3D state_a;". That way there is no need to code useless else
> statements everywhere (and all the assignments that must otherwise be
> included in them).
>
> Andy

Andy,
I read your post carefully and found my point stands:
"your example implies that missing "else" statements generate
latches.
This is not true. "

This is true !!! Based on your claim: Missing assignments (in a
combinational process) generate latches .

If one misses "else" (in a combinational process), it misses an
assignment statement.

Weng





Article: 145652
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 08:17:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 8:11=A0am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 9:48=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
> > Now I ask how the next state latch is generated.
>
> The latch is not just for S0, it is for the entire state. S0 is a
> value for the state register, not a register or latch itself (unless
> the FSM is one-hot encoded, but even then, the other state bits would
> have a corresponding latch, with the same control, but with their
> normal logic as the input).
>
> It is only latched when in S0 (with other conditions: CO1 =3D '0' and
> CO2 =3D '0').
> The input to the latch is the all the normal next state logic.
>
> Andy

Andy,
I disagree with your point.

In the situation, at most only one latch is needed to resolve the
problem. Why full state machine?

We can safely assume the state machine is one-hot encoded.

Weng

Article: 145653
Subject: Re: How a state machine is constructed using latches?
From: whygee <yg@yg.yg>
Date: Wed, 17 Feb 2010 17:18:36 +0100
Links: << >>  << T >>  << A >>
hi,

Weng Tianxiang wrote:
> In the situation, at most only one latch is needed to resolve the
> problem. Why full state machine?
> We can safely assume the state machine is one-hot encoded.
if you have troubles infering latches,
then you can implement them directly
with a specific entity ?
it's not looking as "smart" but
removes any ambiguity from your code.

> Weng
yg

-- 
http://ygdes.com / http://yasep.org

Article: 145654
Subject: Re: How a state machine is constructed using latches?
From: Andy Peters <google@latke.net>
Date: Wed, 17 Feb 2010 09:50:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 9:11=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
>
>
>
> > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Hi,
> > > Sometimes, when an if statement misses a "else" statement part in a
> > > two-process
> > > method for a state machine, a latch-type state machine would be built=
.
>
> > > I always wondering how the state machine is built: using all latches
> > > for the state machine
> > > or using only one latch for the state which misses a "else" statement
> > > part.
>
> > A latch type state machine is not built; the latch is only inserted
> > into the next state logic. A flip-flop still holds the current state.
>
> > I know the following is not the point of your post, but your example
> > implies that missing "else" statements generate latches.
>
> > This is not true.
>
> > Missing assignments generate latches. If a driven signal in a
> > combinatorial process is not assigned a value in a given execution of
> > the process, then the simulator has to remember what the last
> > assignment was. The synthesis tool generates a latch to create that
> > memory.
>
> > Similarly for a variable in a combinatorial process, if the variable
> > is read before it has been written in any given execution of that
> > process, a latch is created to remember the last assignment.
>
> > If I use a combinatorial process (extremely rarely in RTL), I make a
> > default assignment to every signal & variable driven by the process,
> > right up front, where it is always executed (and before any variables
> > are read). In the case of the next state logic, it would simply be
> > "state_ns <=3D state_a;". That way there is no need to code useless els=
e
> > statements everywhere (and all the assignments that must otherwise be
> > included in them).
>
> > Andy
>
> Andy,
> I read your post carefully and found my point stands:
> "your example implies that missing "else" statements generate
> latches.
> This is not true. "
>
> This is true !!! Based on your claim: Missing assignments (in a
> combinational process) generate latches .
>
> If one misses "else" (in a combinational process), it misses an
> assignment statement.
>
> Weng

I think the other Andy's point is that missing an "else" clause in a
combinatorial process is a special case of the more general "missing
an assignment."

-a

Article: 145655
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 10:30:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 9:50=A0am, Andy Peters <goo...@latke.net> wrote:
> On Feb 17, 9:11=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > Hi,
> > > > Sometimes, when an if statement misses a "else" statement part in a
> > > > two-process
> > > > method for a state machine, a latch-type state machine would be bui=
lt.
>
> > > > I always wondering how the state machine is built: using all latche=
s
> > > > for the state machine
> > > > or using only one latch for the state which misses a "else" stateme=
nt
> > > > part.
>
> > > A latch type state machine is not built; the latch is only inserted
> > > into the next state logic. A flip-flop still holds the current state.
>
> > > I know the following is not the point of your post, but your example
> > > implies that missing "else" statements generate latches.
>
> > > This is not true.
>
> > > Missing assignments generate latches. If a driven signal in a
> > > combinatorial process is not assigned a value in a given execution of
> > > the process, then the simulator has to remember what the last
> > > assignment was. The synthesis tool generates a latch to create that
> > > memory.
>
> > > Similarly for a variable in a combinatorial process, if the variable
> > > is read before it has been written in any given execution of that
> > > process, a latch is created to remember the last assignment.
>
> > > If I use a combinatorial process (extremely rarely in RTL), I make a
> > > default assignment to every signal & variable driven by the process,
> > > right up front, where it is always executed (and before any variables
> > > are read). In the case of the next state logic, it would simply be
> > > "state_ns <=3D state_a;". That way there is no need to code useless e=
lse
> > > statements everywhere (and all the assignments that must otherwise be
> > > included in them).
>
> > > Andy
>
> > Andy,
> > I read your post carefully and found my point stands:
> > "your example implies that missing "else" statements generate
> > latches.
> > This is not true. "
>
> > This is true !!! Based on your claim: Missing assignments (in a
> > combinational process) generate latches .
>
> > If one misses "else" (in a combinational process), it misses an
> > assignment statement.
>
> > Weng
>
> I think the other Andy's point is that missing an "else" clause in a
> combinatorial process is a special case of the more general "missing
> an assignment."
>
> -a

No.

Here is another example showing Andy's point is not correct:

Here is the code.
Process_1 : process(RESET, CLK)
begin
   if RESET =3D '1' then
      State_A <=3D S0;
   elsif CLK'event and CLK =3D '1' then
      State_A <=3D State_NS;
   end if;
end process;

Process_2 : process(...)
begin
   case State_A is
      when S0 =3D>
         if C01 =3D '1' then
           State_NS <=3D S1;
         elsif C02 =3D '1' then
           State_NS <=3D S2;
         else
           -- here an assignment statement is missing, but it doesn't
generate latch version !!!
           -- it is treated as a null statement.
         end if;
      when S1 =3D>  -- the followings are normal coding
         ...;
      when others =3D>
         ...;
   end case;
end process;

If you have a compiler of VHDL, try to compile it to see what happens
with "else" and without "else".

Weng

Article: 145656
Subject: Re: How a state machine is constructed using latches?
From: sharp@cadence.com
Date: Wed, 17 Feb 2010 11:46:03 -0800 (PST)
Links: << >>  << T >>  << A >>
I agree with Andy.  The important thing is whether there is a path
through the code that does not assign one of the outputs.  This is
often due to a missing else, but it is the assignment that matters.

You can have a missing else without a missing assignment, and there is
no latch.  All that is required is that you have an unconditional
assignment to the outputs also.

You can have a missing assignment without a missing else, and there is
a latch.  The else may be present, but assign only a subset of the
outputs.

Article: 145657
Subject: Re: How a state machine is constructed using latches?
From: sharp@cadence.com
Date: Wed, 17 Feb 2010 11:57:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 1:30=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> Here is another example showing Andy's point is not correct:
>
...
> =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0-- here an assignment statement is missing, but it=
 doesn't
> generate latch version !!!
> =A0 =A0 =A0 =A0 =A0 =A0-- it is treated as a null statement.

It may recognize that the latch for State_A already provides the
necessary latch to hold the state, and that it doesn't need an
additional latch for State_NS.  Recognizing that it can re-use the
value from an existing latch is different from not needing a latch at
all.


Article: 145658
Subject: Re: How a state machine is constructed using latches?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 17 Feb 2010 14:16:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 1:30=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> =A0 =A0case State_A is
> =A0 =A0 =A0 when S0 =3D>
> =A0 =A0 =A0 =A0 =A0if C01 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S1;
> =A0 =A0 =A0 =A0 =A0elsif C02 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S2;
> =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0-- here an assignment statement is missing, but it=
 doesn't
> generate latch version !!!
> =A0 =A0 =A0 =A0 =A0 =A0-- it is treated as a null statement.

A 'null statement' in this particular instance means that State_NS
will not change.  If it doesn't change, this obviously implies it must
hold it's current value.  So if C01 and C02 are both not equal to '1'
then whatever value State_NS has, it will keep.  This implies that a
hardware implementation will have to implement the following
combinatorial logic as part of the logic for State_NS

State_NS <=3D ... (logic that handles the C01=3D1 and the C02=3D1
conditions)
         or not(C01) and not(C02) and State_NS;

The last 'or' term is what implements the 'missing else branch'.

When you have a condition where you have
- A combinatorial assignment (we do, State_NS)
- The assigned to signal is also on the right hand side (we do)

This situation is commonly referred to as a 'latch'.  Maybe it
shouldn't be but many times it is.  A better term, in my opinion,
would be a combinatorial loop, which is to say that the generating
logic for some signal depends on the value of that signal itself.  In
FPGA designs, it is typically a flag that you may have a design error.

The simplest form of this is type of condition is an oscillator x <=3D
not(x);

> If you have a compiler of VHDL, try to compile it to see what happens
> with "else" and without "else".
>
Which tool are you using?

KJ

Article: 145659
Subject: Re: How a state machine is constructed using latches?
From: rickman <gnuarm@gmail.com>
Date: Wed, 17 Feb 2010 15:46:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Like Andy said, it is not the missing else that causes the latch to be
generated, it is the lack of an assignment in some path of the
process.  The else is a control flow structure and has nothing to do
with assignments.  Andy even gave you an example of when a missing
else will not generate a latch... when an assignment has been made
before or after the missing else...

I am pretty sure your example below *will* generate a latch.

On Feb 17, 1:30=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 17, 9:50=A0am, Andy Peters <goo...@latke.net> wrote:
>
> > On Feb 17, 9:11=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > Hi,
> > > > > Sometimes, when an if statement misses a "else" statement part in=
 a
> > > > > two-process
> > > > > method for a state machine, a latch-type state machine would be b=
uilt.
>
> > > > > I always wondering how the state machine is built: using all latc=
hes
> > > > > for the state machine
> > > > > or using only one latch for the state which misses a "else" state=
ment
> > > > > part.
>
> > > > A latch type state machine is not built; the latch is only inserted
> > > > into the next state logic. A flip-flop still holds the current stat=
e.
>
> > > > I know the following is not the point of your post, but your exampl=
e
> > > > implies that missing "else" statements generate latches.
>
> > > > This is not true.
>
> > > > Missing assignments generate latches. If a driven signal in a
> > > > combinatorial process is not assigned a value in a given execution =
of
> > > > the process, then the simulator has to remember what the last
> > > > assignment was. The synthesis tool generates a latch to create that
> > > > memory.
>
> > > > Similarly for a variable in a combinatorial process, if the variabl=
e
> > > > is read before it has been written in any given execution of that
> > > > process, a latch is created to remember the last assignment.
>
> > > > If I use a combinatorial process (extremely rarely in RTL), I make =
a
> > > > default assignment to every signal & variable driven by the process=
,
> > > > right up front, where it is always executed (and before any variabl=
es
> > > > are read). In the case of the next state logic, it would simply be
> > > > "state_ns <=3D state_a;". That way there is no need to code useless=
 else
> > > > statements everywhere (and all the assignments that must otherwise =
be
> > > > included in them).
>
> > > > Andy
>
> > > Andy,
> > > I read your post carefully and found my point stands:
> > > "your example implies that missing "else" statements generate
> > > latches.
> > > This is not true. "
>
> > > This is true !!! Based on your claim: Missing assignments (in a
> > > combinational process) generate latches .
>
> > > If one misses "else" (in a combinational process), it misses an
> > > assignment statement.
>
> > > Weng
>
> > I think the other Andy's point is that missing an "else" clause in a
> > combinatorial process is a special case of the more general "missing
> > an assignment."
>
> > -a
>
> No.
>
> Here is another example showing Andy's point is not correct:
>
> Here is the code.
> Process_1 : process(RESET, CLK)
> begin
> =A0 =A0if RESET =3D '1' then
> =A0 =A0 =A0 State_A <=3D S0;
> =A0 =A0elsif CLK'event and CLK =3D '1' then
> =A0 =A0 =A0 State_A <=3D State_NS;
> =A0 =A0end if;
> end process;
>
> Process_2 : process(...)
> begin
> =A0 =A0case State_A is
> =A0 =A0 =A0 when S0 =3D>
> =A0 =A0 =A0 =A0 =A0if C01 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S1;
> =A0 =A0 =A0 =A0 =A0elsif C02 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S2;
> =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0-- here an assignment statement is missing, but it=
 doesn't
> generate latch version !!!
> =A0 =A0 =A0 =A0 =A0 =A0-- it is treated as a null statement.
             -- it does not matter if it is a null statement.  The
process has to *remember* the last value of State_NS since it is not
assigned, so a latch is generated.  See below
> =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 when S1 =3D> =A0-- the followings are normal coding
> =A0 =A0 =A0 =A0 =A0...;
> =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0...;
> =A0 =A0end case;
> end process;
>
> If you have a compiler of VHDL, try to compile it to see what happens
> with "else" and without "else".
>
> Weng

   case State_A is
      when S0 =3D>
         State_NS <=3D S0;
         if C01 =3D '1' then
           State_NS <=3D S1;
         elsif C02 =3D '1' then
           State_NS <=3D S2;
         else
           -- here an assignment statement is missing, but it doesn't
generate latch version !!!
           -- it is treated as a null statement.
         end if;
Here the state is explicitly assigned, so it can still be calculated
from the inputs, in this case State_A, C01 and C02.

This is an HDL (Hardware Description Language).  Don't try to come up
with a set of rules of how hardware will be generated based on control
flow constructs.  The only thing that matters is what operations of
the hardware are being described and therefore what hardware is being
described.

Rick

Article: 145660
Subject: Unpredictable design
From: "de4" <de4@n_o_s_p_a_m.poczta.onet.pl>
Date: Wed, 17 Feb 2010 17:55:07 -0600
Links: << >>  << T >>  << A >>
Hello !

I have a very big problem. I created a simple procesor and on simulation it
works fine, on step mode it works fine but when it is running on full speed
of clock it got crazy... :( It should execute instruction i order
0.1.2.3.4.5 (Program Counter values and PC is connected to leds) and it
executes sometimes 0.1.3.5 some times 0.1.2.3.4.5.6.7.8.9 or 0.1.2.6.3.4 or
0.1 or sometimes it is as it should. Sometimes it stops suddenly executing
or executing too much. It is written in VHDL on Spartan 3A. It is too big
to show it here but maybe some experts will be able to tell me what is
going on... I have constraints like this in UCF file :

NET "Clock" LOC = C10;
NET "Clock" IOSTANDARD = LVCMOS33;
NET "Clock" PERIOD = 62.5ns HIGH 50%;
NET "Reset" LOC = H4;
NET "Reset" IOSTANDARD = LVCMOS33;
NET "TX" LOC = B3;
NET "TX" IOSTANDARD = LVCMOS33;
NET "RX" LOC = A3;
NET "RX" IOSTANDARD = LVCMOS33;

are there any other constraint useful for me ? Can it be constraint fault ?
Or  it must be design problem ? Or something else ? 16Mhz clock is
connected to FPGA. It works OK using step by step mode but on full speed
it's stragne bevahior... I really need help, I trying to solve it for three
days and nothing...

Thank you all for any answers...	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145661
Subject: Re: Unpredictable design
From: Symon <symon_brewer@hotmail.com>
Date: Thu, 18 Feb 2010 00:04:57 +0000
Links: << >>  << T >>  << A >>
On 2/17/2010 11:55 PM, de4 wrote:
> works fine, on step mode it works fine but when it is running on full speed
> of clock it got crazy...

> NET "Clock" PERIOD = 62.5ns HIGH 50%;
>

What is 'step mode' exactly? Your clock is relatively slow. So, your 
problem is probably something to do with clock skew. Is your clock on a 
GBUF? Does your clock connect to anything other than a dedicated clock 
input of the FPGAs innards?

HTH Syms.


Article: 145662
Subject: Re: How a state machine is constructed using latches?
From: rickman <gnuarm@gmail.com>
Date: Wed, 17 Feb 2010 16:29:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 1:30=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 17, 9:50=A0am, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > On Feb 17, 9:11=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > Hi,
> > > > > Sometimes, when an if statement misses a "else" statement part in=
 a
> > > > > two-process
> > > > > method for a state machine, a latch-type state machine would be b=
uilt.
>
> > > > > I always wondering how the state machine is built: using all latc=
hes
> > > > > for the state machine
> > > > > or using only one latch for the state which misses a "else" state=
ment
> > > > > part.
>
> > > > A latch type state machine is not built; the latch is only inserted
> > > > into the next state logic. A flip-flop still holds the current stat=
e.
>
> > > > I know the following is not the point of your post, but your exampl=
e
> > > > implies that missing "else" statements generate latches.
>
> > > > This is not true.
>
> > > > Missing assignments generate latches. If a driven signal in a
> > > > combinatorial process is not assigned a value in a given execution =
of
> > > > the process, then the simulator has to remember what the last
> > > > assignment was. The synthesis tool generates a latch to create that
> > > > memory.
>
> > > > Similarly for a variable in a combinatorial process, if the variabl=
e
> > > > is read before it has been written in any given execution of that
> > > > process, a latch is created to remember the last assignment.
>
> > > > If I use a combinatorial process (extremely rarely in RTL), I make =
a
> > > > default assignment to every signal & variable driven by the process=
,
> > > > right up front, where it is always executed (and before any variabl=
es
> > > > are read). In the case of the next state logic, it would simply be
> > > > "state_ns <=3D state_a;". That way there is no need to code useless=
 else
> > > > statements everywhere (and all the assignments that must otherwise =
be
> > > > included in them).
>
> > > > Andy
>
> > > Andy,
> > > I read your post carefully and found my point stands:
> > > "your example implies that missing "else" statements generate
> > > latches.
> > > This is not true. "
>
> > > This is true !!! Based on your claim: Missing assignments (in a
> > > combinational process) generate latches .
>
> > > If one misses "else" (in a combinational process), it misses an
> > > assignment statement.
>
> > > Weng
>
> > I think the other Andy's point is that missing an "else" clause in a
> > combinatorial process is a special case of the more general "missing
> > an assignment."
>
> > -a
>
> No.
>
> Here is another example showing Andy's point is not correct:
>
> Here is the code.
> Process_1 : process(RESET, CLK)
> begin
> =A0 =A0if RESET =3D '1' then
> =A0 =A0 =A0 State_A <=3D S0;
> =A0 =A0elsif CLK'event and CLK =3D '1' then
> =A0 =A0 =A0 State_A <=3D State_NS;
> =A0 =A0end if;
> end process;
>
> Process_2 : process(...)
> begin
> =A0 =A0case State_A is
> =A0 =A0 =A0 when S0 =3D>
> =A0 =A0 =A0 =A0 =A0if C01 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S1;
> =A0 =A0 =A0 =A0 =A0elsif C02 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S2;
> =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0-- here an assignment statement is missing, but it=
 doesn't
> generate latch version !!!
> =A0 =A0 =A0 =A0 =A0 =A0-- it is treated as a null statement.
> =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 when S1 =3D> =A0-- the followings are normal coding
> =A0 =A0 =A0 =A0 =A0...;
> =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 =A0...;
> =A0 =A0end case;
> end process;
>
> If you have a compiler of VHDL, try to compile it to see what happens
> with "else" and without "else".
>
> Weng

Fight fire with fire!  The two reports below show that both the
missing else and the missing assignment (which is also missing in the
missing else case) produce latches.

@W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
57:4:57:7|Latch generated from process for signal Latch, probably
caused by a missing assignment in an if or case stmt
@W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
40:4:40:7|Latch generated from process for signal Comb, probably
caused by a missing assignment in an if or case stmt

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity LatchSynthTest is
  port(
	  CLK			: in	std_logic ;
	  RESET			: in	std_logic ;
	  C01			: in	std_logic ;
	  C02			: in	std_logic ;
	  LatchOutput	: out	std_logic ;
	  CombOutput	: out	std_logic
	  );
end LatchSynthTest ;

architecture behavior of LatchSynthTest is
  SIGNAL Latch		: std_logic;
  SIGNAL Comb		: std_logic;
  SIGNAL LatchReg	: std_logic;
  SIGNAL CombReg	: std_logic;

begin

  CombOutput	<=3D CombReg;
  LatchOutput	<=3D LatchReg;

  Process_1 : process(RESET, CLK)
  begin
    if (RESET =3D '1') then
      LatchReg	<=3D '0';
      CombReg	<=3D '0';
    elsif (rising_edge(CLK)) then
      LatchReg	<=3D Latch;
      CombReg	<=3D Comb;
    end if;
  end process;

  CombProc : process(CombReg, C01, C02)
  begin
    case CombReg is
      when '0' =3D>
        if (C01 =3D '1') then
          Comb <=3D '0';
        elsif (C02 =3D '1') then
          Comb <=3D '1';
        else
          -- Here an assignment statement is missing, but it doesn't
          -- generate latch.  It is treated as a null statement. -
Weng
        end if;
      when others =3D>
        Comb <=3D '1';
    end case;
  end process;

  LatchProc : process(LatchReg, C01, C02)
  begin
    case LatchReg is
      when '0' =3D>
        if C01 =3D '1' then
          Latch <=3D '0';
        elsif C02 =3D '1' then
          Latch <=3D '1';
          -- Here the else is missing, and it does
          -- generate latch.  It is treated as a null statement.
        end if;
      when others =3D>
        Latch <=3D '1';
    end case;
  end process;

end behavior;


Article: 145663
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 17:05:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 4:29=A0pm, rickman <gnu...@gmail.com> wrote:
> On Feb 17, 1:30=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 17, 9:50=A0am, Andy Peters <goo...@latke.net> wrote:
>
> > > On Feb 17, 9:11=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > > > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > > Hi,
> > > > > > Sometimes, when an if statement misses a "else" statement part =
in a
> > > > > > two-process
> > > > > > method for a state machine, a latch-type state machine would be=
 built.
>
> > > > > > I always wondering how the state machine is built: using all la=
tches
> > > > > > for the state machine
> > > > > > or using only one latch for the state which misses a "else" sta=
tement
> > > > > > part.
>
> > > > > A latch type state machine is not built; the latch is only insert=
ed
> > > > > into the next state logic. A flip-flop still holds the current st=
ate.
>
> > > > > I know the following is not the point of your post, but your exam=
ple
> > > > > implies that missing "else" statements generate latches.
>
> > > > > This is not true.
>
> > > > > Missing assignments generate latches. If a driven signal in a
> > > > > combinatorial process is not assigned a value in a given executio=
n of
> > > > > the process, then the simulator has to remember what the last
> > > > > assignment was. The synthesis tool generates a latch to create th=
at
> > > > > memory.
>
> > > > > Similarly for a variable in a combinatorial process, if the varia=
ble
> > > > > is read before it has been written in any given execution of that
> > > > > process, a latch is created to remember the last assignment.
>
> > > > > If I use a combinatorial process (extremely rarely in RTL), I mak=
e a
> > > > > default assignment to every signal & variable driven by the proce=
ss,
> > > > > right up front, where it is always executed (and before any varia=
bles
> > > > > are read). In the case of the next state logic, it would simply b=
e
> > > > > "state_ns <=3D state_a;". That way there is no need to code usele=
ss else
> > > > > statements everywhere (and all the assignments that must otherwis=
e be
> > > > > included in them).
>
> > > > > Andy
>
> > > > Andy,
> > > > I read your post carefully and found my point stands:
> > > > "your example implies that missing "else" statements generate
> > > > latches.
> > > > This is not true. "
>
> > > > This is true !!! Based on your claim: Missing assignments (in a
> > > > combinational process) generate latches .
>
> > > > If one misses "else" (in a combinational process), it misses an
> > > > assignment statement.
>
> > > > Weng
>
> > > I think the other Andy's point is that missing an "else" clause in a
> > > combinatorial process is a special case of the more general "missing
> > > an assignment."
>
> > > -a
>
> > No.
>
> > Here is another example showing Andy's point is not correct:
>
> > Here is the code.
> > Process_1 : process(RESET, CLK)
> > begin
> > =A0 =A0if RESET =3D '1' then
> > =A0 =A0 =A0 State_A <=3D S0;
> > =A0 =A0elsif CLK'event and CLK =3D '1' then
> > =A0 =A0 =A0 State_A <=3D State_NS;
> > =A0 =A0end if;
> > end process;
>
> > Process_2 : process(...)
> > begin
> > =A0 =A0case State_A is
> > =A0 =A0 =A0 when S0 =3D>
> > =A0 =A0 =A0 =A0 =A0if C01 =3D '1' then
> > =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S1;
> > =A0 =A0 =A0 =A0 =A0elsif C02 =3D '1' then
> > =A0 =A0 =A0 =A0 =A0 =A0State_NS <=3D S2;
> > =A0 =A0 =A0 =A0 =A0else
> > =A0 =A0 =A0 =A0 =A0 =A0-- here an assignment statement is missing, but =
it doesn't
> > generate latch version !!!
> > =A0 =A0 =A0 =A0 =A0 =A0-- it is treated as a null statement.
> > =A0 =A0 =A0 =A0 =A0end if;
> > =A0 =A0 =A0 when S1 =3D> =A0-- the followings are normal coding
> > =A0 =A0 =A0 =A0 =A0...;
> > =A0 =A0 =A0 when others =3D>
> > =A0 =A0 =A0 =A0 =A0...;
> > =A0 =A0end case;
> > end process;
>
> > If you have a compiler of VHDL, try to compile it to see what happens
> > with "else" and without "else".
>
> > Weng
>
> Fight fire with fire! =A0The two reports below show that both the
> missing else and the missing assignment (which is also missing in the
> missing else case) produce latches.
>
> @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> 57:4:57:7|Latch generated from process for signal Latch, probably
> caused by a missing assignment in an if or case stmt
> @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> 40:4:40:7|Latch generated from process for signal Comb, probably
> caused by a missing assignment in an if or case stmt
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
>
> entity LatchSynthTest is
> =A0 port(
> =A0 =A0 =A0 =A0 =A0 CLK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in =A0 =A0s=
td_logic ;
> =A0 =A0 =A0 =A0 =A0 RESET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in =A0 =A0std=
_logic ;
> =A0 =A0 =A0 =A0 =A0 C01 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in =A0 =A0s=
td_logic ;
> =A0 =A0 =A0 =A0 =A0 C02 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : in =A0 =A0s=
td_logic ;
> =A0 =A0 =A0 =A0 =A0 LatchOutput =A0 : out =A0 std_logic ;
> =A0 =A0 =A0 =A0 =A0 CombOutput =A0 =A0: out =A0 std_logic
> =A0 =A0 =A0 =A0 =A0 );
> end LatchSynthTest ;
>
> architecture behavior of LatchSynthTest is
> =A0 SIGNAL Latch =A0 =A0 =A0 =A0 =A0: std_logic;
> =A0 SIGNAL Comb =A0 =A0 =A0 =A0 =A0 : std_logic;
> =A0 SIGNAL LatchReg =A0 =A0 =A0 : std_logic;
> =A0 SIGNAL CombReg =A0 =A0 =A0 =A0: std_logic;
>
> begin
>
> =A0 CombOutput =A0 =A0<=3D CombReg;
> =A0 LatchOutput =A0 <=3D LatchReg;
>
> =A0 Process_1 : process(RESET, CLK)
> =A0 begin
> =A0 =A0 if (RESET =3D '1') then
> =A0 =A0 =A0 LatchReg =A0<=3D '0';
> =A0 =A0 =A0 CombReg =A0 <=3D '0';
> =A0 =A0 elsif (rising_edge(CLK)) then
> =A0 =A0 =A0 LatchReg =A0<=3D Latch;
> =A0 =A0 =A0 CombReg =A0 <=3D Comb;
> =A0 =A0 end if;
> =A0 end process;
>
> =A0 CombProc : process(CombReg, C01, C02)
> =A0 begin
> =A0 =A0 case CombReg is
> =A0 =A0 =A0 when '0' =3D>
> =A0 =A0 =A0 =A0 if (C01 =3D '1') then
> =A0 =A0 =A0 =A0 =A0 Comb <=3D '0';
> =A0 =A0 =A0 =A0 elsif (C02 =3D '1') then
> =A0 =A0 =A0 =A0 =A0 Comb <=3D '1';
> =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 -- Here an assignment statement is missing, but it do=
esn't
> =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a null stateme=
nt. -
> Weng
> =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 Comb <=3D '1';
> =A0 =A0 end case;
> =A0 end process;
>
> =A0 LatchProc : process(LatchReg, C01, C02)
> =A0 begin
> =A0 =A0 case LatchReg is
> =A0 =A0 =A0 when '0' =3D>
> =A0 =A0 =A0 =A0 if C01 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 Latch <=3D '0';
> =A0 =A0 =A0 =A0 elsif C02 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 Latch <=3D '1';
> =A0 =A0 =A0 =A0 =A0 -- Here the else is missing, and it does
> =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a null stateme=
nt.
> =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 when others =3D>
> =A0 =A0 =A0 =A0 Latch <=3D '1';
> =A0 =A0 end case;
> =A0 end process;
>
> end behavior;

Hi,
Thank you, Andy, Rick and everyone, I am wrong in the second point:
missing "else" or missing an assignment statement.

But my first point is how to generate a latch for a compiler. Rick,
can you see the floor plan to show how the latch is generated: for the
state only or for full states?

Weng

Article: 145664
Subject: Re: What is the basis on flip-flops replaced by a latch
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 17:12:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 5:38=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> > The latch is used with these processors for the exact reason you are
> > looking at latches. =A0It allows the output of the latch to output a
> > stable value from the input before the clock edge rather than after.
> > This was used to speed memory accesses.
>
> I still remember latches from when I first started learning about
> TTL from Popular Electronics. =A0It was usual to connect a 7490 counter,
> a 7475 latch and 7447 BCD to 7 segment decoder together. =A0You run
> the counter, the display counts (maybe too fast to see), and then
> latches at the appropriate time. =A0Sort of like a lap timer in
> a race, which counts up, the latch holds the value while the
> counter continues on. =A0After a short time the count continues
> on for the next lap. =A0(I think they do this on olympics races.)
>
> -- glen

glen,
I found a very good example on how to use a latch.

See Xilinx's patent: 5933369 "RAM with synchronous write port using
dynamic latches".

It describes the method Xilinx uses for its distributed RAM.

Weng

Article: 145665
Subject: Re: Unpredictable design
From: johnp <jprovidenza@yahoo.com>
Date: Wed, 17 Feb 2010 17:36:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 3:55=A0pm, "de4" <de4@n_o_s_p_a_m.poczta.onet.pl> wrote:
> Hello !
>
> I have a very big problem. I created a simple procesor and on simulation =
it
> works fine, on step mode it works fine but when it is running on full spe=
ed
> of clock it got crazy... :( It should execute instruction i order
> 0.1.2.3.4.5 (Program Counter values and PC is connected to leds) and it
> executes sometimes 0.1.3.5 some times 0.1.2.3.4.5.6.7.8.9 or 0.1.2.6.3.4 =
or
> 0.1 or sometimes it is as it should. Sometimes it stops suddenly executin=
g
> or executing too much. It is written in VHDL on Spartan 3A. It is too big
> to show it here but maybe some experts will be able to tell me what is
> going on... I have constraints like this in UCF file :
>
> NET "Clock" LOC =3D C10;
> NET "Clock" IOSTANDARD =3D LVCMOS33;
> NET "Clock" PERIOD =3D 62.5ns HIGH 50%;
> NET "Reset" LOC =3D H4;
> NET "Reset" IOSTANDARD =3D LVCMOS33;
> NET "TX" LOC =3D B3;
> NET "TX" IOSTANDARD =3D LVCMOS33;
> NET "RX" LOC =3D A3;
> NET "RX" IOSTANDARD =3D LVCMOS33;
>
> are there any other constraint useful for me ? Can it be constraint fault=
 ?
> Or =A0it must be design problem ? Or something else ? 16Mhz clock is
> connected to FPGA. It works OK using step by step mode but on full speed
> it's stragne bevahior... I really need help, I trying to solve it for thr=
ee
> days and nothing...
>
> Thank you all for any answers... =A0 =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

You don't mention if the design passes P&R with no timing errors.
Simply specifying constraints
doesn't mean they are actually met.

John Providenza

Article: 145666
Subject: Derived clock violation in Virtex4
From: Verictor <stehuang@gmail.com>
Date: Wed, 17 Feb 2010 18:09:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I have a V4 with input clock frequency running at 130MHz. This clock
goes into a DCM then CLK0 goes out to other logic. The CLK0 net is
named as "derived_clock" by Synplify. Now the timing report on the
input 130MHz is fine (positive slack) but the derived_clock doesn't
meet timing. How to contrain that?

Thanks.

Article: 145667
Subject: Re: How a state machine is constructed using latches?
From: rickman <gnuarm@gmail.com>
Date: Wed, 17 Feb 2010 19:51:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 8:05 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 17, 4:29 pm, rickman <gnu...@gmail.com> wrote:
> > Fight fire with fire!  The two reports below show that both the
> > missing else and the missing assignment (which is also missing in the
> > missing else case) produce latches.
>
> > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> > 57:4:57:7|Latch generated from process for signal Latch, probably
> > caused by a missing assignment in an if or case stmt
> > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> > 40:4:40:7|Latch generated from process for signal Comb, probably
> > caused by a missing assignment in an if or case stmt
>
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.numeric_std.all;
>
> > entity LatchSynthTest is
> >   port(
> >           CLK                   : in    std_logic ;
> >           RESET                 : in    std_logic ;
> >           C01                   : in    std_logic ;
> >           C02                   : in    std_logic ;
> >           LatchOutput   : out   std_logic ;
> >           CombOutput    : out   std_logic
> >           );
> > end LatchSynthTest ;
>
> > architecture behavior of LatchSynthTest is
> >   SIGNAL Latch          : std_logic;
> >   SIGNAL Comb           : std_logic;
> >   SIGNAL LatchReg       : std_logic;
> >   SIGNAL CombReg        : std_logic;
>
> > begin
>
> >   CombOutput    <= CombReg;
> >   LatchOutput   <= LatchReg;
>
> >   Process_1 : process(RESET, CLK)
> >   begin
> >     if (RESET = '1') then
> >       LatchReg  <= '0';
> >       CombReg   <= '0';
> >     elsif (rising_edge(CLK)) then
> >       LatchReg  <= Latch;
> >       CombReg   <= Comb;
> >     end if;
> >   end process;
>
> >   CombProc : process(CombReg, C01, C02)
> >   begin
> >     case CombReg is
> >       when '0' =>
> >         if (C01 = '1') then
> >           Comb <= '0';
> >         elsif (C02 = '1') then
> >           Comb <= '1';
> >         else
> >           -- Here an assignment statement is missing, but it doesn't
> >           -- generate latch.  It is treated as a null statement. -
> > Weng
> >         end if;
> >       when others =>
> >         Comb <= '1';
> >     end case;
> >   end process;
>
> >   LatchProc : process(LatchReg, C01, C02)
> >   begin
> >     case LatchReg is
> >       when '0' =>
> >         if C01 = '1' then
> >           Latch <= '0';
> >         elsif C02 = '1' then
> >           Latch <= '1';
> >           -- Here the else is missing, and it does
> >           -- generate latch.  It is treated as a null statement.
> >         end if;
> >       when others =>
> >         Latch <= '1';
> >     end case;
> >   end process;
>
> > end behavior;
>
> Hi,
> Thank you, Andy, Rick and everyone, I am wrong in the second point:
> missing "else" or missing an assignment statement.
>
> But my first point is how to generate a latch for a compiler. Rick,
> can you see the floor plan to show how the latch is generated: for the
> state only or for full states?
>
> Weng

I'm not clear what you mean by "how".  Are you asking about the detail
of how it is implemented in the FPGA?  In the Lattice part they used a
FF as a latch.  A register is between the latch and the output.  They
drive the latch oddly driving both the clock and the async reset
inputs with logic, but then if you look at the code what would you
think is the clock?  I don't see why they did it the way they did, but
it works correctly according to the VHDL.  With only four inputs I
would expect they could have just used a single LUT4 and the latch
with the clock always enabled.

Din == '1'
Latch Enable == CombReg + C02
Async Clear  == ~CombReg * C01

Is this what you are asking?

Rick

Article: 145668
Subject: Re: Unpredictable design
From: "de4" <de4@n_o_s_p_a_m.poczta.onet.pl>
Date: Thu, 18 Feb 2010 02:04:55 -0600
Links: << >>  << T >>  << A >>
I'm bigginner so I was trying to verify if my work actually works in FPGA.
So as clock of whole system I used FSM controled by push button. When I
push the button it gave one clock cycle and because that processor gone to
next state - this is what I meant saying 'step mode'. I have written
software that reads all registers and memory and sending do computer. And
there everything looks ok...

Sorry but I don;t know what is GBUF ? I will find it out...
My clock isn't comnected to anything else then to FPGA ( I have Avnet
Sparatan 3A board)

And about constraints in Map messages I have only : (only infos)

MapLib:562 - No environment variables are currently set.

MapLib:159 - Net Timing constraints on signal Clock are pushed forward
through input buffer.

LIT:244 - All of the single ended outputs in this design are using slew
rate limited output drivers. The delay on speed critical single ended
outputs can be dramatically reduced by designating them as fast outputs.

It doesn't tell me a lot :(

Timing messages 

Timing:2752 - To get complete path coverage, use the unconstrained paths
option. All paths that are not constrained will be reported in the
unconstrained paths section(s) of the report.

Timing:3339 - The clock-to-out numbers in this timing report are based on a
50 Ohm transmission line loading model.  For the details of this model, and
for more information on accounting for different loading conditions, please
see the device datasheet.

And in detailed Post-PAR Static Timing Report is written 
All constraints were met.

What Can I check more ?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145669
Subject: Re: Derived clock violation in Virtex4
From: "maxascent" <maxascent@n_o_s_p_a_m.yahoo.co.uk>
Date: Thu, 18 Feb 2010 03:21:10 -0600
Links: << >>  << T >>  << A >>
You need to post your code so we can see how you have coded the DCM.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145670
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 18 Feb 2010 01:53:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 9:47=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Feb 16, 9:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > Hi
>
> > > > my co-worker has a problem with EDK (used on w7, 32bit)
> > > > OLD project can be built but any new projexcts created stop
> > > > during implementation
>
> > > > xilinx claims that the following tablehttp://www.xilinx.com/ise/oss=
upport/index.htm
>
> > > > is UPTODATE OS support list for Xilinx tools, in that table win7 is
> > > > missing
>
> > > > so what is wrong? is there something wrong with the installation, b=
ut
> > > > hey
> > > > why then old projects pass full flow?
>
> > > > any ideas?
>
> > > > Antti
>
> > > Win7 isn't a supported OS for ISE tools and it is not listed in the
> > > table.
>
> > > The tools may work under some conditions, but they likely will not
> > > under all conditions as your co-worker found out.
>
> > > Ed McGettigan
> > > --
> > > Xilinx Inc.
>
> > Hi
>
> > and thanks for clarification, I could not belive the table to be
> > accurate
> > as of today everybody DOES support w7 already ;) ok maybe not
> > all companies do, but most other software does run nicely on w7
>
> > Antti- Hide quoted text -
>
> > - Show quoted text -
>
> ISE 11.1 was released in April while Windows 7 wasn't released until
> October.
>
> While smaller companies and academia tend to move faster with Windows
> OS upgrades as the tend to use the OS sold with the PC/Laptop larger
> companies in constrast don't rapidly upgrade the OS and prefer to stay
> with older, stable versions.
>
> A quick survey of other EDA tools shows
>
> Synopsys Synplify Pro - Win XP, Win Vista, Linux, Solaris
> Mentor ModelSim PE - Win XP, Win Vista (32)
> Mentor ModelSim SE - Win XP, Win Vista (32), Linux (32)
> Mentor ModelSim DE - Win XP, Win Vista (32/64), Linux (32/64), Solaris
> (32/64)
> Altera Quatrus II 9.1 - Win XP, Win Vista, Red Hat 4/5, Suse 9/10,
> CentOS 4/5
> Lattice ispLever - Win 2K, Win XP, Win Vista (32), Red hat 3/4, Suse
> 10, Solaris 2.8/10
> Actel Libero - Win XP, Win Vista, Red Hat WS 4/5.2
>
> Ed McGettigan
> --
> Xilinx Inc.

EASY ;)

actually to the final surprise EDK 10.x worked well on Win7/32

so it ended up ok, no need to buy old PC's to run 10.x versions of the
tools

Antti




Article: 145671
Subject: Re: Unpredictable design
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 18 Feb 2010 10:42:48 +0000
Links: << >>  << T >>  << A >>
On Wed, 17 Feb 2010 17:55:07 -0600, "de4" <de4@n_o_s_p_a_m.poczta.onet.pl>
wrote:

>Hello !
>
>I have a very big problem. I created a simple procesor and on simulation it
>works fine, on step mode it works fine but when it is running on full speed
>of clock it got crazy... :

>are there any other constraint useful for me ? Can it be constraint fault ?
>Or  it must be design problem ? Or something else ? 16Mhz clock is
>connected to FPGA. 

16MHz is slow enough that problems meeting timing are unlikely.

Is the processor accessing any memory external to the FPGA, or just thu internal
BRAMs? External memory is a likely source of timing problems.

Check for any inputs to the processor that aren't themselves clocked by the same
clock, and eliminate them (by reclocking them from the CPU clock.

- Brian

Article: 145672
Subject: Re: Unpredictable design
From: "de4" <de4@n_o_s_p_a_m.poczta.onet.pl>
Date: Thu, 18 Feb 2010 06:12:48 -0600
Links: << >>  << T >>  << A >>
>On Wed, 17 Feb 2010 17:55:07 -0600, "de4"
<de4@n_o_s_p_a_m.poczta.onet.pl>
>wrote:
>
>>Hello !
>>
>>I have a very big problem. I created a simple procesor and on simulation
it
>>works fine, on step mode it works fine but when it is running on full
speed
>>of clock it got crazy... :
>
>>are there any other constraint useful for me ? Can it be constraint fault
?
>>Or  it must be design problem ? Or something else ? 16Mhz clock is
>>connected to FPGA. 
>
>16MHz is slow enough that problems meeting timing are unlikely.
>
>Is the processor accessing any memory external to the FPGA, or just thu
internal
>BRAMs? External memory is a likely source of timing problems.
>
>Check for any inputs to the processor that aren't themselves clocked by
the same
>clock, and eliminate them (by reclocking them from the CPU clock.
>
>- Brian
>


Thank you for response...

Processor don't accessing external memory only BlockRAM based RAM.
I have one input in my system that is a clock connected to global clock.
this input is (clock signal) connected to processor, ram and I/O ( uses TX
and RX line to communicate with processor from outside). Processor is
connected with Clock, Reset and RAM signals. RAM is connected with Clock,
Processor and to I/O unit (dual port). To I/O unit is connected clock,
Reset and signal from ram and TX,RX lines. 

I writing because it is strage behavior I even could say that it is
randomly...
If something would be wrongly design (I mean some fsm in control unit)
program would be executed badly but always in the same way... In my case
some times is 
PC values are 0, 1 ,2 ,4, 5 some times it is 0, 1 and stops. 
16 Mhz is not too much...

Best regards,
Maciek


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145673
Subject: Re: Unpredictable design
From: Symon <symon_brewer@hotmail.com>
Date: Thu, 18 Feb 2010 12:37:46 +0000
Links: << >>  << T >>  << A >>
On 2/18/2010 12:12 PM, de4 wrote:
>
> I writing because it is strage behavior I even could say that it is
> randomly...
> If something would be wrongly design (I mean some fsm in control unit)
> program would be executed badly but always in the same way... In my case
> some times is
> PC values are 0, 1 ,2 ,4, 5 some times it is 0, 1 and stops.
> 16 Mhz is not too much...
>
> Best regards,
> Maciek
>
Hi Maciek,
Can you use chipscope to look at the signals which control the program 
counter, and the PC's value?
Do you get any warnings from P&R something like "Warning: Signal clock 
connects to non-clock resource"?

Look in all the report files for any warnings to do with your clock signal.

Does your reset get released synchronously to the clock?

HTH, Syms.

Article: 145674
Subject: Re: Unpredictable design
From: "de4" <de4@n_o_s_p_a_m.poczta.onet.pl>
Date: Thu, 18 Feb 2010 07:11:09 -0600
Links: << >>  << T >>  << A >>
>Hi Maciek,
>Can you use chipscope to look at the signals which control the program 
>counter, and the PC's value?
>Do you get any warnings from P&R something like "Warning: Signal clock 
>connects to non-clock resource"?
>
>Look in all the report files for any warnings to do with your clock
signal.
>
>Does your reset get released synchronously to the clock?
>
>HTH, Syms.
>

Chipscope is beyond my possibilities... I program FPGA using Avnet Programm
and I don't have Platform Cable... In PAR I don't have any warnings at
all...
I will search them but I didn't see any warnings.

Sorry but "Does your reset get released synchronously to the clock?"
I don;t understand this - I have some Dff like this :

entity D_FF is
	port(	D, Clock, Reset		: in STD_LOGIC;
				Q, notQ 				: out STD_LOGIC);
end D_FF;

architecture CPU of D_FF is
signal Qout : STD_LOGIC;
begin

		PROCESS(D, Clock, Reset)
		BEGIN
			IF Reset = '1' THEN -- Don’t wait for clock
				Q <= '0';
				notQ <= '1';
			ELSIF (Clock'event) AND (Clock='1') THEN -- Positive Edge
				Q <= D;
				notQ <= not D;
		END IF;
		END PROCESS;

end CPU;


and this reset is connected to button on a board...
So I think rather not...

Thank you for response...	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search