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 at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

On Fri, 2004-08-27 at 14:23, Joachim Strömbergson wrote:


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 ...



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 ... :*)

Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis