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 71075

Article: 71075
Subject: FSM in illegal state
From: "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se>
Date: Wed, 7 Jul 2004 19:51:32 +0200
Links: << >>  << T >>  << A >>
Hi all! I'd like to once again bring up the subject of state machines
running into illegal states (illegal in the sense that the state vector does
not correspond to any of the states defined in the VHDL code), because
despite having spent half a day googling and reading related threads, I'm
still left with a couple of questions:

1. Most discussions cover how to recover from illegal states, but few cover
how it actually happens. What are the (I presume) electrical reasons to that
a state machine runs into an illegal state in the first place? Is there
anything one can do to reduce the risk? Assume all FSM inputs connected to
I/O pins are synchronized with one FF each, and the whole design is
synchronous. Does anyone know of a good tutorial on this issue? I could add
that in my case, the transition into an illegal state almost always happen
immediately upon startup of the system, if it happens.

2. How can I force Xilinx XST (6.2 SP3) to produce a safe FSM that recovers
from an illegal state? A "when others => state <= IDLE;" clause doesn't seem
to help (which I think is stupid, isn't this problem so well known that they
should make XST recognize it instead of optimizing it away?). I realize that
changing coding style to "Binary" will reduce the number of illegal state
and thus the risk for it to happen, but it's not completely safe, unless the
number of states is a power of two. What's more, binary coding style seems
to increase slice utilization for the whole design by up to 10%.

Thanks in advance!

/Jerker



Article: 71076
Subject: Re: Are IO buffers required?
From: Rob <>
Date: Wed, 7 Jul 2004 12:22:53 -0700
Links: << >>  << T >>  << A >>
Thanks for the info!

Article: 71077
Subject: Re: FSM in illegal state
From: Phil Hays <Spampostmaster@comcast.net>
Date: Wed, 07 Jul 2004 20:42:15 GMT
Links: << >>  << T >>  << A >>
<jerkerNO@SPAMdst.se> wrote:

>1. Most discussions cover how to recover from illegal states, but few cover
>how it actually happens. What are the (I presume) electrical reasons to that
>a state machine runs into an illegal state in the first place? Is there
>anything one can do to reduce the risk? Assume all FSM inputs connected to
>I/O pins are synchronized with one FF each, and the whole design is
>synchronous. Does anyone know of a good tutorial on this issue? I could add
>that in my case, the transition into an illegal state almost always happen
>immediately upon startup of the system, if it happens.

How is the reset signal handled?  If the FFs are asynchronously reset,
then the end of reset can happen at different times to different FFs,
leading to an illegal state.


--
Phil Hays
Phil-hays at posting domain should work for email


Article: 71078
Subject: Re: FSM in illegal state
From: Kai Harrekilde-Petersen <khp@harrekilde.dk>
Date: Wed, 07 Jul 2004 20:49:23 GMT
Links: << >>  << T >>  << A >>
Phil Hays <Spampostmaster@comcast.net> writes:

> <jerkerNO@SPAMdst.se> wrote:
>
>>1. Most discussions cover how to recover from illegal states, but few cover
>>how it actually happens. What are the (I presume) electrical reasons to that
>>a state machine runs into an illegal state in the first place? Is there
>>anything one can do to reduce the risk? Assume all FSM inputs connected to
>>I/O pins are synchronized with one FF each, and the whole design is
>>synchronous. Does anyone know of a good tutorial on this issue? I could add
>>that in my case, the transition into an illegal state almost always happen
>>immediately upon startup of the system, if it happens.
>
> How is the reset signal handled?  If the FFs are asynchronously reset,
> then the end of reset can happen at different times to different FFs,
> leading to an illegal state.

Internal noise coupling in the chip (crosstalk), power drops, alpha
particles, not properly double-sync'ing an async signal before using
it in two different places (BTDT, seen it in a real chip), ... the
list goes on!


--Kai

Article: 71079
Subject: Re: Puzzled Simulating with 'X' input Quartus II v4.0 sp1
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 07 Jul 2004 16:50:52 -0400
Links: << >>  << T >>  << A >>
Let me make a few comments that may or may not be relavent. 

