Search
Calendar

 << September 2010 >> 

SU| MO| TU| WE| TH| FR| SA
      01020304
05060708091011
12131415161718
19202122232425
2627282930    
#4: What is a GPU?
1:05am - May 17, 2010

Narendra Konda, Director of Hardware Engineering at NVIDIA, spoke on stage at the April 27th Cadence EDA360 Event at the San Jose Tech Museum. Afterwards, Konda was available for questions. It was great to get a direct reponse from NVIDIA for #4 in The Mocha Mystery Series.

 

Please note: Konda's answers below are a brief and interesting addendum to the GPU v. CPU cook-off that NVIDIA showcased at their own special event in January at the Clift Hotel in San Francisco. You can read about that event here.

 

Meanwhile, understanding both Narendra Konda's comments below and the January NVIDIA event requires a grasp of CUDA. To do that, Wikipedia was called in for additional clarification.

 

*****************************

 

Q -- Is a GPU just a suped-up CPU?

 

Narendra Konda -- A GPU is not a general purpose CPU. It is something which inherently has a tremendous amount of compute power. Internally at NVIDIA, externally at our customers, and in a universal context, people want to be able to harness the power of GPUs.

 

A GPU is highly programmable, and requires specific computing realization and knowledge into the silicon. CPUs today are generally quad-core or 6-core devices, but GPUs have up to 512 cores. Once people start to use the power of GPUs, they will see up to a 10x improvement in compute power.

 

For instance, in oil exploration where evaluating wave data is very compute intensive, people are starting to do that work on GPUs and seeing calculations that used to require up to 5 days, now running in just a few hours.

 

GPUs are not CPUs, but they are definitely stepping into the CPU space.

 

Q -- So, what is a GPU?

 

Narendra Konda -- a GPU is a complex device that handles tradtional graphics processing, plus compute processing.

 

A GPU is something in a PC that does graphics processing, and some of the compute processing that was traditionally handled by the CPU.

 

Q -- Accepting that a GPU may have 512 homogeneous cores, who's going to parse the software to run on the GPU?

 

Narendra Konda -- NVIDIA is offering our CUDA architecture to the industry to help solve the problem.

 

Q -- What is CUDA?

 

Wikipedia -- CUDA stands for Compute Unified Device Architecture, and is a parallel computing architecture developed by NVIDIA.

 

Q -- Come again?

 

Wikipedia -- CUDA is the computing engine in NVIDIA GPUs. It's accessible to software developers through industry standard programming languages.

 

Programmers use 'C for CUDA' compiled through a PathScale Open64 compiler, to code algorithms for execution on the GPU.

 

CUDA architecture shares a range of computational interfaces with two competitors -- the Khronos Group's Open Computing Language, and Microsoft's DirectComputer. Third-party wrappers are also availabel for Python, Fortran, Java, and MATLAB.

 

#3: What is Verification IP?
6:58pm - May 9, 2010

 

JL Gray is Vice President of Verilab Inc., an engineering and consulting services company based in Austin. JL recently returned from an extensive trip to Asia, with stops along the way in Shanghai, Taiwan, and Tokyo. In each geography, he conducted instructional seminars to help engineers better understand how to verify their designs.

JL and I spoke by phone after he returned from his trip, per an earlier agreement that he would offer an answer to the latest question in The Mocha Mystery Series. Before you read on, please know that JL is moderating a panel at DAC relevant to this discussion ...

SOC Verification: Are We There Yet?

*****************************

Q – What is Verification IP?

JL Gray [Laughing] It seems like an obvious question, perhaps with an obvious answer, but the reality is that Verification IP can be different things to different people.

For companies who sell Verification IP, it means: "Here's what you need to model the interface for PCI-Express, or DDR, etc."

PCI-Express, for instance, perhaps needs a host. If you sell Verification IP to that type of customer, you're going to sell them something like a checking library, some assertions, and a test suite -- all packaged up together.

But in other cases, when people are selling Verification IP, it's something more internal, where the package is not so pretty.

For instance, "Yeah, I have a 10-megabit Ethernet interface, and I know Bob down the hall wrote it.  Maybe I can reuse it."

If you're using Bob's assertions and test suite, you're effectively using a form of Verification IP.

Q – It isn't Verification IP if it's internally generated?

JL Gray A lot of people hear about reusability, but continue to say, "We don't reuse things from one project to the next, or buy things from the outside." 

