FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Austin Lesea on 18 Jan 2006 16:01 JBits, Is a Xilinx invention, developed here. Austin Eric Smith wrote: > Phil Tomson wrote: > >>It looks like JBits is a University-developed tool. why wouldn't the source >>code be available? > > > If it really was developed at a university, the university probably signed > an NDA with Xilinx to get the bitstream details.
From: Tobias Weingartner on 18 Jan 2006 16:39 In article <QFTyf.3436$bF.2359(a)dukeread07>, Ray Andraka wrote: > > I'm not sure I see what the big push for having bitstream access is. Do you happen to have a means to create a bitstream (from whatever ASCII represented primitives) on for example OpenBSD? Or from a perl script running on an OpenVMS system? Your (the vendor's) tools so lovingly provided are not always the ideal tool for the job, nor is the environment always readily available in order to use them. > I've yet to see a compelling need for it that is not addressed by the > existing tools (there is always XDL if you really want to bit bang). Yes, but how to convert XDL into something that I can shoot into the FPGA? > The only reason that seems to surface is to allow outside parties to > develop their own place and route tools. Frankly, I don't think the > complexity of modern FPGAs is such that this type of undertaking can > improve on or even compete with the free place and route tools already > offered by the FPGA vendors in the timeframe between device introduction > and obsolescence. The gist is not really to compete in a space where a company has invested in millions to create a product, but to play in a space where nobody else is going. > Anyway, for those hadry enough to try, as I said, the > XDL tools do give you enough access to every step of the design flow to > allow you to play with any step you feel compelled to play with. But the tools are in the environment of your choosing. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
From: Tobias Weingartner on 18 Jan 2006 16:54 Peter Alfke wrote: > > Tobias, this subject has been discussed ad nauseam, in this newsgroup > and elsewhere. Well, talking to actel, they cite "competitor" reasons for not giving away this information. > 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. Xilinx (as much as this is "official" in any way) is citing a fear of being not able to meet the support issues. > Also, the non-open nature of the bitstream provides our customers a > certain level of security against reverse-engineering rip-off. 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. > 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. 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... > Just my personal opinion... Darn. :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
From: Tobias Weingartner on 18 Jan 2006 17:00 Scott & Brenda Burris wrote: > > And then there's the little matter of the ML403 kit Xilinx offers with > the Virtex 4 FX and the EDK. As a hobbyist, I'm cringing at the thought > of putting $895 into this. At the same time, I'm going, hmm, what could > I do with the PowerPC chip or the MicroBlaze? Hmm, no it's too much > money.... But I keep thinking about it :-) I know Xilinx doesn't > really target people like me, but I keep hoping for a half-price sale or > a hobby bundle on the ML403 (no support, no commercial use or you give > up your first born, etc). I know what you feel like. We have the XC2S50 here on some demo boards from somewhere. They're ok to play around with. Nowadays I'm salivating over XC3S1500/2000 boards. If I could find something with 3 to 6 of these on board (even the 1000 version), and good chunk of sram, for less than $1k, I'd be a very happy camper... -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
From: Austin Lesea on 18 Jan 2006 17:18
Tobias, -snip- > 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. 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 |