FPGA Configuration
4 messages · 2004-08-05 → 2004-08-12 · Yahoo Group era · View archive on archive.org
Participants: aralbrec, Jeff, Jeff Burrell
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
Jeff · Thu, 05 Aug 2004 20:52
Alvin;
There are several ways to go with configuring the FPGA. I agree
that having a method that allows the 2068 to do the reconfig would be
very handy. This would require some additional hardware to do.
Given the above, rethinking the whole config scheme might be in
order. It would be possible to use a 2Mbit serial flash such as an
AT45DB021B-SI ($2.64) and a PIC processor (about $5.00) to manage the
power on and configuration of the FPGA. The cost of the chips would
be about half of the cost of one of the AT17XXX configurators and
would be more flexible. There is already at least one oscillator on
the interface board, so clocking the PIC would not be a problem.
Specifically: the PIC processor would be programmed to configure
the FPGA on power up when a jumper was in a particular position. The
FPGA would use the passive serial mode for configuration. During
this configuration period, the 2068 would be held in RESET by the
PIC. When the FPGA was configured, the PIC would release the reset
and allow the 2068 to press on with its boot sequence. This would
address the problem of the 2068 trying to boot while the FPGA is
still configuring.
If the jumper was in a second position, the PIC would listen to its
own serial port for a command. One of these commands would be to
accept new data for the configuration flash - hence a way to update
the configurator from a PC. Other commands are possible and
desirable but yet to be determined.
It may also be possible for the PIC to monitor 2068 joystick port
as an alternate input channel. It would be simplest if this was done
with the 2068 unplugged from the interface so both could run in
standalone mode.
I would expect the PIC to only be programmed once upon board build
since it is effectively housekeeping logic.
This change would allow the use of much cheaper configuraion
devices, better management of the powerup sequence, and an easy
upgrade path for the FPGA firmware. It would take longer to
configure the FPGA, but probably not noticeable by the casual user.
2. Re: [ts2068] Re: FPGA Configuration
Jeff Burrell · Mon, 9 Aug 2004 14:57:
Using the AT45 series parts will require something like a PIC or device capable of holding a FSM since programming the FPGA should be as automatic as possible and we need a protocol converter to make the flash look like a configurator to the FPGA. A PIC is probably the best solution for this. As you have probably guessed, I'm trying very hard not to put yet another CPLD/GAL or whatever on the board but it looks like I may need to do so. It wouldn't be too hard to use an ATF1504 CPLD as an I/O port to allow the 2068 talk to the PIC for programming/control of the FPGA.
My biggest concern is that if the reprogramming of the flash is interrupted or messed up in such a way that an erroneous or unwanted configuration is in the flash, we need a way to prevent configuration of the FPGA and ensure that its pins are in a tristate condition so that it will not interfere with the 2068 bus. I suppose the simplest way would be to incorporate HCT245s in all of the lines and provide a jumper that would disable them during the flash programming process.
The chip count keeps increasing. :(
I've pretty much decided to bag the USB functionality in the basic interface and make it an expansion board. I think that a codec and optional ethernet/coprocessor would be more useful. Besides, along with the PS2 keyboard/mouse and serial ports, there is more than enough hardware to keep us busy for quite a while.
aralbrec <[email]> wrote:
--- In [email], "Jeff" <jburrell7@y...> wrote:
> Given the above, rethinking the whole config scheme might be in
> order. It would be possible to use a 2Mbit serial flash such as an
> AT45DB021B-SI ($2.64) and a PIC processor (about $5.00) to manage
the
> power on and configuration of the FPGA. The cost of the chips
would
> be about half of the cost of one of the AT17XXX configurators and
> would be more flexible.
I am quite surprised by the cost difference -- I only
looked at the configurator memories and assumed the
AT45xx was the same price for the same size.
> There is already at least one oscillator on
> the interface board, so clocking the PIC would not be a problem.
An external oscillator might be a problem when
the board is held in reset (reset / unconfigured
ics may not make the clock available on an output
pin), unless the PIC had its own oscillator or even
an RC oscillator. Even better, it could use the
2068/Spectrum/C64's own clock. The clock should be
generated while the computer is held in reset.
The PIC is cheap and flexible so has a lot going
for it, but there are some negatives too. It
won't be fast enough to interface to the z80 as
an i/o peripheral and you've suggested using
the PIC serial interface instead. You've got
to find two wires for that. There is one on
the expansion connector -- IOA5 -- that comes
from the AY chip. A second one is not available
without either more hw or addition of a physical
wire from the joystick port to the expansion
board. You are also locking yourself into the
2068 hw by doing this. I don't know if the C64
has spare lines on its connector but the Spectrum
doesn't have any (or a Joystick port).
The GAL solution is a few bucks more but it
can sit on the bus as an i/o peripheral. I
would lean towards this but only after the
logic has been shown to fit into an inexpensive
part. Using the AT45xx (a good idea) would
require more flip-flops than the configurators
in order to follow the opcode programming sequence
to start streaming out the bits to the fpga.
When not in the configuring mode, the GAL can
just pass along single-bit commands/data
from the z80 through an i/o port.
Alvin
Yahoo! Groups SponsorADVERTISEMENT
---------------------------------
Yahoo! Groups Links
To visit your group on the web, go to:
http://groups.yahoo.com/group/ts2068/
To unsubscribe from this group, send an email to:
[email]
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
---------------------------------
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
3. Re: FPGA Configuration
aralbrec · Mon, 09 Aug 2004 18:57
--- In [email], "Jeff" <jburrell7@y...> wrote:
> Given the above, rethinking the whole config scheme might be in
> order. It would be possible to use a 2Mbit serial flash such as an
> AT45DB021B-SI ($2.64) and a PIC processor (about $5.00) to manage
the
> power on and configuration of the FPGA. The cost of the chips
would
> be about half of the cost of one of the AT17XXX configurators and
> would be more flexible.
I am quite surprised by the cost difference -- I only
looked at the configurator memories and assumed the
AT45xx was the same price for the same size.
> There is already at least one oscillator on
> the interface board, so clocking the PIC would not be a problem.
An external oscillator might be a problem when
the board is held in reset (reset / unconfigured
ics may not make the clock available on an output
pin), unless the PIC had its own oscillator or even
an RC oscillator. Even better, it could use the
2068/Spectrum/C64's own clock. The clock should be
generated while the computer is held in reset.
The PIC is cheap and flexible so has a lot going
for it, but there are some negatives too. It
won't be fast enough to interface to the z80 as
an i/o peripheral and you've suggested using
the PIC serial interface instead. You've got
to find two wires for that. There is one on
the expansion connector -- IOA5 -- that comes
from the AY chip. A second one is not available
without either more hw or addition of a physical
wire from the joystick port to the expansion
board. You are also locking yourself into the
2068 hw by doing this. I don't know if the C64
has spare lines on its connector but the Spectrum
doesn't have any (or a Joystick port).
The GAL solution is a few bucks more but it
can sit on the bus as an i/o peripheral. I
would lean towards this but only after the
logic has been shown to fit into an inexpensive
part. Using the AT45xx (a good idea) would
require more flip-flops than the configurators
in order to follow the opcode programming sequence
to start streaming out the bits to the fpga.
When not in the configuring mode, the GAL can
just pass along single-bit commands/data
from the z80 through an i/o port.
Alvin
4. Re: FPGA Configuration
aralbrec · Thu, 12 Aug 2004 19:30
--- In [email], Jeff Burrell <jburrell7@y...> wrote:
> Using the AT45 series parts will require something like a PIC or
device capable of holding a FSM since programming the FPGA should be
as automatic as possible and we need a protocol converter to make the
flash look like a configurator to the FPGA. A PIC is probably the
best solution for this. As you have probably guessed, I'm trying
very hard not to put yet another CPLD/GAL or whatever on the board
but it looks like I may need to do so. It wouldn't be too hard to
use an ATF1504 CPLD as an I/O port to allow the 2068 talk to the PIC
for programming/control of the FPGA.
The FSM only needs about 75 states (I've already worked this out)
and therefore 7 flip-flops. This easily fits into a GAL part
(and maybe an ATF1504? I'm not familiar with the part).
The logic equations to drive the fpga clock, AT45 clock, etc
can be made very simple if the states are numbered carefully.
The AT45 in SPI mode 0 and fpga slave-serial mode are almost
made for each other -- the GAL can use the 2068 clock to drive
the configuration; the fpga latches the incoming serial bit
on the rising edge of the clock and the AT45 puts out a new
bit just after the falling edge so you can simply connect SO
of the AT45 to DIN of the fpga. After the configuration,
the GAL can have three registers output SI, SCLK and nRESET
connected to the AT45. These 3 bits can be mapped into the
z80 i/o space so that writes to this port can 'bit-bang'
the AT45. Reads can return the states of SO, BUSY/nREADY
and maybe something from the FPGA (like DONE to indicate
a successful configuration). The logic to manage this
i/o port is also small and can fit into the GAL. What
will determine the size of the GAL is the number of output
pins required -- the 7 flip-flops of the state machine
consumes one output pin each on the cheap parts without
buried macrocells.
The fpga takes 2ms to power up, the AT45 can't be touched
for 20ms and the 2068 will take > 350ms. The GAL can
wait until the 2068 reset line goes high before proceeding
with the configuration and then drive the reset pin low
to keep the 2068 in reset during configuration. This way
the GAL can keep the AT45/fpga lines in a neutral state
before they wake up and you can be sure there is a stable
clock coming from the computer before the configuration
begins.
I'm probably the opposite of you -- I see the PIC as
overkill (a large CPLD worse) but I can't argue against
its price so that stance doesn't hold water. But the
requirement of a serial interface to the computer can't
be accommodated without additional hardware so that's
the main reason I don't like it. Being able to map
the configuring device into i/o space also makes it
a lot easier to use and probably more portable across
different z80 systems. On the 6502 it would have to be
memory mapped, but I do believe the C64 has a separate
bank of non-RAM memory space for devices?
> My biggest concern is that if the reprogramming of the flash is
interrupted or messed up in such a way that an erroneous or unwanted
configuration is in the flash, we need a way to prevent configuration
of the FPGA and ensure that its pins are in a tristate condition so
that it will not interfere with the 2068 bus. I suppose the simplest
way would be to incorporate HCT245s in all of the lines and provide a
jumper that would disable them during the flash programming process.
> The chip count keeps increasing. :(
The fpga does a CRC check after configuration and will
not boot up if there is an error -- I think this is
sufficient protection. No extra buffering is needed :-)
If the fpga can drive TTL signals directly I see no
reason to have any buffers at all -- just connect the
fpga directly to the 2068 expansion bus. The GAL (or
whatever drives the configuration) and the 512kx8 flash
can also sit directly on the 2068 bus. The 512kx8 flash
is still needed even if there is room to spare in the
AT45 as the AT45 can't be mapped into the z80 memory
space and the flash is where the boot-up / operating
system code will sit.
> I've pretty much decided to bag the USB functionality in the
basic interface and make it an expansion board. I think that a codec
and optional ethernet/coprocessor would be more useful. Besides,
along with the PS2 keyboard/mouse and serial ports, there is more
than enough hardware to keep us busy for quite a while.
Oooh -- leave it in :-) I think the board should be designed
to accommodate the USB, ethernet, 512kx8 flash, RAM (SIMMs or
whatever), AT keyboard port, PS/2 mouse port, TL16C552 for
2xserial + 1 parallel port, IDE, DAC/ADC. I would be in favour
of having the board optionally populated as budget allows;
this would depend a lot on how easy it would be for an
end-user to populate it. If sockets could be used for
optional parts, that would be best. I know this is asking
a lot and will result in a project that takes a long, long
time to get in an advanced state but this is the kind of
project that would stir up interest, particularly if it
could be simply modified for a number of systems. If you
need a chearleader, here I am :-)
There also has to be a means for expansion and I'm not
clear on how you've planned to do that yet. I would like
to see all the parts above connected directly to the fpga
and not to an intermediary bus -- I think there is enough
pins for that and this would allow some fancy DMA
to go on. I'm still thinking about the SIMMs as they
will slow down the system quite a bit and have been
toying with the idea of some kind of cache in SRAM.
For a VGA interface, I think you'll need
a dedicated port connection to the fpga. For slower
peripherals there could be an expansion bus connected to
the fpga and perhaps connectors on the expansion board to
plug them into.
I also favour the ethernet chip solution to the
ZWorld cpu solution for ethernet. Writing a TCP/IP
stack is something that will take time but I'm up
for it. I also think it's unavoidable as I'd like
to eventually see a serial fax/modem attached via the
serial port. It's my view that with the VGA card
and the ZWorld CPU, you might as well disconnect
the 2068 and have a standalone computer. Of course
that's just me and some people will like the idea of
a "super-cpu" project for a Spectrum just like some
people like it for the C64.
In conclusion, the ZWorld option will have
ethernet access for a 2068 available quickly;
the other way will take a long time but will
be a learning experience. Can we have both
options :-) ?
Alvin