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
What happens if you get an alpha hit and flip a configuration bit? Does that ever happen? Seems like it must not be entirely uncommon, since a lot of RAM has parity bits to detect such flips. I think with the smaller packages it's also more likely that radioactivity from the lead in the solder can flip a bit. Then there's no way to reset without a PROM. The 3DES feature, if available, sounds better, although you still have to program the key in at the IP developer's site, which isnt' always convenient, especially if the IP developer isn't the same company making the hardware. One way around that is that Xilinx could program a default and unique key into each V2 and then keep a database that correlates the serial no. and the key. Then Xilinx could provide a service in which the IP developer sends an unencrypted bitstream to Xilinx, and the final user could tell Xilinx (through an automated website) their serial numbers and Xilinx would send encrypted bitstreams. The disadvantages to this are that you need a different bitstream for each part and somehow Xilinx would have to know who was authorized to get the encrypted bitstreams. OK, it's a bad idea. -Kevin "Ray Andraka" <ray@andraka.com> wrote in message news:3D458CA9.4E5A2478@andraka.com... > We've used the battery backed Xilinx solution before (in our case it was mission > equipment that got a download before the mission, and remained powered up until > the mission was complete). It does indeed offer more security than the anitfuse > because the bitstream is not present anywhere on the board except in the > programmed FPGA. Once power is removed, there is nothing to recover (well there > may be some residual charges on the gates that are even harder to detect and > reverse engineer than the anitfuses). > > The battery maintained SRAM based gives you a couple advantages over the > anitfuse for this scenario: 1) you retain the flexibility of an FPGA, which > helps tremdously in minimizing inventory, putting in upgrades, and testability. > With the Antifuse, it may as well be an ASIC once it is programmed, 2) and more > significantly, you have the advanced features of the xilinx FPGAs available, > which make DSP applications in a single chip possible, specifically the fast > carry chains for fast, compact arithmetic and the distributed memory which is > used for compact delay queues which occur very frequently in DSP applications > (eg filters). The big disadvantage is that if the configuration is lost, the > module has to be returned for service. It can't be revived without an external > source of bitstream. > > Like the Antifuse, the readback can be disabled on an SRAM FPGA making so the > bitstream cannot be read out of the device, and the device is complex enough > that even if it could, the reverse engineering effort would be substantial. > Still in either case, extreme methods could be used to recover the > configuration. The question comes down to what level of protection raises the > price of reverse engineering to the point where it is not worth attacking it? > The Antifuse does have an advantage in radiation hardness, which is exactly > where these devices have carved their greatest niche. >Article: 45626
Yeah, it used to be a problem. I hadn't looked at the tools output for that
case in a while. I knew the Virtex could tap the chain, but for along time the
tools wouldn't let you do it.
MikeJ wrote:
> Paranoia !
> I just thought I would check again the risc5x code I posted earlier works
> correctly.
> Looking with FPGA Editor it does build a single 8 lut long carry chain and
> the 4.2i tools correctly strips off the DC carry bit, in my case using the
> YB slice output.
> Phew !
>
> Mikej
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D4541C8.FF7AC8B6@andraka.com...
> > It may very well be tapping it. The virtex architecture supports tapping
> the carry chain
> > and sending it out the XB and YB outputs of the slice. I have had trouble
> in the past
> > getting the software to use that tap when the carry out to the next slice
> is also used,
> > although I don't recall if it was a xilinx problem or a synplify problem.
> If you are
> > using 4.x there is a good possibility that it is properly tapping the
> carry chain. If you
> > are using the paid version of the Xilinx software, you can open the FPGA
> editor and
> > examine the results directly. If not, you can tell from the timing report
> if you have it
> > show all timing and then you find the carry chain in question.
> >
> > Dmitri Katchalov wrote:
> >
> > > Thanks again everyone.
> > >
> > > Using your suggestions I've managed to implement PIC-style
> > > ADD/SUB/INC/DEC with carry and half-carry out in just 4 slices, see code
> below.
> > > I'm not sure about the polarity of the borrow bit though.
> > >
> > > Synthesis infers 2 5-bit adders, later optimised into 4-bit
> > > adders with carry in/out. P&R places them in one column one immediately
> > > on top of another (in otherwise empty FPGA). I don't have suffucient
> > > knowledge to tell from all those the reports whether the carry chain
> > > is broken or continues over. It does seem to continue over.
> > >
> > > Here is the code, comments appreciated.
> > >
> > > Regards,
> > > Dmitri
> > >
> > > library IEEE;
> > > use IEEE.STD_LOGIC_1164.ALL;
> > > use IEEE.NUMERIC_STD.ALL;
> > >
> > > entity alu_adder is
> > > Port ( A,B: in std_logic_vector(7 downto 0);
> > > op: in std_logic_vector(1 downto 0);
> > > Y: out std_logic_vector(7 downto 0);
> > > carry_out: out std_logic;
> > > dc_out: out std_logic );
> > > constant ADD : std_logic_vector(1 downto 0) := "00";
> > > constant SUB : std_logic_vector(1 downto 0) := "01";
> > > constant DEC : std_logic_vector(1 downto 0) := "10";
> > > constant INC : std_logic_vector(1 downto 0) := "11";
> > > end entity alu_adder;
> > >
> > > architecture Behavioral of alu_adder is
> > > begin
> > > process( A, B, op )
> > > variable tmp: std_logic_vector(7 downto 0);
> > > variable lo_nibble, hi_nibble: unsigned(5 downto 0);
> > > variable cin: std_logic;
> > > begin
> > > case op is
> > > when INC => tmp := (others => '0'); cin := '1';
> > > when DEC => tmp := (others => '1'); cin := '0';
> > > when SUB => tmp := not B; cin := '1';
> > > when ADD => tmp := B; cin := '0';
> > > when others => tmp := (others => '-'); cin := '-';
> > > end case;
> > >
> > > lo_nibble := unsigned('0' & A(3 downto 0) & cin ) +
> > > unsigned('0' & tmp(3 downto 0) & cin );
> > >
> > > hi_nibble := unsigned('0' & A(7 downto 4) & lo_nibble(5) ) +
> > > unsigned('0' & tmp(7 downto 4) & lo_nibble(5) );
> > >
> > > Y <= std_logic_vector( hi_nibble(4 downto 1) & lo_nibble(4 downto
> 1));
> > > dc_out <= lo_nibble(5);
> > > carry_out <= hi_nibble(5);
> > > end process;
> > > end architecture Behavioral;
> > >
> > > Ray Andraka <ray@andraka.com> wrote in message
> news:<3D43FE74.BC6780AD@andraka.com>...
> > > > In order to tap the carry chain you need to add an extra bit in the
> carry
> > > > chain. The synthesis tools won't do that for you, and in fact will
> not
> > > > infer a caryy chain for less than about 7 bits. Using 2 four bit
> counters
> > > > you incur the delay to get off and then onto the second chain, where
> with a
> > > > single chain you only incur ~100ps. With 2 4 bit counts, it is likely
> not
> > > > your worst case path anyway, so for the sake of simplicity,
> readability and
> > > > maintainability of the code, it is probably better to just infer them
> as
> > > > separate counters. My point was that what you asked about could be
> done,
> > > > but it is not done automatically by the tools and it takes a bit of
> > > > finabling to make it work.
> > > >
> > > > Eric Smith wrote:
> > > >
> > > > > > * How do I get the half-carry bit out of the 8bit adder? I guess I
> can
> > > > > > instantiate/infer two separate 4bit adders. Is there a better way?
> > > > >
> > > > > Ray Andraka <ray@andraka.com> writes:
> > > > > > It can be done, but it takes a little mind-bending. Basically,
> you
> > > > > > need to turn your 8 bit adder into a 9 bit one with bit 4 being a
> > > > > > dummy so that you can pull out the carry out through the bit. It
> > > > > > takes a bit of caressing the tools to make them infer it.
> > > > >
> > > > > Is there any advantage to doing that rather than two four-bit
> adders?
> > > > > For instance, with two four-bit adders, does the synthesizer not
> > > > > recognize that it can continue the carry chain between them? Or
> > > > > does the FPGA not allow you to tap the carry from intermediate
> stages
> > > > > of the chain?
> >
> > --
> > --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
> >
> > "They that give up essential liberty to obtain a little
> > temporary safety deserve neither liberty nor safety."
> > -Benjamin Franklin, 1759
> >
> >
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45627
We don't use the muxf5's all that much, but that is mostly because they are
arranged the wrong way to match the bit pitch of the arithmetic. Instead of
coupling the two luts vertically, they'd be much more useful if they combined
horizontally across slices so that the output pitch matched the arithmetic bit
pitch.
MikeJ wrote:
> SAVE THE MUX F5 !!! I use them all the time !
> 8 : 1 mux in 1 CLB (virtex E) : 4 LUT4, 2 F5s 1 F6 perfect !
> you can (and we do) have chips full of these things.
> Mikej
>
> "John_H" <johnhandwork@mail.com> wrote in message
> news:3D416B70.B7E579BD@mail.com...
> > I love my F5 muxes! Synplify does a decent job of inferring them (less
> > common in general logic, more common in multiplexers). It's nice to have
> a
> > decode of the form register[index[2:0]] and get it all into one CLB with
> > some MUXF5 and MUXF6 elements. Bigger multiplexers just use more than one
> > stage of these. Heck, in the Virtex type parts I instantiate a "rotator"
> > that uses cross-coupled F6 muxes to give me a barrel rotate kind of
> > functionality with (more than) twice the efficiency of the standard
> > multiplexers alone. I'm just a little sad the Virtex-II doesn't
> > cross-couple the MUXF6 elements - I have to use a MUXF8 to use that same
> > technique! Less efficiency overall.
> >
> > Ahhh, esoteric design techniques . . . turning a 64 bit barrel shifter
> from
> > 192 slices to about 66 with one fewer levels of logic. Not for everyone
> but
> > fun for many.
> >
> > - John_H
> > MUXFn afficionado
> >
> >
> > Kevin Brace wrote:
> >
> > > I suppose, when BX or BY input is tied to a FF, it looks like to me you
> > > won't be able to use an F5MUX (A multiplexer that ties two 4-input LUTs
> > > to recreate a 4:1 MUX or a 5-input LUT.), but since most synthesis tools
> > > cannot seem to take advantage of F5MUX anyway, that shouldn't be a huge
> > > penalty.
> > > I do wonder, does anyone use F5MUX?
> > > Perhaps, shouldn't Xilinx get rid of it?
> >
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45628
The design we did that in was back in the mid 90's when devices were smaller and
geometries were bigger. At the time we analyzed the probability of an upset and
determined that miniscule compared with other failure modes. WIth the much
bigger devices and smaller geometries, the analysis would obviously have to be
repeated. Probably the biggest factor to weigh is the time between reloads (in
our case the load only had to last a few hours). It would probably not be
appropriate for a design that is not periodically serviced.
Kevin Neilson wrote:
> What happens if you get an alpha hit and flip a configuration bit? Does
> that ever happen? Seems like it must not be entirely uncommon, since a lot
> of RAM has parity bits to detect such flips. I think with the smaller
> packages it's also more likely that radioactivity from the lead in the
> solder can flip a bit. Then there's no way to reset without a PROM.
>
> The 3DES feature, if available, sounds better, although you still have to
> program the key in at the IP developer's site, which isnt' always
> convenient, especially if the IP developer isn't the same company making the
> hardware. One way around that is that Xilinx could program a default and
> unique key into each V2 and then keep a database that correlates the serial
> no. and the key. Then Xilinx could provide a service in which the IP
> developer sends an unencrypted bitstream to Xilinx, and the final user could
> tell Xilinx (through an automated website) their serial numbers and Xilinx
> would send encrypted bitstreams. The disadvantages to this are that you
> need a different bitstream for each part and somehow Xilinx would have to
> know who was authorized to get the encrypted bitstreams. OK, it's a bad
> idea.
> -Kevin
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3D458CA9.4E5A2478@andraka.com...
> > We've used the battery backed Xilinx solution before (in our case it was
> mission
> > equipment that got a download before the mission, and remained powered up
> until
> > the mission was complete). It does indeed offer more security than the
> anitfuse
> > because the bitstream is not present anywhere on the board except in the
> > programmed FPGA. Once power is removed, there is nothing to recover (well
> there
> > may be some residual charges on the gates that are even harder to detect
> and
> > reverse engineer than the anitfuses).
> >
> > The battery maintained SRAM based gives you a couple advantages over the
> > anitfuse for this scenario: 1) you retain the flexibility of an FPGA,
> which
> > helps tremdously in minimizing inventory, putting in upgrades, and
> testability.
> > With the Antifuse, it may as well be an ASIC once it is programmed, 2) and
> more
> > significantly, you have the advanced features of the xilinx FPGAs
> available,
> > which make DSP applications in a single chip possible, specifically the
> fast
> > carry chains for fast, compact arithmetic and the distributed memory which
> is
> > used for compact delay queues which occur very frequently in DSP
> applications
> > (eg filters). The big disadvantage is that if the configuration is lost,
> the
> > module has to be returned for service. It can't be revived without an
> external
> > source of bitstream.
> >
> > Like the Antifuse, the readback can be disabled on an SRAM FPGA making so
> the
> > bitstream cannot be read out of the device, and the device is complex
> enough
> > that even if it could, the reverse engineering effort would be
> substantial.
> > Still in either case, extreme methods could be used to recover the
> > configuration. The question comes down to what level of protection raises
> the
> > price of reverse engineering to the point where it is not worth attacking
> it?
> > The Antifuse does have an advantage in radiation hardness, which is
> exactly
> > where these devices have carved their greatest niche.
> >
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45629In article <3D45F22C.4B2EDCC8@andraka.com>, Ray Andraka <ray@andraka.com> wrote: >We don't use the muxf5's all that much, but that is mostly because they are >arranged the wrong way to match the bit pitch of the arithmetic. Instead of >coupling the two luts vertically, they'd be much more useful if they combined >horizontally across slices so that the output pitch matched the arithmetic bit >pitch. Also, remember the F5 and F6 mux effectively costs nothing (a couple of config bits), since it uses the same inputs as are used for carryin and independantly using the flip flops. Remember that most of the CLB cost is the input and output buffers, not the actual logic inside, so reusing inputs (BX/BY) for other purposes makes sense, so I doubt xilinx would ever drop the F5 and F6 muxes. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 45630
Synopsys FPGA Compiler II Synplicity SynplifyPro Leonardo -- DarylArticle: 45631
>3) Reverse engineering antifuse FPGAs is an almost impossible task.
...
Several years ago, I probably wouldn't have objected to that statement.
Today, I'm a bit suspicious. Maybe even cynical.
Did you read the paper that Ray posted the URL for recently?
It was a real eye opener for me. And it's already several
years old.
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf
Much of the technology used to debug/develop chips is also useful
when hacking/cracking them. If we are discussing security, we need
to make sure we consider modern threats as well well as modern
defenses.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Article: 45632Look at Lattice's new ISP device they just released in the press today. Uses EEPROM inside but loads into SRAM like an FPGA. Not read the datasheet yet ... "Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de> wrote in message news:ai2om4$10v3kt$1@ID-137468.news.dfncis.de... > Hi everybody, > > I am looking for a FPGA that I have to use in a secure manner. I have to do > a project in which the FPGA is use in a 'military' like environment. > > Can somebody tell me which vendors and FPGA families are out there with > 'special' security features? and which security features that are and what > are they good for? > > The FPGA can use any technology (SRAM, antifues, flash ...), but it has to > be secure against as much attacks as possible. > > Thanks everybody for your time. > > I really appreciate your help > > Thomas > > > > P.S: If you like to email me, just delete XY in the following email-address: > wollingerXY@crypto.ruhr-uni-bochum.de > > (I do not know if this is the right newsgroup to post this question - if not > please could somebody let me know where is a better place to post.) > > > > >Article: 45633
I'm am trying to use a RAMB4_S8_S16 dual port block ram in a virtex e
device. Port A (4 bits) is clocked by the positive edge of the clk.
Port B (8 bits) is clocked by the negative edge of the clk. The word
length is 36 bits, so I'm instantiating 9 devices and splitting up the
data bus to each. The write operation (36 words) works fine, but when
I try to read out (18 words) the data is all scrambled. I'm not
getting timing errors or access problems, just scrambled data on the
72 bit side (9 devices * 8 bits each) I would like to use the dual
port to save time by automatically providing the bus conversion from
36 to 72 bits. Am I doing something wrong, or is the model just broke?
Here is some code:
----------------------------------------------------------------------------
-- block ram component
-- ram is 36 bits wide configured as 9 blocks of (1024x4)
----------------------------------------------------------------------------
component ramb4_s4_s8
port (
dia : in std_logic_vector (3 downto 0);
wea : in std_logic;
ena : in std_logic;
rsta : in std_logic;
clka : in std_logic;
addra : in std_logic_vector (9 downto 0);
doa : out std_logic_vector (3 downto 0);
dib : in std_logic_vector (7 downto 0);
web : in std_logic;
enb : in std_logic;
rstb : in std_logic;
clkb : in std_logic;
addrb : in std_logic_vector (8 downto 0);
dob : out std_logic_vector (7 downto 0)
);
end component;
...
bram_fr_b1: ramb4_s4_s8
port map(
dia => bram_a_data(3 downto 0),
wea => bram_a_write,
ena => logic_hi,
rsta => reset,
clka => clk,
addra => bram_a_addr(9 downto 0),
doa => bram_a_data(3 downto 0),
dib => vector8_lo,
web => bram_b_write,
enb => bram_b_en,
rstb => reset,
clkb => clk_not,
addrb => bram_b_addr(8 downto 0),
dob => bram_b_data(7 downto 0)
);
bram_fr_b2: ramb4_s4_s8
port map(
dia => bram_a_data(7 downto 4),
wea => bram_a_write,
ena => logic_hi,
rsta => reset,
clka => clk,
addra => bram_a_addr(9 downto 0),
doa => bram_a_data(7 downto 4),
dib => vector8_lo,
web => bram_b_write,
enb => bram_b_en,
rstb => reset,
clkb => clk_not,
addrb => bram_b_addr(8 downto 0),
dob => bram_b_data(15 downto 8)
);
...
bram_fr_b3: ramb4_s4_s8
...
bram_fr_b4: ramb4_s4_s8
...
bram_fr_b5: ramb4_s4_s8
...
bram_fr_b6: ramb4_s4_s8
...
bram_fr_b7: ramb4_s4_s8
...
bram_fr_b8: ramb4_s4_s8
...
bram_fr_b9: ramb4_s4_s8
port map(
dia => bram_a_data(35 downto 32),
wea => bram_a_write,
ena => logic_hi,
rsta => reset,
clka => clk,
addra => bram_a_addr(9 downto 0),
doa => bram_a_data(35 downto 32),
dib => vector8_lo,
web => bram_b_write,
enb => bram_b_en,
rstb => reset,
clkb => clk_not,
addrb => bram_b_addr(8 downto 0),
dob => bram_b_data(71 downto 64)
);
Am I portmapping this wrong., Has anybody else had this problem with
dual ports of different sizes?
Mike
Article: 45634Thanks everybody for your postings. It was very interesting and informative to read everything. Here more precisely the qualities/features the FPGA should have: - secure against reverse engineering - should not have any documented AND NON-documented security holes - _this feature is not necessary if the FPGA cannot be reverse engineered, BUT would be nice to have_: fast and definitive deletion of the data (if somebody tries to get the information stored on the FPGA) -> deletion without destroying the FPGA and if necessary also destroying the FPGA (or the internal structure After the resent postings some more questions came to my mind: - I did not find any documentation about any physical attacks against FPGAs. Is there public available documentation? How much effort is needed to reverse engineering an FPGA (cost, time .)? How can I reset the Security Bit (cost, time .)? and so on. - Is there an article where different FPGA families are compared (same technology)? - I suppose some of the FPGAs are better in one an the others in a different feature - - Is there an article where different FPGA families with different technologies are compared? - Where can I find information about the definite deletion of the configuration (and/or keys) on a FPGA? Thank you very much in advance Thomas Wollinger "Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de> schrieb im Newsbeitrag news:ai2om4$10v3kt$1@ID-137468.news.dfncis.de... > Hi everybody, > > I am looking for a FPGA that I have to use in a secure manner. I have to do > a project in which the FPGA is use in a 'military' like environment. > > Can somebody tell me which vendors and FPGA families are out there with > 'special' security features? and which security features that are and what > are they good for? > > The FPGA can use any technology (SRAM, antifues, flash ...), but it has to > be secure against as much attacks as possible. > > Thanks everybody for your time. > > I really appreciate your help > > Thomas > > > > P.S: If you like to email me, just delete XY in the following email-address: > wollingerXY@crypto.ruhr-uni-bochum.de > > (I do not know if this is the right newsgroup to post this question - if not > please could somebody let me know where is a better place to post.) > > > > >Article: 45635
hristo schrieb: > hello, > may be basic question > if someone has to implement an FIR using bit serial, he has to see the > output wordlength, thus the FIR bit growth. Then, he needs to expand the > input data with zero to have regular wordlength through the structure > > in parrallel we have not to do that Yes, since the significance is defined via the transmission line and bit serial arithmetic uses only one line per operand. But why should be the extension a problem. Than the computation time is defined via the operand bits stored in operators. Have a look on my publications on http://www.uni-magdeburg.de/reineman/index.html Bye Tom!Article: 45636
Hello!
During the struggle of trying to load a Spartan-XL in Express Mode, I have
observed that the actual bit stream made from Xilinx' own BitGen tool does
not seem to match the format stated in the Spartan-XL data sheet
http://direct.xilinx.com/partinfo/ds060.pdf at page 32; right column...
The outputted data looks as for the Serial Modes...
Thus - could anyone help me with this:
- Can BitGen make the Express Mode bit stream at all...?
- If 'yes' - what should e.g. bitgen.ut then look like, or what
should be selected in the graphics interface to BitGen in ISE 4 ...?
- If 'no' - which application to use then...?
Thanks in advance.
Jesper Kristensen.
Article: 45637<mrmikehicks@earthlink.net> wrote > Am I portmapping this wrong., Has anybody else had this problem with > dual ports of different sizes? > Mike Connect the "bram_b_data" bus in this way: bram_fr_b1: dob(3 downto 0) => bram_b_data(3 downto 0) dob(7 downto 4) => bram_b_data(39 downto 36) bram_fr_b2: dob(3 downto 0) => bram_b_data(7 downto 4) dob(7 downto 4) => bram_b_data(43 downto 40) ... bram_fr_b9: dob(3 downto 0) => bram_b_data(35 downto 32) dob(7 downto 4) => bram_b_data(71 downto 68) This may give you the result you expect MichaelArticle: 45638
Hi all, Are the Virtex-II pro IOs LVTTL 3.3V tolerant or not? LaurentArticle: 45639
Looks like a couple of good thesis topics :-)
Thomas Wollinger wrote:
> Thanks everybody for your postings. It was very interesting and informative
> to read everything.
>
> Here more precisely the qualities/features the FPGA should have:
>
> - secure against reverse engineering
>
> - should not have any documented AND NON-documented security holes
>
> - _this feature is not necessary if the FPGA cannot be reverse engineered,
> BUT would be nice to have_: fast and definitive deletion of the data (if
> somebody tries to get the information stored on the FPGA) -> deletion
> without destroying the FPGA and if necessary also destroying the FPGA (or
> the internal structure
>
> After the resent postings some more questions came to my mind:
>
> - I did not find any documentation about any physical attacks against FPGAs.
> Is there public available documentation? How much effort is needed to
> reverse engineering an FPGA (cost, time .)? How can I reset the Security Bit
> (cost, time .)? and so on.
>
> - Is there an article where different FPGA families are compared (same
> technology)? - I suppose some of the FPGAs are better in one an the others
> in a different feature -
>
> - Is there an article where different FPGA families with different
> technologies are compared?
>
> - Where can I find information about the definite deletion of the
> configuration (and/or keys) on a FPGA?
>
> Thank you very much in advance
>
> Thomas Wollinger
>
> "Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de> schrieb im
> Newsbeitrag news:ai2om4$10v3kt$1@ID-137468.news.dfncis.de...
> > Hi everybody,
> >
> > I am looking for a FPGA that I have to use in a secure manner. I have to
> do
> > a project in which the FPGA is use in a 'military' like environment.
> >
> > Can somebody tell me which vendors and FPGA families are out there with
> > 'special' security features? and which security features that are and what
> > are they good for?
> >
> > The FPGA can use any technology (SRAM, antifues, flash ...), but it has to
> > be secure against as much attacks as possible.
> >
> > Thanks everybody for your time.
> >
> > I really appreciate your help
> >
> > Thomas
> >
> >
> >
> > P.S: If you like to email me, just delete XY in the following
> email-address:
> > wollingerXY@crypto.ruhr-uni-bochum.de
> >
> > (I do not know if this is the right newsgroup to post this question - if
> not
> > please could somebody let me know where is a better place to post.)
> >
> >
> >
> >
> >
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 45640Even 3DES isn't uncrackable if the system that's using it isn't implemented correctly: http://www.cl.cam.ac.uk/~rnc1/descrack/index.html Note for those that take these discussions too seriously: I know this link isn't applicable to the discussion here, I was just amused by the irony of the hardware that was used to implement the 3DES crack. -Pete- Manfred Kraus <newsreply@cesys.com> wrote in message news:ai3h07$10mg5i$1@ID-22088.news.dfncis.de... > Xilinx Virtex-II has DES encryption. > Even if someone manages it to get the configuration bitstream, > it is useless without the (secret) keys. > > -Manfred > >Article: 45641
Hello Friends, I have a DDR SDRAM controller entity and a test entity in a synplify project. I can compile & implement & route successfuly. However, if I produce a netlist out of DDR SDRAM controller entity and use this with the test entity it doesn't work correctly. Does anyone had a similar problem? Thanx, ErsinArticle: 45642
Mike wrote: >I would like to use the dual port to save time by automatically >providing the bus conversion from 36 to 72 bits. Am I doing >something wrong, or is the model just broke? take a look at this old thread: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm 010813225155.01553.00000107%40mb-ci.aol.com&rnum=7 BrianArticle: 45643
Can anybody point me towards a decent Virtex-II based video board. I am working on video compression (MPEG). How about Virtex-II Pro (the one with a Power-PC hard processor), is there any demo board around based on it? Cheers.Article: 45644
Hello folks, Can you let me know what the maximum FIR filter coefficient width is you have implemented on FPGA please? Also, what are the typical widths you find yourself implementing. Thanks for your time, KenArticle: 45645
Hal thanks for the link. One thing that does not apply to antifuse is topside visual inspection. So at that point one would have to view the device from the side taking slices... that in itself is going to be very difficult to perform accurately and precisily. What are the chances someone could do this on a 1 or 2 million system gate device 100% accurately in an timeframe that would make the effort worthwhile? Other than that technique everyone is again on the same playing field when it comes to available techniques of reverse engineeing. The downside to SRAM is that it offers a second point of attack... the bit stream. Yes I realize some of the newer Xilinx parts try may eliminate that risk but in doing so they leave the risk of an inoperable device in the event of battery failure. Your security risks are a function of the family used. Tim "Hal Murray" <hmurray@suespammers.org> wrote in message news:ukc1g5lrrt7cb4@corp.supernews.com... > > >3) Reverse engineering antifuse FPGAs is an almost impossible task. > ... > > Several years ago, I probably wouldn't have objected to that statement. > Today, I'm a bit suspicious. Maybe even cynical. > > Did you read the paper that Ray posted the URL for recently? > It was a real eye opener for me. And it's already several > years old. > http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf > http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf > > > Much of the technology used to debug/develop chips is also useful > when hacking/cracking them. If we are discussing security, we need > to make sure we consider modern threats as well well as modern > defenses. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam. >Article: 45647
Does anyone know where I can find an ORCAD capture library symbol for a PQ240 VirtexE part?Article: 45648
Daryl wrote: > Synopsys FPGA Compiler II > Synplicity SynplifyPro > Leonardo These products are a moving target. Very few readers use more than one at the latest version. Best thing to do is take a represntative design that simulates correctly and try them yourself. -- Mike TreselerArticle: 45649
I'm looking for an app note or article that has an example of implementing impedance measuring code in an FPGA (preferably the Virtex-II Pro). Any advice/comments are welcome. Daniel
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