Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
In article <39f6ac87.8065038@news.dial.pipex.com>, eml@riverside-machines.com.NOSPAM () wrote: > On Fri, 20 Oct 2000 10:12:50 GMT, kolja@prowokulta.org wrote: > > >So, what is left: > >New algorithms invented by you and secret parts of known algorithms, > >such as decryption keys. > >Especially for the latter paranoid protection could be useful. > >But, as Nick pointed out, that's almost impossible to achieve. > >There is - expensive - equipment that can read the content of SRAM > >cells. This would even break Xilinx Virtex-II DES approach. > > What do you mean by 'even break Xilinx Virtex-II DES approach'? Sounds > like you know something we don't know... The DES encryption only protects the config bit stream. If you take the lid off the chip and look at the SRAM contents, you're looking at the decrypted result. The only way to be completely secure against the dedicated cracker is to have a programming element in which the on and off states can't be distinguished. Of course, that's a self-contradictory requirement, short of some as-yet unimagined quantum device :-) -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 26701
Nicholas Weaver wrote: > > In article <8t2evsoh4jbg8guso10o1drhljl391dsum@4ax.com>, > Philip Freidin <philip@fliptronics.com> wrote: > > > First I believe that triple-DES requires 3 keys, each of 56 bits > > (plus parity), so my guess is that the EDN article should say that > > the chip holds two sets of three 56-bit keys. > > No, 3DES only uses 2 keys, A and B. The procedure for > encrypting a block is E(D(E(data,A),B),A). So you encrypt with key A, > decrypt the result with key B, and then reencrypt with key A, so you > are going through the DES function 3 times, but with only 2 keys. In the classical triple DES, yes. I've been out of crypto for seven years (I did physical security and key management hardware). However, IIRCt there was some worry that this might be subject to a "meet in the middle" attack on the two keys. So a three-key "standard" was adopted. > >As for your slides, my guess is that at the time you received it, the DES > >stuff was on their NDA list of features. The EDN article now > >publicly discloses this information. > > I suspect that as well. If so, this will be a very useful > feature, although it will be interesting to see how it can be > attacked. One way, though it may be considered rather extreme, is to fry the chip with X-rays. CMOS SRAM tends to "harden" into it's current state when bombarded with X-rays. When powered on, it'll then tend to come up in that state. IFAIK this isn't perfect, but any bits recovered reduce the effort to crack the key greatly. Of course there may be other holes as well. Depending on the level (as in FIPS 140 level) you get into, the crypto "Spy vs. Spy" game can get very interesting, even when not working for a *government* three lettered organization. ---- Keith R. Williams Not speaking for IBM (I doubt they know I can speak)Article: 26702
In article <39F721F8.1457F1AA@btv.ibm.com>, Keith R. Williams <krw@btv.ibm.com> wrote: >Of course there may be other holes as well. Depending on the level (as >in FIPS 140 level) you get into, the crypto "Spy vs. Spy" game can get >very interesting, even when not working for a *government* three >lettered organization. Yeah. I'm not a security expert myself, but it is fun to just watch and see what people are capable of doing. That, and it is fun to listen to NSA guys talk about customers. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 26703
In article <memo.20001025184516.1288X@steve.rsn-tech.co.uk>, Steve Rencontre <steve@rsn-tech.co.uk> wrote: >The DES encryption only protects the config bit stream. If you take the >lid off the chip and look at the SRAM contents, you're looking at the >decrypted result. Of course, if you take the lid off, just read out the key and you don't need to bother reading out the SRAM contents of the whole chip. >The only way to be completely secure against the dedicated cracker is to >have a programming element in which the on and off states can't be >distinguished. Of course, that's a self-contradictory requirement, short >of some as-yet unimagined quantum device :-) OR, you just don't let the attacker get the box. :) Although you COLUD make the stakes higher by embedding your chip in a large quantity of high explosive (or nerve gas, or something else similarly nasty), encased in a very fine sensor mesh and covered in solid plastic, REALLY hard to get at and well, an error on the attacker's part would be a bit catastrophic. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 26704
>I spoke to someone at Xilinx about this, and he confirmed that to the >extent of the article, what is disclosed is now public, and Brian Dipert >did not reveal stuff he shouldn't have under some NDA. Philip, Philip, Philip....you didn't think I was misbehaving, did you? ;-) Yes, my article marked the first public disclosure of Triple DES support in Virtex-II Brian Dipert Technical Editor: Memory, Multimedia and Programmable Logic EDN Magazine: http://www.ednmag.com Contributing Editor, CommVerge Magazine: http://www.commvergemag.com 1864 52nd Street Sacramento, CA 95819 (916) 454-5242 (voice), (916) 454-5101 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** mailto:bdipert@NOSPAM.pacbell.net Visit me at http://members.aol.com/bdipertArticle: 26705
>just look in deja for design security. This has been hashed over many times on >the newsgroup. Frankly, I think Brian got alot of his material from the >discussions here too, as I recognize a good deal of it. Howdy Ray, the comp.arch.fpga discussion thread mentioned in my article was indeed the original motivation for this article (though I did get a 'bit' more material through my more recent research; implying that I relied on comp.arch.fpga discussions 'a lot' is perhaps overstating reality 'a lot'). ;-) 'A lot' of discussion threads here find their way into my articles, as inspiration for topics if nothing else. After all, why waste my time writing on stuff that isn't of interest to y'all? ;-) Brian Dipert Technical Editor: Memory, Multimedia and Programmable Logic EDN Magazine: http://www.ednmag.com Contributing Editor, CommVerge Magazine: http://www.commvergemag.com 1864 52nd Street Sacramento, CA 95819 (916) 454-5242 (voice), (916) 454-5101 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** mailto:bdipert@NOSPAM.pacbell.net Visit me at http://members.aol.com/bdipertArticle: 26706
Makes you wonder where he got his info ;-> eml@riverside-machines.com.NOSPAM wrote: > > On Wed, 25 Oct 2000 09:49:32 GMT, eml@riverside-machines.com.NOSPAM > wrote: > > >On Fri, 20 Oct 2000 10:12:50 GMT, kolja@prowokulta.org wrote: > > > >>So, what is left: > >>New algorithms invented by you and secret parts of known algorithms, > >>such as decryption keys. > >>Especially for the latter paranoid protection could be useful. > >>But, as Nick pointed out, that's almost impossible to achieve. > >>There is - expensive - equipment that can read the content of SRAM > >>cells. This would even break Xilinx Virtex-II DES approach. > > > >What do you mean by 'even break Xilinx Virtex-II DES approach'? Sounds > >like you know something we don't know... > > I just answered my own question by reading the EDN article. According > to the article, Virtex-II includes "a hard-wired Triple-DES decryption > block, along with two sets of 56-bit key registers and dedicated > battery-backup supply-voltage inputs for only those registers, on its > upcoming Virtex-II FPGAs". > > Funny thing is, though, that I was at a seminar two weeks ago, and > this wasn't mentioned. I've got 29 pages of slides on Virtex-II, and > not one of them mentions a triple-DES block, which isn't the sort of > thing you'd accidentally leave out of a presentation. > > Anyone know any more? > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26707
155MHz DDR should be cake in a Virtex part. I'm doing 622 Mword/sec signalling using the lvds I/O on the VirtexE. Search for LVDS on the Xilinx Web page and you'll find an app. note that shows how to do it all. At 155MHz you should be able to use the LVTTL i/o if you want. Buena Suerte. <gazit@my-deja.com> wrote in message news:8t6cf6$veu$1@nnrp1.deja.com... > Does anyone think it is possible to drive DDR (Double Data Rate) bus at > 155Mhz from/to a programmable logic device ? > In DDR bus the data changes on both clock edges. > My application is half-duplex : separate driver and receiver pins. > > Thanks in advance for your comments, > Rotem. > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 26708
hi, I need an external reset and an internal power on reset type signal. In Synplicity libraries, there is a ROC cell for Virtex but there are no simulation libraries in Alliance toolset for ROC. Is this cell valid for Virtex ? I am also using a DLL. Is there a way to make sure that ROC doesn't go low before LOCK happens ? Also what is the timing for ROC signal after a configuration ? thanks, Muzaffer http://www.dspia.comArticle: 26709
On Wed, 25 Oct 2000 09:55:14 -0700, Philip Freidin <philip@fliptronics.com> wrote: >On Wed, 25 Oct 2000 13:59:28 GMT, eml@riverside-machines.com.NOSPAM wrote: >>I just answered my own question by reading the EDN article. According >>to the article, Virtex-II includes "a hard-wired Triple-DES decryption >>block, along with two sets of 56-bit key registers and dedicated >>battery-backup supply-voltage inputs for only those registers, on its >>upcoming Virtex-II FPGAs". >> >>Funny thing is, though, that I was at a seminar two weeks ago, and >>this wasn't mentioned. I've got 29 pages of slides on Virtex-II, and >>not one of them mentions a triple-DES block, which isn't the sort of >>thing you'd accidentally leave out of a presentation. >> >>Anyone know any more? >> >>Evan > >First I believe that triple-DES requires 3 keys, each of 56 bits (plus parity), >so my guess is that the EDN article should say that the chip holds two >sets of three 56-bit keys. I actually did a Xilinx 3DES a couple of months ago. Unfortunately, 'triple-DES' is not well-defined. The basic DES algorithm is straightforward, but it's only half the problem. The rest is that you have to decide a mode in which you want to use it, which involves things like data chaining and feedback around the DES block, and how many times you want to run data through DES itself. As Keith says, 3DES was originally done with 2 keys, but there was a concern that there was a symmetry problem that effectively made this one-key, which is easily crackable. According to Schneier's book this was eventually disproved, but he still recommends using 3 different keys for maximum security. Fortunately the hardware's identical - I just have three 56-bit key registers instead of 2, and select either the 1st or 3rd register for the final pass. And, of course, DES's successor - Rijndael - has turned up since I finished, so I'm just waiting to be told to throw it all away and start again. >As for your slides, my guess is that at the time you received it, the DES >stuff was on their NDA list of features. The EDN article now >publicly discloses this information. > >(I searched the Xilinx web site, and could not find any supporting info >about this capability.) > >I spoke to someone at Xilinx about this, and he confirmed that to the >extent of the article, what is disclosed is now public, and Brian Dipert >did not reveal stuff he shouldn't have under some NDA. I expect you're right. It does seem rather odd though - it was NDA'ed 2 weeks ago and suddenly turns up in the press, which smells somewhat like a cock-up. EvanArticle: 26710
On 25 Oct 2000 17:43:34 GMT, nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver) wrote: > I suspect that as well. If so, this will be a very useful >feature, although it will be interesting to see how it can be >attacked. A couple of things occur to me - if this feature actually exists, we'll need some way to find out if the power has been disconnected and if the key contents have leaked away. How is this going to be done? Do we just rely on DONE not going active? You obviously can't read the keys back to see if they're still Ok. Next problem: what do you do if the power *has* been disconnected, or the keys have become corrupted in some way? You want to supply new keys to the customer, preferably without getting the board back. You have to set up a secure key exchange with them, using public-key encryption. This takes some organising, but is well understood. **But:** At some point the new secret keys are decoded locally at the customer's site, and must be programmed back into the FPGA *in the clear*. In other words, if the customer has the ability to fix the power-fail problem, then there will always be a point at which the 'secret' keys can be probed on the board. So the customer can't fix the problem on-site, and must return the board. If this is true, It begs the question of whether a separately-powered SRAM-based key is actually very much better than a separately-powered complete FPGA. > On the slides, did they have any information on partial >reconfigurability on the Virtex 2? Afraid not. Mainly faster, bigger, better, more memory, multipliers, interesting clocking and routing, 800Mbps LVDS, bigger CLBs. I think most, if not all of this, is on the website. EvanArticle: 26711
In article <39f73974.44147987@news.dial.pipex.com>, <eml@riverside-machines.com.NOSPAM> wrote: >And, of course, DES's successor - Rijndael - has turned up since I >finished, so I'm just waiting to be told to throw it all away and >start again. Rijndael is a NICE algorithm, especially with the Virtex BlockRAMs exactly matching the space required to store both the encryption and decryption S-boxes, a full round implementation is incredibly fast, and compact implementations give a good area/performance tradeoff. The paper can be hard to read, because it presents the mathematical background first, but the algorithm itself is nice and simple. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 26712
In article <39f739b5.44213007@news.dial.pipex.com>, <eml@riverside-machines.com.NOSPAM> wrote: >Next problem: what do you do if the power *has* been disconnected, or >the keys have become corrupted in some way? You want to supply new >keys to the customer, preferably without getting the board back. You >have to set up a secure key exchange with them, using public-key >encryption. This takes some organising, but is well understood. >**But:** Since it is symmetric key, independantly battery backed up, you MUST get the board back and reprogram it yourself, or trust your customer. There is no way around this problem. But if you trusted your customer, you wouldn't need or use this feature. With only the symmetric key cryptographic algorithm and with the key in the device lost, there is no other approach, as you correctly noted in the later paragraph (munched for space). The key is to make it as idiot-proof-as-possible with regards to the power supply, something like a 10 year key lifespan on a single, small, Lithium-ion battery, with an additional slot to put ANOTHER battery if the main battery ever needs to be replaced. If the device lifetime is less than the battery, something like coating the battery with a blob of epoxy might be useful. >the problem on-site, and must return the board. If this is true, It >begs the question of whether a separately-powered SRAM-based key is >actually very much better than a separately-powered complete FPGA. It is, for the following reasons: 1) Only having to store the key bits really reduces the power demand. So it is reasonable to expect the device to maintain its keys for a decade+ with a very small battery. This is NOT possible if the whole device must remained powered, even in a low power quiescent state. 2) Independant power pins and power plane on the chip for the battery backup greatly simplify the implementation. If I need the whole FPGA to run on battery backup, I need a mechanism to switch between the normal power supply and battery, the FPGA needs to exist on a purely separate power plane, my bitfile MUST shutdown all I/Os into high impedance mode and clock and all activity when the power is switched. This model only requires that I hook up a battery to 2 specific pins on the device, with no other external or internal logic required, yet it brings security ALMOST to the level of a battery backed up device with the configuration loaded/always on. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 26713
Hello Stephen - Make sure you select an 18V02PC44 as opposed to an 1802PC44. Regards, Arthur Stephen Lohning wrote: > I have been trying to program the XC18V02 xilinx prom via jtag without > any success. > The JTAG programmer WebPACK 3.1WP@.x > Application version D.21 doesn't seem to regnize the part properly. > The part is the XC18v02_pc44 I think there is a mistake in the > associated bsd file > > attribute IDCODE_REGISTER of XC1802_pc44: entity is > "0000" & -- version > "0101000000000101" & -- part number > "00001001001" & -- manufacturer's id > "1"; -- required by standardArticle: 26714
1.
If there is SIGNIFICANT economic interest in reverse engineering the
design. The eqipment to go around the DES would not be any problem.
Just open up the chip.
Solution 1:
Get it into an asic tester and observer the triple DES input and output.
This gives you the key and the decrypted bitstream.
Solution 2:
Observe the state of the SRAM cells under an electron microscope.
Could be hard with 7 layer metal, but you can do it for only $10k
2.
If you now the full functionality of the chip, a redesign is probably
easier than the reverse engineering. But you might want to have
100% compatibility and your competitor just won't send you the spec.
But in any case, from observing the chip you can guess about the
functionality of a part of it.
You can then use formal verification software to extract the
corresponding circuit from the stolen netlist. This gives you a
smaller remaining netlist that you can observe and again guess
on part of the functionality. Some automatic reasoning, and so on...
It is just a matter of the right tools.
CU,
Kolja
In article <39F58D51.1C14B0B6@andraka.com>,
Ray Andraka <ray@andraka.com> wrote:
> True enough, but that is only the first step (and arguably the easiest
step) of
> reverse engineering a design from the bitstream. Once the design is
> reconstituted as a netlist of LUTs, you have essentially a flat
representation
> of the design with LUTs, FF's and carry chain elements as its only
primitives.
> WHile this can be reverse engineered, the effort to do so is
substantial even
> for small devices (I know, I had to discover the function of a 2064 a
few years
> ago for a client...that one only has 64 very simple logic cells and it
was no
> small effort) The effort to do the discovery was at least 3x the
effort for a
> design from scratch. I suspect that effort goes up faster than linear
as the
> number and complexity of the LUTs is increased.
>
> So the bottom line is the tools out there now make it possible to
recover the
> flat primitive level design, which is essentially what you get if you
capture
> the backannotated netlist from the tools (uses simprim library).
Getting that
> netlist into a form that allows you to understand the design is
another matter
> altogether. To get an idea of the effort it would take, take a *.vho
output
> from the placer on one of your designs and try to figure out from
there how it
> works. It's not trivial even when you know the design!
> > And, with a tool like Jbits for the Virtex, it is pretty
> > reasonable to go from a bitfile to a technology mapped (lut mapped)
> > netlist.
> >
> > The result can be pretty hard to understand, with
obsfucation
> > and other confusion, but going from bitfile->lut mapped netlist is a
> > reasonable operation. If there is a SIGNIFICANT ecomonic interest
for
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 26715Try this one which I happened to write Yesterday ! It is not general purpose, but it is good enough for the intended use and does not use nasty divisions... library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_ARITH.all; use IEEE.STD_LOGIC_UNSIGNED.all; library WORK; use WORK.all; package MATH is function LOG2(MAXADDRESS : INTEGER) return INTEGER; end MATH; library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_ARITH.all; use IEEE.STD_LOGIC_UNSIGNED.all; library WORK; use WORK.all; package body MATH is -- Will work for up to 32 bit function LOG2(MAXADDRESS : INTEGER) return INTEGER is variable temp : INTEGER; begin temp := 2; for I in 1 to 31 loop if(temp > MAXADDRESS) then return I; end if; temp := temp + temp; end loop; return 32; end; end MATH; -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "Peter Lang" <Peter.Lang@rmvmachinevision.de> wrote in message news:8t6m9d$abi$00$1@news.t-online.com... > Hi, > I am doing my first steps in VHDL. > I wanted to implement a log2-function using > Xilinx Foundation 3.1i with Synopsis FPGA Express 3.4. > I tried the following source-code, which I found here in the newsgroup. > But the Compiler found an error > > Dpm: Error: Non-static loop or event waits in only some branches detected > > I have no idea whats wrong. > > > package MATH is > function log2 ( num : integer) return integer; > end MATH; > > package body MATH is > function log2 ( num : integer) return integer is > variable diviser : integer; -- Divided to form > result > variable acc : integer; -- accumulates > result > begin > diviser := num; > acc := 0; > LogLoop : while (diviser >= 2) loop > diviser := diviser / 2; > acc := acc + 1; > end loop LogLoop; > return acc; > end function log2; > end MATH; > > > >Article: 26716
"Emanuele Russo" <emanuelerusso@tiscalinet.it> wrote in message news:8t4r44$4rv$1@pegasus.tiscalinet.it... > I'm a student and I've to synthetize a dual port memory in VHDL, but I've > some problems with BUSes... > ... can anyone help me with same example... > thank you, > > Emanuele Russo > The enclosed VHDL will synthesize to the internal Dual port RAMs in the Atmel AT40K series. -- ******************************************************************** -- SYNCH DPRAM -- ******************************************************************** -- HDLPlanner Start sdpram_prl -- Do not **Delete** previous line library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_ARITH.all; use IEEE.STD_LOGIC_UNSIGNED.all; library WORK; use WORK.all; entity sdpram_prl is -- synopsys template GENERIC (ADDR_WIDTH : INTEGER := 5; WIDTH : INTEGER := 4); port ( Ain : in STD_LOGIC_VECTOR(ADDR_WIDTH-1 downto 0); Aout : in STD_LOGIC_VECTOR(ADDR_WIDTH-1 downto 0); Din : in STD_LOGIC_VECTOR(WIDTH-1 downto 0); Dout : out STD_LOGIC_VECTOR(WIDTH-1 downto 0); OEN : in STD_LOGIC; WEN : in STD_LOGIC; CLK : in STD_LOGIC ); end sdpram_prl; library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_ARITH.all; use IEEE.STD_LOGIC_UNSIGNED.all; library WORK; use WORK.all; architecture RTL of sdpram_prl is constant clockEdge : STD_LOGIC := '1'; constant setOrResetLevel : STD_LOGIC := '0'; constant setOrReset : INTEGER := 0; TYPE twoDarray is ARRAY(0 to 2**ADDR_WIDTH - 1) of STD_LOGIC_VECTOR(WIDTH-1 downto 0); signal mem : twoDarray; begin dwrite: process (CLK,WEN,Ain) variable write_address : INTEGER; begin if (RISING_EDGE(CLK)) then write_address := CONV_INTEGER(Ain); if (WEN = '0') then mem(write_address) <= Din; end if; end if; end process dwrite; dread: process (OEN,Aout,mem) variable read_address : INTEGER; begin read_address := CONV_INTEGER(Aout); if (OEN = '0') then Dout <= mem(read_address); else for i in 0 to (WIDTH - 1) loop Dout(i) <= 'Z'; end loop; end if; end process dread; end RTL; -- ******************************************************************** -- ASYNCH DPRAM -- ******************************************************************** library IEEE ; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_ARITH.all; use IEEE.STD_LOGIC_UNSIGNED.all; library WORK; use WORK.all; entity adpram_prl is generic ( ADDR_WIDTH : INTEGER := 5; WIDTH : INTEGER := 4 ); PORT ( AIN : in STD_LOGIC_VECTOR (ADDR_WIDTH-1 downto 0); AOUT : in STD_LOGIC_VECTOR (ADDR_WIDTH-1 downto 0); DIN : in STD_LOGIC_VECTOR (WIDTH-1 downto 0); DOUT : OUT STD_LOGIC_VECTOR(WIDTH-1 downto 0); OEN : in STD_LOGIC; WEN : in STD_LOGIC ); end adpram_prl; architecture behv of adpram_prl is constant clockEdge : STD_LOGIC := '1'; constant setOrResetLevel : STD_LOGIC := '0'; constant setOrReset: integer := 0; type twoDarray is array(0 to 2**ADDR_WIDTH - 1) of STD_LOGIC_VECTOR (WIDTH-1 downto 0); signal mem : twoDarray ; begin dwrite: process (WEN,AIN,DIN) variable write_address : INTEGER; begin write_address := CONV_INTEGER(AIN); if(WEN = '0') then mem(write_address) <= DIN; end if; end process dwrite; dread: process (OEN,AOUT,mem) variable read_address : INTEGER; begin read_address := CONV_INTEGER(AOUT); if(OEN = '0') then DOUT <= mem(read_address); else for i in 0 to (WIDTH - 1) loop DOUT(i) <= 'Z'; end loop; end if; end process dread; end behv; -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel SwedenArticle: 26717
ROC is basically for simulation. Put it in your design to simulate the effect of the reset on configuration. If it is in the design, synplicity will black box it into the edif netlist; The alliance tools don't do anything with it though. You will find it in the unisim and simprim libraries. The VHO output from the ALliance tools will include it in the mapped (timing) VHDL output to get proper simulation. Muzaffer Kal wrote: > > hi, > I need an external reset and an internal power on reset type signal. > In Synplicity libraries, there is a ROC cell for Virtex but there are > no simulation libraries in Alliance toolset for ROC. Is this cell > valid for Virtex ? I am also using a DLL. Is there a way to make sure > that ROC doesn't go low before LOCK happens ? Also what is the timing > for ROC signal after a configuration ? > > thanks, > > Muzaffer > http://www.dspia.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26718
USCOM offers full service virtual web hosting starting at only $3.95 month with high traffic, e-mail, FrontPage and Real Audio support, etc. We operate an 100mbps connection to the Internet which is more than 80 times a usual T-1 or 3 times larger than a regular T-3 connection. Web Hosting Services : http://www.uscom.tv Sign up today and recive $15 Service Credit !Article: 26719
On Wed, 25 Oct 2000 11:44:15 -0700, Brian Dipert wrote: >Philip wrote: >>I spoke to someone at Xilinx about this, and he confirmed that to the >>extent of the article, what is disclosed is now public, and Brian Dipert >>did not reveal stuff he shouldn't have under some NDA. > >Philip, Philip, Philip....you didn't think I was misbehaving, did you? >;-) Hardly. I already knew about this stuff (and more) under NDA, and like most NDA's, they no longer cover material after it is made publicly available (providing it wasnt made public through violating my NDA). I just was checking the limits on what I can now talk about to others. I have always trusted you :-). >Yes, my article marked the first public disclosure of Triple DES >support in Virtex-II >Brian Dipert Evan wrote: >I expect you're right. It does seem rather odd though - it was NDA'ed >2 weeks ago and suddenly turns up in the press, which smells somewhat >like a cock-up. Or just part of the Virtex-II strip-tease. Full data sheets are not yet publicly available, nor detailed CLB, BRAM, MPY, ..... I think we will continue to get snippets on capabilities up untill it becomes available, maybe even beyond that. With regard to your comments about what happens to the key on battery failure, and having to send out the key to the customer, I dont see the issue. Either you trust the customers, in which case you dont need this feature, or you dont trust them, in which case you will need the board to be returned. Several others have written: > but I just open up the chip and read out the KEY. Sure. Piece of cake. While I wont claim that this is impossible, I believe you are wildly underestimating the difficulty of removing a surface mount chip from a PCB, while keeping the battery connected, and then opening the device up, and the fun you will have trying to probe flipflops on the chip (where are they exactly), especially with geometries that are sub-visible wave length. So get out your handy SEM, and remember, keep that battery attached. (how did you do that for the BGA package part anyway?) (how did you etch the epoxy (PQFP) while keeping the key alive?) And when you have the key, and decrypt the bitstream, you still just have a bitstream. Good enough to clone a design, not yet a documented schematic/HDL :-) Philip Philip Freidin FliptronicsArticle: 26720
Hallo Franz, warum benutzt Du nicht IntelliFlow, der übernimmt i.A. alle Einstellungen und Parameter. Bei mir funktioniert dieses ganz gut. Gruß Uwe "Franz Hollerer" <hollerer@hephy.oeaw.ac.at> schrieb im Newsbeitrag news:39F57AF3.DACE8CD1@hephy.oeaw.ac.at... > Hi, > > I have some questions about timing simulation and I hope > that somebody can help me. > > The Xilinx software creates time_sim.vhd and time_sim.sdf. > I now want to do a timing simulation with Fusion/SpeedWave. > It principally works. But if I choose time_sim.sdf for further > timing data, fusion prints a lot of error messages (see below). > > Do I really need the .sdf file for a correct timing simulation or is > the > time_sim.vhd file enough? > > Any hints? > > Thanks > Franz Hollerer > > ----------------------------------------------------------------------- > error message > ----------------------------------------------------------------------- > Starting VITAL SDF Backannotation. > Processing SDF file: D:\hollerer\vhdl\tcs\export_dir\time_sim.sdf > Hierarchical Path Prefix: / > Timing mode: Max > Hierarchy divider character: / > Timescale factor: 0.001 ns > ** Error at SDF file line number 21: > For this hierarchical path name in the SDF file: > '/PRE1_CNT_REG_0_Q' > Could not find region level 'PRE1_CNT_REG_0_Q' in the VHDL design. > ** Error at SDF file line number 22: > For this hierarchical path name in the SDF file: > '/PRE1_CNT_REG_0_Q' > Could not find region level 'PRE1_CNT_REG_0_Q' in the VHDL design. > ** Error at SDF file line number 23: > For this hierarchical path name in the SDF file: > '/PRE1_CNT_REG_0_Q' > : > : > : > and so on > > -- > Institut fuer Hochenergiephysik > Nikolsdorfer Gasse 18 > 1050 Wien > Austria > > Tel: (+43-1)5447328/50 > >Article: 26721
Hi there! I would like to know where can I look for this topic and if you have some tipps plz, tell me. tx korgArticle: 26722
On Wed, 25 Oct 2000 19:43:37 -0700, Philip Freidin <philip@fliptronics.com> wrote: >Several others have written: >> but I just open up the chip and read out the KEY. > >Sure. Piece of cake. While I wont claim that this is impossible, >I believe you are wildly underestimating the difficulty of removing >a surface mount chip from a PCB, while keeping the battery >connected, and then opening the device up, and the fun you will >have trying to probe flipflops on the chip (where are they exactly), >especially with geometries that are sub-visible wave length. So >get out your handy SEM, and remember, keep that battery >attached. >(how did you do that for the BGA package part anyway?) >(how did you etch the epoxy (PQFP) while keeping the key alive?) >And when you have the key, and decrypt the bitstream, you still >just have a bitstream. Good enough to clone a design, not yet >a documented schematic/HDL :-) I was at a seminar 2 or 3 years ago on pay TV security. The presenter showed a slide of some guy's garage in Germany, with an electron microscope in it. He'd got it second-hand for a few thousand dollars, IIRC. He burned the top off a processor on a decoder card, attached probes to a bus under the SEM, and reverse-engineered the security algorithm on the chip. The info was then used to produce cloned decoder cards. Sure, a PCB with a battery-backed Virtex-II on it is going to be much harder than this (I think), but I bet someone will be trying it as soon as there's a commercial reason to do so. Another aspect of this is that the goal may not actually be to reverse-engineer the bitstream or find out what's in the chip. My current problem is that I have encoded MPEG which I have to decode. As soon as the pirate's found the clear MPEG, he can record it and he's won. He's not going to have any interest whatever in the other stuff I've got in the chip - any competent engineer could duplicate that from scratch in a few weeks, if they even needed it to start with. I suspect that a lot of FPGA security is like this - the engineer thinks that it's his hard work that has to be protected, but the real secret is something completely different, and is probably a lot less secure than the FPGA bitstream. EvanArticle: 26723
On 25 Oct 2000 20:25:39 GMT, nweaver@soda.CSUA.Berkeley.EDU (Nicholas Weaver) wrote: > This model only requires that I hook up a battery to 2 >specific pins on the device, with no other external or internal logic >required, yet it brings security ALMOST to the level of a battery >backed up device with the configuration loaded/always on. Yes, I agree - it's a lot more practical and may even be feasible in a real product. But look at it from the customer's point of view. If something does go wrong (sunspots? lightning? someone brings their radioactive watch dial too close to the case? whatever..) then they have to return the box to the manufacturer to get it fixed. PC's used to (still have?) a battery-backed CMOS RAM. It hasn't happened to me over the last few years, but I'm pretty sure that I've had problems with the RAM being corrupted. I'm also pretty sure that I wouldn't have bought the PC in the first place if it had to be shipped back to the (possibly defunct) manufacturer to reload the CMOS. EvanArticle: 26724
On Wed, 25 Oct 2000 11:50:03 -0700, Brian Dipert <bdipert@NOSPAM.pacbell.net> wrote: >'A lot' of discussion threads here find their way into my articles, as >inspiration for topics if nothing else. After all, why waste my time >writing on stuff that isn't of interest to y'all? ;-) I look forward to the fully-documented traffic light controller design feature, a subject close to everyone's heart here... Evan
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z