Breaking News
Comments
Newest First | Oldest First | Threaded View
DKC
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
DKC   1/4/2011 8:00:44 PM
NO RATINGS
"...it is not reasonable to expect all applications to be coded in a parallel rather than sequential fashion." Given that the trend is to more-and-more cores and possibly a mix of SMP, FPGA, and GP-GPU, I'd say anybody who thinks that they can keep going with sequential code or low-core-count SMP is not going to be around in a decade. HDLs exist as they are for historical reasons. One of the aims of my ParC project is to support legacy code by translation, i.e. any old Verilog/VHDL should be translatable into ParC going forward. New tools would be written to work with ParC (in ParC), and older tools can be migrated to take advantage at fairly low cost. Eventually the HDLs will become unnecessary.

KarlS
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
KarlS   1/4/2011 6:42:54 PM
NO RATINGS
In the real world of embedded systems, the application code runs on a cpu, in Utopia the application may get synthesized from the abstract. Garbage collection is not unique to Java. If there is no garbage collection then that horrible thing dubbed "memory leak" may occur. Driver development is part of the hardware design and provides a software interface to allow for re-usability. If the process blocks that run on separate threads equate to Verilog always blocks, then HDL must exist first. In any case, it is not reasonable to expect all applications to be coded in a parallel rather than sequential fashion.

DKC
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
DKC   1/4/2011 5:48:05 PM
NO RATINGS
"Since there is software, there must be a cpu" - not really, it depends on what the code does. HLS will turn code into RTL for you. Using C++ from top to bottom of the design flow - i.e. replacing Verilog/VHDL - makes life a lot easier, particularly for developing drivers. Garbage collection is a Java thing rather than C++.

KarlS
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
KarlS   1/4/2011 4:41:47 PM
NO RATINGS
There are two things that need to be separated hardware design and system design. System design takes hardware that has an interface defined by MMIO registers and their implied functions and connects the application software. Generally there is a device driver that actually manipulates the MMIO regs and has a software interface to either an IOS or native code. During design the software(application/OS/driver) must only work to that interface and may use all the available computer science. On the hardware side the MMIO functions have to be translated into physical circuitry. If there is a driver used for some of the hardware, then the driver software interface replaces the MMIO. The simulator/model/virtual prototype must focus on timing other than the traditional hardware waveform. Those waveforms can be used for pretty good hardware timing(it's the only game in town). That's the real time aspect that matter's. The other hardware function is the interrupt request which signals when the hardware needs to be serviced. Since there is software, there must be a cpu and the response time is usually so variable that it should be considered unknown. The idea of having multiple cpus {IO processors} dedicated to a few peripherals is a possible logical solution, but unaffordable. Using C++ aggravates the variability if object instantiation occurs dynamically along with garbage collection and the fact that compiler optimization throws out code that write only MMIO regs.

DKC
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
DKC   1/2/2011 8:01:37 PM
NO RATINGS
"But, ParC is C++ with HDL threading. Where is the parallel programming?" The parallelism in ParC is the same as in Verilog/VHDL, each "process" block is a separate thread that can be run in parallel. The assignment of threads to cores can be explicit or automatic - some of the tests have a call to "migrate(...)" which does a semi-automatic move. The communication mechanisms (signals & pipes) are opaque to the programmer, the runtime system looks after them so threads can be moved easily. In order for code to be reusable long-term you want to write it to take advantage of as many cores as it can. Amdahls law does not necessarily apply because what it really says is that for a given sequential algorithm if you start pulling it apart and adding communication on top of the existing processing then you will get diminishing returns. If you write a specifically parallel algorithm then you can go lots faster - or to look at another way: If you have an MPEG decoder written in C for X86 and an MPEG decoder written in Verilog, the latter is a parallel description which is a lot more complicated - but a lot faster/more-efficient when compiled for the right platform (FPGA/ASIC). ParC is about making the latter description easier to write so that you can also run it efficiently on multi-core (as well as FPGA/ASIC). Debugging ParC/CSP is pretty much the same as debugging Verilog/VHDL, folks like SpringSoft have tools for that, and you can use formal methods and assertion-driven testing.

KarlS
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
KarlS   1/2/2011 4:32:19 PM
NO RATINGS
I did go to the web site. No matter what the ESL is, bad design is still bad design. Also, a bad programmer can create a mess with any language. If the hardware guys are not good with abstractions, does that mean the right ESL will replace them? I think that is the underlying idea. So my conclusion is that programmers and the right ESL are all that's needed. The dream lives on. The topic that "Sequential Programming is so Last Century" caught my eye. But, ParC is C++ with HDL threading. Where is the parallel programming? CSP is the way to go and at first I thought Google's Go language would be usable, but they refuse to consider direct access to MMIO registers so all the "sharing by communicating" is unavailable. My feeling is that several tiny cpu's in an CSP configuration controlling IP peripherals is simple and doable today. Altera's SOPC Builder follow on Qsys looks pretty good. Amdahl's Law applies to multi-core and when things don't work right with everything inside a chip, who has the skill to debug that maze?

DKC
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
DKC   1/2/2011 8:59:18 AM
NO RATINGS
I'm glad you agree HDLs are ugly, however it's not really a requirement. Having worked in simulation for decades I can say most of the ugliness is due to bad design (by committee) and a desire to support (bad) legacy approaches. Also, hardware guys are not that good at finding the right abstractions. An ESL language really needs to be a programming language which is HLS friendly and usable as an HDL. Verilog/VHDL fail on the former, C/C++ on the latter. SystemVerilog is particularly bad since the committee could have helped bridge the SV/SystemC gap but completely failed to do so. Inspired by my SV experience I decided the way to go was to add the HDL threading model to C++. The project is on-going, and you can find it at - http://parallel.cc I will be adding analog support at a later date.

KarlS
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
KarlS   12/30/2010 3:12:40 PM
NO RATINGS
Yes, HDL's are ugly because they are a description/definition language and to some extent reflect some of the ugly things that have to be accounted for in the physics of the chip. HLS and multi-core in a very simple sense assume an unlimited number of registers (variables) that can be selected as inputs to a core(cpu/aithmetic/logicunit/DSP block) with no delay, and the result put back into any register. So much for abstraction: all of those things have to be connected by wires, dissipate power, and take up space. The dirty part is that physics is real, not abstract and must be applied. Multi-core is really SMP in that all the instructions and data must be supplied by the memory hierarchy which is limited by physics -- that UGLY word again! The old approach of "just get more memory and a faster cpu" won't cut it. It did not work for super computers either, so they went out and found some problems that could be solved by an array of processors.

DKC
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
DKC   12/30/2010 8:25:22 AM
NO RATINGS
Most of the C/C++ based ESL stuff fails in that it is a hardware-centric methodology as is programming in Verilog (as suggested by Karl). Software engineers don't like that kind of stuff much because the code isn't sufficiently abstract to be portable/reusable - aside from the fact the HDLs are ugly and dysfunctional. The opportunity for aggregation lies in the fact that programming a 1000-core system and designing logic for SoC are very similar exercises once you get away from SMP and RTL. I.e. a programming methodology for fine-grained parallelism will work equally well for general purpose processors, FPGAs, GP-GPUs and ASICs (with HLS). http://parallel.cc

KarlS
User Rank
Rookie
re: Evolution of design methodology II: The re-aggregation era
KarlS   12/21/2010 4:40:49 PM
NO RATINGS
Here's something that I need a little help with: HLS takes code to silicon and is a key factor. If I want to integrate IP into a system, then what I really want is to integrate the IP function into software. So parse the HDL (Verilog is easy) and produce code to use in the software development. The code is to run on a processor, but the processor itself is not being verified. Treat the IP the same way, verify IP separately and use it. Mainframe computer systems have been built by connecting processors, channels(DMA), Control units(IP), and external devices for about fifty years now. SOC is analogous.



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

Some Days You're the Pigeon, Others You're the Statue
Max Maxfield
4 comments
I was watching the travel channel on television the other evening. It was some program about Madrid. The thing I really noticed was the plethora of statues all over the place.

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)