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 104300

Article: 104300
Subject: is picoblaze worth in my project?
From: "Marco" <marco@marylon.com>
Date: 23 Jun 2006 02:36:53 -0700
Links: << >>  << T >>  << A >>
Hi all,

I'm doing few tests in these days with the PicoBlaze and it seems to
work just fine. Now, in my project, where a Spartan3 has to deal with a
DSP through a serial spi-like communication to reply on different
request that may arrive, do you think could be woth using with a
PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
read from its inputs, or to write on its output, or to read a
temperature from an spi-sensor and the send it to the DPS, or to read
the values from quadraure decoder...
Picoblaze or vhdl from scratch in your experienced opinion?
I'm making some considerations by myself now, but I'd like to hear
comments from you too.

Thanks,
Marco


Article: 104301
Subject: Re: is picoblaze worth in my project?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 23 Jun 2006 12:07:28 +0200
Links: << >>  << T >>  << A >>
Marco schrieb:
> Hi all,
> 
> I'm doing few tests in these days with the PicoBlaze and it seems to
> work just fine. Now, in my project, where a Spartan3 has to deal with a
> DSP through a serial spi-like communication to reply on different
> request that may arrive, do you think could be woth using with a
> PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
> read from its inputs, or to write on its output, or to read a
> temperature from an spi-sensor and the send it to the DPS, or to read
> the values from quadraure decoder...
> Picoblaze or vhdl from scratch in your experienced opinion?
> I'm making some considerations by myself now, but I'd like to hear
> comments from you too.

Picoblaze offers a lot of bang for the buck. Especially in S3, where you 
have 1k program space. Since it sounds like you have to handle a lot of 
task which are not too time critical, I would go for the Picoblaze. 
Also, odification in the control algorithm are done much easier in the 
picoblaze than in a FSM.

Regards
Falk


Article: 104302
Subject: Re: Newbie in Chipscope-changes need to route bidirectional data port
From: "subint" <subin.82@gmail.com>
Date: 23 Jun 2006 03:18:42 -0700
Links: << >>  << T >>  << A >>
Hi,
 i am trying to probe the signal going to the IOB.When i try to probe
the ddr_dq(the inout port of the ddr) i got this error.
Started : "Map".
Using target part "4vlx60ff668-10".
Mapping design into LUTs...
Running directed packing...
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d
   q failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d
   q requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_
   dq requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_
   dq requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_
   dq requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_
   dq requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_
   dq requires general routing.
ERROR:Pack:1564 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_
   dq failed to join the OLOGIC component as required.  The output
signal for
   register symbol

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_
   dq requires general routing.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob1/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob10/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob5/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob14/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob9/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob2/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob11/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob6/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob15/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob3/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob12/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob7/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob4/oddr_d
   q failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob13/oddr_
   dq failed to join an OLOGIC component as required.
ERROR:Pack:1569 - The dual data rate register

mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob8/oddr_d
   q failed to join an OLOGIC component as required.



i didnt understand the message. can you please tell me what it is.
regard
subin

Symon wrote:
> "subint" <subin.82@gmail.com> wrote in message
> news:1150971643.167338.124530@r2g2000cwb.googlegroups.com...
> > Hi,
> > I am using the chipshop first time.
>
> Hi Subin,
> I recommend the battered cod. :-)
>
> > I am using this one to debug my ddr
> > controller in the v4 board. When i tried to route the data bus of ddr
> > through the chipscope it generated ILA and inserted into my design but
> > when i try to implement(map and par) xilinx ise showing error that the
> > bidirectional port is being driven by some buffer by the chipscope
> > module.the ddr bus are  bidirectional so what changes needed in the
> > chipscope setting to route my bidirectional port.
> > regard
> > subin
> >
> I think your problem could be that you're trying to probe the pads of the
> IOBs. There's no way for ChipScope to connect to this without going through
> an input buffer. Try probing the signal that comes off the input
> buffer(IOB.I) of the IOB. If that's not it, perhaps you could post the error
> message you're getting?
> HTH, Syms.
>
>
>
> Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php


