The guest author of this blog is Michael Hermann, VP and General Manager from Nuvation.
At Nuvation we began using the term “Franken-systems” many years ago — maybe back in the late 90s? Nobody recalls the exact moment in time. Somebody probably blurted it out on seeing a lab setup with wires running all over between development boards and perfboard circuit prototypes. We’ve certainly seen the term other places as well, so we don’t know if we came up with it first. Doubtful we did, but we do like the term. It’s a concept that customers, vendors, and new colleagues all seem to understand.
A Franken-system refers to a collection of development boards for processors, FPGAs, sensors, and the like, wired together to create a very non-form-factor early prototype in order to facilitate software and logic development. Sometimes we’ll make lab prototypes for certain circuits, sometimes we’ll have custom cables made, and sometimes we’ll go so far as to fabricate interposer cards to connect boards that have complicated interfaces, lots of connections, or high-speed considerations.
Some Franken-systems are “quick and dirty” while others can look quite well put together — the latter usually being mounted on a surface of some kind and often covered with polycarbonate to avoid inadvertent hands. There’s certainly a range to these setups, but they all have a common theme: enabling on-device software and logic testing before first full prototypes are available.
A Franken-system can be assembled and put into a developer’s hands in mere days, compared with weeks or months it may take before the full prototype is available, providing a setup on which to begin testing code and logic before actual hardware is developed. Simulators and virtualization can do great things and be very helpful, but ultimately, until you’re working on the actual target chip, you’re always at the mercy of how well the simulator emulated it. This is particularly important for processors and hardened IP blocks in FPGAs. When you’re running on that development board you’re learning a lot about the processor — how the programming flow works, how the debugger interface works, how the boot loader works, how the I/O multiplexing works, and so on. Chip flaws will be exposed. Library limitations will be found earlier, and in general you’re efficiently de-risking your project.
Looking beyond the processor itself is where you get into even more important results. On a good Franken-system your development board will now be interfaced to as many of the other target chips, devices, and software as the hardware and software team can put together. Image sensors, ADCs, DACs, sensors, memories, transceivers, etc. — the more of these things that you can get into your Franken-system the better. The upside rapidly outstrips the time and effort required to create even an elaborate Franken-system. Timing issues, driver problems, datasheet errors, register problems, subtle limitations — these things all can come up much earlier in the project process.
While the software/logic team works with the Franken-system they need to be ever-vigilant for the “discovered problems” that will impact the actual hardware design taking place in parallel. This is where one of the most profound upsides comes in; even a single somewhat-serious issue found through testing on the Franken-system, which allows for that issue to be resolved before the hardware prototype design is complete, pays for this activity.
For example, imagine a chip-bug found in a transceiver that if unresolved would have required a prototype re-spin. And it doesn’t have to be a bug in the chip. A more common scenario is finding a subtle limitation in how a new device can be used that often only shows up in actual testing — on the Franken-system. Avoiding that re-spin saves you days or weeks of effort, and likely weeks of schedule, on top of the expense of a re-spin. That’s why Franken-systems are a key part of Nuvation’s First-Time-Right hardware design methodology.
Of course there are limits to the Franken-system approach. For example, you won’t be able to create a setup for some parts of the hardware design. For some parts you can’t get access to a development board (that issue can even apply to the main processor or FPGA, which should encourage you to look for a different processor); for some parts the wiring is impractical or too high-speed; and sometimes the processor/FPGA variant you’re using might not even have a development board in existence. These limits are drastically outweighed by the benefits, however, and are not sufficient reasons to forego the advantages.
Thank You @Steve for this interesting blog, but i am little confused, is Franken system really helpful, apart from this its limitations is something which cannot be ignored easily.
@samicksha—Franken-Systems are customized boards or systems of electronics that a company puts together for a particular need that they have. It is very helpful in cases where supplier demo boards or evaluation boards are just not enough for some system you are trying to prototype, so you customize or even modify existing boards.
In Mary Shelley's :Frankenstein” story, the monster is put together with various body parts from many different people—that is the same for Franken-Systems—they have many boards from many manufacturers and even customized boards all linked together for a design purpose
Franken systems help in establishing “proof of principle”. You need to test whether your logic works. You do not intend to test if the logic works always and at all conditions. A first logical step to understand if the idea works. Then you concentrate on bringing in robustness and reliability with custom design board and modules to the desired specs.
I am not sure if i am really right, but my thought about demo boards is little different here, they work comparitively well in testing environment but in practical or materialized environment performance differs.
@samicksha—you are correct that demo boards work comparitively well in testing environment but in practical or materialized environment performance differs.
However, the goal here is to create a very non-form-factor early prototype in order to facilitate software and logic development.
“n Mary Shelley's :Frankenstein” story, the monster is put together with various body parts from many different people—that is the same for Franken-Systems—they have many boards from many manufacturers and even customized boards all linked together for a design purpose”
@Steve: I had heard of Franken-Systems and I had also read Frankenstein but didn't know the word was derived from the novel. Very creative adaptation of the word to match with the concept 🙂
“they work comparitively well in testing environment but in practical or materialized environment performance differs.”
@Samicksha: In no circumstances is the test environment exactly the same as the actual environment. However, the idea of having a test environment is to ease the process of designing so that the mistakes can be made and rectified easily. I do think that the benefits of using a test environment or systems like Franken-systems outweigh their limitations.
@tzubair—creative credits go to Nuvation—very clever. They are a well-rounded and talented group of engineers. They make enginerring fun!
100% agree with you. Test board will never work as the Practical environment. It will allow you to test whether your basic logic works, if so, other related areas and concerns need to be looked at separately to make things perfect in normal working environment.. Test boards will provide the opportunity to identity any major failures at a early stage, but you will always have some trouble shooting later to make things perfect.
@ue2014: Yes true you do need to practice on test boards but they real test comes out when it goes live because test boards are limited and the testing too will get limited but when it goes live, the scenarios that it gets exposed to are very high.
@steve: Well it should be made fun because if not the mind will not be flexible to think out of the box.
dassa.an this is true for each and every testing processors. New iPhone 6 bending problem is a good example for this.
Good one dassa.sn, I also believe an fun will lead to think out of the box
Test boards are made for generic development purposes. In order to get them working for a particular environment or application, always it is necessary to do some customization. There are instances where some development boards get adapted in principle in some applications as the application engineer would have had such target applications in mind while designing.
Testing are done based on conditions that we think what could be the circumstance would be like in real conditions. So there is always a high possibility in changing things without our intention. So we always need to be ready for such challenges. Even Toyota has recalled some HYBRID vehicles to rectify some issues even after a production of so many testing. So it's a natural thing that anyone experience and we have to face it. But testing gives us a very good opportunity to minimize major errors.
@Ranasinghe: Mate very true and I too feel that making work more interesting will get the best out of you. That's the best point where your mind is being put into a relaxed mode
“They are a well-rounded and talented group of engineers. They make enginerring fun!”
@Steve: This makes me wish that other engineering companies would learn something from them and try to make their environment fun too. I wonder if we really need to make the engineers have some kind of sessions on how to make engineering fun so that they're able to pass this on to the companies they join.
“Test boards will provide the opportunity to identity any major failures at a early stage, but you will always have some trouble shooting later to make things perfect”
@ue2014: I think it's also important that the implementation from the test board to the actual circuit is correct. You may have a perfectly working circuit on a test board but if it's not implemented correctly in the production environment the failure may still arise.
@tzubair—As engineers we should all enjoy and have fun with what we do. Nuvations does some amazing design work, but they have learned that fun and enjoyment is a part of engineering as well
tzabuir – yes, true. We need to be very much careful about the both environments. What we use for Testing board has to be pretty much similar to the real environment. If not, failures may still occur. Since we have a clear idea about what we are gonna test and what kind of environment that this is going to be operated, we could always try to bring the real environment to the test board as much as possible.
And also vasanjk I believe that, by having a same or the stimulated environment, where the real product is going to use will increase the accuracy of the development.
Exactly ue2014, there won't be a 100% accurate product in the first attempt. Everyone have to learn from the experience. Who thought that there will be a defect in apple iPhone 6.
ue2014 , there is a technique that I have tried, which is invite some other colleague who are not in the project to test the thing, cause that we are in the same mindset with in a project. That will help me to get across others mind sets.
@Ranasinghe: Yes by doing that way you will be able to get a honest opinion about the functionality since that user will be using it and seeing it as a complete outsider
@Ranasinghe: I agree with you on the factor of nothing will be 100% perfect. But what's the so called defect you are mentioning on iPhone 6 ?
@Ranasinghe: Is it possible in this scenario ? If that is possible then it would be great and will definitely help to boost the sales levels
The late Bob Pease gave me a ride in his VW twelve or fifteen years ago. Above the front passenger's knees was a loose, roughly spherical, self-supporting assembly of components and wires, some insulated, some not, which I believe he was using to measure temperature and airflow (and possibly other stuff – we were talking about Indian cooking and did not discuss the circuit). From his reply to a jibe I made sometime later I believe that the mess had survived intact for some months, despite passengers getting in and out around it.
There's a similar jungle below the roof of my woodshed controlling the LED illumination and the solar PV charging of its battery – but I do have a PCB designed, though not actually etched yet, to replace it
These Franken-systems are refreshing, simply because they go in the opposite direction of overly compact, inaccessible, and unreparable packaging. Car (and truck) engines have become increasingly difficult to work on under the hood. And electronics in some areas is following in this same direction.
I would like to see electronic instruments and other products designed so that they are easy to access. (I am working on open-source measurement instruments that are maximally accessible at innovatia.com.) Minimal packaging, maximum electronics for products not unduly exposed to the environment would decrease their cost and open them for quick access. Earlier instruments were designed this way: the ESI 253 Z meter and Keithley 2000 DMM are examples. They are in metal enclosures which are easy to remove, without a PhD in Chinese puzzle-solving. Once in, the electronics is emminently probeable and removable.
@ D Feucht—well said Dennis! Spoken like an “engineer's engineer”
is Franken system really helpful, apart from this its limitations is something which cannot be ignored easily.
@Samicksha, I think Franken systems are helpful to build prototype and test the initial prototypes. Its better to test the product on prototypes than to build the product from scratch.
Franken systems help in establishing “proof of principle”.
@vasanjk, true. Its always good to check for “Proof of principle” because sometimes building prototype helps us to raise funds needed for the actual product development.
they work comparitively well in testing environment but in practical or materialized environment performance differs.
@samicksha, true but you dont expect prototype to exactly match your final product performance. You need to build the prototype to show that the concept can be implemented using actual hardware.
there is a technique that I have tried, which is invite some other colleague who are not in the project to test the thing, cause that we are in the same mindset with in a project.
@Ranasinghe, that is a very good idea. But its always better if that person is already aware about the modules being worked on else it would be very hard for him to first understand the module and then test it.
Who thought that there will be a defect in apple iPhone 6.
@Ranasinghe, no one expected there will be defect in Apple iPhone 6. Because of this bug people are avoiding buying iphone 6 and are instead buying iphone 5s. Price of iphone 5s have gone up after this bug was found in iphone 6.
yalanand
yes. Most research scholars use these for proving theories for their theses. Labview kind of software also help in such proof of principle or concept exercises by speeding up things in the software side.
Labview kind of software also help in such proof of principle or concept exercises by speeding up things in the software side.
@vasanjk, I think Labview software is National Instruments software. Do you know any other tools which are used for such tasks ?
Bending of the phone with a small pressure and cracking the phone. You can find more on the net.
chirshadblog, this will more help to identify the ways of errors happen by the users and this can be done in a various ways.
yalanand true briefing can be done before it begins. But make sure that not to tell the testing or the trying steps.
I have to agree your point @yalanand, but if it is not matching final product performance atleast it should suffice the requirement without any resistance, i.e. withour creating service impact.
I have to agree your point @yalanand, but if it is not matching final product performance atleast it should suffice the requirement without any resistance, i.e. withour creating service impact.
SunitaT Another similar visual programming software is Flowstone. It is also nice but mostly targeted towards robotics and audio domains. Quite easy and visually attractive. I don't know if it has all features of Labview.