FPGA changes behaviour when the resource's usage percentage

E

Emanuele83

Guest
Good day to everybody,

I have a problem with my new FPGA design. After a long time using
Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
package. We had a lot of problems soldering this CSG484 packages and
the whole board has been baked 2 times. The first time the balls were
not melted totally and didn’t solder completely the FPGAs to the the
PCB, due to a bad temperature profile. The same PCBs and the same
FPGAs has been baked another time with the correct temperature profile
and the balls were melted properly, the daisy chain was recognized and
the FPGA were possible to be programmed.

Since the beginning we had problems in the communication between FPGAs
and other onboard chips.
I program in VHDL and my code is correctly written from the
algorithmic point of view. It matches the requirements that I have set
to communicate with the other chips onboard and perform the correct
computations on the data that must be processed. I performed a post
synthesis simulation of each and every block that forms the design.
The aim of the design is to run @ 80Mhz speed.
The problem is that even setting the constraints over period, duty
cycle, OFFSET IN and OUT, with all the constraints met in the timing
report, the FPGA behaves in a totally different way if I change the
compiling settings (for example changing from AREA to SPEED goals, or
changing the state machine implementation from “one hot” to “auto”) or
modifying the VHDL code slightly.
Thus I decided to decrease the clock frequency. I have a 40MHz
oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
to let the system work at 40MHz (with some small modification in the
logic to let the external communication possible (RAM, external chips
which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
and the system was working. Ok, it is a matter of speed, I thought. No
it does not. Because, when I modified the VHDL code, or II added a
Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz
are met.
I tried to overconstrain the design (real clock speed at 40MHz,
constraints to 50MHz or 60Mhz) and it works if I do not modify the
VHDL code slightly…
For example leaving the VHDL code written by myself as it is and
adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
different (all the constraints met, as usual).


Thus my doubts are:
Why, if the constraints are met, if SETUP and HOLD time are well
controlled by the Synthesis tool, my FPGA corrupts data?
Do I have to expect something like this? I mean, if the optimization
process is done by the ISE toolsuite, the translation the mapping,
routing and so on, should I trust the timing report results or should
I expect strange behaviour when I program my FPGA?
I am in the FPGA world since no more than 3 years and I never seen
something like this. Can somebody who has more experience tell me if
this is usual, if something like this is normal in a complex FPGA
design?
My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,


Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
4_I also tried to run the synthesis SW on a different computer and
upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
Edition) but after compiling nothing changes
 
Good day to everybody,

I have a problem with my new FPGA design. After a long time using
Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
package. We had a lot of problems soldering this CSG484 packages and
the whole board has been baked 2 times. The first time the balls were
not melted totally and didn=92t solder completely the FPGAs to the the
PCB, due to a bad temperature profile. The same PCBs and the same
FPGAs has been baked another time with the correct temperature profile
and the balls were melted properly, the daisy chain was recognized and
the FPGA were possible to be programmed.

Since the beginning we had problems in the communication between FPGAs
and other onboard chips.
I program in VHDL and my code is correctly written from the
algorithmic point of view. It matches the requirements that I have set
to communicate with the other chips onboard and perform the correct
computations on the data that must be processed. I performed a post
synthesis simulation of each and every block that forms the design.
The aim of the design is to run @ 80Mhz speed.
The problem is that even setting the constraints over period, duty
cycle, OFFSET IN and OUT, with all the constraints met in the timing
report, the FPGA behaves in a totally different way if I change the
compiling settings (for example changing from AREA to SPEED goals, or
changing the state machine implementation from =93one hot=94 t
=93auto=94)=
or
modifying the VHDL code slightly.
Thus I decided to decrease the clock frequency. I have a 40MHz
oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
to let the system work at 40MHz (with some small modification in the
logic to let the external communication possible (RAM, external chips
which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
and the system was working. Ok, it is a matter of speed, I thought. No
it does not. Because, when I modified the VHDL code, or II added a
Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz
are met.
I tried to overconstrain the design (real clock speed at 40MHz,
constraints to 50MHz or 60Mhz) and it works if I do not modify the
VHDL code slightly=85
For example leaving the VHDL code written by myself as it is and
adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
different (all the constraints met, as usual).


Thus my doubts are:
Why, if the constraints are met, if SETUP and HOLD time are well
controlled by the Synthesis tool, my FPGA corrupts data?
Do I have to expect something like this? I mean, if the optimization
process is done by the ISE toolsuite, the translation the mapping,
routing and so on, should I trust the timing report results or should
I expect strange behaviour when I program my FPGA?
I am in the FPGA world since no more than 3 years and I never seen
something like this. Can somebody who has more experience tell me if
this is usual, if something like this is normal in a complex FPGA
design?
My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,


Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
4_I also tried to run the synthesis SW on a different computer and
upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
Edition) but after compiling nothing changes
Click to expand...
I cant see any reason why you should be having any problems running at 80
MHz. If you have checked the timing report and there are no reported
problems then you should be fine. You shouldnt really need to do a post
route sim. I have worked on designs running with 400 MHz DDR memory without
the need for a post route sim. You dont say what chips you are interfacing
with but at 80 MHz you shouldnt have any real problems as long as you are
using correct design techniques and your board is routed correctly. A bit
of an unknown is the soldering of your chips. It seems a bit of a mystery
to me why your manufacturer is having so many problems soldering these
devices. At the end of the day if you cant start off with a good working
pcb then you could end up going round in circles.

Regards

Jon

---------------------------------------
Posted through http://www.FPGARelated.com
 
I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....
Click to expand...

You need to find an assembly house with a Vapour Phase reflow oven, from
what I understand (from my assembly guys) this almost guarantees a good
result.

Even without this BGAs are pretty run of the mill, any competent assembly
house should be able to get this down.

Are you going to a quality assembly house or the cheapest one?


Nial
 
On Jan 25, 10:35 am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
Good day to everybody,

I have a problem with my new FPGA design. After a long time using
Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
package. We had a lot of problems soldering this CSG484 packages and
the whole board has been baked 2 times. The first time the balls were
not melted totally and didn=92t solder completely the FPGAs to the the
PCB, due to a bad temperature profile. The same PCBs and the same
FPGAs has been baked another time with the correct temperature profile
and the balls were melted properly, the daisy chain was recognized and
the FPGA were possible to be programmed.

Since the beginning we had problems in the communication between FPGAs
and other onboard chips.
I program in VHDL and my code is correctly written from the
algorithmic point of view. It matches the requirements that I have set
to communicate with the other chips onboard and perform the correct
computations on the data that must be processed. I performed a post
synthesis simulation of each and every block that forms the design.
The aim of the design is to run @ 80Mhz speed.
The problem is that even setting the constraints over period, duty
cycle, OFFSET IN and OUT, with all the constraints met in the timing
report, the FPGA behaves in a totally different way if I change the
compiling settings (for example changing from AREA to SPEED goals, or
changing the state machine implementation from =93one hot=94 to
=93auto=94)> > or
modifying the VHDL code slightly.
Thus I decided to decrease the clock frequency. I have a 40MHz
oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
to let the system work at 40MHz (with some small modification in the
logic to let the external communication possible (RAM, external chips
which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
and the system was working. Ok, it is a matter of speed, I thought. No
it does not. Because, when I modified the VHDL code, or II added a
Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz
are met.
I tried to overconstrain the design (real clock speed at 40MHz,
constraints to 50MHz or 60Mhz) and it works if I do not modify the
VHDL code slightly=85
For example leaving the VHDL code written by myself as it is and
adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
different (all the constraints met, as usual).

Thus my doubts are:
Why, if the constraints are met, if SETUP and HOLD time are well
controlled by the Synthesis tool, my FPGA corrupts data?
Do I have to expect something like this? I mean, if the optimization
process is done by the ISE toolsuite, the translation the mapping,
routing and so on, should I trust the timing report results or should
I expect strange behaviour when I program my FPGA?
I am in the FPGA world since no more than 3 years and I never seen
something like this. Can somebody who has more experience tell me if
this is usual, if something like this is normal in a complex FPGA
design?
My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
4_I also tried to run the synthesis SW on a different computer and
upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
Edition) but after compiling nothing changes

I cant see any reason why you should be having any problems running at 80
MHz. If you have checked the timing report and there are no reported
problems then you should be fine. You shouldnt really need to do a post
route sim. I have worked on designs running with 400 MHz DDR memory without
the need for a post route sim. You dont say what chips you are interfacing
with but at 80 MHz you shouldnt have any real problems as long as you are
using correct design techniques and your board is routed correctly. A bit
of an unknown is the soldering of your chips. It seems a bit of a mystery
to me why your manufacturer is having so many problems soldering these
devices. At the end of the day if you cant start off with a good working
pcb then you could end up going round in circles.

Regards

Jon        

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
Click to expand...
I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....

Somebody on xilinx forum was complaining about my state machines reset
path. look at the example:

histogram_calculation_process : process (clk_120)
begin
if clk_120'event and clk_120='1' then -- clk rising edge
if rst /= '1' then -- not reset
case state_m_1 is
when idle =>
A_tcspc <= input_a;
B_tcspc <= input_b;
state_m_1 <= state_1;
when state_1 =>
output_sum <= S;
state_m_1 <= idle;
when others => null;
end case
else
state_m_1 <= idle;
end if;
end if;

I always used it and once that it is synchronized with the clock I do
not see a reason to do it differently... any advice?

Tnx
Emanuele
 
On Jan 25, 11:23 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....

You need to find an assembly house with a Vapour Phase reflow oven, from
what I understand (from my assembly guys) this almost guarantees a good
result.

Even without this BGAs are pretty run of the mill, any competent assembly
house should be able to get this down.

Are you going to a quality assembly house or the cheapest one?

Nial
Click to expand...
I do not know if it is the cheapest one. I know only that they are
soldering with IRs reflow.
I am not the one in the office who has the choice... Now we sent a
board to be reworked and new FPGAs will be soldered.
The point is that if they do it with the bad temp profile I am afraid
that the FPGA can be damaged...
 
On 25/01/2011 10:31, Emanuele83 wrote:
On Jan 25, 11:23 am, "Nial Stewart"
nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....

You need to find an assembly house with a Vapour Phase reflow oven, from
what I understand (from my assembly guys) this almost guarantees a good
result.

Even without this BGAs are pretty run of the mill, any competent assembly
house should be able to get this down.

Are you going to a quality assembly house or the cheapest one?

Nial

I do not know if it is the cheapest one. I know only that they are
soldering with IRs reflow.
I am not the one in the office who has the choice... Now we sent a
board to be reworked and new FPGAs will be soldered.
The point is that if they do it with the bad temp profile I am afraid
that the FPGA can be damaged...
Click to expand...
My experience is that as long as the profile is sufficient for solder to
flow, and with a quality paste, it's unusual for things to go wrong. I
have also found from building prototypes in-house that whilst going over
temperature is not disasterous, though may affect long term reliability.

Do you have a backup of an old snapshot of your design? Can you check
the PCB works in the same way it did when the snapshort was taken?

Whilst a 80 MHz clock is low, there are a myriad of reasons why a design
change may stop the FPGA from funtioning as exected. I assume you have
checked the design will work with the specified clock rate? There maybe
issues with simulatenous switching, or through compromised decoupling.

Personally I would use, and I beleive its more conventional for:

histogram_calculation_process : process (clk_120)
begin
if rst = '1' then -- not reset
state_m_1 <= idle;
elsif clk_120'event and clk_120='1' then -- clk rising edge
case state_m_1 is
when idle =>
A_tcspc <= input_a;
B_tcspc <= input_b;
state_m_1 <= state_1;
when state_1 =>
output_sum <= S;
state_m_1 <= idle;
when others => null;
end case
end if;
end if;

This also reduces the complexity of the LUT.

Hope this helps.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
 
On Jan 25, 3:42 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,
Click to expand...
You might want to look into these 'weird things with the clock' a bit
deeper.

Some other points to ponder
1. Do you have multiple clocks in your design? If so...
1a. When you did the timing analysis do you have the tool set up to
analyze *across* clock domains?
1b. Based on the timing report of clock domain crossings, are each and
every crossing handled correctly?

2. Check power. With the BGA and suspect soldering it will be
impossible to verify whether good power is making it to the die, but
maybe there is a power issue with the board that can be seen with the
scope.

3. Check input clock signal integrity

4. Since you're using DCM, does that allow you to bring out some form
of 'locked' output to indicate that the DCM is locked on to the input
clock properly? If so, bring it out and see if the DCM ever comes
'unlocked'. Alternatively, bring the DCM clock output to an output
pin. The point of this exercise is to check that the FPGA clock is
actually working properly. If it's not, then your problem is rooted
in #2 or #3.

3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
Click to expand...
The root cause of different behavior will be:
- Power supply to the part
- Timing (which includes clock domain transfers as mentioned above)
- Assembly issues (which you currently suspect)

Kevin Jennings
 
Emanuele83 <emanuele83katamail@googlemail.com> wrote:

Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz
Click to expand...
IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
Click to expand...
This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Jan 25, 2:22 pm, KJ <kkjenni...@sbcglobal.net> wrote:
On Jan 25, 3:42 am, Emanuele83 <emanuele83katam...@googlemail.com
wrote:

My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,

You might want to look into these 'weird things with the clock' a bit
deeper.

Some other points to ponder
1. Do you have multiple clocks in your design?  If so...
1a. When you did the timing analysis do you have the tool set up to
analyze *across* clock domains?
1b. Based on the timing report of clock domain crossings, are each and
every crossing handled correctly?

2. Check power.  With the BGA and suspect soldering it will be
impossible to verify whether good power is making it to the die, but
maybe there is a power issue with the board that can be seen with the
scope.

3. Check input clock signal integrity

4. Since you're using DCM, does that allow you to bring out some form
of 'locked' output to indicate that the DCM is locked on to the input
clock properly?  If so, bring it out and see if the DCM ever comes
'unlocked'.  Alternatively, bring the DCM clock output to an output
pin.  The point of this exercise is to check that the FPGA clock is
actually working properly.  If it's not, then your problem is rooted
in #2 or #3.

3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

The root cause of different behavior will be:
- Power supply to the part
- Timing (which includes clock domain transfers as mentioned above)
- Assembly issues (which you currently suspect)

Kevin Jennings
Click to expand...
thank you Kevin,

I do apologise, I did not finished the sentence about what my boss
does with his SPARTAN.
I would mean that, as old school, he use no debugger, no constraints,
he is getting the clock from a non-clk dedicated pins, adding buffers
just to delay signals until they working with the external
interfaces.. and the design works as expected (by him). my design,
though well written, and constrained, does not work as expected... It
is due, maybe, to my lack of experience....

My system has only one clock, now at 40MHz. For example I just changed
the constraints of IO pins drive strength from 8 to 6 being more
conservative and the behave changes...
I have already checked the DCM locked pin addressing it on a
testpoint, but it is always locked.
The clock signal was my first test. I modified the path and now goes
freely with a wire directly to the clock tree, there were some logic
on the clock path distorting the signal, and I bypassed it.

I'll try to check the power lines with an oscilloscope to check if
there are bounces...
 
On 25 Jan., 15:06, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
On Jan 25, 2:22 pm, KJ <kkjenni...@sbcglobal.net> wrote:
On Jan 25, 3:42 am, Emanuele83 <emanuele83katam...@googlemail.com
wrote:

My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,

You might want to look into these 'weird things with the clock' a bit
deeper.

Some other points to ponder
1. Do you have multiple clocks in your design?  If so...
1a. When you did the timing analysis do you have the tool set up to
analyze *across* clock domains?
1b. Based on the timing report of clock domain crossings, are each and
every crossing handled correctly?
[..]

My system has only one clock, now at 40MHz. For example I just changed
Click to expand...
Your description ring my "clock domain" alarm bell.
You should ensure that every clock domain crossing is right, which
implies that you first need to identifiy all different clock domains.
Every input that is not synchron to your clock and proper constraint
is a different clock domain which requires appropriate handling of
these inputs. Internal clocks on the same frequency can form different
clock domains in case clock tree is splitted. This is easy seen in
netlist but sometimes not obvious in RTL code.

bye Thomas
 
On 1/25/2011 6:36 AM, Thomas Stanka wrote:

Your description ring my "clock domain" alarm bell.
You should ensure that every clock domain crossing is right, which
implies that you first need to identifiy all different clock domains.
Every input that is not synchron to your clock and proper constraint
is a different clock domain which requires appropriate handling of
these inputs. Internal clocks on the same frequency can form different
clock domains in case clock tree is splitted. This is easy seen in
netlist but sometimes not obvious in RTL code.
Click to expand...
Or maybe there is a stray latch or asych process hiding somewhere...


-- Mike
 
On Jan 25, 6:53 am, Mike Perkins <s...@spam.com> wrote:
On 25/01/2011 10:31, Emanuele83 wrote:



On Jan 25, 11:23 am, "Nial Stewart"
nial*REMOVE_TH...@nialstewartdevelopments.co.uk>  wrote:
I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....

You need to find an assembly house with a Vapour Phase reflow oven, from
what I understand (from my assembly guys) this almost guarantees a good
result.

Even without this BGAs are pretty run of the mill, any competent assembly
house should be able to get this down.

Are you going to a quality assembly house or the cheapest one?

Nial

I do not know if it is the cheapest one. I know only that they are
soldering with IRs reflow.
I am not the one in the office who has the choice... Now we sent a
board to be reworked and new FPGAs will be soldered.
The point is that if they do it with the bad temp profile I am afraid
that the FPGA can be damaged...

My experience is that as long as the profile is sufficient for solder to
flow, and with a quality paste, it's unusual for things to go wrong.  I
have also found from building prototypes in-house that whilst going over
temperature is not disasterous, though may affect long term reliability.

Do you have a backup of an old snapshot of your design?  Can you check
the PCB works in the same way it did when the snapshort was taken?

Whilst a 80 MHz clock is low, there are a myriad of reasons why a design
change may stop the FPGA from funtioning as exected.  I assume you have
checked the design will work with the specified clock rate?  There maybe
issues with simulatenous switching, or through compromised decoupling.

Personally I would use, and I beleive its more conventional for:

histogram_calculation_process : process (clk_120)
begin
   if rst = '1' then -- not reset
      state_m_1 <= idle;
   elsif clk_120'event and clk_120='1' then -- clk rising edge
       case state_m_1 is
         when idle =
               A_tcspc <= input_a;
               B_tcspc <= input_b;
               state_m_1 <= state_1;
         when state_1 =
              output_sum <= S;
               state_m_1 <= idle;
         when others => null;
       end case
    end if;
end if;

This also reduces the complexity of the LUT.
Click to expand...
I can't believe you opened that can of worms. The OP's reset is
synchronous and your reset is asynchronous. Async reset are fine if
you know how to bring the circuit out of reset. But if you just let
every part of your design leave async reset without coordination, it
can start off in an invalid state due to the different parts starting
off on different edges of the clock.

With a sync reset, if it meets timing, it should run ok.

Rick
 
On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote:
Emanuele83 <emanuele83katam...@googlemail.com> wrote:
Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.
Click to expand...
That is one of the things I have always felt was lacking, a way to
verify timing constraints. I've talked to FPGA vendors and their
attitude is just that an engineer should be able to write the
constraints correctly, period. No need to verify! Boy, that goes
against everything I've ever learned about engineering. You can have
problems with ANY part of a design. Being able to verify all aspects
of your design is much better than "testing". Testing can prove the
existence of faults, but it can't prove the absence... at least not
without a LOT of effort and analysis. In fact, testing is a lot like
constraints, you have to do it "right" and how do you prove that you
have done the testing "right"?

Rick
 
On Jan 26, 6:44 am, rickman <gnu...@gmail.com> wrote:
On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote:









Emanuele83 <emanuele83katam...@googlemail.com> wrote:
Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

That is one of the things I have always felt was lacking, a way to
verify timing constraints.  I've talked to FPGA vendors and their
attitude is just that an engineer should be able to write the
constraints correctly, period.  No need to verify!  Boy, that goes
against everything I've ever learned about engineering.  You can have
problems with ANY part of a design.  Being able to verify all aspects
of your design is much better than "testing".  Testing can prove the
existence of faults, but it can't prove the absence... at least not
without a LOT of effort and analysis.  In fact, testing is a lot like
constraints, you have to do it "right" and how do you prove that you
have done the testing "right"?

Rick
Click to expand...
Holy words, fellow, holy words! :)

I'll test the Power supply section today, but for example setting
lower drive strength of output drivers to be conservative in power,
the behaviour changes... Ok when I modify the drive strength also the
delay of I/O clocks changes, but, damn it, I am working at 40Mhz and
the constraints are met!
 
On Jan 26, 6:44 am, rickman <gnu...@gmail.com> wrote:
On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote:









Emanuele83 <emanuele83katam...@googlemail.com> wrote:
Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

That is one of the things I have always felt was lacking, a way to
verify timing constraints.  I've talked to FPGA vendors and their
attitude is just that an engineer should be able to write the
constraints correctly, period.  No need to verify!  Boy, that goes
against everything I've ever learned about engineering.  You can have
problems with ANY part of a design.  Being able to verify all aspects
of your design is much better than "testing".  Testing can prove the
existence of faults, but it can't prove the absence... at least not
without a LOT of effort and analysis.  In fact, testing is a lot like
constraints, you have to do it "right" and how do you prove that you
have done the testing "right"?

Rick
Click to expand...
Holy words, fellow, holy words! :) We use more time to writing the
correct test (that must be done carefully) than to design the logic...

I am going to test the power supply section, but I've already tested
yesterday that compiling the same code, setting the drive strength of
I/Os to a safer value (from 6 to 2) the behaviour of the system is no
more consistent. I left all the timing constraints unchanged, always
met, @40Mhz speed, but it does not work....
 
With a sync reset, if it meets timing, it should run ok.
Click to expand...

I have had it confirmed that if you generate a reset synchronously then use it
'asynchronously' in the standard process template (VHDL) that Quartus knows it's
a synchronous signal and all timing analysis is correctly handled.


Nial.
 
<snip>

2_ I find sometimes this WARNING in the map log:
Pack:266 - The function generator inst_arbiter_core/hist_box_ch_0/
state_m_1_FSM_Out21 failed to merge with F5 multiplexer
inst_arbiter_core/hist_box_ch_0/i_FSM_FFd2-In21_f5. There is a
conflict for the FXMUX. The design will exhibit suboptimal timing.
I am not able to link it to the abnormal behaviour yet, but i found no
explanation in the Xilinx website. Does somebody know something about
it?
I usually use some VARIABLES in my processes, also in the state
machine which gives the PACK:266 error. they are not SHARED VARIABLES
and are modified only synchronously, but sometimes i use them as a
trick to save some clock cycles of latency (implementing real
instantaneous assignments). Is a practice that should be avoided in a
good VHDL code?
Click to expand...
Post that code!


---------------------------------------
Posted through http://www.FPGARelated.com
 
On Jan 26, 8:45 am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
On Jan 26, 6:44 am, rickman <gnu...@gmail.com> wrote:









On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote:

Emanuele83 <emanuele83katam...@googlemail.com> wrote:
Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

That is one of the things I have always felt was lacking, a way to
verify timing constraints.  I've talked to FPGA vendors and their
attitude is just that an engineer should be able to write the
constraints correctly, period.  No need to verify!  Boy, that goes
against everything I've ever learned about engineering.  You can have
problems with ANY part of a design.  Being able to verify all aspects
of your design is much better than "testing".  Testing can prove the
existence of faults, but it can't prove the absence... at least not
without a LOT of effort and analysis.  In fact, testing is a lot like
constraints, you have to do it "right" and how do you prove that you
have done the testing "right"?

Rick

Holy words, fellow, holy words! :) We use more time to writing the
correct test (that must be done carefully) than to design the logic...