Article: 104303
Subject: Re: Newbie in Chipscope-changes need to route bidirectional data
From: Joseph Samson <user@example.net>
Date: Fri, 23 Jun 2006 12:37:45 GMT
Links: << >>  << T >>  << A >>
subint wrote:
>>"subint" <subin.82@gmail.com> wrote in message
>>news:1150971643.167338.124530@r2g2000cwb.googlegroups.com...
>>
>>>Hi,
>>>I am using the chipshop first time.
>>
>>Hi Subin,
>>I recommend the battered cod. :-)
>>
>>
>>>I am using this one to debug my ddr
>>>controller in the v4 board. When i tried to route the data bus of ddr
>>>through the chipscope it generated ILA and inserted into my design but
>>>when i try to implement(map and par) xilinx ise showing error that the
>>>bidirectional port is being driven by some buffer by the chipscope
>>>module.the ddr bus are  bidirectional so what changes needed in the
>>>chipscope setting to route my bidirectional port.
>>>regard
>>>subin

 > Symon replied:
 >
 >>>
 >>
 >>I think your problem could be that you're trying to probe the pads of the
 >>IOBs. There's no way for ChipScope to connect to this without going 
through
 >>an input buffer.


subint followup:
> Hi,
>  i am trying to probe the signal going to the IOB.When i try to probe
> the ddr_dq(the inout port of the ddr) i got this error.
> Started : "Map".
> Using target part "4vlx60ff668-10".
> Mapping design into LUTs...
> Running directed packing...
> ERROR:Pack:1564 - The dual data rate register
> 
> mem_interface_top0/main_00/top_00/iobs_00/data_path_iobs_00/v4_dq_iob0/oddr_d
>    q failed to join the OLOGIC component as required.  The output
> signal for
>    register symbol
> 
	[snip]


Symon is right, you've specified an IOB output to probe in ChipScope. 
Although ChipScope lets you do this, it's generally a bad idea, 
especially if you have an IOB flip-flop. In the case where you're 
probing the output of a non-DDR IOB flip-flop, ChipScope connects a 
probe to the flip-flop output, but then ISE can't place the flip-flop in 
the IOB (because there is no routing resource that ISE can find), so the 
flip-flop goes in the fabric. Now, instead of having a nice short 
clock-to-output delay, you have a much longer delay through the fabric. 
In the case of the DDR IOB flip-flop, there is no DDR flip-flop that ISE 
can put in the fabric, so the signal can't be routed.


---
Joe Samson
Pixel Velocity

Article: 104304
Subject: Re: is picoblaze worth in my project?
From: "John McCaskill" <junkmail@fastertechnology.com>
Date: 23 Jun 2006 05:44:23 -0700
Links: << >>  << T >>  << A >>

Marco wrote:
> Hi all,
>
> I'm doing few tests in these days with the PicoBlaze and it seems to
> work just fine. Now, in my project, where a Spartan3 has to deal with a
> DSP through a serial spi-like communication to reply on different
> request that may arrive, do you think could be woth using with a
> PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
> read from its inputs, or to write on its output, or to read a
> temperature from an spi-sensor and the send it to the DPS, or to read
> the values from quadraure decoder...
> Picoblaze or vhdl from scratch in your experienced opinion?
> I'm making some considerations by myself now, but I'd like to hear
> comments from you too.
>
> Thanks,
> Marco

The PicoBlaze is absolute gem and easy to use.  At one block ram and
under a hundred slices in size it is not that big, but can do quite a
lot of work.  One of the things that I like about it is that I can
change its program without having to resynthesize and place and route
again.

They are very well suited for large state machines that need to deal
with events at microsecond or slower rates.  We have used them on a
V4FX with the TEMAC to offload a custom IP/UDP protocol at GIGE rates,
on a Spartan3e to read the file system on a MiniSD card, and on a V2 to
run the adapation algorithm of some adaptive filters.  In all of these
applications, I think that it was simpler to write the assembly code
than it would have been to write a VHDL/Verilog state machine, and
probably used less resources as well.

On the Xilinx web site, there is a fourm dedicated to the PicoBlaze
with some links to PicoBlaze programs for IIC, serial ports etc that
may be of interest to you as examples.

