Slashdot Mirror

Wow, it is posts like yours that make it worth wading through all the sludge.

Now we only use windows PCs for prototyping

Right, a lot of good engineering software runs only on Windows, but you don't need a Windows PC to run it, virtualization is highly effective and seamless these days. You do need a Windows license but only the most basic and the cost is trivial.

Beyond that, a lot of engineering tools come from small coding shops. Just pay for a Linux port. The big boys are already on Linux (BTW, more than a little interesting that ARM shows up in the selected support category.)

I'm familiar with Dr. Baas' older work (ASaP and ASaP2). He presented his work to a team of processor architects I was a part of several years ago.

At least at that time (which, as I said, was several years ago), one class of algorithms they were looking at was signal processing chains, where the processing steps could be described as a directed graph of processing steps. The ASaP compiler would then decompose the computational kernels so that the compute / storage / bandwidth requirements were roughly equal in each subdivision, and then allocate nodes in the resulting, reduced graphs to processors in the array.

(By roughly equal, I mean that each core would hit its bottleneck at roughly the same time as the others whenever possible, whether it be compute or bandwidth. For storage, you were limited to the tiny memory on each processor, unless you grabbed a neighbor and used it solely for its memory.)

The actual array had a straightforward Manhattan routing scheme, where each node could talk to its neighbors, or bypass a neighbor and reach two nodes away (IIRC), with a small latency penalty. Communication was scoreboarded, so each processor ran when it had data and room in its output buffer, and would locally stall if it couldn't input or output. The graph mapping scheme was pretty flexible, and it could account for heterogenous core mixes. For example, you could have a few cores with "more expensive" operations only needed by a few stages of the algorithm. Or, interestingly, avoid bad cores, routing around them.

It was a GALS design (Globally Asynchronous, Locally Synchronous), meaning that each of the cores were running slightly different frequencies. That alone makes the cores slightly heterogeneous. IIRC, the mapping algorithm could take that into account as well. In fact, as I recall, you pretty much needed to remap your algorithm to the specific chip you had in-hand to ensure best operation.

The examples we saw included stuff familiar to the business I was in—DSP—and included stuff like WiFi router stacks, various kinds of modem processing pipelines, and I believe some video processing pipelines. The processors themselves had very little memory, and in fact some algorithms would borrow a neighboring core just for its RAM, if it needed it for intermediate results or lookup tables. I think FFT was one example, where the sine tables ended up stored in the neighbor.

That mapping technology reminds me quite a lot of synthesis technologies for FPGAs, or maybe the mapping technologies they use to compile a large design for simulation on a box like Cadence's Palladium. The big difference is granularity. Instead of lookup-table (LUT) cells, and gate-level mapping, you're operating at the level of a simple loop kernel.

Lots of interesting workloads could run on such a device, particularly if they have heterogenous compute stages. Large matrix computations aren't as interesting. They need to touch a lot of data, and they're doing the same basic operations across all the elements. So, it doesn't serve the lower levels of the machine learning/machine vision stacks well. But the middle layer, which focuses on decision-guided computation, may benefit from large numbers of nimble cores that can dynamically load balance a little better across the whole net.

I haven't read the KiloCore paper yet, but I suspect it draws on the ASaP/ASaP2 legacy. The blurb certainly reminds me of that work.

And what's funny, is about 2 days before they announced KiloCore, I was just describing Dr. Baas' work to someone else. I shouldn't have been surprised he was working on something interesting.

If you algorithm is standard just google "FPGA/ASIC IP provider" (of which there are many, eg H264 etc) and pay the price, your results will be optimal and cheaper than doing it yourself - assuming you never have before.

If your alogirthm is custom then you are either going to make a horrible job of it as you learn HW as you go, it takes years to get optimal and reach the clock speeds, area, and QoR/Test coverage numbers needed for production Si. Alternatively you could hire a HW team who will cost you a pretty penny to get it done, or outsource - also not cheap but it allows for risk reduction.

