I've done some googling on intellasys discussions here (but really can't   devote much time to that because of sickness, pity there isn't summaries   in newsgroups or threads).  I've seen discussions where people suggest   that Intellasys are after Arm like contracts.  But what is the real target? The Arm field is populated by ready made solutions with reference designs,   and software to run on them.  If we look at it on multiple levels, the   present chip doesn't seem to be targeted at the same market.  Arm chips   offer a conventional wide address space and programming for large pre-made   code _base_.  The Arm also offers a heap of specialist integrated data   processing models for various forms of data.  Still again, the Arm also   offers heaps of I/O features off integrated chips.  My designs will often   require a number of Intellasys chips compared to Arm chips (which requires   pin-count, extra handling and board placement).  On the programming side,   simply put, the majority of programmers can get down with Arms by simply   loading in linux and other software, and can run most applications because   of the fat conventional environment.  Reference designs can be had with   hardware, and I am sure software.  Not getting into the fabless bit that   has allowed manufacturers far and wide to offer individual solutions.   This is what you need with Intellasys to get those big orders alongside   arm.  Not one core seems to offer a fat internal or external direct   execution and data space. Two examples of this commodity culture: In the PC 3D graphics card market, manufactures now often follow the   reference design, and use the 3D manufacturers software and driver code,   than spend the money designing their own. In an article on the Chinese clone market in Popular Science last year,   the writer talked about how Chinese engineers were making mobile phones.   The engineers would be contracted in and construct the similar looking   phone in weeks (I think that the actual cloning of a circuit would take   longer).  From what I could tell, from memory, they brought their toolkit   with them, obviously arm hardware reference, Linux and apps software   data_base_, and designed them together.  Normally, without these items, that   would take many man years to do, and in truth the code and reference   platforms they are re-using might represent hundreds of man years of   development.  This is the reality of the modern day market. The Intellasys chip doesn't seem to have a high end of dsp ability to   compete with high end specialist data processing.  I can name a number of   chips that now do this, even with hundreds of processors.  One used in   those $99 high definition cameras is the cheap ambarella camera control   chip (a large series of MIPS or SPARC processors and custom elements). Things it can do: As a simple micro-controller, just one of the cores on the present chip   (coupled with a larger addressing space) could control a washing machine   or watch, etc.  It is really close to the vision of somebody who was a   co-founder of either Microsoft or Apple, that I read about years ago, who   had a vision of simple processors in everything, including light bulbs. As a FPGA alternative.  I agree with this suggestion I've heard elsewhere. Simple, low powered and low cost data processing core. These are substantially separate markets from the traditional Arms chip,   and a ready made software _base_ is less important.  The Arm continues to   move down into these markets though.  By the time Arm can match this   practicality at the lowest level, just breathing on a Intellasys chip   might be enough to power it . However, if Intellasys does want to take on Arm more directly, maybe Chuck   can figure out some neat misc like processing solution alternatives to the   different precessing models used in Arm chip sets.  The other things   mentioned above could also be addressed.  One thing I wish was that there   would be large directly executed internal or external address and data   spaces for at least one core and non-bit banging serial to parallel word   support for serial comms (and serial memory support).  Along with this   would come test and continue in addition to test and sleep on the i/o so   you can chew through data in the large address space.  As a simple   interrupt (minimal you could say) would be a interrupt address associated   with a comms port, so that completed data would result in halting of   execution and continuation from the new address until return (which would   infer extra address and data stack space).  One, a few, or for a really   aggressive chip all cores, could support this. Another area would be auto routing comms, set destination core and pass   information while intervening cores carry on doing other things. The other advantage of the Intellasys approach is that the use of general   purpose DAC/ADC pins allows a suitably setup chip to do all the I/O   functions of an Arm integrated chip.  I would suggest though, it would be   cool if each external serial pin could also act as a high speed DAC and   ADC pins.  This would give a lot of flexibility.  Just this sort of   feature could put it above many other chips in versatility and usefulness,   especially if it could support faster frequencies. These additions may add a some complexity to the design, but add heaps to   the functionality, usefulness and power of the chip. I am interested in preferring the Intellasys because of my past   association with Misc and Forth, and it's stack _base_d efficiency.  If Arm   was a cute forth processor I would probably prefer it. Well, sorry for any mistakes I made, 6.57AM and haven't slept. Wayne.

On Fri, 23 May 2008 06:58:43 +1000, Wayne   < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it 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 _embed_ded 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 _embed_ded 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 _embed_ded   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 _embed_ded 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   _embed_ded 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   _embed_ded 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 _link_s, medium (networking)   and long distance _link_s, and the same for wireless _link_s.  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 _embed_ded industry and _embed_ded design.  Only a   simple level 1 and 2 direct _link_ interface with some _embed_ded 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 _link_s, 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 _embed_ded   interconnect _link_'s standard.  (USB3.0 could be the de-facto standard, or   the _embed_ded network even be regarded like an extension to USB   (_embed_ded).  Put another way, the devices could be regarded as custom   devices, and the bridge could be an intellasys device _base_d 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.