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 45600

Article: 45600
Subject: timing got worse?
From: William Lenihan <lenihan3we@earthlink.net>
Date: Mon, 29 Jul 2002 08:46:25 GMT
Links: << >>  << T >>  << A >>

Has anyone else come across this experience?

Run a design (Virtex/Virtex-E, xcv600E in my case) thru Alliance (or
Foundation, presumably same P&R engine) version 3.1i, then after
upgrading to version 4.1i, the design's timing gets significantly worse
even though it's operating on the same EDIF netlist & same UCF file &
same "effort" level (max) set in the Design Manager's " Design -->
Options... " menu.

Is there some trick or switch to make 4.1i get at least as good,
preferably better, timing than 3.1i?

--
==============================
William Lenihan
lenihan3we@earthlink.net
==============================



Article: 45601
Subject: Wishbone <-> CoreConnect
From: "Mitchell Crago" <mcrago@flow.com.au>
Date: Mon, 29 Jul 2002 18:57:36 +1000
Links: << >>  << T >>  << A >>
Gudday All,

Has anyone had an attempt at interfacing a WishBone IP core to a CoreConnect
bus. My target platform is a VirtexII-Pro. Has anyone developed some sort of
bridge code, or if not, have any suggestion of which direction may provide
fruitful results.

FYI this work is part of a final year project - any help is greatly
appreciated, and will be attributed in my final report.

Cheers,

Mitchell.
__________________________________________________________________



Article: 45602
Subject: VHDL configurations with Xilinx ISE 4.1i
From: David R Brooks <daveb@iinet.net.au>
Date: Mon, 29 Jul 2002 17:04:07 +0800
Links: << >>  << T >>  << A >>
I am building a VHDL design, using Xilinx ISE 4.1i
The design uses alternative architectures for some entities, with a
top-level configuration file to bind everything.

The project compiles & simulates with ModelSim, however ISE doesn't
want to handle the configuration. Having successfully compiled all the
lower units, it then reports:

  Compiling vhdl file top_cfg.vhd in Library work.
  ERROR:HDLParsers:340 - top_cfg.vhd Entity <top_config> does not 
  exist in library <work>.

Naturally, top_config doesn't exist: it is what I am compiling!!
Here's the first few lines of the config. file:

library work;
configuration top_config of top is
    for struct
        for all : rstgenr
            use entity work.rstgenr(rtl);
        end for;
        ...

Can anyone say how one should compile configurations in ISE?
TIA


Article: 45603
Subject: Re: timing got worse?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Mon, 29 Jul 2002 09:18:39 GMT
Links: << >>  << T >>  << A >>
On Mon, 29 Jul 2002 08:46:25 GMT, William Lenihan
<lenihan3we@earthlink.net> wrote:

>
>Has anyone else come across this experience?
>
>Run a design (Virtex/Virtex-E, xcv600E in my case) thru Alliance (or
>Foundation, presumably same P&R engine) version 3.1i, then after
>upgrading to version 4.1i, the design's timing gets significantly worse
>even though it's operating on the same EDIF netlist & same UCF file &
>same "effort" level (max) set in the Design Manager's " Design -->
>Options... " menu.
>
>Is there some trick or switch to make 4.1i get at least as good,
>preferably better, timing than 3.1i?

Yes, upgrade to 4.2i.

Regards,
Allan.

Article: 45604
Subject: Re: Programming FLASH with Xilinx Parallel Cable III
From: "Daryl" <caoqh@engineer.com.cn>
Date: Mon, 29 Jul 2002 18:39:44 +0800
Links: << >>  << T >>  << A >>
There is many method to program FLASH.
A universal programer always can do it.
For debug, you can download via serial port of computer.

Best Regards, Cao QingHua PhotonicBridges Inc.
"ndesi" <ndesi@talk21.com> wrote in message
news:cf531019.0207271342.22447b3f@posting.google.com...
> Hello :)
>
> I want to configure my Virtex II parts with FLASH (Atmel or Intel).
> I found app note how to do that
> But question is How to Programm FLASH??
>
> I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel
> cable III" output to program FLASH
>
> Is it possible??
> Any other Idea??
>
> I want to use Xilinx software and their cable but i can add  only CPLD
> to my board.
>
> Thanks In Advance



Article: 45605
Subject: Re: secure FPGA
From: Daryl <caoqh@engineer.com.cn>
Date: 29 Jul 2002 20:20:14 +0800
Links: << >>  << T >>  << A >>


Actel's antifuse FPGA

Article: 45606
Subject: Complex FIR low pass filters
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Mon, 29 Jul 2002 14:25:02 +0200
Links: << >>  << T >>  << A >>
Hi everyone,