Rajeev wrote:
> 
> I was simulating with some inputs set to 'X'=unknown on the inputs and
> observing
> defined outputs where I thought the output should be indeterminate.
> Playing around some, I've reduced things to the following example.
> The outputs are as determined by QuartusII v4.0SP1.  No optimizations
> turned on.  The logic is not inside a process, but that doesn't make a
> difference.  Quartus II v3.0 sp2 behaves exactly the same.
> 
>         A,B,Sel : in std_logic;
>         Y,Z : out std_logic;
> 
> -- Straight Combinatorial Logic:
> 
>         Y <= A when Sel='1' else B;
>         Z <= (A and Sel) or (B and (not Sel));
> 
> Simulation Results:
> 
> Inputs  -> Outputs
> Sel A B -> Y Z
>  0  0 0    0 0
>  0  0 1    1 1
>  0  1 0    0 0
>  0  1 1    1 1
>  1  0 0    0 0
>  1  0 1    0 0
>  1  1 0    1 1
>  1  1 1    1 1       so far so good !
> 
>  X  0 0    0 0
>  X  0 1    0 U       :-(  why is Y==A when Sel='X' ??
>  X  1 0    1 U
>  X  1 1    1 U       ! simulator is able to figure out Z=0 when A=B=0
> but
>                        isn't able to figure out the case A=B=1
0 AND anything is always 0.  But 1 AND X is not 1.  So the OR of two
unknowns is not a known.  The value of X is not the same as "don't care"
or not sure if it is a 0 or a 1.  It can also be hi-z and will result in
an unknown state on the output of the AND gate.  

>  X  X 0    X U
>  X  X 1    X U       ok no surprises here...
> 
>  X  0 X    0 U
>  X  1 X    1 U       well its consistent...
> 
>  X  X X    0 U       @#$% Zero ???
> 
> So here's my questions...
> 
> (1) Is it a bad idea to use 'X' in a simulation ?

It would seem X is not a useful state in this simulator.  In a proper
VHDL simulator X has a defined behavior and is the default for FFs that
are not init'd or inputs that are not assigned.  

> (2) Is there something I'm missing that explains this behavior ?

Try using a proper VHDL simulator.  I use the Xilinx version of
Modelsim.  

Is this simulation *after* synthesis?  If so I have no idea why your two
results would be different.  I read your later message and you show the
two outputs use the same equation, but your simulation gives different
results.  It *must* be simulating before synthesis. 

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71080
Subject: Re: FSM in illegal state
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 07 Jul 2004 17:01:00 -0400
Links: << >>  << T >>  << A >>
"Jerker Hammarberg (DST)" wrote:
> 
> Hi all! I'd like to once again bring up the subject of state machines
> running into illegal states (illegal in the sense that the state vector does
> not correspond to any of the states defined in the VHDL code), because
> despite having spent half a day googling and reading related threads, I'm
> still left with a couple of questions:
> 
> 1. Most discussions cover how to recover from illegal states, but few cover
> how it actually happens. What are the (I presume) electrical reasons to that
> a state machine runs into an illegal state in the first place? Is there
> anything one can do to reduce the risk? Assume all FSM inputs connected to
> I/O pins are synchronized with one FF each, and the whole design is
> synchronous. Does anyone know of a good tutorial on this issue? I could add
> that in my case, the transition into an illegal state almost always happen
> immediately upon startup of the system, if it happens.

I have never had a design with a state machine which got into illegal
states.  The only two reasons that I can think of for this happening is 

1) electrical noise which would also cause upset of *other* FFs in the
system causing other symptoms and 

2) timing issues with the FSM.  This can be either from async inputs
(metastability) or from failing to meet setup time on a reg input.  If
you have done your static timing analysis correctly, then it must be a
metastability issue.  The fact that it occurs happens on startup says to
me it is a timing issue.  If you can chase the problem away by slowing
your clock, then it is a static timing issue.  If it persists, then you
most likely have a metastable issue.  

Figure out what is wrong and deal with the cause of the problem.  