I am going to test the power supply section, but I've already tested
yesterday that compiling the same code, setting the drive strength of
I/Os to a safer value (from 6 to 2) the behaviour of the system is no
more consistent. I left all the timing constraints unchanged, always
met, @40Mhz speed, but it does not work....
Click to expand...

1_ I checked the power supply of the board. I fixed some minor stuff,
and I checked the layout. My colleague has forgot to split the power
plan for VCCAUX and VCC_0 so I thought that maybe the noise introduced
by switching I/Os on the VCCAUX could create problems with the DCMs
that I was using. take a look to the clock architecture:

http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/8738/1/dcm_arch.jpg

this was the one at the very beginning (at 80MHz) and now I changed
using the same DCM structure but with 40MHz (output of first DCM is
not clk_2x anymore) and everything now works with 40Mhz.
The second DCM has the only purpose to deskew the RAM chips (which
work at 40MHz now)

Thinking that the problem was on DCM's noisy power supply I just
removed the DCM and bypassed the 40 MHz clock input directly to the
ram output, the external feedback is no more used and the logic is
clocked directly with the external clock.
it seems better, but if I change the compiling settings (optimizing
for area and not for speed for example) the system does not work...
The design seems less affected from the settings modifications but it
is not yet stable, and the goal of 80Mhz is still far away :(

2_ I find sometimes this WARNING in the map log:
Pack:266 - The function generator inst_arbiter_core/hist_box_ch_0/
state_m_1_FSM_Out21 failed to merge with F5 multiplexer
inst_arbiter_core/hist_box_ch_0/i_FSM_FFd2-In21_f5. There is a
conflict for the FXMUX. The design will exhibit suboptimal timing.
I am not able to link it to the abnormal behaviour yet, but i found no
explanation in the Xilinx website. Does somebody know something about
it?
I usually use some VARIABLES in my processes, also in the state
machine which gives the PACK:266 error. they are not SHARED VARIABLES
and are modified only synchronously, but sometimes i use them as a
trick to save some clock cycles of latency (implementing real
instantaneous assignments). Is a practice that should be avoided in a
good VHDL code?


Thanks,
Emanuele
 
rickman <gnuarm@gmail.com> wrote:

On Jan 25, 9:48=A0am, n...@puntnl.niks (Nico Coesel) wrote:
Emanuele83 <emanuele83katam...@googlemail.com> wrote:
Good day to everybody,

Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

That is one of the things I have always felt was lacking, a way to
verify timing constraints. I've talked to FPGA vendors and their
Click to expand...
Sorry but the timing report and the timing analyzer provide that
information.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On 26/01/2011 12:52, Nial Stewart wrote:
With a sync reset, if it meets timing, it should run ok.


I have had it confirmed that if you generate a reset synchronously then use it
'asynchronously' in the standard process template (VHDL) that Quartus knows it's
a synchronous signal and all timing analysis is correctly handled.


Nial.
Click to expand...
Rick is correct, where generic code loses its portability, and not all
devices or manufacturers may have this property.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top