Embedded Systems Conference
Breaking News
Newest First | Oldest First | Threaded View
User Rank
Re: Working in Parallel Doesn't Work
betajet   1/24/2014 7:05:24 PM
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.


Scott Elder
User Rank
Re: Working in Parallel Doesn't Work
Scott Elder   1/24/2014 6:43:36 PM

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.

User Rank
Re: Working in Parallel Doesn't Work
betajet   1/24/2014 6:17:29 PM
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.


Scott Elder
User Rank
Working in Parallel Doesn't Work
Scott Elder   1/24/2014 5:37:04 PM
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
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.



In conjunction with unveiling of EE Times’ Silicon 60 list, journalist & Silicon 60 researcher Peter Clarke hosts a conversation on startups in the electronics industry. One of Silicon Valley's great contributions to the world has been the demonstration of how the application of entrepreneurship and venture capital to electronics and semiconductor hardware can create wealth with developments in semiconductors, displays, design automation, MEMS and across the breadth of hardware developments. But in recent years concerns have been raised that traditional venture capital has turned its back on hardware-related startups in favor of software and Internet applications and services. Panelists from incubators join Peter Clarke in debate.
Flash Poll
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Special Video Section
The LTC®4015 is a complete synchronous buck controller/ ...
The LT®3042 is a high performance low dropout linear ...
Chwan-Jye Foo (C.J Foo), product marketing manager for ...
The LT®3752/LT3752-1 are current mode PWM controllers ...
LED lighting is an important feature in today’s and future ...
Active balancing of series connected battery stacks exists ...
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...