SimmStick FPGA module

>> Another idea: What do you guys think about adding a slot for a SD Card [1].
>> They are cheap (about EUR 10,- for 128MB) and you get them up to 1GB!
>> However, the impact on the board is high: The connector is 'big' and
>> increases the board hight. A FPGA with a higher pin-count is needed. For
>> the solution without the SD Card a 100pin TQFP would fit, but now a 144pin
>> is needed - again a larger board.
>> And this adds again a few EUR/$. All these design decissions! You start with
>> a minimal core design and than start adding (unnecesssary) features again.
>>
>> BTW: Has somebody inplemented an SD Card interface in an FPGA. It should
>> not be too hard [2]. The simplest solution would be the SPI bus.
>
>  You might want to consider two variants: one that is on the KISS path,
> and is on the lower price knee, and just sufficent to operate a workable
> JOP, and another that is more maximal, and more able to launch an
> operating system as well.

I would be happy to go the KISS path, but I don't know how one can keep
a soft-cpu module simple to handle. You have too many options: You're
developing on two levels: the CPU inside the FPGA with peripheral components
and software for the CPU. During development on one of these areas different
ways for downloading the configuration/software fits best:

Simplest: Flash is configured with JOP waiting for a download of a Java program.
How do you donwload it? Via a serial interface - Then we need a serial interface.
Program the serial Flash with the Java program. Not very comfortable during
development - You have to use Quartus for the Flash programming, but you are
only interested in Java development.
Now you start changing JOP, e.g. do some FPGA development. Do you want to
program the Flash for every try or do you prefere to download the configuration
direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash
and one for the Cyclone). Two pin heads need space and make it more complicate
to handle the board (not the KISS path).

Any ideas are highly welcome ;-)

>
>  For package, I'd vote against pin-modules, as they are expensive
> to make, have a pin count ceiling, and are easily damaged. The only
> benefit is they can save a little time in first deployment.
>  Better are the memory-card formats, as they have low cost and sturdy
> connections, that can still be socket managed on 1 & 2 layer PCB, and
> you can offer a socket-pcb for users starting from nothing.
>

First ideas about the memory card format (still SIMM):
http://www.jopdesign.com/jopstick/index.jsp

One format is very small with a FPGA in TQFP100. There are just enough pins
for the SDRAM and the SimmStick bus. The second variant is larger with
a TQFP144 FPGA and a slot for a SD card.

>  Besides the simmmstick itself, you should consider the SODIMM modules,
> as seen in TINI :
>  http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf

Yes, another option. However, is there a kind of 'standard' for this larger modules.
Are there peripheral modules available for this form factor?

>  For "smart expansion", SD would be one option, but smaller and
> more flexible might be USB-Drive ?. Not as cheap at the lowest node,
> but universally portable - few PCs can R/W SD cards, but they can all
> R/W a USB drive.
>  Of course, that means the FPGA needs to be smarter :)

Do you mean USB host? That's not so earsy. I would expect that the FPGA
(and the software) has to be too smart ;-)

Martin

PS.: Thanks for all suggestions from the usenet group! It's really fun to discuss several
options during development of a board.

Martin Schoeberl wrote:
> I would be happy to go the KISS path, but I don't know how one can
keep
> a soft-cpu module simple to handle. You have too many options: You're
> developing on two levels: the CPU inside the FPGA with peripheral
components
> and software for the CPU. During development on one of these areas
different
> ways for downloading the configuration/software fits best:
>
> Simplest: Flash is configured with JOP waiting for a download of a
Java program.
> How do you donwload it? Via a serial interface - Then we need a
serial interface.
> Program the serial Flash with the Java program. Not very comfortable
during
> development - You have to use Quartus for the Flash programming, but
you are
> only interested in Java development.
> Now you start changing JOP, e.g. do some FPGA development. Do you
want to
> program the Flash for every try or do you prefere to download the
configuration
> direct to the FPGA. Then we need a second ByteBlaster adapter (one
for the Flash
> and one for the Cyclone). Two pin heads need space and make it more
complicate
> to handle the board (not the KISS path).
>
> Any ideas are highly welcome ;-)

 Yes. Indeed at my company we have a design that uses an FTDI FT2232C
USB controller to:

 1- Power the board (up to 500mA@5V but you can also use external
power).
 2- Implement a JTAG interface.
 3- Implement a serial/FIFO communication line.

 You get all these from a single cable and that is very useful for
