Fast embedded architectures.

The link was not a link to a datasheet!

I went there, hoping for it link to a datasheet, but instead found a "Ubicom Diversity Forum Index", inviting me to login. If someone would like to provide a link to a datasheet, I'd gladly download it.

The effort involved in trying to create a login, read the terms and conditions etc. is not worth the hope that a datasheet might be found somewhere inside.

Give us a working link to a datasheet please! (seriously) (and only then complain about people not reading it!)

--
Adrian

I am and remain a a huge long-term fan of the Scenix/Ubicom SX chips. A

75mhz 75 MIPS pic clone with a tolerable multi-input-wakupe system and about nothing else. Not even a UART. But they are very very fast, and $4 a pop.

The UP2xxx and UP3xxx lines are interesting, but they're definately out of my hobbyist league. There's just not an established integrated base to build upon. While they do have some neat hardware on them, i'm much more interested in something like Freescale's (Motorola's spun-off silicon guys) ColdFire processors, simply because it provides so much stuff for me:

From what I've read, these are rather amazing chpis. A modernized and risc'ified a 68k with a ton of embedded features. Onbaord features out the door: DDR ram, crypto-accelerators, pci, dual 100bt ethernet, usb2.0, couple uarts, 16-channel dma, fpu and /w accumulator. All with relatively low power consumption.

Ultimately a context switching core is quite alluring and likely the way of the future, but until there's one available which provides a general level of integration on par with its level of technology, I'm going to have to pass.

Myren

I know and I am sorry. It was a major event for it to be available at all. The lead architect (Nick Kelsey) for both the ip2k and ip3k left Ubicom and is doing a startup somehow still involved with those processors. He founded this first public bbs to encourage wider use. He got permission to post the datasheets, but Ubicom required him to only give it to registered users.

So for some it may not be worth the hassle. For others, you can register and get to the datasheets. I do find the company's marketing strategy perplexing.

Regards, Steve

This sounds like a useful chip. Is there anything architecturally interesting, or is it just lots of useful features integrated with early 1980s cpu design?

The SX chips were just fast PICs.

The IP2k is in another league. In fact that is a problem for Ubicom. H/W guys were quite able to program the SX in assembly to solve many problems just like with PICs. The IP2k uses a GNU toolchain which many find difficult to learn or completely alien (what is this C stuff anyway?). And people used to doing C++ programming on PCs cant relate to the limited memory, limited OS, and the occasional need to do an ISR in assembly language. But if you have done C programming in an embedded system it is just great.

The IP2k is a system on a chip. It has flash, ram and I/O (including ethernet and USB serdes interfaces). It uses a 4.8Mhz external crystal and internally has a 50x pll to get to the 120Mhz) It can bitbang multiple highspeed serial interfaces simultaneously. The IP2k still has the weird Harvard design, which gives the GNU tools fits; such as how to deal with the fact that 2 or 3 different memories have different widths and the same address? The IP2k does approach the capability long talked about where "if only I had more speed" I would not need that external hardware.

The IP3k is harder to characterize. In some ways it is like having 8 IP2ks on a chip. It runs at 250Mhz instead of 120Mhz for the ip2k. It is less a system on a chip than the ip2k because it has no flash and therefore requires external permanent storage. It is supposed to be able to run 4 100baseT channels without external MACs, just MII phys. It was designed to be a high speed bridge between multiple high speed networks.

I can't decide if they made good tradeoffs on the ip3k. Is it better than an ARM and several I/O cores integrated together? At least there is no tooling charge for the IP3k system.

Regards, Steve

The ColdFire core design has quite an interesting history (assuming I understand it correctly, of course). Basically, they took the old 68k programming model (from around the 68020 generation), took out some of the most obscure addressing modes and a few other odd instructions, and designed a new core from scratch that implemented that model. The 68k programming model was already fairly "riscy" (16 full-size registers, mostly orthogonal instruction set, etc.), although there are a number of "ciscy" features (data and address registers are distinct, specific stack register, variable instruction lengths). The new core was made using modern risc-type design, which they called "variable length risc architecture". The result is a core that executes the well-known (and, dare I say, well-loved?) 68k programming model in a low-power core at close to one instruction per cycle. Following that, there have been 4 generations of ColdFire core, adding superscaler operation, MMU, floating point, etc., according to need. The cores are combined with a range of peripherals to give a wide variety of microcontrollers for different targets. So they are certainly useful chips with useful features - whether or not they are architectually interesting is a matter of opinion, of course.