How many gates isnt just a question of counting "*" and "/" and scaling (although back of napkin will give you a general feel). Practically any C/C++ you write is going to be very sequentially orientated, this results in algorithms that probably have better parallel implementations. Whilst you might now be thinking threads, or separate processes we are talking HW parallelism, which is far more fine grained than threads, than SW parallelism. Further any integers you have may be optimizable to less than 32 (eg 1 bit or 3 bits) thus saving a large amount of HW area. Finally you didnt really say what sort of performance you want - if its 1MHz and 1 word / year of I/O then I suspect you could build some very clever hardware to do it all a few gates but if its 1GHz and 1 Giga Words/sec then area might expand as you will need to duplicate the circuit in parallel. Finally the speed at which you process data will affect latency (time from input to the first correct output) which is often a killer in real-time or other systems (eg. If you put LCD TVs side by side you might notice some are running several seconds behind whats being broadcast - this is because as it received the image some are doing more video processing to clean up the image - latency )

So at this point I would recommend looking into SystemC (based around C++), SystemVerilog (so so ) and then a raft of tools to help you do the job. These tools are called "High Level Synthesis" (HLS) tools and they arent cheap but they do cut down on man hours manually converting algorithms, but you will still need to be able to think extremely low level as bad code results in bad gate count - no matter the language.

I dont want to come over as a shill so I am going to present the 4 main competitors for HLS tools;
1) Calypto Systems, formerly Mentor Graphics' tools before spin-out ( http://calypto.com/en/products/catapult/overview )
2) Forte Desgin systems ( http://www.forteds.com/products/cynthesizer.asp )
3) Cadence C2S ( http://www.cadence.com/products/sd/silicon_compiler/pages/default.aspx )
4) Impulse C ( http://www.impulseaccelerated.com/ ) - this is very reasonably priced but has its limitations.
5) There are some open source things out there, I wouldnt recommend them as they are quite in their infancy.

Disclaimer: I used to work at one of the companies that provides synthesis tools, for >10 years converting C/C++/SystemC to HW quite often for a service fee. I can tell you we never had a design that cost under 30K and most were in the 100s to millions of USD.

It's been awhile, but I used to use Cadence SoC Encounter. It was pretty effective in taking behavioral verilog and automating a working layout. Of course, you had to tweak it quite a bit. As mentioned, there are a few different software packages available to convert from C/C++ to verilog first.

Here is a link to the Hardware as well. http://www.cadence.com/products/sd/palladium_xp/Pages/default.aspx

Too bad that it only runs at 4Mhz. I was dreaming of a configureable super computer. And yes I understand that for it to even work at 4Mhz is pretty freaking cool. Where is the buy now button?

Or you could try VirtualBox.

The poster specifically said that he does not want to force the students to purchase Windows, which would be needed with VirtualBox. In any case, if $insertOShere cannot run the software that one needs, then that OS is useless for a particular person. So why run Windows in VirtualBox when the the user could just run Windows on the hardware?

The real solution here is to contact the OrCAD developers and ask about Linux support. Here is their address:
http://www.cadence.com/products/orcad/

Specifically, their contact page is here:
http://www.cadence.com/alliances/channel_partner/pages/default.aspx

Write to them and ask about a Linux or Wine-supported version of the software. If we do not express interest in Linux software, then obviously no one is going to write it.

Or you could try VirtualBox.

The poster specifically said that he does not want to force the students to purchase Windows, which would be needed with VirtualBox. In any case, if $insertOShere cannot run the software that one needs, then that OS is useless for a particular person. So why run Windows in VirtualBox when the the user could just run Windows on the hardware?

The real solution here is to contact the OrCAD developers and ask about Linux support. Here is their address:
http://www.cadence.com/products/orcad/

Specifically, their contact page is here:
http://www.cadence.com/alliances/channel_partner/pages/default.aspx

Write to them and ask about a Linux or Wine-supported version of the software. If we do not express interest in Linux software, then obviously no one is going to write it.

FTA:

Ultimately, the next few years could be very important for memristor research. Right now, "the biggest impediment to getting memristors in the marketplace is having [so few] people who can actually design circuits [using memristors]," Williams says. Still, he predicts that memristors will arrive in commercial circuits within the next three years.

So probably not yet. From what I've seen just from a quick Google search, it will involve updating not just the models but the core code as well.

No actually, yields do not fall exponentially. If they did, nothing made today would work at all. Yields are largely independent of feature size

I was speaking of die size, not feature size.