development. The FT2232C (http://www.ftdichip.com/Products/FT2232C.htm)
implements two versatile IO ports and supports a smart bit-bang mode
(MPSSE), so you can do serial or FIFO communications with one channel
and JTAG programming or debugging with the other in parallel (you even
get some GPIOs that are very handy if you need to configure your board
on the fly). We use those 'mini' type-B USB connector that save a lot
of space, and you can buy the cables cheap from Palm or mobile phone
accessory suppliers.

 Since you are fond of Java, you might enjoy the Java bindings for the
FTDI direct driver at http://jd2xx.dev.java.net/ which I maintain. I
have personally implemented an MPSSE JTAG controller using it (tested
with Xilinx FPGAs), it is not very difficult.

> >  Besides the simmmstick itself, you should consider the SODIMM
modules,
> > as seen in TINI :
> >  http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf
>
> Yes, another option. However, is there a kind of 'standard' for this
larger modules.
> Are there peripheral modules available for this form factor?

 I guess the DIMM-PC is as standard as it gets
(http://www.jumptec.de/product/we_docs/dimm.php). Every vendor seems
akin to implement their own standard; besides the world is mostly going
high-speed serial now... If you want your own parallel edgeboard
connector there are those universal 132-pin AGP connectors that sell
for less than a dollar in small quantities... just an idea.

> PS.: Thanks for all suggestions from the usenet group! It's really
fun to discuss several
> options during development of a board.

 Ain't that GREAT (TM)? At least if you finally mess up you can blame
or share the guilt with others :)

 Luck with you project.

--
PabloBleyerKocik /
 pbleyer        / "Their primitive minds couldn't accept the truths."
  @embedded.cl / -- Cheech Wizard in 'Captured by Morton Frogg'

"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> skrev i meddelandet
news:1108427617.762469.128840@g14g2000cwa.googlegroups.com...
> Martin Schoeberl wrote:
> > I would be happy to go the KISS path, but I don't know how one can keep
> > a soft-cpu module simple to handle. You have too many options: You're
> > developing on two levels: the CPU inside the FPGA with peripheral
components
> > and software for the CPU. During development on one of these areas
different
> > ways for downloading the configuration/software fits best:
> >

The AT76C712/3 is a small AVR CPU with USB that boots from a
(AT45DBxxx) serial (SPI) dataflash memory
The dataflash can also contain the configuration data.

If you let the device run the USB Mass Storage Adapter device class
then the programming can be as simple as a drag and drop
to the file system.   You can probably setup your
development environment to save the bitstream to the new "USB key"
The onboard AVR runs 48 MHz so your configuration should be quite fast.

Typically dataflash is much cheaper than configuration memories
and you can get them in sizes up to 64 Mbit today.
In SO-8 pinout, they are up to 16 Mbit today, but the 128 Mbit in SO-8
is around the corner.

During configuration, the AVR can read a script file from
teh FAT file system and can react accordingly
maybe also taking some DIP switches in account.
(You could have several configurations, very easily)

After configuration, the AVR could switch to a USB<->Serial adapter.
(Disabling the USB Mass Storage, until a key is pressed)
-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Martin Schoeberl wrote:
>>>Another idea: What do you guys think about adding a slot for a SD Card [1].
>>>They are cheap (about EUR 10,- for 128MB) and you get them up to 1GB!
>>>However, the impact on the board is high: The connector is 'big' and
>>>increases the board hight. A FPGA with a higher pin-count is needed. For
>>>the solution without the SD Card a 100pin TQFP would fit, but now a 144pin
>>>is needed - again a larger board.
>>>And this adds again a few EUR/$. All these design decissions! You start with
>>>a minimal core design and than start adding (unnecesssary) features again.
>>>
>>>BTW: Has somebody inplemented an SD Card interface in an FPGA. It should
>>>not be too hard [2]. The simplest solution would be the SPI bus.
>>
>> You might want to consider two variants: one that is on the KISS path,
>>and is on the lower price knee, and just sufficent to operate a workable
>>JOP, and another that is more maximal, and more able to launch an
>>operating system as well.
> 
> 
> I would be happy to go the KISS path, but I don't know how one can keep
> a soft-cpu module simple to handle. You have too many options: You're
> developing on two levels: the CPU inside the FPGA with peripheral components
> and software for the CPU. During development on one of these areas different
> ways for downloading the configuration/software fits best:
> 
> Simplest: Flash is configured with JOP waiting for a download of a Java program.
> How do you donwload it? Via a serial interface - Then we need a serial interface.
> Program the serial Flash with the Java program. Not very comfortable during
> development - You have to use Quartus for the Flash programming, but you are
> only interested in Java development.
> Now you start changing JOP, e.g. do some FPGA development. Do you want to
> program the Flash for every try or do you prefere to download the configuration
> direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash
> and one for the Cyclone). Two pin heads need space and make it more complicate
> to handle the board (not the KISS path).

  It depends on the bandwidths, but I like Pablo's idea of a FT2232C - 