Regards,

John McCaskill


Article: 104305
Subject: Re: stimulus for FPGA
From: "Ricardo" <rtafas@gmail.com>
Date: 23 Jun 2006 06:11:16 -0700
Links: << >>  << T >>  << A >>
If you are new to FPGA, probably new to VHDL and Digital Design.

I hope you get some good references in Digital Systems, Synchronous
design and Synthesizable VHDL (google, the Great Library). You won=B4t
regret studying this and things will sound a lot more familiar...

Regards,

Ricardo

anand escreveu:

> I am planning on buying either a Xilinx Spartan or Altera Development
> Kit to test out some designs on FPGA. (I am New to FPGAs).
>
> Question:
>
> Once the design has been downloaded into the FPGA, how do I apply
> stimulus and test the design? I believe several methods are possible,
> but I would like one where both the stimulus (is applied in) and the
> response (is checked) using a high level language like C or C++.
> Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
> That way I can write C or C++ code to run a real "app".


Article: 104306
Subject: Re: cache aware programming
From: eascheiber@yahoo.com
Date: 23 Jun 2006 06:55:41 -0700
Links: << >>  << T >>  << A >>
Hi,

I am using __attribute__ ((section ("ppath"))) and __attribute__
((longcall)) now in my program. The relevant linker script part looks
like this:

MEMORY
{
   SDRAM_64Mx16 : ORIGIN = 0xF0000000, LENGTH = 0x01FFFFFF
   plb_bram_if_cntlr_1 : ORIGIN = 0xFFFFC000, LENGTH = 0x00003FFF
}

/* Specify the default entry point to the program */

ENTRY(_boot)
STARTUP(boot.o)

/* Define the sections, and where they are mapped in memory */

