Breaking News
Comments
Newest First | Oldest First | Threaded View
betajet
User Rank
CEO
Re: Working in Parallel Doesn't Work
betajet   1/24/2014 7:05:24 PM
NO RATINGS
Scott Elder wrote: Sure, if they took the time, their code would run a lot faster.  But I don't think most people would care or pay for it.

IMO most web sites have horribly inefficient Javascript code, which requires people to have far more processing power (and thus less battery life) and far more memory than what would be needed if the people who wrote that code had ever had to carry their programs around in 2000-card boxes.  I think users do care when it takes longer than necessary to load web pages.  They don't realize why it's so slow, but they'd be happier if performance improved because of less waste.

I suspect that Apple hires people who understand computers at the lower levels, and that's a reason why their software works so well.  Apple can afford to pay people to write elegant software.  On this 30th anniversary of the Apple Macintosh, it's useful to point out that much of the original Macintosh OS was coded in 68000 ASM to fit in that 64KB ROM.

JMO/YMMV

Scott Elder
User Rank
Manager
Re: Working in Parallel Doesn't Work
Scott Elder   1/24/2014 6:43:36 PM
NO RATINGS
@betajet,

I understand your point.  But do Web Site programmers need to understand the Intel x86 mnemonics?  Do they need to understand how many clock periods it takes to do a MOV AX to BX instruction?

Sure, if they took the time, their code would run a lot faster.  But I don't think most people would care or pay for it.

In software, everyone has moved up to the next higher level of abstraction.  And the software industry has exploded because of the speed an application can be written and distributed.  I think hardware would benefit using the same methodology.

Apple engineering works the same way.  You only need to know one level away. Selling 100's of millions of products worldwide with an impressive field failure rate suggests it's not a bad methodology.

betajet
User Rank
CEO
Re: Working in Parallel Doesn't Work
betajet   1/24/2014 6:17:29 PM
NO RATINGS
Scott Elder wrote: I wonder how much quicker products would be developed if each level of the development was done by a single collocated team whose deliverables were "shrink wrapped" to the next team working at the next higher level of abstraction.

This might work except that abstraction layers leak, so you end up with problems at the high level that can only be understood by looking one or more layers below.  At that point, the engineer who knows about transistors, ground bounce, flyback diodes, metastability, machine language, and other subjects "nobody needs to understand any more" is the only one who can save the project.

Besides, I would hope that all digital engineers would be curious about how transistor circuits work -- and how they fail -- and would find joy in understanding these things.  Part of being an expert in a subject is to have a grasp of one or two or more layers below where you usually work.  That way it's not magic, and when you have noise or heat problems you have an idea where to start to fix them.

JMO/YMMV

Scott Elder
User Rank
Manager
Working in Parallel Doesn't Work
Scott Elder   1/24/2014 5:37:04 PM
NO RATINGS
Its time to stop trying to develop large integrated systems with parallel teams.

Digital engineers no longer need to understand anything about transistors.  Fewer and few engineers need to understand an HDL like Verilog.  Pretty soon there will be no difference between an engineer that designs a digital circuit for an ASIC and a programmer who writes code for Windows 7 or Mac OS X.  But curiously, all of the prior skills are still required.

We still need process designers, transistor designers, nand gate designers, place and route programmers, etc. all the way up to the programmers that wrote HDLCoder for Simulink.  But we don't need them to all work in parallel.

The requirement to understand all of the details of a product development from the pins down to how a transistor works no longer exists.  But it is very hard to convince the team members that's the case.

I wonder how much quicker products would be developed if each level of the development was done by a single collocated team whose deliverables were "shrink wrapped" to the next team working at the next higher level of abstraction.

Graham Bell
User Rank
Freelancer
SoC is a Sea of Interfaces
Graham Bell   1/22/2014 12:57:27 PM
As SoCs have become more complex, so has the task of verifying that what is implemented on chip is what the designer intended. No single verification approach can deliver the certainty that design teams need to tape out, but a suite of tools that each address a particular issue can help build that confidence. Applying the tools may also do more than avoid errors: better analysis early in the design process can avoid issues propagating, and, by highlighting which issues matter and which can be safely ignored, give designers the freedom to improve their designs.

Today an SoC is a sea of interfaces connecting different blocks and sub-systems. Individual IP blocks may be as complex as entire SoCs of five years ago, and may have internal clocking and power-management strategies which SoC designers need to be aware of. The integration of these complex blocks means that clock signals may have to negotiate up to 100 asynchronous clock domains as they cross block interfaces. Similarly, systemic power management strategies may involve coordinating power management within a block and among many blocks.

Managing the verification of such complex systems is challenging. The designs are large, so designers need tools with very high capacities. They need to be able to control the rising tide of uncertainty caused by clock signals that cross domains, and power-management strategies that create unknown (X) logic states when they blocks are turned on and off. Most of all, designers need these tools to tackle such problems at the highest level of abstraction possible, to speed up the verification process and stop the issues multiplying and becoming more obscure as the RTL design is decomposed to gates. Clock domain crossing (CDC) tools, engineered to recognize and analyze crossings for problems, are essential to help control the verification complexity involved in tackling a full SoC.

 

 



EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Tiny Kickstarter MCU Board Provides 'Smart Fusion' for IoT Systems
Max Maxfield
2 comments
Just a few minutes ago as I pen this words, I received an email from my chum Mike Hibbert, who is a columnist for the computer and electronics hobbyist magazine Everyday Practical ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
20 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
15 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
46 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)