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 53825

Article: 53825
Subject: Re: Does Xilinx have self-boot option like Cypress?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 25 Mar 2003 07:34:54 +1000
Links: << >>  << T >>  << A >>
Steve Casselman wrote:
> I was just wondering how secure 3DES is if you know the bits it is trying to
> encode? The first 64-bits in a bitstream are pretty much the same.

That's an excellent point.  The weakness in any encryption stream is 
usually how it is employed, rather than the mechanics of the algorithm.

A way around this would be to send the common bitstream header as 
plaintext, then start the encryption after that.  Of course, there are 
other structural regularities in an FPGA bitstream that a sufficiently 
skilled and determined snooper might exploit.

Maybe Xilinx can hold a competition to see (a) who can crack their 
bitstream format, and (b) who can break their encryption.  The winner 
gets a job at Xilinx to close the holes they discover :)

John


Article: 53826
Subject: Re: FPGA FFT Questions
From: tom1@launchbird.com (Tom Hawkins)
Date: 24 Mar 2003 13:46:50 -0800
Links: << >>  << T >>  << A >>
already5chosen@yahoo.com (Michael S) wrote in message 
> [O.T.]
> I was always interested in the analysis of the relative impact of the
> rounding error in the floating-point and the fixed-pointed
> implementations of the (Radix-2) FFT. However I was too lazy to look
> for an answer in the literature or to do the analysis myself (also,
> likely,  I am not properly equipped for the later).
> My intuition says that at comparable precision both approaches are
> about equal for SNR, but floating-point is significantly better for
> SFDR . Then again, using intuition is not a good approach to rely on.
> Would you be so kind to give me a pointer to the analysis I am looking
> for ?

"Computational Frameworks for the Fast Fourier Transform", by
Charles Van Loan, is one you might look into.  I can't remember
how detailed it gets into rounding error.

While building the FFT at Dillon Engineering (www.dilloneng.com),
we investigated rounding affect of fixed-point operations just by
experimented with various configurations using known data sets.
Though we considered a radix 4 architecture, in the end we decided
on radix 2 for the increased flexibility.

In the first version, our butterfly adders [and subtractors]
simply truncated any overflow and when our client began running
data sets on the design, they immediately complained about the amount of
distortion produced.  We guessed it might be attributed to overflows,
so we dropped in a limiting adder and were surprised by how much
this cleaned up the output.

We then began experimenting with shifting the results from
various FFT ranks to preserve the most significant bits
assuming an overflow is probable.  The interesting phenomenon
we observed was picking the appropriate ranks to sign-extend and shift
was highly depended on the frequency content of a given data set.
Some data sets were prone to overflow in early ranks, while others
only overflowed in the middle or later ranks.

Towards the end of the program we looked at alternative
FFT approaches to minimize rounding affects and logic area
including polar representation.

The most expensive piece of logic in a butterfly is the twiddle
factor multiplication, which performs a complex vector rotation.
Fixed-point polar representation is attractive in this regard because
the rotation can be performed with just an adder; an adder overflow
actually captures the exact behavior of the vector rotation.
Because twiddle factors are always a radix of 2PI, this operation
is exact.

Though this simplifies the multiplication of the butterfly,
it makes the addition/subtract operation painful, requiring
logic (cordics/tables) to convert to, and from, cartesian form.

This led us to believe there is a fundamental trade-off
begin vector representations (cartesian, polar) and vector
operations (addition, multiplication), i.e., cartesian is
cheap with addition but expensive with multiplication;
polar is cheap with multiplication but expensive with addition.

Then we started thinking, "Is there a hybrid coordinate system
somewhere in between cartesian and polar?"  If it exists then
maybe vector addition and multiplication cost about the same.
Not that it would really save you anything in the end. :-)

-Tom

--
Tom Hawkins                             tom1@launchbird.com
Launchbird Design Systems, Inc.         http://www.launchbird.com/

Article: 53827
Subject: Re: Does Xilinx have self-boot option like Cypress?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 24 Mar 2003 21:49:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b5ntlv$akc$1@bunyip.cc.uq.edu.au>,
John Williams  <jwilliams@itee.uq.edu.au> wrote:
>Steve Casselman wrote:
>> I was just wondering how secure 3DES is if you know the bits it is trying to
>> encode? The first 64-bits in a bitstream are pretty much the same.
>
>That's an excellent point.  The weakness in any encryption stream is 
>usually how it is employed, rather than the mechanics of the algorithm.

