GA144 Application Board

[rickman]

What would you like to see on a GA144 application board? I am
thinking of building a board which would have enough buffered analog
input and output for the 5 ADC and DAC I/Os as well as buffered I/O
for a number of digital I/Os, around 8 to 12 each. Because of the I/O
limits of a 1.8 volt device I am thinking of using a small FPGA as a
voltage level converter.

If I find it is useful, I am thinking of providing a small number of
isolated I/Os. When working with a production JTAG device it was once
explained to me that it can be important to use isolated I/O to
minimize ground loop issues. But that can be added externally if it
creates problems with the layout.

I'm not sure what to do with the SERDES. 450 Mbps is pretty tempting
but I'm not sure what it can be used for other than talking to other
GA chips. The receive can work with a clock, but the transmit
generates a clock of unknown frequency, so I don't see how to use it
in the context of any standard. I don't see any timing data on this
in the spec sheet so I can't anticipate how I might be able to use
it. Any ideas?

I do want to provide for an Ethernet interface and USB. So I expect
I'll include hardware for an MII or RMII interface to a PHY. I think
an F18A node should be able to keep up with 25 MHz nibbles for 100
Mbps operation.

I'm less familiar with USB. I'll have to look up interface chips and
see what they require. I suppose an 80 MHz, 8 bit interface could be
doable and a 40 MHz, 16 bit interface should be very workable. I
don't think the FPGA I am planning to use will work at 480 Mbps.

I expect to include a full size SD card connector for additional
storage. Some sort of LCD interface will also be included, likely to
include a touch panel.

Any other suggestions?

Rick

[Rafael Deliano]

> What would you like to see on a GA144 application board?

For an "evaluation board" ( something stuffed with lots of
components ) most people will stick with the EVB001 from
Green Arrays. Its well done. Maybe a bit expensive, but
people that are serious about GA144 will not have much
problem with that.

For an "adapter board" ( a simple board that enables
breadboarding ) there is not much available yet.
Most people will not take the SchmartBoard 202-0048-02
seriously.
The adapter board would typically
* fit in a PGA socket. One would have a look which of
these obsolete sockets is best available.
* come assembled, tested with ICs, capacitors.
* there would be two variants:
a) with serial boot-memory
b) with serial boot-memory and parallel SRAM
in BGA48
Version a) is for simple "gate array application"
with no virtual machine. One would not want to lose
the pins that are gone with SRAM in version b).

That a third category "application board" exists i
am sceptical. As every one will have a different
application in mind.
For low speed one can breadboard with the adapter boards.
For high speed applications one will have to layout.

MfG JRD

[rickman]

On Mar 11, 5:10 am, Rafael Deliano <Rafael_Deli...@arcor.de> wrote:
> > What would you like to see on a GA144 application board?
>
> For an "evaluation board" ( something stuffed with lots of
> components ) most people will stick with the EVB001 from
> Green Arrays. Its well done. Maybe a bit expensive, but
> people that are serious about GA144 will not have much
> problem with that.

I don't see where the EVB001 is very good for anything other than
playing with the CPU. Maybe the name "evaluation" board is not so
important. I wouldn't spend $500 just to "evaluate" or learn about
the chip. I might spend that much on a board that lets me evaluate
the device for my application. Would you call that an "application"
board? But the EVB001 doesn't have the facility of adding any useful
interfaces really. I just can't see a chip like this being useful in
enough apps unless you can hang some useful interfaces off it, like
high speed USB and at least 100 Mbps Ethernet. I am thinking wireless
may well be important too. I don't know as much about that. I also
don't see anything coming out of GreenArrays along these lines. Just
like they published half an app note on adding a crystal to make an
oscillator they published half an app note on adding 10 Mbps Ethernet
by bit banging. Actually I would only call it 10% of an app note as
there is a ton more work to be done before Ethernet could be supported
in a useful way.

I'm hoping that if I put out a GA144 board with a RMII PHY that might
spur some interest in developing the remainder of the design. I'm not
as encouraged that high speed USB will be practical without adding a
full USB stack on another chip.

> For an "adapter board" ( a simple board that enables
> breadboarding ) there is not much available yet.
> Most people will not take the SchmartBoard 202-0048-02
> seriously.
> The adapter board would typically
> * fit in a PGA socket. One would have a look which of
> these obsolete sockets is best available.
> * come assembled, tested with ICs, capacitors.
> * there would be two variants:
> a) with serial boot-memory
> b) with serial boot-memory and parallel SRAM
> in BGA48
> Version a) is for simple "gate array application"
> with no virtual machine. One would not want to lose
> the pins that are gone with SRAM in version b).

How would you make use of an adapter board? I don't see this as being
a very big seller and I believe it would be VERY expensive to make. I
think people would just roll their own boards before paying a huge
price for such obsolete technology.

You don't really loose many pins by hooking up RAM exactly. The RAM
example uses a single node with 4 I/Os and the two 18 bit I/O ports.
Yes you can use the 18 bit ports as I/O, but you can't use them in the
same way as the individual port bits. On each port all 18 bits are
input or all are output and when you write to one bit you have to
write to all. Otherwise there are only 21 bits of individual I/O.
You do loose 4 of those for the memory control lines.

BTW, in what apps do you see the GA144 being used as a "simple gate
array"?

> That a third category "application board" exists i
> am sceptical. As every one will have a different
> application in mind.
> For low speed one can breadboard with the adapter boards.
> For high speed applications one will have to layout.

What high speed apps? Other than the memory interface and the GA144
to GA144 SERDES, what would be high speed on this chip? Even the
memory interface only runs at 5 MHz according to their app note. I
suppose you could bit bang a SERDES at very reduced speeds compared to
the hard core, but that wouldn't be hard to layout. I think any of
these boards needs to address a user's application if it is going to
be worth the price. Like I said, that is my issue with the EVB001.

The part of "every one will have a different application in mind" that
is a bit funny is that so far, I haven't heard anyone suggest
realistic apps for the part, much less everyone having "different
apps". I'm not saying they don't exist. I'm saying no one seems to
be talking about them. That's what I am looking for. What would
people find interesting to use this device for? An eval/demo/app
board can be a superset of what any one user wants. In fact I am
pretty confident that is the only way to make it useful.

Rick

[emmanuel]

Hello,

I wouldn't spend $500 just to "evaluate" or learn about the chip. If
you want a board , please visit my web page :

http://esaid.free.fr/

http://esaid.free.fr/tutoriel_arrayforth/Ga144_pcb/Ga144_kit.html

I made this GA144 board and it is cheaper.

Emmanuel

[Rafael Deliano]

> How would you make use of an adapter board?

Like that: http://www.embeddedFORTH.de/temp/bb.pdf
( there its an MC68HC908AW32 ). Integrating a
SMD IC into a conventional through-hole
breadboard. PGA-sockets fit in quite well:
http://www.embeddedforth.de/temp/pga.pdf

> I think people would just roll their own boards
> before paying a huge price for such obsolete technology.

There are indeed a lot of companies that view breadboards
as obsolete technology. But there are a lot of old timers
that do it that way nonetheless. My guess is Green Arrays
is at the moment not selling to companies but to individuals.
And individuals of a vintage age for that.
Layouting and getting a 4 layer PCB is only half the
problem here: the LFN88 and especially the BGA48
are not really a job for a soldering iron.
For that reason i guess people would opt for a assembled,
tested, compact subsystem.

> BTW, in what apps do you see the GA144 being used as a
> "simple gate array"?

Most applications are structured controller + DSP or
controller + FPGA. The DSP/FPGA doing the signal processing,
the controller/host the slow, bulky code.
The GA144 has the hybrid option of part of the
chip doing the host via the virtual machine. While
the rest of the nodes are doing the signal processing.
This is not new as FPGAs have tried that too. But
typically people stick with the 2 chip version as
these emulated controllers cannot compete in
performance, price with the real thing.
The virtual machine is prominent in the GA144 mostly
because people expect from Charles Moore "Forth"
and not a FPGA / transputers-on-chip / cellular array.
Initally people will play with the virtual machine till
they find it sucks. For that reason a SRAM-version of
the adapter is needed.

MfG JRD

[Jecel]

On Saturday, March 10, 2012 10:24:25 PM UTC-3, rickman wrote:
> I'm less familiar with USB. I'll have to look up interface chips and
> see what they require. I suppose an 80 MHz, 8 bit interface could be
> doable and a 40 MHz, 16 bit interface should be very workable. I
> don't think the FPGA I am planning to use will work at 480 Mbps.

One small correction: 480 Mbps / 8 bits = 60 Mhz

Search for "usb ulpi phy" for chips with 8 bit wide interfaces that you can use to connect to the GA144. You might be able to implement the needed software in a single core.

-- Jecel

[Albert van der Horst]

In article <49556347-7bf6-494b...@z31g2000vbt.googlegroups.com>,

rickman <gnu...@gmail.com> wrote:
>What would you like to see on a GA144 application board? I am
>thinking of building a board which would have enough buffered analog
>input and output for the 5 ADC and DAC I/Os as well as buffered I/O
>for a number of digital I/Os, around 8 to 12 each. Because of the I/O
>limits of a 1.8 volt device I am thinking of using a small FPGA as a
>voltage level converter.

I guess flash memory would be needed for making nice demonstration
programs.
I have this Renesas board and it can do things I'm not sure
the GA144 can do.
I can store Forth source in the flash, then load it and define it as a
turnkey. Next time I press reset the application starts instead of
the Forth.
A la
OK
REQUIRE BIG-BEN
' BIG-BEN TURNKEY

(press reset)

>
>If I find it is useful, I am thinking of providing a small number of
>isolated I/Os. When working with a production JTAG device it was once
>explained to me that it can be important to use isolated I/O to
>minimize ground loop issues. But that can be added externally if it
>creates problems with the layout.
>
>I'm not sure what to do with the SERDES. 450 Mbps is pretty tempting
>but I'm not sure what it can be used for other than talking to other
>GA chips. The receive can work with a clock, but the transmit
>generates a clock of unknown frequency, so I don't see how to use it
>in the context of any standard. I don't see any timing data on this
>in the spec sheet so I can't anticipate how I might be able to use
>it. Any ideas?

If you can get the price down to a level that one can afford
several boards, experimenting with SERDES would be nice.

>
>I do want to provide for an Ethernet interface and USB. So I expect
>I'll include hardware for an MII or RMII interface to a PHY. I think
>an F18A node should be able to keep up with 25 MHz nibbles for 100
>Mbps operation.
>
>I'm less familiar with USB. I'll have to look up interface chips and
>see what they require. I suppose an 80 MHz, 8 bit interface could be
>doable and a 40 MHz, 16 bit interface should be very workable. I
>don't think the FPGA I am planning to use will work at 480 Mbps.
>
>I expect to include a full size SD card connector for additional
>storage. Some sort of LCD interface will also be included, likely to
>include a touch panel.

There is the flash. Thanks.

>
>Any other suggestions?

Be careful not to invert the VGA connector ;-)

>
>Rick

Groetjes Albert

P.S. Somebody gave me a MSP430 as a present (worth 4 euro) to implement
ciforth on. The nicest instruction set in the world, pdp11!
The German Forth group has a Forth for that board.


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[rickman]

