Hello,

	I have used a FPGA module, XPS, microblaze, verilog etc for a personal  
project.
	This was very interesting and now, I am trying to design my own FPGA mini  
board.
	This is also a learning experience, and of course, because I like that  
stuff.
	It turns out to be very interesting.
	I have read lots of datasheets, app notes, etc to try to get it right.

	So, the question is, would experienced people be willing to spend a few  
minutes reviewing my schematics to tell me if I have some obvious errors ?
	What format should I use ? I use Eagle, so I can give Eagle files or  
plain PDF.

	Thank you,
	PF. Caillaud

PF,

If this was for a business, we (the FPGA Lab) do this, as a service at
Xilinx.  Companies send me their schematics in pdf format, along with
their board stackup (layer assignments, and thicknesses), and we review
them.

We do not promise anything (for guarantees, you would need to go to
Xilinx Design Services, and pay for a formal review with a formal
report), but we do our best to comment on the bypassing, configuration,
signal integrity, and whatever else we can see.

It is in our best interests that a pcb gets built, and works (parts get
ordered that way).

But for an individual with a hobby, we are unable to offer this service.
 Perhaps someone else will volunteer?

Good luck.

You may also want to look at pcb documentation for demo pcbs that are
available on our website:

http://www.xilinx.com/products/boards/files/ml401_2_3_schematics.pdf

is just one example.

Austin

On 2007-07-13, PFC <lists@peufeu.com> wrote:
> 	So, the question is, would experienced people be willing to spend a few
> minutes reviewing my schematics to tell me if I have some obvious errors ?
> 	What format should I use ? I use Eagle, so I can give Eagle files or  
> plain PDF.

If you posted a link to the PDF, people would probably look...

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

>> 	So, the question is, would experienced people be willing to spend a few
>> minutes reviewing my schematics to tell me if I have some obvious  
>> errors ?
>> 	What format should I use ? I use Eagle, so I can give Eagle files or
>> plain PDF.
>
> If you posted a link to the PDF, people would probably look...

	Obviously !
	I wanted to ask for the preferred format first, though.
	I have used FPGAs but this is the first time I design a FPGA board, so it  
would really be cool to have some "divine intervention" from the experts  
here to zap my bugs before they are comitted into copper.
	So, here is a PDF of the schematics :

	http://home.peufeu.com/nik/fpga/board_v01/schema.pdf

	Since the free version of Eagle supports only one schematic sheet, this  
isn't very printable (since everything is on one page !)... also, it  
somehow converted the text to vector. Duh.

	Anyway, this is a simple FPGA board with a Spartan 3E-500, 32 bit SDRAM,  
and a SMSC LAN9117 as network MAC+PHY.
	I went for simplicity so it has linear regulators ; and I didn't try to  
use the OpenCores MAC.
	This MAC chip has a nice interface and is supposed to be easy to program.  
Also drivers are available for happy hacking.
	I won't be using any OS since application is Ethernet streaming up to 100  
Mbps and the Linux TCP/IP overhead is way too large for poor Microblaze.
	SDRAM and MAC do NOT share a multiplexed bus since I want to be able to  
extract some good network performance from this design.

	Board layout needs to be done. This depends on the actual parts matching  
the Eagle libraries. Since I drew most of the large parts footprints from  
the datasheets, this means this will have to wait until I actually order  
and receive the parts from DigiKey, and put them into a laser printed  
paper version of the PCB to check alignment of the pins with the pads and  
holes. I hate it when the pins don't fit in the holes.

	And, the FPGA pin-swapping obviously depends on the routing. Which is  
waiting for the parts. Chicken and egg !

	Hence, in this schematic, all the address and data busses are not  
connected, and some signals too.
	Please do not look at this, since this is the easy part.
	Instead, I would really like some advice on the FPGA specific stuff,  
which is the hard part for me since it's the first time :

- did I route the clocks to the right pins so the DCMs are happy ?
- should the FPGA generate the clock to be sent through the connector or  
should I send the oscillator's output ?
- is the power supply OK ?
- will it really program itself from the flash as the datasheet says ?
- will my JTAG work ?
- is my Ethernet jack schematic and layout OK ?
- will it smoke ?
- will my SPI interface & prog_b jumper be enough to rescue a crapped up  
flash bitstream ?
- does it suck ?
- do I need to add resistors to the data lines ?

	Well I guess you get the idea ;) I will build a shrine to a guy nice  
enough to save me a PCB iteration !!!

	Thanks a lot,
	Pierre

On 2007-07-14, PFC <lists@peufeu.com> wrote:
>
> 	http://home.peufeu.com/nik/fpga/board_v01/schema.pdf

Normally I would illustrate the regulator (like your LT1764A) with the
required output cap right next to it, just to clarify which cap is
meeting the requirements of the regulator.  Considering the datasheet
dedicates about 3.5 pages to the output cap...

Also, I'd question your 220u on that rail.  Take a look at the datasheet
figure 9 -- it illustrates the performance of the 1.2V regulator with
different output cap networks.  Notice the 100u poly cap has a 35mOhm
ESR.  If your 220u is a plain old elecrolytic it's probably useless.

Offhand I'm not seeing where you get voltage rails like MAC_VDD_PLL,
but if they are other common voltages you should make semi-isolated
versions of them with cap-ferrite bead-cap.  If any of the key analog
voltages are your 3.3V (which you get from off-board) I'd strongly
consider making a special, clean 3.3V from some higher rail just for
that.

You might need a multi-voltage reset controller to avoid power sequencing
problems.  You'd have to check all the datasheets to see if they're
all tolerant of their rails coming up in the order produced by your
board.

Speaking of which, I wouldn't drive your MAC reset with FPGA_DONE.
Use a dedicated IO for it.  You can end up making it 'assign MAC_RESET=0'
but if you need it it will be changable.

Where you split your clk into CLK_OUT and FPGA_CLK, put a series R
on both legs.

> - will my JTAG work ?

You need some pullups there for when the jtag connector is not hooked
up.

> - will it smoke ?

Nah, if you make schematic errors it probably just "won't work", unless
your symbols have mistakes, in which case it might smoke.  ;-)

> - will my SPI interface & prog_b jumper be enough to rescue a crapped up  
> flash bitstream ?

Via what?  You'll be able to load bitstreams directly via JTAG no matter
what the state of the flash.

> - does it suck ?

It's probably going to cost you more than buying a dev board with
equivalent functionality.  But what would you learn from that??

> - do I need to add resistors to the data lines ?

You can always stuff them with 0R if you need to.  If your design rules
allow it, something like a CTS 742C083 series resistor array would be
easy to fit in the layout.  That package is basically 3 0603 resistors
side by side in one 1206 package.

Oh yeah, give yourself some pushbuttons to force reprogram, reset, etc.
And some LEDs.  You'll want something dead simple to do your initial
bringup tests.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

	Thank you very much for taking the time to have a look and give advice =
!

> Normally I would illustrate the regulator (like your LT1764A) with the=

> required output cap right next to it, just to clarify which cap is
> meeting the requirements of the regulator.  Considering the datasheet
> dedicates about 3.5 pages to the output cap...

	I was thinking about 10 uF X7R ceramic.

	Upon re-reading LT1764A datasheet I think a 100u low ESR / low Z (like =
 =

panasonic Special Polymer) in parallel with a 10u ceramic will be more  =

suitable ; with a trace of suitable length between the two to add a bit =
of  =

ESR to the ceramic cap so the regulator is happy.

> Also, I'd question your 220u on that rail.  Take a look at the datashe=
et
> figure 9 -- it illustrates the performance of the 1.2V regulator with
> different output cap networks.  Notice the 100u poly cap has a 35mOhm
> ESR.  If your 220u is a plain old elecrolytic it's probably useless.

	Thanks for pointing this one out !
	This cap was intended for the 3.3V main power supply actually, it's a  =

low-ESR type (computer motherboard switching regulator style).

	Correction : the cap now sits on the +3.3V rail.

> Offhand I'm not seeing where you get voltage rails like MAC_VDD_PLL,

	The MAC chip has internal regulators which take 3.3V and generate the  =

internal VDD_CORE, VDD_PLL, and friends.
	So, it just wants the help of external decoupling caps.

	Correction : Note added to schematic.

