timing issues at high speed

[salimbaba]

Hi,
i am using spartan 3 xc3s4000 in my design and i am working at 125Mh
clock. My design works fine in simulations but when i brought it on board
i am having issues with timing i guess. Xilinx does not report any timin
failures but still im facing data loss. DataIn is not equal to DataOut
there is a great loss. Can anyone help me in achieving better timin
closures..

thanks


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

 

[backhus]

On 21 Feb., 06:45, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

Hi,
i am using spartan 3 xc3s4000 in my design and i am working at 125Mhz
clock. My design works fine in simulations but when i brought it on board,
i am having issues with timing i guess. Xilinx does not report any timing
failures but still im facing data loss. DataIn is not equal to DataOut,
there is a great loss. Can anyone help me in achieving better timing
closures..

thanks

---------------------------------------        
Posted throughhttp://www.FPGARelated.com

Hi,
If the timing report gives you a result above 125 MHz, this is no
question of timing closure.
Inside the FPGA everything should be fine.
But how do you make sure that valid data is captured at the inputs?
And, how long are the Input delays. If not designed with care, these
can ecceed the 8 ns period of the clock signal.
Similar things apply for the output.

Have a nice synthesis
Eilert

 

[salimbaba]

Hi,
If the timing report gives you a result above 125 MHz, this is no
question of timing closure.
Inside the FPGA everything should be fine.
But how do you make sure that valid data is captured at the inputs?
And, how long are the Input delays. If not designed with care, these
can ecceed the 8 ns period of the clock signal.
Similar things apply for the output.

Have a nice synthesis
Eilert

timing report shows 127Mhz. And it is basically a gigabit mac and it has
interfaces, So, whatever comes on interface A,i can see it on chipscope an
when to leaves at interface_B, i can see that too which is the same a
coming in. But i dont know why, but this data doesn't come out on wire.
can monitor it till the last point but after that i dont know what'
happening.

Kindly help me out.

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

 

[maxascent]

Are you using SERDES and if so have you simulated to ensure you have i
setup correctly?

Jon

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

 

[salimbaba]

Are you using SERDES and if so have you simulated to ensure you have it
setup correctly?

Jon

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

No Jon, i am not using SERDES in my design.

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

 

[salimbaba]

Are you using SERDES and if so have you simulated to ensure you have it
setup correctly?

Jon

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

No Jon, i am not using SERDES in my design.

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

ok on further monitoring of signals i came across this weird thing, m
state machines don't start from idle state when reset. few state machine
reset to idle, whereas others reset to some other state. Can anyone help m
out with this, and also tell me why is this happening ?

thanks

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

 

[Chris Maryan]

How are you coming out of reset? Ideally you should be coming out of reset synchronously. Is the reset to your SMs synchronous? If it is, then this basically leaves a logical error. Hopefully you are relying on a true reset, not just the default state of the state FFs.

Chris

 

[salimbaba]

How are you coming out of reset? Ideally you should be coming out of rese
=
synchronously. Is the reset to your SMs synchronous? If it is, then thi
ba=
sically leaves a logical error. Hopefully you are relying on a true reset
=
not just the default state of the state FFs.

Chris

i have asynchronous reset in my design. And well i have a reset pin but
have tied it low (PULLDOWN) in UCF, and that reset is going everywhere i
the design.
Can you suggest any solution ?

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

 

[Gabor]

On Monday, February 21, 2011 1:34:23 PM UTC-5, salimbaba wrote:

How are you coming out of reset? Ideally you should be coming out of reset
=
synchronously. Is the reset to your SMs synchronous? If it is, then this
basically leaves a logical error. Hopefully you are relying on a true reset,
not just the default state of the state FFs.

Chris


i have asynchronous reset in my design. And well i have a reset pin but i
have tied it low (PULLDOWN) in UCF, and that reset is going everywhere in
the design.
Can you suggest any solution ?

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

So you really are relying on the initial conditions after
configuration which is in essence an asynchronous release
of reset after power-on.

Generally a state machine can start up reliably with
an asynchronous release of reset, but ONLY if the
state it starts up in has no transition that will
immediately become active upon release of reset.
The simplest way to work around this is to generate
a local reset signal for each state machine or
module that releases synchronously one or two cycles
after the release of the asynchronous reset and
use that signal as a synchronous reset term for
your state machines. Xilinx usually recommends
a 4-stage shift register to create a reset from
the GSR release. The actual number of stages
required to reset cleanly will depend on the
clock frequency and the size of the device,
where the larger devices can have more skew in
releasing GSR. My designs typically have no
external reset signal and use the 4-stage S/R
approach to an internal reset. I have had
very good results with this approach, because
the four stages give the tools ample opportunity
to replicate the final S/R stage(s) to help
meet timing.

-- Gabor

 

