|
Message
From: Joachim Strömbergson<Joachim.Strombergson@I...>
Date: Fri Aug 27 09:23:09 CEST 2004
Subject: [oc] Routing allocation leakage in FPGA makros?
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.
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?
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
Notes
------
[1] The footprint could be defined to the area where the routing/communication
resources allocated reaches, in which case at least the leakage problem would
by definition not exist.
[2] I just realised that I use the word "core", when previously using "macro".
I normally talk about "macros", "cores", "IP-cores" more or less
interchangably and add "soft", "firm", "hard" to distiguish if they are RTL,
netlist (EDIF) and really hard cores.
[3] I know, this scenario is totally fictious and full of paranoia and
speculation. Things like these never happen in the real world, right? ;-)
--
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
VP, Research & Development
----------------------------------------------------------------------
InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden
Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02
E-mail: joachim.strombergson@i... Home: www.informasic.com
----------------------------------------------------------------------
|
 |
Browse
