FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Martin Thompson on 20 Jan 2006 05:06 ptkwt(a)aracnet.com (Phil Tomson) writes: > Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably > not likely, but one can wish) Yes, no, and no :-) It's described in comments in the XDL file itself: Here's some of them pasted out of one of mine: # ======================================================= # The syntax for the design statement is: # design <design_name> <part> <ncd version>; # or # design <design_name> <device> <package> <speed> <ncd_version> ; # ======================================================= # The syntax for instances is: # instance <name> <sitedef>, placed <tile> <site>, cfg <string> ; # or # instance <name> <sitedef>, unplaced, cfg <string> ; # # The syntax for nets is: # net <name> <type>, # outpin <inst_name> <inst_pin>, # . # . # inpin <inst_name> <inst_pin>, # . # . # pip <tile> <wire0> <dir> <wire1> , # [<rt>] # . # . # ; # etc..etc... More details then follow on some of the details. So it is fairly straightforward to understand, assuming you understand the architecture it's talking about already... I have made a start on a python parser for XDL which creates a pysqlite database as the backend. Conekt owns it, but they may be persuaded to open source it.. I wonder... Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conekt
From: Brian Drummond on 20 Jan 2006 09:09 On 19 Jan 2006 06:45:09 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote: >>>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... >> >>But no easier than behavioural VHDL code, in my opinion. > >True. The only gains might come when describing memories and other larger >blocks which tend to be different from family to family... but there are other >easier ways of 'genericisizing' those things too. Indeed. Any such block should have a completely generic entity, preferably with a generic architecture, which will at least work for simulation. If that synthesises down to a million FFs instead of a BRAM, you can always substitute architecture X or A as appropriate. With configurations, if the tools support them properly. - Brian
From: Tobias Weingartner on 20 Jan 2006 15:44 In article <dqmerv$c04(a)xco-news.xilinx.com>, Austin Lesea wrote: > > Not that we will not do what you suggest (someday), but reverse > engineering OTP memory is very cheap, and is considered quite insecure. 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... :) > 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." Ok, more resistant. :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
From: Tobias Weingartner on 20 Jan 2006 15:47 Peter Alfke wrote: > > Tobias, we love universities and their students and faculty for their > uninhibited free thinking, unburdened by mundane practicality. Ouch. Unfortunately, this is not for university business. > 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. Life can be as simple as you make 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. 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. :) > 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. The only advice I was hoping to offer was one of "please reconsider opening the bitstream format". -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
From: Peter Alfke on 20 Jan 2006 19:06
Tobias Weingartner wrote: > The only advice I was hoping to offer was one of "please reconsider opening > the bitstream format". > 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 |