[Bob Perlman]

On Feb 21, 12:34 pm, Gabor <ga...@alacron.com> wrote:

On Monday, February 21, 2011 1:34:23 PM UTC-5, salimbaba wrote:
How are you coming out of reset? Ideally you should be coming out of reset
synchronously. Is the reset to your SMs synchronous? If it is, then this
basically leaves a logical error. Hopefully you are relying on a true reset,
not just the default state of the state FFs.

Chris

i have asynchronous reset in my design. And well i have a reset pin but i
have tied it low (PULLDOWN) in UCF, and that reset is going everywhere in
the design.
Can you suggest any solution ?        

---------------------------------------            
Posted throughhttp://www.FPGARelated.com

So you really are relying on the initial conditions after
configuration which is in essence an asynchronous release
of reset after power-on.

Generally a state machine can start up reliably with
an asynchronous release of reset, but ONLY if the
state it starts up in has no transition that will
immediately become active upon release of reset.
The simplest way to work around this is to generate
a local reset signal for each state machine or
module that releases synchronously one or two cycles
after the release of the asynchronous reset and
use that signal as a synchronous reset term for
your state machines.  Xilinx usually recommends
a 4-stage shift register to create a reset from
the GSR release.  The actual number of stages
required to reset cleanly will depend on the
clock frequency and the size of the device,
where the larger devices can have more skew in
releasing GSR.  My designs typically have no
external reset signal and use the 4-stage S/R
approach to an internal reset.  I have had
very good results with this approach, because
the four stages give the tools ample opportunity
to replicate the final S/R stage(s) to help
meet timing.

-- Gabor

Wow, nicely said! Anyone starting out in FSM design should take heed.

I'll add one more thing: do you have any unconstrained timing paths in
your design?

Bob Perlman
Cambrian Design Works

 

[salimbaba]

On Monday, February 21, 2011 1:34:23 PM UTC-5, salimbaba wrote:
How are you coming out of reset? Ideally you should be coming out o
reset
=
synchronously. Is the reset to your SMs synchronous? If it is, the
this
basically leaves a logical error. Hopefully you are relying on a tru
reset,
not just the default state of the state FFs.

Chris


i have asynchronous reset in my design. And well i have a reset pin bu
i
have tied it low (PULLDOWN) in UCF, and that reset is going everywher
in
the design.
Can you suggest any solution ?

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

So you really are relying on the initial conditions after
configuration which is in essence an asynchronous release
of reset after power-on.

Generally a state machine can start up reliably with
an asynchronous release of reset, but ONLY if the
state it starts up in has no transition that will
immediately become active upon release of reset.
The simplest way to work around this is to generate
a local reset signal for each state machine or
module that releases synchronously one or two cycles
after the release of the asynchronous reset and
use that signal as a synchronous reset term for
your state machines. Xilinx usually recommends
a 4-stage shift register to create a reset from
the GSR release. The actual number of stages
required to reset cleanly will depend on the
clock frequency and the size of the device,
where the larger devices can have more skew in
releasing GSR. My designs typically have no
external reset signal and use the 4-stage S/R
approach to an internal reset. I have had
very good results with this approach, because
the four stages give the tools ample opportunity
to replicate the final S/R stage(s) to help
meet timing.

-- Gabor

Thanks a lot Gabor for the help. I tried 4 stage S/R approach but still th

same problem. And there are no failing paths in my design, at least no
reported in the timing report. Any other suggestions ? And also, i rea
this Cummings's paper on synchronous and asynchronous resets which state
the same solution, but i am still facing the same problem. In need o
urgent help!

Thanks


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

 

[Muzaffer Kal]

On Tue, 22 Feb 2011 01:28:15 -0600, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

Thanks a lot Gabor for the help. I tried 4 stage S/R approach but still the
same problem. And there are no failing paths in my design, at least not
reported in the timing report. Any other suggestions ? And also, i read
this Cummings's paper on synchronous and asynchronous resets which stated
the same solution, but i am still facing the same problem. In need of
urgent help!

I have several questions some of which may give you a clue (and
hopefully not duplicative):
* how many clocks do you have in the system? All of them constrained?
Any of them coming from different sources (different oscillators,
crystals, PHYs etc?)
* did you check the "report unconstrained paths" option? did you read
the resulting report?
* do you have any latches (mainly combination feedback) in the design?
* do you have any divided clocks in the design?
* did you constrain all you IOs? did you check the datasheet/scope to
verify that these timing values are correct?
* do you have any multi-cycle constraints in your design? are you
using the version of TRCE/PAR which has a bug with MC paths? (this is
a trick question!)
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[Thomas Heller]

Am 21.02.2011 21:34, schrieb Gabor:

The simplest way to work around this is to generate
a local reset signal for each state machine or
module that releases synchronously one or two cycles
after the release of the asynchronous reset and
use that signal as a synchronous reset term for
your state machines. Xilinx usually recommends
a 4-stage shift register to create a reset from
the GSR release. The actual number of stages
required to reset cleanly will depend on the
clock frequency and the size of the device,
where the larger devices can have more skew in
releasing GSR. My designs typically have no
external reset signal and use the 4-stage S/R
approach to an internal reset. I have had
very good results with this approach, because
the four stages give the tools ample opportunity
to replicate the final S/R stage(s) to help
meet timing.

Can you post some code (or pointers) demonstrating
this reset signal generation?

Thanks,
Thomas

 

[vasu]

On Feb 22, 12:45 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Tue, 22 Feb 2011 01:28:15 -0600, "salimbaba"

a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

Thanks a lot Gabor for the help. I tried 4 stage S/R approach but still the
same problem. And there are no failing paths in my design, at least not
reported in the timing report. Any other suggestions ? And also, i read
this Cummings's paper on synchronous and asynchronous resets which stated
the same solution, but i am still facing the same problem. In need of
urgent help!

I have several questions some of which may give you a clue (and
hopefully not duplicative):
* how many clocks do you have in the system? All of them constrained?
Any of them coming from different sources (different oscillators,
crystals, PHYs etc?)
* did you check the "report unconstrained paths" option? did you read
the resulting report?
* do you have any latches (mainly combination feedback) in the design?
* do you have any divided clocks in the design?
* did you constrain all you IOs? did you check the datasheet/scope to
verify that these timing values are correct?
* do you have any multi-cycle constraints in your design? are you
using the version of TRCE/PAR which has a bug with MC paths? (this is
a trick question!)
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

I would like to a point here. Do you have any shift registers i.e. SRL
in your design? These create problems when there is a glitch on clock
signal.

 

[salimbaba]

I have several questions some of which may give you a clue (and
hopefully not duplicative):
* how many clocks do you have in the system? All of them constrained?

I have 4 clocks in my system and 2 of them are constrained i.e. i hav
placed OFFSET IN constraints on them. The other 2 are not constrained as
am using them to output data. So i have just given them PERIOD an
TIMESPEC.

Any of them coming from different sources (different oscillators,
crystals, PHYs etc?)

2 clocks are coming from 1 PHY and 2 are coming from 2nd PHY.

* did you check the "report unconstrained paths" option? did you read
the resulting report?

NO. I will check it now and see the report.

* do you have any latches (mainly combination feedback) in the design?

No latches are there in the design.

* do you have any divided clocks in the design?

I have 2 divided clocks. The divided clocks are also being used in th
design.

* did you constrain all you IOs? did you check the datasheet/scope to
verify that these timing values are correct?

If by constraining IOs you mean timegrouping thing, then yes.

* do you have any multi-cycle constraints in your design? are you
using the version of TRCE/PAR which has a bug with MC paths? (this is
a trick question!)

No, i dont have any multi cycle constraints in my design.
Well i dont know which version of TRCE/PAR has the bug, i am using xilin
ISE 12.1 .


thanks

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

 

[Gabor]

On Tuesday, February 22, 2011 2:50:53 AM UTC-5, Thomas Heller wrote:

Am 21.02.2011 21:34, schrieb Gabor:
The simplest way to work around this is to generate
a local reset signal for each state machine or
module that releases synchronously one or two cycles
after the release of the asynchronous reset and
use that signal as a synchronous reset term for
your state machines. Xilinx usually recommends
a 4-stage shift register to create a reset from
the GSR release. The actual number of stages
required to reset cleanly will depend on the
clock frequency and the size of the device,
where the larger devices can have more skew in
releasing GSR. My designs typically have no
external reset signal and use the 4-stage S/R
approach to an internal reset. I have had
very good results with this approach, because
the four stages give the tools ample opportunity
to replicate the final S/R stage(s) to help
meet timing.

Can you post some code (or pointers) demonstrating
this reset signal generation?

Thanks,
Thomas

Here's the Xilinx approach using instantiated
flip-flops with asynchronous preset (and implied
initialization to 1):

