The Hot Chips Symposium at Stanford’s University has barely kicked off and already we have a major bombshell from Tilera, namely their TILE64 multi-core processor.  We are not talking four or eight cores here but a whopping 64 full-featured identical cores, each with an integrated L1 and L2 cache, a distributed L3 cache, and an integrated non-blocking switch which is utilized to connect to the iMesh on-chip network.  The iMesh network is Tilera’s implementation of the grid architecture concept, with several enhancements of course, and allows the cores to communicate with each other as well as the main memory and the I/O. Since the cores are full-featured, each is capable of running an independent operating system. The general architecture of the TILE64 is shown in the illustration below.

Combined with a portfolio of 40 patents and the architecture described above, Tilera claims to be able to deliver 40X times the performance of the leading Texas Instruments DSP.  The TILE64 comes in several flavors running between 600MHz and 1GHz.  At these frequencies each core dissipates between 170 and 300mW, respectively.  Assuming the latter frequency, the chip would dissipate around 20 Watts without any of the peripheral circuitry or the network overhead. My guess is that the complete chip consumes at least 30 Watts, this however is pure speculation, since no average or maximum power dissipation numbers are available on Tilera’s website. Also missing from the website are the chip dimensions and the manufacturing node that is currently being utilized – two metrics that are of most interest to designers.

As discussed in previous posts, a multi-core chip is nothing without a good development environment that allows the programmer to take advantage of all the resources. Not to be outdone by other startups in the multi-core race, Tilera offers a Multicore Development Environment (MDE) that is based on the open-source Eclipse IDE, an ANSI C compiler, and a full system simulation model.  There are plans for the environment to support C++ soon as well.  In the meantime, the MDE enables developers to for example cluster cores, such that a particular application can obtain enough processing power. Of course, all this processing power and flexibility does not exactly come cheap, starting at $435 in 10K quantities. There are also plans for a 120 core device and a 36 core device, so we will definitely be hearing more from Tilera in the near future.

Not so long ago, the name of the game and the claim to fame was processor speed and megahertz. But as with most technology related things, the landscape changes quickly. These days, it is all about who can do more with less; less power that is. To approach this challenge, companies have to some degree been simplifying their cores, and instead of raising the megahertz count have been increasing the core count. The argument being, that several cores running slower but in parallel are more efficient than one core running at maximum speed, from the throughput and power envelope level point of view. However, it does not take a genius to figure out that if you put enough cores onto a single die, the power envelope per core decreases if the overall power for the chip is to stay the same.  Additionally, as you increase the core count, the die area for the chip is likely to increase, which can lead directly to yield problems.  A less leaky process and smaller feature sizes are no substitute for sound power management techniques and smart design. Addressing this very issue, Heinrich Hillmayr from Texas Instruments’ (TI) German division, posted an interesting article titled Minimizing Power Consumption at the Chip Level over at PowerManagementDesignLine.com (This must be one of the longest domain names I’ve ever come across!). If you are a seasoned circuit designer you can skip the first page of the article which briefly describes the basic relationships between voltage, leakage and dynamic currents, and power. If not, this might be a nice little review especially if you have an interview coming up. The second page is where the article gets interesting. In a perfect world there would be neither variation in a waver nor any variation between wavers, but semiconductor manufacturing is far from perfect. Thus in some regions, transistors are stronger than the nominal transistor, meaning that at a given voltage they conduct more current, while in other regions they are weaker and thus conduct less current. This causes two problems: Transistors that are located in the strong region will have a higher leakage current thus increasing the overall core power, while circuits in the weak region will have a problem meeting speed targets. The idea therefore is to diagnose the strength of the silicon, and to lower the voltage in strong silicon regions in order to decrease leakage currents while still meeting timing. The article does not disclose whether the silicon strength is determined by some sort of on-die sensors but simply states that the mechanism is based on embedded information.  I imagine that designing an on-die sensor to accurately determine transistor strength could be quite challenging, but not impossible. Whether such a design would be cost effective in the end is of course another matter. The article also describes voltage scaling based on temperature and has several charts to explain the details mentioned above and is definitely worth a quick glance.

The other day Microchip, a major provider of microcontrollers and analog semiconductors, launched ICwiki, a web-site it hopes will enable engineers to share best known practices as well as collaborate on projects. The site is currently available in several languages, allows for public and private discussions, and as the name implies it is based on Wiki technology. As stated in the press release, Microchip sees ICwiki as an extension to the University of Microchip, and at the same time as a foray into the world of social networking, hoping to capitalize on the recent social networking trend. In its current from though, ICwiki leaves much to be desired. The first missteps can be found in the registration process, where one has to complete more than fifteen fields to finally register. Compare that to Wikipedia which requires about five. It is understandable that Microchip would like to know who ICwiki users are, but that information should be collected on a profile page or something along these lines. Another major problem with the current implementation is that search function seems to be non-functional. The current system of browsing by topic and category, date or keyword will work, but will not scale at all once the number of entries increases. The content editor is minimal in functionality at best and the layout and overall look of the site needs improvement regarding ease of use and readability. Not to mention that on several occasions the site returned errors upon which it conveniently decided to go ahead to close the browser window – very annoying. The whole social networking aspect seems also to be missing, since other than sending email to other users there is not really a way of building a network. Other than the implementation problems, one has to ask the questions whether engineers will be willing to share best know practices in a public setting. Given how strict most companies are on disclosing any intellectual property outside of the company network, it is hard to believe that many professionals are going to feel comfortable discussing in-depth technical matters or best known methods. The exact purpose of having private discussions is also questionable, since people working on projects are likely to already have an internal system that they utilize for project tracking and discussion. Thus it seems that most likely ICwiki is going evolve into more of a discussion forum for specific questions regarding problems directly related to Microchip products, than anything else, at least in its current implementation. Regardless of the final outcome, Microchip should have waited with the announcement and done some more testing or at least a beta phase, since at the moment ICwiki does not seem production ready.