David

They're legacy products on the way out the door. I wouldn't advise them for a new design at this point in time. Moto^H^H^H^HFreescale's

32-bit and higher future is in PowerPC and ARM.

That'd be why they've just released a 600MHz version with a neat pipelined MAC unit for DSP work?

I get the impression from Moto^WFreescale's processor lineup (huge!) that they think that everything is legacy, it's all synthesizable, so they'll just keep making whatever the clients want. These guys support FOUR DIFFERENT 32-bit MPU architectures (ColdFire, PowerPC, ARM, MCore), let alone all of the zillions of within-architecture model variations, and let alone the three families of DSP and uncountable hoards of 8 and 16-bit micros.

Kind of makes sense: in the embedded chip world, integrated peripherals count for a lot, and aren't architecture dependent. RAM is RAM, ROM is ROM. Cache probably has variations, but there's probably a lot of similarity there. What else is an ISA, then, other than something to hang your "legacy" code on?

--
Andrew

I love your analysis on the IPxks. They really point out what these chips are all about.

Unfortunately, the marketting is fscked. The design is fscked. "If i only had more speed" IS NOT the solution to modern integrated processors. Even when its true. Devel costs are just too freaking high.

I've spent way way WAY too long building a bit banged async rs-485 light dimmer / sensor network off the scenix SX chips to think bit banged uarts are even remotely permissible on a system ever again.

There's really no reason not to have UARTS on a system. the design costs cant be THAT much. Bit banging async serial is pain enough, i dont want to begin to have ot imagine doing the same thing for ethernet. 4 mb addressable space, what sort of restriction is that? i dont want to build my own banking system too!

The IP3k especially seems like its competing more with FPGA's than it is your conventional control-oriented embedded processor (the 8threaded

0-cost context swtich should be the first give-away something is funny). I'm really really worried though that development would be rediculously difficult, what with such a multi-threaded design. Having to do EVERYTHING in software. There's way too much too develop, not enough hardware helping out, and way too many concurrency issues to mess the whole thing up. The tools had better blow away everything i've seen before, but i kind of doubt that they're be up to the challenge. I'd want to be able to step through one thread while hte processor was active.

Before anyone goes around taking these harsh words too seriously, I really dont have any idea what programming these things is like. I'd be very interested. The devel kit comes with a lot of code, I know that. I assume you have to use the OS they give you/you purchase to use that code. That sounds like some frightening lock in, but I guess if your making a solution your only goal is to ship it. I'd be really interested to here peoples experience actually using these.

-Myren

Where do you get the idea that these are legacy products? Do you consider Opterons legacy, since they are based on the ancient x86 programming model? There are new ColdFire microcontrollers coming out on a regular basis - new, faster cores at the high end, and more integrated, cheaper and lower-power chips at the low end. New peripherals are added to the range - they have just come out with the "eTPU", which is a dedicated microcoded RISC processor for controlling 16 timer channels. The new version has a lot more power that the old one (and even has a C compiler available!).

Freescale's ARM line is mainly aimed for very low power devices - arguably their own low-power core, the M-Core, is on the way out. And there are plenty of uses for their PPC lines - the ColdFires are complimentary to the PPCs, not competitive.

It would be technically straightforward to use those to build some very impressive blades, and make a big impact on that market. Yes, it would involve a certain amount of work, but there were some decent 68K compilers that could be updated etc. etc.

Politically, on the other hand, ....

Regards, Nick Maclaren.

I'm not sure how much SMP support exists on the high-end ColdFires, and they might have external address ranges of less that the full 4 GB (that's certainly the case for the smaller Coldfires, with which I am somewhat familiar). However, the fact that they have fast networking, DDR controllers, a flexible bus (attaching gluelessly to flash, for example), PCI, USB2, etc., and a power consumption of a few watts at most would let you put a lot of MIPs in a small space, for applications that can be split across loosly-coupled processors.

