October 10th, 2013
Given that history and innovation are being featured here in this space this week, it’s only appropriate to highlight the fact that EDAC is hosting a very interesting event related to history and innovation in Silicon Valley next week.
On Wednesday, October 16th, those who have made massive contributions to the EDA industry will be highlighted and celebrated at a black-tie optional dinner at the Computer History Museum. If you’re interested in rubbing elbows with the powerful and prolific, you should be going to this event. If you want a chance to bid at auction for lunch with today’s corporate leaders in EDA, you should be going to this event. If you think said corporate leaders make enough money to pay for your lunch, rather than vice versa, you should still be going to this event.
Bill Martin, E-System Design President & VP of Engineering, sent the following essay detailing 4 Generations in the History of Electronics, including the Last/Lost Generation …
“If I have seen further, it is by standing on the shoulders of Giants.”
Isaac Newton, 5 February 16761
1st Generation (1940-1960s): Vacuum tubes and possibilities
The start of the electrical computer age produced first generation electrical computers that required large rooms to contain them. These computers were large, heavy, power-consuming devices that had poor reliability (mean time between failures, MTBF): nothing like today’s handheld consumer devices that are more powerful, fit in your pocket, easily connect wirelessly to networks and can last 4+ hours on a single charge.
A few smart engineers realized that larger systems could not be built unless higher levels of integration were possible, helping to improve MTBF, size, weight, power and cost: a recurring theme for each generation that followed.
Was just trying to get downtown in time for happy hour at my favorite wine bar tonight, when what should I stumble upon but the ribbon cutting for Draper University.
The new darling of downtown San Mateo, this one-off school of entrepreneurialism is housed in the iconic Ben Franklin Hotel, which has stood as art-deco sentinel over the historic center of San Mateo for nine decades. Now re-painted, spruced-up, and re-named Draper U, the folks founding this trendy school have closed the entire block of 3rd Avenue this evening in order to celebrate their launch.
No matter that the 3rd Ave Sports Bar, Kaffeehaus, or Masu Japanese Bistro – not to mention the original Amicia’s Pizza – might want to draw in their own Thursday evening foot traffic, Draper University is King of the Hill here this evening. A way-hip band blares away mid-block to pump up the crowd, enormous oversized beach balls roll up and down the suddenly-pedestrian-only street, and a 2-story climbing tower can be spotted above the noisy, shifting crowds.
Human-readable RTL code generation
October 10, 2013 by Matthieu Wipliez
Every now and then I meet somebody (compiler writers most of the time, but not only) who believes that generating human-readable RTL code is worthless. They claim that nobody should need to look at generated code, among other things because they should just trust the compiler, like software engineers do. It is time to examine the facts.
1. The majority of the hardware engineers that we’ve met with Synflow want to be able to understand the generated RTL, because they want to be able to reuse, verify, optimize or modify the generated code themselves. This includes people from big companies such as STMicroelectronics, Samsung, Renesas, ARM, as well as medium enterprises like Thomson Video Networks, RivieraWaves, ScaleoChip. Although this is only a subset of all hardware designers and semiconductor companies, I think we can consider it a reasonably representative sample. As a matter of fact, the rest of designers may not care whether the generated code is human-readable, but no designer has ever told us that he or she would prefer incomprehensible code, or even worse a netlist. Actually, that is probably because…
In the last SCE-MI article, we discussed how SCE-MI macro-based infrastructures can speedup SoC design verification time. In SCE-MI 2.1, Accelera introduced a ‘function-based’ infrastructure which is based on SystemVerilog DPI functionality. The SystemVerilog DPI is an interface which can be used to connect SystemVerilog files with foreign languages (C, C++, SystemC, etc).
One of the curious aspects of electronics is that most products are specified from the top down but implemented and verified from the bottom up. This is true for system-on-chip (SoC) development as well. As the onset, someone in product marketing specifies a chip that has a specific collection of functionality to meet a specific customer need. The architecture team develops a block diagram that defines the subsystems and perhaps some individual IP blocks as well.
When it comes time to develop the RTL that implements the SoC, designers tend to work from the IP blocks upward. They select commercial IP where it makes sense and develop unique IP when needed. Designers are usually responsible for verifying their own blocks, perhaps with some assistance from verification engineers. There is usually minimal verification of commercial IP unless it has been customized for the SoC project.
You are registered as: [email@example.com].
CafeNews is a service for EDA professionals. EDACafe.com respects your online time and Internet privacy. Edit or Change my newsletter's profile details. Unsubscribe me from this newsletter.
Copyright © 2018, Internet Business Systems, Inc. — 25 North 14th Steet, Suite 710 San Jose, CA 95112 — +1 (408) 882-6554 — All rights reserved.