Enabling Vertical Markets With Segments Upon an FPGA

via Secure Socketable IP -

November 3, 2009

by Gregg J. Macdonald

In the software world when someone says give me a copy of the binary they are referring to the executable *.exe file.  In the hardware world it's pretty much the same when someone refers to the binary they are referring to the executable but it is a *.bit file.  Differences arise with how these files are used. In the case of *.exe, many such files may be resident on a given platform and any one may be selected for run.  Typically the mapping is one program to one *.exe.  In the case of *.bit, many different files similarly may exist on a platform but there is also an option and a plethora of reasons to include many programs within one *.bit.  Further there is need for connecting programs to programs . . . Consider all the programs necessary to assemble a complete platform as different segments within the platform.  Consider many different companies and developers offering different segments of the platform.  How will it all come together? (read on)

For software the mapping of number of programs to number of *.exe clearly makes very good sense as one to one.  There are lots of excellent reasons for this success.  For hardware programs the present methods and flows have also embraced a one to one mapping.  However as the software becomes the hardware as in the case of the HUMBLEŠ PC multiple programs begin to reside in a single *.bit.  Presently there is no mechanism or flow for any vendor -- for example as Electronic Compute Systems, Inc. to give its 'executable' to another as easily and securely as is enjoyed with the widely successful software *.exe method and flow.  It's not that it can't be given, but instead the recipient can't do anything else with it.  In other words he can't hook his Intellectual Property (IP) into it. What is missing is an analogous secure-and-interoperable *.exe format-and-distribution method.  So this is where 'enabling-secure-segments' comes in to play.

Segmented Markets Upon an FPGA -

Once just a chip manufacturer, Xilinx now manufactures whole platforms.  They have established outstanding devices, tools, flows and mechanisms protecting FPGA 'executable IP' such as battery-backed-up-key-encrypted bit streams exemplified within the Virtex series of FPGAs.  This enables protection of the complete executable IP for 'the platform'.  However there still exists an easily solvable though missing piece necessary for genuinely and completely enabling segments within this new platform computing revolution.  This missing piece has the ability to form many vertical markets composed of interconnected horizontal segments analogous to the early PC segmented supplier-market.  The recent cover artwork for Xilinx's - July Xcell Journal illustrates this point -- There are no connectors between the horizontal segments. . . Pause on this . . . Gaze at it. . . The base is connected to the platform but the horizontal segments are still floating . . . The artwork clearly captures the actual state of this market with its missing connections . . . Clearly Xilinx is the prime mover, is driving and has enabled the biggest parts first -- a forward looking profitable vertical market of 'targeted platforms' -- embodied well by products like the emerging HUMBLEŠ PC.  However for a truly universal and general purpose vertical market such as a PC upon an FPGA platform there is clear and present need for the base IP and segments -- including HUMBLEŠ  PC with connections to all of the new PC application developers -- to make their 'executable IP' (segments) available to many others while protecting their investment.  Note this also closes an entry point for future viruses and malicious hackers.  In other words reliable connections are needed between segments for segments to persist.  Practically speaking the connectors are formed between the segments and the base platform.  More specifically between the segments and the tools (as is done in the software *.exe world).  From a non-General Purpose PC market perspective the present tool-methods-and-flows are adequate.  Most development and business model concerns are elsewhere.  However, from a General Purpose PC platform business model perspective present methods and flows in place amount to a share-ware-deflationary-open-source-pirates-and-viruses-welcome-environment.  There is nothing wrong with how we got here and why things are as they are.  Using a driving analogy -- If you drive past your destination what should you do?  Hint - turn around . . .  If you arrive at the destination before anyone else what should you do? -- Wait.  So let wisdom prevail . . .  Hopefully the point of this whole article becomes clear right-here in the midst of these sentences.  Enabling Vertical Markets With Segments Upon an FPGA await the last enabling piece -- Secure Socketable IP.  Segments must be securely enabled.  So what if segments are not securely enabled? -- We already have this case. . .  More stagnancy, more deflation, no new green technology jobs . . . including delay and tendency to produce a smaller number of vertical only companies, with few segments or perhaps no new vertical market(s) at all -- Rather instead more sideways status quo.

The Last Enabling Piece = Secure Socketable IP -

Consider the following as an outline for producing what software developers would call the 'executable IP' -- Hardware developers analogously would call 'encrypted IP'.  It's ready to run (sort of), can be distributed and is inherently 'secure' (protected).  Again the intention of this is to enable profitable segmented markets within the overall vertical FPGA computing platform.

For Xilinx ISE -

- Add Generation of encrypted *.ngc output A.K.A. the netlist (with a user defined key)

- Add Accepting the same encrypted *.ngc as input (with the same user defined key)

- Add an HDL Constraint 'Attribute' allowing developer(s) to selectively 'Blank' components and blank signals and blank init-contents of block rams from appearing in the unencrypted *.ngc and from appearing in FPGA-Editor and other output viewer tools and report files . . .

- Don't allow/add/define a local or global 'Un-Blank' attribute (so as not to negate segment-developer-applied-blanking)

Then -

For designs that ISE detects an encrypted *.ngc input (segment), generate a black box in the unencrypted *.ngc output (so IP is not easily pirated) OR force-auto-turn-off *.ngc generation altogether so the encrypted IP is not easily accessible via recompile.

For all the other FPGA vendor tool flows -

The intention and flow is the same, only the netlist file extensions, report files and output tool names are different.

In conclusion - Let wisdom prevail -- Let the segments be enabled via Secure Socketable IP. . .