FPGA Configuration Redux
1 message · 2004-08-15 → 2004-08-15 · Yahoo Group era · View archive on archive.org
Participants: Jeff
Preserved from the Timex/Sinclair 2068 Yahoo Group (2001–2019), which is no longer online. Text reproduced from the archive.org archive; email addresses masked.
Messages
1. FPGA Configuration Redux
Jeff · Sun, 15 Aug 2004 23:01
Alvin;
I understand your points on the FPGA configuration issue. An
AT1504 is a 64 cell CPLD from Atmel that is compatible with the
Altera EPM7064. I was looking at these parts because they can be had
in a number of packages and have the density and pin counts needed
for both the Z80 bus interface as well as the FSM. They may be more
part than we need but I have found that you can more easily lock the
pins if you have a more capable part.
My best guess on pin count goes something like this:
A[0..7], nIORQ, nRD, nWR, A[0..3], nRST, Clk - 17 pins
Flash - 5 pins.
FPGA control pins: 4
I assume we program the IO addresses into the part so no pins are
needed for IO address mapping.
Total pins: 26 plus whatever I haven't thought of. A 44 pin TQFP
package would probably be fine for this. This is the main reason I
haven't been thinking in terms of a GAL or some other small part -
not enough pins.
My concerns about mucking up the configurator had more to do with
the resources the FPGA manages being unavailable or the FPGA locking
up the 2068 rather than it being mis-configured per-se. For
instance, in the process of expanding the FPGA functionality someone
may get the logic for the FPGA data bus interface wrong (or worse,
drive the Z80 address/control lines) and cause massive contention
with the Z80 and preventing the 2068 from operating. At that point,
how do you recover? You can't use the 2068 to reprogram the FPGA and
if you remove the interface from the 2068 connector you can't
communicate with the interface.
This is why I suggested inserting '245s in the lines going to the
FPGA. The would effectively isolate an errant FPGA so there would be
a recovery mode available. We could use a few spare pins and logic
from the CPLD to help manage this. Since the CPLD would presumably
be "known-good" logic we can hang it directly on the 2068 bus.
As to busses and such. A 208 pin package gets allocated pretty
quickly. The 2068 bus needs about 30 lines, the DRAM interface about
20, AC'97 control, any expansion interface, and the on-board
peripherals, and the IDE. Basically, the IDE and on-board
peripherals end up sharing a bus. This may not be too bad, though
because we can still interleave access to keep the speed up.
A Z80 bus access is at least 3 clock cycles, so at 4MHz that is
750nS. If the FPGA state machine can do a 100nS memory cycle
(assuming 70nS or faster DRAMS), there is time for 6 accesses before
the Z80 is back for more data. We probably won't get more than 4
memory/IO accesses per Z80 access due to asyncronicity between the
2068 and the interface, but that should still be sufficient.
One implementation would be a FSM that would have N memory access
slots. Whenever the Z80 needs access to main memory, the FSM would
complete the current access and process the Z80 memory request. This
can be done in 100nS by having a one byte read/write memory buffer in
the FPGA. On writes, the Z80 address and data would be written to
the buffer and the FSM would then write it to main memory during the
next slot. A Z80 read would would alert the FSM to do a main memory
read during the next memory access slot and deposit the value into
the memory buffer where it would be available when the Z80 needs it.
This would gives the Z80 access to the main memory bus without
slowing the bus.
Whenever the Z80 is not accessing memory, the FSM would be
shuttling data between the various on-board peripherals and the
YABUS/second expansion bus peripherals.
I would recommend that the Z80 never directly access any of the
peripherals for data access but only for peripheral configuration.
If the Z80 exclusively worked through memory buffers and an interrupt
scheme it would greatly increase overall system throughput because
the DMA engine would be much faster than the Z80 at moving data
around.
As to the USB/Ethernet peripherals. I guess the real issue here is
make/buy and the cost of the blank PCB. The biggest problem is the
needed surface area for all of the components. The AD1885 codec
needs a lot of room for the associated passive components and
connectors. The other devices are not as bad, but the components
still need a home on the board. I was targeting a blank PCB cost of
$35.00. This would put the codec and ethernet (in the RCM3700) on
the main board with the USB on the expansion bus.
If the USB and a separate ethernet controller are put on the main
PCB I would probably would need to go to a $50.00 sized PCB. The
main advanatages in going to the RCM3700 for the ethernet are that it
is field installable, it has a fast Z80 style processor for co-
processing, and it can offload some of the ethernet management from
the 2068. Any ethernet chip would not be field installable as they
are mostly in QFP packages. Another option for the ethernet would be
to put it on a card using the expansion bus.
So, the short version of all of this is:
1. Work on a 2068 bus compatible CPLD/GAL/etc device to allow
programming the FPGA configurator via the 2068.
2. Ensure that a flaky FPGA can be isolated from the 2068 to allow
the above interface to work even with a bad FPGA.
3. Close in on the final partitioning of peripherals and where they
will reside.