Even with a known plaintext (easy enough to get), it is effecitvely
impossible to brute force 3DES with our current understanding of the
cypher, you HAVE to do something more clever.

Suggested alternatives:

a: Hit the chip with hard X-rays, delid it, and microprobe the SRAM
cells.  Hopefully most will be frozen into place when power is
reapplied to them, use that as a seed for the brute force search,
which will now be easy: Start at the seed (measured) point and search
outward in increasing hamming distance.

b: Delid the chip and probe while still running, then do above.
Probably harder.

c:  See if the path rejects the configurations at different points for
bogus data, based on keys.  You MAY be able to use this to find
information about one of the 3 3DES keys much faster than brute
force.  I don't know about this one, how well/if it would work.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 53828
Subject: triple des
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 24 Mar 2003 15:13:48 -0800
Links: << >>  << T >>  << A >>
Always fun to listen to the chatter,

All of this was considered when we implemented 3des.

No one has broken it yet, so go ahead and have fun!

Austin


Article: 53829
Subject: Re: triple des
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 24 Mar 2003 23:58:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3E7F912C.1D8B1567@xilinx.com>,
Austin Lesea  <Austin.Lesea@xilinx.com> wrote:
>Always fun to listen to the chatter,
>
>All of this was considered when we implemented 3des.
>
>No one has broken it yet, so go ahead and have fun!

And probably nobody has used it in a system where there is a >$100k
payout if you can break this particular form of security, which is my
Wild Ass Guess as to how much it would probably cost to reverse
engineer this mechanism for the first time: you have to find the
location of the cells and their relationship to the key bits, freeze
their state (not necessary, but helps alot), and probe them
(mostly) sucessfully.  You can tolerate some errors, but you want ~80%
accuracy on your readout or better.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 53830
Subject: Re: triple des
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 25 Mar 2003 10:06:12 +1000
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Always fun to listen to the chatter,
> 
> All of this was considered when we implemented 3des.
> 
> No one has broken it yet, so go ahead and have fun!

What, and go beyond sitting around chin-wagging?  That's crazy talk!

  :)


Article: 53831
Subject: where is SMC34c60 similar IP ?
From: "¼Õ±â¿µ" <elcielo0@hitel.net>
Date: Tue, 25 Mar 2003 10:26:58 +0900
Links: << >>  << T >>  << A >>
I want.
SMC34c60 - www.smsc.com



Article: 53832
Subject: Re: Latch inferring : Async OR Sync ?
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Tue, 25 Mar 2003 00:00:18 -0500
Links: << >>  << T >>  << A >>
Usually, if you must use latches latches, it's because of some important
performance requirements, meaning you can't be using synthesys anyway.  -S

"Symon" <symon_brewer@hotmail.com> wrote in message
news:a28bc07f.0301060355.7148acb3@posting.google.com...
> Hi Prashant,
>         In your 'Code A' you should include 'C' in the sensitivity
> list of the process statement. Otherwise, 'B' will only be updated on
> rising edges of 'A', I believe.
>         I've found that this sort of code often gives different
> results between synyhesis and simulation, so be careful!
>                  cheers, Symsx.
>
> prashantj@usa.net (Prashant) wrote in message
news:<ea62e09.0301021035.77494be8@posting.google.com>...
> > Hi all,
> >
> > I read an article recently which mentioned that an inference of a
> > latch due to an incomplete IF statement is an asynchronous piece of
> > code. I agree with that. But if I had this piece of code within a
> > process which triggers @ the rising edge of a clk, would it still be
> > considered async ? I would think not.
> >
> > for e.g.
> > ----------------------------------------------------
> > Code A
> >
> > process(A)
> > begin
> >  if (A = 1) then
> >    B <= C;
> >  end if;
> > end process;
> > ----------------------------------------------------
> >
> > ----------------------------------------------------
> > Code B
> >
> > process(clk)
> > begin
> >  if clk'EVENT and clk = '1' then
> >   if (A = 1) then
> >     B <= C;
> >   end if;
> >  end if;
> > end process;
> > ----------------------------------------------------
> >
> > I would assume Code B to be synchronous, while code A is async. Am I
> > correct ?
> >
> > Thanks,
> > Prashant