On Mar 11, 11:03 am, Rafael Deliano <Rafael_Deli...@arcor.de> wrote:
> > How would you make use of an adapter board?
>
> Like that:http://www.embeddedFORTH.de/temp/bb.pdf
> ( there its an MC68HC908AW32 ). Integrating a
> SMD IC into a conventional through-hole
> breadboard. PGA-sockets fit in quite well:http://www.embeddedforth.de/temp/pga.pdf

I haven not worked on a design in probably 10 years that could
practically be prototyped without making a PCB. Your image shows a
single CPU chip on an adapter board. You can get that for the GA144,
from Schmart Boards. I expect they are selling very few of them
partly because there are issues with power decoupling and noise as is
the problem with adapter boards. Heck, they sent me one for free and
I have yet to use it. It is interesting though. They make little
trenches in the top layer of the board and deposit solder on the
copper inside. This provides a "channel" for soldering which likely
works well for leaded parts but not so well for leadless parts.

I don't have much interest in producing such a board for the GA144.
They are expensive to make and I just don't think it would sell well.
Although I could do something with a double sided board and enough
power decoupling to make the thing work better than a Schmart board.
Am I wrong? Are there others out there who would buy a proper GA144
processor/RAM module on a 0.1 inch pins form factor? More likely it
would be a DIP or four rows of pins, two on each side.

> > I think people would just roll their own boards
> > before paying a huge price for such obsolete technology.
>
> There are indeed a lot of companies that view breadboards
> as obsolete technology. But there are a lot of old timers
> that do it that way nonetheless. My guess is Green Arrays
> is at the moment not selling to companies but to individuals.
> And individuals of a vintage age for that.

I am an old timer and as I said, I have not used a breadboard for some
ten years because they aren't very practical for most designs. I do
use eval boards when they include enough circuitry that I need so I
don't have to breadboard features.

> Layouting and getting a 4 layer PCB is only half the
> problem here: the LFN88 and especially the BGA48
> are not really a job for a soldering iron.
> For that reason i guess people would opt for a assembled,
> tested, compact subsystem.

Yep, that is the big reason why breadboards are history. They aren't
very amenable to surface mount technology.

BTW, the BGA48 and the QFN88 are actually ok to work with on home made
boards. There are companies who will make your boards and provide you
with a solder paste stencil. You just have to do your soldering on a
hot plate or in a toaster oven. I've never done this but I hear it is
a workable solution.

> > BTW, in what apps do you see the GA144 being used as a
> > "simple gate array"?
>
> Most applications are structured controller + DSP or
> controller + FPGA. The DSP/FPGA doing the signal processing,
> the controller/host the slow, bulky code.
> The GA144 has the hybrid option of part of the
> chip doing the host via the virtual machine. While
> the rest of the nodes are doing the signal processing.
> This is not new as FPGAs have tried that too. But
> typically people stick with the 2 chip version as
> these emulated controllers cannot compete in
> performance, price with the real thing.
> The virtual machine is prominent in the GA144 mostly
> because people expect from Charles Moore "Forth"
> and not a FPGA / transputers-on-chip / cellular array.
> Initally people will play with the virtual machine till
> they find it sucks. For that reason a SRAM-version of
> the adapter is needed.
>
> MfG JRD

But what are your apps? I am thinking in terms of including most of
the I/O that would be useful in a design. If the unit has more than
you need you can just ignore the extra. This will not be a high
volume board, so most of the cost will be from recouping the NRE, not
from the recurring production costs.

I think software defined radio is calling out for this chip. That
will be one of the things I may take a swing at. My concern is that
the chip has a lot of features that get you "halfway" there, but they
don't fill in the gaps.

Rick

[rickman]

I'd like to know what you use if for. Have you used the GA144 for any
projects?

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> What would you like to see on a GA144 application board?

1. Crystal oscillator (controlled by GA node or otherwise)
2. Isolated I/O's as you suggested
3. Control processor (i.e. traditional cheap microcontroller) to handle
PC interface, GA program loading, etc. This can also handle the USB
or ethernet stuff. It would be nice if this had some NVRAM and a
battery powered real time clock.
4. If USB interface is provided, host port would be useful. Ability
to power the eval board from USB bus would also be useful.
5. How about some op amps that could be used as level converters
by changing some resistors or the like. Maybe controlling them
completely via the GA's DACs is too dangerous (i.e. a software bug
could fry something by generating the wrong voltage).
6. External SRAM for the GA144, similar to GA's own eval board
7. Provision (pads on board) for high resolution (18 bit) ADC/DAC. The
part may be too expensive to include on all boards, but some users
would want it.

I don't think it's important to have both USB and ethernet. One or the
other should be good enough.

SD or microsd card slot for the control processor is useful. Don't need
specialized LCD interface, just use GPIO or serial interface for that.

[Matthias Koch]

> P.S. Somebody gave me a MSP430 as a present (worth 4 euro) to implement
> ciforth on. The nicest instruction set in the world, pdp11!
> The German Forth group has a Forth for that board.

Two ones, to be correct.

One is a port of threaded CamelForth, the other is a native implementation.
http://mecrisp.sourceforge.net/

The MSP430 really has a very beautiful instruction set, but unfortunately
it lacks some destination addressing modes the PDP-11 had.

Matthias

[rickman]

On Mar 14, 10:53 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:
> > What would you like to see on a GA144 application board?
>
> 1. Crystal oscillator (controlled by GA node or otherwise)

I'm very disappointed in the lack of a follow up on the oscillator app
note to provide enough information to design a well specified
oscillator. So until that happens the oscillator will be a self
contained unit. I've looked for low power devices and will be looking
at some silicon devices that are new to the market. I expect the
board to have both a 32.768 kHz oscillator and a higher speed one,
likely either 24 or 25 or maybe 24.768 MHz.

> 2. Isolated I/O's as you suggested

The trouble with isolated I/O is the board space and the wide range of
isolation level and power handling. I think I prefer to leave that
off board. When I looked into it, I found even a thermocouple could
be better interfaced with a separate circuit for only $12.

> 3. Control processor (i.e. traditional cheap microcontroller) to handle
> PC interface, GA program loading, etc. This can also handle the USB
> or ethernet stuff. It would be nice if this had some NVRAM and a
> battery powered real time clock.

I'm not clear why an MCU would be needed for this rather than using
the self boot feature of the GA144. Any processor you add would need
to be upgradable, by this rational, requiring yet another processor.
I think the design only needs a way to plug in a cable to either cold
boot the GA144 or cold program the serial EEPROM the GA144 boots
from.

As to the PC interface, one node on the GA144 can be a serial port
which should suffice for cold booting or basic comms.

> 4. If USB interface is provided, host port would be useful. Ability
> to power the eval board from USB bus would also be useful.

My thinking is to provide an 8 bit wide on-the-go USB PHY. But this
still runs at 60 MB/s. I don't know enough about USB to tell if a
high speed interface can be implemented in the GA144. But it
certainly should support full speed at 12 Mbps just fine.

> 5. How about some op amps that could be used as level converters
> by changing some resistors or the like. Maybe controlling them
> completely via the GA's DACs is too dangerous (i.e. a software bug
> could fry something by generating the wrong voltage).

What range of levels are you thinking of? The issue with analog
outputs is the power supply. If you want more than 5 volts a PSU has
to be added. Inputs are easy to attenuate and even gain can be
controlled. Filtering also needs to be programmable.

> 6. External SRAM for the GA144, similar to GA's own eval board

With the limited internal ram, yes, external RAM is required. I find
it interesting that with the internal word size being 18 bits, the GA
eval board and SRAM board have 16 bit memory. I looked for 18 bit
memory, but it seems to be very expensive now. At one time it was
quite common and not so expensive.

> 7. Provision (pads on board) for high resolution (18 bit) ADC/DAC. The
> part may be too expensive to include on all boards, but some users
> would want it.

The GA144 has unlimited resolution ADC and even DAC. There is a trade
off between resolution and sample rate and is one of the things they
did totally right on the GA144. I think this chip gives you just less
than CD quality, about 15 bits at 48 ksps.

> I don't think it's important to have both USB and ethernet. One or the
> other should be good enough.

Depends on your application, no? Some will want Ethernet, others
USB.

> SD or microsd card slot for the control processor is useful. Don't need
> specialized LCD interface, just use GPIO or serial interface for that.

There isn't much GPIO really. If you use the memory interface for
memory there are only 21 I/Os left. Makes it hard to interface to a
lot of things. But I want this board to be usable as a self contained
unit with user interface. I will probably adapt one of the display
interfaces used with the BeagleBone to this purpose.

Then we just need software to make this stuff work! Notice my casual
use of the four letter word, "just"...

Rick

[Albert van der Horst]

In article <0d702ca7-8af4-4b99...@9g2000vbq.googlegroups.com>,

rickman <gnu...@gmail.com> wrote:
>On Mar 14, 10:53 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> rickman <gnu...@gmail.com> writes:
>> > What would you like to see on a GA144 application board?
>>
>> 1. Crystal oscillator (controlled by GA node or otherwise)
>
>I'm very disappointed in the lack of a follow up on the oscillator app
>note to provide enough information to design a well specified
>oscillator. So until that happens the oscillator will be a self
>contained unit. I've looked for low power devices and will be looking
>at some silicon devices that are new to the market. I expect the
>board to have both a 32.768 kHz oscillator and a higher speed one,
>likely either 24 or 25 or maybe 24.768 MHz.

I was the more disappointed to read the claim of Chuck Moore
of one year ago that he had implemented the one i/o one component
crystal oscillator. Apparently nobody at GreenArrays took the
trouble to even ask for the few screens and then publish it.

<SNIP>

>> 6. External SRAM for the GA144, similar to GA's own eval board
>
>With the limited internal ram, yes, external RAM is required. I find
>it interesting that with the internal word size being 18 bits, the GA
>eval board and SRAM board have 16 bit memory. I looked for 18 bit
>memory, but it seems to be very expensive now. At one time it was
>quite common and not so expensive.

With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
Using this kind of cheap memory 4 Gbyte would not be much slower
than the bit-banging that is done now. So I want a 32 bit eForth
with 4 Gbyte addressable memory before I would even consider
using an ISO Forth on the GA144. This could use cheap discarded
memory from PC's, by the way.

>
>> I don't think it's important to have both USB and ethernet. One or the
>> other should be good enough.
>
>Depends on your application, no? Some will want Ethernet, others
>USB.
>
>
>> SD or microsd card slot for the control processor is useful. Don't need
>> specialized LCD interface, just use GPIO or serial interface for that.
>
>There isn't much GPIO really. If you use the memory interface for
>memory there are only 21 I/Os left. Makes it hard to interface to a
>lot of things. But I want this board to be usable as a self contained
>unit with user interface. I will probably adapt one of the display
>interfaces used with the BeagleBone to this purpose.
>
>Then we just need software to make this stuff work! Notice my casual
>use of the four letter word, "just"...

There is one thing left to do. As this chip is only interesting
to hobbyists and experimenters, the default version should come
with solderable pins.

>
>Rick

Groetjes Albert

[rickman]

On Mar 21, 9:08 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <0d702ca7-8af4-4b99-8d12-1320b239d...@9g2000vbq.googlegroups.com>,

