EE electroic engineer designer basics please

[johngreene]

What are 10 to 20 EE electronic designer "issues" or "common problems"?

If it was that simple I probably wouldn't have a job.

[markphaser]

I'm not saying its simple thats why its 10 to 20 things just to start with some common issues and common problems to list

[Sir H C]

Seljer is right

Sir H C why would EE designers need to know the rate of change of current going in and out of the cap,inducator,transistor,op-amp,mosfet,fet,tube? what information are they going to use or do with this information from knowing the rate of change or
"transconductance" of input/output and through the component?

If you don't have an intuitive feel for the circuits then all the math in the world won't help you.

I can look at an op-amp circuit and quickly tell the pertinent details, # of stages, folded or not, and a lot more.  Knowing these equations (I use them on a daily basis) among others gets you solving problems a lot faster than if you have to shotgun it with the simulator.  If you don't have a "feel" for the design you will be slower and, bluntly put, suck.

johngreene-

There was a brilliant book that I got years back on digital design for the 8088 processor.  I forget the writer, but he was great.  He had a ton of maxims that were great for the engineer.  He opened his book with reference to Camus' "The Plague" where one character is working on the "perfect" novel.  He has been toiling away for 10 or so years (I ended up reading the book because of this guy's comments, and it is great to read) and is still on the first chapter.  This is the difference between university papers in the red rag and real-world engineers.  I have to design to specifications on time and in budget.  I don't have to exceed by a huge margin, and often you "save" those really killer ideas for the follow-on.

I think the book above is "The 8086/8088 Primer: An Introduction to Their Architecture, System Design, and Programming (Paperback) "  by Stephen Morse.  It is old, but I have to find more by this guy, he is an engineer's engineer.

[mojotron]

Hmmm, now I'm not that sure of what this thread is about???

...
But you need to define 'done'.

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

One time, a long time ago , I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

[markphaser]

Sir HC so why do u use those formulas what for? and why tho?

[Doug_H]

Markphaser,

Re. your first post: Read chapter 12 of the Art of Electronics (ISBN 0-521-37095-7).

[R.G.]

Gentlemen - you are feeding the markphaser.

[Doug_H]

I can't possibly boil down electrical engineering into a 10-20 point bullet list (which seems to be markphaser's preferred method of communication) but I can give him some reading material. Of course, he probably won't read it or even acknowledge that someone took the time to give him a nice nugget of info, since it requires some effort on his part. He'll just keep broadcasting his endless questions as long as others keep responding to his brainpicking in nauseating detail.

IMO it's better to point the way for someone to find info for themselves and learn than to just spoon-feed them, but whatever... I gave up a long time ago on trying to understand the paint-by-number mentality in this forum- first in circuits, now apparently, in education too. In the end it makes no matter to me. I added my 2 cents and can now ignore this thread as easily as I do others.

[johngreene]

Hmmm, now I'm not that sure of what this thread is about???

...
But you need to define 'done'.

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

One time, a long time ago , I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

I find that the design process for ASICs tends to be very structured because of the development systems used. They kind of force the function. Where I often see the breakdown is at the system or even board level. People don't review specs, don't participate in meetings, so you don't find out until you are well into it that something isn't right or has been overlooked because someone just now had to get started writing software for it, designing an interface for it, or some other activity that involves them and they finally took a good look at the spec.

--john

[markphaser]

the Art of Electronics (ISBN 0-521-37095-7).
Read chapter 12 , is chapter 12 about EE design issues Doug H?

What other books are about EE design issues and EE design common problems please?

[Doug_H]

Chap 12 covers construction techniques, packaging, pcb layout, etc which addresses your 1st post.

[Sir H C]

Hmmm, now I'm not that sure of what this thread is about???

...
But you need to define 'done'.

What I see over and over again, is engineers (we are talking about electronic engineering here and not hobby enthusiast) are always thinking about the design and as it progresses, and test data is collected, they come up with better ways of doing it. Continuously. So it is the common problem of wanting to make the design 'perfect' which is a never-ending process. So, an engineer that is capable of meeting milestones knows when the design is 'good enough' to satisfy the requirements and resist the temptation to make it even better when in the end, it will never be noticed.

