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

Groups > comp.lang.forth > #16030

Re: GA144 polyForth

Show all headers | View raw

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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-09-27 14:16 -0700
  Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-29 01:20 -0700
    Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 11:05 -0400
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 09:06 -0700
        Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-09-30 14:29 -0400
          Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 19:56 -0700
    Re: GA144 polyForth Coos Haak <chforth@hccnet.nl> - 2012-09-30 21:54 +0200
    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:18 -0700
      Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-01 23:40 -0700
        Re: GA144 polyForth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-01 21:23 -1000
          Re: GA144 polyForth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:19 +0000
        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 23:04 -0700
  Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-01 10:28 -0500
    Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-01 11:19 -0700
      Re: GA144 polyForth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-03 10:46 -0500
        Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-04 13:46 -0700
  Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-05 22:10 -0700
    Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-05 23:17 -0700
      Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 05:47 -0700
        Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-07 19:31 -0400
          Re: GA144 polyForth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 20:10 +0200
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-08 16:36 -0400
          Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-08 13:31 -0700
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 13:48 -0400
              Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-09 13:21 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-09 17:08 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 07:39 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 14:28 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 13:37 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 16:54 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-13 14:14 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-13 17:30 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-14 02:00 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-14 19:54 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-15 11:03 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-15 16:38 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 04:12 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-16 15:46 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-16 23:05 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-17 13:40 -0400
                Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-17 22:54 -0700
            Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 14:53 -0400
              Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:06 -0400
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-18 15:09 -0400
              Re: GA144 polyForth Howerd <howerdo@yahoo.co.uk> - 2012-10-19 10:43 -0700
                Re: GA144 polyForth rickman <gnuarm@gmail.com> - 2012-10-19 17:43 -0400
  Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 11:29 +0300
    Re: GA144 polyForth mhx@iae.nl (Marcel Hendrix) - 2012-10-06 11:14 +0200
      Re: GA144 polyForth Mikael Nordman <oh2aun@invalid.com> - 2012-10-06 16:08 +0300
    Re: GA144 polyForth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 10:57 -0700

csiph-web