>
> rickman  <gnu...@gmail.com> wrote:
> >On Mar 14, 10:53 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> >> rickman <gnu...@gmail.com> writes:
> >> > What would you like to see on a GA144 application board?
>
> >> 1. Crystal oscillator (controlled by GA node or otherwise)
>
> >I'm very disappointed in the lack of a follow up on the oscillator app
> >note to provide enough information to design a well specified
> >oscillator.  So until that happens the oscillator will be a self
> >contained unit.  I've looked for low power devices and will be looking
> >at some silicon devices that are new to the market.  I expect the
> >board to have both a 32.768 kHz oscillator and a higher speed one,
> >likely either 24 or 25 or maybe 24.768 MHz.
>
> I was the more disappointed to read the claim of Chuck Moore
> of one year ago that he had implemented the one i/o one component
> crystal oscillator. Apparently nobody at GreenArrays took the
> trouble to even ask for the few screens and then publish it.

I read that someone at GA (may have been Chuck) had a 10 MHz crystal
ringing in the lab, but it was far from what I would consider a
crystal oscillator. I think it might be practical to get a 32 kHz
crystal to resonate, but I think MHz frequencies are just too high to
be practical. When I tried to discuss this in a non-forth forum some
real experts in oscillators didn't even know how to approach it. In
other words, no one knew how to analyze it. So how could the
stability and operation over temperature, etc be predicted?

For now I'll just stick with off the shelf oscillators.

> >> 6. External SRAM for the GA144, similar to GA's own eval board
>
> >With the limited internal ram, yes, external RAM is required.  I find
> >it interesting that with the internal word size being 18 bits, the GA
> >eval board and SRAM board have 16 bit memory.  I looked for 18 bit
> >memory, but it seems to be very expensive now.  At one time it was
> >quite common and not so expensive.
>
> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.

I have no idea what a 16 bit CAS 16 bit RAS memory is. Are you
talking about SDRAM, DDR or DDR2? What are the 16 bits?

> Using this kind of cheap memory 4 Gbyte would not be much slower
> than the bit-banging that is done now.

Slower??? In app note 3, fast static ram runs at 5 MHz cycle times.
I think even 133 MHz SDRAM can run about 5 times faster than this
while doing single word accesses. I might use an SDRAM rather than an
SRAM. I'll need to look at a few issues though.

> So I want a 32 bit eForth
> with 4 Gbyte addressable memory before I would even consider
> using an ISO Forth on the GA144. This could use cheap discarded
> memory from PC's, by the way.

Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
of scrounging PC's at the dump for memory is a bit funny. I think a
$4 SRAM or SDRAM chip will do the job ok.

> There is one thing left to do. As this chip is only interesting
> to hobbyists and experimenters, the default version should come
> with solderable pins.

I'm not making a chip. I'm making a board. The chips will already be
soldered to the board. The I/O will use 0.1 inch spaced pins for
standard connectors.

I'm hoping that this board will be useful for people who want to
develop applications that aren't so easy to do with the eval board
from GA.

Rick

[Albert van der Horst]

In article <5eb4fce2-726b-4dfe...@hv2g2000vbb.googlegroups.com>,

rickman <gnu...@gmail.com> wrote:
>> >> 6. External SRAM for the GA144, similar to GA's own eval board
>>

>> >With the limited internal ram, yes, external RAM is required. =A0I find

>> >it interesting that with the internal word size being 18 bits, the GA

>> >eval board and SRAM board have 16 bit memory. =A0I looked for 18 bit
>> >memory, but it seems to be very expensive now. =A0At one time it was

>> >quite common and not so expensive.
>>
>> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
>
>I have no idea what a 16 bit CAS 16 bit RAS memory is. Are you
>talking about SDRAM, DDR or DDR2? What are the 16 bits?

All the dynamic ram chips, since the 4016 16K times 1 , use
a multiplexing for the row and column addressing, so 16K amounts
to 7 Row Addres Strobe lines and & 7 Column Address Strobe lines
on the same pins.
Virtually all EDO ...DDR3 has this mechanisme.

>
>
>> Using this kind of cheap memory 4 Gbyte would not be much slower
>> than the bit-banging that is done now.
>
>Slower??? In app note 3, fast static ram runs at 5 MHz cycle times.
>I think even 133 MHz SDRAM can run about 5 times faster than this
>while doing single word accesses. I might use an SDRAM rather than an
>SRAM. I'll need to look at a few issues though.

With the need to multiplex the CAS and RAS strobes by hand from the
GA144 speed might suffer a bit.
But we are in the unique situation
that we dedicate a whole processor to the memory interface.
This approach saves half of the address lines and money.
The lines are used better.

>
>
>> So I want a 32 bit eForth
>> with 4 Gbyte addressable memory before I would even consider
>> using an ISO Forth on the GA144. This could use cheap discarded
>> memory from PC's, by the way.
>
>Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
>much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
>of scrounging PC's at the dump for memory is a bit funny. I think a
>$4 SRAM or SDRAM chip will do the job ok.

PDA's tables and cell phones have not the data processing capability
of a GA144. So the GA144 needs more data to process.
When the 16G and 256 Gb arrive, we should use that,
17 and 18 bits CAS/RAS strobes. At 18 bits 256G there may be a
natural limit for the GA144 though.

<SNIP>

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> With the limited internal ram, yes, external RAM is required. I find
> it interesting that with the internal word size being 18 bits, the GA
> eval board and SRAM board have 16 bit memory. I looked for 18 bit
> memory, but it seems to be very expensive now. At one time it was
> quite common and not so expensive.

