Author Topic: FPGA Design Security, Without Limiting Modification  (Read 1611 times)

0 Members and 1 Guest are viewing this topic.

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
FPGA Design Security, Without Limiting Modification
« on: September 24, 2022, 07:26:38 am »
I have a board I designed and sell to a major networking company.  We recently had some manufacturing issues because of component availability (not the semiconductor shortage, but a factory fire).  They are still happy to work with me, and are asking for a redesign of the board to remove the parts we can't buy any longer.

As part of this, they want the right to manufacture the board, if my company is "unable to build or deliver forecasted quantities due to unforeseen supply chain circumstances, IP and manufacturing rights would be relinquished over to" XYZ company. 

The IP rights would absolutely not be transferred, in the sense of them owning the design.  But I'm ok with them making the boards, as long as they pay royalties. 

The question here is, how can I provide them with the design for manufacturing without also giving away the keys?

First pass thought, use an SRAM FPGA with a separate Flash chip.  Flash chip is copyrighted.  Let the law protect me.  lol  I expect a major US company would not violate this protection.  However...

It seems clear to me, their intent is to have the IP for making the board, but also for maintenance.  We made some minor mods to rev 1 and rev 2 of the board after in production (this will be rev 3, of course).  Or maybe not.  Maybe the IP rights are requested just to avoid any claims of copyright violation???  As long as they pay me, I'm fine.

Still, if I want to give them sources to the FPGA code, is there a way to protect the IP rights from being copied without compensation?  I found this page at Intel. 

https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-examples/vertical/ref-des-secur-mem.html

Seems to be about a chip that could be sold (I assume programmed) so the design can't run without it.  They don't actually give much details, so I'm not clear.  However, it looks like it only protects the bitstream and could easily be worked around if you recompile the sources. 

I know there are a few one time programmable FPGAs, but I'm not very familiar with them.  The Lattice iCE40 parts have nonvolatile, one time programmable memory.  I could specify the part number of a programmed chip, but they still would be able to work around this if they had a source code.

I think the secure Xilinx chips had to have the key programmed after assembly with the key backed up by a cap or something. 

By selling them a physical entity, it allows me to know how many they are building.  That's a good feature.  I might even be able to have a distributor handle all the order taking and give me my cut! 

I'm starting to think this is not going to be so easy to figure out.  I'm sure I'm not the only one to want something like this.

Just to be clear, I'm not expecting this to foil major attempts to break security.  It's not state secrets. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: FPGA Design Security, Without Limiting Modification
« Reply #1 on: September 24, 2022, 10:49:31 am »
A pretty old FPGA protection idea not requiring any special FPGAs: a small, but essential part of design is moved into a separate small CPLD connected to a bigger FPGA doing the major work. You keep the CPLD content in secret, program them, ship to the manufacturer and thus control the production quantity.
Seen that implemented in some instruments - a big Spartan plus a small CoolRunner. One of them (a Swiss-made USB analyzer) even had the CPLD programmed by some 3rd party mass programming company (or Xilinx themselves?) with a custom name lasered below the CPLD name, so the designer company even didn’t need to run their own mass programming, passing that to a reputable 3rd party.
 
The following users thanked this post: hamster_nz

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: FPGA Design Security, Without Limiting Modification
« Reply #2 on: September 24, 2022, 11:20:36 am »
if you give them the source I don't see how you can stop them building their own

the xilinx fpgas have one time programmable efuses, so you can give them an encrypted bitfile and it'll only work on fpgas that have the right key in efuses, but it requires you program the key in every fpga
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #3 on: September 24, 2022, 06:35:27 pm »
if you give them the source I don't see how you can stop them building their own

the xilinx fpgas have one time programmable efuses, so you can give them an encrypted bitfile and it'll only work on fpgas that have the right key in efuses, but it requires you program the key in every fpga

If I give them the source, encrypting the bit file won't accomplish anything. 

I'm thinking more in terms of what abyrvalg wrote, but even then, if they want the source to the FPGA, they will want the source to the CPLD. 

A dedicated chip that would make the design not work without it would work.  That's what they were essentially talking about in the paper, but even that requires a part of the design to disable the FPGA without the "key" chip.  Putting any functional part of the design into a separate CPLD or other programmable device would allow them to design around that.