there may be enough smarts between that device, and your FPGA, to 
improve PC-target bandwidths for debug (single step?) and download -> 
SDRAM, prior to code FLASH for final pass.
  Perhaps a 'virtual jumper' in the FPGA code, or'd with a FT2232C pin, 
could select Load from USB.FIFO, or top of SerialConfig ?

  Another device that appeals for Soft-cpu is this one :
http://www.st.com/stonline/press/news/year2005/p1563m.htm
with 75MHz burst, 32 bits wide, that's 2400MB/s, vs 25-50MB/s on a SD card.
  So the SD card looses on speed, but gains on universal supply/size,
and you CAN easily remove it - hmmm... perhaps put the M58BW032 on the
other side of the PCB ?

  Maybe option the SD socket, and M58BW032, on the more complex model ?

Next, some form of Codec would be nice, what about something from this 
selection ?
http://para.maxim-ic.com/compare_noj.asp?Fam=CODEC&Tree=Wireless&HP=Wireless.cfm&ln=
$5-7 for 22-60Msps ADC & DAC ?
This ties in well with a SD socket, & USB link...


> 
> Any ideas are highly welcome ;-)
> 
> 
>> For package, I'd vote against pin-modules, as they are expensive
>>to make, have a pin count ceiling, and are easily damaged. The only
>>benefit is they can save a little time in first deployment.
>> Better are the memory-card formats, as they have low cost and sturdy
>>connections, that can still be socket managed on 1 & 2 layer PCB, and
>>you can offer a socket-pcb for users starting from nothing.
>>
> 
> 
> First ideas about the memory card format (still SIMM):
> http://www.jopdesign.com/jopstick/index.jsp
> 
> One format is very small with a FPGA in TQFP100. There are just enough pins
> for the SDRAM and the SimmStick bus. The second variant is larger with
> a TQFP144 FPGA and a slot for a SD card.

SD starts to look nice on this basis...

>> Besides the simmmstick itself, you should consider the SODIMM modules,
>>as seen in TINI :
>> http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf
> 
> 
> Yes, another option. However, is there a kind of 'standard' for this larger modules.
> Are there peripheral modules available for this form factor?

The TINI itself ? ;)
- plus as TINI also has Java path, you could get some cross-polination ?


> 
>> For "smart expansion", SD would be one option, but smaller and
>>more flexible might be USB-Drive ?. Not as cheap at the lowest node,
>>but universally portable - few PCs can R/W SD cards, but they can all
>>R/W a USB drive.
>> Of course, that means the FPGA needs to be smarter :)
> 
> 
> Do you mean USB host? That's not so earsy. I would expect that the FPGA
> (and the software) has to be too smart ;-)

You are probably right, but you did ask for suggestions :)

> 
> Martin
> 
> PS.: Thanks for all suggestions from the usenet group! It's really fun to discuss several
> options during development of a board.

-jg

>> Any ideas are highly welcome ;-)
>
> Yes. Indeed at my company we have a design that uses an FTDI FT2232C
> USB controller to:
>
> 1- Power the board (up to 500mA@5V but you can also use external
> power).
> 2- Implement a JTAG interface.
> 3- Implement a serial/FIFO communication line.
>
> You get all these from a single cable and that is very useful for
> development. The FT2232C (http://www.ftdichip.com/Products/FT2232C.htm)
> implements two versatile IO ports and supports a smart bit-bang mode
> (MPSSE), so you can do serial or FIFO communications with one channel
> and JTAG programming or debugging with the other in parallel (you even
> get some GPIOs that are very handy if you need to configure your board
> on the fly). We use those 'mini' type-B USB connector that save a lot
> of space, and you can buy the cables cheap from Palm or mobile phone
> accessory suppliers.

Yes, this chip is fine. You can get rid of these download cables. So the idea is
to use this USB chip to program the serial flash (in the same way as you do it
with the ByteBlaster - holding the FPGA on reset with nConfig low). Or if you
want to config it direct you could use the the JTAG interface - doning JTAG
with the FT2232C. However, for both modes you have to provide a 'special'
program and can't use Quartus anymore.

Another point: I see this module as an Java SBC and not a slave of a PC. So
I did understand Jim's suggestion to build an USB host. That means you can use
the USB to attach flash or anything else to the SBC and not the board as USB
slave to the PC. This direction was what I meant not so easy.

>
> Since you are fond of Java, you might enjoy the Java bindings for the
> FTDI direct driver at http://jd2xx.dev.java.net/ which I maintain. I
> have personally implemented an MPSSE JTAG controller using it (tested
> with Xilinx FPGAs), it is not very difficult.

You did configura the Xilinx FPGA in JTAG mode? That's very interesting.
I hope there is enough documentation about the Altera Cyclone to do the
same.

>> PS.: Thanks for all suggestions from the usenet group! It's really
> fun to discuss several
>> options during development of a board.
>
> Ain't that GREAT (TM)? At least if you finally mess up you can blame
> or share the guilt with others :)

