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