Slashdot Mirror

The linchpin of the Intel-AMD agreement is a tiny piece of silicon that Intel began talking up over the past year: the Embedded Multi-die Interconnect Bridge, or EMIB. Numerous EMIBs can connect silicon dies, routing the electrical traces through the substrate itself. The result is what Intel calls a System-in-Package module. In this case, EMIBs allowed Intel to construct the three-die module, which will tie together Intelâ(TM)s Core chip, the Radeon core, and next-generation high-bandwidth memory, or HBM2.

AMD sell Intel bare dies that talk EMIB. Interesting thing is that Intel could do a deal with NVidia to supply GPU dies which use the same interface. Well except that Intel pays NVidia licence fees whereas the AMD Intel patent licensing agreement is completely one sided - AMD pays Intel but Intel gets IP rights to anything AMD invents for free.

It's not like AMD is selling Intel a synthesizable core or even a hard macro. And Intel being Intel they probably pay people to do competitor analysis on AMD stuff anyway. So getting bare dies doesn't tell them anything that they don't already know.

And as a lot of people have noted Apple use Intel and AMD GPUs but not NVidia ones. Post Itanium I think Intel regards Apple as its non commodity low volume/high margin market.

So it all makes sense. It'll be interesting to see what the chip costs and if EMIB graphics has performance and/or power advantages over PCI Express run chip to chip. With USB you can strip out the analog transceivers for HSIC

https://www.synopsys.com/dw/dw...

Could you do something similar for PCIe? Turns out you can

http://eecatalog.com/pcie/2012...

Meanwhile, modem makers were looking for a suitable interconnect for next-generation LTE networks. These networks will have air interfaces capable of throughputs beyond the 40 MB/s typically possible with HSIC USB. Further, there was a desire to deploy other SuperSpeed applications such as mass storage in a chip-to-chip environment. The SuperSpeed Inter-Chip USB (SSIC USB) group selected M-PHY as the physical layer, and developed a reference model that bridges from the PIPE 3.0 reference model to the M-PHY physical layer. This allows existing USB 3.0 IP to be quickly adapted for SSIC USB use by deleting (or disabling) the legacy USB 2.0 support, replacing the USB PIPE 3.0 implementation with a shim plus an M-PHY implementation, and making minor changes to the link layer of the USB 3.0 IP.

In September 2012, PCI-SIG and the MIPI Alliance announced an initiative to similarly adapt PCIe to run over M-PHY. Because of the work already done by the USB-IF SSIC USB group, the adaptation will likely include a similar reference model based on PIPE 3.0, simplifying early prototyping and architectural verification.

PCIe over M-PHY is likely to be quickly accepted in the Ultrabook and x86-based tablet PC market because it will allow reuse of hardware and software IP while lowering system power requirements. Adoption may be slower in smartphones and ARM-based tablets, because thereâ(TM)s less experience in using PCIe in those systems.

Of course you could do that for PCIe run chip to chip too. Still maybe you could use lower voltages over EMIB.

https://news.synopsys.com/2016...

Synopsys bought a company that specializes in this kind of work a few months ago.

Three years ago, also this:
http://www.bizjournals.com/san...

The vendor of this IP claims their IP is far more power efficient. That could be important for many applications, or scalability.
Delivers 1000 GOPS/W with 5x better power efficiency than GPUs

The vendor of this IP claims their IP is far more power efficient. That could be important for many applications, or scalability.
Delivers 1000 GOPS/W with 5x better power efficiency than GPUs

They're offering high perfomance, low power, low cost IP cores that can be combined with other IP. This will make it easier and cheaper to integrate that functionality into other devices.

News release: Synopsys Launches High-Performance Embedded Vision Processor IP

Description page w/ link to datasheet: High-Performance Vision Processors Optimized for Object Detection
Interesting nugget: Delivers 1000 GOPS/W with 5x better power efficiency than GPUs

They're offering high perfomance, low power, low cost IP cores that can be combined with other IP. This will make it easier and cheaper to integrate that functionality into other devices.

News release: Synopsys Launches High-Performance Embedded Vision Processor IP

Description page w/ link to datasheet: High-Performance Vision Processors Optimized for Object Detection
Interesting nugget: Delivers 1000 GOPS/W with 5x better power efficiency than GPUs

Argh, where is a good overview of the EDA industry when you need one?

The only thing I can come up with is the "EDA Industry Primer" on one of Synopsys' Investor Relations pages. That's too high level here-- it only describes the buzzwords for investors.

There use to be a better one, and I think it was Cadence that was putting this out. But I can't find it now.

They're really much fancier versions of these FPGA solutions I've seen - http://www.synopsys.com/Systems/FPGABasedPrototyping/CHIPit/Pages/default.aspx

Load the RTL in them and bang away. Neat stuff. Run godawful slow, but that's FPGAs for you (timing is usually a killer). Though it's usually much faster than pure software sims. I think these things ran Linux too - they had the classic Tux penguin when you power 'em up.

I know that Synopsys has their Confirma system for FPGA prototyping of larger (ASIC) designs.

This is for verification in your chip design flow.

What else is out there?

In other words, the background investigator is a POS, and proud of it. Think about that.

