Archive for February, 2011

Engineer Barbie

Tuesday, February 8th, 2011

From an IEEE article: Preparing Barbie for a High-Tech Career
[Mattel] let the public vote online in January 2009 on Barbie’s next career in its “I Can Be…” series, which aims to acquaint children with a variety of professions. As more than 600 000 votes poured in, Computer Engineer Barbie took a commanding lead over the other choices, which included environmentalist, architect, and surgeon.

Any publicity is good publicity, so I appreciate the efforts of the IEEE member who promoted this.  If Barbie is getting new professions, engineering should be one of them.

If they were going for realism, they could have given her lighted magnifying goggles and a nice button-down short-sleeve shirt with a caliper and tweaker stuffed in the pocket.  The promotional pictures should have her looking down, not right at the viewers eyes.  I do like the narrow glasses, though, which allow her to look over them for reading markings on parts without removing them.  They could also do a product placement partnership with Pepsi by giving her a Mountain Dew.

My vote for Barbie’s next job would be for her to retire and become an historical relic.  Barbie is a goofy toy to begin with, but juxtaposing her with real professions, esp a male-dominated one, make the dolls seem even goofier.  It seems like a toy that was offensive a generation ago and is now just a joke.

Invalid Altera FPGA MSEL Configuration Causes Big Trouble

Sunday, February 6th, 2011

A recent board I designed used an Altera Cyclone VI FPGA.  This FPGA’s configuration scheme is set by the value presented to the part’s MSEL lines.

There is a table showing how to strap these lines for each configuration scheme.
Configuration Schemes for Cyclone IV E Devices

When I first tried to bring up my board, I had these lines tied in a way that would have been defined for the GX version of this part, but not the E version that I was using.  When I tried to connect by JTAG, I could observe lots of traffic on the JTAG lines, but the utility gave me the conf_done failed to go high message, which from what I can tell means almost anything that prevents communication with the FPGA.  The FPGA held various I/O lines high or low without apparent order. Within a single bank, some lines would be weakly pulled up, some lines would be high or low, and some would be at intermediate values.  I put resistors on the lines that were high or low and found a 100 ohm resistor would usually pull them most of the way up or down but not all the way.  The way so many lines were pulled up or down made me think that I had a footprint error, major soldering defects, or some kind of fabrication error allowing planes to touch some of the signal vias.

One of the lines being pulled low was my processor’s reset line.  (Maybe it was a bad idea to connect it to the FPGA, but I had spare pins so I went to town connecting nets that I didn’t plan to use on the FPGA.)  I couldn’t cut the line because it ran on an internal layer the whole way.  I ended up removing the processor, thinking some kind of error with the processor was causing its reset line to be held low.  I was disappointed to discover that the line was still being pulled low just as strong.  I was considering removing the FPGA too when I discovered the MSEL error.

After fixing MSEL everything amazingly worked.  The MSEL line is the only jumper wire on the whole board now.

The FPGA datasheet says the MSEL lines must be tied directly (not through resistors or driven by another device) to V[CCA] (not to the I/O voltage).  After this, I will always follow any rules related to MSEL lines to the letter.