Prev: EDK Simulation
Next: ModelSim Licence problem
From: radarman on 13 Feb 2006 23:28
I have a working prototype board from yesteryear with a Flex
10K100GC503-3 FPGA and an EPC2L120 configuration device on it. I
realize these are geriatric parts by todays standards, but if I can get
this board working, it will do what I need. Altera is no help -
pointing out that the part was EOL'ed in 1993.

This board definitely worked when it was put into storage, though I
used an older copy of MaxPlusII to program it at the time. I created
the EDIF files then using Synplicity 7.2.3. At that time, I had no
problem either programming the FPGA directly with the .sof or the EPC2
with the .pof. The JTAG chain is ridiculously simple, correctly pulled
up / terminated, and on a quality 4-layer board. We followed the app
note on adding a byteblaster port to a 'T'.

Now, for some reason, I am having intermittent problems programming
both devices. I am on a newer class machine (Pentium 4 vs Pentium III),
and I am attempting to use the free Quartus Webpack instead of
MaxPlusII - which, while it has a "free" license, doesn't include Flex
10K support.

I can manually specify the correct part in the Quartus .qsf file, and
the tool even correctly identifies the pins in the device settings.
(note - you can get "indirect" support for a lot of older parts this
way - Quartus just doesn't advertise them) Other than a slight problem
using conf_done as a general purpose I/O pin, it seems to all be
working. I have generated test applications that correctly exercise the
LEDs, switches and GPIO.

The problem is that when I try to download the bitstream, the
programmer gets between 50 and 79% done and errors out, reporting that
device 1 (the FPGA) CONF_DONE pin did not go high. Sometimes, though,
it will download correctly - and that is what is maddening. If it
didn't work at all, I would understand. More interesting, once it DOES
configure correctly once, it seems to work properly until I power down
the board.

Likewise, the EPC2 works sometimes, and fails others. I believe the
byteblaster is good, even if I did build it myself (I followed the
Altera ByteBlasterMV schematic faithfully) so I'm not sure what could
be causing this. Ironically, I did borrow a "real" ByteBlasterMV with
the *worse* results.

I have checked all the wiring in my byteblaster box, and it checks out.
The power supply voltages are spot on (5.04V for the FPGA, 3.34V for
the I/O buffers). My byteblaster has an LED indicator that shows when
the '244 is being driven, and I am definitely seeing activity.

Lastly, I have noticed that simple designs seem to download more
reliably than larger designs. Not sure why, as the programming file
should be of equal length either way (though there may be a lot of zero
padding in the smaller files)

Is there something I need to adjust in my PC's BIOS, Quartus,
elsewhere?

Any help greatly appreciated!

From: Hal Murray on 14 Feb 2006 03:48
>Lastly, I have noticed that simple designs seem to download more
>reliably than larger designs. Not sure why, as the programming file
>should be of equal length either way (though there may be a lot of zero
>padding in the smaller files)

Have you tried a scope on the clock/data lines?

Is this the same byteblaster you used back when it worked?
A newer PC might be a bit faster or there might be just a bit
more crosstalk on the cable or ...


--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

From: radarman on 14 Feb 2006 10:52
Hal Murray wrote:
> >Lastly, I have noticed that simple designs seem to download more
> >reliably than larger designs. Not sure why, as the programming file
> >should be of equal length either way (though there may be a lot of zero
> >padding in the smaller files)
>
> Have you tried a scope on the clock/data lines?
>
> Is this the same byteblaster you used back when it worked?
> A newer PC might be a bit faster or there might be just a bit
> more crosstalk on the cable or ...
>

Unfortunately, the project that the board was originally used for has
long since ended. The PC was leased, and has since been returned, and I
have no idea where the byteblaster we used then went.

That does remind me, though - we originally had a Byteblaster II, not a
Byteblaster MV. The original byteblaster used a slower '244 - LS family
I think. That *shouldn't* be a problem, but I can try swapping the
chip.

I will try looking at the signals on a scope. I'm kind of flying blind
without a scope at home, but I can take it to work and check out the
signals.

 | 
Pages: 1
Prev: EDK Simulation
Next: ModelSim Licence problem