Article: 53833
Subject: Synopsys FPGA Compiler 2 (Altera Edition) question
From: benn686@hotmail.com (Ben Nguyen)
Date: 24 Mar 2003 21:23:28 -0800
Links: << >>  << T >>  << A >>
Using FPGA compiler 2 (version 3.5), Ive selected a chip (Altera Flex 
10k70rc240), optimized it, exported a netlist but the place and 
route button is grayed out!  Why? I need an .sof file!

So instead, I put the synopsys generated ".acf" and ".lmf" file into 
the MaxPlusII project folder and tried to compile with MaxPlusII.
Unfortunately, it says "Project requires too many (3867/3744) logic cells.

The Synopsys project options are set: Optimize for Area, Effort: High.

Any thoughts?

Also, can the FPGA compiler compile mixed language code (verilog/vhdl)
or will this cause problems when imported back into MaxPlus?

Thanks In Advance,
Ben

Article: 53834
Subject: Re: CLKDLL synthesized with synplify pro
From: tote_last@yahoo.de (tote)
Date: 25 Mar 2003 00:02:47 -0800
Links: << >>  << T >>  << A >>
Ok, thanks. This helps to understand how to use this DLL. This is
exactly what i need. The second clock buffer to use both clocks (CLKB
and CLK2XB) in my design. And this is all working fine in simulation.

I want to use this on a VirtexE architecture. My problem is, that i
don't know how to synthesize such XILINX cells like CLKDLL with the
SYNPLIFY PRO synthesizer.
In the documentations i just found things like:

input Clk_in /* synthesis xc_clockbuftype = "IBUFG" */;

ok, that's s.th. i can use for the two buffers IBUFG and BUFG. I also
found s. th. similar with the BUFGDLL (IBUFG->CLKDLL->BUFG). However,
that's always working with one input signal name, used as the output
name again. I don't understand how to connect more signals between
such XILINX cells with this method using SYNPLIFY.
SYNPLIFY seems not able to just synthesize these things. Or do i have
to add additional XILINX libraries? Anyway, i also can't find any
option for this.

I do appriciate your help. 

Thorsten



"Avrum" <avrum@sympatico.ca> wrote in message news:<7mJfa.673$lf3.36793@news20.bellglobal.com>...
> Pretty much exactly like that.
> 
> However, from your naming convention, you may be confusing which signal to
> use as the main clock to clock logic. The clock that should be fed to the
> flip-flops is the output of the BUFG, in this case, named CLKB, not the
> signal named Clk - this is a local, dedicated connection from the DLL to the
> BUFG. The BUFG component is the main "clock buffer" - conceptually, it
> drives the load of the clock distribution network.
> 
> In addition, you need a second BUFG to drive the flops being driven on the
> CLK2x domain. You would need to add
> 
> BUFG U4 (.I(CLK2x), .O(CLK2XB));
> 
> Again, remember, CLK2XB is the clock that should be used to drive flops on
> the 2X domain (not CLK2x).
> 
> Also, (I don't have the specs in hand, and you don't say which architecture
> you are using), there may be a requirement as to which clock needs to be
> used for the CLKFB of the DLL when you are using both CLK and CLK2X - you
> may need to use the output of the CLK2X BUFG (which I called CLK2XB).
> 
> Avrum
> 
> "tote" <tote_last@yahoo.de> wrote in message
> news:91e0be86.0303240810.46e23d89@posting.google.com...
> > Hi,
> >
> > in my design i'm using 2 clock signals, CLK and CLK2x. I'm generating
> > these 2 clocks from a "input-clock" with a DLL like:
> >
> > IBUFG U1 (.I(Clk_in), .O(CLKIN));
> > CLKDLL U2 (.CLKIN(CLKIN), .CLKFB(CLKB), .RST(~nReset1),
> > .CLK0(Clk), .CLK90(), .CLK180(), .CLK270(),
> >         .CLK2X(CLK2x), .CLKDV(), .LOCKED(LOCKED));
> > BUFG U3 (.I(Clk), .O(CLKB));
> >
> > That's basically how it's described in the xilinx application notes.
> > Working fine for simulation.
> > However, does anybody know, how to write this to synthesize it with
> > synplify pro?
> >
> > Thanx for your help
> > Thorsten

