FPGA Journal Article - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: FPGA Journal Article

Quoted text here. Click to load it

You might want to look a little closer at the license for the web pack,
and any other license you have ever executed with Xilinx, as it wasn't
that long ago that it contained very strong language about reverse
engineering proprietary data.

With the current DMCA state, the law isn't hardly on the side of fair
use for computer software or hardware owners these days. It's
terribly like owning a car, but unable to remove the heads to repair
a valve without getting sued.

Or when the telco's prevented third party phones from being attached
to their systems. When finally lifted an entire industry blossomed
bringing
us cheap cordless phones and digital answering machines that would
never have appeared with the PUC mandated 10 year capital recovery
limitiation on hardware. Ever wonder why WeCo had to over design the
clunky 500 desk set?


Re: FPGA Journal Article
or for that matter even high speed  consumer modems, as we would have
remained stuck in the accustic coupler days.


Re: FPGA Journal Article
Quoted text here. Click to load it
well I am not doing anything, I just know what can or could be done :)
[pretty much anything...]

Atmel bitstream info is all known and its fully runtime reconfigurable
so it makes way more sense to go with Atmel FPGA/FPSLIC if
someones wants self or dynamicall reconfiguring FPGA systems.

Antti



Re: FPGA Journal Article

Quoted text here. Click to load it

If I recall correctly, the NCD format came from Neocad, a company whose
P&R tools were better than Xilinx' own.  So Xilinx bought 'em.  This
was back when the XC3000s were the bleeding edge.

-a


Re: FPGA Journal Article

Quoted text here. Click to load it

Last really open system was the XC6200. But it failed commercially, at
least in part, because it was a finer grained architecture.

FPGA capacities should now be big enough to support a "virtual FPGA"
layer on top of a real FPGA, using only the "public" parts of the
bitstream (e.g BRAM and SRL16 contents, possibly a subset of the
routing) to give a completely open format. Possibly a virtual XC6200,
but probably a coarser grained architecture (mini-Spartan perhaps).
I wonder what size Spartan-3 you would need for a virtual XC6264?

This would lose a lot of capacity and performance (you may need several
LUTs dedicated to routing for every one you can use for logic) but the
result is likely to be at least competitive with the sort of technology
a startup or small player has on offer.

I think it would be big enough to exercise open source development tools
until something better came along...

- Brian


Re: FPGA Journal Article
Quoted text here. Click to load it

it has already been done there was MPGA project that implemented a virtual
"Meta" FPGA
the project is dead vanished/vanishing but its a nice a example of the use
of SRL16 for
virtual FPGA loading

its however far more interessant to implement dynamic bitstream generator
that patches
some parts of the ready made bitstream to modify the algorithm this needs to
no
resources to be vasted for the download of the new config.




--
Antti Lukats
http://www.xilant.com



Re: FPGA Journal Article
Quoted text here. Click to load it

But this would require that we know the bitstream format, right?  Can you
elaborate a bit (no pun intended) on this dynamic bistream generator idea?


Phil

Re: FPGA Journal Article
Quoted text here. Click to load it

At that point, why not create an ASIC...  (yeah, price, etc, etc)

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Re: FPGA Journal Article
Tobias, this subject has been discussed ad nauseam, in this newsgroup
and elsewhere.
The reason for the "secrecy" is not so much fear of giving away secrets
to a competitor, but rather fear of becoming inundated with support
issues. We have about 100,000 designers using our parts,  a few dozen
of them exploring and abusing subtle aspects could easily bring our
support hotline (and this newsgroup) to its knees.
Also, the non-open nature of the bitstream provides our customers a
certain level of security against reverse-engineering rip-off.
Our primary obligation is to remain an innovative and profitable
company, to the benefit of our customers, our employees, and our
shareholders. Satisfying exotic academic research is fine, as long as
it does not conflict with the primary obligation.
Just my personal opinion...
Peter Alfke


