|
Message
From: Rudolf Usselmann<rudi@a...>
Date: Fri Aug 27 09:46:38 CEST 2004
Subject: [oc] Routing allocation leakage in FPGA makros?
On Fri, 2004-08-27 at 14:23, Joachim Strömbergson wrote:
> Aloha!
>
> (This is slightly off topic, but TGIF, right? ,-)
>
> While digressing the interesting article about the rapidly rising number of
> hard macros in SoCs that is available on EE Times I couldn't help but trying
> to think of the implications for FPGAs:
>
> http://www.eedesign.com/features/exclusive/showArticle.jhtml?articleId=26807055
>
> In FPGAs, the true hard macros (apart from the CLB/Slices/LEs whatever you
> call them) are the memories. But on top of the FPGA architecture we then map
> an increasing number of "hard" macros in the form of pre built blocks with
> internal P&R. Things like the Xilinx MicroBlaze and the Altera Nios processors.
>
> Now, we can to quite a high level degree control where they are being placed.
> But, what I'm unsure of is to what degree the routing used inside the macro is
> confined to the block footprint, or if there is a dead zone around the blocks
> where the allocated routing resources reach [1]. To give an example: If a
> macro uses a comm resource that covers half a chip length, but occupies much
> less than that, other routing would still be affected by the macro, since the
> parts of the routing for that half of the chip would be allocated by the macro.
I think FPGAs mostly use Relative Location constrains (RLOC).
Which means the P&R tool can move them around as long the
relative constrains to other blocks are met.
You can use the xilinx floor planer or fpga editor to look at a
routed design. There is no way to distinguish where one begins
and the other ends ...
> My venture is then that as we increase the number of these macros, and even
> create them ourselves, the problem seen in the paper for normal standard cell
> (SC) ASICs would not only spill over to the FPGA world, but also be
> exacerbated by the fixed routing of the FPGA *and* the leakage effect by the
> macros. I.e. in this case, the well defined, pre qualified world of FPGAs
> which makes them easy to use and work with actually makes this problem worse.
> No? Am I totally out in the grand forest?
>
> Side note: If there actually exsist a leakage effect in (at least some)
> macros, wouldn't that mean that one could concieve to attach logic to the
> routing "sticking out" of the core, thereby probe the internals of the macro?
> Could this be a problem for security sensitive applications?
>
> Consider for example that an evil empi^D^D^D^D company in the northwestern
> region of the U.S. licenses out a Digital Rights Management core [2] required
> (and by regulation mandatory) for DVD playback. The core is treated as a real
> hard core, that is a black box and the internals are off limits for anyone
> besides big media executives and people employed by publicly funded orgs that,
> at least on paper don'r exist [3].
>
> Now would it at all be possible for say, a young and inventive fellow from
> Norway, to create some logic that attaches to the "leakage routing" analyze
> the DRM-system, perhaps be able to extrect parts of (for example) round keys,
> internal states etc and possibly come up with a way to defeat the system.
> Possibly even print the solution as Perl code on a T-shirt?
LOL !
I wouldn't say NO - believing that everything is possible,
giving unlimited resources and the will to to do it !
But it would be really tough to do this on a bit-stream. If
you can extract the netlist and insert snooper cores, it would
be a trivial task.
There should be a way to take a bit-file, and reverse engineer
it in to a schematic. I believe that should be more or less a
trivial task.
Now the printing task would of course be much easier to achieve !
Besides I think we should all start making our own music and
movies instead of dealing with RIAA ... :*)
> This example is highly contrieved, but it hopefully illustrates that core
> developers might wan't to protect the internals, and some users of the core
> might be interested in finding out what goes on internally.
>
> Thought and comments appreciated
Regards,
rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
|
 |
Browse