I think this happens a lot when you don't have solid, specific, requirements that scope the design. If you have a schedule and a set of requirements that don't change, you will know when you are done.

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

One time, a long time ago , I was on a team designing and laying-out a segmentation/reassembly ASIC for a custom serial interface on a PC add-in card. We did not really have solid direction wrt schedule/requirements for this thing and we spent a lot of time re-doing traces on every layer, making that thing extremely compact, reducing timing skews, chasing down every DRC violation... so that we could put it into several different pin packages and it should work. As soon as we thought we got it done, one of us realized that there was some header bits that were ignored in our design, that were really important if we ever wanted to sniff/sample the wire... As soon as we thought it was OK (we did not need to redirect packets and dropping packets that were not addressed to the unit was OK) we get a change in requirements that it needed to handle those header bits - Yikes!!!  Bad design, bad process, bad requirements - but one heck of a layout if you need a 1/16thW 13 ohm resistor!

I find that the design process for ASICs tends to be very structured because of the development systems used. They kind of force the function. Where I often see the breakdown is at the system or even board level. People don't review specs, don't participate in meetings, so you don't find out until you are well into it that something isn't right or has been overlooked because someone just now had to get started writing software for it, designing an interface for it, or some other activity that involves them and they finally took a good look at the spec.

--john

I have done several ASIC cycles where specs were thown in very late in the game.  Did a motor controller where after the circuit design review they decided to add a new mode of operation.  That sucked. 

[Paul Perry (Frostwave)]

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

This has a LOT of relevance to stompboxing... the best time to 'mod' the circuit is BEFORE you lay it out!
As for the 'moving target' specs... the only upside is, if you have to redo a project, you can use a few things that you learnt the first time.... I notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that

[R.G.]

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

That's one sure way to build in disasters. Another name for that is code-to-market-date or feature-to-whim design.

I notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that

At one time I managed a software development department responsible for maintenance and new releases of a custom Unix kernel. It became obvious to us that you should spend 80% of your schedule time designing, specifying and reviewing. 10% went to coding, and 10% to testing. We looked at the schedule time available, took our history on code production and could tell within a week when the code would be done. We never missed a ship date. But the long design was the important part.

If you write out in clean, clear prose what is to happen, and document interfaces clearly, you save yourself untold misery in final test.

The other key is the no one ever puts in a single line of code that is not reviewed by another person. Not even the most senior, highly respected coder you have.

[johngreene]

Aha, rarely have I ever seen a solid, specific, requirement spec for a design. Even at this "unamed" Globally established company I worked for, they were re-writing the specification document after the product was 'done' per the previous spec.

That's one sure way to build in disasters. Another name for that is code-to-market-date or feature-to-whim design.

I've heard it called "Feature-creep" http://searchcio.techtarget.com/sDefinition/0,,sid19_gci860179,00.html

I notice that in software, if you FULLY specify what you want, the coding goes 100 times faster, funny that

At one time I managed a software development department responsible for maintenance and new releases of a custom Unix kernel. It became obvious to us that you should spend 80% of your schedule time designing, specifying and reviewing. 10% went to coding, and 10% to testing. We looked at the schedule time available, took our history on code production and could tell within a week when the code would be done. We never missed a ship date. But the long design was the important part.

If you write out in clean, clear prose what is to happen, and document interfaces clearly, you save yourself untold misery in final test.

The other key is the no one ever puts in a single line of code that is not reviewed by another person. Not even the most senior, highly respected coder you have.

Sounds like a large, well-funded company. I've only spent 1/3 of my career at such places and will agree. The other 2/3 of the time I've spent in small commercial startups and it is always a moving target. People want you to put 'something' together so they can see it, then list all the things they hate about it and tell you to do it again. After 4 or 5 rounds of that, they start complaining about it taking too long. Then it's "We need it in 2 months for the 'blah blah' show". You work nights and weekends trying to get it all working in time. They get some feedback from some big-mouth at the show who says "if it does -this- we would order 1000s of these", so the whole things starts over. Naturally it was all fluff and they don't buy it even though they caused the product to morph into something it was never intended to be. So now it is months behind schedule, many times over budget, and it is something that noone wants.

