12.0 beta release - xTIMEcomposer Studio & xSOFTip Explorer

All the latest news and announcements from XCore and XMOS.
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Re: 12.0 beta release - xTIMEcomposer Studio & xSOFTip Explo

Postby dan » Sun Oct 21, 2012 8:08 pm

The use of the term 'IP' in xSOFTip is intended in the same context one finds it used here:

http://opencores.org/

e.g.

" What is OpenCores? - the #1 community within open source hardware IP-cores"
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sun Oct 21, 2012 9:17 pm

I agree their terminology use is also unfortunate and their position often controversial in various opensource communities. If it is their terminology that has inspired Xmos's recent movement I feel we are in for a difficult and controversial ride in the near future. Their use of the term 'Core' for example if adopted by Xmos is likely to make things even more confusing than just the thread/tile/core changes we have just experienced (I apologise for using the T word). If Xmos does follow Opencores use of the term 'Core' each module in github then becomes a 'Core'! Clearly Opencores has been heavily influenced over the years by what I might term FPGA/ASIC speak as that is clearly their target audience. However (and despite Xmos's interest in the FPGA market) I think applying FPGA/ASIC terminology to Xmos microcontrollers in preference to more familiar microcontroller/microprocessor code terminology is more likely to confuse than inform.

I really think its time for Xmos to stop borrowing from such incumbents and to really strike out for new ground. For many I think are likely see Xmos as the obvious extension of microprocessors and microcontrollers upwards with more powerful code rather than downward from re-configurable logic. Too most engineers, programming on Xmos is more like being able to extend microprocessor code to a universal soft peripheral model, rather than designing via a hardware description language complimented by a soft or hard processor. In other words Xmos has much more in common with microprocessors and microcontrollers than FPGA and ASICs, thus if Xmos must borrow terms, the former rather than the latter makes much more sense as a source.

I would also stress that just because Opencores use the term ambiguously, it still remains an inadvertent oxymoron and certainly doesn't justify Xmos's use of the term,

Again I would be interested in other's perspectives on this.

regards
Al
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Postby Heater » Sun Oct 21, 2012 9:35 pm

Folknology,

This term "core" is a slippery one. In the wolrd of of chip design, FPGAs, etc a core just seems to be some logical function or "ip block" not necessarily a processor core. Most of the cores on opencores.org are not processors at all.

Then again in the processor world a core seems to mean a CPU. As in the multicore Intel or other microprocessors. Seems to be related to the idea of multiple ip cores being stamped out on a single chip.

Either way for XMOS to use the term "core" to refer to a thread is just all wrong.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sun Oct 21, 2012 11:36 pm

Ok time for something more personal on this subject:

I suggest that the influences on Xmos by FPGA/ASIC markets and terminolgy has become detrimental to the point of creating obstacles for new engineers and users. I think such influences are having a negative impact on the adoption of Xmos technology by it's largest market opportunity, i.e. the market place current occupied by Microcontrollers. I also beleive that it's Xmos's simplicity rather than complexity that represents its greatest strategic advantage in the microcontroller market place, becuase of the over complexity and diversity that currently exists there. What is more this fragmentation acts as barrier to entry for many engineers, learning new peripheral sets is time consuming and expensive, even though ARM has unified many cores, peripherals remain complex and diverse. Perhaps a story and some experiences from myself and others may serve as an explanation of my conjecture.

If we could wind the clock back to before microcontrollers became popular we would see heavy use of microprocessors combined with external hardware perpherials often mapped into the address space. Thus when Microcontrollers emerged to reduce BOM and cost these peripherals were simply merged into the silicon and their address based register orientation became ingrained in the microcontroller design rule book, not exactly innovative. As such modern day microcontrollers are very similar to their earlier counterparts except they have more peripherals integrated into denser silicon running at higher clock rates. There has to date been little innovation in the technology and operation although in terms of design cycles, ARM licensed IP has changed the supply chain model a modicum. Much of this early direction of course is down to the success of the early microcontrollers from vendors such as Intel, these in turn became defacto standards for the way to build microcontrollers.

However lets just imagine for a minute that a different evolution of the microcontroller took place in an alternate universe (humour me for a second). In this alternate universe an innovator (lets call them X) saw the issues of Microprocessor and perpiheral BOM explosion and thought a little differently about a solution. You see X had a vision of sigificantly reducing processor complexity and increasing its performance, their vision was to create a small set of basic instructions that included IO and communication primitives inside a significantly reduced instruction set. This meant that they could clock faster and by fit more cores onto a given slice of silicon. Thus when they introduced their innovative products to the nascient microcontroller market place it became a huge hit. As performance was increased the need for less and less hardware peripherals became the winning trend, because the instruction sets were universal, engineers found it easier to solve more and more demanding projects with shared software rather than new hardware peripherals. The market leaders focused on concurrency and performance rather than peripherals development, as such complex peripheral integration had little chance to evolve because collaborative software ecosystems proved more cost effective and agile than their hardware counterparts. Of course in this universe the ARM we know also didn't emerge because they didn't nhave the same opportunity, instead ARMOS (X) became the most successful Microcontroller IP vendor of all time, dwarfing their biggest rival Intel a few years later when they took the on the consumer market combined with the exploding opensource commons.

Ok thats just a story but I hope that you can see the point I am making, just to drive it home a bit further I will relate it to some experiences I and my colleagues have had with microcontrollers. One thing I see very often amongst microcontroller dev is folk implementing I2C using code and just IO pins, I also see similar things for SPI and occasionally Uarts to name some common examples. This maybe surprising behaviour for many higher end folk in FPGA or even dare I say Xmos land, but it is common practice because often the microcontrollers in questions either don't have the built in peripherals or they just aren't available because they are in use for something else (in some cases it can also be conflicting I2C addresses). Thus we fall back on bitbanging these protocols, I have also seen more universal libraries that run on different microcontrollers using this same techniques, the benefit being portability of course by avoiding coding in proprietary peripherals. But this is really the just tip of the iceberg for solving demanding peripheral problems outside of the built in hardware of a microcontroller. For instance there are DMA techniques used on higher pin count microcontrollers that allow one to construct sequences and state tables that when combined with interrupts, timers and DMA enabled GIO pins, which allow complex switching of address pins to drive fast peripherals or even motor drivers with little impact on the cycles of supervisory code running on the processor. So in these cases do we frame such techniques as SOFTI2C or SOFTSPI IP? No of course not, for us its just software and techniques, it doesn't need the framing because we all know our job is about code and algorithms not IP blocks or cores, we just don't think that way! Thus to us coders, Xmos XS1 is just those same techniques lived large, fast and coherent, it's the same thing but on a more optimised platform, natively designed for those sorts of techniques with a nice event metaphor to play by. It is of course what we always wanted instead of what we got, it is in fact the fabled ARMOS, the universal microcontroller family we always wanted but couldn't get!

So to me (and other microcontroller devs like me) this is What Xmos should be shouting about. Not confusing the b'jesus out of us poor lowly Microcontroller folk with your FPGA terminology. Please just keep it simple, stay on message and use terms that we understand, just maybe then we would really be impressed.

regards
Al
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Postby Heater » Mon Oct 22, 2012 10:02 am

Folknology,

Yes. In a, rather large, nutshell yes.

I always thought that part of the point of xcore was to encroach on application areas that were traditionally tackeled by FPGA's. Places where:
1) You need the custom logic not available on MCU's that FPGA's offer.
2) You need the speed that software alone cannot provide but a custom hardware design can.
3) You would benifit from the simplicity of using familiar software techniques and languages for both your low level, high speed logic and the rest of your application.
4) You avoid having to make things expensive and complex with a 2 chip (microprocessor and FPGA) solution.

Point 3) is the point of contention here, simplicity. By framing the xcore devices in language pertaining to FPGA, VHDL designers you are advertising the device to be apparently as complex as hardware solutions not the simplicity of the software solutions on offer.

You are hiding a valuable unique selling point.
User avatar
ahenshaw
Experienced Member
Posts: 96
Joined: Mon Mar 22, 2010 8:55 pm

Postby ahenshaw » Mon Oct 22, 2012 4:29 pm

Personally, I don't have any problem with XMOS referring to *their* threads as "logical cores". XMOS does have a unique hardware implementation that provides their threads with guaranteed performance.

When I push XMOS processors for use in projects, I am very careful to explain the differences and advantages of an XMOS thread over the normal understanding of what a thread usually means. I think that the "logical core" terminology will help me get that point across.

That being said, XMOS needs to be very careful in consistently using the term "logical core". Just using the word "core" by itself would be misleading.
SpacedCowboy
Experienced Member
Posts: 67
Joined: Fri Aug 24, 2012 9:37 pm

Postby SpacedCowboy » Tue Oct 23, 2012 1:53 am

@Folknology

Not to disagree with anything you're saying (because I don't), especially since I'm new to XMOS, but I'm actually coming at it from the other end - to me, using an XMOS chip seems like a great alternative to an FPGA. I'm hoping it'll lower the barriers in terms of debugging for starters - here's the first board I'm thinking of using an XMOS on (caution: lots to do yet, early design stages :) )

Image


I think the G4 will work well as glue between a lot of disparate protocols (USB fifo, video, DMA of J2K data, SDA/SCL) as well as providing a nexus of control over the entire system. This is typically what I'd have a CPLD (or in this case an FPGA since it'll use a chunk of RAM) doing, but I think it'll be easier to design/debug the system in (X)C rather than rewriting verilog code with clock-crossing etc.

For me, microcontrollers are now pretty powerful and you can do a lot with them, but the event-driven interface is something unique, the high i/o count is another big draw, and the minimal support BOM that the chip needs is also attractive.

If I had a wish to improve the chips, I'd want more RAM. As it stands, though, I'm planning on diving on in and seeing what I can do with it. I *think* it'll work out well. We'll see :)

Simon
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Tue Oct 23, 2012 1:21 pm

Hi Simon that's a sophisticated looking project!

I don't think you are alone, initially Xmos targeted FPGA users with their devices so I would imagine there are many folk like yourself. However many FPGA folk have been through the school of HDL hard knocks and now get paid very attractively by being able to practice those multi disciplinary skill sets, as such they often choose FPGA designs over perhaps simpler but new alternatives.

More importantly to this thread however, is the more recent marketing moves from Xmos indicating a change of focus on that much larger microcontroller market place opportunity. They now even label their products microcontrollers (which wasn't the case before), so clearly their new positioning is more sharply focused on those larger volume opportunities, which is exactly why I have made my comments and conjectures above. I think its time for them to shed those older notions and labels that make sense to the FPGA/ASIC market in favour of more simplistic and clean terms that ring bells in the microcontroller space.


P.S. You should write something in the projects section of the forum about what you are working on, I am sure their will be others interested in your project also.

regards
Al

Who is online

Users browsing this forum: No registered users and 1 guest