> but if they are other common voltages you should make semi-isolated
> versions of them with cap-ferrite bead-cap.  If any of the key analog
> voltages are your 3.3V (which you get from off-board) I'd strongly
> consider making a special, clean 3.3V from some higher rail just for
> that.

	The module will be fed from 3.3V from a supply connector (from testing)=
  =

or from carrier board (via Hirose connector).
	As the carrier board will have analog circuits I will make separate 3.3=
V  =

supplies for the FPGA module and for the ADC/DACs running from 3.3V.

> You might need a multi-voltage reset controller to avoid power sequenc=
ing
> problems.  You'd have to check all the datasheets to see if they're
> all tolerant of their rails coming up in the order produced by your
> board.

	Actually, 3.3V will come up, then 2.5V and 1.2V for the FPGA in an  =

undetermined order. From Xilinx datasheets this is OK.
	All the other chips (SDRAM, Flash, MAC) only feed from 3.3V so I think =
 =

this will be OK.

	I have set HSWAP to use pull-up resistors on all pins during config, so=
  =

the /CS, /RD, /WR etc won't be asserted.

> Speaking of which, I wouldn't drive your MAC reset with FPGA_DONE.
> Use a dedicated IO for it.  You can end up making it 'assign MAC_RESET=
=3D0'
> but if you need it it will be changable.

	You're right, you never know ;)
	Done.

> Where you split your clk into CLK_OUT and FPGA_CLK, put a series R
> on both legs.

	Done.

>> - will my JTAG work ?
>
> You need some pullups there for when the jtag connector is not hooked
> up.

	I never saw this in any of the schematics I studied... Well, I guess a =
 =

few SMD pullups aren't gonna cost me a lot !

>> - will it smoke ?
>
> Nah, if you make schematic errors it probably just "won't work", unles=
s
> your symbols have mistakes, in which case it might smoke.  ;-)

	My head still hurts from rechecking all the chip symbols twice from rhe=
  =

datasheets ;)

>> - will my SPI interface & prog_b jumper be enough to rescue a crapped=
 up
>> flash bitstream ?
>
> Via what?  You'll be able to load bitstreams directly via JTAG no matt=
er
> what the state of the flash.

	I meant reprogram the flash in system (since it's soldered). But if JTA=
G  =

works, I can always use iMPACT in the worst case.

>> - does it suck ?
>
> It's probably going to cost you more than buying a dev board with
> equivalent functionality.  But what would you learn from that??

	Yeah ; I want to do it and I think it's both interesting and fun.

>> - do I need to add resistors to the data lines ?
>
> You can always stuff them with 0R if you need to.  If your design rule=
s
> allow it, something like a CTS 742C083 series resistor array would be
> easy to fit in the layout.  That package is basically 3 0603 resistors=

> side by side in one 1206 package.

	I'll check this when I route. Isn't the FPGA drive strength option  =

suficient ?

> Oh yeah, give yourself some pushbuttons to force reprogram, reset, etc=
..
> And some LEDs.  You'll want something dead simple to do your initial
> bringup tests.

	Damn, I have forgotten the Reset Switch ! (too much time using Linux I =
 =

guess). I'll add one.
	I have a PROG_B jumper (to stop the boot and use JTAG instead).

	Updated schematics :

	http://home.peufeu.com/nik/fpga/board_v01/schema2.pdf


	Thanks a lot. I think it's getting closer !

> But for an individual with a hobby, we are unable to offer this service.
>  Perhaps someone else will volunteer?

	Yeah, this is the case !
	Thanks anyway.

> http://www.xilinx.com/products/boards/files/ml401_2_3_schematics.pdf

	Interesting ; however for my first FPGA design I guess Spartan-3 is more  
appropriate than Virtex-4 ;)

On 2007-07-14, PFC <lists@peufeu.com> wrote:
>
>>> - do I need to add resistors to the data lines ?
>>
>> You can always stuff them with 0R if you need to.  If your design rules
>> allow it, something like a CTS 742C083 series resistor array would be
>> easy to fit in the layout.  That package is basically 3 0603 resistors
>> side by side in one 1206 package.
>
> 	I'll check this when I route. Isn't the FPGA drive strength option  
> suficient ?