I was thinking of something like a Maxim chip that has a unique serial number in each one.  I could reserve a bank of 20,000+ serial numbers in my company name.  They can not be sold to anyone but me.  But how to make the FPGA not work without the chip?  If the method described in the paper were part of the FPGA, rather than software, maybe that would work.  Or, a method where the FPGA itself has some aspect that they must buy them through me.  Even this has the issue of the customer simply buying the non-keyed FPGAs and compiling the software to run on those! 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: FPGA Design Security, Without Limiting Modification
« Reply #4 on: September 24, 2022, 07:44:01 pm »
If your customer is willing to buy a license for the code and you're willing to sell it for a bunch of money, sell it on a non-exclusive basis.  You retain the right to sell the same code elsewhere for different or even identical applications.  If they want an exclusive license, the price goes way up.

Engineering is fun, production is boring.  Sell the code for as much as you can get and walk away.  Or, take an equity position in your customer's company.  Profit is fun too!  A license fee based on sales is a pretty good idea.  They don't pay if the product doesn't sell and you're motivated to do upgrades for increased earnings.

You can try to work with hardware security but, in the end, it doesn't work under all conditions.  Sometimes the application is so obvious that the code simply flows from your fingers.  Once it is known that a problem can be solved, alternative solutions abound.

 
The following users thanked this post: SiliconWizard

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: FPGA Design Security, Without Limiting Modification
« Reply #5 on: September 24, 2022, 10:10:36 pm »
if you give them the source I don't see how you can stop them building their own

the xilinx fpgas have one time programmable efuses, so you can give them an encrypted bitfile and it'll only work on fpgas that have the right key in efuses, but it requires you program the key in every fpga

If I give them the source, encrypting the bit file won't accomplish anything. 

I'm thinking more in terms of what abyrvalg wrote, but even then, if they want the source to the FPGA, they will want the source to the CPLD. 

A dedicated chip that would make the design not work without it would work.  That's what they were essentially talking about in the paper, but even that requires a part of the design to disable the FPGA without the "key" chip.  Putting any functional part of the design into a separate CPLD or other programmable device would allow them to design around that.

I was thinking of something like a Maxim chip that has a unique serial number in each one.  I could reserve a bank of 20,000+ serial numbers in my company name.  They can not be sold to anyone but me.  But how to make the FPGA not work without the chip?  If the method described in the paper were part of the FPGA, rather than software, maybe that would work.  Or, a method where the FPGA itself has some aspect that they must buy them through me.  Even this has the issue of the customer simply buying the non-keyed FPGAs and compiling the software to run on those!

if you give them the source all bets are off, they can just remove that part that checks what ever scheme you come up with
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: FPGA Design Security, Without Limiting Modification
« Reply #6 on: September 24, 2022, 11:15:27 pm »
Well, with the minor extra costs, if what you use Altera's MAX10 series.  The bootprom is internal, can hold 2 bootable firmwares, securable, and can also be used to hold user data.  Actually, quite a bit of user space if you drop one of the bootable firmwares and/or disable the power-up memory block initialization function.

Though, you will need to receive the FPGAs to program them yourself, then you would send them to your client for mounting.

