Re: [colorforth] ForthBox and FPGA

[Jecel Assumpcao Jr <jecel@xxxxxxxxxxxxx>]

On Monday 01 March 2004 21:08, Samuel A. Falvo II wrote:
> OK, now that I gave my rationale behind my decision for the ForthBox
> concept, let's explore some other options.  Let's *assume*, for this
> particular thread, that I can use FPGAs cost effectively, and that
> kit-builders wouldn't mind the soldering issues they raise.

It is possible to hand solder the quad flat pack chips, though not very 
easy. There used to be PGA and J-lead packages which could be socketed, 
but these seem not to be available anymore.

Thanks for the link.

> I raised objections in the other post.  But let's assume those
> objections have been resolved in favor of the FPGA solution.

I will address these here:

- The reason a kit with $20 of components sells for $280 is that not 
many are sold each year and yet they have to keep the company running.

- The free version of the software will be enough for your project and 
can run in Linux (under Wine in the current version, natively in the 
next one). The vendors restrict access to the low level details and say 
they do so to protect your designs from reverse engineering by others. 
Xilinx had a JBits tool in Java that could be used to get around this, 
but its distribution is a bit restricted and it only works with certain 
product families.

- I don't do simulations at all but instead use a dual trace analog 
osciloscope for all my debugging. It is an absolute joy to be able to 
reprogram the chip in a minute to bring different internal signals to 
the pins (instead of having to change the probes). You can see some 
pictures of the debugging (but the text is in Portuguese) at 
http://www.merlintec.com:8080/hardware/14

- The video signal uses a four resistor direct DAC, generating from 0 to 
1.6V on a 75 ohm load in 0.1V steps. A 54MHz counter is used to 
generate a pretty good 3.58MHz sine wave and that gives me about 130 
colors at 8 bits per pixel. The adaptation in the other page I 
mentioned added 8 more resistors to give 4096 colors on a VGA monitor. 
The sound, on the other hand, is generated via a single pin with a 
delta sigma (or PWM, as you called it) DAC.

- The SDRAM interface circuit does take up some space in the FPGA, but 
if you don't need much performance it is easy to do. Several examples 
on the web can make it look almost like a SRAM to the rest of your 
circuit. Even in single quantities, 8MB of 16 bit SDRAM costs less than 
$2. Smaller memories of older types are often much more than this. 
Anyway, this issue is independent of the FPGA one (which also have some 
internal SRAM - don't forget about that) since they easily interface 
with SRAMs if you want.

> How difficult would it be to put an Ethernet port in?  A USB host
> controller? 

It isn't quite as simple as this:

http://www.fpga4fun.com/10BASE-T0.html

You need at least proper buffer chips. The rest you can do in the FPGA 
itself, if it is large enough. See all the stuff that is already 
available at

http://www.opencores.org/browse.cgi/by_category

> One of my personal goals for my ideal ForthBox (which is
> not able to be addressed with the Kestrel design) is to connect it to
> my network to do IRC and e-mail access.  I don't want to use RS-232,
> because that doesn't eliminate my dependency on my PC.  And if it
> supports USB, then I see no reason to support dedicated PS/2 ports
> for the keyboard and mouse, nor for printers or other peripherals. 
> Even storage devices can be established as USB devices.

PS/2 ports are pretty easy to do. On my next machine I will have four 
USB 2.0 ports but that wasn't simple. The buffer chips only handle Full 
Speed and High Speed and yet a proper host interface must also handle 
Low Speed peripherals. My solution was to use a hub chip from Philips 
that connects to the FPGA via the PCI bus (a complication I had hoped 
to avoid). I will also be using a PCI Ethernet chip (and so no extra 
pins on the FPGA) which has the high level logic but costs almost the 
same as a simple buffer (phy) chip.

If you can use chips which at least are compatible with what ColorForth 
can handle you can save some development time. I have seen network code 
mentioned, but don't remember anything about USB.

-- Jecel

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com