<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
With reference to the Ozy problem with C7N & C8N parts, I had an
experience earlier this year that may relate. I had an Ozy/Janus/Atlas
working with a softrock and wanted to play around with the Ozy FX2
firmware and FPGA code. I downloaded and installed Eclipse and got it
running to recompile the FX2 firmware successfully. Then I downloaded
Quartus and the Ozy2_Janus2 project for the FPGA. It took me awhile to
get the .v code to compile without errors due to setup and
configuration problems, but I finally got it to work. I could then
successfully run initozy and both the firmware and FPGA code would load
OK but when I ran PowerSDR, I did not have a spectrum display or any
audio. I pursued the problem for quite awhile but was unable to
determine what was wrong. Finally, I was looking at the Quartus
settings (for the 100th time) and noticed there were two entries for
the Altera EP2C8Q208 FPGA. One had a suffix of C7N and the other C8N.
The EP2C8Q208C8N was selected by default. I checked the FPGA on my Ozy
board and it was a C7N, so I selected that in Quartus. The code
compiled and when I initialized Ozy and started PowerSDR everything
worked perfectly and has every since. I have subsequently added
Mercury and Penelopy and they have worked fine. My boards don't seem
to be position sensitive in Atlas.<br>
<br>
In my case, I was trying to compile for the C7N with C8N selected in
Quartus. I don't know what the effect would be if you compiled for the
C7N and then used the code with a C8N. Maybe someone that has a C8N
can pursue it. I don't know if any of this relates to the present
problem but I thought I should mention it.<br>
<br>
Doug - W8NFT<br>
<br>
<br>
<br>
<br>
----- Original Message ----- From: "Scott Cowling" <a
class="moz-txt-link-rfc2396E" href="mailto:scotty@tonks.com"><scotty@tonks.com></a><br>
<br>
<br>
<table class="header-part1" border="0" cellpadding="0" cellspacing="0"
width="100%">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Subject: </div>
[hpsdr] FPGA Speed Grade on Ozy</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">From: </div>
Scott Cowling <a class="moz-txt-link-rfc2396E" href="mailto:scotty@tonks.com"><scotty@tonks.com></a></td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Date: </div>
Wed, 03 Jun 2009 18:57:20 -0700</td>
</tr>
</tbody>
</table>
<table class="header-part2" border="0" cellpadding="0" cellspacing="0"
width="100%">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">To: </div>
<a class="moz-txt-link-rfc2396E" href="mailto:hpsdr@openhpsdr.org"><hpsdr@openhpsdr.org></a></td>
</tr>
</tbody>
</table>
<br>
OK, here's the real story dug up from the paper archives.
<br>
<br>
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.
<br>
<br>
162 of them were C7 speed grade
<br>
495 of them were C8 speed grade
<br>
<br>
Notice that the total is 657 even though we built only 650 boards. This
allows a couple of spares.
<br>
<br>
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:
<br>
<br>
16-bit counter, f(max)
<br>
C8: 310.65MHz
<br>
C7: 349.4MHz
<br>
<br>
18x18 multiplier, f(max)
<br>
C8: 180.57MHz
<br>
C7: 216.73MHz
<br>
<br>
8-bit, 16-tap FIR filter, f(max)
<br>
C8: 110.57MHz
<br>
C7: 131.25MHz
<br>
<br>
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".
<br>
<br>
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.
<br>
<br>
It would be informative to see if anyone has a C7 FPGA that exhibits
the bug.
<br>
<br>
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.
<br>
<br>
Welcome to the "fun" world of FPGA debug! Hope this is somewhat
helpful.
<br>
<br>
73,
<br>
Scotty WA2DFI
<br>
<br>
</body>
</html>