> 2. How can I force Xilinx XST (6.2 SP3) to produce a safe FSM that recovers
> from an illegal state? A "when others => state <= IDLE;" clause doesn't seem
> to help (which I think is stupid, isn't this problem so well known that they
> should make XST recognize it instead of optimizing it away?). I realize that
> changing coding style to "Binary" will reduce the number of illegal state
> and thus the risk for it to happen, but it's not completely safe, unless the
> number of states is a power of two. What's more, binary coding style seems
> to increase slice utilization for the whole design by up to 10%.

I am not a fan of dealing with this type of problem by illegal state
recognition.  If it gets into an illegal state it has already caused a
malfunction of the rest of the circuit most likely.  Getting back to a
known state is only useful in that it can resume normal operation.  But
it is not a "fix".  

I am unclear as to why the others clause would not result in recovery
from an illegal state.  That could very easily add a lot of extra logic
and even slow the max speed of the FSM.  But it should not be optimized
away since it is a specified part of the machine.  I assume the illegal
state detection works in simulation, no?  If so, it should work in
operation.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 71081
Subject: Re: FSM in illegal state
From: "Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se>
Date: Wed, 07 Jul 2004 21:04:13 GMT
Links: << >>  << T >>  << A >>
 > How is the reset signal handled?  If the FFs are asynchronously reset,
 > then the end of reset can happen at different times to different FFs,
 > leading to an illegal state.

Hi Phil! I use no reset signal at all; instead I specify initial values 
for all signals by the declarations, which is supposed to work fine with 
XST. But your point is still interesting in case I would need to 
introduce an asynchronous reset some day. Does that mean one should 
avoid them if illegal states are a concern?

/Jerker

Article: 71082
Subject: Re: FSM in illegal state
From: "Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se>
Date: Wed, 07 Jul 2004 21:25:59 GMT
Links: << >>  << T >>  << A >>
 > Internal noise coupling in the chip (crosstalk), power drops, alpha
 > particles, not properly double-sync'ing an async signal before using
 > it in two different places (BTDT, seen it in a real chip), ... the
 > list goes on!

OK, probably I would need the complete list with full descriptions! Do 
you know of any books or tutorials on this subject? I'm not really an 
electrical engineer but I have to deal with this, so any pointers would 
be appreciated.

/Jerker

Article: 71083
Subject: RC Servo PWM Digital Capture in a Xilinx xc9500 CPLD?
From: "Bruno Cardeira" <bmscc@netcabo.pt>
Date: Wed, 7 Jul 2004 22:33:47 +0100
Links: << >>  << T >>  << A >>
Hello everyone!
Can anyone tell me or suggest a way to capture a RC servo PWM signal with a
Xilinx CPLD in ABEL?. When the pulse duration is 1ms the digital value is
logic 0, when is 2 ms the digital output is a logic 1.

Best Regards
Thanks in advance



Article: 71084
Subject: Re: FSM in illegal state
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 07 Jul 2004 14:46:06 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> I am unclear as to why the others clause would not result in recovery
> from an illegal state.  That could very easily add a lot of extra logic
> and even slow the max speed of the FSM.  But it should not be optimized
> away since it is a specified part of the machine.  I assume the illegal
> state detection works in simulation, no?  If so, it should work in
> operation.  
> 

The synthesis tools are "smart" enough to recognize that there is no 
logical way to reach the "others" state. Therefore it is optimized out. 
Many synthesis tools do this.

-- 
My real email is akamail.com@dclark (or something like that).

Article: 71085
Subject: Re: FSM in illegal state
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 7 Jul 2004 14:54:07 -0700
Links: << >>  << T >>  << A >>
Hi Jerker,
Well, you _do_ have a reset. It's just a little hidden. At some point the
storage elements stop being held at the initial values. This is the
equivalent of your reset being released. If the elements are being clocked
asynchronously to the release signal at this time, you could be in trouble.
Cheers, Syms.
"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote in message
news:hzZGc.4458$dx3.36217@newsb.telia.net...
> > How is the reset signal handled?  If the FFs are asynchronously reset,
>  > then the end of reset can happen at different times to different FFs,
>  > leading to an illegal state.
>
> Hi Phil! I use no reset signal at all; instead I specify initial values
> for all signals by the declarations, which is supposed to work fine with
> XST. But your point is still interesting in case I would need to
> introduce an asynchronous reset some day. Does that mean one should
> avoid them if illegal states are a concern?
>
> /Jerker



Article: 71086
Subject: Chipscope inserter changes net names.
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 7 Jul 2004 15:03:14 -0700
Links: << >>  << T >>  << A >>
Hi All,
When I probe nets with Chipscope Inserter, the net names change. For
example, 'clock_enable' changes to 'ila0_trig0<68>'. This screws up my
timing constraints declared in my .UCF file. E.g. NET "clock_enable" TNM=FFS
"ff_grp1"; doesn't see the net anymore.
Anyone solved this?
Cheers, Syms.
p.s. I'm using version 6.2.02 of the Chipscope software. I'm downloading
6.2.03 to see if it makes any difference.



Article: 71087
Subject: Re: FSM in illegal state
From: Phil Hays <Spampostmaster@comcast.net>
Date: Wed, 07 Jul 2004 22:20:46 GMT
Links: << >>  << T >>  << A >>
"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote:

> > How is the reset signal handled?  If the FFs are asynchronously reset,
> > then the end of reset can happen at different times to different FFs,
> > leading to an illegal state.
>
>Hi Phil! I use no reset signal at all; instead I specify initial values 
>for all signals by the declarations, which is supposed to work fine with 
>XST.

You do have an asynchronous reset, you just didn't know that you did.
When a Xilinx FPGA finishes the program download, it has all initial
values held until an internal signal is released.  This release is
asynchronous to your clock.  To avoid problems with this add a counter
that is reset to all zeros.  Until that counter counts to 15, keep the
state machine in the initial state.

(Note: Startup is a messy subject.  This is a simplified version.)

There is another common issue with DCMs or DLLs that you might also be
having a problem with.  Are you using a DCM or a DLL?


> But your point is still interesting in case I would need to 
> introduce an asynchronous reset some day. Does that mean one should 
> avoid them if illegal states are a concern?

Yes.  Suppose the initial state is "100" and the desired next state is
"010".  This would be a three state one-hot machine.
If the first bit is held until just after the first edge of the clock
and the second bit is held until just before the first edge of the
clock, then the next state will be illegal, "110".
If the first bit is held until just before the first edge of clock and
the second bit is held until just after the first edge of the clock,
then the next state will be illegal, "000".  

Does that make it clear?


--
Phil Hays
Phil-hays at posting domain should work for email

Article: 71088
Subject: Re: FSM in illegal state
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jul 2004 10:30:16 +1200
Links: << >>  << T >>  << A >>
Duane Clark wrote:
> rickman wrote:
> 
>>
>> I am unclear as to why the others clause would not result in recovery
>> from an illegal state.  That could very easily add a lot of extra logic
>> and even slow the max speed of the FSM.  But it should not be optimized
>> away since it is a specified part of the machine.  I assume the illegal
>> state detection works in simulation, no?  If so, it should work in
>> operation. 
> 
> 
> The synthesis tools are "smart" enough to recognize that there is no 
> logical way to reach the "others" state. Therefore it is optimized out. 
> Many synthesis tools do this.

Wow, isn't software clever... and it probably does not tell you it did
this either... but never mind, the other state have no logical pathways,
so everything will be OK.

Back to the real engineering world:
  Do LOOK at the resultant output of your tools, and HOW it actually 
built the FSM. It can use .D or .T registers, with .D the most common.

Implicit in most .D coding is that state 00000 is the goto state from
any illegal ones : Thus for many reasons (hopefully very rare) you MIGHT 
goto an illegal state, but the one after that will be 00000.

This should be a cornerstone state of your legal state list, either
the POR state, or the safe-idle state.

Choosing gray code related states can reduce the pathways to illegal 
states, but in complex FSM's, this is not always possible.

  You should not rely on this recovery pathway in regular system 
operation, it should be a safety-net.
  During tests, you could INC a counter when passing through 00000,

.T register state engines can be smaller, but they also can literally
stick at an illegal state.

-jg