Turns out, I was correct - yield is an exponential function of die size.

All yield models discussed at http://www.semiconfareast.com/test-yield-models.ht m express yields as powers of e.

Then there's this: "The size of the actual silicon plays an important role in yield. A smaller design, holding all other factors equal, will increase yield for two primary reasons. First, the smaller the die the more that can fit on a wafer thus giving more yielded parts for a given number of wafers. Second, the actual per part yield is a function of area where smaller area is better since there is less chance that a random defect will land on the silicon rendering the part inoperative."- http://www.cadence.com/company/newsroom/articles/D esign_Yield_Cost_Model_eedesign_June04.pdf

...which also supports my statement.

I wonder if somebody could explain why dual-core CPUs are a good idea. If it's a pair of cores on a single piece of silicon, it seems it would take the same silicon as two separate cpus, so where's the benefit? You'd save the cost of an extra socket on the motherboard, but then again yield decreases roughly exponentially with die size, which argues for 2 separate cpus.

I hate to say this, but the last time I looked, Cadence only last month was ported to 64bit Linux

Now maybe in a year or two my company can start running Cadence on cheaper boxen.

I saw 3-4x performance gains on Redhat 8.0, Xeon 2.8GHz, 4GB ECC.

3-4x compared to what? That's a simple question... care to answer it?

My server was a nice Altus 130 with dual Athlon 2600MP and 4 Gb of ram, and a nice, EDA vendor supported Red Hat 7.2. Now, I happen to know that the Athlon CPUs tends to get starved since the CPU-Memory bus isn't quick enough to keep it up for some things, like verilog simulations, or on various benchmark reports that you can find at various sites. That's why even my old Sun Blade 1000s with only 600 Mhz CPUs was able to keep up. The Suns have a better memory bus. A P4 with the 800 Mhz bus would do better that the Athlons, and let the greater CPU power show. The 533 Mhz bus wasn't really different that the Athlon.

This was VerilogXL, NCVerilog and Design Compiler.

We run Modelsim and VCS. So? I might believe NCVerilog would be Modelsim, but VCS?

Your FUD doesn't hold water "anonymous coward".

There is FUD flying alright, but its mainly anti-Sun FUD coming from you. Well, that might be a little harsh. I'll give you the benefit of the doubt and just assume that you are ignorant and unfamiliar with your vendors plans and supported tools. Since I'm in a charitable mood I'll help you out.

Why don't you try visiting DeepChip? You will find, if you read carefully, that Linux is far from a universal win, although there are many success stories. Unfortunately many of the success stories sound sort of like yours-- "I have a hot, brand new Linux box that beats some sort of old Sun!! Linux RULES!!" If you cast your net wider to check FPGA sites, and various other ones, the story is about the same.

Here is the Cadence SUPPORTED HARDWARE PLATFORMS MATRIX FOR 32 BIT platforms. You will notice that there are large gaps in the Linux support, and that it is for older releases.

There is also a Cadence SUPPORTED HARDWARE PLATFORMS MATRIX FOR 64-BIT APPLICATIONS, but I wouldn't bother looking for any Linux based tools there for at least a year or two, if ever. Even IBM's AIX doesn't fare so well there.

What about Synopsys? Well, their baseline for building EDA tools on X86 Linux is going to be Red Hat 7.2 (the one that is EOLed) for some time to come, and it will only support binary compatible versions. (I will also note that Synopsys has dropped support for various intermediate Red Hat releases on various tools due to problems, so you might find that 7.0 and 7.3 supported, but not 7.1 or 7.3). On the Itanium Synopsys is going to support Red Hat Enterprise (you know, the cheap one - not.) Although why you would buy an Itanium based system and run Red Hat instead of HP/UX is beyond me. HP/UX is far more mature and has a much larger software base than Linux, but I guess some people will run Linux just to run Linux.

What about Mentor Graphics? Their supported platform release history looks a lot like the other two. There are lots of tools that only run on old Linux releases, and gaps in the releases.

As You can read in the Red Hat Network 2.6.0 Release Notes that they have End Of Lifed Red Hat 6.2-7.0. 7.2 should be EOL about now too.