Article: 53835
Subject: Re: Quartus-II, how to use a user package
From: "Ryan" <ryans@cat.co.za>
Date: Tue, 25 Mar 2003 10:42:35 +0200
Links: << >>  << T >>  << A >>
I had a similar problem a while ago.

What I subsequently found out is that Quartus does support packages, but the
package has to be in the .vhd file with the rest of your code. Currently it
does not have the capability to find packages external to a specific source
file!!!!

Ryan

"Sean" <creon100@yahoo.com> wrote in message
news:b97bab2f.0303240642.3016b717@posting.google.com...
> In my current design I have a small VHDL file that is a package
> containing some math functions.  However, I can't figure out how to
> use this in Quartus-II because it doesn't find the library.  I've
> tried copying the package file into a folder with a library name in
> the main quartus library directory, but that doesn't work.  I then
> tried specifying that folder in the user libraries settings, but it
> still didn't find it.  At this point I can't synthesize anything since
> it can't find this package, does anyone have any suggestions?  Thanks.



Article: 53836
Subject: Re: FPGA FFT Questions
From: already5chosen@yahoo.com (Michael S)
Date: 25 Mar 2003 01:56:43 -0800
Links: << >>  << T >>  << A >>
> 
> While building the FFT at Dillon Engineering (www.dilloneng.com),
> we investigated rounding affect of fixed-point operations just by
> experimented with various configurations using known data sets.
> Though we considered a radix 4 architecture, in the end we decided
> on radix 2 for the increased flexibility.
> 
> In the first version, our butterfly adders [and subtractors]
> simply truncated any overflow and when our client began running
> data sets on the design, they immediately complained about the amount of
> distortion produced.  We guessed it might be attributed to overflows,
> so we dropped in a limiting adder and were surprised by how much
> this cleaned up the output.
> 
> -Tom

I am much more conservative than you, Tom, in my arithmetical beliefs.
I wouldn't even consider the FFT implementation witch can overflow or
saturate in the middle.

Article: 53837
Subject: xst removes useful signals
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Tue, 25 Mar 2003 11:18:25 +0100
Links: << >>  << T >>  << A >>
Look at this VHDL code snippet:

entity txmem is
    Port ( CLKIN : in std_logic;
           DATAIN : in std_logic;
           ENABLE : in std_logic;
           CLK : in std_logic;
           SOUT : inout std_logic);
end txmem;

[...]
architecture Behavioral of txmem is
    type mem is array (15 downto 0) of std_logic_vector(7 downto 0);
begin
    pippo: process( CLKIN, CLK, ENABLE)
    [...]
        variable memoria: mem;
        variable index_write_word: integer := 0;
        variable index_write_bit: integer := 0;
    begin
        if ENABLE='1' then
            if CLKIN'event and CLKIN='1' then
              case index_write_bit is
                when 7 =>
                  memoria(index_write_word)(index_write_bit) := DATAIN;
                  index_write_bit := 0;
                  index_write_word := index_write_word+1;
                when others =>
                  memoria(index_write_word)(index_write_bit) := DATAIN;
                  index_write_bit := index_write_bit+1;
              end case;
            end if;
        else
   [...]


When I sintesize it, XST removes all of the array elements:

 memoria<15><7> and memoria<15><6> are equivalent: (memoria<15><6>) is
removed.
 memoria<15><7> and memoria<15><5> are equivalent: (memoria<15><5>) is
removed.
 memoria<15><7> and memoria<15><4> are equivalent: (memoria<15><4>) is
removed.
 memoria<15><7> and memoria<15><3> are equivalent: (memoria<15><3>) is
removed.
 memoria<15><7> and memoria<15><2> are equivalent: (memoria<15><2>) is
removed.
 memoria<15><7> and memoria<15><1> are equivalent: (memoria<15><1>) is
removed.
 memoria<15><7> and memoria<15><0> are equivalent: (memoria<15><0>) is
removed.
 memoria<15><7> and memoria<14><7> are equivalent: (memoria<14><7>) is
removed.
 memoria<15><7> and memoria<14><6> are equivalent: (memoria<14><6>) is
removed.
[...]

Why?

Thank you in advance!

--
Lorenzo