Those are the people who wouldn't refer to Bob's test suite as Verification IP.

Q – So there's internally generated Verification IP that nobody calls VIP, and then there's the commercial variety?

JL Gray –  Yes and those distinctions are based on the use model, the quality, and the expectations. There are actually two types of VIP.

First -- the packaged professional version implies someone has tested it, and maybe you're lucky because you're not the first to be trying it out. It comes with support, which is a kind of theoretical distinction.

 Q – What would that professional package include?

JL Gray –  It all depends. Cadence's Verification IP, for instance, includes automatic compliance verification and is metric driven, so it falls into the metric-driven verification flow.

Some VIP can come with just a bus function model, a BFM, but doesn't include a compliance suite. Say you're building a certain type of design block, and wanted to know if it would actually work in a different system, the Verification IP [associated with that design] might not come with a Verification test suite. You might have to purchase it from somebody else.

 Q – It sounds like the definition varies from vendor to vendor.

JL Gray –  That's probably true.

If you look at some of the verification methodology from Cadence, for instance, they want to define what the file should include -- documentation, tests that make it run, etc. -- and they actually go ahead and try to specify these things in advance.

But, if you buy something from a company that supports Verilog, VHDL, C++, etc., they will probably come up with their own scheme. Maybe you're using VMM, or OVM, or Vera -- there are so many permutations!

And it's particularly complicated and tricky to be an IP vendor, because you have to deal with all of these things.

 Q – Problems with Verification IP overlap with problems with Design IP?

JL Gray –  Yeah, it is the same as with Design IP. You might know it's been used successfully, but even then it might not work for you and your specific system. It's very hard to know in advance.

 Q – That's bad for me if I'm trying to define Verification IP, but good for you if you're providing services wrapped around VIP?

JL Gray –  [Laughing] We have developed some VIP for our customers, and  we help our customers understand the various commercial products out there.

 Q – You mentioned two types of Verification IP. Define the second type.

JL Gray –  It's not so much a completely different type, as much as a sub-type. Something that you're sharing on an ad-hoc basis. It may not have started off as VIP, becuase you've got a manager saying you can't reuse this or that on your project. You say back to the manager, "Okay!"

But, you're actually chuckling and knowing that if you don't call it Verification IP, then you can get away with it.

Of course, that's only if the somebody who made it did a good job packaging it for reuse -- an important distinction!

But even then, you have a lot of real issues to deal with. Maybe it doesn't have the right hooks, or maybe you have the source code, but there's no way to get updates. It's just a Big Mystery Box, without any documentation at all!

 Q – If I were a manager facing that reality, I'd insist that my team develop their own verification suite.

JL Gray –  Yes, that's an interesting observation, and could be the logical conclusion from my statements here.

For some of the SoC companies, however, you've got 50 things or more that are special and unique. It's your job to stitch them together, and ship it out. At the top level, you're putting a bunch of stuff together and hoping that it works.

 

Really, how much of this can you do in-house?  Eventually, you don't have the resources, or the expertise, or a stable enough interface to get it all done. In that case, VIP is really important!

 

Q – Let's start again: Is there such a thing as Verification IP?

JL Gray –  Yes!

 Q – What is Verification IP, in 25 words or less?

JL Gray –  [Laughing] You mean, defined in a single tweet?

Verification IP is a piece of testbench infrastructure that has been developed for use on multiple projects.

 Q – How much money should I spend on my Verification IP?

JL Gray –  That's a very interesting question -- and funny, because a lot of people want things for free!

It's my impression that a lot of companies know there's value in VIP, but depending on the interface and how much it costs, they may or may not decide to develop it in-house.

So, the answer to your question depends on several things: Who is it for, and who is going to use it?

In the end, the correct amount of money is as much as it takes to sleep better at night!

 

#2.1: Is there such a thing as analog IP?
2:42pm - May 3, 2010

 

Navraj Nandra, Director of Marketing for Analog and Mixed-Signal IP at Synopsys, presents a viewpoint here regarding analog IP that differs somewhat from the view expressed by Magma CEO Rajeev Madhavan in the original April 23rd Mocha Mystery Series posting on the topic.

By the way, Nandra has his own blog on the Synopsys website:

 

www.synopsysoc.org/theeyeshaveit/

 

********************************

 

Q – Is there such a thing as analog IP?

 