Albert mentioned PC memory, and it occurs to me, PC memory is almost
always DIMM format, 32 bits wide (consumer PC's) or 36 bits(?)
(workstations and servers, for ECC). Maybe you could use a 36 bit
module as two 18 bit words, or even use a 32 bit module as 18 bit
memory, simply discarding 14 of the bits.

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> 1. Crystal oscillator (controlled by GA node or otherwise)
> I'm very disappointed in the lack of a follow up on the oscillator

> app... until that happens the oscillator will be a self contained
> unit. I expect the board to have both a 32.768 kHz oscillator and a

> higher speed one, likely either 24 or 25 or maybe 24.768 MHz.

Sounds good, if the cpu's can keep up with that. I would have thought
100 khz or 1 mhz to be a good speed, with a software PLL to multiply it
up if necessary. Dividing it down is easy.

>
> The trouble with isolated I/O is the board space and the wide range of

OK.

>> 3. Control processor (i.e. traditional cheap microcontroller)
>

> I'm not clear why an MCU would be needed for this rather than using
> the self boot feature of the GA144. Any processor you add would need
> to be upgradable, by this rational, requiring yet another processor.

Conventional MCU's are easier to program is the main reason. For
example, you want ethernet on the board. Are you planning to code a
TCP/IP stack for the GA144? If not, you want a conventional cpu
available (or an fpga that can run a softcore). (Hmm, maybe there is a
TCP/IP in eforth that can run on the GA virtual machine). I don't see
why the conventional cpu would have to be upgradeable, just that it
could run some reasonable code.

> My thinking is to provide an 8 bit wide on-the-go USB PHY.

I have the impression that USB needs a software stack almost as
complicated as TCP/IP, but I don't know much about it either.

>> 5. How about some op amps that could be used as level converters

> What range of levels are you thinking of?

I've forgotten why I asked about this, but yes, below 5v.

>
>> 7. Provision (pads on board) for high resolution (18 bit) ADC/DAC.

> The GA144 has unlimited resolution ADC and even DAC. There is a trade
> off between resolution and sample rate and is one of the things they
> did totally right on the GA144. I think this chip gives you just less
> than CD quality, about 15 bits at 48 ksps.

I think some audio users will find that insufficient. If anything they
really want 24/48, but in accurate 18/48 will allow the best reasonable
input for the GA144 to then implement signal processing on the samples.

> There isn't much GPIO really. If you use the memory interface for
> memory there are only 21 I/Os left. Makes it hard to interface to a
> lot of things.

Hmm, I didn't realize that the memory interface ate all the pins like
that. Maybe the memory bus can be narrower than 16 bits.

[Albert van der Horst]

In article <m1aax...@spenarnc.xs4all.nl>,

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

>In article <5eb4fce2-726b-4dfe...@hv2g2000vbb.googlegroups.com>,
>rickman <gnu...@gmail.com> wrote:
>>> >> 6. External SRAM for the GA144, similar to GA's own eval board
>>>
>>> >With the limited internal ram, yes, external RAM is required. =A0I find
>>> >it interesting that with the internal word size being 18 bits, the GA
>>> >eval board and SRAM board have 16 bit memory. =A0I looked for 18 bit
>>> >memory, but it seems to be very expensive now. =A0At one time it was
>>> >quite common and not so expensive.
>>>
>>> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
>>
>>I have no idea what a 16 bit CAS 16 bit RAS memory is. Are you
>>talking about SDRAM, DDR or DDR2? What are the 16 bits?
>
>All the dynamic ram chips, since the 4016 16K times 1 , use
>a multiplexing for the row and column addressing, so 16K amounts
>to 7 Row Addres Strobe lines and & 7 Column Address Strobe lines
>on the same pins.
>Virtually all EDO ...DDR3 has this mechanisme.

I looked it up. At Farnell for $7,34 in single quantity:
Hynix HSPS1G3EFR. This is a building block for PC memory.
A single chip will have 128 Mbyte.
It is conveniently organised as 64M * 16 bits.
I hope BGA doesn't scare you.
This chip could add serious punch to GA144.
It will cost 14 address lines, 12 CAS/RAS and 2 banks,
which leaves room for control lines.
It uses 2.5 V which makes direct connection possible.

There are tsop's too though and 1.8 V, but I have found only
32 Mbytes, which is still respectable.

If you reckon that it is about the same work to interface this
as what they have done now...

[hwf...@gmail.com]

On Wednesday, March 21, 2012 12:13:23 PM UTC-7, rickman wrote:
> I read that someone at GA (may have been Chuck) had a 10 MHz crystal
> ringing in the lab, but it was far from what I would consider a
> crystal oscillator. I think it might be practical to get a 32 kHz
> crystal to resonate, but I think MHz frequencies are just too high to
> be practical. When I tried to discuss this in a non-forth forum some
> real experts in oscillators didn't even know how to approach it. In
> other words, no one knew how to analyze it. So how could the
> stability and operation over temperature, etc be predicted?

I looked at this once and decided the I/O structure wasn't really sufficient to run a crystal oscillator with one pin. The problem is that you need to bias the pin near its switching point to decide which side of the voltage swing you're on.

Maybe a node could be programmed as an inverter with two pins and you'd have a feedback resistor like a typical oscillator.

>
> Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
> much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
> of scrounging PC's at the dump for memory is a bit funny. I think a
> $4 SRAM or SDRAM chip will do the job ok.
>

Mobile SDR SDRAM would be easiest to use. Not DDR2 or DDR3. There is no PLL in the SDR parts so the clock doesn't have to be a fixed period, or any minimum period as long as times are met. These parts don't have the PC market pushing down their prices, but they will be around for a long time. They also come in small sizes like 16Mb (2M byte).

[Paul Rubin]

hwf...@gmail.com writes:
> I looked at this once and decided the I/O structure wasn't really

> sufficient to run a crystal oscillator with one pin...

> Maybe a node could be programmed as an inverter with two pins and
> you'd have a feedback resistor like a typical oscillator.

Yes, two pins seems fine, one pin an unnecessary constraint.

> Mobile SDR SDRAM would be easiest to use... These parts don't have

> the PC market pushing down their prices, but they will be around for a
> long time. They also come in small sizes like 16Mb (2M byte).

But may still be rather expensive in absolute terms. Really I'm not
sure I even see a use for 2M of ram in a thing like this. The 256k (I
guess that's words rather than bytes) in the GA eval board seems like
more than plenty. As Bill Gates said, 640k should be enough for anybody
;-).

[rickman]

On Mar 22, 7:36 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <5eb4fce2-726b-4dfe-b699-8c1c59229...@hv2g2000vbb.googlegroups.com>,

>
> rickman <gnu...@gmail.com> wrote:
> >> >> 6. External SRAM for the GA144, similar to GA's own eval board
>
> >> >With the limited internal ram, yes, external RAM is required. =A0I find
> >> >it interesting that with the internal word size being 18 bits, the GA
> >> >eval board and SRAM board have 16 bit memory. =A0I looked for 18 bit
> >> >memory, but it seems to be very expensive now. =A0At one time it was
> >> >quite common and not so expensive.
>
> >> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
>
> >I have no idea what a 16 bit CAS 16 bit RAS memory is. Are you
> >talking about SDRAM, DDR or DDR2? What are the 16 bits?
>
> All the dynamic ram chips, since the 4016 16K times 1 , use
> a multiplexing for the row and column addressing, so 16K amounts
> to 7 Row Addres Strobe lines and & 7 Column Address Strobe lines
> on the same pins.
> Virtually all EDO ...DDR3 has this mechanisme.

Ok, so you want one of the SDRAM types of memory. You should have
said that instead of "16 bit CAS 16 bit RAS memory". I looked briefly
at controlling an SDRAM, but there are other control signals required
and it might be required to "steal" bits from both the address and
data busses. This will also slow down the interface. But at 700 MIPS
it shouldn't reduce it to 5 MHz transfer rate like the GA example.

> >> Using this kind of cheap memory 4 Gbyte would not be much slower
> >> than the bit-banging that is done now.
>
> >Slower??? In app note 3, fast static ram runs at 5 MHz cycle times.
> >I think even 133 MHz SDRAM can run about 5 times faster than this
> >while doing single word accesses. I might use an SDRAM rather than an
> >SRAM. I'll need to look at a few issues though.
>
> With the need to multiplex the CAS and RAS strobes by hand from the
> GA144 speed might suffer a bit.
> But we are in the unique situation
> that we dedicate a whole processor to the memory interface.
> This approach saves half of the address lines and money.
> The lines are used better.

I have not dug into the details of how they are controlling the
memory, but I find it hard to believe they need 140 instruction cycles
to interface to ram. Maybe they are using the native speed of the F18
node to time the interface and so must make it run very slow to assure
it doesn't exceed the timing specs due to speed variations. But
adding a clock to the design will mitigate that.

> >> So I want a 32 bit eForth
> >> with 4 Gbyte addressable memory before I would even consider
> >> using an ISO Forth on the GA144. This could use cheap discarded
> >> memory from PC's, by the way.
>
> >Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
> >much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
> >of scrounging PC's at the dump for memory is a bit funny. I think a
> >$4 SRAM or SDRAM chip will do the job ok.
>
> PDA's tables and cell phones have not the data processing capability
> of a GA144. So the GA144 needs more data to process.
> When the 16G and 256 Gb arrive, we should use that,
> 17 and 18 bits CAS/RAS strobes. At 18 bits 256G there may be a
> natural limit for the GA144 though.

The GA144 doesn't have the data processing capability of a GA144!
Saying the GA144 can run at 700 MIPS is an over statement since only
some instructions run that fast and most potential instruction cycles
will be wasted. This is not intended to be a number cruncher. The
amount of memory needed will depend on the app. What app are you
thinking of that requires 4 GB? High processing speeds and large
memories typically go with high I/O speeds too. The GA144 comes up
short in that way as well. But if you need a large memory, I'll see
if I can provide it.

Rick

[rickman]

On Mar 22, 1:50 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <m1aaxl....@spenarnc.xs4all.nl>,

> Albert van der Horst  <alb...@spenarnc.xs4all.nl> wrote:
>

> >In article <5eb4fce2-726b-4dfe-b699-8c1c59229...@hv2g2000vbb.googlegroups.com>,

> >rickman  <gnu...@gmail.com> wrote:
> >>> >> 6. External SRAM for the GA144, similar to GA's own eval board
>
> >>> >With the limited internal ram, yes, external RAM is required. =A0I find
> >>> >it interesting that with the internal word size being 18 bits, the GA
> >>> >eval board and SRAM board have 16 bit memory. =A0I looked for 18 bit
> >>> >memory, but it seems to be very expensive now. =A0At one time it was
> >>> >quite common and not so expensive.
>
> >>> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
>
> >>I have no idea what a 16 bit CAS 16 bit RAS memory is.  Are you
> >>talking about SDRAM, DDR or DDR2?  What are the 16 bits?
>
> >All the dynamic ram chips, since the 4016 16K times 1 , use
> >a multiplexing for the row and column addressing, so 16K amounts
> >to 7 Row Addres Strobe lines and & 7 Column Address Strobe lines
> >on the same pins.
> >Virtually all EDO ...DDR3 has this mechanisme.
>
> I looked it up. At Farnell for $7,34 in single quantity:
> Hynix HSPS1G3EFR. This is a building block for PC memory.
> A single chip will have 128 Mbyte.
> It is conveniently organised as 64M * 16 bits.
> I hope BGA doesn't scare you.
> This chip could add serious punch to GA144.
> It will cost 14 address lines, 12 CAS/RAS and 2 banks,
> which leaves room for control lines.
> It uses 2.5 V which makes direct connection possible.

I can't find this part using Google or Digikey and the part number
does not result in any hits in a search on the Hynix page. Is this a
Farnell number rather than a Hynix number? Looking at the Hynix web
page I can't even find info on the BGA package they use. It may well
be a hard part to design with using less expensive technology. The
memory part GA uses can be routed without micro-vias and can use 6 mil
trace/space rules. I'll see what I can find elsewhere.

> There are tsop's too though and 1.8 V, but I have found only
> 32 Mbytes, which is still respectable.

TSSOPs are huge by comparison.

> If you reckon that it is about the same work to interface this
> as what they have done now...

Are you volunteering to do the software?

What is your app?

Rick

[rickman]

On Mar 22, 4:07 pm, Paul Rubin <no.em...@nospam.invalid> wrote:

> hwfw...@gmail.com writes:
> > I looked at this once and decided the I/O structure wasn't really
> > sufficient to run a crystal oscillator with one pin...
> > Maybe a node could be programmed as an inverter with two pins and
> > you'd have a feedback resistor like a typical oscillator.
>
> Yes, two pins seems fine, one pin an unnecessary constraint.

I'd love to see someone make this work. In the meantime I'm adding
oscillators to the design.

> > Mobile SDR SDRAM would be easiest to use... These parts don't have
> > the PC market pushing down their prices, but they will be around for a
> > long time. They also come in small sizes like 16Mb (2M byte).
>
> But may still be rather expensive in absolute terms.  Really I'm not
> sure I even see a use for 2M of ram in a thing like this.  The 256k (I
> guess that's words rather than bytes) in the GA eval board seems like
> more than plenty.  As Bill Gates said, 640k should be enough for anybody
> ;-).

Map data. Think of a hand held GPS with many other capabilities like
2 way radio and weather alerts. That is my ultimate goal.

Rick

[Richard Owlett]

hwf...@gmail.com wrote:
> [snip] They also come in small sizes like 16Mb (2M byte).

In FORTH is it common for 2==16 ?
I SUSPECT that this is an example of of why some prefer term
"octet".

OWL now _ducks_ for cover ;/

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> Really I'm not sure I even see a use for 2M of ram >

> Map data. Think of a hand held GPS with many other capabilities like
> 2 way radio and weather alerts. That is my ultimate goal.

That wants flash rather than ram. An SDHC card socket communicating
through gpio pins is probably fine. The interface is just 4 bits wide,
or even 1 bit wide in the old MMC/SD format.

[rickman]

On Mar 22, 3:25 pm, hwfw...@gmail.com wrote:
> On Wednesday, March 21, 2012 12:13:23 PM UTC-7, rickman wrote:
> > I read that someone at GA (may have been Chuck) had a 10 MHz crystal
> > ringing in the lab, but it was far from what I would consider a
> > crystal oscillator.  I think it might be practical to get a 32 kHz
> > crystal to resonate, but I think MHz frequencies are just too high to
> > be practical.  When I tried to discuss this in a non-forth forum some
> > real experts in oscillators didn't even know how to approach it.  In
> > other words, no one knew how to analyze it.  So how could the
> > stability and operation over temperature, etc be predicted?
>
> I looked at this once and decided the I/O structure wasn't really sufficient to run a crystal oscillator with one pin. The problem is that you need to bias the pin near its switching point to decide which side of the voltage swing you're on.
>
> Maybe a node could be programmed as an inverter with two pins and you'd have a feedback resistor like a typical oscillator.

Read the GA oscillator app note and then tell me if you can make it
work at 133 MHz. They haven't make it work at 10 MHz yet.

> > Isn't 4 GB a bit much?  PDA's, tablets and cell phones don't have that
> > much memory!  Geeze, this PC I am typing on only has 4 GB!!!  The idea
> > of scrounging PC's at the dump for memory is a bit funny.  I think a
> > $4 SRAM or SDRAM chip will do the job ok.
>
> Mobile SDR SDRAM would be easiest to use. Not DDR2 or DDR3. There is no PLL in the SDR parts so the clock doesn't have to be a fixed period, or any minimum period as long as times are met. These parts don't have the PC market pushing down their prices, but they will be around for a long time. They also come in small sizes like 16Mb (2M byte).

Yep. Mobile has a slight edge in power as well.

Rick

[rickman]

On Mar 22, 11:52 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:
> >> 1. Crystal oscillator (controlled by GA node or otherwise)
> > I'm very disappointed in the lack of a follow up on the oscillator
> > app...  until that happens the oscillator will be a self contained
> > unit.  I expect the board to have both a 32.768 kHz oscillator and a
> > higher speed one, likely either 24 or 25 or maybe 24.768 MHz.
>
> Sounds good, if the cpu's can keep up with that.  I would have thought
> 100 khz or 1 mhz to be a good speed, with a software PLL to multiply it
> up if necessary.  Dividing it down is easy.

If the software can't keep up with a 25 MHz oscillator why bother with
a PLL? I think a 700 MIPS processor use a 25 MHz clock to control its
operations.

> > The trouble with isolated I/O is the board space and the wide range of
>
> OK.
>
> >> 3. Control processor (i.e. traditional cheap microcontroller)
>
> > I'm not clear why an MCU would be needed for this rather than using
> > the self boot feature of the GA144.  Any processor you add would need
> > to be upgradable, by this rational, requiring yet another processor.
>
> Conventional MCU's are easier to program is the main reason.  For
> example, you want ethernet on the board.  Are you planning to code a
> TCP/IP stack for the GA144?  If not, you want a conventional cpu
> available (or an fpga that can run a softcore).  (Hmm, maybe there is a
> TCP/IP in eforth that can run on the GA virtual machine).  I don't see
> why the conventional cpu would have to be upgradeable, just that it
> could run some reasonable code.

I'm looking for participants to code the software.

> > My thinking is to provide an 8 bit wide on-the-go USB PHY.
>
> I have the impression that USB needs a software stack almost as
> complicated as TCP/IP, but I don't know much about it either.

Yep, that's what I am told too. More participants.

> >> 5. How about some op amps that could be used as level converters
> > What range of levels are you thinking of?
>
> I've forgotten why I asked about this, but yes, below 5v.
>
>
>
> >> 7. Provision (pads on board) for high resolution (18 bit) ADC/DAC.
> > The GA144 has unlimited resolution ADC and even DAC.  There is a trade
> > off between resolution and sample rate and is one of the things they
> > did totally right on the GA144.  I think this chip gives you just less
> > than CD quality, about 15 bits at 48 ksps.
>
> I think some audio users will find that insufficient.  If anything they
> really want 24/48, but in accurate 18/48 will allow the best reasonable
> input for the GA144 to then implement signal processing on the samples.

Yes, high end audio specs are better than this, but end user audio
products are seldom better or even as good.

> > There isn't much GPIO really.  If you use the memory interface for
> > memory there are only 21 I/Os left.  Makes it hard to interface to a
> > lot of things.
>
> Hmm, I didn't realize that the memory interface ate all the pins like
> that.  Maybe the memory bus can be narrower than 16 bits.

The memory interface *IS* the I/O. They just didn't add much I/O
other than memory. Memory isn't usable in the same way either, like
edge detection I believe.

Rick

[Richard Owlett]

rickman wrote:
> What would you like to see on a GA144 application board? I am
> thinking of building a board which would have enough buffered analog
> input and output for the 5 ADC and DAC I/Os as well as buffered I/O

> for a number of digital I/Os, around 8 to 12 each. ...
>
> [*LARGE* snip]

I've been lightly following this thread. I don't believe the
GA144 is "aimed at"/"suitable for" problems I'm currently
interested in. I also do not claim the programming expertise
to address the problem of moving data and/or calculations
between cores/nodes/???.

Physical hardware, much more fascinating ;)
I suspect that are not only the "wrong" questions being
asked, but assumptions might also be "wrong". N.B. generous
use of "..." .

