If the inventor files non-provisional on time, auction cancels; if not, highest bidder takes it.
Does this make sense to buyers?
What kills interest the most: lack of diligence (no full content pre-bid), validity risk, or liquidity?
What minimum criteria would you require before bidding?
A companion write-up for the animated chart of Intel's patent-litigation adversaries, 1983–2026.
Each bar is one year. Its height is the number of distinct adversaries Intel faced in new patent/trademark-infringement suits that year, split by type:
Across 1983–2026 that's 219 adversary-year appearances from 170 distinct adversaries.
1. Intel is overwhelmingly a target, not an aggressor: Of the cases analyzed, Intel was the defendant 205 times and the plaintiff only 28. It gets sued ~7× more often than it sues.
2. The nature of the attacker flipped: Patent trolls went from a clear minority to the majority of Intel's opponents:
| Era | NPE share of adversaries |
|---|---|
| 1983–1999 | 14% (5 of 35) |
| 2000–2009 | 56% (31 of 55) |
| 2010–2026 | 53% (69 of 129) |
In the 1980s–90s Intel's fights were with real chip companies (AMD, Cyrix, Chips & Technologies, Hyundai). From the 2000s on, litigation became a toll: entities that build nothing collecting from a company that builds everything.
3. The busiest years are recent: The peak for new distinct adversaries in a single year is 2020 (13), followed by 2010 (12). But the more telling metric is the active caseload — lawsuits actually open in a given year (new + earlier ones not yet closed). That climbs relentlessly and peaks at 30 simultaneous active cases in 2022, staying in the 25–30 range across the modern era. The siege never really lets up.
All data comes from the Unified Patents litigation database (portal.unifiedpatents.com), which aggregates U.S. patent/trademark infringement dockets across District Courts, the Federal Circuit (CAFC), the ITC, the Court of Federal Claims, and the Supreme Court. The records cover cause of action, parties (plaintiff/defendant), filing date, current status, termination date, court, judge, and industry.
A Python crawler queries Unified Patents' public Elasticsearch endpoint directly (no scraping of the rendered UI), paginating through every infringement-type case. For each case it pulls: filing date, closed/termination date, status, plaintiff(s), defendant(s), cause of action, court, judge, and an industry tag. The full pull is ~74,000 cases; this analysis filters to those where Intel is a party (word-boundary match, so "Intel" doesn't catch "Intellectual Ventures").
Python (pandas, numpy, matplotlib) for processing and the animation; the Unified Patents Elasticsearch API for data; company logos from logo.dev, Wikidata (P154), and the USPTO trademark database.
I’m trying to understand what people actually rely on when enabling LR/SC-based lock-free code on RISC-V.
"A" tells me LR/SC exists, but it does not seem to tell me the reservation granularity a runtime/RTOS should assume.
In practice, do people just:
The part I’m looking for is public documentation. Are there RISC-V core manuals that explicitly state LR/SC reservation size and invalidation rules?
Not trying to make a grand claim here, just trying to find what real projects use as their contract.
I experimented with eight techniques that are sometimes suggested for distinguishing RISC-V hardware from emulation:
rdcycle behaviorfence.iMy actual test target was QEMU. Some of the techniques detected particular QEMU modes or configurations. For example, an unavailable instruction or CSR may expose an incomplete virtual CPU configuration. But none of the tests provided evidence that could reasonably be called hardware attestation.
The distinction I came away with is:
The threat model considered here is deliberately narrow:
The experiments do not prove that every possible software-only detector must fail. My broader argument is that any behavior entirely visible through the ISA can, in principle, be reproduced by an emulator that knows the detection procedure.
I wrote up the tests, assembly snippets, results, and limitations here:
I would be interested in counterexamples under the stated threat model:
Is there a U-mode-visible property that could establish execution on a physical device, rather than merely identify a particular emulator implementation or configuration?
Edit:
The motivating scenario is evasive malware that remains dormant under QEMU-based analysis and activates only on the physical target.
Built from the registry's conflict detector. Every edge is an encoding collision between two extensions.
The red cluster is: FATAL same opcode, different instruction.
The custom-space cluster (67 warnings) is everyone reaching for custom-0.
Interactive: extensilica.com/compatibility
=============================================
EDIT (June 11, 2026): brucehoult and XIVN1987 correctly identified that shared major opcodes (like every RVV instruction sitting at OP-V 0x57) were being reported as FATAL conflicts on the compatibility graph. That was a too-coarse classification on my end.
Fix is live: those edges now read as INFO ("shared major opcode; not a conflict by itself. A true conflict requires overlapping full decode mask/match patterns, including any fixed register/immediate field constraints"). Full mask/match resolution (funct6, vm, register/immediate carve-outs) is the next iteration.
See https://extensilica.com/compatibility for the updated graph; technical details in the comments below.
Follow-up to my earlier post announcing extensilica.com: a few of you pushed back on it, fair enough. So instead of more promises, here's the first full port, end to end, on video.
The NIST scalar-crypto family (zbkb, zknh, zksh, zkne, zknd) now builds and runs from a clean Ubuntu VM in 3 commands. No manual cross-compiler, no compiling Spike from source, no proxy-kernel setup:
cargo install xsil
xsil install riscv-zbkb
xsil run riscv-zbkb
What happens under the hood: it pulls the toolchain + Spike (sha256-verified), compiles a real ELF, and runs it on Spike. The output in the video is straight from the simulator, not hardcoded.
The 5 packages share the same simulator/toolchain, so installing one caches the rest for the others.
Sample run (zbkb):
zbkb demo:
x = 0123456789abcdef
ror x, 8 = ef0123456789abcd
brev8 x = 80c4a2e691d5b3f7
rev8 x = efcdab8967452301
andn x,m = 010045008900cd00
Still genuinely want the criticism, especially on the shared-dependency model and where this falls apart on non-Ubuntu / non-x86 hosts. The pushback on the first post is part of why this exists. Vector crypto (RVV) is next.
Registry + packages: extensilica.com
Hey r/RISCV,
I’ve been frustrated by how hard it still is to reproduce a RISC-V extension from a paper, datasheet, vendor document, or research repository.
Too often the path is:
So I built ExtenSilica:
The goal is simple:
Make RISC-V ISA extensions easier to package, run, test, and eventually verify.
No committee can make an extension reproducible.
Only executable artifacts can.
ExtenSilica is independent, experimental, and built in public. I am not waiting for permission to test this idea. The only validation that matters now is whether RISC-V ISA extensions can become runnable, testable, and reproducible packages.
A .xsil file is a gzip-tar package with:
The CLI is written in Rust and published on crates.io:
cargo install xsil
xsil install rvx-demo
xsil run rvx-demo
Published versions are intended to be immutable. The CLI verifies hashes before running.
The registry currently tracks 102 RISC-V ISA extension entries:
Most entries are RL1 today: packaged scaffolds and metadata, not end-to-end verified ports.
That is intentional.
A package should not become “verified” because someone added a badge. Higher readiness levels should require real evidence: simulator runs, tests, logs, dependency assumptions, RTL/FPGA artifacts where applicable, and eventually a verification methodology serious enough for hardware people to trust.
Spec / CLI source: https://github.com/ExtenSilica/xsil
If you maintain a RISC-V extension, research artifact, simulator fork, toolchain patch, RTL flow, FPGA evaluation setup, or teaching material, this is the moment to claim or publish it.
The first people who help turn seeded entries into real XSIL packages will be recorded as founding contributors in the ExtenSilica registry.
Not as investors.
Not as speculators.
As maintainers, reviewers, package authors, and early builders of a missing RISC-V infrastructure layer.
No payments. No marketplace. No token sale. No affiliation with RISC-V International. No endorsement implied.
Just a prototype, a catalog, a package format, a CLI, and a long road ahead.
RISC-V does not need more isolated extension islands.
We need to pull this together.
Tear it apart,
I wrote a short formal note and would appreciate technical criticism from people familiar with cache/memory interference models.
The claim is intentionally narrow.
Under the following assumptions:
the per-critical-access stall imposed on a target task is bounded by:
(N - 1) * Lmem
where N - 1 is the number of adversarial cores and Lmem is the fixed latency of one serialized L2 miss / memory service.
The paper also gives an attaining construction: the other N - 1 cores issue synchronized congruent-different-tag memory requests in phase with the target task’s critical access.
I am not claiming this applies to arbitrary modern COTS multicore CPUs. It does not. The model is deliberately constrained.
What I am looking for is criticism of the proof itself.
A useful counterexample would be an admissible trace, inside the stated assumptions, that causes a critical access to suffer more than (N - 1) * Lmem.