Navraj Nandra – Yes.  The term IP is defined as "build once and license many times", while the term Analog is applied to a whole host of circuits. Putting the two ideas together means you have to decide which analog circuits support the IP definition.

 

Physical layer interfaces for USB and PCI Express are analog circuits; these are easy to consider as IP, because their specifications are standardized through electrical working groups.

 

Data converters, complete analog front-ends such as video, or audio CODECs can also be considered as analog IP - although there are currently no steering groups standardizing these specifications. However, the specifications are pretty much fixed for these circuits.

 

Q – If there's been analog IP for so long, why isn't everyone convinced?

Navraj Nandra – There are a couple of reasons.

1) No standard electrical specifications exist for analog IP. This is an excuse for custom analog design services to remain intact.

 

2) When analog IP was not widely available, the analog functions were pretty much custom designed and there was little reuse. However, with the increased availability of ready-to-integrate analog IP, this trend is shifting towards an IP reuse model.

 

I remember early in my career as a designer working for Philips Semiconductors in Eindhoven, there was an initiative to reduce the number of new data converters, to reuse as much as possible already existing designs. The same thing had already happened years before in digital design, so that even at that time no one questioned the idea of digital IP. We wanted to make that happen in analog design as well.

 

Today, a vendor that develops an analog IP roadmap is focused on the future requirements of a target market, and acts as a catalyst to accelerate the trend towards analog IP for that market.

 

For example, we have an analog IP portfolio of data converters that targets multiple applications: broadband wireless (LTE, WiMAX, WiFi) broadcast receivers, wireline, and video. These are all analog IP blocks that are ready to integrate without customization.

 

Q – Can you get 10 analog designers to go on record saying they're happily using analog IP in their designs, specifically IP they themselves did not design?

 

Navraj Nandra – Absolutely!

 

Last year, we commissioned an analog IP audit which polled about 400 engineers and managers worldwide, where we specifically asked that question.

 

Depending on the region, we had between 50% and 65% respondants state that they have used analog IP that was not developed in-house.

 

Q – Then why do you think the impression lingers that analog IP has not yet come of age?

 

Navraj Nandra – I don't necessarily see that. It's a regional issue.

 

Some regions are more open to purchasing analog IP. In fact, they see it as their competitive advantage. These are fast-paced companies developing the latest consumer devices that need ready-to-integrate data converters or an audio CODEC, for example.

 

And today, even large centralized engineering teams tasked with building IP are starting to purchase externally designed analog IP.

 

Q – Ultimately isn't it the problem that the interface around an analog design block is completely dependent upon its environment? There are no standard environments, so there's no analog IP.

 

Navraj Nandra –  Not at all, for most analog circuits.

 

Even complex analog systems like video analog front-ends can be defined in a way that allows them to serve most application requirements, thus being good candidates for analog IP.

 

The exception to this is RF and power management -- this is where the IP model has been failing. One of the product decisions I made early on was not to offer RF and power management as analog IP.

 

But, that doesn't mean that analog IP is not here and available in most other categories.

 

 

 

#2: Is there such a thing as analog IP?
2:27am - Apr 24, 2010

 

During his March 10th keynote at Magma’s MUSIC users conference in Silicon Valley, CEO Rajeev Madhavan left the distinct impression that analog IP is now a reality.

 

I had never heard it stated with such conviction, however, and the question was already on the list for the Mocha Mystery Series – so Madhavan agreed to speak by phone at a later point to discuss analog IP in greater detail. His comments from our April 15th phone call are below.

 

Before reading further, note there will be major announcements made at DAC in this area, with particular news out of the manufacturing sector.

 

Note also that Madhavan co-founded Magma in 1997, and has served as President, CEO, and Chairman of the Board. Prior to Magma, he co-founded Ambit Design and LogicVision. His MSEE is from Queen’s University in Ontario.

 

 

********************************

Q  –  Is there such a thing as analog IP?

Rajeev Madhavan – Historically, there has been no analog IP that you could preserve in any form, and optimize for a particular node.

For instance, if you designed an HDMI at 90 nanometers, you started from scratch. For an analog-to-digital converter, you had to simulate everything in the design. If you went to a specialized analog foundry to use their low power process, it took months and months to get it done.

[That’s why] analog IP has always been more about services, and less about IP. It’s been about telling the customer, “I’ve done this before.”

You’ve entered a customer account with, “I’ve got this technology and these IP blocks, but it’s my services built around my experience with certain types of IP that you are buying.”

All of that is about to change, however. We’ve added algorithms and techniques, [and achieved] the most exciting thing I’ve done in my EDA life in terms of technology!

It’s actually working, and [in cooperation] with one of the top foundry companies, it will be announced at DAC!

Now analog IP can be used as building blocks of design, with given optimizations at certain nodes. Plus, it will be migratable! Now it can be optimized to give better performance, rather than tweaking the design for years [to get it right].

And, there’s actually a layout tool that’s [at a development point comparable] to where we were with digital many years ago

Synopsys realized early on, that you needed some base cells in digital, so they created a digital IP business over 15 years ago. The first IP element was the adder/multiplier – the kind of things that come along in a library, and then get picked by the tool for optimization. Now we’ve actually done the same thing in analog.

It took a long time to understand the customers’’ needs, and to get the tool for automation, but we’ve got it in deployment in 12 of the top 20 semiconductor companies now.

We are really breaking new ground here, which for me is the final frontier of design. We are actually allowing the analog designers to think in terms of band gaps, not transistors, and allowing for more repeated reuse – telling the customer that if they’re doing a design at 180 nanometers, they can do it at 90 nanometers, as well.

It’s a very unique value proposition, and we’re all very excited about it! To succeed [in the long run], we know we need to create a portfolio of analog IP companies around us. We are working with a lot of companies to do that.

There are two tactics available. We can keep the technology to ourselves, or we can allow everyone else to create their own IP using the technology. I am very much in favor of the second approach, creating a business model that allows people to innovate.

Q – So, analog IP isn't the question? Instead it’s about being able to migrate an analog design block from one process node to the next smaller node?

Rajeev Madhavan – If you look at a PLL with 10-to-20 sub-blocks – when you go from one process to another, you have to make changes. But if you make those changes and optimize it using the tool, that will allow you to meet new specs.

The problem has always been there, to come up with a solution for resizing the design, with the analog part always inherently more complex, because it’s not a discrete model like in digital. In analog, it’s about working with a continuous algorithm, one that can be scaled to any dimension. Mathematically, it’s very complex.

You have to put your digital experience aside, and allow for a heuristic solution – one that converges. This continuous optimization problem can only be solved by providing the user with a tool that can input the heuristics into an automated solution – a very unique thing.

Q –  Fundamentally, it’s a math problem?

Rajeev Madhavan – Yes, it’s a tricky, but beautiful math problem, with lots of good things coming out [of the solution].

Everything has to be done to maintain electrical integrity in the design, no matter what is changed. Previously, designers used design rules to hit the mark, but now the problem has been formulated at the math level. The algorithms solve it at the math level, rather the engineer [having to do it].

Q – So,  it’s the layout tool that’s been lacking?

Rajeev Madhavan – Absolutely, just like in digital design in the early days. The difference is that this optimization will now happen at the system level.

[To reiterate], in RTL synthesis, the circuit is being done by the tool. People have tried to solve the analog problem by doing exactly the same thing, but it has not worked.

It’s forced us to accept the fact that analog designers are among the most ingenious people, which is what has keeps them alive professionally and differentiated. They are experts at optimizing for a give process, at doing layout for a given problem.

Q – But isn’t the problem creating analog IP, not the initial design?

Rajeev Madhavan – Absolutely, but this is about re-purposing designs. It’s about generating 10 to 15 different types of circuits, and exploring an entire design space at different voltages, rather than just generating one circuit. We’ve achieved this, and also solved the layout. The solution would not have been complete without both.

Q – Now you‘ve got a tool,  how do you get the analog guys to use it?

Rajeev Madhavan – With 12 out of the top 20 semis using the tool, we’re seeing very good proliferation with engineers learning how to use it. However, we’re not replacing the humans. The analog designer is still the god of circuit topology!

We’re not attacking the designers, but providing somet'g that can be integrated into their Cadence lay-out environment. The tool just allows them to work more efficiently. If you accept Moore’s Law in analog, the designers need to be able to make changes automatically [as the process nodes shrink].

Q – I recently heard an vendor bragging that they have over 3000 available IP blocks? How much of that do you think is analog IP?

Rajeev Madhavan – You don’t need 3000 different types of IP in analog. You only need about 100 baseline categories.

But, if you need to make changes in those blocks, the customization capabilities have to be a lot greater than in digital IP blocks.