Article: 53838
Subject: Re: EPXA1 Development Kit Getting Started
From: Franz Hollerer <nospam@nospam.org>
Date: Tue, 25 Mar 2003 11:40:50 +0100
Links: << >>  << T >>  << A >>
Hi Thomas,

Thanks for your answer.

Do you mean the toolset path which can be specified inside
Quartus II or the PATH environment variable provided by the
operating system?

I removed all old entries in the PATH environment variable without
effect.

I have also installed Cygnus for HOST=TARGET=Windows but it does not
occur in the PATH.

Is there a way to tell Quartus II to be more informative?

The message
 >>>Design Debug: Software build was unsucessful. 0 errors, 0 warnings.

can't be all? Is there a log file where I can find more details about
the real problem?

Best regards,
Franz Hollerer

Thomas Siebert wrote:
> Hi,
> 
> I had similiar issues with my NIOS Installation and compiling sources
> under Quartus. In my case this was caused by old references to directories
> of former installations of the cygnus tools. You may find those false
> directories
> in the path variable of your systems folder.
> 
> regards  Thomas
> 
> "Franz Hollerer" <nospam@nospam.com> schrieb im Newsbeitrag
> news:Xns93459A6561A9Ehollererdecomsyscom@213.129.232.14...
> 
>>Hi,
>>
>>I try to compile the hello example described in the
>>EPXA1 Development Kit Getting Started User Guide using
>>GNUPro.
>>
>>If I call 'make debug' from the command line it works,
>>but if I use Quartus II v2.1 I get some non-informative error message:
>>
>>
>>>Design Debug: Software build was unsucessful. 0 errors, 0 warnings.
>>
>>Can someone give me a hint what's going wrong?
>>
>>Best regards,
>>
>>Franz Hollerer
> 
> 
> 


Article: 53839
Subject: Altera EPXA1 Development Kit - problems with the GNUPro Insight Debugger
From: Franz Hollerer <nospam@nospam.org>
Date: Tue, 25 Mar 2003 13:26:54 +0100
Links: << >>  << T >>  << A >>
Hi,

I try to experiment with the "hello" example described in the
Altera Excalibur EPXA1 Development Kit - Getting Started User Guide.

I want to use the GNUPro Debugger to debug the program. I can
start the debugger as described in the document, but setting
breakpoints, single steps etc. does not work.

Are there some restrictions for using the gdb? e.g. Ram, Flash?

Best regards,
Franz


Article: 53840
Subject: Re: Permanent Local Damage to FPGA
From: Ray Andraka <ray@andraka.com>
Date: Tue, 25 Mar 2003 13:36:12 GMT
Links: << >>  << T >>  << A >>
Before you conclude that it is the FPGA and not a fault in your design, you
need to figure out if the fault exists in a different design using the same
failing resource.  In order to do that, you'll need to isolate the failure to
a particular node.  Internal errors are quite rare.  If you are seeing this on
more than one device, the likelihood of if being a bonafide FPGA failure is
near nil.  Xilinx can probably help out with testing to determine if a failure
slipped past their testing.


Glen Herrmannsfeldt wrote:

> "Michael Garvie" <mmg20@cogs.susx.ac.uk> wrote in message
> news:3E7F5476.251F4276@cogs.susx.ac.uk...
>
> > Do you know of any evidence suggesting a permanent failure mode
> > affecting a local area (CLB or routing) of an FPGA which doesn't go away
> > with reconfiguration or rebooting?  Perhaps manufacturing defects only
> > appearing after a year of deployment,  damage due to extreme operating
> > conditions or general degradation after decades of deployment?
>
> I might guess that if you can get bus contention on an internal bus, then
> you could possibly cause damage.  The software should check this before it
> writes the bits, unless you modify them after the check.
>
> -- glen

--
--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: 53841
Subject: Re: Altera EPXA1 Development Kit - problems with the GNUPro Insight
From: Franz Hollerer <nospam@nospam.org>
Date: Tue, 25 Mar 2003 16:17:49 +0100
Links: << >>  << T >>  << A >>
Hi,

I now found that I can use the gdb to interrupt the already
downloaded an running hello example and go from this point step by step.

If I set a breakpoint at main() and restart the program gdb says:

 > Error: You can't do that without a process to debug.

What does this message mean? How can I use the gdb to restart
the program to allow debuging from the very begin of the program?

