It's like professional boxing, where there are now so many sanctioning organizations (WBA, WBC, WBO, IBF, ...) that the average person has no idea who the real champions are, and no longer really cares, either.
Monday, February 26, 2007
Wednesday, February 21, 2007
Inspired by the DFT Bookcase over at the DFT Digest blog, I decided to create pointers to the technical books I use every day in my work. (Yes, I looked the ones strewn about my desk and next to the computer, rather than those arranged neatly (and less used) on my bookshelf. Perhaps you'll discover a title or two that will help you.
|Great book for learning Perl -- it's how I learned, going through it from cover to cover. And I still use it for a basic reference.|
|A surprisingly useful book. I can't count the number of times that I needed to solve some puzzle in Perl, and found it already grokked in this book.|
|Lots of good ideas here. When you are going to pick a coding style, why not follow what they've already figured out?|
|My newest addition. I'm enjoying working through it to learn about references, packages, and object-oriented Perl.|
|Programming Perl is the "bible", though personally it's not my favorite. And I find Larry Wall's humour distracting.|
|My go-to book for Tcl.|
|Because, sometimes, a good ol' shell script is enough.|
Tuesday, February 20, 2007
- the claim that this multi-core design was first architected for easy programming, before creating the hardware architecture. I agree with the claim that "most massively-parallel chip companies started with the hardware, leaving the programming model almost as an afterthought".
- the implementation is globally asynchronous, locally synchronous (GALS). Man, that is sexy! ;-) I've been interested of commercial implementations of this more-efficient clocking approach.
I'm going to watch for Ambric and try to learn more about their designs. By the way, interesting caveat in the quotes: "If Ambric's tools work as well as the company promises, ..." Ain't that always the challenge?
Monday, February 12, 2007
It's a nice short read.
One of the "takeaways" from his advice is that he highly recommends this book,
which is surely a classic in career planning:
Friday, February 09, 2007
What's nice is the variety of topics he touches on:
- The lack of interest in ESL vs. design implementation, and why engineers are being short-sighted by not getting into architecture.
- Thermal performance, an interdisciplinary problem. When I've been involved in thermal analysis, the biggest problem is coming up with a credible power consumption figure. It's back to the "vectors" problem, and what's a representative (or worst-case) simulation?
- Is DFM for Designers?
- Fewer students are going into Engineering. And engineers "get no respect", as Rodney Dangerfield would say.
Thanks Gabe, for the synopsis!
Wednesday, February 07, 2007
Look at all Dr. Williams' achievements, stretching back to the 1970s. This is (one of) the father of LSSD, which begat the full scan DFT methodology that we all use today. He's truly a giant in DFT one of the legendary early figures in EDA.
Congratulations on a well-deserved honor!