PLD Dev Software - MachXL 6.2 - MODERATION REVIEW WILL BE REQUIRED!!!

[bgm]

Hokay ... this is a replay on a problem that I ran into last year, which I never got a "good" solution for but did wind up using a working around through the use of the ancient DOS MACHXL software. 

Why this has recently come up *again* is that I need to do some serous re-engineering of a old school PLDs (technically a CPLD but I digress), and I need to get hold of both software and license codes for the MACHXL 6.2 software. 

Now ... I will say this right up front ... the software I am hunting for is proprietary, *LICENSED* software ... and under any other circumstance, such a request in a general forum *SHOULD* invoke the wrath of the moderator ... but this is I think a very special case ... and to this end I am going to attach *some* of the correspondence that I had with Lattice on this subject then. 

Put simply, I need a way of creating Verilog or VHDL that I can use to target a MACH210 and MACH220 PLD.  Changing the parts out just *isn't* an option (don't ask). 

I really don't want to have to re-develop the alternate solution in PALASM (I will if I have to ... but I really don't *want* to .. I did the last lot of modifications by using PALASM but a larger re-write ... yeah ... don't go there). 

Dave ... if you feel that this probably shouldn't be dealt with on the forum as it may wind up getting you into trouble, then please, by all means, let me know and zap the post and we'll talk offline on this. 

Laugh, cry, or just shake your head.  Either way, take your pick. 

