The problem is that after a few years the toolchain used to develop the old project won't even open on the new PC.
How do you modify/recompile a project after many years?
- A laptop for each project?
Don't laugh, there was a dude working for the national power grid, and he had a double door heavy metal locker full of shelves, and all shelves were full of laptop bags, all nicely labeled. One laptop and its cables for each industrial equipment used in their installations. Those laptops were never updated, upgraded or connected online. TBH at first we all thought the dude was crazy, but it's the best and safest method I've seen so far, since industrial equipment tend to have a lifetime of many decades. - Virtual machines?
- Docker?
- Something else?
Ooohhhh a subject near and dear to my heart because I have been *burnt* by this *SOOOO* many times ....
I have been tossing the around the idea of writing an article on this because this is a real ugly problem and one that I personally deal with far too regularly. I haven't done so to date because it personally gets me so angry and irate and every time I start .. I start frothing at the mouth as it is something that I personally can do very little to change.
That said ... lets see if I can answer in some way the crux the problem.
There are a number of separate, but very related problems with this.
>Physical hardware Devices
>Logical Software
Physical hardware DevicesFor physical hardware devices where you need a physical hardware ... that is a bit of a challenge. I've seen sites which use laptops kept in storage for this purpose. I've also seen what happens when said laptops get dragged out after 10 years of non-use only to find that they no longer power up.
For this one ... I don't have a good answer. Biggest issue I've had to deal with to date is software which has physical security keys that require parallel port dongles. These are a right and royal pain in the arse and a USB-Parallel converter usually doesn't cut it (unfortunately).
If a device is to be put into storage like this, make sure it is imaged before you do so, the image is checksummed and that you periodically power the device up so that you can be assured that it is still good. The last thing you need is to have to go racing for the laptop at a critical point only find that it doesn't work ....
This begins what we in the industry like to say is the:
Beginnings of a bad day (Tm) ....
Logical SoftwareSoftware has it's own subset of problems ...
#1. Software OS support. If the software you use will only run on Windows 95, Windows NT/2000/2003/XP and so on then keeping a VM of the supported OS is insanely helpful. I deal with this with a device programmer that I have which has drivers that will *ONLY* work on XP. Windows 7, 8 and so on simply won't allow it to work. My options ... zip, zilch .. nada... so I'm stuck with a device programmer that can *ONLY* work with XP (vendor has long ceased to exist).
For this particular problem, VMs are a godsend. Whether you are using VMware (workstation, fusions, etc), Parallels, DOSBOX, etc ... you get the idea. They can allow you to get around this particular sticking problem. In my day job, I spend a large chunk of my time in a DOS VM that runs PALASM ... 'nuff said ...
#2. Time locked icensing. Some software has time locked licenses. PRIME offenders in this category are the PLD vendors (Altera, Lattice, Xilinx, etc) which insist on shipping their wares with LMgrd abomination. This means that even if you keep a VM with the software (and a OS that is supported) in VM, the moment you power it on ... guess what ... you are *HOOPED*. It won't run as the software is then locked. In some cases you can sort of fool it by setting a VM date to a date in the past, but that is just plain clunky.
An even *WORSE* situation is when you come in after the fact and you have no working image to start from. Then you have to acquire the software and license ... and if you can't ... well ... to put it bluntly ... you're 100% screwed. I have personally been on the sharp end of this stick with this one from products from both Lattice and Cypress. I reserve a particular hatred of the MBAs who dreamt up such levels of barstardry ... no really I do. If ever there was a reason to have the MBAs of the world (along with their legal advisers) lined against a wall and shot ... well .. this would be it.
In all though, there really isn't a lot that you can do for this particular case.
#3. Data "locking" because of above. In most cases, design files, etc can typically be preserved and/or exported. When you have software that stores its data in a encrypted form that can't be exported or read because of the #2 above ... then that is when I totally loose it. Unfortunately this is a particular level of EVIL that *DOES* happen ...
Only option for this particular problem is that whenever you have a design that is pretty much "complete" ... it really should be "exported" into a common digital form (a PDF at the least) and where possible, at the very least an analog image (i.e. a printout) should be produced as well.
A schematic printout is 100% better than *NOTHING* ... reverse engineering a control board after the fact because the files are locked up in a proprietary format because the original designer did it that way is no fun I can tell you.
#4. Cloud based barstardry. When your software is both time locked and also cloud locked, you are even more screwed than the above. In that case, if the vendor goes broke or they won't support your old tool, congrats ... you are 100% screwed and you are also screwing the poor barstard who has to come in afterwards to deal with the mess left behind.
In regard this particular issue, I will say this up front and right to the point now, no matter who you are, or who you work for ...
IF YOU USE A CLOUD BASED EDA TOOL FOR SOMETHING THAT IS TO BE SUPPORTED INTO THE FUTURE ...YOU ARE AN IDIOT!For the above, just like in problem #3, keep a printout. Scan it if you have to so that you have at least a digital copy as well (if you can't print and/or export to PDF or something else equally readable).
SummarySo .. what *CAN* be done? Well ... in truth .. for some things ... not really a lot. Ultimately all of these companies only answer to the Almighty Dollar ...
If people were to stop *SPENDING* money on such organisations who product products that have biblically awful EDA software licensing constraints, then they would stop doing it.
Ultimately using open source tools in the only real way that you could really assure yourself that your design will be maintainable into the future.
The problem at this stage is that there is very few options though.
In the SCHEMATIC and board LAYOUT space ... KiCAD and a few other open source products are fast becoming viable alternatives to the level of barstardry that the likes of Mentor, Altium and Autodesk would like to subject us to.
In the PLD area though ... the pickings are a hell of a lot worse. There really isn't far too many options if you want to take some Verilog and/or VHDL and synthesise that into silicon. Most of the physical device vendors lock their products with either their own software, or software sub-licensed from others and in most part ... their software licensing is pretty bloody awful.
I would be *WONDERFUL* if we could say take iVerilog and then have a synthesis module for it that allows us to target all of the various CPLDs and FPGAs on the market ... but ... that isn't going to happen in the near future. Even for long since EOL products, the vendors aren't releasing the source code for their toolchains so basically when they EOL their chip ... you are still screwed to a greater to lesser degree.
It would be wonderful if they "did" open source their toolchains for EOL products ... but ... they don't, and realistically, I can't see them changing unless they were forced to by legislation.
It's a sad fact of life but typically most designers don't have to look after and support their creations in 10 years time, so they ultimately don't give a rats arse about what happens in regard to availability of the toolchain that they use when they create it in the beginning. This is something that I would dearly *LOVE* to change in the industry.
... and on that note ... I'll get off my high horse, put my claws away and try to calm down with a nice cup of tea ...
/BGM