It's all marketing's fault. 

--john

[R.G.]

A sure way to stop that stuff is to require whomever is requesting extra features or added function to write down, date and sign the instructions to do it, along with the financial authorization to pay for the changes.

Or at least it would be if they were dumb enough to actually write it down. Organizational political smarts are not equally distributed. 

I was extruded through formal project management training as a condition of continued employment, and found I liked it. One facet of this training is that there is no such thing as a free lunch. Each time you change something, it costs money and time. And a clear recognition of that is tough to get a loosey-goosey organization to understand.

I PM'd a couple of product releases in the several $10M class, piddly things by that organization's standards. But it was a beautiful and self-actualizing thing to do on the couple of occasions when I was able to ask a VP who had just dictated a product change "How would you like to pay for that?"

The question is just as, if not more appropriate for a small, nimble organization. If your bosses were REALLY good, they would say "How much time and money does it add to the schedule to put in X feature starting in three days when you have had time to evaluate it, and how much does that evaluation process cost me?" Both costs may or may not be considerable, but it's sure that they're not free.

One of the primary values of formal PM is that there are techniques for you to figure out early in the program that you will not make schedule or budget, and estimate by how much. In some cases, you can say with certainty that you are already dead with as little as 20% of schedule time past and 20% of money spent.  It's hard to make a gut-feeling, seat-of-the-pants entrepreneur believe that, though.

Oh, yeah, markphaser. You need to know all this too. Otherwise you'll be fired if you do get an EE job.

[markphaser]

R.G is one of those EE 4.0 graduate degree students that get a job as a R&D and the real EE designer sits little bratty R.G in front of a Black box with 3 or 4 wire/terminals and R.G just stares at it like a deer looking at a car's headlights coming at him. The real EE designer comes back every 1hour is everything ok R.G yes yes doesn't have anyones hand to have to hold on to. So i figured R.G is really a R&D graduate with a job screwing light bulds around the R&D department claiming he is a R&D engineer or EE but really just a hobbyist little bratty that his daddy sent him to upper divisions schools all paid for spoon feeding him but don't forget R.G not everyone gets the same fold of cards are u did.

[dr]

...............?troll..............

[R.G.]

troll

No, he's just irritated. He gets downright belligerent over on HC where he uses walters9515 for an ID.

I do wish there was some way I could help him understand some basics, but I don't think it can be done. And for the life of me I wish I could simply stop responding to this stuff. But it seems to trigger me to try to keep the information straight for the beginners. The correct response to all of this is simply no response at all. I try, but am not always successful.

walters/markphaser/brent/brentwalters/walters9515 is really unusual in that the words appear to get picked up, but there is no understanding that ever gets picked up with them. It is very much like the difference between optical character scanning and reading. OCR turns a picture into letters. Reading turns a picture into knowledge.

The longer and more involved the explanations mp is given, the more questions come back; and the more a complete lack of understanding of the context and meaning behind the words become obvious.

And markphaser, I was not being snide or snotty to you. I was telling you the literal truth. These days, an EE who has no concept of project management is going to have a very difficult time holding on to a good job, and will certainly not get ahead in the organization. It's not enough to know the equations and real world practice of electronics. You have to learn the economics of engineering design, the management and scheduling of projects, and the politics of  your organization.

I have a good book for you to find and read. Go look up and read the PMBOK, the Project Management Body of Knowledge. It'll be very enlightening.

[Sir H C]

The difference I found between software and hardware is that you have to stop feature creep much earlier in hardware.  Since the top guys know you can always "recompile" the software up until the release day, they think they can change the specs until that point.  Since you have to send out for masks and the like, test jigs, and packaging for hardware, it is harder to keep the changes coming.  Still we add extra transistors and gates on the ICs in case something goes awry.