Best regards,
Franz Hollerer


Franz Hollerer wrote:
> Hi,
> 
> I try to experiment with the "hello" example described in the
> Altera Excalibur EPXA1 Development Kit - Getting Started User Guide.
> 
> I want to use the GNUPro Debugger to debug the program. I can
> start the debugger as described in the document, but setting
> breakpoints, single steps etc. does not work.
> 
> Are there some restrictions for using the gdb? e.g. Ram, Flash?
> 
> Best regards,
> Franz
> 


Article: 53842
Subject: Re: Permanent Local Damage to FPGA
From: Michael Garvie <mmg20@cogs.susx.ac.uk>
Date: Tue, 25 Mar 2003 15:57:00 +0000
Links: << >>  << T >>  << A >>
What I really meant was:
Given that a design works perfectly on a tested FPGA.  After 10 years or so of
full operation maybe under exposure to radiation, high temperatures, moisture and
other abnormal operating conditions; is there a failure mode which affects local
CLBs permanently?
Regards,
Miguel

PD: This is not a problem I am having, I'm interested in how FPGAs fail.

Ray Andraka wrote:

> Before you conclude that it is the FPGA and not a fault in your design, you
> need to figure out if the fault exists in a different design using the same
> failing resource.  In order to do that, you'll need to isolate the failure to
> a particular node.  Internal errors are quite rare.  If you are seeing this on
> more than one device, the likelihood of if being a bonafide FPGA failure is
> near nil.  Xilinx can probably help out with testing to determine if a failure
> slipped past their testing.
>
> Glen Herrmannsfeldt wrote:
>
> > "Michael Garvie" <mmg20@cogs.susx.ac.uk> wrote in message
> > news:3E7F5476.251F4276@cogs.susx.ac.uk...
> >
> > > Do you know of any evidence suggesting a permanent failure mode
> > > affecting a local area (CLB or routing) of an FPGA which doesn't go away
> > > with reconfiguration or rebooting?  Perhaps manufacturing defects only
> > > appearing after a year of deployment,  damage due to extreme operating
> > > conditions or general degradation after decades of deployment?
> >
> > I might guess that if you can get bus contention on an internal bus, then
> > you could possibly cause damage.  The software should check this before it
> > writes the bits, unless you modify them after the check.
> >
> > -- glen
>
> --
> --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: 53843
Subject: Programming fpga
From: "joan rodo" <joanrodo@betaprint.com>
Date: Tue, 25 Mar 2003 17:02:15 +0100
Links: << >>  << T >>  << A >>
Hi Guys

    I'm developing a new board  with a spartan II  xc2s50 and I want to
integrated the programming of the FPGA in my C software there any routine
that translates from  mcs file to a C file.

    Or there are any easy solution for to that.

Thanks for all.








Article: 53844
Subject: Re: CLKDLL synthesized with synplify pro
From: "Barry Brown" <barry_brown@agilent.com>
Date: Tue, 25 Mar 2003 08:48:48 -0800
Links: << >>  << T >>  << A >>
This works in VHDL source:

 -- These attributes are needed if virtex library not used with Synplify.
 attribute syn_black_box : boolean;
 attribute syn_black_box of IBUFG : component is true;
 attribute syn_black_box of IBUF  : component is true;
 attribute syn_black_box of CLKDLL : component is true;
 attribute syn_black_box of BUFG : component is true;
 attribute syn_black_box of OBUF : component is true;

Alternatively, you can just include the synplify virtex library:

library virtex;
use virtex.components.all;

But this will confuse ModelSim, so you'll have to comment it out for
simulation.

I believe I have heard that the latest version of Synplify can also use the
Xilinx
Unisim library, as ModelSim does, but I have not yet upgraded, so I have to
hide it with pragmas for synthesis:

-- synthesis translate_off
library unisim;
use unisim.vcomponents.all;
-- synthesis translate_on

Barry Brown


