Tag Archives: engineering

Do Romantic Thoughts Reduce Women’s Interest in Engineering?

If romance reduce girls’ pursuit in engineering, probably the reverse is also true that girls choose engineering have less interest in romance as well. They should do a follow up research and survey a large sample of engineering girls, see how many of them had a boyfriend in high school.

Now, someone should come up with a research showing male engineers are not romantic, so Pat cannot complain I am not romantic.

BY Steven Cherry, IEEE Spectrum, Fri, August 26, 2011
A new study suggests thoughts of romance can reduce college women’s interest in science and engineering

In the 1960s, when women first began enrolling at universities in record numbers, many people wondered: “Why weren’t more of them studying engineering?” Fifty years later, we’re still wondering. Only one in seven U.S. engineers is a woman. The so-called “engineering gender gap” is still a chasm.

And that’s not likely to change very quickly. The average college graduate nowadays is a woman—57 percent to 43—but when it comes to the so-called STEM fields, that’s science, technology, engineering, and math, women account for only 35 percent. And most of those are for life and physical sciences, not engineering or computer science.

It’s a problem perhaps best examined by psychologists, and examining it they are. And a new series of studies argues that—as clichéd as it sounds—maybe love really does have something to do with it.

An article based on the studies, will be published next month in the peer-reviewed journal, Personality and Social Psychology Bulletin.

My guest today is the paper’s lead author. Lora Park is an assistant professor of psychology at the University of Buffalo, in New York, and principal investigator at the Self and Motivation Lab there. She joins us by phone.A new study suggests thoughts of romance can reduce college women’s interest in science and engineering

Effects of Everyday Romantic Goal Pursuit on Women’s Attitudes Toward Math and Science

Abstract:
The present research examined the impact of everyday romantic goal strivings on women’s attitudes toward science, technology,engineering, and math (STEM). It was hypothesized that women may distance themselves from STEM when the goal to be romantically desirable is activated because pursuing intelligence goals in masculine domains (i.e., STEM) conflicts with pursuing romantic goals associated with traditional romantic scripts and gender norms. Consistent with hypotheses, women, but not men, who viewed images (Study 1) or overheard conversations (Studies 2a-2b) related to romantic goals reported less positive attitudes toward STEM and less preference for majoring in math/science compared to other disciplines. On days when women pursued romantic goals, the more romantic activities they engaged in and the more desirable they felt, but the fewer math activities they engaged in. Furthermore, women’s previous day romantic goal strivings predicted feeling more desirable but being less invested in math on the following day (Study 3).

Link to the paper: http://www.buffalo.edu/news/pdf/August11/ParkRomanticAttitudes.pdf

Automation without abstraction is like a bicycle without pedals

Automation is just transforming information from one format to another format, it won’t make the information any easier to work with. Abstraction drops irrelevant information and keeping only the useful information at the right layer. Abstraction can scale vertical, automation can only scale horizontally.

Design and Reuse, by David Murray

I’ve noticed recently that the word ‘automation’ can be used very loosely in the EDA industry as a presumption of productivity and quality. I’ve recenlly been working with some legacy customer flows on an IP integration process that was 100% ‘automated’ from an Excel sheet. This excel sheet was written to CSV text file which was then parsed with perl to create an RTL output. As the solution evolved however and the requirements grew more complex, another set of perl scripts were deployed which directly manipulated the RTL file. In fact this perl included some snippets of RTL code to insert into the output. So while technically the process was 100% automated, theis type of textmanipulation brought the level of abstraction lower even than the RTL level. I came across similar types of ‘automation’ in my previous life as a design engineers life, where automation was considered the ability to record keystrokes macros within a text editor. Again this automation was at a very granular and low level of abstraction and consisted of no more than creating repeatable, but not very reusable small steps. No matter the claimed level of automation of a process, a simple fact remains; automation without abstraction is like a bicycle without pedals.
A bicycle without pedals!

The Laufmaschine or ‘running machine’, a brilliant concept, was realized by German, Baron von Drais in 1817. Described as “A mechanical machine with two, in-line wheels and the ability to steer”, the Laufmaschine could get you from A to B in a more efficient fashion and it meant keeping both feet on the ground (and probably a new set of shoes every week). At initial trials, the laufmaschine was able to get running speeds at walking efficiency. This laufmaschine was also called a velocipede, meaning ‘fast foot’ as well as swiftwalker (a marketing term if there ever was one). Its goal was to make walking or running more efficient and it successfully achieved this.

In 1863, Frenchman Pierre Lallement modified a two-wheeler in Paris and attached pedals, forever changing the concept. The introduction of the pedal took the fast-walking to a new level . With the advent of gears, the efficiency of man travelling was catapulted way ahead of our counterparts in the animal kingdom. Man on a pedal-enabled bicycle was100 times more efficient than man walking. Man was now CYCLING!

So how does this relate to SoC realization and IP integration? As the number of connections required to assemble a system grew, manual connectivity was replaced with in-house (as well as outhouse!) scripting solutions without really changing the assembly concept. The scripts – be they Excel VBA, perl or python were performing low-level data manipulation rather than high level automation abstraction. There were still trying to deliver better walking efficiency.

These scripted solutions are essentially ‘swift-stitch’, or ‘veloci-wire-up’ style environments performing low-level connectivity manipulation. As the complexity inevitably increases, the levels of efficiency of scripting simply aren’t scaling. A new concept is needed for IP integration; a higher level of abstraction is needed to boost the SoC realization process.