Although this is not strictly an FPGA question, I thought that someone here
should be able to answer it quite easily. Does anyone know of any references
on the use of complex FIR low pass filters. It doesn't have to be very
informative, as I have already designed some, however I would like to see
what other people do.

Thanks

Adrian




Article: 45607
Subject: Re: Complex FIR low pass filters
From: Ray Andraka <ray@andraka.com>
Date: Mon, 29 Jul 2002 13:05:13 GMT
Links: << >>  << T >>  << A >>
There is a description of a DA archtecture I've used for complex FIR filters
(complex data, complex coefficient)  in my paper "FPGA makes radar on a chip a
reality", which is available at no charge from my website.

Noddy wrote:

> Hi everyone,
>
> Although this is not strictly an FPGA question, I thought that someone here
> should be able to answer it quite easily. Does anyone know of any references
> on the use of complex FIR low pass filters. It doesn't have to be very
> informative, as I have already designed some, however I would like to see
> what other people do.
>
> Thanks
>
> Adrian

--
--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: 45608
Subject: Re: Bit serial arithmetic Vs Digit serial Arithmetic
From: Ray Andraka <ray@andraka.com>
Date: Mon, 29 Jul 2002 13:11:14 GMT
Links: << >>  << T >>  << A >>
You are only partially correct.  The input words need to be sign extended
rather than zero extended unless the input data is unsinged data (usually
not the case except in video).  The wordlength only has to be extended if
the architecture  of your fiter requires it.  Scaling accumulator
multipliers, for example have a serial input and a parallel output, so the
serial input does not have to be extended at all.  A serial distributed
arithmetic filter uses scaling accumulators to do the multiply, so you avoid
the need for input extension because the partial sums are accumulated as
parallel arithmetic.  Only the partial sums are computed serially.  See the
distributed arithmetic and multiplier pages on my website for a more
complete  explanation.

hristo wrote:

> 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
>
> what about digit serial, should we still need to expand the input data
> with zero digits
>
> Many thanks

--
--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: 45609
Subject: Re: ALU in VHDL and a bunch of questions
From: Ray Andraka <ray@andraka.com>
Date: Mon, 29 Jul 2002 13:20:06 GMT
Links: << >>  << T >>  << A >>
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



Article: 45610
Subject: Re: secure FPGA
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Mon, 29 Jul 2002 13:38:19 GMT
Links: << >>  << T >>  << A >>

"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

How about putting an SRAM based FPGA on a special battery circuit such that
it stays configured when power is off.  That way when someone tries to break
into it, it loses configuration and all info is gone.  You can make it such
that when the product cover is removed, power is removed from the FPGA. Any
SRAM FPGA will suffice, but Xilinx comes to mind!

Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 45611
Subject: Re: Programming FLASH with Xilinx Parallel Cable III
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Mon, 29 Jul 2002 15:48:58 +0200
Links: << >>  << T >>  << A >>
Xilinx has Flash memories, that can be used in the JTAG chain
and can be programmed with the Parallel cable.
XC18V04  for example.

If you prefer to use other flash memories and want to programm
them in-system,  you will have to use the download cable of
the flash manufacturer. You will also need glue logic to configure
a Virtex-II out of a standard flash.

-Manfred

"ndesi" <ndesi@talk21.com> schrieb im Newsbeitrag
news:cf531019.0207271342.22447b3f@posting.google.com...
> Hello :)
>
> I want to configure my Virtex II parts with FLASH (Atmel or Intel).
> I found app note how to do that
> But question is How to Programm FLASH??
>
> I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel
> cable III" output to program FLASH
>
> Is it possible??
> Any other Idea??
>
> I want to use Xilinx software and their cable but i can add  only CPLD
> to my board.
>
> Thanks In Advance



Article: 45612
Subject: Re: secure FPGA
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Mon, 29 Jul 2002 15:51:38 +0200
Links: << >>  << T >>  << A >>
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: 45613
Subject: Re: Programming FLASH with Xilinx Parallel Cable III
From: "Steve Casselman" <sc@vcc.com>
Date: Mon, 29 Jul 2002 15:30:33 GMT
Links: << >>  << T >>  << A >>
If the flash has jtag you can use the Xilinx cable III. The Xilinx tools
won't do it for you but you can write your own tools from scratch. You can
also download our HOTMan app builder software, which contains functions to
help program jtag, and with a little programming you'll be able to program
your device over the network if you want.

Steve
www.vcc.com


