I do agree with you. What would have been a better incentive, or do you think the prior system was better? 

Personally, it actually motivated me to be a bit more active and finish my post. But I have also noticed a bit of "farming" for points (which was very much a consideration I'm sure, hence "good heart token").

I think the reason it appealed to me was that the feedback mechanism was tangible and (somewhat) immediate. Contrast that with, say, pure upvotes, which feel non-impactful to me. 

I think an incentive is good, but one that is less than pure dollar values and more than ego-filling-warm-fuzzy-feeling upvotes.

Sorry, what does "hansonpilled" mean? Does Robin Hanson have some insight on this as well?

Those two links are the same. But yeah I'm referring to the latter, w.r.t fuzzing of the synthesized devices.

"Fuzzing" as a concept is used, but not very "block-level" (some some exceptions, e.g. you likely know about UVM's support for random data streams, coming from an FPGA background). The fuzzing analogue in hardware might be called "constrained random verification".

Fuzzing as I've heard it referenced is more of a jargon used in the software security world, the aforementioned AFL fuzzer being one example.

I do agree that traditional fuzzing isn't used in hardware is rather surprising to me.

Oh I guess, while I'm on the topic of "bringing software paradigms into the hardware world", let me also talk about CirctIR briefly. 

I also believe LLVM was a bit of a boon for the software security world, enabling some really cool symbolic execution and/or reverse engineering tools. CirctIR is an attempt to basically bring this "intermediate representation" idea to hardware.

This "generator for intermediate language representation", by the way, is similar to what Chisel currently does w.r.t generating verilog. But CirctIR is a little more generic, and frankly Chisel's generator (called FIRRTL) is annoying in many ways.

Chris Lattner worked at SiFive for a bit, and made these same observations, so he spearheaded the CirctIR movement. Partially as a result, there are many similarities with FIRRTL and CirctIR (Chisel's goal is to make hardware design easier, and CirctIR's goal is to make designs portable and/or decouple these toolchain flows. Related goals, but still differentiable)

.

I've wanted for some time to play with this as well, but the fuzzing work has gotten me more interested currently and something I'm trying to make an MVP for at work.

Hi, I'm a lurker. I work on CPUs. This also motivated me to post!

This is a rather niche topic, but I want to express it, because I greatly enjoy seeing other ramble about their deep-work domain expertise, so maybe someone will find this interesting too? This is relatively similar to the concept behind the podcast [What's your problem?], in which engineers talk about ridiculously niche problems that are integral to their field.

Anyways-- here's my problem.

Fuzzing (maybe known as mutation based testing, or coverage directed verification, or 10 other different names) has, in my opinion, been revolutionary for the software security industry. [AFL] is probably the best and most successful example, and I think most people would agree with me that this tool has saved millions of manhours in finding security vulnerabilities.

Why don't we have such tools in hardware? Well, my personal opinion is that EDA tools are rather monopolistic and cumbersome relative to e.g. GCC (e.g. imagine paying millions of dollars for a GCC release!), and a partial side-effect of that is that the language hardware codes in (verilog, systemverilog) is so ingrained we can't get out of it.

This is just barely starting to change.

[Here] is my personal top favorite of a contender. What makes this cool is not entirely revolutionary new ideas, but rather the sheer amount of effort to make things just work is truly truly commendable. 

The main perk of fuzzing is, frankly, finding low-ish hanging fruit. Just like how buffer overflows are, in some sense, a "known problem", there's a plethora of hardware vulnerabilities I've found that you wouldn't believe are insanely easy to find. And I firmly think this can be done by simple fuzzing.

My project plan? Convert the detected vulnerabilities into generated exploitable software vulnerabilities. And I think the above project can fit into the "detection" aspect-- honestly still a WIP for me to evaluate how good it is, or how complicated the fuzzer is (most of the time it's just a wrapper around SMT solvers), but it's something I'm excited about.

(On the "exploitable vulnerabilities" end, there is similar work [here], but I've done some experimentation with this and still find it rather cumbersome for a variety of details I won't get in to.)

I'm unfamiliar with the Berkeley area, is there a recommended parking area/garage?

1. Definitely not in the next 10 years. In some sense, that's what formal verification is all about. There's progress, but from my perspective, it's a very linear growth.
   The tools that I have seen (e.g. out of the RISC-V Summit, or DVCon) are difficult to adopt, and there's a large inertia you have to overcome since many big Semi companies already have their own custom flows built up over decades.
   I think it'll take a young plucky startup to adopt and push for the usage of these tools-- but even then, you need the talent to learn these tools, and frankly hardware is filled with old people.
2. I think we have different interpretations of "design". You consider chip design in the aggregate, but I'm subdividing it into multiple areas. There's several aspects of chip design, some of which can be automated, but I'm claiming never to an extreme extent as e.g. 1 month. This technology in particular really only helps in determining where to place "buildings" but not really much in actually building the "buildings" themselves. While valuable, there's only so much "placing" can do.
   My view is that, the time and money spent won't go down, just reallocated, which may or may not increase quality.
3. Sorry, I guess I meant the former where I incorporate every source, at least on the hardware side. Were you to isolate just the ML Chip placement gain... again, hard to say. It's just indicative of a release of resources, but who knows if those extra resources can/will be properly directed to something better?
4. + 5. : Sorry! I guess I meant post-design fabrication, which is really just a term I came up with to mean "shipping it to TSMC once you're done designing". A better term, in hindsight, is just called "tapeout", but I was hesitant to use the term time-to-tapeout since that feels cumulative rather than isolating that one period of time I mean.
   
   See: https://anysilicon.com/verification-validation-testing-asic-soc-designs-differences/
   
   What I mean is that, this technology is addressing the "Physical Design" blob of time as above. Notice that the whole critical path to "Shipping"/getting the chips out there goes "Verification"--> "Tapeout" --> "Validation"/Testing 
   
   Suppose the "Physical Design" time gets eliminated. These freed resources will most definitely go into "RTL Design" and not "Verification". That's what I mean by "creating new designs"-- it gives us more time to think of cool stuff, but again, depends if that stuff is good or not.
   
   Why will extra resources not be devoted to verification? That's a whole can of worms. Industry inertia, overlapping talent skillset, business models, design complexity-- but I guess most of all I'd say inertia. 
   
   On inertia-- as I said, this cadence takes about 1-2 years. We are so so so very accustomed to this cadence, I can't see it changing barring massive changes in our needs. If you told me you could reduce our verification time from 1 year to 11 months, I'd just spend that extra month iterating on my RTL design instead, or use that extra time to run more simulations, because 11 vs. 12 months doesn't mean much.
   
   If you told me I could reduce it from 1 year --> 6 months? I'd maaaaybe throw money at you. It has potential to double my income, but that depends.
   
   Imagine new iPhones came out every 6 months instead of yearly. Isn't that super weird? Well... That depends on how well Apple can market to me that I absolutely need it.
   
   Perhaps that differs for AI use cases... but even there, I'd argue this yearly cadence is ingrained already

I thought I wrote an answer to this. Turns out I didn't. Also, I am a horrific procrastinator. 

1. In some sense, I'd agree with this synthesis. 
   I say some sense, because the other bottleneck that lots of chip designs have is verification. Somebody has to test the new crazy shit a designer might create, right? To go back to our city planner analogy-- sure, perhaps you create the most optimal connections between buildings. But what if the designer but the doors on the roof, because it's the fastest way down?
   Yes, designs can be come up with faster, and can theoretically be fabbed out faster. But, as with anything that depends on humans, that itself 1) has a certain amount of complexity that builds technical debt and 2) requires inspection. 
   To me, this is like how software engineering has A) the actual development and B) the deployment to production. No matter how fast B) is, which may certainly aid in iteration, A) is still heavily gated by humans.
