GA144 polyForth

[Howerd]

Hi All,

I have just downloaded the latest arrayForth and polyForth systems for the GreenArrays GA144 EV001 evaluation board, dusted down the eval board and installed it...

Back in ~1978 I accidentally came across microForth for the COSMAC computer, with a 2 MHz CDP1802 and 12K of RAM, and typed 1 1 + . for the first time.
Since then I have used various flavours of Forth, and I use this simple test to confirm that I can interact with the computer.

So nothing new here, I still get the answer 2, and Greg's saneForth Terminal looks very DOS-like (except that it actually runs under Win7 64 bit).

But this is actually something very different :
1. There is no assembler because this is running in a few of the F18 cores in one of the GA144 chips which have a Forth instruction set.
2. There is no cross compiler because the GA144 polyForth compiles itself on the chip - the PC is only a terminal.
3. There is no "inner interpreter" AKA "address interpreter" because the F18 cores are programmed to be the polyForth virtual machine. OK, you can argue semantics here...
4. Contradicting point 1, there is a sort of assembler, in that you can define extensions to the virtual machine, and also access any of the other 100+ F18's via Ganglia and Snorkels ( whatever they are - more docs please GA guys :-)

I also ran a speed test :
: asd 1000 for 1000 for 0 drop next next ;
takes about 3 seconds.
IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit processors are some tens of seconds.

Speed wise, the combination of GA144, SPI EEPROM and SRAM, running polyForth looks plenty fast enough for the sort of embedded apps I usually work with.
Power wise, it looks good too.
Cost wise, well maybe I can haggle with GA...
Peripherals - there are plenty of fast counters, F18's in adundance that can be programmed to do simple serial or even 10M Ethernet, or you can use the built in SERDES.

All in all it could compete with an MSP430, 8051 or a PIC except that only with the GA144 do you get so many fast cores with fast I/O to play with.

The GA144 with polyForth seems to be to good not to use...

Just sharing my excitement - well done to all the GreenArray folks!

Best regards,
Howerd

[Paul Rubin]

Howerd <how...@yahoo.co.uk> writes:
> I have just downloaded the latest arrayForth and polyForth systems for
> the GreenArrays GA144 EV001 evaluation board, dusted down the eval
> board and installed it...

That sounds really cool. Thanks for the post. Had you been using
eforth on the eval board before?

> 2. There is no cross compiler because the GA144 polyForth compiles
> itself on the chip - the PC is only a terminal.

I'm just wondering but do they distribute it as source code so you can
rebuild it yourself?

> 3. There is no "inner interpreter" AKA "address interpreter" because
> the F18 cores are programmed to be the polyForth virtual machine. OK,
> you can argue semantics here...

I wish they would document how the VM works. Greg Bailey had a plea for
someone to target a C compiler to the GA144, but I couldn't make enough
sense of the VM source listing to tell whether those VM nodes (they have
ROM code for the vm) could be a sensible C target already.

> the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
> more docs please GA guys :-)

That's the stuff for routing code and data around the GA144. It's
mentioned on some of the videos (type "greenarrays" into youtube).

> : asd 1000 for 1000 for 0 drop next next ;
> takes about 3 seconds.

OK, I remember hearing something like 250ns access time to the external
ram, so each pass through the loop is doing 10-12 ram accesses (the F18
cycles probably don't use much of that 3 sec). I guess not too bad,
figuring it's a traditional threaded interpreter.

> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
> processors are some tens of seconds.

Hrm, do you mean recent 8 bitters? And I wonder how something like an
MSP430 (16 bit) would do.

> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
> polyForth looks plenty fast enough for the sort of embedded apps I
> usually work with.

> Power wise, it looks good too.

Did you measure the power, running that 3 second loop? I wonder how it
really compares with something like an MSP430, since those VM nodes are
running at 700 mhz or so. OTOH they may be idle most of the time,
waiting for the external ram.

> All in all it could compete with an MSP430, 8051 or a PIC except that
> only with the GA144 do you get so many fast cores with fast I/O to
> play with.

Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
pointed out a few times. It's nice that there's now a working "soft
core" using a few of its cells that can run a relatively conventional
software environment (calling Polyforth conventional just shows how far,
er, ahead of the curve GA is).

> The GA144 with polyForth seems to be to good not to use...
> Just sharing my excitement - well done to all the GreenArray folks!

Yes, it's a good development, and makes the product more "real".
Congrats GA.

[rickman]

On 9/29/2012 4:20 AM, Paul Rubin wrote:
> Howerd<how...@yahoo.co.uk> writes:
>> I have just downloaded the latest arrayForth and polyForth systems for
>> the GreenArrays GA144 EV001 evaluation board, dusted down the eval
>> board and installed it...
>

>> 3. There is no "inner interpreter" AKA "address interpreter" because
>> the F18 cores are programmed to be the polyForth virtual machine. OK,
>> you can argue semantics here...
>
> I wish they would document how the VM works. Greg Bailey had a plea for
> someone to target a C compiler to the GA144, but I couldn't make enough
> sense of the VM source listing to tell whether those VM nodes (they have
> ROM code for the vm) could be a sensible C target already.

I am a bit biased being more of a hardware designer, but I can't see a C
compiler being all that useful. Maybe I don't appreciate the utility or
efficiency of such a tool, but it seems to me the VM will run a lot
slower than many other CPUs and will end up being very energy
inefficient. I can see running one VM to facilitate high level control
or UI functions but running many of them can be difficult due to memory
access conflicts and not along the lines of the chip's strong suit...
fast, efficient hardware.

>> the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
>> more docs please GA guys :-)
>
> That's the stuff for routing code and data around the GA144. It's
> mentioned on some of the videos (type "greenarrays" into youtube).

I don't recall seeing this anywhere. Chuck has done his stuff on
inter-node comms but I don't recall these names being used anywhere.
But then he noted that this was very complex code, so I never dug into
it. I expect to be useful it will need clear, simple documentation of
how to use it.

>> : asd 1000 for 1000 for 0 drop next next ;
>> takes about 3 seconds.
>
> OK, I remember hearing something like 250ns access time to the external
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> cycles probably don't use much of that 3 sec). I guess not too bad,
> figuring it's a traditional threaded interpreter.
>
>> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
>> processors are some tens of seconds.
>
> Hrm, do you mean recent 8 bitters? And I wonder how something like an
> MSP430 (16 bit) would do.

Comparing a VM on a processor node on a $15 GA144 (which also needs
external memory, etc) to an MCU that costs next to nothing is pretty
pointless. The question is not, can the GA144 do a job, the question
is, is it the best chip for the application?

>> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
>> polyForth looks plenty fast enough for the sort of embedded apps I
>> usually work with.
>
>> Power wise, it looks good too.
>
> Did you measure the power, running that 3 second loop? I wonder how it
> really compares with something like an MSP430, since those VM nodes are
> running at 700 mhz or so. OTOH they may be idle most of the time,
> waiting for the external ram.

If it is running one node at full speed, it will use around 5 mW. Many
8 bitters will use around that same power level, but this would need to
be normalized to their computing time. That is essentially what Greg
Bailey does in white paper 3, "Comparison..." with an MSP430. But they
use an old version of the MSP and I think the results are a bit skewed
because of that.

>> All in all it could compete with an MSP430, 8051 or a PIC except that
>> only with the GA144 do you get so many fast cores with fast I/O to
>> play with.
>
> Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
> pointed out a few times. It's nice that there's now a working "soft
> core" using a few of its cells that can run a relatively conventional
> software environment (calling Polyforth conventional just shows how far,
> er, ahead of the curve GA is).

Yes, and I think the device could be much better served by a Verilog or
VHDL compiler than a C compiler. But in reality I think they just need
to figure out how customers can best use their devices and work on
producing more app notes and guides to help us learn these techniques.
The last conversation I had with Greg was along the lines of I need to
measure timing data for myself. I think this is a bit much to expect of
customers.

>> The GA144 with polyForth seems to be to good not to use...
>> Just sharing my excitement - well done to all the GreenArray folks!
>
> Yes, it's a good development, and makes the product more "real".
> Congrats GA.

Hmmm, I think that was intended to be "*too* good not to use". A small
change makes a big difference in interpretation.

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> Greg Bailey had a plea for someone to target a C compiler to the
>> GA144, but I couldn't make enough sense of the VM source listing to

> I can see running one VM to facilitate high level
> control or UI functions but running many of them can be difficult

Yes, the idea is to just run one VM with control and UI stuff. The VM
is programmed into the ROM of 3 nodes that sit near the nodes programmed
to be the external SRAM controller. I don't think anyone was talking
about running multiple ones. Greg was looking to be able to program the
VM in C.

>>> the other 100+ F18's via Ganglia and Snorkels

>> mentioned on some of the videos (type "greenarrays" into youtube).
> I don't recall seeing this anywhere. Chuck has done his stuff on
> inter-node comms but I don't recall these names being used

http://www.youtube.com/results?search_query=greenarrays

It's on the second page of results.

> If it is running one node at full speed, it will use around 5 mW.
> Many 8 bitters will use around that same power level, but this would
> need to be normalized to their computing time.

The computing time is on the same order as the GA running the VM. I'm
kind of surprised to hear that modern 8 bitters use anything like 5mw if
they care about power at all, though.

[rickman]

On 9/30/2012 12:06 PM, Paul Rubin wrote:
> rickman<gnu...@gmail.com> writes:
>>> Greg Bailey had a plea for someone to target a C compiler to the
>>> GA144, but I couldn't make enough sense of the VM source listing to
>> I can see running one VM to facilitate high level
>> control or UI functions but running many of them can be difficult
>
> Yes, the idea is to just run one VM with control and UI stuff. The VM
> is programmed into the ROM of 3 nodes that sit near the nodes programmed
> to be the external SRAM controller. I don't think anyone was talking
> about running multiple ones. Greg was looking to be able to program the
> VM in C.

Ok, I guess I got confused when Howerd referred to "a few of the F18
cores", he means one virtual machine on three nodes.

>>>> the other 100+ F18's via Ganglia and Snorkels
>>> mentioned on some of the videos (type "greenarrays" into youtube).
>> I don't recall seeing this anywhere. Chuck has done his stuff on
>> inter-node comms but I don't recall these names being used
>
> http://www.youtube.com/results?search_query=greenarrays
>
> It's on the second page of results.

I'll take a look when I get a chance. Video is my least favorite way of
getting technical info. I find it time consuming for the amount of
information conveyed and hard to review. But then GA doesn't let you
make notes on the PDF files either. Sometimes it seems like they don't
want you to learn about this stuff.

>> If it is running one node at full speed, it will use around 5 mW.
>> Many 8 bitters will use around that same power level, but this would
>> need to be normalized to their computing time.
>
> The computing time is on the same order as the GA running the VM. I'm
> kind of surprised to hear that modern 8 bitters use anything like 5mw if
> they care about power at all, though.

8 bitters are just a little better on power (if at all) than 32 bitters,
IIRC. I seem to find a lot of parts running at around 200 uA/MHz with
various voltages on the core. So at 8 MHz 5 mW would be a good number
for most CPUs. At full speed even the good 32 bitters can get up to
30-40 mW without too much trouble.