SECTIONS
{
.vectors : {
   __vectors_start = .;
   *(.vectors)
   __vectors_end = .;
} > SDRAM_64Mx16

.text : {
   __text_start = .;
   *(.ppath)
   *(.text)
   *(.text.*)
   *(.gnu.linkonce.t*)
   __text_end = .;
} > SDRAM_64Mx16

After compilation I run powerpc-eabi-objdump and I get:

  0 .vectors      000020c4  f0000000  f0000000  00000110  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text         0000e6e8  f00020c4  f00020c4  000021d4  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  2 ppath         0000001c  00000000  00000000  000000f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .rodata       00000906  f00107ac  f00107ac  000108bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .fixup        00000014  f00110b4  f00110b4  000111c4  2**2


My question is why is ppath at 0x00000000 when this address should not
be mapped in
the SDRAM?

Actually I would have liked to have the ppath section directly after or
before all
other code, so that maybe __attribute__ ((longcall)) shouldn't even be
necessary.

Regards,
e.


Article: 104307
Subject: Re: cache aware programming
From: eascheiber@yahoo.com
Date: 23 Jun 2006 07:01:44 -0700
Links: << >>  << T >>  << A >>
Ok guys,

I think I got it, it should be:
    *(ppath)
without the dot and I won't see section ppath in the output :).

Regards,
e.


Article: 104308
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 23 Jun 2006 07:47:31 -0700
Links: << >>  << T >>  << A >>
Jim,

No, I have not cracked the Altera chip.  I have received emails from
schools and universities who wish to crack it.  These are the same
schools that have published successful smart card attacks.

My quote of $5,000 is what we pay to have a device ground down on the
backside such that we can do analysis on a device.

For another $5,000, one can get up to three or four FIB cuts, and a
couple of jumper wires.

The IEEE paper clearly discusses the technology, and what happens when
the fuse has all of its ions electromigrated to the other end, leaving
intrinsic silicon poly, which has a different index of refraction that
the poly with the ions.

There are difficulties.  Find the fuses, read the values, and then
figure out what (if any)logic may be present to confuse the key bits.

That is why the Actel via fuses are considered much better (harder to
find, and read).

None the less, the attack is not 2E128 as the NIST standard implies (the
one they claim to meet FIPS 197, definition of AES 128, 256, 384 and
512).  Sure the algorithm is a AES 128 one, but with knowledge of all
the fuse contents, the search space is lessened such that in maybe
twenty minutes or so of permutations on the key bits, you have the
device unlocked (bitstream is now in the clear on your computer, and
ready for cloning, reverse engineering, etc.)

No one has reverse engineered a bitstream for Xilinx or Altera, as far
as we know, on a large device.  But that doesn't mean that someone could
not make specific modifications to an existing bitstream (change IO
location, drive strength, etc.) without having to know the whole design.

The question is not one of can I crack it (I believe I can), but one of
a ASSP vendor deciding to place their IP in a component that is not in
compliance with FIPS 140-2.  Very, very simple.

For reference:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1493126

Remember that any attack that is successful removes the security
forever.  So, do you want to use something where there are known ways to
crack it?  Or, do you want to use something that today there is no known
method of cracking?

For example, finding the battery backed key has been something that has
been tried and been unsuccessful.  Then we were attacked with
differential power attacks (DPA).  So far, those have been unsuccessful
as well.  As an aside, DPA attacks of ASIC AES has been successful!

Yet another example of how a FPGA can actually be superior to an ASIC
solution.

I will be giving a talk on security in V4 and V5 soon, so watch for the
announcements.

Just as an aside, the coin cell lithium battery vendors have informed me
that for my use, the battery will last "forever."  Since we hold the key
down to Vbatt voltages of much less than 1 volt, and the coin cell
starts out life at over 3 volts, and the stated 15 year life is to
discharge to 2 volts, we will last multiples of 15 years.  So the
"terrible battery problem" is no big issue.

Set top cable boxes use a lithium battery to store the keys.  Cable
companies aren't stupid:  they would not use a battery unless there was
a good reason.  After all, they make millions of set top boxes.  All
they protect is a few movies, and yet they feel that following FIPS
140-2 is the only safe way to go (as everything else has been hacked).

We are examining how to use efuses.  I can not say anything right now,
except I think there are going to be very useful, and helpful.  They can
be used for device ID, matching a key to a device, factory information
(lot, wafer, serial numbers), control of internal circuits (set
currents, voltages, etc. to get around process variations), repair
faults by substituting redundant features...long long list.  And, of
course, to hold a key for those who only have a $5,000 or less secret to
protect.

How much efuse memory should be for the user?  How much for the
customer?  Unlike my friend, the questions we ask are pretty detailed,
and we are very careful about what we do.

Austin


Jim Granville wrote:
> Austin Lesea wrote:
>> What is missing from all those press releases:
>>
>> *Disclaimer:  non-volatile poly-efuse EM technology can be read out by a
>> microscope using polarized light for a total investment of less than
>> $5,000
> 
> .. and that may not quite be the open door you paint.
> 
> Have _you_actually_cloned_ a/any device for $5000, or is this more
> generic "Austin Arm waving" ? :)
> 
> [Until Xilinx have non volatile fuses, then the spin will change ? ]
> 
>  Being able to read the physical fuses is some way from being able to
> duplicate them, or reverse the key those fuses create.
> It is not likely that Altera simply mapped Fuse1 = Encryption bit1, etc.
> 
>  So, to descramble that, will need a LOT of devices, and much more time....
> 
>  With fully volatile security, yes, the code within is secure,
> but the system is _very_ open to spoofing type attacks, so again
> security can be a mirage....
> 
>  -jg
> 

Article: 104309
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 23 Jun 2006 07:49:44 -0700
Links: << >>  << T >>  << A >>
Jim,

Part of my problem is that Altera has kept it a secret how to set the
key bits.

Without that knowledge, I can not program a device, in order to crack it.

So, I guess I will have to buy some parts from those trusting ASSP vendors.

Austin