wire sys_clock, sys_reset;
wire [2:0] presys_rst;
// --------------------------------------------------------------------
// Instantiate flip-flops for internal reset signals
// These flip-flops come up preset (all ones) after configuration.
FDP sys_rst_ff[3:0]
(
.D ({presys_rst,1'b0}), // form a shifter with 0 shifting in from right
.Q ({sys_reset,presys_rst}),
.C (sys_clock),
.PRE (1'b0) // A preset term may be inserted here, otherwise release reset after config
);

And here's the equivalent Verilog:


wire sys_clock;
reg sys_reset = 1'b1;
reg [2:0] presys_rst = 3'b111;

always @ (posedge sys_clock)
{sys_reset,presys_rst} <= {presys_rst,1'b0};

-- Gabor

 

[Gabor]

On Tuesday, February 22, 2011 2:28:15 AM UTC-5, salimbaba wrote:

Thanks a lot Gabor for the help. I tried 4 stage S/R approach but still the
same problem. And there are no failing paths in my design, at least not
reported in the timing report. Any other suggestions ? And also, i read
this Cummings's paper on synchronous and asynchronous resets which stated
the same solution, but i am still facing the same problem. In need of
urgent help!

Thanks

In that case I would look for other asynchronous inputs to
the state machines that are failing. How do you know they
are failing to start up after reset and not some time later?
The most common reason for a state machine to go haywire
is that it has a state transition that depends on an
asynchronous input. Note that since your design has
more than one clock, asynchronous means any input that
was not created on the same clock used by the state
machine.

-- Gabor

 

[Muzaffer Kal]

On Tue, 22 Feb 2011 07:51:24 -0600, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:

I have several questions some of which may give you a clue (and
hopefully not duplicative):
* how many clocks do you have in the system? All of them constrained?

I have 4 clocks in my system and 2 of them are constrained i.e. i have
placed OFFSET IN constraints on them. The other 2 are not constrained as i
am using them to output data. So i have just given them PERIOD and
TIMESPEC.

OFFSET constraints are for data. For clocks you always need PERIOD

constraint without which your design is NOT constrained properly.

Any of them coming from different sources (different oscillators,
crystals, PHYs etc?)

2 clocks are coming from 1 PHY and 2 are coming from 2nd PHY.

How do you transfer data between these domains? (I am assuming the
PHYs have different oscillators, is this the case?) This can be source
of many unexplained issues in your silicon testing.

* do you have any latches (mainly combination feedback) in the design?

No latches are there in the design.

How do you know? Do you have a method of finding unintentional
latches, combinational feedback?

* do you have any divided clocks in the design?

I have 2 divided clocks. The divided clocks are also being used in the
design.

Are the PERIOD constraints for the divided clocks set properly?

* did you constrain all you IOs? did you check the datasheet/scope to
verify that these timing values are correct?

If by constraining IOs you mean timegrouping thing, then yes.

IOs are constrained by OFFSET constraints (ie relative delay of
signals with respect to a clock) and clocks are constrained by PERIOD
constraints. You need to make sure every signal which arrives at a CLK
pin of a register has a PERIOD constraint attached to it.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[GoogleGoonsAreClueless]

On Feb 22, 6:12 am, Gabor <ga...@alacron.com> wrote:

On Tuesday, February 22, 2011 2:28:15 AM UTC-5, salimbaba wrote:
Thanks a lot Gabor for the help. I tried 4 stage S/R approach but still the
same problem. And there are no failing paths in my design, at least not
reported in the timing report. Any other suggestions ? And also, i read
this Cummings's paper on synchronous and asynchronous resets which stated
the same solution, but i am still facing the same problem. In need of
urgent help!

Thanks

In that case I would look for other asynchronous inputs to
the state machines that are failing.  How do you know they
are failing to start up after reset and not some time later?
The most common reason for a state machine to go haywire
is that it has a state transition that depends on an
asynchronous input.  Note that since your design has
more than one clock, asynchronous means any input that
was not created on the same clock used by the state
machine.

-- Gabor

How many times are we going to have this discussion, and how many
times are people (like the OP) going to get burned when they don't
believe the following:

"The most common reason for a state machine to go haywire is that it
has a state transition that depends on an asynchronous input."

All inputs that are used in a 'conditional' in a state machine MUST be
synchronized to the state machines clock.

<http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/
1ea0ba1a1005287f/0e3c67b4b4163205>
<http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/
fa2dba1d2e86c730/17568f37ad2dde1b>

RK

 

[salimbaba]

In that case I would look for other asynchronous inputs to
the state machines that are failing. =A0How do you know they
are failing to start up after reset and not some time later?
The most common reason for a state machine to go haywire
is that it has a state transition that depends on an
asynchronous input. =A0Note that since your design has
more than one clock, asynchronous means any input that
was not created on the same clock used by the state
machine.

-- Gabor

How many times are we going to have this discussion, and how many
times are people (like the OP) going to get burned when they don't
believe the following:

"The most common reason for a state machine to go haywire is that it
has a state transition that depends on an asynchronous input."

All inputs that are used in a 'conditional' in a state machine MUST be
synchronized to the state machines clock.

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/
1ea0ba1a1005287f/0e3c67b4b4163205
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/
fa2dba1d2e86c730/17568f37ad2dde1b

RK

All the inputs are synchronized with the state machine clock. It ha
something to do with metastability of the signal that starts the stat
machine because when i removed it, everything was in place. State machin
was in the IDLE mode as it should be.

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