I'm new to hardware prototyping and circuit design. Where do ardware engineers look for reliable circuits that would work for the first time of prototype?
I know this is a general question. I'm looking for advice instead of a specific answer.
I'm new to hardware prototyping and circuit design. Where do ardware engineers look for reliable circuits that would work for the first time of prototype?
I know this is a general question. I'm looking for advice instead of a specific answer.
where do HW engineers \$\color{red}{\text{look for}}\$ reliable circuits that would work for the first time of prototype
I've emphasized \$\color{red}{\text{look for}}\$ because I'm using it in a more general way than what the OP may have thought of.
So, I \$\color{red}{\text{look for}}\$ problems and solutions in my simulator....
To give the best chance possible to make a prototype work first time (maybe with a few value changes at worst) I use a simulation tool. I always use it and I always simulate then, when I'm happy, I don't bother with a bread-board prototype, I go straight to a 1st issue PCB.
This saves really quite a lot of time because you are forced head first into facing the problems of your design from the luxury of your desk. Do this first and your yield will improve. My estimation is this: -
More specifically, I never acquire components from flaky sources\$^1\$; I use proper dealerships selling recognized component brands and get a paper trail back to source. I want quality gear and that's the way to do it.
\$^1\$ - Flaky sources - peeBay, bang-bad, mali-express, shamazon etc..
The very first thing I do is work out exactly what I want to achieve. If I do understand the broad strokes of the topic, but not sufficiently well-versed in the details yet, then I spend time studying the topic until I can sit down and perform the work "by hand." Even in the most complex cases, that is always possible to do. Keep in mind that the human mind and theory existed long and far before electronics did. You should be able to figure it out with gears and cogs or even with sand and rocks, if necessary. At least, in principle.
Once you understand the topic and your goals well enough, then it is just a matter of using imagination to work out additional ways to achieve similar results. With several different approaches towards a goal, you can make some trade-off decisions and you are left with a smaller pile of ideas -- perhaps only one or two.
If there are remaining knowable unknowns -- things that you need to resolve in more detail before proceeding, those are pulled to the front and experimental design takes place in order to resolve them. These are sub-projects designed to turn the knowable unknowns into knowable knowns.
It may be the case, at this point, that you decide it is impossible. The project is aborted, then. (Until something new arrives in mind, anyway.)
Assuming it still seems feasible, there will still be things you don't know you don't know. So you spend a little time trying to imagine anything left over that you may have missed. If something arises, rinse and repeat. Otherwise, move on and hope that unexpected unknowns can be identified and successfully overcome if and when they arrive.
At this point, I'm in a position to examine prior work. I know what to look for and I know at least much of what to make of it, when I see it. I then think about what I see.
This is about the point where I start considering making a choice about which of the remaining ideas, and which of the implementations I've already examined, are more likely to get where I need to go. And I'm in a much better position to make those choices, by now.
Then I select an approach and spend still more time on it, both in theory first and then sitting down to make a prototype, having already divided it into sections that can be separately tested, with a notebook that provides me with my theoretical expectations before I sit down to make and test anything, so that I know what to expect and within what boundaries.
This is a vital step -- developing the expectations portion of the notebook. The reason is that if the results of experimentation match, you have some confidence in the process followed. If there are residuals that are not well explained, either the process itself was flawed (go back and re-check work product) or some new effect that needs to be tracked down is uncovered and exposed (more experimentation ahead to bring whatever it is into the knowable sphere, if possible.)
I think you can see a process, there. And it does NOT involve, at least not initially, "searching the web." That said, most things have been solved before in some fashion. So there is a point, very important, where the literature is examined to see what's been done, earlier. (Or your own memory from earlier experience.)
I'll leave it at that, for now.
Whether it is a discrete electronic circuit or FPGA "circuits".
I do re-use my older stuff, but I generally try to stay clear of foreign stuff that is unproven and/or which I have not understood.
It is not always avoidable to use foreign IP especially for deeper FPGA functions which would take too long for me to rebuild/understand. But the more experience I gain over the years, it becomes more and more likely.
Why ? At the end of the day, you always suffer. For me it is very preferable to suffer from my own mistakes, such as this prime recent example. That mistake was completely avoidable, if I had used a premade part instead of drawing my own symbols. But when contrasting this with the times that I might have used a wrong symbol while relying on premade parts, I would use my own stuff any day.