Austin Lesea wrote:
> Jim,
> 
> No, I have not cracked the Altera chip.  I have received emails from
> schools and universities who wish to crack it.  These are the same
> schools that have published successful smart card attacks.
> 
> My quote of $5,000 is what we pay to have a device ground down on the
> backside such that we can do analysis on a device.
> 
> For another $5,000, one can get up to three or four FIB cuts, and a
> couple of jumper wires.
> 
> The IEEE paper clearly discusses the technology, and what happens when
> the fuse has all of its ions electromigrated to the other end, leaving
> intrinsic silicon poly, which has a different index of refraction that
> the poly with the ions.
> 
> There are difficulties.  Find the fuses, read the values, and then
> figure out what (if any)logic may be present to confuse the key bits.
> 
> That is why the Actel via fuses are considered much better (harder to
> find, and read).
> 
> None the less, the attack is not 2E128 as the NIST standard implies (the
> one they claim to meet FIPS 197, definition of AES 128, 256, 384 and
> 512).  Sure the algorithm is a AES 128 one, but with knowledge of all
> the fuse contents, the search space is lessened such that in maybe
> twenty minutes or so of permutations on the key bits, you have the
> device unlocked (bitstream is now in the clear on your computer, and
> ready for cloning, reverse engineering, etc.)
> 
> No one has reverse engineered a bitstream for Xilinx or Altera, as far
> as we know, on a large device.  But that doesn't mean that someone could
> not make specific modifications to an existing bitstream (change IO
> location, drive strength, etc.) without having to know the whole design.
> 
> The question is not one of can I crack it (I believe I can), but one of
> a ASSP vendor deciding to place their IP in a component that is not in
> compliance with FIPS 140-2.  Very, very simple.
> 
> For reference:
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1493126
> 
> Remember that any attack that is successful removes the security
> forever.  So, do you want to use something where there are known ways to
> crack it?  Or, do you want to use something that today there is no known
> method of cracking?
> 
> For example, finding the battery backed key has been something that has
> been tried and been unsuccessful.  Then we were attacked with
> differential power attacks (DPA).  So far, those have been unsuccessful
> as well.  As an aside, DPA attacks of ASIC AES has been successful!
> 
> Yet another example of how a FPGA can actually be superior to an ASIC
> solution.
> 
> I will be giving a talk on security in V4 and V5 soon, so watch for the
> announcements.
> 
> Just as an aside, the coin cell lithium battery vendors have informed me
> that for my use, the battery will last "forever."  Since we hold the key
> down to Vbatt voltages of much less than 1 volt, and the coin cell
> starts out life at over 3 volts, and the stated 15 year life is to
> discharge to 2 volts, we will last multiples of 15 years.  So the
> "terrible battery problem" is no big issue.
> 
> Set top cable boxes use a lithium battery to store the keys.  Cable
> companies aren't stupid:  they would not use a battery unless there was
> a good reason.  After all, they make millions of set top boxes.  All
> they protect is a few movies, and yet they feel that following FIPS
> 140-2 is the only safe way to go (as everything else has been hacked).
> 
> We are examining how to use efuses.  I can not say anything right now,
> except I think there are going to be very useful, and helpful.  They can
> be used for device ID, matching a key to a device, factory information
> (lot, wafer, serial numbers), control of internal circuits (set
> currents, voltages, etc. to get around process variations), repair
> faults by substituting redundant features...long long list.  And, of
> course, to hold a key for those who only have a $5,000 or less secret to
> protect.
> 
> How much efuse memory should be for the user?  How much for the
> customer?  Unlike my friend, the questions we ask are pretty detailed,
> and we are very careful about what we do.
> 
> Austin
> 
> 
> Jim Granville wrote:
>> Austin Lesea wrote:
>>> What is missing from all those press releases:
>>>
>>> *Disclaimer:  non-volatile poly-efuse EM technology can be read out by a
>>> microscope using polarized light for a total investment of less than
>>> $5,000
>> .. and that may not quite be the open door you paint.
>>
>> Have _you_actually_cloned_ a/any device for $5000, or is this more
>> generic "Austin Arm waving" ? :)
>>
>> [Until Xilinx have non volatile fuses, then the spin will change ? ]
>>
>>  Being able to read the physical fuses is some way from being able to
>> duplicate them, or reverse the key those fuses create.
>> It is not likely that Altera simply mapped Fuse1 = Encryption bit1, etc.
>>
>>  So, to descramble that, will need a LOT of devices, and much more time....
>>
>>  With fully volatile security, yes, the code within is secure,
>> but the system is _very_ open to spoofing type attacks, so again
>> security can be a mirage....
>>
>>  -jg
>>