"tote" <tote_last@yahoo.de> wrote in message
news:91e0be86.0303250002.4fc43654@posting.google.com...
> Ok, thanks. This helps to understand how to use this DLL. This is
> exactly what i need. The second clock buffer to use both clocks (CLKB
> and CLK2XB) in my design. And this is all working fine in simulation.
>
> I want to use this on a VirtexE architecture. My problem is, that i
> don't know how to synthesize such XILINX cells like CLKDLL with the
> SYNPLIFY PRO synthesizer.
> In the documentations i just found things like:
>
> input Clk_in /* synthesis xc_clockbuftype = "IBUFG" */;
>
> ok, that's s.th. i can use for the two buffers IBUFG and BUFG. I also
> found s. th. similar with the BUFGDLL (IBUFG->CLKDLL->BUFG). However,
> that's always working with one input signal name, used as the output
> name again. I don't understand how to connect more signals between
> such XILINX cells with this method using SYNPLIFY.
> SYNPLIFY seems not able to just synthesize these things. Or do i have
> to add additional XILINX libraries? Anyway, i also can't find any
> option for this.
>
> I do appriciate your help.
>
> Thorsten
>
>
>
> "Avrum" <avrum@sympatico.ca> wrote in message
news:<7mJfa.673$lf3.36793@news20.bellglobal.com>...
> > Pretty much exactly like that.
> >
> > However, from your naming convention, you may be confusing which signal
to
> > use as the main clock to clock logic. The clock that should be fed to
the
> > flip-flops is the output of the BUFG, in this case, named CLKB, not the
> > signal named Clk - this is a local, dedicated connection from the DLL to
the
> > BUFG. The BUFG component is the main "clock buffer" - conceptually, it
> > drives the load of the clock distribution network.
> >
> > In addition, you need a second BUFG to drive the flops being driven on
the
> > CLK2x domain. You would need to add
> >
> > BUFG U4 (.I(CLK2x), .O(CLK2XB));
> >
> > Again, remember, CLK2XB is the clock that should be used to drive flops
on
> > the 2X domain (not CLK2x).
> >
> > Also, (I don't have the specs in hand, and you don't say which
architecture
> > you are using), there may be a requirement as to which clock needs to be
> > used for the CLKFB of the DLL when you are using both CLK and CLK2X -
you
> > may need to use the output of the CLK2X BUFG (which I called CLK2XB).
> >
> > Avrum
> >
> > "tote" <tote_last@yahoo.de> wrote in message
> > news:91e0be86.0303240810.46e23d89@posting.google.com...
> > > Hi,
> > >
> > > in my design i'm using 2 clock signals, CLK and CLK2x. I'm generating
> > > these 2 clocks from a "input-clock" with a DLL like:
> > >
> > > IBUFG U1 (.I(Clk_in), .O(CLKIN));
> > > CLKDLL U2 (.CLKIN(CLKIN), .CLKFB(CLKB), .RST(~nReset1),
> > > .CLK0(Clk), .CLK90(), .CLK180(), .CLK270(),
> > >         .CLK2X(CLK2x), .CLKDV(), .LOCKED(LOCKED));
> > > BUFG U3 (.I(Clk), .O(CLKB));
> > >
> > > That's basically how it's described in the xilinx application notes.
> > > Working fine for simulation.
> > > However, does anybody know, how to write this to synthesize it with
> > > synplify pro?
> > >
> > > Thanx for your help
> > > Thorsten
>



Article: 53845
Subject: Re: Permanent Local Damage to FPGA
From: jb@nospam.com
Date: 25 Mar 2003 08:55:05 -0800
Links: << >>  << T >>  << A >>
In article <3E807C4C.AA71B21D@cogs.susx.ac.uk>, Michael says...
>
>What I really meant was:
>Given that a design works perfectly on a tested FPGA.  After 10 years or so of
>full operation maybe under exposure to radiation, high temperatures,
>moisture and other abnormal operating conditions; is there a failure mode
>which affects local CLBs permanently?
>Regards,
>Miguel
>
>PD: This is not a problem I am having, I'm interested in how FPGAs fail.

It's not specific to FPGAs, but CMOS circuits can fail long term if not
designed properly.

