Hey i am using ise 9.1i for synthesizing my
designs for spartan 3 fpgas. Iam facing a very wierd problem.
My system comprises of 1 xcs400 fpga and an ARM 7 processor. My RTL designis very modular. Here is the problem.
 
I have a microcontroller interface in my rtl design to communicate witharm. other portions of my rtl design are related to some other logicimplementations.now what happens is that when i change some line of code orlogic in the other modules WHICH ARE IN NO WAY CONNECTED TO CONTROLLERINTERFACE, the bit file that is generated causes my processor to crash andgo into abort conditions. this happens primarily because of contention onthe data bus of the processor.
However, i cannot tell why this is happening that a change in logic is somevery remote part of the design causes the controller interface tomisbehave. Keep in view that my controller interface is perfected and isrunning perfectly on a couple of other systems.the only difference betweena working bit file and a non working bit file is a small change in someother part of the design and it is so small that it may include only a sizechange of a register.
 
i have pulled down all unused ios and all other setups are exactly thesame
 
Regards	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Aug 4, 9:23=A0am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hey i am using ise 9.1i for synthesizing my designs for spartan 3 fpgas. =
I
> am facing a very wierd problem.
> My system comprises of 1 xcs400 fpga and an ARM 7 processor. My RTL desig=
n
> is very modular. Here is the problem.
>
> I have a microcontroller interface in my rtl design to communicate with
> arm. other portions of my rtl design are related to some other logic
> implementations.now what happens is that when i change some line of code =
or
> logic in the other modules WHICH ARE IN NO WAY CONNECTED TO CONTROLLER
> INTERFACE, the bit file that is generated causes my processor to crash an=
d
> go into abort conditions. this happens primarily because of contention on
> the data bus of the processor.
> However, i cannot tell why this is happening that a change in logic is so=
me
> very remote part of the design causes the controller interface to
> misbehave. Keep in view that my controller interface is perfected and is
> running perfectly on a couple of other systems.the only difference betwee=
n
> a working bit file and a non working bit file is a small change in some
> other part of the design and it is so small that it may include only a si=
ze
> change of a register.
>
> i have pulled down all unused ios and all other setups are exactly the
> same
>
> Regards =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

It's very likely that you are having timing problems.  If your design
is
not properly constrained, the timing can vary significantly from run
to run, even for parts of the design that don't change.  I assume
you at least have PERIOD constraints on any clocks in the design.
In addition you should constrain inputs and outputs for setup/hold
and clock to out.  Alternately turn on the switch in the tools that
says to push all of your I/O flip-flops into the IOB's.  This will
cause the timing at the pin interface to be constant from run
to run.  There may be cases where you I/O logic cannot be
pushed into the IOB's however, so you need to check for these
and make sure that you have constrained the timing for them
appropriately.

A good source of information is your post place&route timing
report.  Make sure you tell the report generator to add the
data sheet section.  This gives you a view into the setup/hold
and clock to out timing of your design as built.  See if there
are significant differences between the versions that work
and those that don't.

Finally another cause of build-to-build design instability is
also caused by timing differences but not in a way that
lends itself to being constrained.  If you have any signals
that come in asynchronously or cross clock domains be
sure that for each clock they are only registered in one
flip-flop.  Any further logic in that clock domain should use
the output of the same initial synchronizing flip-flop.  If
the same async input goes through multiple flip-flops,
those flip-flops can see the signal change on different
clock cycles, and which one sees the signal first can
change from build to build based on the relative routing
delays from the source to the flip-flop D input.

HTH,
Gabor

Hey 

Related to constraints like period. I have PERIOD constraints on my clocksand related signals have also been placed into TIMEGRPs. Also i mention theduty cycle of clocks

here are some numbers
there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. Thecontroller interface runs at mclk and is seperated from other logic.

i use the following statements to constraint

NET "phy_clk" TNM_NET = "phy_clk";
TIMESPEC "TS_phy_clk" = PERIOD "phy_clk" 40 ns HIGH 50 %;

NET "mclk" TNM_NET = "mclk";
TIMESPEC "TS_mclk" = PERIOD "mclk" 20 ns HIGH 50 %;



Further the TIMEGRPS are

TIMEGRP "phy_clk_pads" OFFSET = IN 35 ns BEFORE "phy_clk"  ;
TIMEGRP "mclk_pads" OFFSET = IN 15 ns BEFORE "mclk"  ;
TIMEGRP "phy_clk_pads" OFFSET = OUT 35 ns AFTER "phy_clk"  ;
TIMESPEC "TS_P2P" = FROM "PADS" TO "PADS" 15 ns;


so now the controller interface constraints are

INST "data_bus<7>" TNM = "mclk_pads";
INST "data_bus<6>" TNM = "mclk_pads";
INST "data_bus<5>" TNM = "mclk_pads";
INST "data_bus<4>" TNM = "mclk_pads";
INST "data_bus<3>" TNM = "mclk_pads";
INST "data_bus<2>" TNM = "mclk_pads";
INST "data_bus<1>" TNM = "mclk_pads";
INST "data_bus<0>" TNM = "mclk_pads";
INST "read_" TNM = "mclk_pads";
INST "cs_" TNM = "mclk_pads";
INST "write_" TNM = "mclk_pads";

SO i dont think that i am missing the constraints. However if u think i amthen comment on it plz
///////////////////////////////////////////////////////

Related to your comment on flopping signals only once in one clock domain:

I am not doing any branching for the first stage of floping which isexaclty the point u made. However i have more flops down the chain just toadd delay but that doesnot realy count as a problem.


Regards