[However the number of IP blocks is not the point], it’s that when people talk about the quality of IP, they won’t just be talking about digital IP. They will be talking about analog IP, as well.

I have no doubt about this!

 

#1: Is multicore a reality?
3:27am - Apr 1, 2010

 

To get the answer, I called Grant Martin, Chief Scientist at Tensilica. Grant had no problem providing a clear answer to  my question, while also confusing me simultaneously. Oh well. The topic wouldn't qualify as a Mocha Mystery if it was easy to understand.

Before you read on, please keep in mind that prior to Tensilica, Grant worked for Burroughs in Scotland, for Nortel/BNR in Canada, and for Cadence in San Jose, where he was named a Cadence Fellow. After our phone call, I decided Grant deserves a new title ...

Heterogeneous Asymmetric Multiprocessing Fellow

**********************************

Q –  Is multicore a reality today?

Grant Martin –  It all depends on the definition. Some take a narrow definition, but I take a wider one. Some say, for instance, that multicore just refers to symmetric multiprocessing – 2, 4, or 8 cores – which is what companies like Sun, IBM, and Intel mean when they talk about their SPARC, x86, or PowerPC chips.

Here at Tensilica, however, we think of multicore as being blended with multiprocessing multiprocessing being the design style that many consumer, handset, and large equipment manufacturers have been using for a long, long time – including if you look back at the original cell phones of the mid-1990’s. They used RISC cores along with DSPs to do voice encoding and decoding.

When you have heterogeneous multiprocessors, some may be multicore and some may be domain-specific compute engines for particular end applications. You might have an audio processor, for instance, to do encoding/decoding, or you might have a special broadband processor on a single core that might involve multiprocessing.

In theory, you could have a homogeneous set of processor cores. But more likely, a homogeneous multicore device is an N-way symmetric device, such as you might get from IBM. Other devices are definitely more heterogeneous. If you split something into multiprocessing for different applications, then you’re more likely to want to take advantage of those features.

Q  –   This is really confusing!

Grant Martin –  Yes, it is. But again, it’s typically because companies like IBM, AMD, and Intel say multicore, and then only talk about homogeneous multiprocessing. But, there's a lot of heterogeneous asymmetric multiprocessing in consumer devices.

In many ways, the conversation is driven by lots of people still remembering the old mainframe CPU, where everybody had to line up to run their jobs. Today, however, the modern distributed smart phone can have 4, 8, or more processors – they have so much more processing power than your old mainframe!

And, now it’s battery life that’s driving innovation. Widespread use of heterogeneous asymmetric multiprocessing does not need to wait for the development of better batteries, because it is more power efficient than many homogeneous approaches.

Q –   So, the term you like is: heterogeneous asymmetric multiprocessing?

Grant Martin – Yes, because it reflects the wider scheme. But remember, inside there could still be a multicore device, which would give you the capacity to load more applications in the future – not in real time, but more in the user interface or controller domain.

Q –  Moving past the confusing hardware terminology, can today’s software be parsed effectively to take advantage of what multicore has to offer?

Gran Martin –  No, because you would need a tool to be able to convert standard applications into a number of threads that would cooperate – multi-threading the application into symmetric, cache-coherent multicore. But, such a tool remains a profound research project.

That doesn’t mean all is lost, however. There continue to be multicore support libraries to help programmers handle multi-threading to run on multicore devices, and there are different companies who provide those libraries today.

Last year, Intel bought several small, independent companies offering those sorts of libraries – Cilk Arts and RapidMind. Intel bought them specifically to add to their already well-developed programming environment and toolsets. Presumably, Intel is now providing an even richer set of offerings.

Q –  Have you vetted the Intel multi-threading programming tools or environment?

Grant Martin – I haven’t looked at Intel specifically, but I had heard about both RapidMind and Cilk Arts long before they were acquired.

These kinds of libraries have been around for a long time, but they are basically manual assists for creating multi-threaded applications. There’s nothing, as yet, that's an automatic tool for parsing an application into multiple threads.

I am aware, however, of a tool from one company – Critical Blue – which does what-if analysis to help you analyze whether your application can be parsed into multiple threads. If you want to port the application to a symmetrical multicore device, you need to know up front if you can take advantage of the multi-threading capacity you'll find there. There may be other tools out there like the one from Critical Blue, but I’m not aware of them.

Q –  Is all of this an issue for Tensilica – tools for automatic parsing?