Maybe for the address lines, but the data lines are bidirectional.
If you plan to run the SDRAM at 10MHz, I wouldn't give it a second
thought.  If you're aiming at >100MHz then you probably want to give
yourself the option.

I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines
total).

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

>>>> - do I need to add resistors to the data lines ?
>>>
>>> You can always stuff them with 0R if you need to.  If your design rules
>>> allow it, something like a CTS 742C083 series resistor array would be
>>> easy to fit in the layout.  That package is basically 3 0603 resistors
>>> side by side in one 1206 package.
>>
>> 	I'll check this when I route. Isn't the FPGA drive strength option
>> suficient ?
>
> Maybe for the address lines, but the data lines are bidirectional.
> If you plan to run the SDRAM at 10MHz, I wouldn't give it a second
> thought.  If you're aiming at >100MHz then you probably want to give
> yourself the option.
>
> I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines
> total).

	OK, I had forgotten that the SDRAM chip doesn't have a drive strength  
limit option...

	I'll use Xilinx mch_opb_sdram controller with XCL links to the CPU. The  
"mch" (multichannel) part isn't of any use to me but I tested this core  
versus the standard SDRAM core in a previous FPGA design and found this  
one to be much faster, and it plays well with the DMA controller's bursts.

	So the SDRAM will probably run around 50-70 MHz if I believe the core's  
datasheet, on SPartan-3E.

	I will locate the single 32-bit SDRAM chip below the FPGA, on the other  
side of the board (it's a PQFP 208) so trace length and skew will be  
minimal (about 1 cm).
	I may still have room for the resistor arrays, though. Since the FPGA  
limits its drive strength, I should place the resistors at the SDRAM pins,  
I think ?

	However, for the connector IO, I believe I can use the FPGA drive  
strength setting for signals sent by the FPGA, and place resistors  
(source-termination) at chips on the carrier board which will send data to  
the FPGA, right ?

	Thanks for the advice !

Ben Jackson wrote:
> On 2007-07-14, PFC <lists@peufeu.com> wrote:
>>>> - do I need to add resistors to the data lines ?
>>> You can always stuff them with 0R if you need to.  If your design rules
>>> allow it, something like a CTS 742C083 series resistor array would be
>>> easy to fit in the layout.  That package is basically 3 0603 resistors
>>> side by side in one 1206 package.
>> 	I'll check this when I route. Isn't the FPGA drive strength option  
>> suficient ?
> 
> Maybe for the address lines, but the data lines are bidirectional.
> If you plan to run the SDRAM at 10MHz, I wouldn't give it a second
> thought.  If you're aiming at >100MHz then you probably want to give
> yourself the option.
> 
> I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines
> total).

For a point-to-point solution on a small board, I'd suggest the series 
resistors are overkill for data and address lines.  If there were 
multiple loads, those resistors could be very handy.  If the routing 
length was 6" or more, those resistors could be very handy.  For even a 
200 MHz SRAM interface placed very close to the FPGA, I had no qualms 
about point-to-point connections.

For the signals that are *edge* critical, the resistor placeholder could 
be helpful to avoid some overshoot or troubles with monotonicity but I'd 
expect a smooth signal regardless if the transmission length is that short.
__________________

One additional quick item - how are you hooking up the JTAG?  If you're 
using the Xilinx programming adapter (I really prefer the Platform Cable 
USB) I'd suggest using the connector and pinout that plays nice with the 
ribbon cable connection.

If this is board will have very few items produced, I'd also suggest 
using a memory that has a JTAG interface such that programming the Flash 
and reconfiguring the FPGA on the fly are both done with the same 
connect-in and forget-it interface.  It may be a few dollars rather than 
50 cents for a chip that gives you the flexibility, but I'd glagly take 
a $40 hit to avoid reconnecting those darned header signals over and 
over.  A quick on-and-off connection with the 1mm spaced ribbon cable is 
  so much easier than dealing with the flying leads and, perhaps, better 
for signal fidelity which can be an issue sometimes.

- John_H

	I have tried to apply all the advice given by Ben Jackson and John-H. So,  
here is the updated schem & now fully routed board.
	http://home.peufeu.com/nik/fpga/board_v02/

	Thanks a lot ! I guess I've got to order the parts now, check footprints  
