FBP in hardware

[Graham Chiu]

I note that GreenArrays has released their GA144 chip which has 144 forth computers on a single $20 chip.
Sounds like hardware waiting for FBP.

http://www.greenarraychips.com/home/products/

--
Graham Chiu

[Ged Byrne]

There's a great interview with Chuck Moore on the "Lost Art of Keeping
It Simple."

Moore is the GreenArray's CTO and the creator of Forth.

CM: code can be beautiful. But it rarely is.
Beauty lies in showing off the structure
of a program, without distracting details.
Factoring into subroutines or threads is
essential for this. A wall of straight-line
code is ugly. As is code loaded with
comments or conditions.

Pretty code can result from clever instantiation
of objects. This is supposed to suppress details.
Also from the careful choice of names so that
their purpose is clear.

RM: Is there an upper limit on how big a piece of software
can be and still be beautiful?

CM: I think so. A painting may be beautiful, but not a gallery
full of paintings. Beauty can be overwhelming.

http://www.simple-talk.com/opinion/geek-of-the-week/chuck-moore-on-the-lost-art-of-keeping-it-simple/

Showing of the structure of the program instead of just a wall of
text. Isn't that's what FBP's all about?

Regards,


Ged

[Tom Young]

On Tue, Feb 7, 2012 at 4:46 AM, Graham Chiu <compk...@gmail.com> wrote:

I note that GreenArrays has released their GA144 chip which has 144 forth computers on a single $20 chip.
Sounds like hardware waiting for FBP.

 

It is using FBP:
http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
actually contains a figure labeled "MD5 Data Flow Diagram". 

      -twy

http://www.greenarraychips.com/home/products/

--
Graham Chiu

--
"...the shell syntax required to initiate a coprocess and connect its input and output to other processes is quite contorted..."
W. Richard Stevens [Advanced Programming in the Unix Environment, p441]

[Raoul Duke]

On Tue, Feb 7, 2012 at 8:38 AM, Tom Young <f...@twyoung.com> wrote:
> It is using FBP:
> http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
> actually contains a figure labeled "MD5 Data Flow Diagram".

did (not) data flow exist in the EE world before fbp in the CS world?

[Tom Young]

I believe it did, but was mostly limited to intra-node dataflow.   This diagram shows inter-node dataflow and more closely resembles FBP. 

--
Tom Young
47 MITCHELL ST.
STAMFORD, CT  06902

"When bad men combine, the good must associate; ..." 
   -Edmund Burke 'Thoughts on the cause of the present discontents' , 1770

This e-mail message from Tom Young is intended
only for the individual or entity to which it is addressed. This e-mail
may contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended recipient,
you are hereby notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you received this
e-mail by accident, please notify the sender immediately and destroy
this e-mail and all copies of it.

[Ged Byrne]

Forth isn't flow based programming, but it does share a lot of the
concepts.

Consider the following from the excellent book Thinking in Forth:

What have we done? We've inserted a new stage in the development
process: We decomposed by components in our design, then we
described the
sequence, hierarchy, and input-process-output in our implementation.
Yes, it's
an extra step, but we now have an extra dimension for
decomposition not
just slicing but dicing.

Suppose that, after the program is written, we need to change the
record
structure. In the sequential, hierarchical design, this change would
a ect all
three modules. In the design by components, the change would be
con ned to
the record-structure component. No code that uses this component
needs to
know of the change.

http://freefr.dl.sourceforge.net/project/thinking-forth/reprint/rel-1.0/thinking-forth-color.pdf

Forth is the one technology that doesn't get mentioned in the FBP
book. I think there's a lot of common thinking even if the executions
are quite different.

SeaForth has developed this further:

a processor with nothing else to do sleeps until it gets a message
from another task
on another processor. When the message is exchanged the two parallel
components
synchronize. In the SEAforth implementation processors sleep waiting
for program or
data messages to arrive and when sleeping consume very little power.
When a
message arrives they awaken from sleep to do the appropriate thing and
components
synchronize. Sending or receiving a message simply requires writing
or reading
a port address.

www.ultratechnology.com/CSP-Data-Flow_Diagrams.doc

Regards,


Ged

[Paul Morrison]

Could we do something with these processors similar to what I described
in the second edition of my book under the heading Gedankenexperiment:

"Each microprocessor would basically be running a single code loop which
takes packets off one or more (fixed capacity) input queues in the
microprocessor�s memory, does some processing, and writes zero or more
packets out onto the outgoing wires. When a packet arrives on a
microprocessor�s input wire, it triggers an interrupt, and the interrupt
code [logic] stores the packet on the corresponding input queue. Such a
network, we believed, would support the implementation of a wide variety
of FBP applications � plus it offers the possibility of having special
purpose hardware components to perform common data transforms such as
merges, selects, etc., and of being able to smoothly integrate hardware
and software devices.

"Now, since it would be impractical to have to specify an application by
plugging and unplugging wires, you would need some programmable way of
selecting components, and specifying how their inputs and outputs are
connected. This would seem to suggest something like FPGAs
(Field-Programmable Gate Arrays) � ... or maybe we could bring back the
old plugboards!"

[Tom Young]

On Tue, Feb 7, 2012 at 10:02 PM, Paul Morrison <paul.m...@rogers.com> wrote:

Could we do something with these processors similar to what I described in the second edition of my book under the heading Gedankenexperiment:

"Each microprocessor would basically be running a single code loop which takes packets off one or more (fixed capacity) input queues in the microprocessor’s memory, does some processing, and writes zero or more packets out onto the outgoing wires. When a packet arrives on a microprocessor’s input wire, it triggers an interrupt, and the interrupt code [logic] stores the packet on the corresponding input queue. Such a network, we believed, would support the implementation of a wide variety of FBP applications – plus it offers the possibility of having special purpose hardware components to perform common data transforms such as merges, selects, etc., and of being able to smoothly integrate hardware and software device

 

It seems that the GreenArrays chips are designed to follow this pattern, but each processor node,  is limited to a very small amount of program and data memory.   A lookup table with 64 32bit words, for instance, consumes two nodes almost entirely.   The MD5 prgram uses at least thirteen nodes.  

"Now, since it would be impractical to have to specify an application by plugging and unplugging wires, you would need some programmable way of selecting components, and specifying how their inputs and outputs are connected. This would seem to suggest something like FPGAs (Field-Programmable Gate Arrays) – ... or maybe we could bring back the old plugboards!"

The nodes appear to be organized into 2D arrays (as implied by the GreenArrays name) and  communicate with nearby nodes in the same row or column as directed by the Forth program. 

"Virtual Plugboards" , ole!

       -Tom

[ern0]

Just a few words from a junior embedded programmer (me): It's a common
practice in embedded system design to use more, relativelly weak
microprocessors in a system instead of one stronger.

Say, we (Intep Kft, Budapest, Hungary - http://intep.hu/ ) have an
access point (I don't know the official name): you put the proximity
card near to the device, it reads the ID, you press a key on the keypad
(work start, work end, launch, holiday etc.), it beeps and opens a door
with the relay. This device contains an Atmel SAM9x as the master (it
has dataflash with the list of card IDs, receives commands from the
desktop client on RS485 etc.), and 2 or 3 AVRs, one handles the LCD
display, one receives the proximity ID (it must be calculated from a
digitalized waveform).

The processors are connected with serial, usually SPI or TWI, sometimes
RS485.

OK, the architecture is not dataflow, just similar. Watching the
analogue waves arrives from proximity card requires not too much
processing power, but it must be run non-stop, so it's more simple and
stable to implement as a separate AVR subsystem than a task.
--
ern0
dataflow evangelist