FPGA changes behaviour when the resource's usage percentage

[Mike Perkins]

On 26/01/2011 14:09, Emanuele83 wrote:

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....


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

If the power supply is marginal in terms of noise, it may be worth
fixing the location of the DCM to a site on a quieter side of the FPGA.
It is something I've had to do when decoupling was not ideal, where
different compilations gave very different results similar to your
experience.

Have you looked at the 80MHz output pin using a 'scope? Is it clean?

When interfacing the logic from your "Rest of Logic" to the "Ext 40MHz
chip", how are you qualifying which edge of the 80 MHz clock the data
changes on?

I don't see any issue with using variables, shared or otherwise. I
would have thought synthesis would take out common logic where it feels
it can. One consequence of using variables in the manner you describe
would be more levels of logic, leading to a slower design. If timing
constraints are set correctly, then this ought not be an issue.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[Nial Stewart]

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.

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

Fair enough if the logic you're designing might be targeted at any manufacturers
devices.

I'm just confirming the case with the Altera tools that a synchronously
generated reset that's implemented as an apparently asycnchronous reset
is treated synchronously. Ie the reset trees are used instead of wasting
a valuable logic input to implement the reset.


Nial.