with the real thing...

> For a point-to-point solution on a small board, I'd suggest the series  
> resistors are overkill for data and address lines.  If there were  
> multiple loads, those resistors could be very handy.  If the routing  
> length was 6" or more, those resistors could be very handy.  For even a  
> 200 MHz SRAM interface placed very close to the FPGA, I had no qualms  
> about point-to-point connections.

	OK. That's cool, because when putting the SDRAM below the FPGA there  
isn't much space for resistors...

> One additional quick item - how are you hooking up the JTAG?  If you're  
> using the Xilinx programming adapter (I really prefer the Platform Cable  
> USB) I'd suggest using the connector and pinout that plays nice with the  
> ribbon cable connection.

	I have a JTAG parallel port gizmo from Trenz ; it works well and is  
compatible with the Xilinx tools. I'll use a compatible header on my board  
so a simple ribbon will work.

> If this is board will have very few items produced, I'd also suggest  
> using a memory that has a JTAG interface such that programming the Flash

	iMPACT can write the flash via the FPGA's own JTAG, I will use this  
feature.

> and reconfiguring the FPGA on the fly are both done with the same  
> connect-in and forget-it interface.  It may be a few dollars rather than  
> 50 cents for a chip that gives you the flexibility, but I'd glagly take  
> a $40 hit to avoid reconnecting those darned header signals over and  
> over.  A quick on-and-off connection with the 1mm spaced ribbon cable is  
>   so much easier than dealing with the flying leads and, perhaps, better  
> for signal fidelity which can be an issue sometimes.

	Oh yeah. Flying leads are a pain. How come they could agree on everything  
in JTAG to make it a standard, except the pinout ????

	Regards,
	Pierre

PFC wrote:
<snip>
>> If this board will have very few items produced, I'd also suggest 
>> using a memory that has a JTAG interface such that programming the Flash
> 
>     iMPACT can write the flash via the FPGA's own JTAG, I will use this 
> feature.
<snip>


Your schematic shows a JTAG header and an external programming interface 
header for the ATMEL flash.  If you're suggesting that Impact will reach 
out of the FPGA on the passive serial lines and program the flash there, 
I don't know the tools like I thought I did.

If I do understand the tools, the FPGA can be programmed with the JTAG 
but the flash will have to be reconnected through your external 
programming header.  If you used a JTAG-compatible memory rather than 
the economical ATMEL chip, you would have a daisy-chain of the two 
devices in your JTAG chain.  Programming the FPGA or the Flash would be 
a simple matter of selecting which chip for Impact to target.

- John_H

> Your schematic shows a JTAG header and an external programming interface  
> header for the ATMEL flash.  If you're suggesting that Impact will reach  
> out of the FPGA on the passive serial lines and program the flash there,  
> I don't know the tools like I thought I did.

	XAPP 445 page 9 seems to hint at this.
	I could also upload a bitstream containing a bootloader and SPI flash  
driver, an send configuration via the serial port. I reprogrammed the  
parallel Flash on my previous FPGA module this way.

	Can you point to a suitable Flash chip supporting JTAG, just in case ?

	Thanks.


> If I do understand the tools, the FPGA can be programmed with the JTAG  
> but the flash will have to be reconnected through your external  
> programming header.  If you used a JTAG-compatible memory rather than  
> the economical ATMEL chip, you would have a daisy-chain of the two  
> devices in your JTAG chain.  Programming the FPGA or the Flash would be  
> a simple matter of selecting which chip for Impact to target.
>
> - John_H

The Xilinx XCS04S would give you the JTAG connections for reprogramming and 
is certainly supported well by the Impact tools.

The Spartan-3E Family Complete Data Sheet's section on Configuration (in the 
Functional Description) has a direct link to the Platform Flash product page 
in the Spartan-3E Configuration Mode Options and Pin Settings table.

- John_H