As you can see, almost all EDA tools from the major EDA vendors are only supported on obsolete, unsupported Linux releases. If you put in a little effort, you will find that many of them are moving to run only on the professional versions o

I saw 3-4x performance gains on Redhat 8.0, Xeon 2.8GHz, 4GB ECC.

3-4x compared to what? That's a simple question... care to answer it?

My server was a nice Altus 130 with dual Athlon 2600MP and 4 Gb of ram, and a nice, EDA vendor supported Red Hat 7.2. Now, I happen to know that the Athlon CPUs tends to get starved since the CPU-Memory bus isn't quick enough to keep it up for some things, like verilog simulations, or on various benchmark reports that you can find at various sites. That's why even my old Sun Blade 1000s with only 600 Mhz CPUs was able to keep up. The Suns have a better memory bus. A P4 with the 800 Mhz bus would do better that the Athlons, and let the greater CPU power show. The 533 Mhz bus wasn't really different that the Athlon.

This was VerilogXL, NCVerilog and Design Compiler.

We run Modelsim and VCS. So? I might believe NCVerilog would be Modelsim, but VCS?

Your FUD doesn't hold water "anonymous coward".

There is FUD flying alright, but its mainly anti-Sun FUD coming from you. Well, that might be a little harsh. I'll give you the benefit of the doubt and just assume that you are ignorant and unfamiliar with your vendors plans and supported tools. Since I'm in a charitable mood I'll help you out.

Why don't you try visiting DeepChip? You will find, if you read carefully, that Linux is far from a universal win, although there are many success stories. Unfortunately many of the success stories sound sort of like yours-- "I have a hot, brand new Linux box that beats some sort of old Sun!! Linux RULES!!" If you cast your net wider to check FPGA sites, and various other ones, the story is about the same.

Here is the Cadence SUPPORTED HARDWARE PLATFORMS MATRIX FOR 32 BIT platforms. You will notice that there are large gaps in the Linux support, and that it is for older releases.

There is also a Cadence SUPPORTED HARDWARE PLATFORMS MATRIX FOR 64-BIT APPLICATIONS, but I wouldn't bother looking for any Linux based tools there for at least a year or two, if ever. Even IBM's AIX doesn't fare so well there.

What about Synopsys? Well, their baseline for building EDA tools on X86 Linux is going to be Red Hat 7.2 (the one that is EOLed) for some time to come, and it will only support binary compatible versions. (I will also note that Synopsys has dropped support for various intermediate Red Hat releases on various tools due to problems, so you might find that 7.0 and 7.3 supported, but not 7.1 or 7.3). On the Itanium Synopsys is going to support Red Hat Enterprise (you know, the cheap one - not.) Although why you would buy an Itanium based system and run Red Hat instead of HP/UX is beyond me. HP/UX is far more mature and has a much larger software base than Linux, but I guess some people will run Linux just to run Linux.

What about Mentor Graphics? Their supported platform release history looks a lot like the other two. There are lots of tools that only run on old Linux releases, and gaps in the releases.

As You can read in the Red Hat Network 2.6.0 Release Notes that they have End Of Lifed Red Hat 6.2-7.0. 7.2 should be EOL about now too.

As you can see, almost all EDA tools from the major EDA vendors are only supported on obsolete, unsupported Linux releases. If you put in a little effort, you will find that many of them are moving to run only on the professional versions o

The machine is fast and the OS is advanced. But what irks me to no end is that Apple seems hell-bent on keeping the Mac in its little niche market. It doesn't make much sense but Apple refused to capitalize on people's migration from traditional Unix to the more "user friendly" NT. As an example I'll use the situation I am most familiar with but keep in mind this sort of thing is probably similar across dozens of industries. Computer hardware and electronics design. The most popular tools today are probably those from Cadence and Synopsys. Both have powerful software suits available for 32-bit and 64-bit versions Solaris, Linux, HP-UX, and NT(32)/XP. For some reason people started migrating from Unix to NT. So now I'm stuck using design and verification tools on 2000. When I use Mentor Graphics ModelSim and Cadence's Layout and PSpice I have to install all this extra stuff like Cygwin, and Perl just to try to imitate the functionality avaialable in Unix. I'm sure many other people do this. Plus, these third party tools are so poorly integrated into the rest of the OS.
With Mac OS X, it's all there. The complete Unix toolset and environment comes standard, the Macs are good for graphics as it is (which is what all these new design tools focus on anyway), and the UI is a dream to use. It's simply a better platform in a lot of different ways. Check out Sun and SGI's third party applications pages, then look at Apples. There are whole industries missing.
Here's where Apple needs to come in and sell these people on their product. Users want better software, software companies want a larger use base and better product and Apple wants to ship more units. Why is this not being done?
The funny thing is that in-house ASIC design at Apple is probably done on Solairs, HP, or NT. I'm sending e-mail Cadence and gang. Everyone who doesn't want to see this whole industry to be swallowed by NT and wants to move to OS X should do the same.

Cadence Design Systems v. Avant!

First Avant! had to pay a decent chunk in fines for the criminal case.

Then Cadence got paid $182 million from the civil case.

Cadence Design Systems v. Avant!

First Avant! had to pay a decent chunk in fines for the criminal case.

Then Cadence got paid $182 million from the civil case.

Maybe it could if it wasn't somewhat large $2.5B company. My guess is that it was Cadence Design System's Palladium product they were infringing upon. http://www.cadence.com/products/palladium.html

Until recently, they didn't support Sloaris 8, thus preventing a lot of newer Suns (Blade 100/1000/2000) from being used. The Blade 100's are really important to education customers since they're cheap, even if they're slow.

I agree, the currently available hardward description languages out there (nearly nothing but VHDL & Verilog) are sorely behind the curve. Unfortunately, you're not going to get the support of the big EDA vendors (Synopsys,Cadence,etc.) if you go with an academically developed language like the one you mentioned. There are new languages coming down the pipe, however. A new Verilog standard was approved last year, which makes a few steps in the right direction. Also, there has been a good bit of momentum behind some newer languages, such as Superlog from Co-Design Automation, which is still under NDA, but looks like it has promise. HDLs develop very slowly. Companies invest millions of dollars in EDA software that only support the big two languages, and nobody is willing to budge unless everybody moves at once (sounds familiar!)

First, most ASICs built these days are built with logic synthesis tools from Synopsys or Cadence. The inputs are typically register transfer level (RTL) code written in either the VHDL or Verilog languages. These logic synthesis tools have been around for quite some time (well over a decade for Synopsys) and have a significant infrastructure built around them. This design paradigm and sets of tools all assume synchronous logic. I can't fathom how you would build/constrain/debug these circuits in an asynchronous style with the existing toolset. And don't say "we'll use something else". It is these types of tools which have made our million gate ASICs possible. If we were still using schematics or other hack tools we would barely have passed the 80286. The current design tools took a long time to develop, hone, and get the bugs out of. The amount of money involved in just the tools is on the order of billions of dollars per year. That's a lot of inertia to move away from.

Second, yes the asynchronous approach can reduce the power consumption of ASICs. However, there are a lot of clocked approaches that do a very good job of reducing power. It all depends on what goals you have when you design the ASIC. Having multiple clocks and clock gating is common in the low power and embedded domains. It hasn't been as much of a factor in desktop systems but is certainly in use in handheld devices. The Crusoe takes these approaches to an extreme level. It's all a matter of what you want to design for and time to market pressures.

Lastly, speed. I think folks forget the feedback path. If you're going to rely on this asynchronous handshake, it requires a given stage to hold its outputs until the next stage acknowledges (asynchronously) that it got the data. This means the given stage can't accept anything new yet. This cascades/ripples back through the pipeline. This feedback takes time (and logic levels) that don't exist in clocked logic. Imagine an automotive assembly line where things could only move forward if each station got permission from his adjacent stations. In clocked logic you've guaranteed that the data is ready to move forward because you've calculated these things out. You've removed a bunch of communication overhead. Yes, there is slack in the synchronous pipeline, but for the most part current designs are pretty well balanced so that each stage uses a large portion of its clock cycle.

That's about all I can think of at the moment. I need to be getting home before I get snowed in! ;-) Just a few comments from a digital hardware designer. Hope this provided some food for thought...

I've had some minimal experience with some Cadence tools running on Solaris workstations. I wonder if they could possibly run as well under Windows.

Anybody?

--