[hpsdr] Ozy Problem

[Ray Anderson]

While the speed figures that Scott dug up in the cyclone II data book
seem to be pretty fast on the service, they really don't tell the whole
story.

I'm sure the codewriters have looked at this issue in the past, but
perhaps a second look is in order regarding the Ozy post-routing timing
margins.

>From the comments posted on the list recently it sounds like the C7
(fast) chips don't seem to exhibit the reported issues, while the C8
(slower) ones do sometimes. If there is a datapath with marginal timing
margins it could cause intermittent and/or random failures such as are
being observed.

Could be a red-herring, but then again, maybe not...

There is enough brainpower available on this project that I'm sure the
root cause will be discovered before long. Thanks to all the volunteers
who have put in their time and expertise to get us where we are today.

Regards,

-Ray  WB6TPU






Scott Cowling wrote:
----------------------------------------
OK, here's the real story dug up from the paper archives.

Due to our supplier's inability to deliver enough Altera FPGAs in 
time for us to complete the Ozy build prior to Dayton in 2007, we 
purchased FPGAs from three different vendors.

162 of them were C7 speed grade
495 of them were C8 speed grade

Notice that the total is 657 even though we built only 650 boards. 
This allows a couple of spares.

So, up to 162 boards out there in HPSDR-land have the faster chip on 
them. Before you get to thinking that your board is better because 
you have the faster chip (or worse due to the slower chip), here are 
some figures for you from the Altera Cyclone II handbook regarding
performance:

16-bit counter, f(max)
C8:  310.65MHz
C7:  349.4MHz

18x18 multiplier, f(max)
C8:  180.57MHz
C7:  216.73MHz

8-bit, 16-tap FIR filter, f(max)
C8:  110.57MHz
C7:  131.25MHz

Maybe Kirk can comment, but I don't think we are anywhere close to 
the f(max) limits on anything we do in Ozy. Of course, that does not 
mean that there isn't a bug that a faster FPGA "fixes".

Just like putting 667MHz SDRAM on your PC bus that runs at 533MHz, a 
faster FPGA does not run any "faster" just because it is a C7 instead 
of a C8. It only has to be "fast enough" to keep up with the clock 
given the internal logic that is programmed into it.

It would be informative to see if anyone has a C7 FPGA that exhibits the
bug.

Also note that FPGAs run marginally slower when they are hot. If the 
problem is right on the edge, that might explain why the boards work 
for a while and then degrade after they heat up.

Welcome to the "fun" world of FPGA debug! Hope this is somewhat helpful.

73,
Scotty WA2DFI
----------------------------------------------


 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



 1244150734.0