Xilinx XST and a State Machine - A Mystery

Computer architecture

    Next

  • 1. Reconfiguration standards
    My university task involves use of reconfigurable logic. I need to automate re-configuration and organize data transfers between PC and FPGA. The netlist to be downloaded into FPGA is described in EDIF file (I can have it as VHDL or Verilog as well). I was recommended to use WebPack and TCL scripting for automatic compilation. However, I want not to restrict my system with the compiler/Xilinx FPGAs. I want my system to be as universal as possible. I want to let user to choose any off-the-shelf FPGA depending on its requirements and financial opportunities. This also means that I want to use existing HW(pci, isa, rs232, etc.) and SW (driver) interfaces. Are there any existing re-configurable industry standards (cards, HW/SW interfaces) I can relay on? An alternative would be to create a level of abstraction from the board.
  • 2. Paging Peter Alfke (3S1000 pricing)
    You mentioned in a recent thread that the 3S1000 would sell for $20 in CY2004 in the slowest speed grade and large quantities. I was recently quoted $85.65 for XC3S1000-4FG676C in 5000s for CY2004. Is there really such a huge difference between 5000 piece prices and "large quantities"? I ended up going with an off-the-shelf solution as being more cost-effective, but a $35 ish price might have made for a different decision.
  • 3. What are Pull ups?
    Hi! I am using SPARTAN 2 XC2S150 for my design. I have a question regarding pull up resistors. I am using ISE5.1. 1)What is meant by optional pull ups? There are options in the Constraints Editor to insert pull ups at the I/Os. Are these PERMANENT pull ups or just during configuration? If I select these pull ups, then i also need to set M2M1M0=100 ? 2)Alternatively if i DO NOT select those pull ups in the Constraints editor, but i still set M2M1M0=100 then what will happen? Pull ups will be used for configuration only? 3) Do i need to connect all my VCCO pins to 3.3V and VCCINT to 2.5V? All GND pins on the pacakge be grounded? 4)If I use one clock signal in my design, then it can be input on only one IGCKO(input global clock buffer) or i need to connect all IGCK's to this clk signal? Regards Rider
  • 4. Downloading into XCV600 FPGA using PCI
    Hi Guys, I have written program in a way that I have logic which is being already download in to FPGA( PCI ). In my C code I am using API function to write to FPGA and then on the same bus but using different Address I am reading the values out of FPGA. What I have in my C code that I have used Sleep()command make pause then to execite the next statement which is read fucntion. But If I change time in sleep command than I am getting different values. It means that inside the FPGA in evertying clock cycle the value the signal which I am reading is changing all the time. Also in my VHDL code I haven't got anything which makes the values to change as time passes. And also according to the simulation I have a stable output as well. Could any body tell me how to do this properly to get stable output or if some one has done this before then please give me some hint to sort out this prob. Cheers Isaac
  • 5. WebPack - mixed design flow
    My system has netlist in EDIF while some of technology elements used in the netlist are described in a separate VHDL file at logic level. WebPack supports only pure EDIF, schematic, Verilog or VHDL design flows. Is ther a way to compile a mixed design? That is, I first elaborate VHDL and then load EDIF netlist which uses VHDL components. May be ISE Foundation supports this?

Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 00:52:16 GMT

recently fixed a problem with one of my state machines, and I think
that the cause could be a bug in Xilinx XST. Below is the code that
produced the failure. The state-machine worked most of the time,
though occasionally the 'phaseRamWE' signal would be stuck low, even
though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
incrementing. I fixed it by explicitly declaring the desired value of
'phaseRamWE' in every state. Notice that all states are defined so it
should recover from any conditions introduced by asynchronous inputs.

Have any of you seen similar behavior? Appears to be an XST bug to me.



parameter [3:0]
S1 = 4'b0000,
S2 = 4'b0001,
S3 = 4'b0010,
S4 = 4'b0011,
S5 = 4'b0100,
S6 = 4'b0101,
S7 = 4'b0110,
S8 = 4'b0111,
S9 = 4'b1000,
S10 = 4'b1001,
S11 = 4'b1010,
S12 = 4'b1011,
S13 = 4'b1100,
S14 = 4'b1101,
S15 = 4'b1110,
S16 = 4'b1111;