Hm. There are two issues here and I'm a bit confused regarding which you mean.

My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.

Vacancy: UNIX Systems Support...

[...] Driver license and ability to lift up to 45 kg Education: BSCS or equivalent [...]

BSCS - 3rd Semester - "Linux Clustering: Avoiding Compound Strain Injuries"

Bzzzt, try again. It's more like a slice of $37,500,000,000. Equivalent to the current game market. I'll quote parts of the article, so you don't have to read it all:

why would game developers spend the money to add Linux functionality to games for a limited number of users? The answer is not that simple, especially since Linux desktop use continues to grow.

There are many reasons why you might want to shift from Windows to a Linux OS. We won't cover what those reasons might be in detail here, but will note that users routinely complain of Windows instability, high prices and many layers of software that impede performance.

Linux "is no longer a niche phenomenon." The overall Linux marketplace revenues for server and PC hardware and packaged software are expected to reach $35.7 billion by 2008, IDC says. Packaged software revenue is the fastest growing market segment within the Linux marketplace, growing 44% annually to over $14 billion in 2008.

Bling, Bling! Let me demonstrate what's going on here and why Windoze is a loser. I can go out and buy a big_name or I can build my own computer for gaming. If I buy the big_name, it's going to come all nice and configured with Windoze and ready to roll, but it will set me back about $1,000. I can get the same kind of hardware from a no name or parts market for about $450 to $700, depending on how stu^H^H^H much I want to pay for a video card. Even if I'm stupid, I can get a hell of a lot better hardware on the parts market for less money. Then, I can buy windoze, pirate windoze or use free software. Whether I pirate or buy windoze, I still only have a four minute halflife online, that's FUCKING UNACCEPTABLE. With free software there's now a chance I will be able to play. Bang for the buck is going toward Linux in a big way. If I want to play games, Microsoft is the expensive and expendable middle man.

What I'd love to see is live game CDs. I'd pay good money for that, and trust me, I've got plenty I have not been spending on $100 operating systems that suck.

Let me paraphrase Gandhi:

1. they ignore you
2. the laugh at you
3. they bust their ass accommodating the market share of the future.

That time has come. I think the $37.5 billion estimate is low. Gamers have traditionally driven PC hardware markets and gone to pains for their pleasure. Linux is now about as easy to set up as Winblows and is much easier to keep up. Companies that ignore this to stay in M$ clutches are going to lose out big time.

I got my masters degree in engineering (M.Sc. - E) two days ago and for my thesis I used several open source tools designs for electrical engineering.

A site gathering many tools and aiming to be a complete design and analysis package is, gEDA: GPL Electronic Design Automation.

Another promising project is SystemC, which is an open source HDL (Hardware description language). The language is C-based and easy to learn (if you know C). With some (very expensive) commercial tools from Synopsys, it is possible to translate SystemC code to VHDL and do synthesis.

Moving a bit more towards software, but for embedded devices, a project from Berkeley is TinyOS. Completely open source.

Many things can be done without spending a dime but actual engineering, i.e. a product, does require commercial products before a design can be shipped of to the factory. But a startup can go a long way before spending anything on commercial software, very much like many software companies have done for many years now.

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.

CAD? Perhaps Synopsys will do?
They've got that, and their timing extraction tools, and others (I'm out of the semiconductor business now, so I've lost track), and last I knew, Cadence was porting their stuff too.

I too remember hearing that Mentor Graphics would cost upwards of $1M per seat. <SARCASM>The high price is clearly to compensate for the highly elegant user interface.</SARCASM>

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!)

Nope, the TI calculators are based on the 68000 from motorola.

The Z80, in its day, was a complicated chip. Now allotting that much board space for 'only' that much functionality seems like a waste. As a result, the Z80 has being sold more and more as IP to be embedded in a larger chip than as a whole chip itself. Here are some cores.

The list of Z80-like parts includes: Z80, Z180, 84C011 (toshiba), 84C11, 84C013, 80C13, 84C015, 84C15, 64180 (hitachi), NCS800 (national), Z181, Z182.

But, unless you've got some legacy code, your best bet is finding a microcontroller that has the correct mix of peripherials, power, speed, and price. Technology has advanced so much since then. Even if you have legacy code... it's probably still worth considering alternatives.

P.S. here is a good source of documentation

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...

Most mechanical/aerospace and electrical/computer design firms are heavily rooted in UNIX. I work for a semiconductor design and technology firm and all our EDA (electronic design automation) tools not only run on UNIX, but 75% of them either don't have Windows ports or are "crippled" on Windows (because of issues with multiuser, remote display, etc...).

About half of those tools now have full, native ports on Linux. Specifically you ask? Try Synopsys, Mentor Graphics, ModelTech, etc... Although Sun just came out with a powerful new UltraSPARC III chip (powerful from an FPU, and therefore engineering, standpoint against x86), Linux gives you much more "bang for the buck" on single/dual processor x86 hardware than SPARC.

Furthermore, many of the preceding companies have been touting the price vs. performance ratio of Linux clusters versus traditional shared memory Sun systems (in favor of Linux, of course ;-) and have modified their Linux ports just for such implementations.

-- Bryan "TheBS" Smith