Article: 71089
Subject: Re: How to add clock delay in CPLD?
From: raonpc@gmail.com (pablo aimar)
Date: 7 Jul 2004 15:30:51 -0700
Links: << >>  << T >>  << A >>
Hi,
  you can try following method:
  take the clock input from clock oscillator to pin A of cpld, bring
it out through pin B and now give it to global clock(global lines)
pin, by this method you can have some delay (I/O buffer delay), but
you need to scarifice two pins of cpld.
----
  Insert two inverters in the clock path, assign output of first inv
to a io pin,(not optimized out) use the o/p of second inverter. here
the clock is no longer assigned to global lines. for simple logic this
may work.

Thanks
rao

> news:cbnvnr$2od0$1@mail.cn99.com...
> > Hi,friends,
> > To meet the Tsu requirement in my design, I think I should try to add some
> > clock delay to the input register, how can I do that in CPLD? (not FPGA,
> > without PLL,DLL)
> >
> > Thanks!
> >
> >

Article: 71090
Subject: Re: FSM in illegal state
From: "Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se>
Date: Wed, 07 Jul 2004 22:39:13 GMT
Links: << >>  << T >>  << A >>
Hi Rick, thanks for your reply!

 > 1) electrical noise which would also cause upset of *other* FFs in the
 > system causing other symptoms and

I don't think I can rule that out in this specific application. But 
where, that is on what physical signal, do you mean the electrical noise 
would occur, and how could it affect the FPGA's internal state?

 > 2) timing issues with the FSM.  This can be either from async inputs
 > (metastability) or from failing to meet setup time on a reg input.  If
 > you have done your static timing analysis correctly, then it must be a
 > metastability issue.  The fact that it occurs happens on startup says
 > to me it is a timing issue.  If you can chase the problem away by
 > slowing your clock, then it is a static timing issue.  If it persists,
 > then you most likely have a metastable issue.

I doubt that it's about static timing in my case since my clock is 20 
MHz, and XST's post-layout static timing analysis doesn't complain. 
Metastability could be an issue, but it's strange that it happens so 
often. On one particular design, it happens about once every ten times i 
startup the system. All inputs are synchronized with one FF each, but 
I'll try adding a second one to see if it helps.

 > I am not a fan of dealing with this type of problem by illegal state
 > recognition.  If it gets into an illegal state it has already caused a
 > malfunction of the rest of the circuit most likely.  Getting back to a
 > known state is only useful in that it can resume normal operation.
 > But it is not a "fix".

I agree totally, that's why I pointed out that most previous threads 
dealt with recovery from but not with the cause of illegal states.

 > I am unclear as to why the others clause would not result in recovery
 > from an illegal state.  That could very easily add a lot of extra
 > logic and even slow the max speed of the FSM.  But it should not be
 > optimized away since it is a specified part of the machine.  I assume
 > the illegal state detection works in simulation, no?  If so, it should
 > work in operation.

Well, the FSM optimizer detects unreachable and removes related logic, 
and I guess that's what's happening here too. Indeed, if I simulate the 
RTL code as it is, I can't put the design in an illegal state - there is 
simply no signal that I can force to an illegal value. But if I add a 
dummy state in the enumerated state type definition without adding a 
"when" clause for it, then I can enforce the dummy state and the "when 
others" clause is applied. If I simulate the post-layout code, I would 
be very surprised if the illegal state detection worked since it was 
taken away during synthesis, but I haven't tried it.

/Jerker

Article: 71091
Subject: false paths, Synplify
From: hadley@yxi.com (Tedd Hadley)
Date: 7 Jul 2004 15:52:36 -0700
Links: << >>  << T >>  << A >>
Hello,
                                                                                
How does one specify ANY arbitrary path in the design as a false
path, using define_false_path in Synplify?
                                                                                
define_false_path lets you specify "-to" "-from" in terms of ports
or registers, but not combinational instance pins.  "-through" only
lets you specify an OR-list of instance pins or nets.
                                                                                
These restrictions seem to leave a large number of possible false
paths (combinational-pin to combinational-pin, for example)
unspecifiable to Synplify.
                                                                                
