Are the 100 Most Promising AI Start-ups Prototyping?

I came across a report on the 100 most promising AI start-ups. The report claimed that CBInsights had “selected the 100 most promising AI start-ups from a pool of 3K+ companies based on several factors …”  Wait, what … 3K+ companies!?!?  This was a stunning reminder of the sheer magnitude of what is shaping up to be a veritable tsunami of AI start-ups.  Combine this tsunami with a large number of inquiries from early stage AI start-ups asking S2C for help with FPGA prototyping, and it’s becoming abundantly clear that the demand curve for modestly priced FPGA prototyping products and services will be shaped like a hockey stick, absolutely.

Many of these start-ups are at a complete loss as to what’s required to plan for, implement, and execute an FPGA prototype.  So, for what it’s worth, here are a few hindsight considerations from one experience I had with FPGA prototyping at a start-up developing a small but very complex SoC;

1. Start FPGA prototype planning early and involve all SoC stakeholders … chip design verification, silicon bring-up, firmware development, etc…
2. Write an SoC Product Requirements Document (PRD) that all stakeholders clearly understand, and agree to … and establish a revision control process that keeps it current as the requirements evolve through the project.
3. Remember that the SoC, not the FPGA prototype, is the mission … so, set reasonable expectations for FPGA prototype project scope and facilitate the FPGA prototype project with sufficient resources, deep FPGA prototyping expertise, and aggressive but achievable milestones.

Of course, the project I reference did none of the above, that’s why I referred to them as “hindsight considerations”.  The FPGA prototype “vision” for pre-tapeout verification was to use the FPGA prototype in parallel with simulation-based verification for higher verification coverage, and then make the prototype available to firmware developers for early firmware bring-up and get it all done before tapeout.

This particular design verification project was challenged from the beginning.  As it turned out, not all simulation jockeys believed in FPGA prototypes, and there was some passive aggressive behavior that impacted the success of the overall SoC verification effort.  The “golden netlist” (the one used for tapeout) for SoC simulation always needs to be modified for the FPGA implementation to accommodate the intrinsic FPGA clocking, embedded memory, embedded IP, and DFT physical constructs.  The burden of understanding the netlist differences, what impact they will have on the test results when the FPGA prototype is subjected to the same testing as the golden netlist, and which netlist differences to ignore and which need special attention, should be a team responsibility.

This project came to appreciate the need for a robust netlist versioning process for modifying the netlist throughout the verification project to assure that the two verification platforms stay aligned when design bugs are fixed and PRD changes are introduced into the design during the development process.  The importance of a robust SoC bug reporting platform (Bugzilla, Jira, etc.) was also really appreciated late in the project when the bug discovery rate slowed to a trickle to minimize one of the two verification teams spending a lot of time isolating, fixing, and verifying an SoC bug that the other team had already fixed weeks ago.

Then, there was the point at which the FPGA prototype platform was handed over to the firmware team … this was a rude awakening.  Unlike the use of the FPGA platform for design verification, the firmware team expects the FPGA platform to actually work according to the PRD!  The firmware team has no patience for a software validation platform that doesn’t work, and they don’t have the skill set nor the inclination to try to understand why their software is not working on the hardware.  They simple “kick” the FPGA prototype back to the hardware guys and tell them to “fix it”.

The first attempts to run firmware on the FPGA prototype can be plagued by elusive problems that are as simple as how the hardware comes out of “reset”.  The FPGA prototyping team must plan to support the firmware team during the inevitable ramp-up of firmware validation on the FPGA prototype platform.  If firmware validation is on the critical path to tapeout, as it was for this project, days and weeks matter.

As a strong foundation to any FPGA prototyping project, high quality, reliable FPGA hardware is an absolute must.  The SoC verification project is challenging enough without having to worry about the underlying FPGA hardware.  S2C has been building and delivering FPGA prototyping hardware and software since 2005, and each generation has been an improvement on the previous generation.  S2C supports Intel and Xilinx FPGAs, and offers Single, Dual and Quad FPGA versions of its Prodigy Logic Systems.

To get a quick S2C quote click here.