Meyers Musings : Corporate Arseholery At Work (the MBA wankers are at it again)

[bgm]

TLDR:  Lattice have started charging $600 USD per year for me to look at my existing designs, and I'm pissed … or why I will never again use or recommend a Lattice product (they can GFT … Go and F**** Themselves) and I hope after reading this, you give them the middle finger as well until they change their F***** attitude but there is some far more disturbing implications ....

Past the TLD line … great.  A warning though - some fairly strong language and opinions are to follow, so that means if you are under the age of 12, then you have probably heard all these words used in the school playground already so you won't be seeing anything new.  Those older than 12 ... yeah ... definitely nothing new. 

Now, go grab yourself a refreshing beverage of your own choice (personally right now it's a Friday afternoon and I'm massively pissed … or want to get that way so I'm going to grab a beer (or three), but each to their own). 

The reason for this post is because what we need to discuss is how copyright and other legal protections of the world are effectively fucking over service personnel and how design engineers have been either ignorant or complicit in part of this. 

Lets start by defining the problem. 


Access to Information (or more specifically the lack thereof). 
Whether you are looking (or want to look get) at a schematic for a Apple laptop, or the design files for a PLD that is at the heart of a industrial safety system.  You would think that most information like this would at least be generally available – even for say a device which has been EOL'd by the manufacturer. 

Turns out … this is no longer true. 


Days of Yore:
Rewind 30+ years ago, and you could get service manuals for pretty much anything that was sold.  Hell, when you bought your spanking new Apple II, Sperry or Commodore computer, in the user manual, you typically got a full set of schematics, along with block diagrams as well as “theory of operation”.  In some cases, you even got comment assembly source code to go with it as well. 

This didn't just apply to computers though. 

You want a service manual, for a Caterpillar 966A (1966 vintage) front end wheel loader, a Ford 5000 Tractor or a Holden station wagon car, worst case, you had to go through microfiche files and best case they would send you a service manual for free.  All you had to do was “ask”. 

In some cases, you had to buy the relevant manuals (because these things were large and involved a not fairly inconsiderable amount of cost to print). 

Documentation (ala “knowledge”) was shared.  It was available. 

If you had to fix something (whether it was a car, washing machine or a computer), pretty much everything you needed was available. 


Fast forward to now:
With copyright laws as they presently are, and the latest MBA corporate bastardry, if you want documentation to anything, you literally have to steal it off the back of a truck. 

No … I am not being sarcastic, things really are getting that bad. 

… and if you think that was just for documentation … oh how have I got news for you. 

The very tools that we use are now being screwed down as well. 


The Tools:
A few years ago, I got on my high horse about the changes to the Eagle EDA tool licensing when Autodesk decided to change from a once-off purchase price (and then an ongoing upgrade price model) to a 'pay-as-you-go' online subscription model. 

My issue with THEIR implementation of the subscription model was that while it has a whole bunch of benefits (for both the end user and the supplier – Autodesk), it has a couple of REALLY NASTY downsides. 

#1 is the fact that the permanent online connection. 
#2 is the perpetual subscription model

Now while I said it (The Autodesk Eagle subscription model) wasn't the most evil of subscription models (and it isn't – you can still view your designs, you can export them – you just can't change them) it was bad enough. 


New Corporate C**KS:
Well … Lattice have now descended to the realms of true corporate cocks by taking the ispLever software (which uses the LMGRD license license manager, for which they previously would only grant a 1 year license key for) and now charging you a mandatory $600 USD/year. 

If you don't pay up, you don't even have access to look at your existing designs. 

Yes, that is right, the software won't run at all unless you pay.  They are locking your designs. 

If ever there was an example of pure corporate shitfuckery … this is it. 

Now it isn't 100% awful, as if you used Verilog or VHDL to create your work, then those are stored as basic text files … BUT …

   … if you used the schematic editor …

   … you are well and truly fucked. 


Is the real problem with this cost? 

Yes and no. 

Yes, because $600 USD/year isn't small change. 

No … because no organisation should have the RIGHT to hold your IP to hostage, and that is what Lattice (and many before them) have done. 


Forcing a Change:
If you as a designer are using Lattice parts in a new design YOU are condoning this corporate behaviour. 

Corporations understand only one thing – money.  It is as simple as that. 

Design engineers have a say in the choice of parts. 

The only way to get them to change the behaviour is as a whole the industry says to Lattice, you don't change your behaviour, we don't use your products.  No sales = no money. 

That is the ONLY way to get them to change, and if they see the correlation between screwing over the customer and lack of sales, they will change their ways. 

You can forget about getting legislative changes in the US – it has the best government that the corporate lobbyists can buy. 


Further Reaching Implications:
So why bother?  After all, ispLever is only for old devices and who is this really going to affect? 

At the moment, the technicians and other poor barstards who are stuck looking after legacy systems that use these legacy parts, are the ones most directly affected.  Which basically means maybe me and a half a dozen others as we are probably the only ones stupid enough to be maintaining stuff 20 years on.  The new designer, not really affected. 

Looking further forward though it sends a very disturbing message.  If Lattice are willing to screw over people who work after legacy systems, how soon before users of the Diamond software suite that supports their newer devices are treated the same way? 

Actually here is a quirk ... the current Lattice 4000V CPLD ... that is handled by ispLever so if you spend $10 for that CPLD, you still need to shell out an additional $600 USD to define the bit stream file for it.  Err .. yeah.  If they didn't sell a lot of them before, they probably won't be selling a lot of them now.  I'm guessing it is going to be EOL'd pretty soon. 

The other rather pertinent point is that if Lattice are willing to do this, how long is it before Intel (aka Altera), Xilinx and others are willing to pull the same crap? 

They hold they keys … and that fundamentally is the problem. 

Can you imagine the proverbial shit storm that would be blown up if Parker (the maker of pens) said that you could only write on their brand of white paper?  In effect the software that programs these PLD devices is the same.  It is the “pen” that writes to the “paper” (in this case the chip). 

If you think about it, we had something similar to this with Lexmark and not allowing 3rd party ink. 

In the case of PLDs, we really need a viable open source alternative to the plethora of vendor specific tools. 

Effectively, we need a “gcc” version of Verilog and VHDL that can synthesise parts for a complete range of parts. 

The problem is that to implement the secret sauce that is the fitters for each device, we need to know internal architecture and that is something that the vendors are almost certainly NOT going to share. 

… and here is the real rub, the only way these tools will succeed is if vendors release this information which means that we need to be selective about which vendors we support.  That is a problem when it comes to engineering because it is now adding an additional constraint – is your parts manufacturer a collective bunch of arseholes? 

For the sake of completeness while writing this, I just checked Digikey, Mouser, Element14 and RS websites and none of them have an “Arsehole Manufacturer” as a selectable option in the parts filters - seriously ... I looked!  Go check yourself.  No such option. 


Copyright:
I mentioned copyright at the top of this post is where this comes into play. 

In days of yore, while the likes of Apple, Caterpilar, GE, Ford, etc would release documentation with a copyright on it, they would provide it at their largess. 

That basically means that yes, they still hold a copyright and if someone really annoyed the shit out of them by being complete and utter tools, they still retained the copyright stick to beat them with.  The thing was, they (the manufacturers) generally were pretty good about providing information. 

The issue is that just isn't the case anymore. 

More and more of these companies are keeping their documentation to themselves, and they are hiding behind the copyright to do it.  If you want an example of this, go look at just about *ANY* Louis Rossman repair video.  This isn't just in the electronics industry (John Deer, Ford, etc) issue alone though.  They are *ALL* pulling this shit now as the MBAs have now decided that knowledge is something that they can monetise and isn't in the benefit for all of us.  I can still recall an incident not that long ago (ok, 4 or 5 years ago now), when a certain manufacturer wanted me to sign a NDA for a data sheet - yes a F***** data sheet.  Not for some ultra secret new product ... it was for an existing product and it's internal operation was so secret they wanted a signed NDA.  No points for guessing ... didn't use the part and their sales rep got stroppy with us when we told them why - No Sh*t Sherlock.  I'm not.signing a NDA for a data sheet.  For a prototype chip or something like that maybe, but for a data sheet for a generally available part  ...  Nope. 

And so we come back to copyright law and the issue with it. 

Let's start of by talking about duration.  I'm going to reference US copyright law here as it has the furthest reaching tendrils ... 

At the time I am writing this, under current US copyright law, for an individual, stuff that you or I create individually lasts our lifetime + 70 years : 17 USC 302(a). 
For corporations, it is from the date of publication  : 17 USC 302(c). 

… and this is a problem when it comes to software and other informational tools that we use and deal with. 

When technology is effectively “out of date” after 5 years, to have corporations holding an axe over your head well after the time that they effectively EOL (ala abandoned) the product … that is just too long. 

From a legal standpoint, a somewhat more rational change to copyright law might be the addition of an “abandonment” clause.  If you pull support for a device that you make, then any and all documentation for that device should go into the public domain after that. 

That means that if YOU as the manufacturer no longer deem it worth your time to support something, it doesn't mean that someone else may not be willing to.  That applies to schematics, as well as the software. 

Will it ever happen – very bloody unlikely, but I can dream….


Now ... you will have to excuse me.  I have a Guiness that appears to be suffering from evaporation at the moment ...

[bgm]

I figured I had better write a small follow up to this seeing as I've had a couple of out of band questions so rather than me giving the same reply over and over again in email, I'd figure I'd write it here and hopefully I don't get asked again. 

This incidentally is in regard to my specific bugbear regarding how we are at the mercy of out vendors development tools - specifically I'm talking about the PLD development tools here. 

How things work
Ok, lets start.  First off ... crash course in how these things operate.  This is a very general overview, so if someone wants to jump up and down saying "This isn't how product 'x' works ..." ... yeah, it probably isn't.  This is a very *quick* generalisation. 

Typically your VHDL/Verilog/CUBEL/PALASM/etc ... compiler takes your source files and then parses those.  It then takes that syntax and turns it into a net list. 

Think of this as the preprocessor and compiler stage of a 'C' compiler.  It hasn't produced a final compiled bitstream file yet. 

It then takes that and then feeds that into an minimiser which does things like reduce product terms and so forth doing tricks like using Karnaugh maps, etc to actually get down to the minimum amount of logic actually required to implement your design. 

The results of this are then fed into a vendor specific fitter. 

The job of this fitter is to give the optimiser some insight into the best (and optimal) way of implementing the logic reduced map.  For example, if the logic decrees that you are in effect using an adder and the hardware actually has a hardware adder, it will substitute the logical implementation with the hardware implementation.  Think of it as fiddling with the compiler flags with GCC.  Does you target device have a FPU?  Yes - great, use that instead of a software only FP library. 

The end result of the output from the fitter typically then goes *back* into the optimiser before it then gets handed off to the vendor provided synthesiser to create your final vendor specific bitstream file.  This is the logical equivalent of taking the ASM files that the C compiler generates, and then pushing that to an assembler and linker to produce your final executable. 

This is how your Verilog/VHDL source files starts as a ASCII text file and then winds up as a vendor specific bitstream file.  Whether that device is a Vertix FPGA from Xilinx, or a MACH 4000 CPLD from Lattice. 

Licensing and Legalities
With me so far?  Good ... 

Now here is where we get the 'kinks'. 

Vendors like Lattice, etc will typically *NOT* write (and maintain) their own VERILOG and VHDL font-end compilers.  Why bother?  That's expensive and you can just go to another vendor (for example ... say from Mentor Graphics (nee Siemens)). 

So what they do is they license those bits that they can and then they write the bits that they need to. 

Typically the VHDL/VERILOG parts are license (like the timing analysis tools, etc), while the fitters and the final synthesisers are created by themselves. 

... and this is where we really have a problem. 

Take ispLever (from Lattice) or WARP (from Cypress).  Typically what they do is they license a VHDL, and VERILOG compiler from the likes of Mentor Graphics (I'm not saying they do, I'm just using them as an example). 

While they license the software, they almost certainly are *NOT* going to tell us what the licensing arrangement is.  Do they license the VHDL/VERILOG compiler from Mentor for 10 years or do they buy it outright?  Who knows ... (actually ... they *will* know, but they certainly aren't going to tell us that). 

My guess is (and this is just a suspicion .. I have *ZERO* evidence to support this theory) is that the vendors of these devices license the master software for say 15 years (rather than perpetual) and then after that they then need to pay the likes of Mentor, etc for the continued use.  Thinking about it, this would make sense but it does highlight the problem with this whole system. 

This means that it may NOT be Lattice who is doing this to ream the end user – it may be due to their original license agreement.  Either way though, the end result is the same. 

As the end customer, you are 100% completely at the mercy of not only your vendor, but also the primary vendor of the various licensed bits of software. 

In the case of ispLever, it's Lattice.  In the case of WARP, it was Cypress.  *IF* they have licensed components of their software from say Mentor and Mentor says "you can't use it any more, stop distributing it, and stop generating license keys" ... guess what ... you are 100% screwed. 

... and this is the fundamental problem with the whole part of the PLD industry. 

There is an old saying that is really appropriate here. 

"Those who fail to study history are forever doomed to repeat it"

Aside from myself, who else remembers the UNIX wars of yesterday and the cost off development systems.  Yes ... you had to *PAY* often *stupid* amounts of money in the early days of UNIX for access to a compiler because the AT&T MBA's and lawyers decided that this was a really good revenue stream. 

We have the same case here. 

This *NEEDS* to change. 

For large vendors (the Apples, Samsungs, etc) for the world, they will typically have their own separate agreements but for the small fry such as myself and probably are large percentage of the people reading this, we are the ones who are at the greatest risk. 

These days the cost of development systems is fast being driven to zero, and that is the way that it should be. 

GCC, CLANG and others have fast driven the costs of development software towards zero (there is still niche markets for things like profilers and memory leak detectors as well as code analysis tools and that is fine), but for general “stuff”, you typically don't need to shell out massive amounts of money for a development tool unless you are on a very specific platforms. 
This however is NOT the case in this industry and that is a very real problem, and as I said before ... this is something that NEEDS to change. 

I'm not happy with the status quo of having my work at the mercy of ANY vendor.  This is regardless of whether it is a schematic and layout or our custom logic in a PLD device. 

A more practical reason for this is that your designs may well live on well after you have gone (retired, dead, etc). 

Pitty the poor service guy who then has to fix something.  Either because regulations mandate a change or that this is a previously undiscovered fault.  That service tech/engineer is the one who is going to be doing the most bleeding because of your choices.  I say this specifically from the viewpoint of one who regularly runs into this issue. 

These are the people who these MBA/Legal wankers are hurting the most because of their biblical levels of arseholery. 

I like to use the term “extortion”, but I'm told that legal doesn't like that term when used in conjunction with them. 

Where to from here
So options …

In the PCB SCHEMATIC and LAYOUT space, KiCAD is a really good step forward.  We really should be moving towards this product.  I say this even though personally I still to this day prefer using my licensed copy of Eagle (oh the irony … but my license is a perpetual for the 7.x branch before Autodesk got involved).  My own business has now moved everything to KiCAD but old habits die hard. 

IVERILOG and YOSYS are baby steps in the PLD space.  The issue here is going to be to get the likes of Lattice, Xilinx, Altera(nee Intel) and others to get onboard provide enough information regarding their devices so that a generally open implementation of the tools can then be used. 

We are a LONG way from that though. 

What as a DE can you do?  Ask the questions.  If you are working for a large company, ask them if they can ask the questions of the PLD vendors?  Would they be willing to open up?  If the can say that would be a positive toward using their devices.  All these vendors are ultimately fixated on money (regardless of what the BS their PR departments would like to spruce).  If it becomes apparent that it is in their financial interests to "play nice", they will. 

We have to effect change.  The vendors won't be doing this voluntarily out of the goodness of their hearts ...

[T3sl4co1l]

You... did read the "fine print" right, you didn't just blindly tick the "Agree To Terms" button did you?

Any of these tools are provided at will, non-transferrable and revocable, or some combination thereof -- I don't know Lattice's terms specifically, nor for those tools specifically.

If you absolutely did not intend to agree to these terms, you should've shopped for a different supplier.  No one else out there?  Can't negotiate with Lattice, they won't give you any better deal than $600?  (Not that I can imagine a corporation negotiating a contract for less than $600 -- and anyone big enough to be worth negotiating with, can sneeze away a hundred times that, they'd never even bother.)

Anyone still uses PLDs?  Those are so ancient I'd suppose anyone who needs them that badly, is lucky they still exist at any price.  FPGAs and MCUs have moved so far beyond PLDs that there are myriad substitutes, when substitution is permissible at all.


Given the above -- perhaps the $600 would be best spent on a therapist, rather than the exact problem itself?  Someone to talk to; reevaluate work-life balance; that sort of thing.

Best of luck, in any case!

Tim

[bgm]

Anyone still uses PLDs?  Those are so ancient I'd suppose anyone who needs them that badly, is lucky they still exist at any price.  FPGAs and MCUs have moved so far beyond PLDs that there are myriad substitutes, when substitution is permissible at all.

When I say PLDs, I'm including everything from SPLDs to FPGAs (an FPGA *is* a programmable logic device), and I'm not *just* referring to the old stuff.  The problem applies equally to the newer stuff as well in that you are signing your life away to the vendor. 

If that vendor can pull the plug, then like it or not, that *is* a problem. 

This is not a new issue - it's been around for ages.  People keep forgetting as for most part, as it typically doesn't affect them ... until it does.  Then they feel the pain.  In my case, this was a very poignant reminder. 

The event that prompted me to send this was when I had to look at an old(ish) design to see if it could be appropriately butchered to fix an edge case problem, and suddenly, I couldn't.  At this point it was an "Oh f****" moment ... (visualise lots of repeated head banging on desk and plenty of colourful language), and the device in question wasn't even particularly old (based on the Lattice 4000V which is *still* production). 

One of the plethora of joys of service tech life is you get to live with the pain, misery and suffering imposed by bad decisions of the various design engineers that came before you.  Often that means that if you need to extend or modify something that exists anew, you are shackled to using the existing tools, and that was the case here. 

I may sometimes be a touch "salty" but never let it be said that I don't mind someone else deriving a small amount of humour at my own expense.  With a bit of luck someone out there should have got a giggle (or two) at my own misery and maybe, just maybe, a minute of so of thought about the problem with handing the keys over to someone else ... 

[GSV Sleeper Service]

Has anyone been in contact with Lattice about this yet?

There is some confusing language on the Lattice Diamond page that suggests that mature devices are covered under the free Lattice Diamond license.  This is confusing since Diamond does not have support for the tool chains that fit those devices.

As someone who recently picked up 10k+ of the 4000v devices I hope they are not serious about this $600/yr requirement. 

[schmitt trigger]

Welcome to the new normal.

It sucks for the user, but almost everyone (or perhaps everyone) is shifting towards that business model.

[SilverSolder]

Welcome to the new normal.

It sucks for the user, but almost everyone (or perhaps everyone) is shifting towards that business model.

It will open up a gap in the market for companies that don't do this...   it will take time, but I think it will eventually become more normal to "cut the cord" with subscription software.   It just isn't sustainable...

[bgm]

Has anyone been in contact with Lattice about this yet?

Sorry for the delayed reply (life kinda got in the way). 

Short answer is yes.  I constructed a very civil question as to why the change. 

    ... the silence has been deafening ...

[bgm]

Welcome to the new normal.

It sucks for the user, but almost everyone (or perhaps everyone) is shifting towards that business model.

The "throwaway" model (when the vendors throw away the tools because they are no longer profitable for them to maintain, they want to force you to throw away everything as well). 

You maybe right in regard to that this is the model that these jokers are trying to push everyone to, but it's model that is fundamentally broken for anything that needs to be maintained long term. 

Give the vendors an inch, and they'll take a mile. 

[coppice]

Anyone still uses PLDs?  Those are so ancient I'd suppose anyone who needs them that badly, is lucky they still exist at any price.

Anyone still use resistors? Those are so ancient I'd suppose anyone who needs them that badly, is lucky they still exist at any price.

[MadTux]

Just unpacked a cute ispMach4256 dev board that I had lying for a while to start a small project and realized no more software  . Fuck them!!!
Somebody should crack that fricking IspLever Classic and upload it to Piratebay and friends.

Maybe somebody can upload a licence from back in time, when it was essentially free to use?
 From what I've heard, it only checks MAC adress and time, for that 1 year period. Both things that could easily be spoofed on a VM. Removing that crap with a crack would be the nicer solution though.

[luzotug]

Yes Marty, with $600 per year you're better of jumping in a DeLorean ;-)

It's a PITA but it's probably not a good idea to upload an expired licence, the big corporate will be able to track down from whom the licence came from.

It has been said before and I agree, the licence is probably not for the Lattice stuff per se but for all the third party tools (synplify, active-hdl) and Lattice don't want to support the cost of those licences anymore.
In the long run, it's best to have a truly free and open source toolchain, there is already one for the ice40 fpga, we need one for the ispMach4000 cpld too.

[test2]

I came across this text that came out of a "license.dat" file and it seems to make my installation of "ispLEVER_Classic2_0" work. It worked "as is" without the need to to change the "HOSTID=ANY" text. I am using winXP.


FEATURE BASIC_ALL lattice 7.0 01-jan-9999 uncounted 0EC5CE7AE0DE
HOSTID=ANY
FEATURE LSC_STARTER lattice 7.0 01-jan-9999 uncounted 73224EA033EB
HOSTID=ANY
FEATURE LSC_BASE lattice 7.0 01-jan-9999 uncounted 9CE97753891C
HOSTID=ANY
FEATURE LSC_ANY_PAC lattice 7.0 01-jan-9999 uncounted DCF4E89B41D1
HOSTID=ANY
FEATURE LSC_PAC_STARTER lattice 7.0 01-jan-9999 uncounted
93096E4F2DD0 HOSTID=ANY
FEATURE LSC_PAC_SYSTEM lattice 7.0 01-jan-9999 uncounted BF10B454B18D
HOSTID=ANY
FEATURE LSC_DUMMY_FEATURE lattice 7.0 01-jan-9999 uncounted
A0265D023D6F HOSTID=ANY
FEATURE 0100 lattice 7.0 01-jan-9999 uncounted 841224FE9639
HOSTID=ANY
FEATURE 0200 lattice 7.0 01-jan-9999 uncounted C47123FB9538
HOSTID=ANY
FEATURE 0300 lattice 7.0 01-jan-9999 uncounted 9EF02EFCB437
HOSTID=ANY
FEATURE 0400 lattice 7.0 01-jan-9999 uncounted C4372DF99B2E
HOSTID=ANY
FEATURE LSC_ADVANCED lattice 8.0 01-jan-9999 uncounted 1C47C70A6ACA
HOSTID=ANY
FEATURE LSC_ADVANCED_DSP lattice 10.0 01-jan-9999 uncounted
CAA8BAA7C278 HOSTID=ANY
FEATURE LSC_ADVANCED_FLXMC lattice 10.0 01-jan-9999 uncounted
6B082DACDAA5 HOSTID=ANY
FEATURE LSC_ADVANCED_LSCDR lattice 10.0 01-jan-9999 uncounted
17865366C30E HOSTID=ANY
FEATURE LSC_ADVANCED_LTSSM lattice 10.0 01-jan-9999 uncounted
8B6A3666E0EA HOSTID=ANY
FEATURE LSC_ADVANCED_MCTL lattice 10.0 01-jan-9999 uncounted
7AF5C1DCD5B6 HOSTID=ANY
FEATURE LSC_ADVANCED_ORCA lattice 9.0 01-jan-9999 uncounted
9EA3C938B4C7 HOSTID=ANY
FEATURE LSC_ADVANCED_ORLI10G lattice 9.0 01-jan-9999 uncounted
0BB1D333EF42 HOSTID=ANY
FEATURE LSC_ADVANCED_ORSO42G5 lattice 9.0 01-jan-9999 uncounted
AB9147E09AC1 HOSTID=ANY
FEATURE LSC_ADVANCED_ORSO82G5 lattice 9.0 01-jan-9999 uncounted
B37D4BDCA6C5 HOSTID=ANY
FEATURE LSC_ADVANCED_ORSPI4 lattice 10.0 01-jan-9999 uncounted
BC81D9589AFD HOSTID=ANY
FEATURE LSC_ADVANCED_ORT42G5 lattice 9.0 01-jan-9999 uncounted
A8267218E893 HOSTID=ANY
FEATURE LSC_ADVANCED_ORT82G5 lattice 9.0 01-jan-9999 uncounted
901A5E24E897 HOSTID=ANY
FEATURE LSC_ADVANCED_ORT8850 lattice 9.0 01-jan-9999 uncounted
2645BEDC38F6 HOSTID=ANY
FEATURE LSC_ADVANCED_PCI lattice 10.0 01-jan-9999 uncounted
28737B9BA88B HOSTID=ANY
FEATURE LSC_ADVANCED_PCI_MACO lattice 10.0 01-jan-9999 uncounted
2C481E792E16 HOSTID=ANY
FEATURE LSC_ADVANCED_PLUS lattice 8.0 01-jan-9999 uncounted
5D3951FEC095 HOSTID=ANY
FEATURE LSC_ADVANCED_SPI4 lattice 10.0 01-jan-9999 uncounted
A3823192B587 HOSTID=ANY
FEATURE LSC_ADVANCED_SPI4_25LLM0 lattice 10.0 01-jan-9999 uncounted
738E4582A946 HOSTID=ANY
FEATURE LSC_CLASSIC lattice 10.0 01-jan-9999 uncounted 275097B247D1
HOSTID=ANY
FEATURE LSC_DIAMOND_A lattice 10.0 01-jan-9999 uncounted 4AAED9D8068E
HOSTID=ANY
FEATURE LSC_SYNPLIFY lattice 10.000 1-jan-9999 uncounted 8E52C4F86F30
HOSTID=ANY
FEATURE LSC_SYNPLIFYPRO1 lattice 10.000 1-jan-9999 uncounted
411DD7556BA8 HOSTID=ANY
FEATURE LSC_WARRANTY lattice 10.000 1-dec-9999 uncounted F4620A8B6EA0
HOSTID=ANY
FEATURE LSC_CONTROL_INCFLOW lattice 10.000 1-dec-9999 uncounted
31EC2B26739A HOSTID=ANY
FEATURE LSC_IP_fir_comp_e3_ipe lattice 10.000 31-dec-2025 uncounted
3152599ADCC0 HOSTID=ANY
FEATURE LSC_IP_fir_comp_pm_ipe lattice 10.000 31-dec-2025 uncounted
B7EFE0974E39 HOSTID=ANY
FEATURE LSC_IP_fir_comp_x2_ipe lattice 10.000 31-dec-2025 uncounted
67F56168DBE8 HOSTID=ANY
FEATURE LSC_IP_tri_sdi_e3_ipe lattice 10.000 31-dec-2025 uncounted
F8A64B04F058 HOSTID=ANY
FEATURE LSC_IP_nco_dds_x2_ipe lattice 10.000 31-dec-2025 uncounted
C1AA8E1D7667 HOSTID=ANY
FEATURE LSC_IP_nco_dds_e3_ipe lattice 10.000 31-dec-2025 uncounted
9B026E1CD069 HOSTID=ANY
FEATURE LSC_IP_nco_dds_pm_ipe lattice 10.000 31-dec-2025 uncounted
A634E3068684 HOSTID=ANY
FEATURE LSC_IP_cic_filtr_x2_ipe lattice 10.000 31-dec-2025 uncounted
5B57318F70B9 HOSTID=ANY
FEATURE LSC_IP_ts_mac_e3_ipe lattice 10.0 31-dec-2025 uncounted
61EB65B1A0D2 HOSTID=ANY
FEATURE LSC_IP_ts_mac_pm_ipe lattice 10.0 31-dec-2025 uncounted
D20AAE91B0E8 HOSTID=ANY
FEATURE LSC_IP_ts_mac_x2_ipe lattice 10.0 31-dec-2025 uncounted
5B995171A8CD HOSTID=ANY
FEATURE LSC_IP_ddr2_p_pm_ipe lattice 10.0 31-dec-2025 uncounted
B40D56D40196 HOSTID=ANY
FEATURE LSC_IP_ddr2_p_x2_ipe lattice 10.0 31-dec-2025 uncounted
40B2EFD40975 HOSTID=ANY
FEATURE LSC_IP_ddr2_p_e3_ipe lattice 10.0 31-dec-2025 uncounted
593E07CC1180 HOSTID=ANY
FEATURE LSC_IP_ddr_p_pm_ipe lattice 10.0 31-dec-2025 uncounted
79B8888680FF HOSTID=ANY
FEATURE LSC_IP_ddr_p_x2_ipe lattice 10.0 31-dec-2025 uncounted
891CE3B07807 HOSTID=ANY
FEATURE LSC_IP_ddr_p_e3_ipe lattice 10.0 31-dec-2025 uncounted
D659459B93EC HOSTID=ANY
FEATURE LSC_IP_pci_t32_e3_ipe lattice 10.0 31-dec-2025 uncounted
AB5CF3E89F26 HOSTID=ANY
FEATURE LSC_IP_pci_mt32_e3_ipe lattice 10.0 31-dec-2025 uncounted
9C75314C842C HOSTID=ANY
FEATURE LSC_IP_pci_t64_e3_ipe lattice 10.0 31-dec-2025 uncounted
21E7F1ED7D2E HOSTID=ANY
FEATURE LSC_IP_pci_mt64_e3_ipe lattice 10.0 31-dec-2025 uncounted
F98938497F31 HOSTID=ANY
FEATURE LSC_IP_edge_det_x2_ipe lattice 10.0 31-dec-2025 uncounted
2E22250B008C HOSTID=ANY
FEATURE LSC_IP_edge_det_e3_ipe lattice 10.0 31-dec-2025 uncounted
C623531BFD9E HOSTID=ANY
FEATURE LSC_IP_csc_x2_ipe lattice 10.0 31-dec-2025 uncounted
666536384764 HOSTID=ANY
FEATURE LSC_IP_sgmii_e3_ipe lattice 10.0 31-dec-2025 uncounted
DCD0672C4833 HOSTID=ANY
FEATURE LSC_IP_pcie_x1_e3_ipe lattice 10.0 31-dec-2025 uncounted
307A9A056686 HOSTID=ANY
FEATURE LSC_IP_pcie_x4_e3_ipe lattice 10.0 31-dec-2025 uncounted
A940A1006389 HOSTID=ANY
FEATURE LSC_IP_ddr3_p_e3_ipe lattice 10.0 31-dec-2025 uncounted
80BEE8D6FE76 HOSTID=ANY
FEATURE LSC_IP_scaler_e3_ipe lattice 10.0 31-dec-2025 uncounted
44335B509C22 HOSTID=ANY
FEATURE LSC_IP_scaler_x2_ipe lattice 10.0 31-dec-2025 uncounted
34658B6C9425 HOSTID=ANY
FEATURE LSC_IP_divide_e3_ipe lattice 10.0 31-dec-2025 uncounted
003943ABF469 HOSTID=ANY
FEATURE LSC_IP_divide_x2_ipe lattice 10.0 31-dec-2025 uncounted
8BC9A567EC6E HOSTID=ANY

[xjordanx]

It might be too much to hope for in the near term but I think what we all need is the FPGA / CPLD equivalent of RISC-V.

A truly open-source HARDWARE architecture in SILICON for programmable devices, that can be customized with building blocks and follows an open free industry standard for programming, fitting, optimization etc.

As you said, like GCC, but open down to the gate / synthesis level, so any silicon vendor can make them (or we as a community of users can group-buy) and then anyone can write the software to program them (or adapt existing OSS flows with Icarus etc.).

I'm also a capitalist, and want to make good money, and money does make the world spin whether it's in the hands of capitalists or governments - no system is ever going to be perfect. That said, I'm also not an open source zealot (not even close) however I do see the value in this idea and would love to see it come to life in future, as it has with RISC-V. I think there'll always be room for closed "specialized" devices but we also need something open.

My 2c...
/Ben J.

[Sonic2k]

The content of the license.dat file provided in this thread works and will give you access to your previous work. It even works with version 1.8 of iSPLever Classic. Tested on my end and confirmed to work.

Regarding the corporate a-holery, this is not going to go away unless the world is changed drastically either by war or some other event. Not even the 'rona was sufficient to change the corporate greed trajectory.

Some companies such as ST Micro, etc, embrace open source. Others, like Lattice, NXP, and Freescale fight against it even in 2024. Freescale still want to charge $895 for their ancient C compilers (that don't even comply with C11) and all that's keeping them afloat is the automotive sector. Nobody wants to use their product.

This is what happens when accountants are allowed to run a company instead of the people who know how to make products, typically the people who created the company in the first place. The accountants suck up to the shareholders who have the accountants' balls in a vise. Profit at all costs!

I've been on both ends of the spectrum.
You can make a ton of profit with open source tools provided to your customers. Your CEO gets his Mercedes as expected
You can charge $895 for your tools. Your CEO gets an Airbus A320 to himself, a Maybach, 12 houses and all his kids enjoy more luxury than kings in many countries.

Which of these two indicates the greatest amount of greed?