Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #9987 > unrolled thread

GA144 Application Board

Back to article view | Back to comp.lang.forth

Contents

  GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-10 17:24 -0800
    Re: GA144 Application Board Rafael Deliano <Rafael_Deliano@arcor.de> - 2012-03-11 10:10 +0100
      Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-11 04:33 -0700
        Re: GA144 Application Board emmanuel <emmanuel.said@cern.ch> - 2012-03-11 06:00 -0700
          Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-11 19:41 -0700
        Re: GA144 Application Board Rafael Deliano <Rafael_Deliano@arcor.de> - 2012-03-11 16:03 +0100
          Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-11 13:45 -0700
    Re: GA144 Application Board Jecel <jecel@merlintec.com> - 2012-03-11 12:33 -0700
    Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-11 19:45 +0000
      Re: GA144 Application Board Matthias Koch <koch@pci.uni-hannover.de> - 2012-03-15 14:11 +0100
    Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-14 19:53 -0700
      Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-20 20:15 -0700
        Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-21 13:08 +0000
          Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-21 12:13 -0700
            Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-22 11:36 +0000
              Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-22 17:50 +0000
                Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-22 14:50 -0700
                  Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 12:24 +0000
                    Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-23 10:11 -0700
                      Re: GA144 Application Board Roger Ivie <rivie@ridgenet.net> - 2012-03-23 13:15 -0500
                        Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-24 11:51 -0700
                          Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-25 12:06 +0000
                            Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-25 12:50 -0700
                          GA144 memory interfacing was Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-26 13:00 +0000
                            Re: GA144 memory interfacing was Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-26 20:03 -0700
                              Re: GA144 memory interfacing was Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-28 12:21 +0000
                                Re: GA144 memory interfacing was Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-28 07:59 -0700
              Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-22 14:26 -0700
            Re: GA144 Application Board hwfwguy@gmail.com - 2012-03-22 12:25 -0700
              Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-22 13:07 -0700
                Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-22 14:54 -0700
                  Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-22 15:00 -0700
                    Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-23 10:15 -0700
                      Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-23 17:32 -0700
                        Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-24 12:01 -0700
                          Re: GA144 Application Board Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-24 22:27 +0000
                            Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-24 19:13 -0700
                          Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-24 16:01 -0700
                            Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-24 19:18 -0700
                              Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-25 13:06 -0700
                                Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-25 15:02 -0700
                                  Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-25 15:51 -0700
                                    Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-25 16:38 -0700
              Re: GA144 Application Board Richard Owlett <rowlett@pcnetinc.com> - 2012-03-22 16:54 -0500
                Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-23 10:17 -0700
              Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-22 14:52 -0700
              Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 12:34 +0000
                Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-23 10:24 -0700
              Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 14:22 +0000
        Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-22 08:12 -0700
          Re: GA144 Application Board Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-23 12:38 +0000
        Re: GA144 Application Board Paul Rubin <no.email@nospam.invalid> - 2012-03-22 08:52 -0700
          Re: GA144 Application Board rickman <gnuarm@gmail.com> - 2012-03-22 15:00 -0700
    Time to revisit S100 Bus? - was [Re: GA144 Application Board] Richard Owlett <rowlett@pcnetinc.com> - 2012-03-22 20:17 -0500
      Re: Time to revisit S100 Bus? - was [Re: GA144 Application Board] rickman <gnuarm@gmail.com> - 2012-03-23 10:29 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#10418

On Mar 23, 2:15 pm, Roger Ivie <ri...@ridgenet.net> wrote:
> 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-...
>
> --
> 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

[toc] | [prev] | [next] | [standalone]

#10446

In article <29c5b9f9-65da-44ed-aacb-0baaa9130e72@eb6g2000vbb.googlegroups.com>,
rickman  <gnuarm@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

Groetjes Albert

--
-- 
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

[toc] | [prev] | [next] | [standalone]

#10456

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>,
>
>
>
>
>
>
>
>
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#10511 — GA144 memory interfacing was Re: GA144 Application Board

In article <29c5b9f9-65da-44ed-aacb-0baaa9130e72@eb6g2000vbb.googlegroups.com>,
rickman  <gnuarm@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.

>
>Rick

Groetjes Albert

--
-- 
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

[toc] | [prev] | [next] | [standalone]

#10547 — Re: GA144 memory interfacing was Re: GA144 Application Board

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

[toc] | [prev] | [next] | [standalone]

#10624 — Re: GA144 memory interfacing was Re: GA144 Application Board

In article <b0e3e421-95e2-448f-82c8-d338f5253add@l14g2000vbe.googlegroups.com>,
rickman  <gnuarm@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.

>
>Rick

Groetjes Albert

--
-- 
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

[toc] | [prev] | [next] | [standalone]

#10627 — Re: GA144 memory interfacing was Re: GA144 Application Board

Albert van der Horst <albert@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.

[toc] | [prev] | [next] | [standalone]

#10321

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

[toc] | [prev] | [next] | [standalone]

#10313

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).

[toc] | [prev] | [next] | [standalone]

#10317

hwfwguy@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
;-).

[toc] | [prev] | [next] | [standalone]

#10324

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

[toc] | [prev] | [next] | [standalone]

#10329

rickman <gnuarm@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.

[toc] | [prev] | [next] | [standalone]

#10365

On Mar 22, 6:00 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#10383

rickman <gnuarm@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.

[toc] | [prev] | [next] | [standalone]

#10419

On Mar 23, 8:32 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#10423

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.

[toc] | [prev] | [next] | [standalone]

#10429

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

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

Rick

[toc] | [prev] | [next] | [standalone]

#10424

rickman <gnuarm@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.

[toc] | [prev] | [next] | [standalone]

#10430

On Mar 24, 7:01 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#10458

rickman <gnuarm@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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web