Grant Martin – No, it’s not, because we focus on heterogeneous multiprocessors. Of course, there are issues about splitting software and porting it, but it’s more ad hoc. People here focus on a different task – determining the kind of data they need to send across different kinds of control paths.

However, we definitely do work on methods to help our customers in terms of our own multiprocessing systems, but it’s a far less regular process than what you’re talking about – taking existing software and splitting it to take advantage of multicore hardware.

Q – In a perfect world, there would be a tool that could take any software and split it, to optimize any kind of homogeneous or heterogeneous multicore platform. Right?

Grant Martin –  Yes, that would be very nice! But for now, it still only falls into the category of a research topic.

Think about it – to automatically split or suggest cut points in a 2D application is not realistic. In reality, you have the datawise dimension of the application for mapping onto symmetric homogeneous multicore hardware, and you also have the time-based dimension of the application, such as you find in signal processing, where you are using asymmetric multiprocessing. In fact, to split most applications you need a little bit of both.

You need to explore the datawise multi-threading and timewise dataflow. Today, you have cores stacked beside each other, and cores stacked on top of each other. It’s all very complicated, and nothing that I am aware of in the research community comes close to solving all of this.

Q –  If you could fund a university to work on these things, which university would you choose?

Grant MartinThere are people at U.C. Berkeley who have done some work in this domain – but in truth, most other centers of this type of research work are in Europe. I was at a Summer School last year in Barcelona called ACASES [Advanced Computer Architecture and Compilation for Embedded Systems], which was driven by large applications and some for embedded systems.

Q – Regarding embedded systems: isn’t splitting an application across multiple threads an ideal way to minimize the footprint?

Grant Martin - Yes, but we shouldn’t overstate the advantages. Often people understand an application domain – especially if they’re mapping it onto multicore – but they may not understand the application at each stage. Things are sequentialized into different types of processing at different point in time. It’s not like we’re starting with a totally blank slate, but there are interesting, unanswered questions in understanding how to shunt data back and forth.

Interestingly enough, we could have talked about these same issues 2 years ago. There really has been no dramatic progress in recent years. There is still today this overwhelming need to have an automatic solution, which hasn’t arrived as yet, because people are finding adequate ways to deal with the problem today.

We currently have hardware that allows us to do things on a symmetric multicore, because there are limits on inherent datawise concurrency in many applications. Today, you might be able to use 4 cores on a device, but not 8.

Q – Is there an argument for abandoning the effort, for just resolving to stick with sequential code?

Grant Martin –  It depends on what part of the application you’re in. If it’s not dominated by computation time, but only by user interface time, then usually a sequential application is good enough, and no one would worry about parallelizing it up.

But, the minute you want to process large amounts of data, then you want to explore the concurrency – then you want to worry about the concurrency in time and space. You want to ask: Can I pipeline a bunch of tasks, optimizing through different cores, each optimized for different tasks?

Q –  It’s really an N-dimensional problem, right?

Grant Martin –  Yes, it’s N-dimensional. But, a lot of good thinking comes from some of those dataflow-oriented tools like Simulink from MathWorks and the old SPW tool from CoWare, now part of Synopsys,which also has System Studio in this area. Those kinds of tools encourage people to think of defining computing into data flow, and then deciding what might be parallel at all stages in the applications.

Q –  How does this whole discussion apply to Tensilica?

Grant Martin – Many of our customers use multicore in their products. Some use a control processor, plus a number of different accelerator cores. For them, partitioning is easy.

Also, along with the new advanced standards in baseband processing for wireless devices, comes the use of heterogeneous data style multiprocessing. At Tensilica, we’re developing capability along those lines, and seeing a lot of interest from our customers. But this is not optimizing, and is by no means an automated process. But it’s also not impossible – many applications are being ported onto heterogeneous multiprocessors today.

Using heterogeneous multiprocessing means having to deal with the reality of what can be done today, and finding more tractable ways of doing programming than just a simple emphasis on homogeneous multicore machines. We need to learn how to explore the whole problem if we want to find the whole solution.

Looking at multicore machines, and thinking about multiprocessing and multi-threading, are orthogonal dimensions of a complex problem.

Q – If this is what you get to think about all day, is it possible you’ve got the best job in the world?

Grant Martin –  I definitely enjoy what I do, and have every day since I joined Tensilica 6 years ago. The work is challenging, but we do really good stuff here!