Other tools don't seem to have this problem, noteably XST and
Quartus II which allow any number of "through" nets on a path to
be identified, thus allowing any and all possible paths in a design
to be characterized.
                                                                                
Am I missing something?  Surely the free tools don't outdo Synplify
on this one?
                                                                                
Best regards,

Article: 71092
Subject: Re: Urgent : Xilinx PACE question
From: y_p_w@hotmail.com (y_p_w)
Date: 7 Jul 2004 16:14:18 -0700
Links: << >>  << T >>  << A >>
benkhalh@hotmail.com (Oleg) wrote in message news:<5f8ab9cc.0407070601.1b243a93@posting.google.com>...
> Hi,
> Help me please to fixe the folowing probleme:
> 
> When i open PACE window (ISE 6.1)to create area constrainte (region),
> in the design broser window (top most left window in PACE) there are 3
> folders : I/O pins, Global Logic and Logic, this last one should
> containe the logic of my design(by blocks) but its empty, Why? how to
> fixe this? is it because the tool dont keep the heararchy of the
> design???
> Note: this happen when i use VHDL entrance to ISE tool,but does not if
> i use Synplify to synthesis my design and then i entre EDIF file to
> ISE(her i can see and plce my blocks).
> 
> This is very important for me since i need to place manualy some
> blocks of my design to get a better speed.
> 
> Thanks for any help.

I'm not an expert on this (I've barely begun to use the tool), but
wouldn't you normally do this in the Floorplanner?  The Floorplanner
comes up blank for me, but then I open <design_file>.ncd, and the
design layout is displayed.  I think this is where the manual
placement is supposed to occur.

Article: 71093
Subject: Re: FSM in illegal state
From: "Doug Miller" <nospam_doug_miller@worldnet.att.net>
Date: Wed, 07 Jul 2004 23:22:05 GMT
Links: << >>  << T >>  << A >>
If you are using ISE 6.1, also check the "Clock Information:" section of
your SYR (Synthesis) file.  In some cases, it (erroneously) generates
additional clocks from combinatorial logic.  From some of my own experience,
I've noticed this sometimes this can be cured by making sure that all
possible states are defined in your combinatorial logic.

Example - Extra clocks will be generated if the two commented lines below
are left commented, but will not be generated if they are uncommented.

  if (currentState = IDLE) then
    if (someTrigger = '1') then
      nextState  <= SOME_OTHER_STATE;
     --  else
     --   nextState  <= IDLE;
     end if;
   end if;


"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote in message
news:40ec3825_4@read01.nntp.se.dataphone.net...
> Hi all! I'd like to once again bring up the subject of state machines
> running into illegal states (illegal in the sense that the state vector
does
> not correspond to any of the states defined in the VHDL code), because
> despite having spent half a day googling and reading related threads, I'm
> still left with a couple of questions:
>
> 1. Most discussions cover how to recover from illegal states, but few
cover
> how it actually happens. What are the (I presume) electrical reasons to
that
> a state machine runs into an illegal state in the first place? Is there
> anything one can do to reduce the risk? Assume all FSM inputs connected to
> I/O pins are synchronized with one FF each, and the whole design is
> synchronous. Does anyone know of a good tutorial on this issue? I could
add
> that in my case, the transition into an illegal state almost always happen
> immediately upon startup of the system, if it happens.
>
> 2. How can I force Xilinx XST (6.2 SP3) to produce a safe FSM that
recovers
> from an illegal state? A "when others => state <= IDLE;" clause doesn't
seem
> to help (which I think is stupid, isn't this problem so well known that
they
> should make XST recognize it instead of optimizing it away?). I realize
that
> changing coding style to "Binary" will reduce the number of illegal state
> and thus the risk for it to happen, but it's not completely safe, unless
the
> number of states is a power of two. What's more, binary coding style seems
> to increase slice utilization for the whole design by up to 10%.
>
> Thanks in advance!
>
> /Jerker
>
>



Article: 71094
Subject: Re: FSM in illegal state
From: "Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se>
Date: Wed, 07 Jul 2004 23:47:25 GMT
Links: << >>  << T >>  << A >>
Hi Jim!

 >   Do LOOK at the resultant output of your tools, and HOW it actually
 > built the FSM. It can use .D or .T registers, with .D the most common.