If the current in a wire is too high you can get electromigration (see
http://www.csl.mete.metu.edu.tr/Electromigration/emig.htm ). This will
lead to thinning and breakage.

If a thin poly line is connected to a large aluminum rail, the aluminum
will diffuse into the poly, increasing its resistance.  This can be designed
around by using aluminum stubs or including sacrificial poly.


Jeff Bartlett
Synopsys, Inc
physical verification tools


Article: 53846
Subject: Re: Permanent Local Damage to FPGA
From: spam_hater_7@email.com (Spam Hater 7)
Date: 25 Mar 2003 09:37:10 -0800
Links: << >>  << T >>  << A >>
Hi,

Yes, it is possible to configure an FPGA so that it will destroy parts of itself.

Two or more low-Z drivers on an internal bus is one way.

I get a reminder of this at least once a year.

SH

Michael Garvie <mmg20@cogs.susx.ac.uk> wrote in message news:<3E7F5476.251F4276@cogs.susx.ac.uk>...
> Dear All,
> Do you know of any evidence suggesting a permanent failure mode
> affecting a local area (CLB or routing) of an FPGA which doesn't go away
> with reconfiguration or rebooting?  Perhaps manufacturing defects only
> appearing after a year of deployment,  damage due to extreme operating
> conditions or general degradation after decades of deployment?
> 
> Single Event Latch-Up seems to be extremely uncommon and when it does
> happen reconfiguration restores correct functionality.
> 
> Yours Sincerely,
> Miguel Garvie

Article: 53847
Subject: Re: Programming fpga
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 25 Mar 2003 17:44:11 GMT
Links: << >>  << T >>  << A >>
It might be easiest to generate a .bin file from the Xilinx tools rather
than an .mcs file.

Simple.  Straighforward.


"joan rodo" <joanrodo@betaprint.com> wrote in message
news:b5pum8$i7q$1@nsnmrro2-gest.nuria.telefonica-data.net...
> Hi Guys
>
>     I'm developing a new board  with a spartan II  xc2s50 and I want to
> integrated the programming of the FPGA in my C software there any routine
> that translates from  mcs file to a C file.
>
>     Or there are any easy solution for to that.
>
> Thanks for all.



Article: 53848
Subject: Re: FPGA FFT Questions
From: johnjakson@yahoo.com (john jakson)
Date: 25 Mar 2003 09:58:52 -0800
Links: << >>  << T >>  << A >>
> [O.T.]
> I was always interested in the analysis of the relative impact of the
> rounding error in the floating-point and the fixed-pointed
> implementations of the (Radix-2) FFT. However I was too lazy to look
> for an answer in the literature or to do the analysis myself (also,

While building an ASIC HFC Cable Telephony Modem containing 192 cFFT,
we were given a std CT Rad2 C code to begin with. At every step of the
transformation to Verilog the datapath in the C code was precisely bit
for bit equal to Verilog and the int result could be compared to
original Matlab FP result. We were looking for uniform error levels
across the outputs to within 1 or 2 lsbs. We were later surprised to
learn how errors in the int math would accumulate to the outputs at
the ends making those channels less than useful picking up 5 or 6bit
lsb or error.

Solution was not just to add saturation logic to the write back, but
to pay attention to the rounding. When doing >> by 0,1,2 bits, the
sign must also be considerd so that result is exactly same as div by
1,2,4 etc. The scaling was usually handled by scaling back every other
row.

One other detail is that the Rad2 was based on a 3 mul asymetric
butterfly probably as efficient as Rad4 in terms of *+, inside a Rad8
box, good for serial engines.

In another FPGA FFT engine, the C model, Matlab and Verilog models did
not agree except in some approx way, the rounding was not sign
correct.

The gist is that FPGAs give you a fast but dumb adder but relatively
slow logic to sort out fine math details. In the ASIC, the final
incremental cost of saturation and sign corrected rounding was about 4
extra gate delays & 20% more ALU logic over simple fast adders.

Article: 53849
Subject: Re: Increased Wafer yield by row adjusted placement
From: Stromeko@nexgo.de (Achim Gratz)
Date: 25 Mar 2003 10:16:50 -0800
Links: << >>  << T >>  << A >>
johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0303181856.3de89734@posting.google.com>...
> I notice that 1 good die is offset (top right) ie the xy row col
> placement isn't entirely strict for no good obvious reason.

There is a very obvious and good reason: when a wafer is diced, you
glue it to a membrane and then saw it in both perpendicular directions.
Only then are the individual dice taken off the membrane.

> If it is indeed the case that wafers can be sawed row by row then
> independantly col by col I can see a 10% yield increase by sliding the
> corner clipped rows sideways a bit. Perhaps that would lead to 10%
> price reduction too! Perhaps a reward or job too!

No cigar. :-)

Achim.



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