"ndesi" <ndesi@talk21.com> wrote in message
news:cf531019.0207271342.22447b3f@posting.google.com...
> Hello :)
>
> I want to configure my Virtex II parts with FLASH (Atmel or Intel).
> I found app note how to do that
> But question is How to Programm FLASH??
>
> I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel
> cable III" output to program FLASH
>
> Is it possible??
> Any other Idea??
>
> I want to use Xilinx software and their cable but i can add  only CPLD
> to my board.
>
> Thanks In Advance



Article: 45614
Subject: Re: secure FPGA
From: "Timothy R. Sloper" <trs74@bellsouth.net>
Date: Mon, 29 Jul 2002 12:08:04 -0400
Links: << >>  << T >>  << A >>
Simon,

That's a bit of overkill isn't? Ranks right up there with Xilinx's rad-hard
solution. :) If you want the cheapest, most secure programmable solution
antifuse (Actel) is the way to go. No need for backup batteries, or any
other "special" components.

You, Cesar, and I should get together for some drinks one nite...

Tim Sloper
Field Applications Engineer (Actel)



"S. Ramirez" <sramirez@cfl.rr.com> wrote in message
news:fzb19.25216$s8.673318@twister.tampabay.rr.com...
>
> "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
>
> How about putting an SRAM based FPGA on a special battery circuit such
that
> it stays configured when power is off.  That way when someone tries to
break
> into it, it loses configuration and all info is gone.  You can make it
such
> that when the product cover is removed, power is removed from the FPGA.
Any
> SRAM FPGA will suffice, but Xilinx comes to mind!
>
> Simon Ramirez, Consultant
> Synchronous Design, Inc.
> Oviedo, FL  USA
>
>




Article: 45615
Subject: xilinx ISE 4.2, xst, cpld 95144xl, tristate
From: emanuel stiebler <emu@ecubics.com>
Date: Mon, 29 Jul 2002 10:21:20 -0600
Links: << >>  << T >>  << A >>
Hi all,

I have this very small vhdl segment, I try to put in a 95144xl cpld.
Using ISE4.2, XST.

The problem I "suspect" is, that the "d" bus doesn't go tristate,
even when "rstout" is not active. What am I missing ?

thanks,
emanuel

P.S. "suspect" means, that some chip on the bus is blocking the bus.
And there are only three chips on it.

----------cut ------------------

library IEEE;
use IEEE.std_logic_1164.all;

entity cpld is
	port (
	rstout:  in STD_LOGIC;			    -- enable signal	
        d:	 out STD_LOGIC_VECTOR(15 downto 0); -- databus  
);
end cpld;

architecture cpld_arch of cpld is

begin
	d <= B"1110_1100_1110_0111" when rstout = '0' else "ZZZZZZZZZZZZZZZZ";
end cpld_arch;

Article: 45616
Subject: Re: secure FPGA
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 29 Jul 2002 16:29:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>,
Timothy R. Sloper <trs74@bellsouth.net> wrote:
>Simon,
>
>That's a bit of overkill isn't? Ranks right up there with Xilinx's rad-hard
>solution. :) If you want the cheapest, most secure programmable solution
>antifuse (Actel) is the way to go. No need for backup batteries, or any
>other "special" components.

Actually, it may seem overkill, but it is of a greater level of
security, since antifuses are easier to reverse engineer and extract
the information than SRAM cells.

Then again, it costs more.  So much of security consists of
determining what level of attack you are willing to stop, and stoping
everyting up to that point, without going beyond it.

So, to the origional poster, what are the ACTUAL security concerns
desired?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 45617
Subject: Re: secure FPGA
From: "Timothy R. Sloper" <trs74@bellsouth.net>
Date: Mon, 29 Jul 2002 13:36:48 -0400
Links: << >>  << T >>  << A >>
Nicholas,

1) There is absolutely no bit stream to intercept in an anitfuse scenario.
2) With the security bit set there is aboslutely no visibility into an
anti-fuse part (this is permanent)
3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact
it's more difficult to reverse engineer an antifuse FPGA than most ASICs as
the shorts between the metal lines are not visible from the top. To physical
view the shorts you need to cross-section the device not look at it from the
top.
4) It would be a painstaking process to determine the state of one switch
element let alone the potentially millions of elements that are found in the
larger devices to reproduce the entire design.

Here is a link to an app note on security of anti-fuse and Flash devices
http://www.actel.com/appnotes/DesignSecurity.pdf if anyone would like more
detail.

Tim


