Distributed EDA: sharing some CPU love

Is HDL simulation is amenable to distributed computing ?

It all comes down to paritioning. Consider map-reduce - a paradigm borrowed from the Buddha of programming languages: LISP.  The map-reduce paradigm, a mainstay of parallel processing, is dependent on operations being commutative and associative. 

I dont know how far will that get you in EDA.

Consider simulation – symbolic simulation (which is greatly used in formal verification), generates intermediate symbols to propagate further. This is actually done to stop explosion of minterms and to parition the assertions and verifications. This is the starting step for partitioning a simulation problem.

Now consider loops – you simplify this by actually making two copies of the node (corresponding to the forward path and backward paths) and send them off to the machines where they are to be processed.

Enter locks. Exit stage left.

Synchronization is among those problems of programming that starts with double espressos and ends off with sleep deprivation drugs. I’m not talking about computer science mind you – the lowly sweatshop programming is what I am referring to. 

I can imagine of various situations where you hold a lock on a node, and you need to communicate that to another process (on another machine or the same machine) – maybe the forward path problem doesnt have the right to hold the lock, because the backward path problem is the higher priority one. 

Enter priority scheduling and interrups. There is no stage.

It is a hard programming problem. Perhaps it can be better tackled in functional programming languages with a strong message passing paradigm  like Erlang.  But then EDA computing is highly, highly processor intensive – even on a single computation. I dont know how far that will scale – but as hardware is getting cheaper, I think it is time someone in EDA made the bet on functional programming languages and throw lots of cheap hardware at the problem.

I think it will scale better than expected.

Liar Liar at the DAC

Well this was interesting DeepChip post

It was interesting to read about Cadence’s Parallel VCS. I dont know what was the underlying technology that they tried to use, but it is heartening to know that multi processing/threading, does have a few champions left in EDA.

Looking at the non-EDA enterprise world, I see the shift towards trying to capitalize as much processor real estate as possible. Take for instance virtualization – it exists simply because people want to save money and power by running two operating systems on the same physical box, yet keep them separate (IP address, hardware ID, etc.) Probably, the problem space allows you to scale in that way – which EDA does not.

EDA is one of the most processor hungry software I know of. Yet, it is not capitalizing and scaling with multiple processors. It will be a darn shame if we are going to use only one of Intel Larrabee’s cores, when it hits the market (P.S. nVidia vs Intel will be fun to watch)

EDA will have to move to these computing systems, but the question is still open, on whether C++ (the traditional turf of EDA) will capture the flag, or will it be some other language. 

Note that the advantage of manual memory management loses its sheen when compared to the raw brawn of 16 cores.

Laptop bags – why so bad?

I dont get it – there are hundreds of laptop bags, made from exotic materials, and most of them have like this teeny strap covering the top of the laptop. The whole point in getting a backpack, as opposed to slipping it inside my grocery bag was protection. But the booming business in laptop-sleeves, which incidentally are touted by many of the same manufacturers, probably are the reason for substandard protection.

I have witnessed multiple people undergo “backpack malfunction” with their laptops. I have a Pakuma backpack which I bought two years back and it has survived India … Need I say more?

Would it kill more bag manufacturers to have a thick all-around padding and just forget about the ipod holder for a while