You mean mess up with the board or with the sales numbers ;-)

>
> Luck with you project.
>
Thanks!


Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/ 

>> I would be happy to go the KISS path, but I don't know how one can keep
>> a soft-cpu module simple to handle. You have too many options: You're
>> developing on two levels: the CPU inside the FPGA with peripheral components
>> and software for the CPU. During development on one of these areas different
>> ways for downloading the configuration/software fits best:
>>
>> Simplest: Flash is configured with JOP waiting for a download of a Java program.
>> How do you donwload it? Via a serial interface - Then we need a serial interface.
>> Program the serial Flash with the Java program. Not very comfortable during
>> development - You have to use Quartus for the Flash programming, but you are
>> only interested in Java development.
>> Now you start changing JOP, e.g. do some FPGA development. Do you want to
>> program the Flash for every try or do you prefere to download the configuration
>> direct to the FPGA. Then we need a second ByteBlaster adapter (one for the Flash
>> and one for the Cyclone). Two pin heads need space and make it more complicate
>> to handle the board (not the KISS path).
>
>  It depends on the bandwidths, but I like Pablo's idea of a FT2232C - there may be enough smarts 
> between that device, and your FPGA, to improve PC-target bandwidths for debug (single step?) and 
> download -> SDRAM, prior to code FLASH for final pass.

From your first suggestion I thought you mean USB master on the FPGA to
use USB devices.

>  Perhaps a 'virtual jumper' in the FPGA code, or'd with a FT2232C pin, could select Load from 
> USB.FIFO, or top of SerialConfig ?

I don't get the idea. For configuration from Flash I want the module to
run stand-alone. That means no USB connection. The FT2232C has
to be disabled in this mode and the power has to be provided through
a different pin (from the SIMM bus, e.g.).

>
>  Another device that appeals for Soft-cpu is this one :
> http://www.st.com/stonline/press/news/year2005/p1563m.htm
> with 75MHz burst, 32 bits wide, that's 2400MB/s, vs 25-50MB/s on a SD card.
>  So the SD card looses on speed, but gains on universal supply/size,
> and you CAN easily remove it - hmmm... perhaps put the M58BW032 on the
> other side of the PCB ?

It was not the idea to exectue (Java) code direct from the SD card. We have
large SDRAM on board. The code is copied from the SD card (or serial Flash)
to the SDRAM prior execution. So speed is not the point. The SD card can
further act as file system.
I know that the automotive industry does like to execute direct from Flash.
They want to avoid the additional boot time due to the memory copy. They
want a boot in the ms region. However, this is not the problem for this board.

>
>  Maybe option the SD socket, and M58BW032, on the more complex model ?
>
> Next, some form of Codec would be nice, what about something from this selection ?
> http://para.maxim-ic.com/compare_noj.asp?Fam=CODEC&Tree=Wireless&HP=Wireless.cfm&ln=
> $5-7 for 22-60Msps ADC & DAC ?
> This ties in well with a SD socket, & USB link...

What for would you use these Codecs?

>> First ideas about the memory card format (still SIMM):
>> http://www.jopdesign.com/jopstick/index.jsp
>>
>> One format is very small with a FPGA in TQFP100. There are just enough pins
>> for the SDRAM and the SimmStick bus. The second variant is larger with
>> a TQFP144 FPGA and a slot for a SD card.
>
> SD starts to look nice on this basis...

But the SD connector is still 'large' ;-)

>
>>> Besides the simmmstick itself, you should consider the SODIMM modules,
>>>as seen in TINI :
>>> http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf
>>
>>
>> Yes, another option. However, is there a kind of 'standard' for this larger modules.
>> Are there peripheral modules available for this form factor?
>
> The TINI itself ? ;)
> - plus as TINI also has Java path, you could get some cross-polination ?
>
Yes, a point to consider. I don't know how large the TINI user base is.
As the TINI is a VERY slow JVM, JOP could be a fine replacement
(JOP is almost 200 times faster than the TINI). And you have an FPGA...

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/