Dubious assumptions:
- homogeneity of c.l.f.
SECT1 - immediate high volume use - 1000's per ???
SECT1a - immediate volume use - 100's per ??/N
SECT2 - immediate low volume use - semi/full custom apps
SECT3a - near future use for semi/full custom apps
SECT3b1 - experimenter use
SECT3b2 - Hobbyist
- even when above (& other) differences are recognized
the initial needs of all groups (AND sub-groups) are very
similar (~==)

A proposed (possibly naive) solution _framework_
- CPU card with
RAM
ROM &/or PROM
unity gain analog buffers
{before some squawk - open traces which can be closed
are tradition ;)
- I/O card (w buffers)
- Memory card (ROM RAM OTHER{why might a TB drive not be
memory???)
- Analog I/O card (Think before complaining - I'm proposing
a philosophy NOT an implementation ;/

[Albert van der Horst]

In article <50fb1a46-ceea-43a5...@l7g2000vbw.googlegroups.com>,
rickman <gnu...@gmail.com> wrote:
>On Mar 22, 1:50=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>

>wrote:
>> In article <m1aaxl....@spenarnc.xs4all.nl>,

>> Albert van der Horst =A0<alb...@spenarnc.xs4all.nl> wrote:
>>
>> >In article <5eb4fce2-726b-4dfe-b699-8c1c59229...@hv2g2000vbb.googlegroup=
>s.com>,

>> >rickman =A0<gnu...@gmail.com> wrote:
>> >>> With 18 bits you should interface a 16 bit CAS 16 bit RAS memory.
>>

>> >>I have no idea what a 16 bit CAS 16 bit RAS memory is. =A0Are you
>> >>talking about SDRAM, DDR or DDR2? =A0What are the 16 bits?

>>
>> >All the dynamic ram chips, since the 4016 16K times 1 , use
>> >a multiplexing for the row and column addressing, so 16K amounts
>> >to 7 Row Addres Strobe lines and & 7 Column Address Strobe lines
>> >on the same pins.
>> >Virtually all EDO ...DDR3 has this mechanisme.
>>
>> I looked it up. At Farnell for $7,34 in single quantity:
>> Hynix HSPS1G3EFR. This is a building block for PC memory.
>> A single chip will have 128 Mbyte.
>> It is conveniently organised as 64M * 16 bits.
>> I hope BGA doesn't scare you.
>> This chip could add serious punch to GA144.
>> It will cost 14 address lines, 12 CAS/RAS and 2 banks,
>> which leaves room for control lines.
>> It uses 2.5 V which makes direct connection possible.
>
>I can't find this part using Google or Digikey and the part number
>does not result in any hits in a search on the Hynix page. Is this a
>Farnell number rather than a Hynix number? Looking at the Hynix web
>page I can't even find info on the BGA package they use. It may well
>be a hard part to design with using less expensive technology. The
>memory part GA uses can be routed without micro-vias and can use 6 mil
>trace/space rules. I'll see what I can find elsewhere.

Just start Farnell and select down to IC and memory. There are
1000's of chips to select from. I spend hours comparing them.
The nice thing of Farnell, that in a pinch, they are willing to
deliver to private persons in single quantities. (It'll cost you,
though, and the risk is all yours.)

>
>
>> There are tsop's too though and 1.8 V, but I have found only
>> 32 Mbytes, which is still respectable.
>
>TSSOPs are huge by comparison.

1 cm by 2.2 cm. Is that a concern? If the proto runs, we could
switch to BGA.

>
>> If you reckon that it is about the same work to interface this
>> as what they have done now...
>
>Are you volunteering to do the software?

I could be interested, certainly. I'm working with Leon Konings
who is doing a development environment in Factor. T

>
>What is your app?

I see no applications. I'm the author of parpi: a parallel prime
counter, which is a demo program/proof of principle.

[Albert van der Horst]

In article <6671227.141.1332444346642.JavaMail.geo-discussion-forums@ynjx8>,

<hwf...@gmail.com> wrote:
>On Wednesday, March 21, 2012 12:13:23 PM UTC-7, rickman wrote:
>> I read that someone at GA (may have been Chuck) had a 10 MHz crystal
>> ringing in the lab, but it was far from what I would consider a
>> crystal oscillator. I think it might be practical to get a 32 kHz
>> crystal to resonate, but I think MHz frequencies are just too high to
>> be practical. When I tried to discuss this in a non-forth forum some
>> real experts in oscillators didn't even know how to approach it. In
>> other words, no one knew how to analyze it. So how could the
>> stability and operation over temperature, etc be predicted?
>

>I looked at this once and decided the I/O structure wasn't really sufficien=
>t to run a crystal oscillator with one pin. The problem is that you need to=
> bias the pin near its switching point to decide which side of the voltage =
>swing you're on.

Remember the professors who claimed a device heavier than air couldn't
fly? Your reasoning is trumped by the claim of a respectable person
(i.c. Chuck Moore) to the contrary. Do you even realise that between
clock cycles the io pin can be switched from upgoing triggers to
downgoing triggers?

>
>Maybe a node could be programmed as an inverter with two pins and you'd hav=

>e a feedback resistor like a typical oscillator.
>>
>> Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
>> much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
>> of scrounging PC's at the dump for memory is a bit funny. I think a
>> $4 SRAM or SDRAM chip will do the job ok.

>>=20
>Mobile SDR SDRAM would be easiest to use. Not DDR2 or DDR3. There is no PLL=
> in the SDR parts so the clock doesn't have to be a fixed period, or any mi=
>nimum period as long as times are met. These parts don't have the PC market=
> pushing down their prices, but they will be around for a long time. They a=

>lso come in small sizes like 16Mb (2M byte).

This is useful information. I'm not sure whether it is such a big
problem to have a clock if need be, but synchronous operation is much
easier.

W.r.t. the size of memory. It is one of the things that holds the
GA144 down. The less of these things there are the more applications
are possible.

[Albert van der Horst]

In article <7xobro3...@ruckus.brouhaha.com>,

You missed something. PC memory is modules consisting of chips.
We are talking the chips here, and they come in 16-bit wide versions.

[Albert van der Horst]

In article <6671227.141.1332444346642.JavaMail.geo-discussion-forums@ynjx8>,
<hwf...@gmail.com> wrote:

>On Wednesday, March 21, 2012 12:13:23 PM UTC-7, rickman wrote:
>> I read that someone at GA (may have been Chuck) had a 10 MHz crystal
>> ringing in the lab, but it was far from what I would consider a
>> crystal oscillator. I think it might be practical to get a 32 kHz
>> crystal to resonate, but I think MHz frequencies are just too high to
>> be practical. When I tried to discuss this in a non-forth forum some
>> real experts in oscillators didn't even know how to approach it. In
>> other words, no one knew how to analyze it. So how could the
>> stability and operation over temperature, etc be predicted?
>

>I looked at this once and decided the I/O structure wasn't really sufficien=
>t to run a crystal oscillator with one pin. The problem is that you need to=
> bias the pin near its switching point to decide which side of the voltage =
>swing you're on.
>
>Maybe a node could be programmed as an inverter with two pins and you'd hav=

>e a feedback resistor like a typical oscillator.
>>
>> Isn't 4 GB a bit much? PDA's, tablets and cell phones don't have that
>> much memory! Geeze, this PC I am typing on only has 4 GB!!! The idea
>> of scrounging PC's at the dump for memory is a bit funny. I think a
>> $4 SRAM or SDRAM chip will do the job ok.

>>=20
>Mobile SDR SDRAM would be easiest to use. Not DDR2 or DDR3. There is no PLL=
> in the SDR parts so the clock doesn't have to be a fixed period, or any mi=
>nimum period as long as times are met. These parts don't have the PC market=
> pushing down their prices, but they will be around for a long time. They a=

>lso come in small sizes like 16Mb (2M byte).

Aren't we talking about obsolete parts. My 2001 laptop has
K4H5616 Samsung chips that look like ddr2 to me.


This is what we miss iff we don't follow the flow:

http://uk.farnell.com/hynix-semiconductor/h5ps5162gfr-s6c/sdram-ddr2-512mb-x16-84fbga/dp/2078288

It need not get to go any better than $3.01 for a 64Mbyte part for me.
Single quantities, this part is "awaiting delivery" though.
You can order already.

(The programming effort is one time.)

[rickman]

On Mar 22, 5:54 pm, Richard Owlett <rowl...@pcnetinc.com> wrote:

2 M BYTE = 16 M BIT, the lower case 'b' usually implies bits, not
bytes.

Or are you just joking?

Rick

[rickman]

On Mar 23, 8:24 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <50fb1a46-ceea-43a5-91c4-23180cb4c...@l7g2000vbw.googlegroups.com>,

>
> rickman  <gnu...@gmail.com> wrote:
>
> >On Mar 22, 1:50=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> >wrote:

...snip....

> >I can't find this part using Google or Digikey and the part number
> >does not result in any hits in a search on the Hynix page.  Is this a
> >Farnell number rather than a Hynix number?  Looking at the Hynix web
> >page I can't even find info on the BGA package they use.  It may well
> >be a hard part to design with using less expensive technology.  The
> >memory part GA uses can be routed without micro-vias and can use 6 mil
> >trace/space rules.  I'll see what I can find elsewhere.
>
> Just start Farnell and select down to IC and memory. There are
> 1000's of chips to select from. I spend hours comparing them.
> The nice thing of Farnell, that in a pinch, they are willing to
> deliver to private persons in single quantities. (It'll cost you,
> though, and the risk is all yours.)

Farnell is EU and I am USA. We hae Digikey and Mouser, both with good
parts search engines. I prefer Digikey and have a company account,
never a delivery problem. In fact, I've discovered that US Mail
Priority mail is faster for me than UPS and cheaper too!

> >> There are tsop's too though and 1.8 V, but I have found only
> >> 32 Mbytes, which is still respectable.
>
> >TSSOPs are huge by comparison.
>
> 1 cm by 2.2 cm. Is that a concern? If the proto runs, we could
> switch to BGA.

A BGA is under 1 cm square. That is their reason for existence since
everything else about them is a PITA. It all depends on how
accessible they make the balls on the BGA.

> >> If you reckon that it is about the same work to interface this
> >> as what they have done now...
>
> >Are you volunteering to do the software?
>
> I could be interested, certainly. I'm working with Leon Konings
> who is doing a development environment in Factor. T

This project has two faces. One is as a "cape" board (daughter card)
for a BeagleBone. The other is as a stand alone board using the
GA144. Since the GA144 is $20 each, I may even leave it and the
memory off for the BB option where it will just be an I/O board.

> >What is your app?
>
> I see no applications. I'm the author of parpi: a parallel prime
> counter, which is a demo program/proof of principle.

I am looking for apps so I can tailor the board to as many needed apps
as I can.

Rick

[rickman]

On Mar 23, 8:34 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <6671227.141.1332444346642.JavaMail.geo-discussion-forums@ynjx8>,

>
>  <hwfw...@gmail.com> wrote:
> >On Wednesday, March 21, 2012 12:13:23 PM UTC-7, rickman wrote:
> >> I read that someone at GA (may have been Chuck) had a 10 MHz crystal
> >> ringing in the lab, but it was far from what I would consider a
> >> crystal oscillator.  I think it might be practical to get a 32 kHz
> >> crystal to resonate, but I think MHz frequencies are just too high to
> >> be practical.  When I tried to discuss this in a non-forth forum some
> >> real experts in oscillators didn't even know how to approach it.  In
> >> other words, no one knew how to analyze it.  So how could the
> >> stability and operation over temperature, etc be predicted?
>
> >I looked at this once and decided the I/O structure wasn't really sufficien=
> >t to run a crystal oscillator with one pin. The problem is that you need to=
> > bias the pin near its switching point to decide which side of the voltage =
> >swing you're on.
>
> Remember the professors who claimed a device heavier than air couldn't
> fly? Your reasoning is trumped by the claim of a respectable person
> (i.c. Chuck Moore) to the contrary. Do you even realise that between
> clock cycles the io pin can be switched from upgoing triggers to
> downgoing triggers?

"Claim"??? What claim? What I read was that they can drive a 32 kHz
crystal to ring (not the same as oscillate) and could NOT get a 10 MHz
crystal to even ring without hand tuning the processor speed by
varying the voltage or something similar. Using instructions for
timing doesn't provide enough resolution to ping the crystal at a
frequency within its operating range. Crystals are typically 200 ppm
or better.

If Chuck or anyone else has said they have this working like a
***real*** oscillator I would like to see that. They seem to be
keeping such info a big secret.

> >Mobile SDR SDRAM would be easiest to use. Not DDR2 or DDR3. There is no PLL=
> > in the SDR parts so the clock doesn't have to be a fixed period, or any mi=
> >nimum period as long as times are met. These parts don't have the PC market=
> > pushing down their prices, but they will be around for a long time. They a=
> >lso come in small sizes like 16Mb (2M byte).
>
> This is useful information. I'm not sure whether it is such a big
> problem to have a clock if need be, but synchronous operation is much
> easier.
>
> W.r.t. the size of memory. It is one of the things that holds the
> GA144 down. The less of these things there are the more applications
> are possible.

In theory, but what apps are you talking about? Why deal with pie in
the sky rather than real information? That is why I keep asking about
apps. EVERYTHING has a tradeoff. I'm not going to add huge memory on
an MCU if there are no apps for it.

Rick

[rickman]

I think it needs both. The Flash will be there as an SD card socket
for map data (no difference electrically with SD and SDHC, just
software). But RAM will be needed. The GA144 just doesn't have
enough to do much at all.

The SD card is 4 bit data path, with a couple/three more for control.
That's a pig in terms of GA144 I/O but it is necessary. There are
only a couple of nodes with 4 bits of I/O and one is the memory
controller... yet another shortcoming of the GA144. But it is still
practical and useful.

Rick

[rickman]

I'm not sure what to say about your post. Most of it is sentence
fragments and does not really convey your intention so I can
understand it.

What are you trying to say?

Rick

[Roger Ivie]

On 2012-03-23, rickman <gnu...@gmail.com> wrote:
> Farnell is EU and I am USA. We hae Digikey and Mouser, both with good
> parts search engines. I prefer Digikey and have a company account,
> never a delivery problem. In fact, I've discovered that US Mail
> Priority mail is faster for me than UPS and cheaper too!

The US outlet of Farnell is Newark. I only know this because of
the recent Raspberry Pi hoopla.

It looks to me like there were a couple of typos in the part number;
near as I can tell, the part number should have actually been
H5PS1G63EFR instead of HSPS1G3EFR. The Newark page is here:

http://www.newark.com/hynix-semiconductor/h5ps1g63efr-s6c/sdram-ddr2-1gb-x16-84fbga/dp/58T1894

--
roger ivie
ri...@ridgenet.net

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> I think it needs both. The Flash will be there as an SD card socket
> for map data (no difference electrically with SD and SDHC, just
> software). But RAM will be needed. The GA144 just doesn't have
> enough to do much at all.

Sure, ram is needed, it's just not clear how to use gigabytes of ram
with such a slow interface.

> The SD card is 4 bit data path, with a couple/three more for control.
> That's a pig in terms of GA144 I/O but it is necessary.

I thought SD still supports the 1 bit MMC mode.

[rickman]

> http://www.newark.com/hynix-semiconductor/h5ps1g63efr-s6c/sdram-ddr2-...
>
> --
> roger ivie
> ri...@ridgenet.net

Thanks for the clarification.

This is a DDR2 device using SSTL logic level interfaces, not supported
by the GA144. I am not interested in analyzing this with the GA144 to
see if it can be kludged. I don't think the GA144 data sheet provides
enough info. I'll take a look at SDRAM and DDR when I get a chance.

Rick

[rickman]

I believe so, but I haven't looked at it in detail. I seem to recall
the SD spec is a closed spec and costs serious bucks.

Certainly the speed is impacted in 1 bit mode. I would provide a full
interface, I'm just saying that there will be more than one node
involved and they aren't likely to be side by side.

I need some time to look at the pin assignments in aggregate and see
what will work best.

Rick

[Jan Coombs]

On 24/03/12 19:01, rickman wrote:
> I believe so, but I haven't looked at it in detail. I seem to recall
> the SD spec is a closed spec and costs serious bucks.

I have:

SD Specifications Part 1 Physical Layer Simplified Specification
Version 2.00 September 25, 2006
Simplified_Physical_Layer_Spec.pdf 1.1MB

SD Media Format Expands the MAXQ2000's Space for Nonvolatile
Data Storage
AN3969__Maxim-SDaccess.pdf 121kB
[Maxim app note 3969, 2007 - outlines normal and SPI mode access]

Let me know if you'd like them mailed or posted somewhere.

Jan Coombs.

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> I thought SD still supports the 1 bit MMC mode.
> I believe so, but I haven't looked at it in detail. I seem to recall
> the SD spec is a closed spec and costs serious bucks.

The closed part of the spec is the "secure" part, dealing with media
copy protection, that it turns out basically nobody uses. The other
parts (the parts anyone cares about) are open.

> Certainly the speed is impacted in 1 bit mode. I would provide a full
> interface, I'm just saying that there will be more than one node
> involved and they aren't likely to be side by side.

The 1 bit mode is probably fine for loading programs and parameters into
the GA, or for copying chunks of code into an external ram at bootup.
It may be too slow for doing lots of bulk data transfers.

I think for GPS navigation, it might make sense to use the GA144 for the
signal handling, but you're probably better off with a conventional CPU
for dealing with stuff like maps.

[rickman]

On Mar 24, 6:27 pm, Jan Coombs <jan_2011...@murray-microft.co.uk>
wrote:

Thanks a lot Jan. Using the title you provided I was able to find the
2006 spec at a Freescale web page. Excellent!

Rick

[rickman]

Thanks, I guess that makes sense, the security spec would be handled
differently.

We'll find out what works well for a GPS app. I can't imagine that a
700 MIPS processor with 100+ MHz DRAM can't run as fast as the 25 MHz
ARM7 in my current GPS reciever, although it is clearly speed limited
when viewing moving maps in the tiny display. I would like to have a
larger display, maybe 5 inches and with e-Ink technology (I assume it
can support a 1 second update rate). I saw a Kindle and was VERY
impressed with the clarity and contrast of the display not to mention
the low power aspects of it.

Rick

[Albert van der Horst]

In article <29c5b9f9-65da-44ed...@eb6g2000vbb.googlegroups.com>,
rickman <gnu...@gmail.com> wrote:

>On Mar 23, 2:15=A0pm, Roger Ivie <ri...@ridgenet.net> wrote:
>> On 2012-03-23, rickman <gnu...@gmail.com> wrote:
>>

>> > Farnell is EU and I am USA. =A0We hae Digikey and Mouser, both with goo=
>d
>> > parts search engines. =A0I prefer Digikey and have a company account,
>> > never a delivery problem. =A0In fact, I've discovered that US Mail

>> > Priority mail is faster for me than UPS and cheaper too!
>>
>> The US outlet of Farnell is Newark. I only know this because of
>> the recent Raspberry Pi hoopla.
>>
>> It looks to me like there were a couple of typos in the part number;
>> near as I can tell, the part number should have actually been
>> H5PS1G63EFR instead of HSPS1G3EFR. The Newark page is here:
>>
>> http://www.newark.com/hynix-semiconductor/h5ps1g63efr-s6c/sdram-ddr2-...
>>
>> --
>> roger ivie
>> ri...@ridgenet.net
>
>Thanks for the clarification.
>
>This is a DDR2 device using SSTL logic level interfaces, not supported
>by the GA144. I am not interested in analyzing this with the GA144 to
>see if it can be kludged. I don't think the GA144 data sheet provides
>enough info. I'll take a look at SDRAM and DDR when I get a chance.

I don't know what SSTL is. I surely don't want interfaces.
I expect that a 2.5 V chip can be connected directly to the GA144.
We are not talking ECL here!
I'm sure that a 1.8 V chip can be connected directly to the GA144.
I have found several.

It is you who insists on talking about DDR2 devices. I'm talking
about loose chips that are present on memory expansion cards.
I read the specs of the chips. That is why I'm talking about
CAS and RAS instead of DDR2 and such.

>
>Rick

[rickman]

On Mar 25, 8:06 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <29c5b9f9-65da-44ed-aacb-0baaa9130...@eb6g2000vbb.googlegroups.com>,

You picked the HSPS1G3EFR if I remember correctly. This is a non-
existent part as far as I can tell. Roger was nice enough to
translate that into the H5PS1G63EFR which is a real device, a real
DDR2 device, with a RAS and a CAS and all the other signals that all
DRAM devices have... ALL DRAM devices since the original async DRAMs
to present DDR3 devices. This part uses a differential clock along
with four other differential inputs. The GA144 does not have any
differential drivers and although it may be possible to fake a
differential driver by using two single ended outputs, it will be hard
to time align them. In other words, this is not a part anyone would
use with the GA144 unless they had to.

If you feel this chip is the right chip to use with the GA144, please
design a board for it. I don't care for the package as it requires 4
mil space and 4 mil trace design rules to break out the signals. It
makes the board production and prototyping more expensive which is a
cost I'm not going to bear.

We'll find a better part.

rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> We'll find out what works well for a GPS app. I can't imagine that a
> 700 MIPS processor with 100+ MHz DRAM can't run as fast as the 25 MHz
> ARM7 in my current GPS reciever, although it is clearly speed limited
> when viewing moving maps in the tiny display.

The GA's internal 64-word SRAM runs at around 100 mhz or a little
faster. If the GA application note is any indication, external ram will
be an order of magnitude slower. Note that the GA already has a 3-node
external SRAM controller, i.e. special purpose ROM code in those 3
nodes, so it's probably easiest to just use that, along with the circuit
and chip that they recommend. That gives 256k 16-bit words of external
SRAM, I think. It's conveniently set up for access through eforth
running in a VM that's in the ROM of some adjacent nodes.

> I would like to have a larger display, maybe 5 inches and with e-Ink
> technology (I assume it can support a 1 second update rate). I saw a
> Kindle and was VERY impressed with the clarity and contrast of the
> display not to mention the low power aspects of it.

For GPS, color probably makes it a lot nicer. On the cpu side, it's
probably a lot easier to write the map handling code in a scripting
language with lists, garbage collection, etc. That's part of the
purpose of a separate cpu for the map stuff.

[rickman]

On Mar 25, 4:06 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:
> > We'll find out what works well for a GPS app. I can't imagine that a
> > 700 MIPS processor with 100+ MHz DRAM can't run as fast as the 25 MHz
> > ARM7 in my current GPS reciever, although it is clearly speed limited
> > when viewing moving maps in the tiny display.
>
> The GA's internal 64-word SRAM runs at around 100 mhz or a little
> faster. If the GA application note is any indication, external ram will
> be an order of magnitude slower. Note that the GA already has a 3-node
> external SRAM controller, i.e. special purpose ROM code in those 3
> nodes, so it's probably easiest to just use that, along with the circuit
> and chip that they recommend. That gives 256k 16-bit words of external
> SRAM, I think. It's conveniently set up for access through eforth
> running in a VM that's in the ROM of some adjacent nodes.

Where did you get the 100 MHz figure for the internal RAM? I have
never seen anything that would make me think that and I am pretty sure
the process they are using will allow such a tiny ram to run faster
than 100 MHz.

I'm not sure what you have read about the external memory interface,
I've looked at all of the info I can find about the RAM interface and
they claim 250 ns access on a 55 ns part. They say you "should" be
able to get 200 ns access using the "degenerate version discussed
below" in their app note 3.

Actually their recommended chips range up to 1M x 16 or 2 MB of RAM.

> > I would like to have a larger display, maybe 5 inches and with e-Ink
> > technology (I assume it can support a 1 second update rate). I saw a
> > Kindle and was VERY impressed with the clarity and contrast of the
> > display not to mention the low power aspects of it.
>
> For GPS, color probably makes it a lot nicer. On the cpu side, it's
> probably a lot easier to write the map handling code in a scripting
> language with lists, garbage collection, etc. That's part of the
> purpose of a separate cpu for the map stuff.

I'm talking about handheld GPS, not a car unit. Color has some value,
but the screen washes out in sunlight. I don't see how a separate CPU
makes anything about the map display easier. Have you done this sort
of work before?

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Where did you get the 100 MHz figure for the internal RAM?

http://www.greenarraychips.com/home/documents/greg/DB001-110412-F18A.pdf
page 9

Correct figure is closer to 200 mhz. It says 5.1 ns but I
mis-remembered that as 5 cycles, which at 700 mhz cpu operation
is closer to 100 mhz for memory access.

> I'm not sure what you have read about the external memory interface,
> I've looked at all of the info I can find about the RAM interface and
> they claim 250 ns access on a 55 ns part.

Ok, that (or 200 ns) is still more than an order of magnitude slower
than 100 mhz.

> I'm talking about handheld GPS, not a car unit. Color has some value,
> but the screen washes out in sunlight. I don't see how a separate CPU
> makes anything about the map display easier. Have you done this sort
> of work before?

I see, yes, e-ink is nice in sunlight, though traditional monochrome lcd
is also fine. And I guess if you're just rendering and scrolling a big
map around, the code is probably straightforward enough that Forth won't
get in your way too much. If you're doing fancier sorts of navigation
(find road directions to some street address) then using GC'd languages
has to be a lot easier. Scripting languages are also much easier to
write GUI's with.q

Are you planning to implement the GPS directly in the GA144 (a lot of
complicated code and algorithms), or use an external GPS chip and
process the position info that comes out? Using an external chip will
sure be a lot easier.

I've never programmed a GPS but I wrote some code (in C) to control a
digital compass from a PC a while back. It was mostly GUI code, and
quite inconvenient compared to today's approach of just writing an HTML
page.

[rickman]

On Mar 25, 6:51 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:

> > I'm talking about handheld GPS, not a car unit.  Color has some value,
> > but the screen washes out in sunlight.  I don't see how a separate CPU
> > makes anything about the map display easier.  Have you done this sort
> > of work before?
>
> I see, yes, e-ink is nice in sunlight, though traditional monochrome lcd
> is also fine.  And I guess if you're just rendering and scrolling a big
> map around, the code is probably straightforward enough that Forth won't
> get in your way too much.  If you're doing fancier sorts of navigation
> (find road directions to some street address) then using GC'd languages
> has to be a lot easier.  Scripting languages are also much easier to
> write GUI's with.q

My current unit has the "traditional" monochrome display which is hard
to read under many lighting conditions. A typical LCD with backlight
is not really a good universal solution. I think the e-ink comes a
lot closer although it still doesn't do well in dark conditions.
Seems they don't build in any sort of light since so far the apps have
been printed book replacements and it's ok to require an external
light. Might not be a problem, just add an LED on a simple arm of
some sort... perhaps... That's still a long way off to worry about.

As an example of how the "traditional" LCD is not so good, I just
bought an outdoor thermometer which is hung on the outside of a window
with a suction cup. I checked the temp last night and in moderate
light it as unreadable. Everything else in the room could be seen
fine, but the LCD required me to get a flashlight to shine on it.

> Are you planning to implement the GPS directly in the GA144 (a lot of
> complicated code and algorithms), or use an external GPS chip and
> process the position info that comes out?  Using an external chip will
> sure be a lot easier.

Again, that is a long way off. Yes,for $25 (the last time I checked)
you can add a GPS chip which includes the analog circuits. So it may
not be worth doing any of it in the GA144 as it would still require
the RF analog front end. I have worked with this stuff before but I
don't know off the top of my head if the GA144 could do enough of the
work to make it worth while. I know the GPS chips have been highly
optimized over the years. But part of this is to see how much the
GA144 can do. I think it can do a lot of SDR functions and will be
looking at weather radio, VHF transceiver and lightning detector/
analyzer. It would be interesting to have this all in one unit along
with the GPS.

> I've never programmed a GPS but I wrote some code (in C) to control a
> digital compass from a PC a while back.  It was mostly GUI code, and
> quite inconvenient compared to today's approach of just writing an HTML
> page.

The GPS is not really in the "plan" so to speak. It is a door I am
keeping open. This board is really a way to evaluate the GA144 in
this context and hopefully useful to others at the same time.

Rick

[Albert van der Horst]

In article <29c5b9f9-65da-44ed...@eb6g2000vbb.googlegroups.com>,
rickman <gnu...@gmail.com> wrote:

>On Mar 23, 2:15=A0pm, Roger Ivie <ri...@ridgenet.net> wrote:
>> On 2012-03-23, rickman <gnu...@gmail.com> wrote:
>>

>> > Farnell is EU and I am USA. =A0We hae Digikey and Mouser, both with goo=
>d

>> > parts search engines. =A0I prefer Digikey and have a company account,
>> > never a delivery problem. =A0In fact, I've discovered that US Mail

>> > Priority mail is faster for me than UPS and cheaper too!
>>
>> The US outlet of Farnell is Newark. I only know this because of
>> the recent Raspberry Pi hoopla.
>>
>> It looks to me like there were a couple of typos in the part number;
>> near as I can tell, the part number should have actually been
>> H5PS1G63EFR instead of HSPS1G3EFR. The Newark page is here:
>>
>> http://www.newark.com/hynix-semiconductor/h5ps1g63efr-s6c/sdram-ddr2-...
>>
>> --
>> roger ivie
>> ri...@ridgenet.net
>
>Thanks for the clarification.
>
>This is a DDR2 device using SSTL logic level interfaces, not supported
>by the GA144. I am not interested in analyzing this with the GA144 to
>see if it can be kludged. I don't think the GA144 data sheet provides
>enough info. I'll take a look at SDRAM and DDR when I get a chance.

I did an investigation.

I hope www.digikey.us works the same as www.digikey.nl.

Okay there we go.
We start with selecting an arbitrary memory supplier, so we are not
bothered with other components: ISS.
Then narrow it down to memory. They supply merely 1200 types ( ;-).

Lets have a look what they have in the popular 16M x 16 category,
i.e. 32 Mbyte.
That narrows it down to 64 chip types.

Lets select the same voltage as the GA144: 1.7 .. 1.9
706-1127-ND digikey part number
IS43DR16160A-xxx supplier part number

Download the datasheet.
I see what you meant. We are out of luck, 4 differential inputs.
I am afraid that most newer chips with attractive capacities have
such an interface.

This is what I found with only the clock as a differential input.

706-1144-ND Digikey
IS43R16160B ISS

60 pin bga 8*13 mm
TSOP-2 12*22 mm

I have studied this in some detail:

1. Why does it bother you to have a TSOP-2 package, when
the pin spacing is more than that of the GA144?
If that demands 4 mil, so does the GA144.

2. I see the term STTL-2. That is not a reference, as
the data sheet is self contained. I see there is a differential
clock input, but that is the only differential input.
If we put CLK and ~CLK on the same output word, it should be okay.
It costs one extra pin, so be it.

3. This chip still works at 2.3 V. I don't expect problems with
direct interfacing, do you?

4. It seems that burst length can be kept to 2.
If set to 2 permanently, we would have obligatory 32 bit
access, not bad.

5. The GA144 is well equipped to read on both edges of DQS.
It can wait for a signal to go up, as well as go down.

6. There is a total of 18 bidirectional wires. 16 databits and 2
strobes, a good match for the GA144.

The IS43R16320B is even slightly more attractive, except for the package.
It differs with the 16160 in voltage, works on 1.8V and has a
64 mbyte capacity. Only disadvantage : only available in BGA.
This is the digikey part number:
706-1142-ND
It is about twice as expensive, for twice the amount of RAM.

This type of memory is called "DDR SDRAM". It seems that we have
to stay away from "DDR2 SDRAM". Okay, you told so.

This is two orders of magnitude better than the evaluation board.

Caveat: I only investigated one supplier and I'm not an expert.

[rickman]

On Mar 26, 9:00 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:

> In article <29c5b9f9-65da-44ed-aacb-0baaa9130...@eb6g2000vbb.googlegroups.com>,
>
> rickman  <gnu...@gmail.com> wrote:
>

> >Thanks for the clarification.
>
> >This is a DDR2 device using SSTL logic level interfaces, not supported
> >by the GA144.  I am not interested in analyzing this with the GA144 to
> >see if it can be kludged.  I don't think the GA144 data sheet provides
> >enough info.  I'll take a look at SDRAM and DDR when I get a chance.
>
> I did an investigation.
>
> I hopewww.digikey.usworks the same aswww.digikey.nl.
>
> Okay there we go.
> We start with selecting an arbitrary memory supplier, so we are not
> bothered with other components: ISS.
> Then narrow it down to memory. They supply merely 1200 types ( ;-).
>
> Lets have a look what they have in the popular 16M x 16 category,
> i.e. 32 Mbyte.
> That narrows it down to 64 chip types.
>
> Lets select the same voltage as the GA144: 1.7 .. 1.9
> 706-1127-ND            digikey part number
> IS43DR16160A-xxx       supplier part number
>
> Download the datasheet.
> I see what you meant. We are out of luck, 4 differential inputs.
> I am afraid that most newer chips with attractive capacities have
> such an interface.
>
> This is what I found with only the clock as a differential input.

Can you say "DDR"? This device is DDR and I can tell that without
reading the data sheet. I'm not interested in DDR devices.

> 706-1144-ND    Digikey
> IS43R16160B    ISS
>
> 60 pin bga 8*13   mm
> TSOP-2     12*22  mm
>
> I have studied this in some detail:
>
> 1. Why does it bother you to have a TSOP-2 package, when
> the pin spacing is more than that of the GA144?
> If that demands 4 mil, so does the GA144.

That package is HUGE and eats too much board space (more than TWICE
the size of the GA144). I think I can work with the 54 pin BGA the
SDRAM devices come in. The 60 pin device may be similar, but I'm not
interested in DDR.

> 2. I see the term STTL-2. That is not a reference, as
> the data sheet is self contained. I see there is a differential
> clock input, but that is the only differential input.
> If we put CLK and ~CLK on the same output word, it should be okay.
> It costs one extra pin, so be it.
>
> 3. This chip still works at 2.3 V. I don't expect problems with
> direct interfacing, do you?

At 2.3 volt Vdd yes, it will destroy the GA144 I/Os. Why do you want
to use 2.3 volt Vdd?

> 4. It seems that burst length can be kept to 2.
> If set to 2 permanently, we would have obligatory 32 bit
> access, not bad.
>
> 5. The GA144 is well equipped to read on both edges of DQS.
> It can wait for a signal to go up, as well as go down.

Please look at how you would map the I/Os of this device to the
GA144. SDRAM is much simpler.

> 6. There is a total of 18 bidirectional wires. 16 databits and 2
> strobes, a good match for the GA144.

Read up on the I/O of the GA144, I don't see any useful way to map the
strobes to the data bus. Am I missing something?

> The IS43R16320B is even slightly more attractive, except for the package.
> It differs with the 16160 in voltage, works on 1.8V and has a
> 64 mbyte capacity. Only disadvantage : only available in BGA.
> This is the digikey part number:
>     706-1142-ND
> It is about twice as expensive, for twice the amount of RAM.
>
> This type of memory is called "DDR SDRAM". It seems that we have
> to stay away from "DDR2 SDRAM". Okay, you told so.

Stay away from DDR too. SDARM is good and there are plenty of devices
to choose from. BTW, why are you bothering with this? You don't have
an app for the board or the memory. So what is your interest?

> This is two orders of magnitude better than the evaluation board.
>
> Caveat: I only investigated one supplier and I'm not an expert.

Yes, I get that. But what is wrong with the 2 MB on the eval board?
The part on the eval board was carefully chosen for a number of
reasons. The memory is fast and ***should*** run at 55 ns cycle time,
not sure why they are so slow. The package allows 6 mil space and
trace design rules. The part is low power when idle and is not high
power when running. SDRAMs use 100 mA when running full tilt. Full
tilt on an SDRAM gets you about the same access time I believe. The
only advantage to the SDRAM is the larger capacity.

Rick

[Albert van der Horst]

In article <b0e3e421-95e2-448f...@l14g2000vbe.googlegroups.com>,

rickman <gnu...@gmail.com> wrote:
>Stay away from DDR too. SDARM is good and there are plenty of devices
>to choose from. BTW, why are you bothering with this? You don't have
>an app for the board or the memory. So what is your interest?
>
>> This is two orders of magnitude better than the evaluation board.
>>
>> Caveat: I only investigated one supplier and I'm not an expert.
>
>Yes, I get that. But what is wrong with the 2 MB on the eval board?
>The part on the eval board was carefully chosen for a number of
>reasons. The memory is fast and ***should*** run at 55 ns cycle time,
>not sure why they are so slow. The package allows 6 mil space and
>trace design rules. The part is low power when idle and is not high
>power when running. SDRAMs use 100 mA when running full tilt. Full
>tilt on an SDRAM gets you about the same access time I believe. The
>only advantage to the SDRAM is the larger capacity.

In name it is 2Mbyte i.e. 500k *32bit. Of the 32 bit only 18 bit is
used. Of the 500k * 56% only 250 k is addressable from eForth.

By using CAS/RAS you double the address bits. I think that is a
neat idea. 64Mbyte versus 250 K opens possibilities.

IMO there is room for a development boards with a different
trade off. A high RAM board doesn't inspire you. Pity.
For me it is too hard to pull this off.

Thanks anyway, you set me straight on a number of issues.

[Paul Rubin]

Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> In name it is 2Mbyte i.e. 500k *32bit. Of the 32 bit only 18 bit is
> used. Of the 500k * 56% only 250 k is addressable from eForth.

According to the app note

http://www.greenarraychips.com/home/documents/greg/AP003-110810-SRAM.pdf

it's set up as 16 bits * 1M words. I had mis-remembered it as 256k.

> By using CAS/RAS you double the address bits. I think that is a neat

> idea. 64Mbyte versus 250 K opens possibilities. ... A high RAM board

> doesn't inspire you. Pity.

I'm having a hard enough time figuring out to do with the GA even with
small ram. I'm not sure how big ram really helps, especiallly once it
needs multi-word addresses, rather slow access time especially to get
the data to internal nodes on the chip, etc.

[Mark Flamer]

On Sunday, March 11, 2012 6:00:50 AM UTC-7, emmanuel wrote:
> On 11 mar, 12:33, rickman <gnu...@gmail.com> wrote:

>
> > On Mar 11, 5:10 am, Rafael Deliano <Rafael_Deli...@arcor.de> wrote:
>
> >
>
> > > > What would you like to see on a GA144 application board?
>
> >
>

> > >    For an "evaluation board" ( something stuffed with lots of
>
> > > components ) most people will stick with the EVB001 from
>
> > > Green Arrays. Its well done. Maybe a bit expensive, but
>
> > > people that are serious about GA144 will not have much
>
> > > problem with that.
>
> >
>
> > I don't see where the EVB001 is very good for anything other than
>
> > playing with the CPU.  Maybe the name "evaluation" board is not so
>
> > important.  I wouldn't spend $500 just to "evaluate" or learn about
>
> > the chip.  I might spend that much on a board that lets me evaluate
>
> > the device for my application.  Would you call that an "application"
>
> > board?  But the EVB001 doesn't have the facility of adding any useful
>
> > interfaces really.  I just can't see a chip like this being useful in
>
> > enough apps unless you can hang some useful interfaces off it, like
>
> > high speed USB and at least 100 Mbps Ethernet.  I am thinking wireless
>
> > may well be important too.  I don't know as much about that.  I also
>
> > don't see anything coming out of GreenArrays along these lines.  Just
>
> > like they published half an app note on adding a crystal to make an
>
> > oscillator they published half an app note on adding 10 Mbps Ethernet
>
> > by bit banging.  Actually I would only call it 10% of an app note as
>
> > there is a ton more work to be done before Ethernet could be supported
>
> > in a useful way.
>
> >
>
> > I'm hoping that if I put out a GA144 board with a RMII PHY that might
>
> > spur some interest in developing the remainder of the design.  I'm not
>
> > as encouraged that high speed USB will be practical without adding a
>
> > full USB stack on another chip.
>
> >
>
> > >    For an "adapter board" ( a simple board that enables
>
> > > breadboarding ) there is not much available yet.
>
> > > Most people will not take the SchmartBoard 202-0048-02
>
> > > seriously.
>
> > > The adapter board would typically
>
> > > * fit in a PGA socket. One would have a look which of
>
> > >    these obsolete sockets is best available.
>
> > > * come assembled, tested with ICs, capacitors.
>
> > > * there would be two variants:
>
> > >    a) with serial boot-memory
>
> > >    b) with serial boot-memory and parallel SRAM
>
> > >       in BGA48
>
> > >    Version a) is for simple "gate array application"
>
> > >    with no virtual machine. One would not want to lose
>
> > >    the pins that are gone with SRAM in version b).
>
> >
>
> > How would you make use of an adapter board?  I don't see this as being
>
> > a very big seller and I believe it would be VERY expensive to make.  I
>
> > think people would just roll their own boards before paying a huge
>
> > price for such obsolete technology.
>
> >
>
> > You don't really loose many pins by hooking up RAM exactly.  The RAM
>
> > example uses a single node with 4 I/Os and the two 18 bit I/O ports.
>
> > Yes you can use the 18 bit ports as I/O, but you can't use them in the
>
> > same way as the individual port bits.  On each port all 18 bits are
>
> > input or all are output and when you write to one bit you have to
>
> > write to all.  Otherwise there are only 21 bits of individual I/O.
>
> > You do loose 4 of those for the memory control lines.
>
> >
>
> > BTW, in what apps do you see the GA144 being used as a "simple gate
>
> > array"?
>
> >
>
> > >    That a third category "application board" exists i
>
> > > am sceptical. As every one will have a different
>
> > > application in mind.
>
> > > For low speed one can breadboard with the adapter boards.
>
> > > For high speed applications one will have to layout.
>
> >
>
> > What high speed apps?  Other than the memory interface and the GA144
>
> > to GA144 SERDES, what would be high speed on this chip?  Even the
>
> > memory interface only runs at 5 MHz according to their app note.  I
>
> > suppose you could bit bang a SERDES at very reduced speeds compared to
>
> > the hard core, but that wouldn't be hard to layout.  I think any of
>
> > these boards needs to address a user's application if it is going to
>
> > be worth the price.  Like I said, that is my issue with the EVB001.
>
> >
>
> > The part of "every one will have a different application in mind" that
>
> > is a bit funny is that so far, I haven't heard anyone suggest
>
> > realistic apps for the part, much less everyone having "different
>
> > apps".  I'm not saying they don't exist.  I'm saying no one seems to
>
> > be talking about them.  That's what I am looking for.  What would
>
> > people find interesting to use this device for?  An eval/demo/app
>
> > board can be a superset of what any one user wants.  In fact I am
>
> > pretty confident that is the only way to make it useful.
>
> >
>
> > Rick
>
>
>
>
>
>
>
> Hello,
>
>
>
> I wouldn't spend $500 just to "evaluate" or learn about the chip. If
>
> you want a board , please visit my web page :
>
>
>
> http://esaid.free.fr/
>
>
>
> http://esaid.free.fr/tutoriel_arrayforth/Ga144_pcb/Ga144_kit.html
>
>
>
> I made this GA144 board and it is cheaper.
>
>
>
> Emmanuel

Emmanuel, are you offering these boards for sale?