Article: 104310
Subject: Re: xc3sprog -- any updates?
From: "Eric" <jonas@mwl.mit.edu>
Date: 23 Jun 2006 09:43:09 -0700
Links: << >>  << T >>  << A >>
> I got it from :
>    http://www.rogerstech.force9.co.uk/
>    http://www.rogerstech.force9.co.uk/xc3sprog/index.html
> (seems to be the webpage of the author...)
>
> Sandro

Wow, I swear I started with the same copy. I don't know how that
happened...  try again? Revision 2 should be the latest latest.


Article: 104311
Subject: Re: Any eval SW comes with Spartan 3E Dev board from Xilinx/Digilent ?
From: "Dave Pollum" <vze24h5m@verizon.net>
Date: 23 Jun 2006 09:55:44 -0700
Links: << >>  << T >>  << A >>

rashid.karimov@gmail.com wrote:
> ISE  and/or EDK ?

I just received the S3E board.  It comes with:
DVD-
 ISE 8.1i (not sure if it's the latest SP)
 ISE 8.1i Foundation (eval)
 Chipscope Pro 8.1i (eval)
Spartan-3 Generation Resource CD
EDK 8.1i, including Platform Studio (eval(Windows only))

HTH
-Dave Pollum


Article: 104312
Subject: Re: stimulus for FPGA
From: "anand" <writeanand@gmail.com>
Date: 23 Jun 2006 10:38:16 -0700
Links: << >>  << T >>  << A >>
So in the case, how do real applications actually run (in the customer
environment) when it is downloaded onto an FPGA?



Mark McDougall wrote:
> anand wrote:
>
> > Once the design has been downloaded into the FPGA, how do I apply
> > stimulus and test the design? I believe several methods are possible,
> > but I would like one where both the stimulus (is applied in) and the
> > response (is checked) using a high level language like C or C++.
> > Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
> > That way I can write C or C++ code to run a real "app".
>
> An FPGA is no different in this respect to any other piece of hardware
> you may design. So there is no software "API" to interface to an FPGA
> any more than there are APIs to interface to a 74LS02 or a LED.
>
> You may be getting confused with *simulation*, which does not involve
> programming a physical FPGA but instead simulating the behaviour of your
> FPGA code in software. Stimulus can be provided in several manners and
> with many different languages, including C/C++.
>
> Alternatively, you need to interface your FPGA to a PC via whatever
> means is suitable to the task, from a PCIe/PCI connector down to a
> serial port. Exactly how you interface in software is very dependent on
> the hardware interface method you choose.
>
> Another alternative I've just thought of involves using a soft-core
> processor inside the FPGA to interface with the core logic, enabling you
> to write stimulus in C. That brings a whole number of new issues, not
> the least of which is the requirement for a much larger FPGA and perhaps
> more RAM than would otherwise be required.
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266


Article: 104313
Subject: Re: xst can, but vcomp can't
From: "Andy" <jonesandy@comcast.net>
Date: 23 Jun 2006 10:52:42 -0700
Links: << >>  << T >>  << A >>
I'm assuming that "neg" is a constant?

Try declaring neg as a constant parameter, or using an entity with neg
as a generic.

If you can tolerate a delta delay on the clock in simulation, you could
xor the clock with neg and then use only one edge specification. The
xor with a constant will get optimized out.

True DDR circuits are possible with single edge flops and xor gates:

process (clk)
variable qr, qf : std_logic;
begin
if rising_edge(clk) then
  qr := d xor qf; -- encode qr
elsif falling_edge(clk) then
  qf := d xor qr; -- encode qf
end if;
q <= qr xor qf; -- decode q (combinatorial)
end if;

Andy


Ralf Hildebrandt wrote:
> Morten Leikvoll wrote:
>
>
> > Looks like an idea.. Can I call a procedure from another procedure? In that
> > case I can try write a new procedure to extract the bit and pass it (as
> > inout?) to a clock detecting procedure using a clean bit. Hmm.. not sure if
> > that will work tho.. Gotta try it.
>
> Sounds like something that is worth to try. I can't tell you if it will
> be accepted.
>
>
> > I am not really trying to use dual edge here. I only want to program my
> > cpu_register to be able to detect a rising of falling edge from my system
> > depending on a constant input parameter (here, the input variable 'neg').
>
> But what you have written is a something like dual-edge flipflop. If you
> want to detect edges of a signal, use 2 flipflops in a chain. The first
> samples the input data, the 2nd samples the output of the first. Now you
> can compare the output values of both flipflops. If the 1st has '0' as
> output and the 2nd '1' you got a falling_edge and the same holds for the
> rising_edge. The disadvantage: You have a delay depending on your
> sampling frequency.
> 
> 
> Ralf


Article: 104314
Subject: Re: keys to the Kingdom
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 23 Jun 2006 10:52:47 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Jim,
>
> Part of my problem is that Altera has kept it a secret how to set the
> key bits.
>
> Without that knowledge, I can not program a device, in order to crack it.

Hmmm ... perhaps you might now understand the feelings of those legit
users want the Xilinx bitstream format opened (so they can write their
own tools).

Everybody's got a secret, I guess.

-a


Article: 104315
Subject: Re: Xilinx ISE S/W Install kernel version "mismatch"
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 23 Jun 2006 17:54:16 GMT
Links: << >>  << T >>  << A >>
Rich Grise wrote:
> On Wed, 21 Jun 2006 23:17:30 +0000, Duane Clark wrote:
>> Rich Grise wrote:
>>> On Tue, 20 Jun 2006 06:14:25 +0000, Adam Goldman wrote:
>>>> Not specifically for your distribution but here's something on recompiling
>>>> xpc4drvr and windrvr6 for a different kernel:
>>>>
>>>> http://gentoo-wiki.com/HOWTO_Xilinx
>>>>
> ...
> I have no problem with compiling from source, on my current kernel, but
> does Xilinx let us D/L source?
> 

Yes. The HOWTO mentioned by Adam tells where to get them from Xilinx.

Article: 104316
Subject: Re: xst can, but vcomp can't
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Fri, 23 Jun 2006 20:19:34 +0200
Links: << >>  << T >>  << A >>
Andy wrote:


> True DDR circuits are possible with single edge flops and xor gates:
> 
> process (clk)
> variable qr, qf : std_logic;
> begin
> if rising_edge(clk) then
>   qr := d xor qf; -- encode qr
> elsif falling_edge(clk) then
>   qf := d xor qr; -- encode qf
> end if;
> q <= qr xor qf; -- decode q (combinatorial)
> end if;

A lot of synthesis tools will refuse to do something with such a 
process. They see two 'event conditions and finish with an error. That 
is the reason why I have suggested to model this "pseudo-dual-edge 
flipflop" manually.

Ralf

Article: 104317
Subject: Re: stimulus for FPGA
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Fri, 23 Jun 2006 20:24:59 +0200
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

>> Once the design has been downloaded into the FPGA, how do I apply
>> stimulus and test the design?
> 
> It's best to test the code before you synthesize it.
> You don't even need a development board for this.
> Just a text editor and a simulator.
> 
>> I believe several methods are possible,
>> but I would like one where both the stimulus (is applied in) and the
>> response (is checked) using a high level language like C or C++.
>> Are there any C/C++ "APIs" that allow the FPGA pins to be "wiggled"?
> 
> A simulation testbench that you write
> in vhdl or verilog will wiggle and watch the pins
> logically, not physically.

Let me add: After the simulation tests the real hardware tests at the 
FPGA have to be done either using some pins and applying the stimuli 
from another device, like a personal computer or using a synthesized 
testbench, that has to be build additionally to the design.


Ralf

Article: 104318
Subject: Re: stimulus for FPGA
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 23 Jun 2006 11:36:18 -0700
Links: << >>  << T >>  << A >>
anand wrote:
> So in the case, how do real applications actually run (in the customer
> environment) when it is downloaded onto an FPGA?

There are no applications.
There are only gates and flops.

         -- Mike Treseler

Article: 104319
Subject: Optimization of Multiplication in FPGA
From: "agou" <agou.win@gmail.com>
Date: 23 Jun 2006 11:52:37 -0700
Links: << >>  << T >>  << A >>
hi, there

in my project, i need to do some multiplication. and i optimized the
multiplicand to numbers like 0.75, 0.625. I wonder would the
synthesizer automatically detect them like 0.75 = 1 - 1/4, 0.625 = 1/2
+ 1/8, or i need to code it manually in this way?

does it differ across different synthesizer? i am using xilinx
synthesizer.

thanks
Zhaoyi


Article: 104320
Subject: Re: Optimization of Multiplication in FPGA
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 23 Jun 2006 21:27:46 +0200
Links: << >>  << T >>  << A >>
agou schrieb:
> hi, there
> 
> in my project, i need to do some multiplication. and i optimized the
> multiplicand to numbers like 0.75, 0.625. I wonder would the
> synthesizer automatically detect them like 0.75 = 1 - 1/4, 0.625 = 1/2
> + 1/8, or i need to code it manually in this way?

You need to code "semi" manual anyway, since most synthesizers do not 
support floting point multiplications. So when you make a x 0.75 
multiplication, you need to multiply by 192 when you need 8 bit 
precision. A multiplication with an constant is cheap anyway.

Regards
Falk

Article: 104321
Subject: Re: stimulus for FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 23 Jun 2006 15:00:45 -0500
Links: << >>  << T >>  << A >>
In article <1151084296.046232.309590@m73g2000cwd.googlegroups.com>,
 "anand" <writeanand@gmail.com> writes:
>So in the case, how do real applications actually run (in the customer
>environment) when it is downloaded onto an FPGA?

The FPGA is connected to real hardware.

Start with something simple.  Use push-buttons for input and LEDs
for output.  Can you blink the LED?  Can you change the blink pattern
when you push the button?

A scope on an output pin (or several of them) is a pretty good
test case.

Most development boards include various IO gear.  Take a look
at the documentation for the boards you are considering and see
what sort of toy you could make.

-- 
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: 104322
Subject: Achieving timing in Xilinx EDK designs
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 23 Jun 2006 16:00:48 -0400
Links: << >>  << T >>  << A >>
Hi all,

I was wondering if anyone would be willing to share their experiences with
regards to what can be done when a design containing an EDK submodule fails
to meet timing after another IP core has been added to one of the buses? In
the latest particular case I added an opb2plb bridge and that broke the
timing. The OPB bus already runs at half of the PLB rate, and the PLB rate
is 100 MHz.

Also, are there any estimates of how many loads can be added to PLB and/or
OPB at various rates?


Thanks,
/Mikhail



Article: 104323
Subject: Spartan3 or 3E pins to GND
From: "=?iso-8859-1?q?Jaime_Andr=E9s_Aranguren_Cardona?=" <jaime.aranguren@gmail.com>
Date: 23 Jun 2006 13:18:39 -0700
Links: << >>  << T >>  << A >>
Hi,

Is it possible to programmatically configure pins of an Spartan3 or 3E
as ground signals? I mean, not only configure them as input signals,
but as real ground signals connected to the ground signal on another
PCB.

Regards,

JaaC


Article: 104324
Subject: Re: keys to the Kingdom
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 24 Jun 2006 08:19:05 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Jim,
> 
> No, I have not cracked the Altera chip.  I have received emails from
> schools and universities who wish to crack it.  These are the same
> schools that have published successful smart card attacks.
> 
> My quote of $5,000 is what we pay to have a device ground down on the
> backside such that we can do analysis on a device.
> 
> For another $5,000, one can get up to three or four FIB cuts, and a
> couple of jumper wires.

..and here, you are still a long way from 'get at the IP'.. ?
- and rather a world away from your earlier sweeping claims...:

<paste classic Austin Arm Waving : >
> To have a press release that touts a "superior security solution" is the
> worst of the worst marketing.  To claim to be able to protect IP from
> ASSP vendors is quite honestly, false and misleading.  If I can get the
> IP that is a secret for less than $5,000, then I can clone the devices
> without paying anything at all.

No, wait, I _can_ see a false and misleading claim  :)

If you are going to rail against Altera, surely it helps to keep your 
credibility intact ?

-jg




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