"PFC" <lists@peufeu.com> wrote in message news:op.tvkbmksacigqcu@apollo13...
>
>> Your schematic shows a JTAG header and an external programming interface 
>> header for the ATMEL flash.  If you're suggesting that Impact will reach 
>> out of the FPGA on the passive serial lines and program the flash there, 
>> I don't know the tools like I thought I did.
>
> XAPP 445 page 9 seems to hint at this.
> I could also upload a bitstream containing a bootloader and SPI flash 
> driver, an send configuration via the serial port. I reprogrammed the 
> parallel Flash on my previous FPGA module this way.
>
> Can you point to a suitable Flash chip supporting JTAG, just in case ?
>
> Thanks.
>
>
>> If I do understand the tools, the FPGA can be programmed with the JTAG 
>> but the flash will have to be reconnected through your external 
>> programming header.  If you used a JTAG-compatible memory rather than 
>> the economical ATMEL chip, you would have a daisy-chain of the two 
>> devices in your JTAG chain.  Programming the FPGA or the Flash would be 
>> a simple matter of selecting which chip for Impact to target.
>>
>> - John_H 

On 2007-07-16, John_H <newsgroup@johnhandwork.com> wrote:
>
> Your schematic shows a JTAG header and an external programming interface 
> header for the ATMEL flash.  If you're suggesting that Impact will reach 
> out of the FPGA on the passive serial lines and program the flash there, 
> I don't know the tools like I thought I did.

I don't know if Xilinx can do that, but there's an Altera megafunction
called "Serial Flash Loader" (SFL) which can do that with the Quartus II
programming tool.  That means you can have just one external header (JTAG)
and have access to do direct bitstream loads, signaltap and flash
programming.

(to the OP:  doesn't apply to you, obviously!)

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

> The Xilinx XCS04S would give you the JTAG connections for reprogramming  
> and
> is certainly supported well by the Impact tools.
>
> The Spartan-3E Family Complete Data Sheet's section on Configuration (in  
> the
> Functional Description) has a direct link to the Platform Flash product  
> page
> in the Spartan-3E Configuration Mode Options and Pin Settings table.

	OK, I'll include one, found it on DigiKey, it fits nicely.
	I'm keeping the SPI DataFlash, though, but it will only contain the  
software code that the BRAM microblaze bootloader will copy into SDRAM,  
you know the story.
	I don't know if I will need it though, if the Ethernet driver fits in  
BRAM, it would be able to load the software from the PC via ethernet on  
boot, so it'll always be up to date without flashing !

	Thanks for the advice !

>> Your schematic shows a JTAG header and an external programming interface
>> header for the ATMEL flash.  If you're suggesting that Impact will reach
>> out of the FPGA on the passive serial lines and program the flash there,
>> I don't know the tools like I thought I did.
>
> I don't know if Xilinx can do that, but there's an Altera megafunction
> called "Serial Flash Loader" (SFL) which can do that with the Quartus II
> programming tool.  That means you can have just one external header  
> (JTAG)
> and have access to do direct bitstream loads, signaltap and flash
> programming.
>
> (to the OP:  doesn't apply to you, obviously!)

	Actually, I possibly skrewed up ;) in my datasheet reading...
	XPS can load a parallel flash if your design contains an opb_emc memory  
controller though.
	
	So for safety I put a JTAG Platform Flash  to configure the FPGA. SPI  
flash will just store software (or maybe even not be populated).

	http://home.peufeu.com/nik/fpga/board_v03/schema.pdf

	I think I'll order the stuff at DigiKey tomorrow. Yes !!

	Have a nice day !

On 2007-07-17, PFC <lists@peufeu.com> wrote:
>
> 	Actually, I possibly skrewed up ;) in my datasheet reading...
> 	XPS can load a parallel flash if your design contains an opb_emc memory
> controller though.

Yes, if you make a design with some RAM and a parallel flash, the
Xilinx tools will build an application to run on this design (I'm
thinking PPC here, but maybe it also does this if you include microblaze?)
that will program the flash memory.

It's pretty slow, though.  As soon as we had our own stuff booting and
talking on the network we switched to programming that way.

> 	So for safety I put a JTAG Platform Flash  to configure the FPGA. SPI  
> flash will just store software (or maybe even not be populated).

If it makes you feel better, the hardware guys at work put platform flash
down on the first few revs of a much more complex board than yours
(ultimately booted by a CPLD sequencing the parallel flash) just to be
sure the FPGA would configurable right away...

(btw, I just got my pcbs today and assembled my FLEX board and everything
works!  yay!)

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/