One of the biggest areas for ColdFires is in network devices (firewalls, routers, etc.), where they provide a lot of bang for the buck. I'm using a small ColdFire on a card I'm working on at the moment, partly because it is cheaper than a stand-alone 100 MBit ethernet controller.

In article , David writes: |> > |> > It would be technically straightforward to use those to build some |> > very impressive blades, and make a big impact on that market. Yes, |> > it would involve a certain amount of work, but there were some |> > decent 68K compilers that could be updated etc. etc. |> |> I'm not sure how much SMP support exists on the high-end ColdFires, and |> they might have external address ranges of less that the full 4 GB (that's |> certainly the case for the smaller Coldfires, with which I am somewhat |> familiar). However, the fact that they have fast networking, DDR |> controllers, a flexible bus (attaching gluelessly to flash, for example), |> PCI, USB2, etc., and a power consumption of a few watts at most would let |> you put a lot of MIPs in a small space, for applications that can be split |> across loosly-coupled processors.

They probably do only support 4 GB addressing, but don't assume that large addressing, cache coherence, SMP and close coupling are all part and parcel of the same thing. They aren't.

As history relates (for those few people who remember it), there have been some very successful Unix systems with limited addressing per process and no cache coherence, but shared memory and close coupling. Yes, you have to place a few restrictions on how such systems are used, but they affect very few programs and even fewer of those at all seriously.

For example, running a single system image on a complete row of blades would be straightforward. mmap/shmem/etc. would have to be restricted a little, and they wouldn't support OpenMP or the use of POSIX threads for parallelism (a rare use of them) but that is about all. There would be little problem in migrating processes or even kernel threads between blades (very good for dynamic replacement).

However, I am not holding my breath for such systems ....

Regards, Nick Maclaren.

My experience too, ubicom is simply pushing the problems elsewhere, and that elsewhere (concurrency issues) is a nasty place. I think Motorola's embedded PowerPC family integrated with multiple TPUs is a better solution. I want more parallel hardware support, not less.

You are right about the marketing and product "stragedy", I like the ip2k design. I don't understand that last part.

My experience with the ip2k is that the SDK/os keeps development time in line with other significant embedded development. This means you can do a web server (for configuration and interface), custom I/O software (some in assembly) as easily as other solutions, maybe quicker. You just cannot compare development with a PIC/SX and with the C programmable, fast! ip2k (and maybe the ip3k, I don't know).

My experience is that most problems are from resource limitations. This means if you have enough memory and speed, doing bitbang implementations are not such agony. It is only when you are really close to the max capability of the chip does the development time go asymptotic with respect to completion.

The way I think they use multithreading is not like done in Linux. You do not try to run SMP. You allocate a thread to a specific I/O device and minimize the inter-thread communication. Done this way you don't even need an interrupt routine, one thread just watches for a I/O event and handles it. So to run a 100base_t interface, one thread handles all I/O and is fed data buffers from the main application (which I think is run in only one thread). The only concurrency issue is the communications between threads. Supposedly read-modify-write instructions are atomic for easy semaphores etc.

Like I said this is no PIC.

I have not used the ip3k tools. The ip2k gdb is pretty marginal but generally you can find work arounds to such things as single stepping with a heavy interrupt load. Supposedly the ip3k had the thread aware version of gdb.

The eTPU is an amazing device. It is a dual processor thread machine each controlling 32 timer channels. These are processors with serious I/O bandwidth.

w..

ColdFire is indeed complementary to PPC, but it is _competitive_ against ARM. Motorola is going to go the way of others and abandon their proprietary 16/32-bit cores. I can predict this quite confidently. The huge mass-market applications - phones, PDAs, etc - have gone ARM.

It's relatively easy for a silicon company to swap cores, it's the peripherals that have more importance in many cases. The 7100 ARM series from Freescale looked like a simple core swap. Would not be surprised to see an eTPU in ARM models.....

What will be more interesting, is the migration from ARM7 to Cortex cores. On that basis, ARM7 is already in the 'legacy basket'....

-jg

Ahh, but you do not need these for blades...

Like blades ;-)

--
	Sander

+++ Out of cheese error +++

Sounds interesting; I'll look in to that.

devices and memories (at

In the case of PXA25x, it has a reasonablly good core but the IO bus and on-chip peripherals let it down badly.