Re: FPGA Journal Article
Quoted text here. Click to load it

Well, talking to actel, they cite "competitor" reasons for not giving
away this information.

Quoted text here. Click to load it

Xilinx (as much as this is "official" in any way) is citing a fear of
being not able to meet the support issues.

Quoted text here. Click to load it

Bullshit.  I can get the bitstream and parts are readily available.
There is little to no need to reverse-engineer your customers' design.
It's right there for me to use, should I care to.  Also, should I want
to reverse-engineer things, it would not be *that* hard.  I'm sure that
I could get various pieces out of the bitstream that would be usefull
to me (along with traces/etc) in doing a 80% job.

If you want security, provide it.  Have a means to program a OTP flash
(or somesuch) piece of hardware on your FPGA with an AES key, and have
the bitstream flash device have its bitstream encrypted with the same
key.  At this point, things would considerably more "challenging" to
reverse-engineer.  I'm no VLSI designer, but I can't imagine that putting
a simple AES engine onto the FPGA, along with some OTP ram for the key,
would take any significant room.  As a bonus, you may be able to offer
the simple AES engine for the FPGA to use once programming is done.

Quoted text here. Click to load it

Certainly.  Does the "idea" I have given above (which is available in
many forms on the web, etc) mean that you could use it, implement it,
and have yet another innovative & profitable device on your hands?  :)

Open documentation (not necessarily support) tends to foster collaboration
and innovation on many fronts.  The "encrypted config bitstream" idea is
hardly new or novel, but I'm sure there are many people out there who would
welcome the chance to get their creative juices flowing...

Quoted text here. Click to load it

Darn.  :)

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Re: FPGA Journal Article
Tobias,

-snip-

Quoted text here. Click to load it


Not that we will not do what you suggest (someday), but reverse
engineering OTP memory is very cheap, and is considered quite insecure.

That is the reason why RAM backed up by a battery is the only solution
that is acceptable to the US federal government (FIPS-41), and to TV set
cable box vendors...

The one time programmable key might be sufficient as a deterrent, and
will certainly slow down the process of ripping off the design.  I
agree.  But please do not put it forth as being "secure."

Austin

Re: FPGA Journal Article
Quoted text here. Click to load it

Sure, a ROM may be such.  I dont really care how it's implemented, but
if done as a "persistant write-only" area of the FPGA (from a user's
point of view)...  if that is battery backed ram, flash, whatever.  I'll
leave the finer details to the VLSI designers... :)


Quoted text here. Click to load it

Ok, more resistant.  :)

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Re: FPGA Journal Article
Tobias, we love universities and their students and faculty for their
uninhibited free thinking, unburdened by mundane practicality.
But beware that some of your sentences sound not just enthusiastic and
uninhibited, but also ill informed. Life would be easy if the world
were a simple as you see it.
Of course we have evaluated non-volatile storage on an FPGA, and we
offer a decryption engine in every Virtex-4 device that we ship. With
battery-backed-up SRAM key storage, because we know that Flash storage
offers no security worth talking about.
And several smart people at Xilinx (and surely also in Altera) are
still thinking very hard about a technically and economically viable
solution. We gladly take advice. But it has to be more substantial than
what you seem to offer.
Peter Alfke


Re: FPGA Journal Article
Quoted text here. Click to load it

Ouch.  Unfortunately, this is not for university business.

Quoted text here. Click to load it

Life can be as simple as you make it.

Quoted text here. Click to load it

So what you're saying is that for Virtex-4 devices the reason to keep
the bitstream format closed has been reduced by one hurdle.  :)

Quoted text here. Click to load it

The only advice I was hoping to offer was one of "please reconsider opening
the bitstream format".

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Re: FPGA Journal Article

Quoted text here. Click to load it
Tobias, just to remind you, the following is what you wrote,
and that is what I strongly take exception to:

"I'm no VLSI designer, but I can't imagine that putting
a simple AES engine onto the FPGA, along with some OTP ram for the key,

would take any significant room.  As a bonus, you may be able to offer
the simple AES engine for the FPGA to use once programming is done."

That's what I call simplistic and un-informed advice.
I want to avoid the bovine excrement word...
Peter Alfke


Re: FPGA Journal Article
Quoted text here. Click to load it

Call it as you see it.  I tend to.  And since you are much more
versed as to what is possible and/or easy/big/small, I'll defer
to your expertise on the matter above.  Sorry to cause a stir.

Still... can I get the bitstream info?  :)

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Re: FPGA Journal Article
Quoted text here. Click to load it
No, Tobias, you can not. The price of what you are asking is higher then you
realize.

If you want it, you will have to get it by reverse engineering.

Antti



Re: FPGA Journal Article

Quoted text here. Click to load it

That is easily handled by a solid policy of "unsupported" features,
which
can be selectively waved by the company for selected fully paying
customers
which have volume to merit a response.

Quoted text here. Click to load it

Security by obscurity has never worked ... just look at the weekly
exploits
to microsoft windows that result largely due to reverse engineering.

Any engineering team in the world that can manufacture a cloned product
without legal recourse will do exactly that, via reverse engineering if
necessary,
including die probing live parts if necessary.  There just has to be an
economic
social, or political incentive first.

Quoted text here. Click to load it

exotic academic, or hobby stage, engineering is where garage
innovations
create new industries.


Re: FPGA Journal Article
Quoted text here. Click to load it

Interesting idea.  Are you saying that a XC6200 model would be developed in
HDL and then run through synt, p&r, etc. and that could then be used for
downloading the bitstream to?

...but like you say, you would be taking a big performance/area hit.

If you were going to do that, then why not just create some sort of
higher level Virtual FGPA device (kind of like what a Virtual Machine is to the
software world) that would have lots of nice high-level features (high-level
macros available, etc.) and also be tunable for the underlying architecture
(depending on whether the target was Xilinx, Altera, or Lattice.  Just as VMs
allow for easier porting, greater genericity, etc. maybe something like a VFPGA
could have similar advantages?  Also, just like the Java VM doesn't care what
underlying architecture it's running on, this sort of thing could potentially
make it easier to port designs between FPGA families... I wonder if it could be
done such that there is a minimal impact on performance and area?

Phil

Re: FPGA Journal Article

Quoted text here. Click to load it


Something like that; though I doubt the XC6200 would be the best
starting point.

Quoted text here. Click to load it

It looks possible, especially if the basic elements were a
common-denominator subset of individual targets like Xilinx; e.g.
4-input LUTs followed by registers, with some sort of carry chain.

Quoted text here. Click to load it

But no easier than behavioural VHDL code, in my opinion.

Quoted text here. Click to load it

ummm, in a sense; if you are willing to use the "native" routing on each
target, and allow each company's "native" tools to perform the routing,
placement, bitstream generation (because they know the details of that
target and its bitstream). And even then, you will lose some performance
on at least some targets.

But that is a completely different issue than trying to keep every level
of the design "open"...


IMO the closest you will get to allowing open tools to participate
WITHOUT taking a big performance hit is the XDL approach. It's a text
version of the NCD format - parseable and even human readable - with
converters to/from NCD format. So you could potentially take an EDIF
netlist and create open source tools to "map" it to an unplaced XDL, or
use the Xilinx mapper and convert its output to XDL. Then create open
source tools to floorplan, place and route in XDL format. Those portions
of the tool flow are where the challenges are; and if you create
something worthwhile, it would be useful to many Xilinx users.

You would realistically then have to use Xilinx tools to convert XDL to
NCD and translate the completed design into a bitstream format. This is
pretty much a straight translation and not very interesting in my book;
though it would be a wart on an otherwise complete open source
toolchain.

- Brian

Site Timeline