So, what did we learn from the laufmaschine? With pedals, Mr Lallement found a way of synthesizing one motion into another, increasing efficiency by an order of magnitude in the process. Pedals were in fact a very small but highly significant change to the methodology – CYCLING was the result! We need the same paradigm in SoC realization where we replace adhoc IP stitching type of solutions and change to a new methodology called ‘weaving’.

Like pedals, ‘weaving’ doesn’t seem like a massive leap in innovation but it gives a quantum leap in efficiency. Weaver takes what these integration scripts were doing time and time again and abstracts it up to a specification language that defines how to integrate IPs and systems.
Weaving

The key to this solution is a simple but powerful IP integration specification language that allows engineers to specify a high level integration specification as a set of rules that define how IP is integrated. These rules contain powerful assembly instructions and link with formal port/interface definitions, such as IP-XACT.

This rule when run on a sub-system containing multiple IP instances will export any ports that have been formalized through attributes or IP-XACT. The selected ports will be created on the sub-system boundary and connected to the originating instances. It will also maintain any packaging metadata that was stored with the ports e.g. properties, IP-XACT interface mappings etc.

The export instruction has a range of options that control the intended port creation. Other instructions include, connect, tieoff, group/split (for hierarchical manipulation), etc. and work at both the port or interface level. An integration specification can therefore be considered a collection of these rules

How can such a small change in abstraction lead to massive efficiency gains?

A rule can be reused multiple times on many sub-systems and also on multiple projects. Therefore the reuse potential is huge. Also the design intent is very clear and concise and easy to understand review. In a sample peripheral sub-system, 3 rules (with 9 instructions) auto-generates 1434 lines of structural HDL code. Similarly at the top-level of a large chip, 21 rules (120 instructions) gives 11188 lines of HDL, an average of 96 lines of HDL code created, per instruction. (Much like 1 revolution of the pedals giving you 100m in distance!)

Specifications and Scripts

The specification language is easy to understand and familiar to people working in the domain . There are only a handful of instructions to learn. So what is the difference between specifications and scripts?

* Rules are executable, synthesizable specifications whereas scripts tend to be ad-hoc implementations.
* Specifications by their nature captures design intent and raise the design abstraction. The design intent can be very clear. Scripts are low level and design intent cannot be as clear.
* Specifications are more formalised and are more stable than the resulting implementation. Scripts tend to be very implementation specific and implementation sensitive.
* Rules are essentially specifications whilst scripts are code

Scripting will always play a role in design automation and should be considered the essential glue of a process. Scripts should handle corner cases, tweaks and nuances but because of their ad-hoc nature and its resulting instability and unpredictability, script should be kept to a minimum and not form the central part of an integration flow. Scripts offer flexibility and a way to get out of certain holes but long-term, strategic solutions require a more automated AND abstracted solution. Scripting gives a context of what you are trying to do with the data and because of this it provides a pointer as to where the automation is going, probably much like what went through the Frenchman’s mind when he envisaged pedals. He would probably not have come up with a bicycle without first seeing the original laufmaschine.

It is time to raise the level of abstraction and aim to finally become 100 times more efficient at the IP integration process.

How to explain what is computer engineering to 7th grade

My friend is an elementary school teacher. Her grade 7 class is having career day to understand different kinds of jobs and she asked me as a guest speaker. I am a toastmaster, so I thought how hard can it be to speak in front of 20 kids. I was wrong. It is quite hard to explain what is my job to the little kids. I cannot use difficult words or they won’t understands. Many technical, which terms seems very natural to me, are like Martian language to them.

I did came prepared, but I did not prepare enough. I did not think hard enough trying explain my job in very simple language. I printed some photos Gameboy and iPhone circuit board. They seems quite exciting seeing how a Gameboy looks like inside. I also brought a chips to show them, but I doubt they understand exactly what it does. At the end of the day, I think they sort of know computer engineers build computer chips and there are computer chips inside every electronic device. I bet they are totally lost when I try to explain how we make build a chip. I even used the word fabrication.

The little kids asked me some questions about my job. Most of them are pretty general questions, like how’s my work environment like, what kind of education I need, working hours, etc. When I said I work flexible hours, I can come into work leave any time I like and I can take breaks whenever I want, the little kids seem very excited. Then I explained a little more that my job is project base, which means I have work long hours when the deadline is getting close. I tried to use handing in homework as an analogy, I hope some of them will get it.

I like talking to little kids about engineering.  I feel I have done some good service to my profession.  I wonder did my words inspired any kid grow up to be an engineer.

Dropping standard

Every four moths, new co-op shows up in our company.  I don’t know whether is that I am getting old or it is really a fact.  I found that the standard of engineering students are getting worse and worse.

The first clue is the minimum grade in school to get a engineering school admission.  In the old days, you have to get over 90% in order to getting into the engineering school.  I heard that the admission average of engineering school is drop to 70% in the past few years.  It seems all the bright kids are flocked to study fiance and accounting.

The second clue comes in the computer knowledge of our co-ops students.  Newspaper says computer literancy is improving in Canada, but more people know how to use computer does mean they don’t how to use the computer better.  Many student only know how to use computer to surf the net, basic word processing and merely as a mean of communication and entertainment.  The general grow up with GUI seems totally clueless about the command prompt.  In the past, only those who loves into computer study computer, we know everything about the computer inside out.  Back then we don’t have computer classes, we just learn on our own by reading the manual.  Kids today are so used to spoon-fed computer knowledge, it seems reading the manual to learn has became a lost art.