Prev: Vendor Tool Stability
Next: A question from a VHDL beginner
From: salimbaba on 4 Aug 2010 09:23
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 through http://www.FPGARelated.com
From: Gabor on 4 Aug 2010 09:33
On Aug 4, 9:23 am, "salimbaba"
<a1234573(a)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 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

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
From: salimbaba on 5 Aug 2010 07:59
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
///////////////////////////////////////////////////////

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 is
exaclty the point u made. However i have more flops down the chain just to
add delay but that doesnot realy count as a problem.


Regards








>On Aug 4, 9:23=A0am, "salimbaba"
><a1234573(a)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
>

---------------------------------------
Posted through http://www.FPGARelated.com
From: Gabor on 5 Aug 2010 08:54
On Aug 5, 7:59 am, "salimbaba"
<a1234573(a)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 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

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
From: Jeff Cunningham on 5 Aug 2010 09:30
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
 | 
Pages: 1
Prev: Vendor Tool Stability
Next: A question from a VHDL beginner