>On Aug 4, 9:23=A0am, "salimbaba"
><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
>> Hey i am using ise 9.1i for synthesizing my designs for spartan 3 fpgas.=
>I
>> am facing a very wierd problem.
>> My system comprises of 1 xcs400 fpga and an ARM 7 processor. My RTLdesig=
>n
>> is very modular. Here is the problem.
>>
>> I have a microcontroller interface in my rtl design to communicate with
>> arm. other portions of my rtl design are related to some other logic
>> implementations.now what happens is that when i change some line of code=
>or
>> logic in the other modules WHICH ARE IN NO WAY CONNECTED TO CONTROLLER
>> INTERFACE, the bit file that is generated causes my processor to crashan=
>d
>> go into abort conditions. this happens primarily because of contentionon
>> the data bus of the processor.
>> However, i cannot tell why this is happening that a change in logic isso=
>me
>> very remote part of the design causes the controller interface to
>> misbehave. Keep in view that my controller interface is perfected andis
>> running perfectly on a couple of other systems.the only differencebetwee=
>n
>> a working bit file and a non working bit file is a small change in some
>> other part of the design and it is so small that it may include only asi=
>ze
>> change of a register.
>>
>> i have pulled down all unused ios and all other setups are exactly the
>> same
>>
>> Regards =A0 =A0
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.FPGARelated.com
>
>It's very likely that you are having timing problems.  If your design
>is
>not properly constrained, the timing can vary significantly from run
>to run, even for parts of the design that don't change.  I assume
>you at least have PERIOD constraints on any clocks in the design.
>In addition you should constrain inputs and outputs for setup/hold
>and clock to out.  Alternately turn on the switch in the tools that
>says to push all of your I/O flip-flops into the IOB's.  This will
>cause the timing at the pin interface to be constant from run
>to run.  There may be cases where you I/O logic cannot be
>pushed into the IOB's however, so you need to check for these
>and make sure that you have constrained the timing for them
>appropriately.
>
>A good source of information is your post place&route timing
>report.  Make sure you tell the report generator to add the
>data sheet section.  This gives you a view into the setup/hold
>and clock to out timing of your design as built.  See if there
>are significant differences between the versions that work
>and those that don't.
>
>Finally another cause of build-to-build design instability is
>also caused by timing differences but not in a way that
>lends itself to being constrained.  If you have any signals
>that come in asynchronously or cross clock domains be
>sure that for each clock they are only registered in one
>flip-flop.  Any further logic in that clock domain should use
>the output of the same initial synchronizing flip-flop.  If
>the same async input goes through multiple flip-flops,
>those flip-flops can see the signal change on different
>clock cycles, and which one sees the signal first can
>change from build to build based on the relative routing
>delays from the source to the flip-flop D input.
>
>HTH,
>Gabor
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Aug 5, 7:59=A0am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hey
>
> Related to constraints like period. I have PERIOD constraints on my clock=
s
> and related signals have also been placed into TIMEGRPs. Also i mention t=
he
> duty cycle of clocks
>
> here are some numbers
> there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. The
> controller interface runs at mclk and is seperated from other logic.
>
> i use the following statements to constraint
>
> NET "phy_clk" TNM_NET =3D "phy_clk";
> TIMESPEC "TS_phy_clk" =3D PERIOD "phy_clk" 40 ns HIGH 50 %;
>
> NET "mclk" TNM_NET =3D "mclk";
> TIMESPEC "TS_mclk" =3D PERIOD "mclk" 20 ns HIGH 50 %;
>
> Further the TIMEGRPS are
>
> TIMEGRP "phy_clk_pads" OFFSET =3D IN 35 ns BEFORE "phy_clk" =A0;
> TIMEGRP "mclk_pads" OFFSET =3D IN 15 ns BEFORE "mclk" =A0;
> TIMEGRP "phy_clk_pads" OFFSET =3D OUT 35 ns AFTER "phy_clk" =A0;
> TIMESPEC "TS_P2P" =3D FROM "PADS" TO "PADS" 15 ns;
>
> so now the controller interface constraints are
>
> INST "data_bus<7>" TNM =3D "mclk_pads";
> INST "data_bus<6>" TNM =3D "mclk_pads";
> INST "data_bus<5>" TNM =3D "mclk_pads";
> INST "data_bus<4>" TNM =3D "mclk_pads";
> INST "data_bus<3>" TNM =3D "mclk_pads";
> INST "data_bus<2>" TNM =3D "mclk_pads";
> INST "data_bus<1>" TNM =3D "mclk_pads";
> INST "data_bus<0>" TNM =3D "mclk_pads";
> INST "read_" TNM =3D "mclk_pads";
> INST "cs_" TNM =3D "mclk_pads";
> INST "write_" TNM =3D "mclk_pads";
>
> SO i dont think that i am missing the constraints. However if u think i a=
m
> then comment on it plz

The only way to see if your design is properly constrained is to
create
a "Verbose" timing report (post P&R) and turn on "Report Unconstrained
Paths" for say 100 paths.  See if any paths look like they should be
constrained.  Also enable the "data sheet" section of the timing
report.
Compare the data sheet numbers (I/O timing) for a working version
vs. a non-working version to see if anything looks like it could be
causing the problem.  Your I/O constraints are quite loose.  They
only leave 5 ns for setup and clock to Q at the external device.  Make
sure this is acceptable.

Regards,
Gabor

Do you have state machines in the design? Are
they properly reset with a 
SYNCHRONOUS reset at the beginning of the day? Using the global async 
reset is not sufficient. You must provide a reset signal that is 
synchronous to the state machine's clock. Failure to do this can result 
in illegal states and erratic behavior.

-Jeff