always @(posedge rst or posedge clk)
begin
if (rst) // 'rst' is asserted
and deasserted synchronously to 'clk'
begin
rfd <= 1'b0;
phaseRamWE <= 1'b0;
phaseRamWriteAdr <= 0;
phaseRamReadAdr <= 0;
phaseAccum <= 0;
state <= S1;
end
else
begin
case (state)
S1:
begin
if (pipeFill == 1'b1) // 'pipeFill' is
asynchronous to 'clk'
begin
phaseRamWE <= 1'b1;
state <= S2;
end
end

S2:
begin
phaseRamReadAdr <= phaseRamReadAdr + 1;
state <= S3;
end


S3:
begin
phaseRamReadAdr <= phaseRamReadAdr + 1;
state <= S4;
end

S4:
begin
phaseRamWriteAdr <= phaseRamWriteAdr + 1;
phaseRamReadAdr <= phaseRamReadAdr + 1;
state <= S5;
end

S5:
begin
phaseRamWriteAdr <= phaseRamWriteAdr + 1;
phaseRamReadAdr <= phaseRamReadAdr + 1;
state <= S6;
end

S6:
begin
rfd <= 1'b1;
phaseRamReadAdr <= phaseRamReadAdr + 1;
phaseRamWriteAdr <= phaseRamWriteAdr + 1;
if (start == 1'b0) // 'start' is
synchronous
begin
state <= S7;
end
else
begin
state <= S8;
end
end


S7:
begin
if (start == 1'b0) // 'start' is
synchronous
begin
state <= S7;
end
else
begin
state <= S8;
phaseRamReadAdr <= phaseRamReadAdr + 1;
phaseRamWriteAdr <= phaseRamWriteAdr + 1;
end
end


S8:
begin
if (start == 1'b0) // 'start' is
synchronous
begin
state <= S9;
phaseRamWE <= 1'b0;
phaseAccum <= 0;
rfd <= 1'b0;
phaseRamReadAdr <= 0;
phaseRamWriteAdr <= 0;
end
else
begin
state <= S8;

Re: Xilinx XST and a State Machine - A Mystery

Postby Frank Buss » Wed, 22 Sep 2010 01:00:05 GMT




I have seen similar behaviour with Altera Quartus. It was the same problem:
asynchronous inputs changed the state machine and sometimes it hangs. I
think it is possible that the state machine is internally implemented with
some more bits and it is possible that it hangs, if there are some timing
violations or meta stability conditions, because then there is an invalid
state encoded and everything can happen with optimized gates. The fix was
easy: Creating an input latch (or even two, if you are paranoid) for each
asynchronous signal to make it synchronous.

-- 
Frank Buss,  http://www.**--****.com/ 
piano and more:  http://www.**--****.com/ 

Re: Xilinx XST and a State Machine - A Mystery

Postby John McCaskill » Wed, 22 Sep 2010 01:05:46 GMT

On Sep 20, 10:52m, Darol Klawetter < XXXX@XXXXX.COM >



<snip>

I only skimmed the code, but this bit jumped out at me:

            if (pipeFill == 1'b1)                     // 'pipeFill' is
asynchronous to 'clk'

If pipeFill is really asynchronous to the clock that is running your
state machine,  using it without synchronizing it first is going to
cause you problems.  Probably not because of metastability, but
because of coherency problems. If pipeFill is changing near the clock
edge, some FFs will see the new value, and some the old.  This can
cause weird and flaky behaviour.

Regards,

John McCaskill
www.FasterTechnology.com

Re: Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 01:09:53 GMT





I thought the same thing, especially because XST often uses one-hot
encoding internally, and that introduces more state bits. Even though
I exhaustively defined all states, this may not be the case in the
post-synthesis result.

Re: Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 01:12:19 GMT



> asynchr>no>s to 'clk'
>
> If pipeFill is really asynchronous to the clock that i> running your
> state machine, sing it without synchronizing it fir>t is going to
> cause you problems. robably not because of meta>tability, but
> because of coherency problems. If pipeFill is changing >ear the clock
> edge, some FFs will see the new value, and some the >ld. his can
> cause weird and fl>ky>behaviour.
>>
>> Regards,
>
> John McCaskillwww.FasterTechnology.com

Agreed, but the state machine should recover, right? All states are
defined.

Re: Xilinx XST and a State Machine - A Mystery

Postby Muzaffer Kal » Wed, 22 Sep 2010 01:18:26 GMT

On Mon, 20 Sep 2010 08:52:16 -0700 (PDT), Darol Klawetter




Try adding a (* safe_implementation = "yes" *)  to your state register
and see if that gets rid of the problem.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

 http://www.**--****.com/ 

Re: Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 01:26:50 GMT



> asynchr>no>s to 'clk'
>
> If pipeFill is really asynchronous to the clock that i> running your
> state machine, sing it without synchronizing it fir>t is going to
> cause you problems. robably not because of meta>tability, but
> because of coherency problems. If pipeFill is changing >ear the clock
> edge, some FFs will see the new value, and some the >ld. his can
> cause weird and fl>ky>behaviour.
>>
>> Regards,
>
> John McCaskillwww.FasterTechnology.com

I think I just found the source of the problem, and it's not a bug in
XST. In state S1, if 'state' is updated while 'phaseRamWE'  is not,
then it would produce the symptoms I saw. Early on, I had considered
synchronizing pipeFill to the 'clk" domain, but I thought I would just
handle it in the robustness of the state machine - my mistake.

Re: Xilinx XST and a State Machine - A Mystery

Postby John McCaskill » Wed, 22 Sep 2010 01:55:39 GMT

On Sep 20, 11:12m, Darol Klawetter < XXXX@XXXXX.COM >





> > asynchr>no>s>to 'clk'
>
> > If pipeFill is really asynchronous to the clock that i> >unning your
> > state machine, sing it without synchronizing it fir>t>is going to
> > cause you problems. robably not because of meta>t>bility, but
> > because of coherency problems. If pipeFill is changing >e>r the clock
> > edge, some FFs will see the new value, and some the >l>. his can
> > cause weird and fl>ky>b>haviour.
>>
>>>>Regards,
>
> > John McCaskillwww.Faster>ec>nology.com
>
> Agreed, but the state machine should recover, right? >ll states are
> defined.

Hello Darol,

While you may have specified all the possible states for the width of
state variable that you used, unless you tell XST otherwise, it will
choose which ever encoding style that it feels is optimal. That is
usually a one hot encoding for a state machine the size of yours.  By
default, XST will assume that states that you do not explicitly have a
transition to are truly unreachable and will not worry about them, and
will ignore default or when others cases of your case statement.

You can change the default behavior. You can force the tools to use an
encoding of your choice, and you can use the safe state machine
constraint to cause the tools to be more conservative in their
assumptions about unreachable states. Doing that will come at a cost
that the tools will choose a different encoding that will probably be
slower and bigger.

I think that you are much better off to always synchronize an
asynchronous signal at the boundary of your design.

Regards,

John McCaskill
www.FasterTechnology.com

Re: Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 03:02:48 GMT

n Sep 20, 11:55m, John McCaskill < XXXX@XXXXX.COM > wrote:
> > > asynchr>no>s>t> 'clk'
>
> > > If pipeFill is really asynchronous to the clock that i> >u>ning your
> > > state machine, sing it without synchronizing it fir>t>i> going to
> > > cause you problems. robably not because of meta>t>b>lity, but
> > > because of coherency problems. If pipeFill is changing >e>r>the clock
> > > edge, some FFs will see the new value, and some the >l>.>his can
> > > cause weird and fl>ky>b>h>viour.
>
>
> > > John McCaskillwww.Faster>ec>n>logy.com
>
> > Agreed, but the state machine should recover, right? >l> states are> >>> defined.
>
>
> While you may have specified all the possible states fo> the width of
> state variable that you used, unless you tell XST othe>wise, it will
> choose which ever encoding style that it feels is op>imal. That is
> usually a one hot encoding for a state machine the size>of yours. y
> default, XST will assume that states that you do not exp>icitly have a
> transition to are truly unreachable and will not worry a>out them, and
> will ignore default or when others cases of your c>se>statement.
>
> You can change the default behavior. You can force the t>ols to use an
> encoding of your choice, and you can use the safe>state machine
> constraint to cause the tools to be more conserv>tive in their
> assumptions about unreachable states. Doing that will >ome at a cost
> that the tools will choose a different encoding that wi>l probably be
> slow>r >nd bigger.
>
> I think that you are much better off to always >ynchronize an
> asynchronous signal at the boundary o> y>ur design. >> >> Regards,
>
> John McCaskillwww.FasterTechnology.com

Thanks for the response, John. Yes, I realized that the Xilinx tools
could use different state encoding than that specified by the user,
but it seemed reasonable to assume that functionality would be matched
(wrong assumption). Anyway, you may have noticed, from a previous post
to this thread, that my problem was caused by my own error and was not
tool related.

I agree with your last paragraph. It's typically better to use a
couple of flops on an asynchronous control signal than trying to
handle it within the state machine (especially if the tool is going to
take encoding liberties).

Re: Xilinx XST and a State Machine - A Mystery

Postby KJ » Wed, 22 Sep 2010 05:47:23 GMT

On Sep 20, 2:02m, Darol Klawetter < XXXX@XXXXX.COM >




The rule is that any time there is a logic path from an asynchronous
input to more than one device that samples the signal(s), you must
first synchronize the signal before feeding it into any logic path.

This condition occurs for any state machine with more than one state.

KJ

Re: Xilinx XST and a State Machine - A Mystery

Postby KJ » Wed, 22 Sep 2010 05:49:07 GMT

>

The rule is that any time there is a logic path from an asynchronous
input to more than one device that samples the signal(s), you must
first synchronize the signal before feeding it into any logic path.

This condition occurs for any state machine with more than flip flop
used to implement the state.

KJ

Re: Xilinx XST and a State Machine - A Mystery

Postby Darol Klawetter » Wed, 22 Sep 2010 06:01:45 GMT



I agree that this is a rule that should be generally followed, but
there are exceptions. For example, a gray-coded state machine is
sometimes used to tolerate an asynchronous control input. If timing is
violated on any of the flops, the machine will stay at the current
state or transition to the next state.

Re: Xilinx XST and a State Machine - A Mystery

Postby Gabor » Wed, 22 Sep 2010 06:09:33 GMT

On Sep 20, 5:01m, Darol Klawetter < XXXX@XXXXX.COM >





In practice, Gray code is not very useful for state machines that have
many
branch possibilities.  Remember that you need to make sure that any
possible transition only changes one state bit.  This is easy for any
linear or loop state logic like a counter, but most control logic
state
machines will have multiple-way branching from many of the states.
So unless you add intermediate states to prevent more than two-way
branching from any node you can still run into problems with
asynchronous inputs to the Gray coded machine.  The added states
would give the same delay as a synchronizer flop on the input signal.

Re: Xilinx XST and a State Machine - A Mystery

Postby d_s_klein » Wed, 22 Sep 2010 06:31:51 GMT

On Sep 20, 2:01m, Darol Klawetter < XXXX@XXXXX.COM >





This is not a rule that "should be generally followed".  It is rule
that must ALWAYS be followed!

If a signal from a "foreign" clock domain is used in a conditional
inside a state machine, the state machine will fail (eventually).

This is NOT a metastability problem.  It is because the time to decode
the D inputs of the state bits is different for each D input, and if
the "foreign clock" signal is used in a conditional it will go to more
than one D input.  There is no way to ensure that the D inputs are all
valid at the same time, and when the clock happens while one is valid
and the other is not state machine gets corrupted.  This syndrome is
independent of the coding method of the state variable.

Synchronizing all inputs to a state machine to the state machines
clock will prevent that.

Not optional.  Sorry.

RK

Re: Xilinx XST and a State Machine - A Mystery

Postby Stef » Wed, 22 Sep 2010 07:14:17 GMT

In comp.arch.fpga,



Did that many years ago for a CPLD design! Draw a big Karnaugh map,
try put in your states with the minimum possible dummy states and
only single bit changes. Great fun, better than cross-words. :-)

But agreed, wouldn't do that now (although, I might ...), and back
then it only worked if the machine was not too complex.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Most public domain software is free, at least at first glance.


Return to Computer architecture

 

Who is online

Users browsing this forum: No registered users and 40 guest