I don't see a lot of value in running a VM on the GA144 at the same
speed and possibly more power than many MCUs. Looking at the rest of
the chip as the reason to use the GA144, what is there? It has some
real potential for software based IO, but this is also very limiting.
Many MCUs have 100 Mbps Ethernet, the GA144 does 10 Mbps. Many MCUs
have 480 Mbps USB2.0, the GA144 doesn't have USB implemented as yet, but
it might be able to support 12 Mbps.

There are so many things the GA144 can't do without external support
chips, including storing more than a few kBytes of information.

I thought I had a handle on a way to use the device by looking at it as
a processor based analog to an FPGA, but when I tried to design with it
that way I couldn't get all the info I needed from GA. They just didn't
want to support any method of working other than their way. I can't
imagine how they would support C developers who are used to big, complex
tools for developing C programs.

I can't see how providing a C compiler to use with a single VM running
at similar speeds to an 8 bit MCU will be any real incentive to use the
GA144 and it would be tons of work. Forth is not a bad language for
developing high level code and it is not hard to learn. They need tools
to let people deal with the real problems of using the GA144 which seems
to be the floor planning. In the short term I would think this would be
app notes more than anything else that would take so much longer to
develop.

Rick

[Coos Haak]

Op Sat, 29 Sep 2012 01:20:40 -0700 schreef Paul Rubin:

<snip>

>>: asd 1000 for 1000 for 0 drop next next ;
>> takes about 3 seconds.
>
> OK, I remember hearing something like 250ns access time to the external
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> cycles probably don't use much of that 3 sec). I guess not too bad,
> figuring it's a traditional threaded interpreter.
>
>> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
>> processors are some tens of seconds.
>
> Hrm, do you mean recent 8 bitters? And I wonder how something like an
> MSP430 (16 bit) would do.

noForth, a Dutch Forth, see
http://www.forth.hcc.nl/w/WerkgroepMSP/WerkgroepMSP
does it in just under 5 seconds.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> http://www.youtube.com/results?search_query=greenarrays

> I'll take a look when I get a chance. Video is my least favorite way
> of getting technical info.

Yeah, I agree with this. I've looked at a few of the videos and they
have useful content, but I'd rather have readable documentation.

> 8 bitters are just a little better on power (if at all) than 32
> bitters, IIRC.

Oh that's interesting, I'd figured 32 bitters have 4x as many gates
toggling on each cycle. It takes more instructions to make stuff happen
with an 8-bitter, but for stuff like UI's that may not matter. I've
thought 16 bits is a sweet spot for small cpu's running either Forth or C.

> I don't see a lot of value in running a VM on the GA144 at the same
> speed and possibly more power than many MCUs.

The VM seems like a reasonable approach for complex control stuff
reaching into the GA144 instead of adding an external processor. Of
course the GA144 makes no sense as a conventional MCU replacement. It's
only for when there's other stuff you want to do with the rest of the
nodes. As you know, I agree with you that finding applications for the
rest of the nodes isn't so easy.

> I can't see how providing a C compiler to use with a single VM running
> at similar speeds to an 8 bit MCU will be any real incentive to use
> the GA144 and it would be tons of work. Forth is not a bad language
> for developing high level code and it is not hard to learn.

If you've got a reasonable (virtual) cpu target, and if you don't care
about crappy code coming out, targeting a C compiler isn't that hard. I
could imagine it helping with user acceptance and letting people port
some of their existing code instead of writing new code.

One issue making things harder for you may be that you were trying to
push the chip's performance to its limits. It may be easier with
programs where the nodes are mostly idle and plenty fast, and you deal
with speed or space problems by spreading the workload over more nodes.

> They need tools to let people deal with the real problems of using the
> GA144 which seems to be the floor planning.

Yeah, that calls for automated tools, and more inter-node connectivity
if they make a new version of the chip.

[Andrew Haley]

Howerd <how...@yahoo.co.uk> wrote:

> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
bit processors are some tens of seconds.

Erm, 16MHz? IIRC we never got it running past 6. :-)

Andrew.

[Howerd]

On Saturday, September 29, 2012 10:20:47 AM UTC+2, Paul Rubin wrote:

Hi Paul,

> Had you been using eforth on the eval board before?

I got it running when I first got the board, but it lacks a multitasker, so I haven't been using it. So far I am just using the Eval board to evaluate the chip...

> I guess not too bad, figuring it's a traditional threaded interpreter.

I don't think it is a traditional threaded interpreter. The tokens have bits that determine which node they are to be sent to, and a lot of Forth primitives map directly to F18 opcodes. My mind goes fuzzy thinking about this.

> Did you measure the power, running that 3 second loop?

I got out the soldering iron and fitted a 1 ohm resistor in place of the link for the Vcc Core, and the results are :
Reset 0.0mA ( my meter doesn't go that low )
polyForth 14.1mA
"ASD" loop 13.8mA

So running a tight loop uses *less* current than running polyForth, presumably because some of the cores are doing less.
BTW Freezing the chip with freeze spray increases the pF idle current from 14.1 to 14.4mA, and the 3 seconds for the ASD loop goes down to about 2.5.

The conclusion is that if you want very low power consumption you may have to disable the pF VM and/or its Ganglions and Snorkels. I remember hearing about a new hardware development to allow each core to do more without polling and using current.
I would love to have a visual tool that displayed what was going on in each core, like softsim, but for the real chip.

> It's nice that there's now a working "soft
> core" using a few of its cells that can run a relatively conventional
> software environment (calling Polyforth conventional just shows how far,
> er, ahead of the curve GA is).

This made me chuckle :-) I used polyForth though the 80's and 90's and still sometimes today, so seeing it running on tha GA144 is really sweet. I can see some interesting design decisions, such as : do I put the ADC in its own polyForth task, extend the polyForth VM to read it for me, or use another F18???

The weird power result made me realise that if you want to know how much current the GA144 uses you have to add up the current that each F18 core uses - obviously really, but there's 144 of them, and any or all of them might be doing something interesting.

BTW I put similar ASD code on an 89C450 with a 22MHz crystal - 29 seconds compared to 11 seconds for the DO ... LOOP form on the GA144. So not far off 3 times faster, but of course the one polyForth VM is only using a handful of F18's - you cold run 20 of them, if you could find a use for this...

Summary : the GA144 is to hardware what colorForth is to software - leave all of your assumptions behind and be prepared to find new ways of doing things.
Absoultely superb, if you like that kind of thing, as I do :-)

Best regards,
Howerd

[Howerd]

On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:

Hi Andrew,

Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?

Best regards,
Howerd

[Paul Rubin]

Howerd <how...@yahoo.co.uk> writes:
>> Had you been using eforth on the eval board before?
> I got it running when I first got the board, but it lacks a
> multitasker, so I haven't been using it.

But eforth has a beautiful multitasker that's just a dozen lines of code
or so, and should be pretty portable. I wonder why the GA version
didn't include it. Maybe it could be added on.

> I don't think it is a traditional threaded interpreter. The tokens
> have bits that determine which node they are to be sent to, and a lot
> of Forth primitives map directly to F18 opcodes. My mind goes fuzzy
> thinking about this.

Yeah, that makes sense about the primitives. I wonder if the stacks are
in the VM or in external ram. ANS requires 32 stack levels iirc, so
they could use an f18 node for both stacks, caching the top element
in the control node.

> polyForth 14.1mA
> "ASD" loop 13.8mA

> So running a tight loop uses *less* current than running polyForth,...

> The conclusion is that if you want very low power consumption you may
> have to disable the pF VM and/or its Ganglions and Snorkels.

Wait, do you mean polyForth burns that much power when it's sitting
there waiting for input, polling the port or something? They don't have
edge triggered i/o? When an f18 node is waiting on a port it's supposed
to use almost no power; that's its whole idea.

> BTW I put similar ASD code on an 89C450 with a 22MHz crystal - 29
> seconds compared to 11 seconds for the DO ... LOOP form on the GA144.

Oh man, that's pretty about the 89C450 which I'll guess might be
comparable to an AVR. This looks interesting:

http://tinyurl.com/d5zef8l

a $12.95 Cortex M0+ board from element14.com, 128k flash, 16k sram, 48
mhz, various goodies on the board, shipping from stock. Of course on
the 89C450, I'd expect a native-compiled Forth to be much faster.

I ordered a couple of the Cortex M4 Launchpads ($5 each, 10+ week
delivery) on the theory that they might increase the price once the
things are actually shipping, and ordered an MSP430 Launchpad ($4.30)
while I was at it. I have only vague ideas of what to do with them, but
at that price they are almost free. I may run 4e4th on it.

[Elizabeth D. Rather]

On 10/1/12 8:40 PM, Paul Rubin wrote:
> Howerd <how...@yahoo.co.uk> writes:

...

> Wait, do you mean polyForth burns that much power when it's sitting
> there waiting for input, polling the port or something? They don't have
> edge triggered i/o? When an f18 node is waiting on a port it's supposed
> to use almost no power; that's its whole idea.

The standard polyFORTH multitasker doesn't shut down when there's
nothing to do (it was not designed for low-power operation). The SwiftX
multitasker on processors such as MSP430 designed for low-power apps has
a very simple mod to go to power-saving mode automatically if one lap
around the task loop yields no active tasks. Then you add one
instruction to any interrupt code to wake up. It would be easy to add
that feature to the GA144 polyFORTH if they want to. Assuming, of
course, that this is what you're observing.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Andrew Haley]

Howerd <how...@yahoo.co.uk> wrote:
> On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:
>> Howerd <how....@yahoo.co.uk> wrote:
>>
>> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
>>
>> bit processors are some tens of seconds.
>>
>> Erm, 16MHz? IIRC we never got it running past 6. :-)
>>
>

> Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?

Maybe, I think you could run Novix at 8MHz if you used insanely fast
SRAM for the stacks. I thought there was only one run of Novix chips,
though. I also thought MPE didn't use Novix, but the Harrix RTX.

Andrew.

[Howerd]

On Wednesday, October 3, 2012 5:46:03 PM UTC+2, Andrew Haley wrote:
> Howerd <how....@yahoo.co.uk> wrote:
>
> > On Monday, October 1, 2012 5:28:08 PM UTC+2, Andrew Haley wrote:
>
> >> Howerd <how....@yahoo.co.uk> wrote:
>
> >>
>
> >> > IIRC a 16 MHx Novix takes less than 1 second for this, and most 8
>
> >>
>
> >> bit processors are some tens of seconds.
>
> >>
>
> >> Erm, 16MHz? IIRC we never got it running past 6. :-)
>
> >>
>
> >
>
> > Maybe it was 8 MHz - but this was in the 1990's at MPE, not 1980's at COMSOL, so maybe they were faster chips?
>
>
>
> Maybe, I think you could run Novix at 8MHz if you used insanely fast
>
> SRAM for the stacks. I thought there was only one run of Novix chips,
>
> though. I also thought MPE didn't use Novix, but the Harrix RTX.
>
>
>
> Andrew.

Hi Andrew,

