Logic implementation probelm

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 design
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 and
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 some
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 between
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 size
change of a register.

i have pulled down all unused ios and all other setups are exactly the
same

Regards    

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

On Aug 4, 9:23=A0am, "salimbaba"
a1234573_at_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 RT
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 cod
=
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 cras
an=
d
go into abort conditions. this happens primarily because of contentio
on
the data bus of the processor.
However, i cannot tell why this is happening that a change in logic i
so=
me
very remote part of the design causes the controller interface to
misbehave. Keep in view that my controller interface is perfected an
is
running perfectly on a couple of other systems.the only differenc
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
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 clocks
and related signals have also been placed into TIMEGRPs. Also i mention the
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 = "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 am
then comment on it plz