"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:ai3qgd$1jd6$1@agate.berkeley.edu...
> In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>,
> Timothy R. Sloper <trs74@bellsouth.net> wrote:
> >Simon,
> >
> >That's a bit of overkill isn't? Ranks right up there with Xilinx's
rad-hard
> >solution. :) If you want the cheapest, most secure programmable solution
> >antifuse (Actel) is the way to go. No need for backup batteries, or any
> >other "special" components.
>
> Actually, it may seem overkill, but it is of a greater level of
> security, since antifuses are easier to reverse engineer and extract
> the information than SRAM cells.
>
> Then again, it costs more.  So much of security consists of
> determining what level of attack you are willing to stop, and stoping
> everyting up to that point, without going beyond it.
>
> So, to the origional poster, what are the ACTUAL security concerns
> desired?
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu




Article: 45618
Subject: Re: VHDL configurations with Xilinx ISE 4.1i
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 29 Jul 2002 11:16:55 -0700
Links: << >>  << T >>  << A >>


David R Brooks wrote:


> library work;
> configuration top_config of top is
>     for struct
>         for all : rstgenr
>             use entity work.rstgenr(rtl);
>         end for;
>         ...
> 
> Can anyone say how one should compile configurations in ISE?

I don't know about ISE, but leonardo can handle a top configuration

only if it is at the end of the last item in the file list
AND if the preceding file list is complete and in correct
compilation order.

    -- Mike Treseler



Article: 45619
Subject: Re: secure FPGA
From: Ray Andraka <ray@andraka.com>
Date: Mon, 29 Jul 2002 18:39:37 GMT
Links: << >>  << T >>  << A >>
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.





"Timothy R. Sloper" wrote:

> Nicholas,
>
> 1) There is absolutely no bit stream to intercept in an anitfuse scenario.
> 2) With the security bit set there is aboslutely no visibility into an
> anti-fuse part (this is permanent)
> 3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact
> it's more difficult to reverse engineer an antifuse FPGA than most ASICs as
> the shorts between the metal lines are not visible from the top. To physical
> view the shorts you need to cross-section the device not look at it from the
> top.
> 4) It would be a painstaking process to determine the state of one switch
> element let alone the potentially millions of elements that are found in the
> larger devices to reproduce the entire design.
>
> Here is a link to an app note on security of anti-fuse and Flash devices
> http://www.actel.com/appnotes/DesignSecurity.pdf if anyone would like more
> detail.
>
> Tim
>
> "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
> news:ai3qgd$1jd6$1@agate.berkeley.edu...
> > In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>,
> > Timothy R. Sloper <trs74@bellsouth.net> wrote:
> > >Simon,
> > >
> > >That's a bit of overkill isn't? Ranks right up there with Xilinx's
> rad-hard
> > >solution. :) If you want the cheapest, most secure programmable solution
> > >antifuse (Actel) is the way to go. No need for backup batteries, or any
> > >other "special" components.
> >
> > Actually, it may seem overkill, but it is of a greater level of
> > security, since antifuses are easier to reverse engineer and extract
> > the information than SRAM cells.
> >
> > Then again, it costs more.  So much of security consists of
> > determining what level of attack you are willing to stop, and stoping
> > everyting up to that point, without going beyond it.
> >
> > So, to the origional poster, what are the ACTUAL security concerns
> > desired?
> > --
> > Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

--
--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: 45620
Subject: Re: secure FPGA
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 29 Jul 2002 18:57:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
It is a high barrier to reverse engineering, but arguably less than
the battery configuration power supply or Virtex encrypted bitfile
loader style.  It's how much security at how much flexibility and cost
that always needs to be kept in mind.

In article <r%e19.43877$ND5.4403512@e3500-atl2.usenetserver.com>,
Timothy R. Sloper <trs74@bellsouth.net> wrote:
>1) There is absolutely no bit stream to intercept in an anitfuse scenario.

There is absolutely no bitstream to intercept in the SRAM battery
backup scenario.  There is only a 3DES encrypted bitstream to
intercept in the Virtex 2 encrypted bitfile setup.  You want to brute
force 3DES, be my guest.  

Considering the low power drain on the dedicated pins and the lifespan
of Li batteries, the Virtex 2 style is fairly easy to use for most
purposes.

>2) With the security bit set there is aboslutely no visibility into an
>anti-fuse part (this is permanent)

A good probe technique should be able to create a break on the
security bits, probably more reliabily than a glitch attack on the
SRAM based security bits.  

That would be how I'd attack an antifuse setup: Reverse engineer the
part until I can determine the location of the readback lock bits,
then changed them by very fine drilling, probing, and filling.
Basically drill down to where I need to break [1], backfill with
insulator and conductor to restore any layers/vias broken on the way
in, and then use the readback mechanisms.

It is a damn challange (you go through a lot of basic parts), but
still probably easier than attacking the SRAM based key approach (hit
with hard radiation, probe for the bit states, use that as the seed
number for a 3DES search, searching all keys which are a given hamming
distance from my initial guess determined by probing).

>3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact
>it's more difficult to reverse engineer an antifuse FPGA than most ASICs as
>the shorts between the metal lines are not visible from the top. To physical
>view the shorts you need to cross-section the device not look at it from the
>top.

Reverse engineering the state of battery backed SRAM is even harder,
because of the probabilistic nature when you try to freeze the bits
into a configuration and then probe them and probabilistically
reconstruct the state, or live probing on the powered part.

>"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
>news:ai3qgd$1jd6$1@agate.berkeley.edu...

>> Actually, it may seem overkill, but it is of a greater level of
>> security, since antifuses are easier to reverse engineer and extract
>> the information than SRAM cells.
>>
>> Then again, it costs more.  So much of security consists of
>> determining what level of attack you are willing to stop, and stoping
>> everyting up to that point, without going beyond it.


[1] Since the antifuse operation is a closing operation, any break
would be an opening.  Since I can work on the part unpowered, it
should be possible to drill through conducting layers and then
reconstruct the layers after performing the breaks.  Admittedly a very
high barrier, but doable.  This also works for EEPROM/flash, as it can
create a short as well as a break.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 45621
Subject: Re: Bit serial arithmetic Vs Digit serial Arithmetic
From: hristostev@yahoo.com (hristo)
Date: 29 Jul 2002 13:06:27 -0700
Links: << >>  << T >>  << A >>
Yes, Ray i agree with you, the input data should be sign extended.[ i
have wriiten my query in hurry ;-)]
staying in the same scheme serial digit input, serial digit output 
should sign extend the input data when using digit serial arithmetic

Ray Andraka <ray@andraka.com> wrote in message news:<3D453FB4.6C6CF807@andraka.com>...
> You are only partially correct.  The input words need to be sign extended
> rather than zero extended unless the input data is unsinged data (usually
> not the case except in video).  The wordlength only has to be extended if
> the architecture  of your fiter requires it.  Scaling accumulator
> multipliers, for example have a serial input and a parallel output, so the
> serial input does not have to be extended at all.  A serial distributed
> arithmetic filter uses scaling accumulators to do the multiply, so you avoid
> the need for input extension because the partial sums are accumulated as
> parallel arithmetic.  Only the partial sums are computed serially.  See the
> distributed arithmetic and multiplier pages on my website for a more
> complete  explanation.
> 
> hristo wrote:
> 
> > 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
> >
> > what about digit serial, should we still need to expand the input data
> > with zero digits
> >
> > Many thanks
> 
> --
> --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: 45622
Subject: Re: ALU in VHDL and a bunch of questions
From: "MikeJ" <mikejNO SPAM@freeuk.com>
Date: Mon, 29 Jul 2002 22:28:49 +0100
Links: << >>  << T >>  << A >>
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
>
>



Article: 45623
Subject: Re: logic elements v/s logic cells
From: "MikeJ" <mikejNO SPAM@freeuk.com>
Date: Mon, 29 Jul 2002 22:39:41 +0100
Links: << >>  << T >>  << A >>
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?
>



Article: 45624
Subject: Re: xilinx ISE 4.2, xst, cpld 95144xl, tristate
From: "M. Randelzhofer" <mrandelzhofer@uumail.de>
Date: Mon, 29 Jul 2002 23:55:21 +0200
Links: << >>  << T >>  << A >>
If the buskeepers are enabled (default), the last state is held in tristate.

MIKE


"emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag
news:3D456B80.A4455AC9@ecubics.com...
> Hi all,
>
> I have this very small vhdl segment, I try to put in a 95144xl cpld.
> Using ISE4.2, XST.
>
> The problem I "suspect" is, that the "d" bus doesn't go tristate,
> even when "rstout" is not active. What am I missing ?
>
> thanks,
> emanuel
>
> P.S. "suspect" means, that some chip on the bus is blocking the bus.
> And there are only three chips on it.
>
> ----------cut ------------------
>
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> entity cpld is
> port (
> rstout:  in STD_LOGIC;     -- enable signal
>         d: out STD_LOGIC_VECTOR(15 downto 0); -- databus
> );
> end cpld;
>
> architecture cpld_arch of cpld is
>
> begin
> d <= B"1110_1100_1110_0111" when rstout = '0' else "ZZZZZZZZZZZZZZZZ";
> end cpld_arch;





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