2. It's hard to give a concrete answer for that, since there are A) so many different AI models and B) so many different hardware architectures to run those AI models. AI is a full-stack problem, that honestly still has lots of room to grow, so any advance in any component of the stack will produce growth.
   Put a gun to my head though-- x = 3, y = 2
3. Though not in this specific paper/iteration, this technology definitely has potential to lower time-to-fab-- more specifically, post-silicon fabrication.
   But, you see, I don't think the barrier to entry is post-silicon fabrication. It is creating the design in the first place, and verifying it. This is what ARM does-- they already provide pre-verified designs (reference implementations) for you to rip off of and, as is, ship out. Just give them licensing fees!
   Furthermore, in many ways, a 1-2 year lead time is kinda built in already in our society (think of it-- you usually buy new hardware every couple years, right?). Thus, suppose you completely eliminate post-silicon fabrication times. Where would this extra time go? I highly doubt we would change our society-accepted cadence of hardware rotations. Most definitely, it would go right back into creating new designs-- human brains. Thus, I think the biggest barrier to entry is knowledge and engineering talent.
   Manufacturing talent is, frankly, thanks to TSMC's duopoly in foundries, not much of a barrier. Sure, it's a barrier that China is tackling (see the whole SMIC fiasco) but not one much of the Western world is willing to tackle.
   So, again, that just circles back to design talent.

All in all, I rebuff my original point that this isn't that big of a deal, but is still insanely cool. I'd love to heavily advance this technology, because it's pretty god damn annoying, but it just means I'd have more time to sit on my hands, and that's no guarantee I'd do anything good with that time!