You are right - time has taken its toll on the wetware :-(
They were RTX 2001's I think, which I believe are very similar to the Novix.
So maybe 16MHz clock was right.
I definitely remember having to double check that the loop was actually doing something, as I thought it was way too fast...

Best regards,
Howerd

[Howerd]

On Tuesday, October 2, 2012 8:40:15 AM UTC+2, Paul Rubin wrote:

Hi Paul,

> But eforth has a beautiful multitasker

Yes - somehow I had missed this. I think I didn't use eForth because it did not come with source code...

It occured to me that the polyForth VM is loaded mostly by "hi" so its in high level polyForth, so it should be easy to follow what is spinning and using power. I will take a look, when I get time.

Best regards,
Howerd

[Albert van der Horst]

In article <HoGdnUYJTP4XC_fN...@supernews.com>,

Elizabeth D. Rather <era...@forth.com> wrote:
>On 10/1/12 8:40 PM, Paul Rubin wrote:
>> Howerd <how...@yahoo.co.uk> writes:
>...
>> Wait, do you mean polyForth burns that much power when it's sitting
>> there waiting for input, polling the port or something? They don't have
>> edge triggered i/o? When an f18 node is waiting on a port it's supposed
>> to use almost no power; that's its whole idea.
>
>The standard polyFORTH multitasker doesn't shut down when there's
>nothing to do (it was not designed for low-power operation). The SwiftX
>multitasker on processors such as MSP430 designed for low-power apps has
>a very simple mod to go to power-saving mode automatically if one lap
>around the task loop yields no active tasks. Then you add one
>instruction to any interrupt code to wake up. It would be easy to add
>that feature to the GA144 polyFORTH if they want to. Assuming, of
>course, that this is what you're observing.

Look! If it is waiting for the keyboard it is consuming 700 nano Amperes!

From the point of marketing not spending this effort is a first rate
blooper. The power consumption is the single most important marketing
asset of the GA144.

In this competitive world a company that makes such marketing
mistakes doesn't deserve to live...

(Unless of course it would consume little but way more than a Launchpad.
Then they are wise not to draw attention to the fact.)

>
>Cheers,
>Elizabeth

Groetjes Albert

[Howerd]

Hi Albert,

This is the Host chip, running a high level IDE. Maybe we could add an idle instruction to the polyForth IDE, but I think that there is always going to be an overhead when you interface a GA144 to a clocked system - since the GA144 runs asynchronously it has to run a polling loop.
OK, it could idle between characters, but a better way would be to use the on-chip SERDES instead of RS232 to communicate with the outside world, and let another interface burn the current. This would also give a 400 x speed improvement.

BTW after reset the auto-baud loop uses 8 mA, presumably on one F18.

Best regards,
Howerd

[Paul Rubin]

Howerd <how...@yahoo.co.uk> writes:
> always going to be an overhead when you interface a GA144 to a clocked
> system - since the GA144 runs asynchronously it has to run a polling
> loop. OK, it could idle between characters,

Can't it use edge or level sensitive triggering on the port pin
listening to the rs232 signal? Then the GA node should block until the
bit actually arrives.

It also occurs to me, I don't see any way for a GA node to enter a sleep
for a given amount of time (say 100 microseconds), other than with a
full-speed busy loop and that 8 ma of power consumption. Compare that
with microcontrollers that have very low powered counter-timers.

8 ma is more than I expected for a single node anyway. It means over 1
amp for all 144 nodes going at once, or several watts of power. I
didn't realize the ga144 could use that much. Or, maybe the 8ma
includes other stuff too.

> but a better way would be to use the on-chip SERDES instead of RS232

The on-chip serdes is designed to only talk to other ga144's--do you
mean to add a third ga144 to the board?

[Mikael Nordman]

On 28.9.2012 0:16, Howerd wrote:
> I also ran a speed test :
> : asd 1000 for 1000 for 0 drop next next ;
> takes about 3 seconds.

> All in all it could compete with an MSP430, 8051 or a PIC except that
> only with the GA144 do you get so many fast cores with fast I/O to >
> play with.

Out of curiosity I ran the same speed test with FlashForth on PIC18,
PIC24 and AVR Atmega.

181 ms on PIC24 @ 54 MHz
750 ms on PIC18 @ 48 MHz
4154 ms on Atmega 328 @ 8 Mhz

Mike

[Marcel Hendrix]

Mikael Nordman <oh2...@invalid.com> writes Re: GA144 polyForth

That's remarkably good. On a 2.667 GHz i7 desktop machine, iForth (64bit)
takes 2.22 ms. Adjusting for clockspeed, 2.22 ms * 2667 / 54 = 110 ms, as
compared to PIC24's 181 ms.

The speed difference between PIC24 and PIC18 is much higher than the
expected factor of 2. I guess FlashForth for PIC24 is radically different
and uses more of the available registers?

-marcel

[Howerd]

On Saturday, October 6, 2012 8:17:09 AM UTC+2, Paul Rubin wrote:

Hi Paul,

> ... I don't see any way for a GA node to enter a sleep

> for a given amount of time (say 100 microseconds), other than with a
> full-speed busy loop and that 8 ma of power consumption.

Yes - being asynchronous means that it has no idea of time.
But the only reason to wait for 100 ns is to synchronise with an external synchronous device - I'm stating the obvious here, but the GA144 is best suited to a fully asynchronous environment. If only the whole world was asynchronous - maybe it should be ;-)

> The on-chip serdes is designed to only talk to other ga144's--do you
> mean to add a third ga144 to the board?

Nope - there are already two on the eval board, one of them is already acting as the interface to the synchronous world, via USB and serial comms. The two chips communicate via serdes.
But the serdes protocol is very simple, and self clocking (as it must be!), so maybe it could be implemented in software on another chip. The auto-baud software needs at least 19200 baud to not overflow the 18 bit counter, so a reasonably fast ARM should be able to keep up.

There is a common theme here that I have noticed : The GA144 does things its own way, and it is difficult to interface it to the rest of the world which is doing things another way.

For example :
1. It would be great, but non-trivial, to run a USB stack on a handful of F18's. Does this mean that the GA144 should have hardware USB support added, or that USB should changed for something simpler?
2. SDRAM has a synchronous interface, but runs dynamically internally. I believe there are asynchronous RAMS, but thay are rare. Should the GA144 add a fast SDRAM module, or should the SDRAM chip be modified?
3. Most software is written with the assumption of large amounts of flat addressed memory ( doesn't the 1M byte DOS limit feel really tight? ). But you can write software in very small, colorForth size chunks. If you spread these around a few F18's maybe you can create something really cool.

Going back to the original point - yes the GA144 can wait in an idle state for a pin to change state, but it must poll to get timings. Maybe a neighbouring F18 could wait for a change of state on a fixed clock signal, say at 16 * baudrate, then pass this on. This should get the power down to a minimum. Then again, maybe fixed baud rate is not the right way to talk to a GA144...

What would be interesting is to move the polyForth virtual machine to the target GA144, using serdes to communicate with it, and then measure the power.
Maybe I'll find some time over Xmas :-)

Best regards,
Howerd

[Mikael Nordman]

On 6.10.2012 12:14, Marcel Hendrix wrote:
>> Out of curiosity I ran the same speed test with FlashForth on PIC18,
>> PIC24 and AVR Atmega.
>
>> 181 ms on PIC24 @ 54 MHz
>> 750 ms on PIC18 @ 48 MHz
>> 4154 ms on Atmega 328 @ 8 Mhz
>
> That's remarkably good. On a 2.667 GHz i7 desktop machine, iForth (64bit)
> takes 2.22 ms. Adjusting for clockspeed, 2.22 ms * 2667 / 54 = 110 ms, as
> compared to PIC24's 181 ms.
>
> The speed difference between PIC24 and PIC18 is much higher than the
> expected factor of 2. I guess FlashForth for PIC24 is radically different
> and uses more of the available registers?
>
> -marcel
>
>

The 16-bit PIC24 has much better adressing modes than the
8-bit processors. This is partly due to that the PIC24
has a 24-bit instruction word so it can fit more data
in one instruction.

Normalized for 8 MHz Fosc the comparative figures are
PIC24: 1221 ms
PIC18: 4500 ms
Amega: 4154 ms

Normalized for 8 MIPS peak instruction rate:
PIC24: 610 ms (16 Mhz Fosc)
PIC18: 1125 ms (32 MHz Fosc)
Amega: 4154 ms (8 Mhz Fosc)

The decrement of TOR in NEXT is just one instruction.
PIC24: dec [--W15], [W15++] ; XNEXT
bra c, back


Here it is 3 instructions.
PIC18: decf TOSL, F, A ; XNEXT
movlw 0
subwfb TOSH, F, A
bc back

And for the Atmega its 12 instruction cycles.
It would be only 5 cycles if the
NEXT code is inlined. But I decided
to save space instead of making it fast.
Atmega: call XNEXT
brcc back
; (next) decrement top of return stack
XNEXT:
pop zh
pop zl
pop xh
pop xl
sbiw xl, 1
push xl
push xh
ijmp

Mike

[Paul Rubin]

Mikael Nordman <oh2...@invalid.com> writes:
> 181 ms on PIC24 @ 54 MHz
> 750 ms on PIC18 @ 48 MHz
> 4154 ms on Atmega 328 @ 8 Mhz

Out of curiosity I tried it in JSForth in Firefox 15 on my Core 2
laptop:

http://forthfreak.net/jsforth80x25.html

I don't have a convenient way to time it precisely but I'd guess it used
around 1/8 of a second.

[rickman]

On 10/6/2012 8:47 AM, Howerd wrote:
> On Saturday, October 6, 2012 8:17:09 AM UTC+2, Paul Rubin wrote:
>> Howerd<how....@yahoo.co.uk> writes:
>>> always going to be an overhead when you interface a GA144 to a clocked
>>> system - since the GA144 runs asynchronously it has to run a polling
>>> loop. OK, it could idle between characters,
>>
>> Can't it use edge or level sensitive triggering on the port pin
>> listening to the rs232 signal? Then the GA node should block until the
>> bit actually arrives.

That is how many MCUs time an async data stream, but they have to have a
timer running so they can record the time of each transition. The GA144
is capable of implementing timers the same way by monitoring a clock
input, but GA doesn't seem too interested in using this sort of
operation. Chuck's work seems to focus on no clock at all which is not
practical. He tried that with his video circuits and found the VGA
signal from software loop timing was not stable enough to work with his
monitor, and that is a *relaxed* application.

>> It also occurs to me, I don't see any way for a GA node to enter a sleep
>> for a given amount of time (say 100 microseconds), other than with a
>> full-speed busy loop and that 8 ma of power consumption. Compare that
>> with microcontrollers that have very low powered counter-timers.

The async processor goes to sleep until an input triggers it. So why
not use a clock for that input? Then the GA144 core could utilize very
little power just waiting.

>> 8 ma is more than I expected for a single node anyway. It means over 1
>> amp for all 144 nodes going at once, or several watts of power. I
>> didn't realize the ga144 could use that much. Or, maybe the 8ma
>> includes other stuff too.

8 mA is too high for a single node. One node is about 5 mW which would
be around 3 mA I believe. Still it's in that ballpark. With all 144
nodes running the power consumption is around three quarters of a Watt.
But the power consumption is instruction dependent, so you need to
qualify that. Just like the instruction rate is not 700 MIPS, but
depends on your code the power consumption depends on your code too.

>>> but a better way would be to use the on-chip SERDES instead of RS232

The SERDES is useless for talking to anything other than another GA
device. At least it is not supported in any other mode. I'm not sure
what protocol they use, but the clocking rate varies widely and so is
hard to interface to other devices. At least this is what I got out of
the specs and lack of other info.

>> The on-chip serdes is designed to only talk to other ga144's--do you
>> mean to add a third ga144 to the board?
>
> Hi Paul,
>
>> ... I don't see any way for a GA node to enter a sleep
>> for a given amount of time (say 100 microseconds), other than with a
>> full-speed busy loop and that 8 ma of power consumption.
> Yes - being asynchronous means that it has no idea of time.
> But the only reason to wait for 100 ns is to synchronise with an
external synchronous device - I'm stating the obvious here, but the
GA144 is best suited to a fully asynchronous environment. If only the
whole world was asynchronous - maybe it should be ;-)

To sync with a sync device it would just wait for the clock signal.
Sync devices always use a clock. The reason for waiting for some amount
of time is to reduce power when you have nothing to do. That means you
need a timer to start the processor again. That can be done by a timer
node using an external clock.

The world will become async as soon as no one cares about speeds or times.

>> The on-chip serdes is designed to only talk to other ga144's--do you
>> mean to add a third ga144 to the board?
> Nope - there are already two on the eval board, one of them is
already acting as the interface to the synchronous world, via USB and
serial comms. The two chips communicate via serdes.
> But the serdes protocol is very simple, and self clocking (as it must
be!), so maybe it could be implemented in software on another chip. The
auto-baud software needs at least 19200 baud to not overflow the 18 bit
counter, so a reasonably fast ARM should be able to keep up.

Are you mixing the SERDES and the software UART? ARMs and many other
processors implement software UARTs. The SERDES runs at 100's of MHz.
That is too fast for any CPU I am aware of to implement in software...
assuming you knew the protocol.

> There is a common theme here that I have noticed : The GA144 does
things its own way, and it is difficult to interface it to the rest of
the world which is doing things another way.

Duh, not only other digital systems, but lots of real world applications
are hard to interface to the GA144. Clocks tell us time and nearly
everything is time based.

> For example :
> 1. It would be great, but non-trivial, to run a USB stack on a
handful of F18's. Does this mean that the GA144 should have hardware USB
support added, or that USB should changed for something simpler?

"Trivial"??? If that were true, GA would have done it already and put
the code in the cores so it could boot from USB without the support
chips from FTDI.

> 2. SDRAM has a synchronous interface, but runs dynamically
internally. I believe there are asynchronous RAMS, but thay are rare.
Should the GA144 add a fast SDRAM module, or should the SDRAM chip be
modified?

Async RAMs are not "rare", in fact that is what is on the GA144 eval
board. They aren't dense and they can be expensive, but the ones GA
picked aren't too bad at around $5.

The problem with DRAMs (the generic term for all dynamic memory) is that
they must be operated with both minimums and maximums on the timing
signals. The maximums are not too hard to meet, but typically designers
want to run the DRAMs as fast as possible. In the old days when DRAM
interfaces were async (meaning no clock, not lack of timing constraints)
it could be hard to optimize this interface. SDRAM added a clock and
gave the interface specific timing related to that clock. I tried to
design an SDRAM software interface for the GA144 and the big problem is
trying to make the processors run the interface anywhere close to full
speed. I think I could get it to run at 50 MHz, but I can't be sure
because they don't provide all the timing data for this sort of design.
But 50 MHz is not even half speed for the old single data rate SDRAM
and is nowhere near the rates of DDR, DDR2 or DDR3.

Don't try to turn this into a problem with the memory devices. They
work just fine. The problem is that GA won't put a proper memory
interface on the chip which will run at memory speeds. Instead they use
software which runs much slower than optimal.

> 3. Most software is written with the assumption of large amounts of
flat addressed memory ( doesn't the 1M byte DOS limit feel really tight?
). But you can write software in very small, colorForth size chunks. If
you spread these around a few F18's maybe you can create something
really cool.

Yes, there are apps which will suit the GA144 small memory model, but
they aren't the same apps that are typically running on >1MB devices.
Remember the memory chunks are only 64 words per processor for both
program and data. So even with 144 of them you only have some 9 kWords
of memory on chip. Otherwise you have to load the programs and data
from external memory. Memory can be a real bottle neck unless you are
running a pretty special app that fits the GA144. I think digital
receivers are one class of app that might work ok on this device, but I
don't know of any others.

> Going back to the original point - yes the GA144 can wait in an idle
state for a pin to change state, but it must poll to get timings. Maybe
a neighbouring F18 could wait for a change of state on a fixed clock
signal, say at 16 * baudrate, then pass this on. This should get the
power down to a minimum. Then again, maybe fixed baud rate is not the
right way to talk to a GA144...

Yes, an external clock and a timer node is the way to get timing data.
But to suggest that you shoudldn't talk to the GA144 with a fixed baud
rate is not very realistic. What part of the world is going to change
to suit the GA144?

One way to do this is to work with a two wire interface, one wire for
clock and one wire for data. Whoever is sending the data sends the
clock and the receiver has the option of slowing the clock like in I2C.
Or they could just add some hardware to handle this properly for
whatever interface you don't like.

> What would be interesting is to move the polyForth virtual machine to
the target GA144, using serdes to communicate with it, and then measure
the power.
> Maybe I'll find some time over Xmas :-)
>
> Best regards,
> Howerd

Rather than play with the board to measure things that don't likely
matter to the world, what do you think you could use this device for
that would be a better implementation than other devices?

Rick

[Bernd Paysan]

rickman wrote:
> The async processor goes to sleep until an input triggers it. So why
> not use a clock for that input? Then the GA144 core could utilize
> very little power just waiting.

You wrote it above: Chuck stops the clock, there is no clock to be used
during sleeping time.

You can stop your clock in a serial interface after the stop bit,
waiting for the next start bit (that's the purpose of the start bit, to
provide a transition). You have to keep it running until the stop bit
arrives.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Howerd]

Hi Rick,

> 8 mA is too high for a single node. One node is about 5 mW which would
> be around 3 mA I believe.

This is consistant with three nodes being active - the comms, bitsy and stack.
Comms could wait for a clock signal, and the polyForth VM could be put into an idle mode, presumably.

> > 1. It would be great, but non-trivial, to run a USB stack on a
> handful of F18's. Does this mean that the GA144 should have hardware USB
> support added, or that USB should changed for something simpler?
> "Trivial"???

No, I said non-trivial! It would make a great PHD project :-)

> nearly everything is time based.

This is true, but this is just because everything is time based - its a self-fulfilling prophecy. The GA144 has no problem measuring time, just that it does so in its units. It can, of course, compare this to a reference clock if required.

> What part of the world is going to change to suit the GA144?

Any part that comes into contact with it - maybe the way things are done at the moment is not the only way. After all, Chuck designed the GA144 using colorForth...

> One way to do this is to work with a two wire interface...
Another is to use the GA144 serdes protocol. IIRC it it very simple, and since it is self-clocking, you can run it at lower speeds too. My comment about ARM chips being able to implement it in software was because it needs to be reasonably fast, I believe, so as not to overflow the 18 bit counters.

> Don't try to turn this into a problem with the memory devices. They
> work just fine. The problem is that GA won't put a proper memory
> interface on the chip which will run at memory speeds.

I am not an expert on current memory technology, but it seems to me that any memory array returns its result when its ready, and most of the difficulty is in creating a synchronous interface to this. If this is true, what you are advocating is adding another synchronous interface to the GA144 to match the one on the RAM chip, and I am suggesting removing them both.

> Or they could just add some hardware to handle this properly for
> whatever interface you don't like.

I have been checking out the latest chips for an embedded upgrade - MSP430, 8051, even PIC24. They all seem to be a collection of interface modules wrapped around some sort of processor, rather than a processor with modules.
Instead of doing this, GA supply the simplest possible hardware, and allow the end user to program appropriate interfaces.
One solution is to put a conventional chip alongside a GA144 to handle all of these interfaces. Maybe this is a necessary evil to communicate with the rest of the world.

> what do you think you could use this device for
> that would be a better implementation than other devices?

I intend to use the GA144 to interface to one or more antennas. I have a "gut feeeling" that if you remove all of the simplifying assumptions between electromagnetic radiation and software you might be able to find some new properties of both.
I am particularly interested in the orbital angular momentum ( OAM ) property of electromagnetic radiation - I want to go back to basics and see whether this can be measured easily with a GA144. I think the 6 GHz counter and VCO might be able to resolve OAM effects. We shall see...

Best regards,
Howerd

[rickman]

On 10/8/2012 2:10 PM, Bernd Paysan wrote:
> rickman wrote:
>> The async processor goes to sleep until an input triggers it. So why
>> not use a clock for that input? Then the GA144 core could utilize
>> very little power just waiting.
>
> You wrote it above: Chuck stops the clock, there is no clock to be used
> during sleeping time.
>
> You can stop your clock in a serial interface after the stop bit,
> waiting for the next start bit (that's the purpose of the start bit, to
> provide a transition). You have to keep it running until the stop bit
> arrives.
>

I'm not sure what clock you are talking about. I'm talking about a
clock that is used to measure the period of the async bits, a
requirement in an async protocol.

The UART node can be stopped waiting for a transition on the input.
When the start bit transition happens on the async input the UART node
sends a message to the timer node which counts external timing clock
edges to measure time. Meanwhile both nodes stop. The timer node waits
for clock edges and the UART node waits for a message from the timer
node as well as further edges from the async input. If the async input
transitions first the bit is considered noise and the UART node starts
over. If the timer message arrives first this marks the middle of the
start bit. On subsequent timer messages the UART node reads the async
input to get data and overhead bits.

I believe Chuck does not like to use an external clock because it is
"extra" hardware and dissipates power. But a 5 mW node is not exactly a
"light" footprint to do nothing other than mark time. I prefer the
external clock.

Rick

[rickman]

OAM eh? What aspects of the GA144 will enable this to be measured
better than other methods? The 5.6 GHz counter is just an ADC with a
variable resolution vs. sample rate. There are lots of ADC available
with very high sample rates and much better resolution.

Rick

[Howerd]

Hi Rick,

> OAM eh? What aspects of the GA144 will enable this to be measured
> better than other methods?

The fact that there is minimum hardware between the antenna and the transistors that measure voltage - I am also looking for macroscopic quantum effects.
If you read voltage using an ADC with amplifiers, filtering, anti-aliassing etc you are bound to observe what the theory says is there, because that theory was used to design the system. I want to get closer to the hardware.

Best regards,
Howerd

[rickman]

What sample rate do you plan to use? I guess I'm curious about how you
plan to proceed. I can't think of anything the GA144 can do that other
ADC devices can't.

I quickly read about OAM after reading your first post and I don't think
it is in defiance to existing theory. I think no one (or few until
recently) bothered to look for it. If it can't be observed using
scientific methods, then it won't be of much use in building transceivers.

BTW, the GA144 ADC has all the same limitations you mention above, if
you think it gets around any of the above, check again. The issue with
anti-aliasing is not eliminated, it is just addressed in the ADC method
to some extent. If you read up you will find the GA144 ADC anti-alias
functionality is pretty poor for most applications depending on the
frequencies you wish to exclude and which you wish to include.

Rick

Rick

[Howerd]

Hi Rick,

> What sample rate do you plan to use?

I'm not intending to use the VCO as a conventional ADC, just observe the count as the voltage changes, so the sample rate will vary with voltage. Alos, mostly I want to measure timings.

> I quickly read about OAM after reading your first post and I don't think
> it is in defiance to existing theory.

Yes, OAM is predicted by quantum mechanics, and was first observed in 1935 IIRC.
Very much existing theory.

The theory that I want to get away from is where it is assumed that an electric field can be approximated by a scalar voltage. This may require 2, 3 or 4 receiving antennas and a transmitting antenna - measuring all signals in a synchronised way.

> The issue with anti-aliasing is not eliminated, it is just addressed
> in the ADC method to some extent.

My plan is to make some measurements of timings on wires and antennas, present them on a PC using colorForth (booted from a USB stick using USBboot), then relate this to the theory... Anti-aliassing will no doubt come into this at some stage.

Best regards,
Howerd

[rickman]

On 10/13/2012 10:39 AM, Howerd wrote:
> Hi Rick,
>
>> What sample rate do you plan to use?
> I'm not intending to use the VCO as a conventional ADC, just observe the count as the voltage changes, so the sample rate will vary with voltage. Alos, mostly I want to measure timings.

I'm not sure I follow that. How will you change your sample rate? BTW,
unless I don't understand the why the ADC works, every time you read the
ADC it stops the counter for a short time. Be aware of this as it may
have an impact on your measurements if not accounted for.

>> I quickly read about OAM after reading your first post and I don't think
>> it is in defiance to existing theory.
> Yes, OAM is predicted by quantum mechanics, and was first observed in 1935 IIRC.
> Very much existing theory.
>
> The theory that I want to get away from is where it is assumed that an electric field can be approximated by a scalar voltage. This may require 2, 3 or 4 receiving antennas and a transmitting antenna - measuring all signals in a synchronised way.

I still don't see how the GA144 ADC is any different for this than any
other ADC.

>> The issue with anti-aliasing is not eliminated, it is just addressed
>> in the ADC method to some extent.
> My plan is to make some measurements of timings on wires and antennas, present them on a PC using colorForth (booted from a USB stick using USBboot), then relate this to the theory... Anti-aliassing will no doubt come into this at some stage.

Anti-aliasing is used to prevent signals above the Nyquist rate (1/2
your sample rate) from affecting your measurement of baseband signals.
If you aren't sampling in the conventional sense, there is no need to
anti-alias. But then I'm not clear what you *are* doing so I can't say
for sure.

Rick

[Howerd]

Hi Rick,

> every time you read the ADC it stops the counter for a short time

There is no ADC, just a fast counter clocked by a VCO.

> I still don't see how the GA144 ADC is any different for this than any
> other ADC.

Its no different to any other VCO and counter, but it is possible to pass the count value on to other cores to process, before passing it to the outside world. That and having five of these on each chip makes it very good for waht I want to do.

> Anti-aliasing is used to prevent signals above the Nyquist rate (1/2
> your sample rate) from affecting your measurement of baseband signals.

If I run the VCO flat out at 5GHz, using it as a over-sampled one-bit ADC this should be OK for 10 MHZ signals. If this is possible, of course - I may need to drop it down to 2.5GHz.

> But then I'm not clear what you *are* doing so I can't say for sure.

Maybe you have guesed that I'm not clear how to achieve what I want ;-)
But my direction is clear : for each antenna measure the electrical signal on an input pin as using the minimum number of transistors possible. Look at what really goes on when electicity interacts with antennas. Play it by ear...
I would like to start by repeating Chuck's measurement of wire length by timing a pulse bouncing back from the end of the wire.

Best regards,
Howerd

[rickman]

And the name they give it is an "ADC". Analog in, Digital out...

>> I still don't see how the GA144 ADC is any different for this than any
>> other ADC.
> Its no different to any other VCO and counter, but it is possible to pass the count value on to other cores to process, before passing it to the outside world. That and having five of these on each chip makes it very good for waht I want to do.

The question is how will you make use of this data? If you aren't going
to treat it as the digital equivalent of an analog waveform, just what
is it?

>> Anti-aliasing is used to prevent signals above the Nyquist rate (1/2
>> your sample rate) from affecting your measurement of baseband signals.
> If I run the VCO flat out at 5GHz, using it as a over-sampled one-bit ADC this should be OK for 10 MHZ signals. If this is possible, of course - I may need to drop it down to 2.5GHz.

This statement clearly shows you don't understand what a VCO is. You
*don't* run the VCO "flat out". The frequency varies with the input
voltage, the voltage you are trying to measure. The frequency varies
with the input voltage and drives the counter. By reading the counter
at known times you can subtract successive values getting the difference
which corresponds to the average voltage in that time period. You can
process the counter values as you wish, but the frequency of the VCO is
not constant.

How do you think the VCO works? Or are you planning to drive the VCO
with Vss? Then what do you do with the input voltage?

>> But then I'm not clear what you *are* doing so I can't say for sure.
> Maybe you have guesed that I'm not clear how to achieve what I want ;-)
> But my direction is clear : for each antenna measure the electrical signal on an input pin as using the minimum number of transistors possible. Look at what really goes on when electicity interacts with antennas. Play it by ear...
> I would like to start by repeating Chuck's measurement of wire length by timing a pulse bouncing back from the end of the wire.

Ok, that should be pretty simple, but make sure it is a long enough
wire. The CPU is fast, but not that fast. The 700 MIPS number is a
peak rate and you can't get too close to that with real code.

Rick

[Howerd]

Hi Rick,

> And the name they give it is an "ADC"

Yes, OK, I meant not a conventional ADC, i.e. not delta-sigma, successive approximation, integrating etc...

> The question is how will you make use of this data? If you aren't going
> to treat it as the digital equivalent of an analog waveform, just what
> is it?

I want to interact with RF electrical signals using Forth, the same way I do with any other piece of hardware.
So I don't know what I will do with the data - it depends on what I find.
I am hoping it will be like firing up a new processor with Forth for the first time and probing its peripherals, checking what I see against the databook.

> This statement clearly shows you don't understand what a VCO is.

No, it shows that I did not express myself clearly ;-)
I will probably run the VCO with an input voltage very close to Vss, and just look at the bottom bit of the counter. This will give me a 1-bit ADC with a 5 GHz sampling rate, if you want to look at it that way.
I want to detect the smallest possible voltage and time variations, then average them over human-scale time periods. I'm also not interested in absolute values of either voltage or time, just deltas.

> The CPU is fast, but not that fast.

True, but its the VCO that determines the sampling rate - 5 GHz has a wavelength of 5.9 cm. 50 GHz would be better...

Best regards,
Howerd

[rickman]

Then you are looking for resolution, not VCO speed. You can use the
GA144 ADC for high resolution at very slow sample rates. But if you
don't know what you are looking for, I'm not sure how you will know when
you find it.

Many other ADCs will give you very high resolution as well.

>> The CPU is fast, but not that fast.
> True, but its the VCO that determines the sampling rate - 5 GHz has a wavelength of 5.9 cm. 50 GHz would be better...

The rate of the VCO is not the sample rate of the ADC. The VCO is
analog at the interface to the input signal and the frequency is analog
(continuously variable). It is the counter that is digital.

Rick

[Howerd]

Hi Rick,

> Then you are looking for resolution, not VCO speed.

I am looking for both - detection of very small signals and very small time intervals.

> Many other ADCs will give you very high resolution as well.

Digital resolution, yes, but analog resolution probably not.

> GA144 ADC for high resolution at very slow sample rates.

I think you are using "resolution" in two different ways - there is analog resolution ( ability to detect a given change in voltage ), and ADC resolution ( number of bits ).

> The rate of the VCO is not the sample rate of the ADC

It is if it is a 1-bit ADC, sort of.

Its the analog resolution that I am interested in. I presume that the GA144's VCO is just a handful of transistors, so the bottom bit of the VCO count represents some very small change in the charge at the input pin.

Only with the GA144 do I get very sensitive analog inputs together with some fast processing, plus a high level (eForth or polyForth) IDE, all on chip.
I think this is magic :-)

Best regards,
Howerd

Best regards,
Howerd

[rickman]

In the GA144 the time interval will be determined by the CPU speed, I
think the best you might get is around 10 ns, but I don't recall
exactly, this might be for a clock timed loop that just takes the data
and passes it on. At that speed you will only get 4.3 ENOB (effective
number of bits) theoretical max. That's not very sensitive.

>> Many other ADCs will give you very high resolution as well.
> Digital resolution, yes, but analog resolution probably not.

Uh, yeah... right. It's time to learn about electronics. You can
think that you are going to toss existing theory out the window, but
this is not the area that needs to be reinvented in order to learn
about... what was it you were exploring again?

>> GA144 ADC for high resolution at very slow sample rates.
> I think you are using "resolution" in two different ways - there is analog resolution ( ability to detect a given change in voltage ), and ADC resolution ( number of bits ).

Yes, they are related by the gain of your amplifiers... uh, if you had
amplifiers. In the GA144 integrating ADC the analog resolution will be
related to the sample rate... if you have a sample rate. The faster
the sample rate the lower the analog resolution. The 4.3 bits I mention
above are over the analog range of about 1.2 volts, this is not well
defined in the data sheet, so I'm not certain what this range is. The
ADC has a non-linear curve with more resolution in the center which is
what I am assuming will be used. Trying to get the full analog range of
1.8 volts uses the compressed ranges near the limits with very low
analog resolution.

The digital resolution is the number of bits. The analog resolution is
the analog range divided by the number of bits. No magic, no new
science to be invented. The two are directly connected. The only way
to improve the analog resolution is to slow down the measurement to give
longer integrations or to use an amplifier to get the same voltage range
at the ADC input with a smaller range on the amplifier input.

>> The rate of the VCO is not the sample rate of the ADC
> It is if it is a 1-bit ADC, sort of.

Ok, you can go ahead and think of this as a 1 bit ADC but that buys you
the worst possible resolution at the highest sample rate.

> Its the analog resolution that I am interested in. I presume that the GA144's VCO is just a handful of transistors, so the bottom bit of the VCO count represents some very small change in the charge at the input pin.

No, the counter bits do NOT correspond to anything at the input. The
counter free runs at a rate between about 3.5 GHz and 5.5 GHz. The raw
readings just keep incrementing and the absolute values mean nothing.
You get an ADC reading by SUBTRACTING one reading from the next. This
DIFFERENCE is proportional to the integral of the voltage at the input
over the sample period.

Actually, the range of the VCO in the linear area is only about 1.3 or
1.4 GHz rather than the 2 GHz I used to calculate the ENOB. The
frequency range is what determines the difference range and the ADC
resolution.

> Only with the GA144 do I get very sensitive analog inputs together with some fast processing, plus a high level (eForth or polyForth) IDE, all on chip.
> I think this is magic :-)

Yes, I expect it must seem like magic... Or you could listen to people
who don't see it as magic, but rather understand the details and can
explain how it works as if it were engineering...

I'm pretty sure you won't see anything in your signals using the GA144
that you can't see as well if not better using other devices. For
example, how well will your readings be time correlated using multiple
ADCs in the GA144? I can't get an answer to questions like this. Or
even how long the GA144 nodes take to come out of sleep when the input
clock transitions. These are *very* important numbers when using the
ADC for signal acquisition. Random delays here cause signal
distortion/noise.

Rick

[Howerd]

Hi Rick,

> You can think that you are going to toss existing theory out the window,...
Not at all - I am looking for observable effects predicted by existing
theory.

> The digital resolution is the number of bits.

Ageed.

> The analog resolution is the analog range divided by the number of bits.

Only in the most simplistic model, ignoring oversampling, compressed
sampling, and maybe some other effects.

What concerns me here is that you seem to have such confidence in your
theoretical models of what goes on in electronic circuits.
Surely any theory only covers the available data, and must be modified
when new data comes long that doesn't fit in.
I want to look for new data...