Well, the output netlist isn't exactly human-readable, although I guess 
I could write a simple FSM, synthesize it and study it. But actually I 
already know how XST has encoded my machine. My options are essentially 
One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably 
on D flip-flops. I get One-Hot encoded machines unless i ask for 
something else.

However, correct me if I'm wrong, the state encoding itself doesn't 
change anything in the machine's ability to recover from illegal states 
- it takes some logic that detects these illegal states and forces the 
state vector back to normal, and that logic obviously isn't there. Many 
synthesis tools provide an extra option "safe FSMs" which will add such 
logic, but XST doesn't. So my question is XST-specific - how do I add 
illegal state recovery logic with XST?

/Jerker

Article: 71095
Subject: Re: RC Servo PWM Digital Capture in a Xilinx xc9500 CPLD?
From: "John_H" <johnhandwork@mail.com>
Date: Wed, 07 Jul 2004 23:51:32 GMT
Links: << >>  << T >>  << A >>
Form the signal into a digital value.
Use an external crystal or R/C oscillator to count the width of the pulse.
A count of n in 1ms is a 0, a count of 2n is a 1.  If all you need is a
logical result and not a variable value, this threshold is pretty easy to
program.

"Bruno Cardeira" <bmscc@netcabo.pt> wrote in message
news:40ec6b3b$0$508$a729d347@news.telepac.pt...
> Hello everyone!
> Can anyone tell me or suggest a way to capture a RC servo PWM signal with
a
> Xilinx CPLD in ABEL?. When the pulse duration is 1ms the digital value is
> logic 0, when is 2 ms the digital output is a logic 1.
>
> Best Regards
> Thanks in advance



Article: 71096
Subject: Re: FSM in illegal state
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jul 2004 11:59:03 +1200
Links: << >>  << T >>  << A >>
Jerker Hammarberg (DST) wrote:

> Hi Jim!
> 
>  >   Do LOOK at the resultant output of your tools, and HOW it actually
>  > built the FSM. It can use .D or .T registers, with .D the most common.
> 
> Well, the output netlist isn't exactly human-readable, although I guess 
> I could write a simple FSM, synthesize it and study it. But actually I 
> already know how XST has encoded my machine. My options are essentially 
> One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably 
> on D flip-flops. I get One-Hot encoded machines unless i ask for 
> something else.
> 
> However, correct me if I'm wrong, the state encoding itself doesn't 
> change anything in the machine's ability to recover from illegal states 
> - it takes some logic that detects these illegal states and forces the 
> state vector back to normal, and that logic obviously isn't there. 

No, not quite.
If you consider .D registered FSMs, then if you have enumerated 00000
as a legal state, that naturally maps what you call recovery logic.
If the tools choose one-hot, and take 00000 as illegal/not possible,
(since it is not a one-hot state) then you loose the natural recovery path.
ie the state encoding itself CAN affect the recovery, as if you
avoid the .D recovery path of all low, your FSM will not perform
the same as one that includes all lows as a specified state.

Try Gray or Johnson, and make sure the 00000 is an enumerated/specified
state, and see what happens ?

-jg


Article: 71097
Subject: Re: RC Servo PWM Digital Capture in a Xilinx xc9500 CPLD?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jul 2004 12:58:33 +1200
Links: << >>  << T >>  << A >>
Bruno Cardeira wrote:
> Hello everyone!
> Can anyone tell me or suggest a way to capture a RC servo PWM signal with a
> Xilinx CPLD in ABEL?. When the pulse duration is 1ms the digital value is
> logic 0, when is 2 ms the digital output is a logic 1.

In building block terms, this is a monostable and a D register.
In a CPLD a monostable is built as an edge-reset-counter-compare.
You could consider hysteresis on the time threshold, as the 1-2ms
windows are usually linear.

If it is multichannel RC, there is a frame signal to consider too.

-jg


