On Fri, 23 May 2008 06:58:43 +1000, Wayne
optusnet.com.au>

Something I forgot, is about the future of design, which is directly of
interest to anybody that uses these devices, or even pics. I would like
to see a full speed general purpose embedded serial interconnect IO bus
standard. Looking through serial memory I found something like a maximum
of 70mhz speed which is pretty useless if it was the only bus in a cutting
edge design. However, we know that they get serial lines working at
5Ghz+ for external I/O these days, which is more than enough for many
consumer embedded applications and can supply up to a 1Bip instruction
stream to a seaforth core. That is not enough for all categories, but I
think in the lab it is up past 20Ghz these days. You could also fit many
independent lines in the same space as one parallel bus. It is time the
industry moved to a large bandwidth serial i/o interconnect for embedded
devices.

While it is possible to use existing memory devices in a serial module
that handles the conversion from serial to parallel and back again and
control etc (which I have been considering) on a device like the seaforth
(with the seaforth given the ability to directly execute from the serial
bus for each border core, giving up to 18 Bips of external execution from
memory, and even every core, (even 100 cores at 36 bits, would equal
10gb/s per channel) where multiple channels and conventional memory IC
could be combined on one module for cost saving, the extra module IC to do
the conversion could cost as much as the Seaforth. The real cost savings
come from a official standard and integration into a signal IC. Please
also note, this is a good way to use common mass produced dram memory
types, caching and buffering them to look like static memory chip (as used
in some memory types already).

I wish I could have contributed to he debate on the upcoming USB3.0
standard, but that probably would have taken too much effort just to get
through the door. However, my thoughts on it might also prove useful for
a theoretical embedded I/o buss. Firstly, start simple, there is a serial
bus there, that can be bit banged, or accessed by parallel to serial
converter, speed control, and simple hand shaking etc. No structures, no
security, no data recovery, no rules, direct link. This is the level an
embedded developer might use for custom IO lines, little more advanced
than seaforth already does it. This first control mode level, also allows
people to instigate custom communication modes, security, data integrity,
networks, and devices as the developer wishes. All other control mode
levels also have this ability, to allow developer to instigate their own
versions of the features not defined in that level, as they wish, if they
wish.

The second control level can be turned on and controls data transmission
structures and methods. At this level synchronous direct and indirect
packets, streaming, token passing and slots can be used.

The third level defines networks, the comms now have routing information,
and routing search functions.

Instead of continuing on to device, data integrity and security levels, in
the two last levels there would be sub modes to handle these. A little
bit more complex, but enables these things to be optional on these modes.
The device submode defines regular devices and third party custom
versions, and new devices. The reason for this, is to enable direct
connected devices without network handling structure overhead, and not to
enforce device structure handling overhead to communicate across a custom
embedded network. It also allows standard security and data integrity
overhead to be optional at these two levels.

There is also one other basic consideration in parallel to the control
mode levels, that also effect them, what type of link is being used. For
instance: on and off chip interconnects, on board device link (high speed
cards etc) and off board local close and medium links, medium (networking)
and long distance links, and the same for wireless links. Each of these
standards can have different speeds and characteristics, but share common
data and control. This is the simple expandable version, there is a much
more advanced idea I have.

A link will only support the highest common denominator between the two
directly connected devices and this forms the lowest common denominator
for transmissions along the path to it.

Such a interface would have polling as optional (for senor reading etc),
instead using push signalling to automatically pick things up. Devices
would also be able to operate on a true plug and play level if designed
that way.

The benefits of using such a structure would be common handling
structures, requiring less complex programing than supporting separate
interfaces in parallel. Also, The developer only has to incorporate to
the hardware/mode level they require, for the devices they want, and these
devices default to that level. This automatically means they no longer
have to accommodate for every conceivable combination of possibility. It
may appear to be similar to some present situations but there are subtle
differences effecting the workload and efficiency. It is really an
attempt of an idea to simplify design. There is an additional more
advanced addition to this that would make it like the lego of the
development world.

How does that relate to the embedded industry and embedded design. Only a
simple level 1 and 2 direct link interface with some embedded devices has
to be defined, and room left for eventual expansion into the other areas
(even by separate industries in those areas). To get from one interface
type to another requires a bridge, so hardware wise things can be
customised for a particular industry, independent from what's on the other
side of the bridge in another industry sector, even local standardised
link technologies can be used for individual links, as long as the data
structures are supported. For instance, a usb bus with standardised USB
1, 2 or 3 devices could be on the other side of the bridge, and be
regarded as a level 3 network with the bridge supporting device/data
structure translation across itself between USB and the embedded
interconnect link's standard. (USB3.0 could be the de-facto standard, or
the embedded network even be regarded like an extension to USB
(Embedded). Put another way, the devices could be regarded as custom
devices, and the bridge could be an intellasys device based on seaforth
cores (bridges can also be any device, like the main processor for
example, that reads in one type of port and outputs in another type of
port). Seaforth technology is probably well positioned to perform this
sort of work, and such a standard would also need lots of bridge chips.
Such a standard, really requires a major sponsor, or group support to get
compatible devices (however, as with USB externally, an existing link
standard could be adopted to perform the task, but it still would need to
be expand to support things like hi speed serial modules).

Anyway that is the rough of it, up late again, very tired, so I could have
written it better from memory. I have additional ideas to further
simplify the design process and circuit board design, to almost plug and
play levels. Eventually, optics could simplify this further.

I hope people can appreciate this, it is sort of like trying to get back
to simpler days.