Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 45625

Article: 45625
Subject: Re: secure FPGA
From: "Kevin Neilson" <kevin-neilson@removethistextattbi.com>
Date: Mon, 29 Jul 2002 23:00:33 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: ALU in VHDL and a bunch of questions
From: Ray Andraka <ray@andraka.com>
Date: Tue, 30 Jul 2002 00:44:49 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: logic elements v/s logic cells
From: Ray Andraka <ray@andraka.com>
Date: Tue, 30 Jul 2002 01:52:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: secure FPGA
From: Ray Andraka <ray@andraka.com>
Date: Tue, 30 Jul 2002 01:59:22 GMT
Links: << >>  << T >>  << A >>
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: 45629
Subject: Re: logic elements v/s logic cells
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 30 Jul 2002 02:32:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
In 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.edu

Article: 45630
Subject: Who can compare the synthesis tools for me ?
From: Daryl <caoqh@engineer.com.cn>
Date: 30 Jul 2002 10:51:32 +0800
Links: << >>  << T >>  << A >>
Synopsys FPGA Compiler II
Synplicity SynplifyPro
Leonardo


-- 
Daryl

Article: 45631
Subject: Re: secure FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 30 Jul 2002 03:20:37 -0000
Links: << >>  << T >>  << A >>

>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: 45632
Subject: Re: secure FPGA
From: "Gazza" <garethbaron_spammers_get_lost@attbi_z.co.com>
Date: Tue, 30 Jul 2002 05:12:01 GMT
Links: << >>  << T >>  << A >>
Look 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
Subject: Dual Port Block RAM
From: mrmikehicks@earthlink.net
Date: Tue, 30 Jul 2002 05:12:05 GMT
Links: << >>  << T >>  << A >>
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: 45634
Subject: Re: physical attacks (& secure FPGA) - some more questions
From: "Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de>
Date: Tue, 30 Jul 2002 09:11:55 +0200
Links: << >>  << T >>  << A >>
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.)
>
>
>
>
>



Article: 45635
Subject: Re: Bit serial arithmetic Vs Digit serial Arithmetic
From: Thomas Reinemann <thomas.reinemann@masch-bau.uni-magdeburg.de>
Date: Tue, 30 Jul 2002 09:48:45 +0200
Links: << >>  << T >>  << A >>
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
Subject: How to generate correct Express Mode configuration bit stream for Spartan-XL...?
From: "Jesper Kristensen" <Jesper.Kristensen@Tellabs.com>
Date: Tue, 30 Jul 2002 08:39:04 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Dual Port Block RAM
From: "Michael Rhotert" <mrhotert@yahoo.com>
Date: Tue, 30 Jul 2002 13:54:20 +0200
Links: << >>  << T >>  << A >>
<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
Michael



Article: 45638
Subject: VIRTEX-II pro -> LVTTL 3.3
From: Laurent Gauch <laurent.gauch@amontec.com>
Date: Tue, 30 Jul 2002 14:37:28 +0200
Links: << >>  << T >>  << A >>
Hi all,

Are the Virtex-II pro IOs LVTTL 3.3V tolerant or not?

Laurent


Article: 45639
Subject: Re: physical attacks (& secure FPGA) - some more questions
From: Ray Andraka <ray@andraka.com>
Date: Tue, 30 Jul 2002 12:38:15 GMT
Links: << >>  << T >>  << A >>
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: 45640
Subject: Re: secure FPGA
From: "Pete Ormsby" <faepeteDELETETHIS@attbi.com>
Date: Tue, 30 Jul 2002 12:49:45 GMT
Links: << >>  << T >>  << A >>
Even 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
Subject: ntelist problem
From: "Ersin" <eozalp@cesys.com>
Date: Tue, 30 Jul 2002 15:33:40 +0200
Links: << >>  << T >>  << A >>
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,
Ersin





Article: 45642
Subject: Re: Dual Port Block RAM
From: brimdavis@aol.com (Brian Davis)
Date: 30 Jul 2002 06:37:55 -0700
Links: << >>  << T >>  << A >>
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

Brian

Article: 45643
Subject: Looking for a Virtex-II based video board...
From: "mok" <mok_3001@yahoo.com>
Date: Tue, 30 Jul 2002 14:44:46 +0100
Links: << >>  << T >>  << A >>
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
Subject: Maximum FIR coefficient widths on FPGA
From: "Ken Mac" <aeu96186@yahoo.co.uk>
Date: Tue, 30 Jul 2002 14:53:16 +0100
Links: << >>  << T >>  << A >>

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,

Ken



Article: 45645
(removed)


Article: 45646
Subject: Re: secure FPGA
From: "Timothy R. Sloper" <trs74@bellsouth.net>
Date: Tue, 30 Jul 2002 11:09:13 -0400
Links: << >>  << T >>  << A >>
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
Subject: VirtexE : OrCAD capture part symbol
From: Jerry <jerryl@adaptivenetworks.com>
Date: Tue, 30 Jul 2002 08:51:54 -0700
Links: << >>  << T >>  << A >>
Does anyone know where I can find an ORCAD capture library symbol for a PQ240 VirtexE part?

Article: 45648
Subject: Re: Who can compare the synthesis tools for me ?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 30 Jul 2002 09:38:57 -0700
Links: << >>  << T >>  << A >>
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 Treseler



Article: 45649
Subject: Impedance Measureing
From: Daniel <Daniel.Westerheim@Lynntech.com>
Date: Tue, 30 Jul 2002 09:49:04 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search