we have seen this problem before -
a clock glitch causes an unrecoverable error -
as far as i know, it's the nature of xilinx's fpga's,
and there's nothing that can be done on an ibob
except keep the clock clean.
dan
The distressing thing about this problem is that it renders the iBOB
unusable until the Prog button is pushed, or the power is cycled. I
intend to use my iBOB unattended with many different designs running
at different clock frequencies, but now I am concerned that a clock
glitch could require manual intervention. Does anyone have any
experience with this? iMPACT does not report any problems with
programming, but the PPC remains unresponsive.
On 5/30/08, *Dan Werthimer* <[email protected]
<mailto:[email protected]>> wrote:
hi glen,
i think if timing is violated on some parts of an fpga,
it can affect the configuration of other parts of the fpga design
(even though those parts are clocked correctly) and all
hell can break loose.
dan
Nope, I have added software in the past, but as soon as I
started having this problem, I have just been running default
builds.
Hmm, now it looks like this problem was due to the ADC clock
DCM not locking, because when I reduced the ADC clock to 400
MHz I was able to get the designs to run OK. Then when I
brought the ADC clock back up to 1024 MHz, the designs still
program and work OK. While I can understand jitter or other
effects causing timing problems with a design that
theoretically meets timing at these frequencies, what I do not
understand is why this would cause the PPC to not boot or give
any indication that it had booted at least. Doesn't it use the
100 MHz on board oscillator? It seems like the PPC would work
no matter what. Certainly when the ADC clock is disconnected,
I can still access the PPC. Any clues as to what could be
going on here?
Thanks again for the help,
Glenn
On 5/30/08, *David MacMahon* <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Have you added extra software in the new design that might be
locking up the PPC?
Dave
On May 30, 2008, at 11:37 , G Jones wrote:
Dave,
Thanks for the suggestion but I always make sure my designs
meet timing before I run them. I have also looked for any
differences in warnings during compilation and have not
seen
anything yet.
Glenn
On 5/30/08, David MacMahon <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote: Hi, Glenn,
The first place I would check is the timing report (or par
log) to make sure the new builds are meeting timing.
Dave
On May 30, 2008, at 11:14 , G Jones wrote:
Hello,
I expect the only way I'll solve this is through careful
experimentation, but I wanted to check to see if anyone had
any tips on what might be going on with my iBOB
designs. A few
days ago, I started having trouble where when I
compiled and
downloaded a design to the iBOB, "Nothing" would
happen, that
is no output from the serial port, no response from
LWIP, but
the LEDs generally behaved as expected for the design.
Here is
what I know:
The board still seems to work fine: When I press the "prog"
button, it successfully loads the design stored in the
PROM.
Also when I load an older design from a few weeks ago,
it runs
without trouble.
However, once I load a newly compiled design I get this odd
behavior where the serial port and ethernet ports are
unresponsive. Once this happens, if I try to load another
design which worked before, the ports remain unresponsive
until I press the "prog" button, after which old
designs work
fine again.
When I compile a simple design that basically just connects
the ADC to a snap64 block, I can download and run it just
fine. However, recompiling a more complicated design like a
spectrometer leaves the iBOB unresponsive. A bit file
from the
same design compiled a while ago still runs fine on the
iBOB.
I just noticed that the newly compiled spectrometer
design is
not drawing as much current as the originally compiled,
working version.
Any clues as to what I could have messed up with my
tool flow?
I wonder if I accidentally installed a new conflicting
version
of cygwin or something like that which is generating
corrupt
bit files.
Thanks,
Glenn