I think the discussion of the GA144's ADC is missing the point. Let me
try to explain by describing two circuits :

1. An antenna, RF amplifier, anti-aliassing filter, very fast ADC,
fast DSP. Say some electrons wander down the antenna - what does it
take to observe a change in the DSP's output?

2. An antenna connected to the VCO input of an F18. The VCO is
presumably very few FET's arranged to oscillate, clocking a line of
edge triggered flip-flops. Bit 0 of the counter is averaged at, say,
100 Mhz rate.

I predict that #2 would be more sensitive, i.e. it would take fewer
electrons to make a visible change. There is also significantly more
possibility of quantum coupling efects occuring over just a few
transistors than over circuit #1.

Also, if I do not find any interesting new effects using the GA144,
there is not much more to be done, besides going to a faster chip
process, since this looks to me like the absolute minimum number of
components to convert a signal at the antenna to something useable.

I have nothing against circuit #1 - it does exactly what it is
designed to do.

Here are some questions that might be answered experimentally by the
GA144 :

1. does electrical current flowing down a wire have oribital angular
momentum (OAM), and if so could this be useful?
2. if a radio wave containing OAM arrives at two antennas, can the OAM
be detected by two F18 VCO's ?
3. is it posible to demodulate RF signals using an GA144 by applying
simple fast algorithms?

> how well will your readings be time correlated using multiple ADCs in the GA144?

This interests me too. There are two F18's with analog pins next to
each other, so it would be possible to have one waiting for the other
with just the latching time of the ports between them. I would expect
jitter of around 10ns if the F18 cores are also doing something useful
with the data, but this is really just a guess.

> Or even how long the GA144 nodes take to come out of sleep when the input clock transitions.

As I understand this, the GA144 doesn't "go to sleep" - it is clocked
by receiving an instruction on one of its ports.
So no time at all.
The VCO-counting-ADC is free running, so any two would be independent.
You could synchronise reading them, but the read pulse would not be
connected to the VCO, so I would expect a lot of jitter. I think the
GA144's ADC's are good for audio maybe, but not for low jitter, high
speed, high resolution measurements.

In my experience, it is best never to use ADC's, but to convert the
signal you want to measure into a time period. The GA144 is good at
measuring time periods...

I'm sorry if this sounds like the classic Forth question and answer :
Q. how would you do X in Forth? A. don't do X, do Y.

Best regards,
Howerd

[rickman]

Then why do you need to use something that you feel will uncover things
that haven't been seen before? If it fits in with existing theory, then
it should be observable with existing technology.

>> The digital resolution is the number of bits.
> Ageed.
>
>> The analog resolution is the analog range divided by the number of bits.
> Only in the most simplistic model, ignoring oversampling, compressed
> sampling, and maybe some other effects.
>
> What concerns me here is that you seem to have such confidence in your
> theoretical models of what goes on in electronic circuits.
> Surely any theory only covers the available data, and must be modified
> when new data comes long that doesn't fit in.
> I want to look for new data...

That's fine, but my point is that you have said nothing understandable
that indicates the GA144 will do anything any other ADC can't do. You
talk about 5 GHz as if it is the sample rate and it isn't, you talk
about the counter lsb as if this is somehow related to a very low
sensitivity voltage and it isn't. Before you can even make a
measurement with the GA144 ADC you need to understand how it works and
how it doesn't work.

> I think the discussion of the GA144's ADC is missing the point. Let me
> try to explain by describing two circuits :
>
> 1. An antenna, RF amplifier, anti-aliassing filter, very fast ADC,
> fast DSP. Say some electrons wander down the antenna - what does it
> take to observe a change in the DSP's output?

Your use of "DSP's output" is not clear. Do you mean the ADC output?
To see a change you need enough voltage at the input to the ADC to cross
one of the many thresholds in the ADC. This will of course on the
voltage change at the antenna, the characteristics of the filter and the
gain of the amplifier.

> 2. An antenna connected to the VCO input of an F18. The VCO is
> presumably very few FET's arranged to oscillate, clocking a line of
> edge triggered flip-flops. Bit 0 of the counter is averaged at, say,
> 100 Mhz rate.

This made sense until you talk about bit 0 "averaged at" 100 MHz. I
don't know what that means. The frequency of the VCO output will vary
between the values I listed the other day. Bit 0 will toggle at half
that rate. Of course, this rate varies with the voltage of the input
signal.

> I predict that #2 would be more sensitive, i.e. it would take fewer
> electrons to make a visible change. There is also significantly more
> possibility of quantum coupling efects occuring over just a few
> transistors than over circuit #1.

Quantum coupling to what? How will the VCO frequency change with
quantum coupling? What in the GA144 will let you detect quantum
coupling if it does happen? I don't recall a quantum coupling detector
listed in the data sheet.

I don't see how the GA144 is any more sensitive to the antenna signal
than the GA144. In fact the GA144 can be fairly insensitive depending
on the sample rate. At high sample rates it is very insensitive.

> Also, if I do not find any interesting new effects using the GA144,
> there is not much more to be done, besides going to a faster chip
> process, since this looks to me like the absolute minimum number of
> components to convert a signal at the antenna to something useable.
>
> I have nothing against circuit #1 - it does exactly what it is
> designed to do.
>
> Here are some questions that might be answered experimentally by the
> GA144 :
>
> 1. does electrical current flowing down a wire have oribital angular
> momentum (OAM), and if so could this be useful?

If you are going to measure this, you need to predict outcomes. What
will be observed if you do detect OAM? What will be observed if you
don't detect OAM? Until you can answer that question there is no
experiment really.

> 2. if a radio wave containing OAM arrives at two antennas, can the OAM
> be detected by two F18 VCO's ?

I give up, can it?

> 3. is it posible to demodulate RF signals using an GA144 by applying
> simple fast algorithms?

I can answer this one, yes. Just like you can demodulate RF signals
using simple, fast algorithms on any other processor.

>> how well will your readings be time correlated using multiple ADCs in the GA144?
> This interests me too. There are two F18's with analog pins next to
> each other, so it would be possible to have one waiting for the other
> with just the latching time of the ports between them. I would expect
> jitter of around 10ns if the F18 cores are also doing something useful
> with the data, but this is really just a guess.

10 ns is a long time in the RF world. If you sample a 100 MHz carrier
(middle of the FM band) this is an entire cycle of the carrier, 360
degrees, 2 pi radians, lots of confusion possible here.

Some folks posting here who worked with GA claim there can be low double
digit ps of uncertainty in the sampling time, but I think this depends
on a great many factors and I can't get answers out of GA to confirm any
of it.

>> Or even how long the GA144 nodes take to come out of sleep when the input clock transitions.
> As I understand this, the GA144 doesn't "go to sleep" - it is clocked
> by receiving an instruction on one of its ports.
> So no time at all.

Hmmm, a difference of nomenclature. When I say "sleep" and you say
"clocked" we are talking about the same thing. While it is waiting for
the input transition it is "asleep". Or you could say it is "crouched"
like a cat, waiting to "spring" and "pounce" on its "prey", opps, I mean
"data". Cat like reflexes! Yes, I want Schrödinger's cat in my CPUs...

> The VCO-counting-ADC is free running, so any two would be independent.
> You could synchronise reading them, but the read pulse would not be
> connected to the VCO, so I would expect a lot of jitter. I think the
> GA144's ADC's are good for audio maybe, but not for low jitter, high
> speed, high resolution measurements.

I thought you were interested in high resolution??? Now I'm very confused.

> In my experience, it is best never to use ADC's, but to convert the
> signal you want to measure into a time period. The GA144 is good at
> measuring time periods...

Oh, do you have lots of experience with this? How does the GA144
measure time periods? I think Chuck does it by tying the ADC input to
Vdd which will run the VCO at max rate. After calibrating (somehow) he
examines the counter at the start and the end of a time period. Is this
what you mean? Notice that there is no input signal in this example.
Where would you connect your input signal?

> I'm sorry if this sounds like the classic Forth question and answer :
> Q. how would you do X in Forth? A. don't do X, do Y.

I'm still confused, what is X again? No, what is Y? No, I am asking
"why", no, I want to know "ex"...

Who's on first?

Rick

[Howerd]

Hi Rick,

> If it fits in with existing theory, then it should be observable with existing technology.

Yes, the GA144 is existing technology...

> you have said nothing understandable that indicates the GA144 will do anything any other ADC can't do.

The GA144 is very simple, so the electrical path between input pin and
counter output is very short.
This might allow effects to be observed that would be smoothed out by
amplifiers, filters and conventional ADCs.

> You talk about 5 GHz as if it is the sample rate and it isn't,

If you clock a counter at 5GHz +/-100MHz, as the frequency changes the
value of bit 0 of the counter when observed every 10 ns will change,
and this value, if summed over a long period of time, will reflect the
change in frequency. Since this is a VCO a small change in voltage
will cause a small change in frequency which will cause a change in
the summed count value.
It depends on exactly how you define these terms, but you could view
this as an oversampled 1 bit ADC - I'm not sure whether the sample
rate is 5GHz or 100 MHz.
Either way this is not important for my application, because I am not
thinking of the VCO as an ADC.

> you talk about the counter lsb as if this is somehow related to a very low
> sensitivity voltage and it isn't.

As explained above, a small change in the VCO frequency will be shown
as a change in the summed counter value.
The high digital resolution is because of the oversampling, and the
high analog resolution is because of the summing ( or averaging ).

I see it this way : the VCO is DC biassed to run at some frequency,
say 1GHz, with a very small AC modulation applied to it ( from the
antenna ).
say the VCO runs between 1,000,000 Hz and 1,000,001 Hz as the AC
signal changes ( a 1 part 10E9 change ).
You read the VCO's counter every 10 ns, so you would see a count of
0 , 10 , 20 , 30 at the low frequency , with a missed count every
10E9 counts at the higher frequency. Average this over 1 second and
you would see a change of 1 in the counter as the AC input changed
( 1,000,000 mod 2**18 or 1,000,001 mod 2** 18 ).
To express this in terms of ADC's, it is a 10 x oversampled 1 bit ADC,
averaged over 1 second.
This has sacrificed analog range - you measure only deltas, but I am
only interested in deltas.
Given that you can display the change of 1 count on a PC screen, this
means that you can detect a change on the input pin that causes a 1 in
10E9 change in frequency - this is the high analog sensitivity that I
hope to see.

The thing that makes the GA144 special is that the electrical circuit
between input pin and counter is the smallest it could be, so there
could be very small quantum effects that would probably not occur with
a conventional ADC setup.

> While it is waiting for the input transition it is "asleep".

I understand sleep mode in terms of chips like the MSP430, where the
system clock is slowed down or stopped, and it takes some time to get
it back to full speed.
In the case of the MSP430 the design has been cleverly optimised for
fast wake-up ( 6 us IIRC ).
Since the GA144 has no clock, it does not have a distinct sleep state,
and therefore it has no wake up time.

>> In my experience, it is best never to use ADC's, but to convert the
>> signal you want to measure into a time period.

> Oh, do you have lots of experience with this?

Yes - I have used time measurement in preference to voltage on many
projects.

> How does the GA144 measure time periods?
> I think Chuck does it by tying the ADC input to Vdd which will run the VCO at max rate.

Yes, that is my understanding too. Its just a fast counter. Is there
any other way to measure time periods?

> Notice that there is no input signal in this example.
> Where would you connect your input signal?

On a digital input of a neighbouring F18, so that it captures the VCO
counter when the input changes state.

> I thought you were interested in high resolution??? Now I'm very confused.

I am interested in high resolution measurement of electrical charge
flowing into the analog input pin.
I think all this talk about ADC specs is confusing in this context...

> I'm still confused, what is X again?

X is " how can I use the GA144's VCO as a very high resolution ADC?"
Answer - you can't.
Y is " how can I use the GA144's VCO to measure very small analog
changes on its input pin with very high resolution?" Answer - see
above.

I have found this thread very helpful, as it has forced me to organise
and express my thoughts about what I would like to do with the GA144.
Hopefully I will find some time soon to actually do these tests - I
will report any results here :-)

Best regards,
Howerd

[rickman]

On 10/16/2012 7:12 AM, Howerd wrote:
> On Oct 15, 10:38 pm, rickman<gnu...@gmail.com> wrote:
>
> Hi Rick,
>
>> If it fits in with existing theory, then it should be observable with existing technology.
> Yes, the GA144 is existing technology...

That is not sufficient. There is a world of existing technology and
some will do the job and some won't. The point is... and I'm getting
really tired of trying to make it, if the stuff you want to measure fits
existing theory then the existing technology that also fits that theory
should be capable of measuring it. By existing technology I mean any
ADC that has adequate resolution and speed.

>> you have said nothing understandable that indicates the GA144 will do anything any other ADC can't do.
> The GA144 is very simple, so the electrical path between input pin and
> counter output is very short.
> This might allow effects to be observed that would be smoothed out by
> amplifiers, filters and conventional ADCs.

But you don't have any idea that I can tell of what you are looking for.
You never answered my question about what two outcomes would show the
existence or absence of the effect you want to measure.

>> You talk about 5 GHz as if it is the sample rate and it isn't,
> If you clock a counter at 5GHz +/-100MHz, as the frequency changes the
> value of bit 0 of the counter when observed every 10 ns will change,
> and this value, if summed over a long period of time, will reflect the
> change in frequency. Since this is a VCO a small change in voltage
> will cause a small change in frequency which will cause a change in
> the summed count value.

Why do you need to look at this one bit? To detect the change in
frequency over a long period you can just directly read the *entire*
counter and subtract subsequent readings. This value is directly
proportional to the frequency. The longer the period you monitor it the
greater the analog resolution. I'm not sure dealing with bit 0 the way
you describe will even give you a meaningful value. I believe you will
simply be monitoring what amounts to aliasing.

> It depends on exactly how you define these terms, but you could view
> this as an oversampled 1 bit ADC - I'm not sure whether the sample
> rate is 5GHz or 100 MHz.

It's not. The VCO won't run at 5 GHz unless your input voltage is very
close to Vdd.

> Either way this is not important for my application, because I am not
> thinking of the VCO as an ADC.

I know, you aren't thinking of it as an ADC, but you are using it as an

ADC.


>> you talk about the counter lsb as if this is somehow related to a very low
>> sensitivity voltage and it isn't.
> As explained above, a small change in the VCO frequency will be shown
> as a change in the summed counter value.

No, because the frequency shows up in the counter by taking the
difference.

> The high digital resolution is because of the oversampling, and the
> high analog resolution is because of the summing ( or averaging ).

If you say so.

> I see it this way : the VCO is DC biassed to run at some frequency,
> say 1GHz, with a very small AC modulation applied to it ( from the
> antenna ).

Ok, now you are biasing the ADC input with the input superimposed.

> say the VCO runs between 1,000,000 Hz and 1,000,001 Hz as the AC
> signal changes ( a 1 part 10E9 change ).
> You read the VCO's counter every 10 ns, so you would see a count of
> 0 , 10 , 20 , 30 at the low frequency , with a missed count every
> 10E9 counts at the higher frequency. Average this over 1 second and
> you would see a change of 1 in the counter as the AC input changed
> ( 1,000,000 mod 2**18 or 1,000,001 mod 2** 18 ).

Ok, so now you are reading the entire counter, not just bit 0. At the
higher frequency you won't see a missed count, you will see a count of
N+1. This is how I am suggesting that you use the ADC as an ADC. By
"average" I assume you mean integrate or "sum"? Average would loose
data unless you use fractions and then it is really just the same as
integrating with a wasteful division at the end.

> To express this in terms of ADC's, it is a 10 x oversampled 1 bit ADC,
> averaged over 1 second.

No, it is just the same ADC that is designed into the GA144 sampled very
fast and then the differences added back together which is the same as
just subtracting the first reading from the last.

> This has sacrificed analog range - you measure only deltas, but I am
> only interested in deltas.

That is how you use the ADC, take the delta of the counter readings.
This gives you the integral of the voltage over the sample period.

> Given that you can display the change of 1 count on a PC screen, this
> means that you can detect a change on the input pin that causes a 1 in
> 10E9 change in frequency - this is the high analog sensitivity that I
> hope to see.

What voltage will result in the change of 1? That depends on the period
over which you integrate, it has nothing to do with the bias you apply.
In fact, if you look at the ADC input curve you will see that it is
most sensitive at the mid range and by biasing it near Vdd you are in a
very flat range with little sensitivity.

> The thing that makes the GA144 special is that the electrical circuit
> between input pin and counter is the smallest it could be, so there
> could be very small quantum effects that would probably not occur with
> a conventional ADC setup.

Please explain how these quantum effects will be observed? What
difference will this make on your readings?

>> While it is waiting for the input transition it is "asleep".
> I understand sleep mode in terms of chips like the MSP430, where the
> system clock is slowed down or stopped, and it takes some time to get
> it back to full speed.
> In the case of the MSP430 the design has been cleverly optimised for
> fast wake-up ( 6 us IIRC ).

Not 6 us, any processor can start up in 6 us if you keep the oscillator
running or use gates for the oscillator. The F18A stops to wait for an
input and resumes in some time less than an instruction cycle. They
won't tell me how much of the port read instruction executes before the
sleep and how much happens after the sleep. But they tell me I am free
to measure it for myself...

> Since the GA144 has no clock, it does not have a distinct sleep state,
> and therefore it has no wake up time.

That is your terminology. Sleep means it is doing nothing and the
processor is doing nothing while it is waiting for an input transition.
Call it a rose if that makes you feel better.

>>> In my experience, it is best never to use ADC's, but to convert the
>>> signal you want to measure into a time period.
>> Oh, do you have lots of experience with this?
> Yes - I have used time measurement in preference to voltage on many
> projects.
>
>> How does the GA144 measure time periods?
>> I think Chuck does it by tying the ADC input to Vdd which will run the VCO at max rate.
> Yes, that is my understanding too. Its just a fast counter. Is there
> any other way to measure time periods?
>
>> Notice that there is no input signal in this example.
>> Where would you connect your input signal?
> On a digital input of a neighbouring F18, so that it captures the VCO
> counter when the input changes state.

What is this input signal? I thought we were talking about the antenna?

>> I thought you were interested in high resolution??? Now I'm very confused.
> I am interested in high resolution measurement of electrical charge
> flowing into the analog input pin.
> I think all this talk about ADC specs is confusing in this context...

No, what is confusing is that you won't talk about the ADC as an ADC.
To measure electrical charge flowing (otherwise known as current) you
need to add a resistor to turn the current into a voltage. Then the ADC
can measure the voltage.

>> I'm still confused, what is X again?
> X is " how can I use the GA144's VCO as a very high resolution ADC?"
> Answer - you can't.
> Y is " how can I use the GA144's VCO to measure very small analog
> changes on its input pin with very high resolution?" Answer - see
> above.

Ok, now I understand. You don't want to measure voltage, charge *or*
current, you want to measure ANALOG. I can see why you don't want to
use an ANALOG to DIGITAL converter to measure ANALOGs. That would be
pointless. BTW, perhaps you should share with the Green Arrays people
that their ADC can't measure with high resolution. It will be news to
them!!!

> I have found this thread very helpful, as it has forced me to organise
> and express my thoughts about what I would like to do with the GA144.
> Hopefully I will find some time soon to actually do these tests - I
> will report any results here :-)

Please keep us informed. I am finding this very entertaining... sort of.

Rick

[Howerd]

Hi Rick,

I've chopped the bulk of the reply post because it is getting way too
long...

>> X is " how can I use the GA144's VCO as a very high resolution ADC?"

> BTW, perhaps you should share with the Green Arrays people
> that their ADC can't measure with high resolution.

No, you can't use the VCO as a VERY high resolution ADC ( 30 bits ).
But you can, I think, use it to measure down to this level if you use
the counter directly, and not as a conventional ADC.

> You don't want to measure voltage, charge *or* current, you want to measure ANALOG.

Exactly. Voltage and current are scalar quantities, quantum mechanics
shows that electric fields are vectors, so current flowing in a wire
is a 1 dimensional representation of a 2 or more dimensional field.
If you measure voltage with chips that are desinged to measure
voltage, you will only see voltage.
So, yes I want to measure ANALOG, whtever that is.

I will keep you informed of progress...

Best regards,
Howerd

[rickman]

On 10/17/2012 2:05 AM, Howerd wrote:
> Hi Rick,
>
> I've chopped the bulk of the reply post because it is getting way too
> long...
>
>>> X is " how can I use the GA144's VCO as a very high resolution ADC?"
>> BTW, perhaps you should share with the Green Arrays people
>> that their ADC can't measure with high resolution.
> No, you can't use the VCO as a VERY high resolution ADC ( 30 bits ).
> But you can, I think, use it to measure down to this level if you use
> the counter directly, and not as a conventional ADC.

I think you need to read a bit more about the GA144 and how the ADC
works. There is no limit to the resolution of the ADC data word. Once
you actually understand how the ADC works, you will see that. But as
long as you keep talking about the constituent parts, you will not see it.

>> You don't want to measure voltage, charge *or* current, you want to measure ANALOG.
> Exactly. Voltage and current are scalar quantities, quantum mechanics
> shows that electric fields are vectors, so current flowing in a wire
> is a 1 dimensional representation of a 2 or more dimensional field.
> If you measure voltage with chips that are desinged to measure
> voltage, you will only see voltage.
> So, yes I want to measure ANALOG, whtever that is.

Hey, ANALOG is *your* term, not mine! Go back to your previous post,
you said, "Y is " how can I use the GA144's VCO to measure very small

analog changes on its input pin with very high resolution?" Answer - see

above." So what is an ANALOG that you are measuring changes in?


Rick

[Howerd]

Hi Rick,

> I think you need to read a bit more about the GA144 and how the ADC works.

Ah, the RTFM principle ;-)

> So what is an ANALOG that you are measuring changes in?

If I knew that, I wouldn't need to do the experiment.

Almost every mobile phone these days has a "chip antenna" - a small
block that picks up the RF. I don't know how these work, but they are
certainly not half wavelength dipoles. So there are some interesting
new developments in antenna technology that do not fit with my 1973-76
physics course.
I am curious what other possibilites exist, and the GA144 seems to be
an ideal chip experimenting with.

I want to get away from the (very useful) abstractions that are taught
in schools and get back to the simplest possible model that actually
fits the observations.

Best regards,
Howerd

[rickman]

:PhD? Hardly! A PhD dissertation is supposed to be about original
work, not the mere implementation of a standard protocol.

