1 Dec
2005
1 Dec
'05
2:07 a.m.
I found why my PCTD 3 tape controller was defying my attempts to probe
it--the XC2064-50 FPGA seems to be dead as a doornail. Regardless of
signal inputs, it remains stubbornly inactive--i.e., my logic analyzer says
that none of the identifiable outputs changes state.
Since DMA and interrupt logic (as well as configuration) is contained in
the FPGA, attempting to read from any I/O port returned FF. A jumper
bypassing the FPGA for IO read, shows that the drive status lines are
indeed present and readable. Similarly, writing to the appropriate I/O
address causes the expected drive line to wiggle.
Since I don't need soft configurability (only for IRQ and DMA; the I/O
address is set via DIP switch), I may remove the FPGA and substitute some
TTL. I haven't decided yet.
But do old FPGA's just quietly go belly-up? Or is there something about
the XC2064-50 that I'm in the dark about? Are there any easy tests that I
can apply to confirm my suspicions?
Cheers,
Chuck
1 Dec
1 Dec
4:28 a.m.
"Chuck Guzis" wrote:
But do old FPGA's just quietly go belly-up? Or is there something about
the XC2064-50 that I'm in the dark about? Are there any easy tests that I
can apply to confirm my suspicions?
Doesn't it need to be 'loaded', either via a eeprom or the pcu?
Most older fpga's (I thought) had to be programmed at startup via some
form of bit-serial line. This is often something like an i2c eeprom
directly attached to the chip.
I have not looked that XC2 datasheet, however. (actually, I'm having trouble
finding one...)
-brad
7:20 a.m.
On Thu, 1 Dec 2005, Chuck Guzis wrote:
I found why my PCTD 3 tape controller was defying my
attempts to probe
it--the XC2064-50 FPGA seems to be dead as a doornail. Regardless of
signal inputs, it remains stubbornly inactive--i.e., my logic analyzer says
that none of the identifiable outputs changes state.
Since DMA and interrupt logic (as well as configuration) is contained in
the FPGA, attempting to read from any I/O port returned FF. A jumper
bypassing the FPGA for IO read, shows that the drive status lines are
indeed present and readable. Similarly, writing to the appropriate I/O
address causes the expected drive line to wiggle.
Since I don't need soft configurability (only for IRQ and DMA; the I/O
address is set via DIP switch), I may remove the FPGA and substitute some
TTL. I haven't decided yet.
But do old FPGA's just quietly go belly-up? Or is there something about
the XC2064-50 that I'm in the dark about? Are there any easy tests that I
can apply to confirm my suspicions?
Cheers,
Chuck
XC2064a are SRAM based FPGAs and _are_ inactive until their configuration is
loaded, Thats what I would check into... (configuration loading)
Peter Wallace
3:13 p.m.
I found why my PCTD 3 tape controller was defying my attempts to probe
it--the XC2064-50 FPGA seems to be dead as a doornail. Regardless of
signal inputs, it remains stubbornly inactive--i.e., my logic analyzer says
that none of the identifiable outputs changes state.
[I've never sued the XC2000 series, a lot of this is based on my
experiences with the XC3000s, but anyway)
I think the XC2000 series are old enough to be RAM based, that is they
have to load their configuration from some external device at power-on.
There are probably 2 ways (at least) to do this, either by connecting it
to an EPROM (whereupon the FPGA will generate sequential addresses to the
EPROM and read in the data) or by giving it a serial clock/data
bitstream, e.g. from a microcontroller or a special Xilinx serial ROM
chip.
You should be able to see some activity on the pins of the configuration
memory device (if, for example, it loads from EPROM and the addresses are
not changing, it's a fair bet that the FPGA has died). There may also be
a pin that changes state to say the thing has been configured, if there
is you could look at that one.
The good thing (for you) is that if the FPGA is dead, it's not a custom
or programmed part (the 'program' is in the external memory device), it
can thereofre be replaced fairly easily (but note that 'improved'
versions, with odd suffixes, may well not be compatible, and would need
diffeerent configuration data).
Since DMA and interrupt logic (as well as configuration) is contained in
the FPGA, attempting to read from any I/O port returned FF. A jumper
bypassing the FPGA for IO read, shows that the drive status lines are
indeed present and readable. Similarly, writing to the appropriate I/O
address causes the expected drive line to wiggle.
Since I don't need soft configurability (only for IRQ and DMA; the I/O
address is set via DIP switch), I may remove the FPGA and substitute some
TTL. I haven't decided yet.
Hang on, this thing isn't configured from the host computer is it (e.g.
by the device dricer loading a bitstream into the chip)? If it is, it
will appaer totally dead until that program's been run.
But do old FPGA's just quietly go belly-up? Or is there something about
Any chip can fail.... I've had XC3000s die.
-tony
5:36 p.m.
On 12/1/2005 at 11:13 PM ard at p850ug1.demon.co.uk wrote:
Hang on, this thing isn't configured from the host
computer is it (e.g.
by the device dricer loading a bitstream into the chip)? If it is, it
will appaer totally dead until that program's been run.
Uh huh--no E/EP/ROM on the board at all--just the XC2064 and a bunch of
TTL. It appears that the device driver loads the bitstream. Of course, I
don't have and can't locate the device driver.
I think it's time to pull out the soldering iron and get rid of the blasted
thing so I have something that I CAN program. It seems exceedingly
unlikely that a driver is going to materialize out of the aether at this
point.
Let this be a warning to anyone with a Chi Corporation/Computer Logics
Pertec tape controller--if you don't have the driver, you don't have
anything that can be easily used. Both the PCTD3 and the PCTD16 use
externally-loaded FPGAs.
Bummer.
Cheers,
Chuck
5:54 p.m.
Chuck Guzis wrote:
On 12/1/2005 at 11:13 PM ard at p850ug1.demon.co.uk
wrote:
Not even some little
8-pinner serial eeprom?
-Ryan Brooks
Hang on, this thing isn't configured from the
host computer is it (e.g.
by the device dricer loading a bitstream into the chip)? If it is, it
will appaer totally dead until that program's been run.
Uh huh--no E/EP/ROM on the board at all--just the XC2064 and a bunch of
TTL. It appears that the device driver loads the bitstream. Of course, I
don't have and can't locate the device driver.
6911
days inactive
6912
days old
6 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
brad＠heeltoe.com -
cclist＠sydex.com -
pcw＠mesanet.com -
ryan＠hack.net