Article: 71098
Subject: Re: FSM in illegal state
From: "Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se>
Date: Thu, 08 Jul 2004 01:32:09 GMT
Links: << >>  << T >>  << A >>
 > If you consider .D registered FSMs, then if you have enumerated 00000
 > as a legal state, that naturally maps what you call recovery logic.
 > If the tools choose one-hot, and take 00000 as illegal/not possible,
 > (since it is not a one-hot state) then you loose the natural recovery
 > path. ie the state encoding itself CAN affect the recovery, as if you
 > avoid the .D recovery path of all low, your FSM will not perform
 > the same as one that includes all lows as a specified state.

But that only solves the problem for one specific illegal state... or do 
I misunderstand something? Say I have a three-state machine, where XST 
by default would encode the states "100", "010", and "001". So there are 
now five illegal states. If I follow your suggestion, I could encode the 
states like "00", "10", and "01". But there is still one illegal state, 
namely "11". I agree this is a lot better and it significantly reduces 
the risk of falling into the illegal state, but the risk is still there. 
And if the machine somehow falls into this illegal state, I want there 
to be some recovery logic to take the machine out of it.

Simply put - no matter what encoding I use, there will always be illegal 
states (except when the number of states is an exact power of two, so 
that I can assign each state vector configuration to a legal state). And 
if there are illegal states, the machine can fall into them. And if the 
machine can fall into an illegal state, I want it to get out of there 
automatically.

 > Try Gray or Johnson, and make sure the 00000 is an
 > enumerated/specified state, and see what happens ?

I have tried binary encoding, and indeed wouldn't hang anymore. But 
considering what I wrote above, I don't feel confident that it really 
solved the problem - I believe I just reduced the probability for it to 
happen. But I would happily be proved wrong!

/Jerker

Article: 71099
Subject: Re: FSM in illegal state
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 08 Jul 2004 13:56:35 +1200
Links: << >>  << T >>  << A >>
Jerker Hammarberg (DST) wrote:
>  > If you consider .D registered FSMs, then if you have enumerated 00000
>  > as a legal state, that naturally maps what you call recovery logic.
>  > If the tools choose one-hot, and take 00000 as illegal/not possible,
>  > (since it is not a one-hot state) then you loose the natural recovery
>  > path. ie the state encoding itself CAN affect the recovery, as if you
>  > avoid the .D recovery path of all low, your FSM will not perform
>  > the same as one that includes all lows as a specified state.
> 
> But that only solves the problem for one specific illegal state... or do 
> I misunderstand something? Say I have a three-state machine, where XST 
> by default would encode the states "100", "010", and "001". So there are 
> now five illegal states. If I follow your suggestion, I could encode the 
> states like "00", "10", and "01". But there is still one illegal state, 
> namely "11". I agree this is a lot better and it significantly reduces 
> the risk of falling into the illegal state, but the risk is still there. 
> And if the machine somehow falls into this illegal state, I want there 
> to be some recovery logic to take the machine out of it.
> 
> Simply put - no matter what encoding I use, there will always be illegal 
> states (except when the number of states is an exact power of two, so 
> that I can assign each state vector configuration to a legal state). And 
> if there are illegal states, the machine can fall into them. And if the 
> machine can fall into an illegal state, I want it to get out of there 
> automatically.

With .D registers, and you can consider FSMs as low level coded as:
Q0.D = SeriesOfTerms0;
Q1.D = SeriesOfTerms1;

Each valid state will have a number of hold-until-next-move-true terms,
but states not covered will have NO .D terms, and so their NEXT state is
Q0.D = 0;
Q1.D = 0;
or to the 00 state.

If you code
  IF State=11 THEN immediate_next = 00, then no more logic is generated,
as that is implicit.

So it will get out of there automatically. With one-hot, the actual 
problem is that where it GOES NEXT is also not on the state map, whereas 
with other schemes, esp if you implicitly include 0000, then there is a 
recovery path.

>  > Try Gray or Johnson, and make sure the 00000 is an
>  > enumerated/specified state, and see what happens ?
> 
> I have tried binary encoding, and indeed wouldn't hang anymore. But 
> considering what I wrote above, I don't feel confident that it really 
> solved the problem - I believe I just reduced the probability for it to 
> happen. But I would happily be proved wrong!

See above.




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