>> nearly everything is time based.
> This is true, but this is just because everything is time based - its a self-fulfilling prophecy. The GA144 has no problem measuring time, just that it does so in its units. It can, of course, compare this to a reference clock if required.

Ok, this is looney land type stuff. Time is measured in units of
seconds and the various SI defined powers of 10. Talking about GA144
units of time is a bit tongue in cheek as the GA144 has no way of
"measuring" time without a time reference. Don't pervert reality with
this sort of comment.

>> What part of the world is going to change to suit the GA144?
> Any part that comes into contact with it - maybe the way things are done at the moment is not the only way. After all, Chuck designed the GA144 using colorForth...

More loony land stuff. I don't think 100 years of electrical
engineering is going to reverse course to adapt to the GA144. I'm not
sure the "world" has even noticed its existence. "Wait, do you feel
that, a disturbance in the force? It must be the GA144!"

>> One way to do this is to work with a two wire interface...
> Another is to use the GA144 serdes protocol. IIRC it it very simple, and since it is self-clocking, you can run it at lower speeds too. My comment about ARM chips being able to implement it in software was because it needs to be reasonably fast, I believe, so as not to overflow the 18 bit counters.

Really? What is the GA144 SERDES protocol? What is the maximum rate,
the minimum? What is the setup and hold timing on the data? BTW, it is
*not* self-clocking. It has two wires, one is the clock and one is
data. That is *not* self clocking. I suppose you mean the chip defines
the clock rate, not an external timing reference. That is why I ask
about the protocol spec, there isn't one! They only have to make one
GA144 chip talk to the other GA144 chips and they don't spec the SERDES
to talk to any other devices.

>> Don't try to turn this into a problem with the memory devices. They
>> work just fine. The problem is that GA won't put a proper memory
>> interface on the chip which will run at memory speeds.
> I am not an expert on current memory technology, but it seems to me that any memory array returns its result when its ready, and most of the difficulty is in creating a synchronous interface to this. If this is true, what you are advocating is adding another synchronous interface to the GA144 to match the one on the RAM chip, and I am suggesting removing them both.

Yes, that would be much better, a memory with no interface. The GA144
can communicate with it via... well, what exactly?

>> Or they could just add some hardware to handle this properly for
>> whatever interface you don't like.
> I have been checking out the latest chips for an embedded upgrade - MSP430, 8051, even PIC24. They all seem to be a collection of interface modules wrapped around some sort of processor, rather than a processor with modules.
> Instead of doing this, GA supply the simplest possible hardware, and allow the end user to program appropriate interfaces.
> One solution is to put a conventional chip alongside a GA144 to handle all of these interfaces. Maybe this is a necessary evil to communicate with the rest of the world.

Necessary evil? No, this is the absurdity of thinking you can design a
useful chip and ignore the world it will be working in. The GA144 may
have some application in apps where it stands alone. But as a component
is a large system it is rather pointless. The only interfaces a user
can program on this chip are the slow, simple interfaces that *every*
other MCU already has without programming. In fact, I was just looking
at the Atmel SAM4 devices with the cortex M4 processor. They are very
low power and have just dozens of peripherals built in. Many of these
peripherals can't be done in software of the GA144 because the CPUs are
too slow.

When I looked at using the GA144 in an app which needs an interface to a
PC, I realized I would need to add an MCU to implement the USB interface
at high speed rates. Sometimes the 50 year old serial port is just not
enough!

>> what do you think you could use this device for
>> that would be a better implementation than other devices?
> I intend to use the GA144 to interface to one or more antennas. I have a "gut feeeling" that if you remove all of the simplifying assumptions between electromagnetic radiation and software you might be able to find some new properties of both.
> I am particularly interested in the orbital angular momentum ( OAM ) property of electromagnetic radiation - I want to go back to basics and see whether this can be measured easily with a GA144. I think the 6 GHz counter and VCO might be able to resolve OAM effects. We shall see...

Yes, we have already discussed this and it is clear that the GA144 has
no advantage over conventional ADCs for this app. But since you don't
understand how the GA144 ADC operates you can't see that. You also
haven't said how OAM might manifest itself in a measurement, so you
certainly can't say there is anything superior to any technique.

Rick

[rickman]

On 10/18/2012 2:53 PM, rickman wrote:
>
> Rick

I'm not sure what was wrong, but it appears that I replied to an old
message. Sorry if my reply sounded a bit cranky. It is just that much
of this has gotten to be repetitive so I couldn't tell it was an old
message, oddly enough.

Rick

[rickman]

No, I was right the first time. For some odd reason the newsreader is
showing my reply (the first one) as to an old message. But it was the
most recent message I was responding to and it is highly repetitive with
the rest of this conversation.

Rick

[Howerd]

Hi Rick,

I've chopped the original text here, again because its is getting too long...

>:PhD? Hardly! A PhD dissertation is supposed to be about original
>work, not the mere implementation of a standard protocol.

Since no one has implemented USB on a GA144 I think this counts as original.
My point about making a good PhD thesis is that it needs a substantial amount of time, such a PhD thesis could provide.

> "Wait, do you feel that, a disturbance in the force? It must be the GA144!"

I would describe it more as a feeling of excitement - something new, created out of a desire for simplicity.
The chip layout was designed using OKAD2 in colorForth.
The architecture of each F18 is a very well thought out Forth machine.
The GA144 has just enough hard-coded interfaces that it can boot, and uses a power efficient, asynchronous design.
Each F18 has a built in BIOS to allow it to communicate with all the other F18's. This has effectively extended Forth into the world of parallel computing.

If this was just talk and speculation I would be quite interested, but I have seen OKAD2 in action, and I have two GA144's on an eval board sitting on the shelf, waiting for me to find some free time... They are real and they work :-)
What's not to get excited about?
But of course YMMV - whatever floats your boat...

> What is the GA144 SERDES protocol? What is the maximum rate,
> the minimum? What is the setup and hold timing on the data? BTW, it is

> *not* self-clocking. It has two wires,...
It sounds like 18 bit SPI to me. The data sheet says 450MHz.
You are right about the two wires though - I was confusing it with the 1-wire protocol which only runs at ~25MHz - only twice as fast as USB full speed.

> No, this is the absurdity of thinking you can design a
> useful chip and ignore the world it will be working in.

The alternative is to be a sheep and follow what every one else is doing.

> Yes, we have already discussed this and it is clear that the GA144 has
> no advantage over conventional ADCs for this app.

I think we will have to agree to differ on this.

> You also haven't said how OAM might manifest itself in a measurement,

That is because I don't know yet. Sorry.
Apparently OAM is being used :
http://www.extremetech.com/extreme/120803-vortex-radio-waves-could-boost-wireless-capacity-infinitely
although I am sceptical that you can even double the bandwidth using OAM in this way, due to increased noise. We shall see...

> so you certainly can't say there is anything superior to any technique.

Not yet, clearly.

> More loony land stuff.
After all the GA144 looks like any other chip - its OK if you don't get excited about it ;-)
Its just from my eccentric perspective that the GA144 seems to be very special.
I got a similar feeling of excitement from the CDP1802 chip back in the late 70's - again something new and simple, and from seeing Forth for the first time, and colorForth etc. etc.

I usually pretend to be quite normal, except of course when there's a full moon ;-)

Best regards,
Howerd

[rickman]

On 10/19/2012 1:43 PM, Howerd wrote:
> Hi Rick,
>
> I've chopped the original text here, again because its is getting too long...
>
>> :PhD? Hardly! A PhD dissertation is supposed to be about original
>> work, not the mere implementation of a standard protocol.
> Since no one has implemented USB on a GA144 I think this counts as original.
> My point about making a good PhD thesis is that it needs a substantial amount of time, such a PhD thesis could provide.

Yes, that is the problem. What should be a simple matter of
implementing a standard protocol that runs on all sorts of processors
down to small 8 bit MCUs, is instead a major exercise on the GA144.

The more I defend this device, the less I like it!

>> "Wait, do you feel that, a disturbance in the force? It must be the GA144!"
> I would describe it more as a feeling of excitement - something new, created out of a desire for simplicity.
> The chip layout was designed using OKAD2 in colorForth.

That's totally irrelevant.

> The architecture of each F18 is a very well thought out Forth machine.

"Well thought out" is a matter of opinion. Many here will disagree with
you on that. I can think of a number of obvious functions missing from
the GA144, the most significant is likely a real, clock based memory
interface.

> The GA144 has just enough hard-coded interfaces that it can boot, and uses a power efficient, asynchronous design.
> Each F18 has a built in BIOS to allow it to communicate with all the other F18's. This has effectively extended Forth into the world of parallel computing.

That is what is missing. There is NO inter-CPU communications protocol
built in. It was only a month or so ago that Chuck came up with an
admittedly very complex scheme to pass data through nodes to get to a
destination.

> If this was just talk and speculation I would be quite interested, but I have seen OKAD2 in action, and I have two GA144's on an eval board sitting on the shelf, waiting for me to find some free time... They are real and they work :-)
> What's not to get excited about?
> But of course YMMV - whatever floats your boat...

If I were designing chips I might get excited about OKAD. But I design
boards and need chips that work and are well enough documented so that I
can do my work.

>> What is the GA144 SERDES protocol? What is the maximum rate,
>> the minimum? What is the setup and hold timing on the data? BTW, it is
>> *not* self-clocking. It has two wires,...
> It sounds like 18 bit SPI to me. The data sheet says 450MHz.
> You are right about the two wires though - I was confusing it with the 1-wire protocol which only runs at ~25MHz - only twice as fast as USB full speed.

450 MHz is what, max, min, typ? How are words delineated? They may
work, but what can they be used for?

>> No, this is the absurdity of thinking you can design a
>> useful chip and ignore the world it will be working in.
> The alternative is to be a sheep and follow what every one else is doing.

Yes, the sheep that design products that are bought and do useful stuff.

>> Yes, we have already discussed this and it is clear that the GA144 has
>> no advantage over conventional ADCs for this app.
> I think we will have to agree to differ on this.

If you could just explain anything about your ADC ideas that fits in
with either the real design of the GA144 or electronics design I would
be happy to just agree with you. But you have not answered any of my
questions about how you will be using the ADCs.

>> You also haven't said how OAM might manifest itself in a measurement,
> That is because I don't know yet. Sorry.
> Apparently OAM is being used :
> http://www.extremetech.com/extreme/120803-vortex-radio-waves-could-boost-wireless-capacity-infinitely
> although I am sceptical that you can even double the bandwidth using OAM in this way, due to increased noise. We shall see...

Yes, by people who understand OAM and also understand how ADCs work. Or
do I misunderstand and they are all using GA144s in their receivers?

>> so you certainly can't say there is anything superior to any technique.
> Not yet, clearly.
>
>> More loony land stuff.
> After all the GA144 looks like any other chip - its OK if you don't get excited about it ;-)
> Its just from my eccentric perspective that the GA144 seems to be very special.
> I got a similar feeling of excitement from the CDP1802 chip back in the late 70's - again something new and simple, and from seeing Forth for the first time, and colorForth etc. etc.
>
> I usually pretend to be quite normal, except of course when there's a full moon ;-)
>
> Best regards,
> Howerd

Excited or irrational exuberance? I was impressed with the device at
one point. Then I started to program with it and found the glaring lack
of documentation combined with the resistance of the company to fill in
the gaps. That, on top of the severe limitations of the chips. I do
see the GA144 being useful in some limited applications, but the harder
I look at it, the more limited these apps seem to be.

Rick