It does however once again raise a point that I made on the EDA forums last year regarding software for working with the various PLDs (I didn't start the thread, but I took one of the moderators to task when someone was rapped over the knuckles for asking pretty much the same question that I'm asking here ... and still got no real solution).  If you are interested in the historical thread, here is the link (http://www.edaboard.com/thread341295.html). 

---> First Sample Message <---
On 13 Oct 2015, at 9:52 pm, techsupport@lscc.com wrote:

If you wish to reply to this email; click reply and send in your reply only in simple text format to techsupport@lscc.com. Please do not modify the Subject line of this email, do not edit the original content in this email. The mail response program will not be able to update the response in the case. If any message size including attachment exceeds more than 4MB, there will be a delay in getting the attachment added to the case [E18].
____________________________________________________________________________

Hi Brendon,
I have confirmed with our lic admin that we are not able to generate a full license for this software any more.
Sorry for the inconvenience.


“Inconvenience” … seriously.  <fx: face palm>

Ok … so MachXL 6.x is now out because we can’t generate license codes … so … where to from here?  I am open to suggestions at this point ….

CUBEL?  PALASM?  So far the best I’ve found that works so far is the DOS MACHXL software which is … how should I say … “challenging” to work work with (for more reasons than you can shake a stick at). 

I had toyed with the idea of replacing the part but when I looked into it, that isn’t real feasible for a number of reasons. 


/BGM
---> END First Attached Message <---

After a *large* number of ever decreasing useful messages which basically deteriorated into them just sending me the actual notifications regarding that these parts had been discontinued (which is about as useless as you can imagine - I already *know* that), I finally send them the following (yes ... I was *massively* cranky at that time). 


---> FINAL REPLY <---
On 14 Oct 2015, at 7:19 pm, techsupport@lscc.com wrote:

____________________________________________________________________________
Hi Brendon,
We stopped shipping these devices almost 15 years back. The last date for ordering this was sometime in 2001.
http://www.latticesemi.com/view_document?document_id=3188
So, I'm sorry but there is not much we can do in terms of continuing to support these devices and softwares.


I wasn’t *asking* to purchase a discontinued device, or for that matter to solve world hunger.  I was merely after something that *should* have been *well* with the reach and capability of the manufacturer. 

You’re a technology company and you’re telling me that no-one had the forethought to store a copy of the original software with the bits of code required to generate an activation code on a CD  …. 

Is source code control not used in Lattice? 

IBM, Boeing, GE, Freeport, etc.  .... Swear to god.  If you needed to, you could literally go back to the beginning of time regarding anything that they have done regarding documentation if you needed to.  They are organisations that are best described as “paranoid” about keeping both printed as well as digital copies of software (and documentation) if for nothing else than as a way of not being able to be sued.  You want it … go to the legal archives and it’s there … and Lattice which is a “Technology Company” can’t do this …. 

   …

Look, from a practical perspective, I can well understand dropping frontline support for a discontinued device - no - really I can, and I have no problem with that at all.  What we should however be able to expect is that if a manufacturer does that, they at least provide the ability for the customers to be able to support themselves. 

To have the PLD programming software tied up with a activation code that you now can’t create a code for … it just belies belief. 

Here is a little bit of info which I think you probably *should* be aware of, and if you aren’t, then seriously - you need to get out of the office a bit more and go and spend some time in the field on some mines, and other places.  Contrary to what Lattice may believe, industrial grade component that can be used in a industrial controllers *OFTEN* have lifespans in the 30+ year region.  Old conveyor, crusher and other controllers I see in my day to day *often* have components dating to the early 80s (yes…. 6502s, Z80s … etc).  This stuff still lives on in industrials - this is not the exception - it’s the norm as this stuff is damned robust and continues to work 30+ years from when it went in.  Industrial equipment *often* has a lifespan in the 50-80 year range (depending on what it is). 

If you are going to sell stuff that is intended to target industrials … your support needs to be likewise as good.  I give full marks to Vinayak Dabholkar for his initial attempts at support.  Aside for the initial mis-underdstanding that I’m talking about a 20yo PLD instead of the current MACH device, he made I think a good effort.  My praise however tails off a bit after this though. 

Now, I suspect that at this stage, the horse has bolted and I’m on my own.  I was sort of expecting this which is why I’ve been looking into various alternatives.  What really annoys the hell out of me was that when I asked for possible alternatives (I’ve already told you what I had thought of), the best you can do is simply send back a 2001 letter regarding the discontinuance of the devices - that just isn’t helpful. 

At this stage, my plan “E” (yeah … I’ve had to skip past plans “B”, “C” and “D”) is to use the DOS based MACHXL software release by AMD *PRIOR* to the Vantis spin-off, and try to and re-create the existing logic in PALASM and then try to modify that.  The great irony here is that the *only* reason that i can do this is that someone in AMD had the *forethought* to release that to the world without codes and other general stupidity that seems to infect the current generation of manufacturers PLD software.  Shame it wasn’t in source code form as that would have allowed me to at least build it for a more modern platform but alas … we do what we can. 

Here is a couple of radical ideas for you to close out this issue. 

1.  As I previously mentioned before regarding a suggestion for old devices ….  on your web site in BIG BOLD LETTERS, put this comment next the old AMD/Vantis/Lattice devices that aren’t presently supported by ISPLever - put this message … “No longer supported.  We can’t support you, and you are own your own as we can’t even find codes to activate the software”.  Otherwise, may put a reference to using the CUBEL, PALASM or something else as a possible alternative - but maybe I’m asking too much there. 
2.  When you decide to retire ispLEVER and all those who are relying on the PALS, GALS, etc that it presently supports, how about you release either a final build without any license codes, or better still release the source code for ispLEVER so that if someone has to later support these devices in 10+ years time, at least they have the software to program these devices well after you have decided you don’t want to know about them any more. 

To be honest, when I started down this path to begin with nearly a month ago, I wasn’t expecting this to become as big of a drama as it has - after all… how difficult can it be to get a copy of the software and license codes to program a PLD …. right? 


/BGM
---> END FINAL MESSAGE <---

[Kilrah]

Your post/story is barely readable, but anyway...

You’re a technology company and you’re telling me that no-one had the forethought to store a copy of the original software with the bits of code required to generate an activation code on a CD  …. 

They certainly do have, but putting it to use again may involve complexities (servers, outdated software they were running on) that are beyond what they're ready to do for you for free.

IBM, Boeing, GE, Freeport, etc.  .... Swear to god.  If you needed to, you could literally go back to the beginning of time regarding anything that they have done regarding documentation if you needed to.

Sure they can, but according to discussions with people in this field who have gone through the process or attempted to they'll ask for upfront payment of way more than you'll be ready to pay for to do so, in order to avoid doing it.

There's that story about navigation software for a fighter jet that would fail in a given geographical region due to a bug that was in the end acknowledged - but the answer was still "oh we don't support that hardware revision you have on your jets anymore, so we won't fix it unless you pay $millions to dig out the plans, development tools, retrain people on the platform etc" so that you end with a quote that's at least half as much than upgrading the hardware on all your jets to fix an error of theirs.

[bgm]

Your post/story is barely readable, but anyway...

Agreed.  I could have definitely formatted the message to make it easier to follow.  The entire transcript of the correspondence with Lattice support from start to finish was  nothing short of abysmal and it is *painful* to read.  To get it through their heads that I was after the old AMD/VANTIS parts instead of their later series of MACH FPGAs was an exercise in itself (it went on for nearly a week ... I kid you not ...). 

That said, when I made the post last night, I was tired and cranky with having to deal with the *same* problem yet again (nearly a year after I sort of dealt with it the first time and at the time I was sure that I didn't have to deal with it *again* ... alas ... I was wrong). 

I am rather concerned that actually asking the general community for assistance here may get Dave (and the forum) into trouble which is why I really wanted him to read it first before generally throwing it open (though I seriously doubt that Lattice is going to make an issue of it - my impression last year was they pretty much weren't interested and were just happy to have the case "closed" so that it could be added support stats for their help desk). 

You’re a technology company and you’re telling me that no-one had the forethought to store a copy of the original software with the bits of code required to generate an activation code on a CD  …. 

They certainly do have, but putting it to use again may involve complexities (servers, outdated software they were running on) that are beyond what they're ready to do for you for free.

That isn't how they responded.  It makes a lot more sense when you read the whole 3 months of correspondence going back and forth on the issue.  When *I* had to point out that they needed to go and ask on of their FAEs if they had a copy of the S/W (most engineers I know are pack-rats) ... only *then* I think did their support actually consider the idea.  Now as to whether they actually *did* it is another question entirely (I seriously doubt it) as I just got quoted the same message regarding end-of-sale notice item (thanks guys ... I got that the *first* time ... I read it.  I know it ... I was't trying to buy a device ... just trying to get the last copy of the software and an activation code for it). 

IBM, Boeing, GE, Freeport, etc.  .... Swear to god.  If you needed to, you could literally go back to the beginning of time regarding anything that they have done regarding documentation if you needed to.

Sure they can, but according to discussions with people in this field who have gone through the process or attempted to they'll ask for upfront payment of way more than you'll be ready to pay for to do so, in order to avoid doing it.

There's that story about navigation software for a fighter jet that would fail in a given geographical region due to a bug that was in the end acknowledged - but the answer was still "oh we don't support that hardware revision you have on your jets anymore, so we won't fix it unless you pay $millions to dig out the plans, development tools, retrain people on the platform etc" so that you end with a quote that's at least half as much than upgrading the hardware on all your jets to fix an error of theirs.

At that point, the various people in Defence need to start digging their heels in - that kind of screw up is pretty major. 

Look, I got on my soap box in the EDABOARD forums last year so I've pretty much said what I wanted to say on the subject (I didn't see the attitude of the various manufactures changing then, and in nearly a year, I haven't seen any marked change since then). 

So my Q remains ... does anyone have the S/W and a code to make it run?  (It will be locked to the MAC address of the registering machine but changing a MAC address is pretty trivial)

... unless someone has a better idea (and no ... changing out the hardware just *isn't* an option ... as much as I would *like* it to be). 

In a public forum ... it is a pretty nasty thing to ask for as it just invites legal issues which is why I think Dave, really needs to think about if the original post should stand or if it should be zapped. 

[uncle_bob]

Hi

Sounds to me like the only real answer is to port it to the newer software. That's pretty much a way of life on these sort of products / projects. Often the support engineering bill is larger than the original development bill.

The proper answer would be to have archived an image of the entire development toolchain (and possibly the entire machine) as part of the development process. There are a lot of places that do this sort of thing when they know there will be long term support involved. I have a *lot* of copies of FPGA software on disks (not what you need - sorry) for this reason. Yes, it's going to take up some storage. Yes it needs to be managed. No, in your case, it didn't get done right the first time. Do it right this time and from now on.

Bob

[Kilrah]

Yep, as much as it sucks it's how everybody does it and we have to deal with it and take the appropriate measures ourselves. When someone decides to obsolete something it instantly goes as if as if it had never existed.

I've gone through the same with a Digilent FPGA dev board that I bought in 2006 with a Xilinx part on, this part needs their old toolchain to work, which is out of support and can't be installed on W10. I wanted to reuse that board and while the old toolchain is still downloadable I needed to create a virtual machine to install the software on. Then it didn't work, since the last download cable drivers somehow wouldn't work with the possibly customized version used on my board.
I had to dig the original CDs that came with the board to get THE particular version from a few years before that is known to work, which was a pain since they were physically located in another country than me. Install it on an (unsupported) XP virtual machine since that's what was needed at the time. Then those CDs had activation key stickers that you had to enter at install for an online service to actually convert to a license number... but of course that online service is long dead and gone. Fortunately when running the process you'd get an email with the license no in return... and as I keep all my email I could dig it out from the first time I did the process back when I bought the board. Otherwise I'd have been SOL with a perfectly good but unusable board. Interestingly it's still sold new by some from leftover stock, I'd love to see someone try to get one working now.

The need to keep a full copy of a properly set up development environment for any project that goes unmaintained for some time is known in every software project, but for FPGA stuff and the related painful proprietary (and messy) dev tools it seems it's an order of magnitude more important. And even more so for EOL stuff.

[uncle_bob]

Hi

It's been very apparent that you need to do this sort of thing for at least a decade. I started to run into people doing this as "routine" back in the 1990's. Do I *always* do this? Most certainly not. I toss the decision up to higher authorities and let them make the call. If they decide the storage is "to expensive" then we don't archive the thing properly. I make a nice note and a copy of the email. That goes into the doc's. If the project needs to be re-done, at least there will be no doubt about what was (or was not) done.

If you take a look at all of the library issues on a software project these days ... FPGA's are pretty simple ...

Bob

[mikeselectricstuff]

Is source code control not used in Lattice? 

A problem with PLD/FPGA  software in particular is that it is often comprised of parts from several different third-party vendors (look at how many different copyright messages accompany a typical FPGA build), so it isn't always in the manufacturers' control.
It's quite possible that software components  are licensed to the manufacturer for a given period, and need renewing periodically - for old parts they will at some point decide that it's not worth it. That may be one reason for them not being able to supply old versions.
And of course there's no money in supporting parts that are long out of production - I'm sure Lattice could come up with something if they really wanted, but why should they put resources into it?

Another issue particular to CPLD/FPGA is that they are 100% dependent on the software - without it they are basically unuseable. With any CPU there will pretty much always be some way to generate code for it, be it assembler, cross-compiling or hex hacking.
 
What is it about your hardware that means it has to be kept going and updated rather than replaced ?
Might a bodge board be an option ?

[uncle_bob]

Is source code control not used in Lattice? 

A problem with PLD/FPGA  software in particular is that it is often comprised of parts from several different third-party vendors (look at how many different copyright messages accompany a typical FPGA build), so it isn't always in the manufacturers' control.
It's quite possible that software components  are licensed to the manufacturer for a given period, and need renewing periodically - for old parts they will at some point decide that it's not worth it. That may be one reason for them not being able to supply old versions.
And of course there's no money in supporting parts that are long out of production - I'm sure Lattice could come up with something if they really wanted, but why should they put resources into it?

Another issue particular to CPLD/FPGA is that they are 100% dependent on the software - without it they are basically unuseable. With any CPU there will pretty much always be some way to generate code for it, be it assembler, cross-compiling or hex hacking.
 
What is it about your hardware that means it has to be kept going and updated rather than replaced ?
Might a bodge board be an option ?

Hi

.... add in another twist:

In this era of software patents and the like, some bit or piece of the base toolset may have run into trouble. At that point there isn't always a choice. The offending item goes off the market. In most cases a re-write is undertaken and a "version X+1" comes out that no longer has a problem. The gotcha is a pre-built toolchain that depends on version X. On a "free" toolchain, paying royalties on a "per instance" basis is a kiss of death. There other similar things that are equally incompatible. Needless to say, the guys that won the judgement are *really* interested in going after anything that looks like use after the magic date. Since this is all really obnoxious, a gag order (NDA) is generally a standard part of the deal.

Bob

[bgm]

The proper answer would be to have archived an image of the entire development toolchain (and possibly the entire machine) as part of the development process. There are a lot of places that do this sort of thing when they know there will be long term support involved. I have a *lot* of copies of FPGA software on disks (not what you need - sorry) for this reason. Yes, it's going to take up some storage. Yes it needs to be managed. No, in your case, it didn't get done right the first time. Do it right this time and from now on.

In short, original design done back in the day wasn't done by me or anyone I know.  I was just asked to come in after the fact and pick up the pieces.  What you are suggesting is pretty much what I said on the EDABOARD forum a year or so ago about keeping a complete dev environment which is then handed over to the client (I'm assuming you didn't read the link - especially my last lot of posts on the subject). 

Now of course, when this stuff was designed (early-mid 90s) the CPLDs I'm having to deal with were still owned and made by AMD so virtual dev environments pretty much didn't exist then.  The issue since then is how to pick up the pieces afterwards. 

Last year, I got by using a bodge hack using PALASM, and that sort of worked, but I need to revisit it, as it was't really right and using PALASM is ... well ... *PAINFUL* to say the least.  I really need to redo the logic in it, and really it isn't hard.  My Verilog, while ... pretty rudimentary is good enough that I got what I needed to do working in simulation and that was ok and I just needed to convert it to a JED file to write to the PLD so I could test it with a logic analyser to make sure it was correct.  It's one of those things, that really shouldn't be hard to do, yet because of the toolchain I'm being forced to use ... well ... is. 

Now ... 

An update on this, as it is very applicable here.  Late yesterday, I got a out-of-band-message from the original query and I now have a copy of the software, so many thanks there (I will abstain from mentioning a name as I am still real uncomfortable with the original post). 

That did however come without the license code (he had the CD but not the ability to re-generate the license code) ... so I now have a *COMPLETE* LEGIT copy of MachXL 6.2 ... *BUT* I don't have a license code. 

After looking at the software in a fair bit of detail, what I found has left me dumbfounded. 

MachXL 6.2 uses LMGRD 5.12c ... 

Why is this important??? 

Lattice STILL uses the LMGRD license system. 

In a past life at another place of employment, when I had to generate LMGRD licence codes for some of the stuff that we produced, the version of it we were using then was able to generate keys and codes for literally every version of the LMGRD license manager since day dot. 

So ... draw your own conclusions on that one .... 

[bgm]

Is source code control not used in Lattice? 

A problem with PLD/FPGA  software in particular is that it is often comprised of parts from several different third-party vendors (look at how many different copyright messages accompany a typical FPGA build), so it isn't always in the manufacturers' control.

Very true. 

It's quite possible that software components  are licensed to the manufacturer for a given period, and need renewing periodically - for old parts they will at some point decide that it's not worth it. That may be one reason for them not being able to supply old versions.
And of course there's no money in supporting parts that are long out of production - I'm sure Lattice could come up with something if they really wanted, but why should they put resources into it?

Back to my original reply to them ... just SAY so.  Don't faff about.  Be upfront and just say so. 

Another issue particular to CPLD/FPGA is that they are 100% dependent on the software - without it they are basically unuseable. With any CPU there will pretty much always be some way to generate code for it, be it assembler, cross-compiling or hex hacking.

Absolutely agreed 100%.  I simply can't think of a single MPU that hasn't had a cross compiler made for it that you can't run under a modern system (MIPS, 68xx, PIC, etc .... )

What is it about your hardware that means it has to be kept going and updated rather than replaced ?
Might a bodge board be an option ?

In a word ... "Insurance" .. and no, I am *not* joking. 

I am *allowed* to "add" logic so that I can add functionality to a previously unused pin. 

I *cannot* however change existing core functionality, nor can I change a "critical" part (yes, they have a list - the PLD is on it).  If I break those rules, it needs to be re-certified (otherwise insurance is void), and as the original manufacturer no longer exists ... well .. I would have to foot the bill for that, and that is *MANY* $$$$$$ ... so that isn't an option. 

So ... provided that I'm careful and don't change behaviour of an existing pin I'm ok. 

Amusing bit of legal irony here ... technically I could *wipe* the PLD clean and according the the paperwork, that would still be ok with insurance because then it just wouldn't turn on. 

Wipe it blank, controller doesn't work as nothing will turn on ... all sweet. 
Change out the PLD for another which would do the job and has current dev tools and would work ... nope ... can't have that. 

Legal logic - don't you just *love* the lawyers! 

Actually as an aside ... it's pretty difficult to substitute another part .. I was looking into that last year before I got floored with the re-cert costs. 

Industrials are pretty scary as if you screw some of this stuff up, people can die.  Its partly why some of this stuff is so damned expensive to begin with (at lot of it is massively over-engineered ... for probably very good reasons). 

I would imagine that anything to do with aviation would be infinitely worse (I am *so* glad I'm not touching *anything* in that area!). 

[uncle_bob]

Hi

Well since you brought up aviation .....

Back before there were .... errr ... electrical control systems ... they did it all with cams and the like. There is still a machine shop out in Arizona making those cams to the original prints. You can't change the cams, you can't change the prints, you can't rectify the control system. Instead you pay a crazy price for the replacement cams. It's the most heavily equipped shop I've ever been in. They work an 8 hour day 5 days a week as far as I can tell ....

Bob

[bgm]

Yep, as much as it sucks it's how everybody does it and we have to deal with it and take the appropriate measures ourselves. When someone decides to obsolete something it instantly goes as if as if it had never existed.

Yeah ... stuff then gets treated as if it has the plague.  Shame that as the vendor pool is so small... they are not treated the same. 

I've gone through the same with a Digilent FPGA dev board that I bought in 2006 with a Xilinx part on, this part needs their old toolchain to work, which is out of support and can't be installed on W10. I wanted to reuse that board and while the old toolchain is still downloadable I needed to create a virtual machine to install the software on. Then it didn't work, since the last download cable drivers somehow wouldn't work with the possibly customized version used on my board.
I had to dig the original CDs that came with the board to get THE particular version from a few years before that is known to work, which was a pain since they were physically located in another country than me. Install it on an (unsupported) XP virtual machine since that's what was needed at the time. Then those CDs had activation key stickers that you had to enter at install for an online service to actually convert to a license number... but of course that online service is long dead and gone. Fortunately when running the process you'd get an email with the license no in return... and as I keep all my email I could dig it out from the first time I did the process back when I bought the board. Otherwise I'd have been SOL with a perfectly good but unusable board. Interestingly it's still sold new by some from leftover stock, I'd love to see someone try to get one working now.

There you go.  Another one to watch out for.  That has just given me an idea ... a registration list of devices and vendors support attitudes towards them.  Name and shame so to speak. 

The need to keep a full copy of a properly set up development environment for any project that goes unmaintained for some time is known in every software project, but for FPGA stuff and the related painful proprietary (and messy) dev tools it seems it's an order of magnitude more important. And even more so for EOL stuff.

So true.  These days it is a lot *easier* than it was in the past with the advent of virtual machines.  It does make me wonder why the PLD providers don't provide a complete virtual machined in conjunction with their older software for this exact purpose.  It simply can't be disk space requirements, and most S/W runs under Linux so the OS licensing cost for something like that would be zero so you have to wonder. 

As others have said, it may have to do with the fact that they license various bits and pieces of IP from other people and the moment they stop producing a part (and therefore making money from it) they wish to stop their payment to the various IP licensors (spelling?).  That being the case, it is a pretty shitty position to be putting support people in who have to look after equipment for devices which they no longer provide support for.  Problem is that I can't see them "willingly" changing in the future unless they are *forced* to change. 

I have personally seen a complete controller system *thrown out* because it needed a minor change and as it was based on the Cypress PLDs, and as Cypress no longer provides either support, software or any other access to the software, you cannot change them so in that case the 100k controllers were literally thrown out en-mass because they couldn't be updated.  Insanity ... all because the vendor was either unable (or unwilling) to provide support for the WARP software required to configure them. 

As I have publicly said in other forums in the past, I have no problem with vendors stopping frontline support for a EOL component.  They don't make it any more, so don't ask questions.  Fine ... but at least, allow people to continue to support themselves by at least allowing them to at least still program the components with the software.  The moment you take away the support software, the components really are "dead" and often that will also kill a device if that is using them.  That is the bit that really gets up my nose.  If nothing else, release *all* details on the EOL component and the logic behind programming it so if you can't release the software after the EOL date, at least allow others to re-create the software by release all specs that they would need to be able to do so. 

In my case right now with my existing problem, I'm currently stepping through LMGRD code to see how 5.12c works to see if I can fudge my own keys for MachXL (I've found quite a few references to hacking it on the net).  We'll see by the end of the week how this goes. 

[ale500]

I'm currently stepping through LMGRD code to see how 5.12c works

Take notes, screen shots, something.  You will need them when you have to re-do this for some other reason (happened to me, more than once, another piece of software).

I recently had to compile 3-years old production code. It didn't work. Our build process depends on many pieces of software that requeire license servers that with newer versions of hw and OS and so changed...With so many variables it is very difficult to keep working builds, and all tools are versioned... but not the license servers...
The point is how long is long time support ? 10 ? 15 ? 20 years ?

[rsjsouza]

Having legacy software to support (compiler suite), I can attest to what Mike mentioned regarding third party components. We have royalties tied to certain components that make it very costly and difficult to manage after 15~20 years on the road. Not to mention the fact that sometimes software simply gets lost in the maze of servers and data managers - especially across layoffs.

Lmgrd 5.x is a third party component that was designed by a company that does not exist anymore - it was sold to Macromedia which in turn became a spinoff called Flexera. Believe me, I am almost 100% sure nobody know how this thing works anymore.

All that said, didn't they say that they can't support this right from the start?

[Bruce Abbott]

I have personally seen a complete controller system *thrown out* because it needed a minor change and as it was based on the Cypress PLDs, and as Cypress no longer provides either support, software or any other access to the software

The system is working as designed. How can we have a prosperous economy if people keep using their old stuff instead of buying new stuff?

[mikeselectricstuff]

I wonder if there is any mileage in looking for a currently supported CPLD device that has a sufficiently similar architecture and size, that you could write a utility to translate its bitmap to a PALASM file  that would fit the MACH devices.
 

[bgm]

Lmgrd 5.x is a third party component that was designed by a company that does not exist anymore - it was sold to Macromedia which in turn became a spinoff called Flexera. Believe me, I am almost 100% sure nobody know how this thing works anymore.

I am *well* aware of this history of it ... (having had to use it in a past life ....)

Even in it's hey-day ...  LMGRD was .. well ... a "challenged" beast, but key generation is actually not that complicated once you've got the software installed. 

Historically, what happened with LMGRD was it was like this.  You have a product you want to secure.  So you pay a license, and then get issued with a local enterprise key file along with a software key generator. 

You saved your enterprise key, and then created a table of products (and features) which you then generated your own keys for. 

In your application, you would then link the LMGRD client libraries in with your code.  That could be done either as a dynamically loadable library (DLL in the case of Windows or a shared library in the case of UNIX systems) or statically linked at compile time, and then you would add the hooks in your code that would check the software and feature keys from the generated ID (from your enterprise key) and you ship that off to your customer. 

They install it, and in the process of registering they get a unique value which they have to mail back to you.  That part is their "client key" (typically MAC address of the machine in question - the case of SGI and SUN workstations, it was a hostid) along with some other stuff.  You take that, and combine it with your enterprise key, and generate a license file which you then send back which you specify *which* "features" of the software you want to enable. 

They install that license file, and when the code runs by running the codes it gets from the license file along with the details from the local machine and if the combination of the two spit out at the other end saying that all is good, your software runs.  Product features, expiring dates and a whole swag of other things affect that. 

Now this is a *GROSS* over-simiplifciation of the entire process but you get the idea. 

Providing that you (as the vendor) haven't lost the key generation software, that pretty much will ensure that the keys you generate will work with your s/w.  In the past when I have used the software, you could pretty much generate a license for just about *any* version of the LMGRD client that was in existence.  Back in my day ... (yeah old person speaking now), we had to deal with early versions of LMGRD that had to generate keys for SGI IRIX 6.5, 6.2, 5.3, OS/2, Windows NT 3.1 and WFW which meant that there was a smattering of LMGRD client versions.  Really not that much of an issue as you selected which client version you wanted to generate a key for (for most part, license key dat files were pretty platform independent, but they were often version dependant). 

Now ... Lattice *still* uses LMGRD for ispLever which you can *STILL* get license codes for ... so they *still* have the software license generator.  They still have their enterprise license codes.  This sort of stuff would almost certainly be kept by Legal. 

This means software wise, what they *need* to generate the codes, they *should still* have. 

All that said, didn't they say that they can't support this right from the start?

They did say they can't support the chips, which is just fine - I wasn't asking them to - I was just after the software and the license code. 

To begin with, it was "We no longer have the software".  After I got that (albeit ... crippled as it was missing stuff), then it was "We can't generate license codes". 

I've solved one problem - I now have the full software suite (progress ... of a sorts).  Now its just the keys I need ... and those, I'm still missing ...

Doesn't bode well for the future for ispLEVER ... unless they recompile it to *not* link in the LMGRD libraries. 

I started the process of reverse engineering the LMGRD client last week but I have had to shelve that for the moment as I've got a few more pressing problems I need to sort out at the moment.  Right now, I'm working on some PALASM code that *may* do the business but it is really god ugly and I would rather much use the original Verilog so that I know the original logic and timing, etc is still the same. 

Touching this stuff is ... yeah ... ugly ... real, real, ugly.   

[marcopolo]

Any news?

[ebclr]

Sometimes web archive may help to find old stuff  no more available on INTERNET

http://archive.org/web/