(note that if it hasn't changed in the last decade, I think you need a paid version of Quartus to enable the security JTAG firmware mode.  However, once enabled, nobody will be getting the ability to replicate your internal firmware.)
« Last Edit: September 24, 2022, 11:28:49 pm by BrianHG »
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: FPGA Design Security, Without Limiting Modification
« Reply #7 on: September 25, 2022, 12:04:49 am »
Well, with the minor extra costs, if what you use Altera's MAX10 series.  The bootprom is internal, can hold 2 bootable firmwares, securable, and can also be used to hold user data.  Actually, quite a bit of user space if you drop one of the bootable firmwares and/or disable the power-up memory block initialization function.

Though, you will need to receive the FPGAs to program them yourself, then you would send them to your client for mounting.

same issue as with the xilinx efuse bit file encryption, but if they have the source none of it helps
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: FPGA Design Security, Without Limiting Modification
« Reply #8 on: September 25, 2022, 12:29:44 am »
Note that for one of my FPGA designs, I use a sub 0.50$ SO-8 microchip keylock chip as my unlock key.  My client has the fpga bootprom file, but not the FPGA HDL source.  They need my KEY microchip MCU which I provide to make the project FPGA work.

Reconstructing the FPGA HDL from the bit-stream I gave them to nullify the power-up activation mechanism isn't going to realistically happen.

Reverse engineering the protected 8bit MCU's 128bit encryption key via analysis is tough as the IO interface is too slow to brute force it.  Decapping the 8bit MCU and finding all the firmware protect fuses in an IC die designed for protecting it's internal fuses isn't impossible, but should be cost prohibited from finding such specialists to do the job.
« Last Edit: September 25, 2022, 12:51:40 am by BrianHG »
 
The following users thanked this post: Someone

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #9 on: September 25, 2022, 03:25:27 am »
If your customer is willing to buy a license for the code and you're willing to sell it for a bunch of money, sell it on a non-exclusive basis.  You retain the right to sell the same code elsewhere for different or even identical applications.  If they want an exclusive license, the price goes way up.

Engineering is fun, production is boring.  Sell the code for as much as you can get and walk away.  Or, take an equity position in your customer's company.  Profit is fun too!  A license fee based on sales is a pretty good idea.  They don't pay if the product doesn't sell and you're motivated to do upgrades for increased earnings.

You can try to work with hardware security but, in the end, it doesn't work under all conditions.  Sometimes the application is so obvious that the code simply flows from your fingers.  Once it is known that a problem can be solved, alternative solutions abound.

Yeah, I have no idea how much I might get as a one time payment.  But I'm very confident it is much less than I could get from continued production.  I've already made millions from the previous revision. 

The company is a multi billion dollar, international networking company.  I suppose they might give me stock instead of cash, but I can't see the point.

I'm seeing this as a one (more) time effort to get this into production, then continuing rewards in my retirement.  It's unlikely there will be further development and bugs are also unlikely.  The current version has been in production for over 10 years. 

We had a lot of issues with this past order, because one part was virtually impossible to obtain and I had to buy from Chinese grey market vendors.  They aren't all crooks, but you can't tell which are and which aren't.  None will give you credit, but they expect their payment up front.  I finally found a US broker who could deal with them and did some testing on the last batch of parts, finding enough corrosion that we had to reject them.  That saved me $175,000! 

No, I want to make these boards in a US factory that I trust.  I might set it up so they take and fill the orders, and I get a fat royalty on each one.  But that means I have to get past the IP issue.  I suppose I can talk to them about it some more.  Maybe they are just talking Gerbers, BOMs and bit files.  But I expect they will want the sources, digital schematics, VHDL, etc.  We'll see.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #10 on: September 25, 2022, 03:31:48 am »
Well, with the minor extra costs, if what you use Altera's MAX10 series.  The bootprom is internal, can hold 2 bootable firmwares, securable, and can also be used to hold user data.  Actually, quite a bit of user space if you drop one of the bootable firmwares and/or disable the power-up memory block initialization function.

Though, you will need to receive the FPGAs to program them yourself, then you would send them to your client for mounting.

(note that if it hasn't changed in the last decade, I think you need a paid version of Quartus to enable the security JTAG firmware mode.  However, once enabled, nobody will be getting the ability to replicate your internal firmware.)

I'm not certain what you are describing.  It sounds like bit stream protection.  I'm expecting my customer will want the source code.  But I suppose we can negotiate that. 

At one time, as a money saving effort, I looked into buying the Lattice Flash based FPGAs pre-programmed.  They would have a custom part number.  Cost was about $0.50 a chip, as I recall.  But still, giving the customer source so they can modify it, means they can buy the regular chip and burn it.  Unless the chip has not markings from the manufacturer.  Still, that seems pretty weak to me. 

They could also use a different FPGA and reroute the board, but at some point the cost becomes an incentive to just pay me.  They say it is in case my company can't ship product. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 629
  • Country: ca
Re: FPGA Design Security, Without Limiting Modification
« Reply #11 on: September 26, 2022, 04:01:40 pm »
Use distributors programming and device marking services. You will get a special part number assigned to you, your part will look like some specialty ASIC, and you will know how many were sold.
I am available for freelance work.
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3686
  • Country: us
Re: FPGA Design Security, Without Limiting Modification
« Reply #12 on: September 26, 2022, 05:25:56 pm »
I'm not certain what you are describing.  It sounds like bit stream protection.  I'm expecting my customer will want the source code.  But I suppose we can negotiate that. 

At one time, as a money saving effort, I looked into buying the Lattice Flash based FPGAs pre-programmed.  They would have a custom part number.  Cost was about $0.50 a chip, as I recall.  But still, giving the customer source so they can modify it, means they can buy the regular chip and burn it.  Unless the chip has not markings from the manufacturer.  Still, that seems pretty weak to me. 

They could also use a different FPGA and reroute the board, but at some point the cost becomes an incentive to just pay me.  They say it is in case my company can't ship product.

It's really not clear what you are actually looking for.  To state the (hopefully) obvious, you can't give them the unencrypted modifiable source code and also implement useful technical protections against them using it without paying you.

I suggest treating this as two completely unrelated problems.

If you want to give them the ability to manufacture unmodified boards on their own, then selling them preprogrammed FPGAs is probably the easiest way to do it.

If the customer wants modifications they should either pay you R&D costs or they should be licensing or buying the code from you.

More or less you have to count on them to act honestly.  Technical obstructions are both to make it clear when they are violating the agreement and also in the hopefully unlikely case that end up suing them, to demonstrate intent. You have the advantage that if you have been selling them these for years, you must have some idea on the expected volume.  If you see a major drop in volume that they are paying for then you will have an idea something is up.
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #13 on: September 26, 2022, 06:36:15 pm »
There's already an FPGA on the board.  There's no real need to partition any of that out of the FPGA into a CPLD and, in fact, I can't think of any part of it that would be a good idea to partition out.  There are some mode controls for the CODEC which generally are fixed, but could be selectable in principle. 

One choice I'm considering is replacing some of the opamps in the design with a GreenPak device which contains two opamps, externally accessible.  The part also includes a "rheostat" which could be used to control a gain setting, or possibly a filter corner frequency.  This is a bit of a reach, but could suffice. 

I have a need to connect a 5V RS-422 driver/receiver chip.  If the part also supported 5V to 3.3V level shifting, that would be great, but I don't think it will.  SLG47004 is the only part in their product line that is even close to something I could use.  Well, not true...  They have some parts with up to four LDOs, which could be a good part, even if I didn't need a custom, SLG46580. 

So maybe use both chips and I can assure the royalty by splitting it between the two chips.  Maybe the LDO can do the 5V/3V conversion, but I haven't found anything that says this would work. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: FPGA Design Security, Without Limiting Modification
« Reply #14 on: September 26, 2022, 07:21:55 pm »
Can't an attorney hold it in escrow? Let them examine the content of some backup media on a controlled computer if they want, then the attorney locks it into his vault till the contract stipulations are triggered.
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #15 on: September 26, 2022, 08:15:59 pm »
Can't an attorney hold it in escrow? Let them examine the content of some backup media on a controlled computer if they want, then the attorney locks it into his vault till the contract stipulations are triggered.

That won't get me my royalty payments.  Once they have the IP, the cat's out of the bag and they might make 10,000 units without payment. 

Actually, even if they don't want to cheat me, there are so many pitfalls, such as building board, but not shipping them to customers.  Do I get a royalty when built, or only when shipped, invoiced and paid?  Too much crap involved in trying to work that out.  Much better to have parts on the board they can only buy through me. 
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4393
  • Country: dk
Re: FPGA Design Security, Without Limiting Modification
« Reply #16 on: September 26, 2022, 08:28:30 pm »
Can't an attorney hold it in escrow? Let them examine the content of some backup media on a controlled computer if they want, then the attorney locks it into his vault till the contract stipulations are triggered.

That won't get me my royalty payments.  Once they have the IP, the cat's out of the bag and they might make 10,000 units without payment. 

Actually, even if they don't want to cheat me, there are so many pitfalls, such as building board, but not shipping them to customers.  Do I get a royalty when built, or only when shipped, invoiced and paid?  Too much crap involved in trying to work that out.  Much better to have parts on the board they can only buy through me.

only way to do that is to withhold the source
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: FPGA Design Security, Without Limiting Modification
« Reply #17 on: September 26, 2022, 08:30:55 pm »
That won't get me my royalty payments.

You still have copyrights, you're a bit more reliant on their honest at that point but your legal leverage to get royalties isn't completely gone. As long as you're delivering boards, it also simply wouldn't get triggered.

I got the feeling they wanted to protect themselves against you say getting a heart attack too and no one having easy access and ability to sell the boards or IP at that point.
 
The following users thanked this post: Someone

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #18 on: September 26, 2022, 09:18:35 pm »
That won't get me my royalty payments.  Once they have the IP, the cat's out of the bag and they might make 10,000 units without payment. 

Actually, even if they don't want to cheat me, there are so many pitfalls, such as building board, but not shipping them to customers.  Do I get a royalty when built, or only when shipped, invoiced and paid?  Too much crap involved in trying to work that out.  Much better to have parts on the board they can only buy through me.

only way to do that is to withhold the source

Yes.  I don't think I can withhold the FPGA source and make them happy.  But for small parts like these, I expect no one will realize up front, they are programmable devices.  Even when they order them, they may be surprised by the price, but still may not know they are programmable.  As long as they are available for sale, I think I am good to go. 

The agreement is about them taking over manufacturing, if I can't meet the deadlines.  In particular, that can be manipulated readily.  I've received purchase orders before, with a requested delivery date prior to the date of the PO! 

As long as they don't have an issue with sticking to the agreement of paying me, they will have no concerns.  The programming in these chips will be so minimal, that there will literally be nothing to change.  The LDO chip will have LDOs.  The opamp chip will have opamps and rheostats.  Heck, 95% of each chip will be wasted.  There's just no use for comparators, etc.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3686
  • Country: us
Re: FPGA Design Security, Without Limiting Modification
« Reply #19 on: September 26, 2022, 11:09:23 pm »
I agree that selling them pre-programmed chips is by far the easiest option especially for a small shop like I assume you are.

One question about any contract with royalties is how could you tell if they were cheating.  For instance, do you know what final products they are using it in?  Are they sold publicly or used internally by the customer? Are sales volumes for the product(s) in question published?  Would you be able to examine one of their products to show it was using your design?  The easier it is to tell if they are cheating the more confident you can be in the royalty payments. 

Regardless, make sure to have a lawyer look over the proposed contract, especially if involves "triggers" like you being unable to meet forecast demand.

Quote
Yes.  I don't think I can withhold the FPGA source and make them happy.  But for small parts like these, I expect no one will realize up front, they are programmable devices.  Even when they order them, they may be surprised by the price, but still may not know they are programmable.  As long as they are available for sale, I think I am good to go.

I don't really understand what you are saying here, and it sounds like you might be assuming your customers are idiots, which isn't a great look.  You say they definitely want the FPGA code but won't realize that the components you sell are programmable?  I find that unlikely.  Especially if you give them a manufacturing dataset and a BOM and their CM comes back and says it's $5 worth of materials except for the single small chip that they have to buy from you for $100 (obviously numbers I just made up, but scale as appropriate).  It's certainly possible the entire cost will just be under what they are interested in looking at, but if someone looks at that BOM and says "can we reduce the cost of our whole product by replacing this one part" they are going to look into what that part is.  If it's clearly explained in the agreement that when they buy the chip from you they are paying for the software/firmware license and effective royalties for the entire design that's probably fine.  If this comes off to them as deceptive that's probably not good for your continued business relationship.
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #20 on: September 26, 2022, 11:37:17 pm »
They won't be buying anything from me in the strict sense.  I'll likely propose that I do the design on my dime.  They will be required to buy an initial set of boards for an appropriate "prototype" cost. 

I have not found lawyers to be terribly useful for this purpose actually.  They have their own perspective.  They don't know exactly what is important to me.  In the previous negotiation, they missed the two contradictory clauses that controlled cancellation of of the order as well as missing that the PO (which always refers to their own terms and conditions) was the most recent document, so might actually prevail inspite of the clause that said the T&C could not be modified other than by an explicit document signed by both parties.  I've learned my lesson from this.  Insist the PO specifically defers to the negotiated T&C. 

Yeah, that was eye opening! 

"Idiots"... lol.  Being a large company, they often do not communicate between the right hand and left.  Even if they do realize there can be BOM savings, that assumes they understand what the "black boxes" on the schematic do.  Also, that will only happen long after all the contracting is  negotiated.  No matter what, they will be required to pay a royalty for every unit made, including derived works.  These machinations are merely a way for me to assure they pay for every unit, without my needing to inspect their books.  Not like they will let me inspect anything.  They are a multi-billion dollar company, and I'm... not. 

This is something that will very likely get past their first line, and let us get into production.  I don't expect we will have any significant problems that will result in them wanting to take over production and discover there are two parts on the board with very high price tags.  If this does happen, it will be down the road.

But talking about this makes me realize, if I want royalties, I may have to indicate they will be in the form of buying the two chips.  Otherwise, it would be hard to ask for the royalty and at the same time have a high price on the two chips.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline gnuarmTopic starter

  • Super Contributor
  • ***
  • Posts: 2218
  • Country: pr
Re: FPGA Design Security, Without Limiting Modification
« Reply #21 on: September 26, 2022, 11:39:36 pm »
Possibly, I would not need to try to collect the royalty through the chips.  They could however, serve as an indicator of how many units they are building.  Since it is my design, my custom part, I expect I could get info from the supplier on who is buying what. 

That would be good enough to track royalties due.
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf