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 104450

Article: 104450
Subject: Re: keys to the Kingdom
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Jun 2006 12:04:13 -0700
Links: << >>  << T >>  << A >>
Let's not quibble over the price tag, and whether $10,000 is a
meaningful hurdle.

The debate was about key security, and the consensus in the crypto
community is that things like efuses can be read out with moderate
effort, while battery-backed up SRAM data is either much more secure or
even perfectly secure, i.e. has never been cracked.

Some people think batteries are a pain, others think they are just fine
and last >15 years.

It's security vs convenience. Xilinx picked security, Altera picked
convenience.
The choice is yours. 
Peter Alfke, Xilinx Applications


Article: 104451
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: Sietse Achterop <sietse@cs.rug.nl>
Date: Tue, 27 Jun 2006 21:35:40 +0200
Links: << >>  << T >>  << A >>
mk wrote:
> In your code, I didn't see any decoding of the top 3 bits to enable
> one of the 8 rams to cover the whole 64k range. That's the reason it
> thinks all the memories are identical, you are using the same 13 bits
> to drive them. You should somehow differentiate them, probably with an
> enable signal generated from the top 3 bits (maybe you're doing that
> during the generation of read/write strobe?). Why it's removing the
> last 8k memory I am not sure as you are certainly driving the inputs;
> check the top level connectivity for reading the outputs of the memory
> into the core.

One moment I thought You had it, but alas.
To remove any doubt I used all 16 address bits in the decoding as in:

   int_ram_adr <= ram_adr_i(12 downto 0);

   p_read : process (clk)
   begin
     if rising_edge(clk) then
       if ram_adr_i(15 downto 13) = "000" then
         ram_data_o <= extram(conv_integer(int_ram_adr));
       else
         ram_data_o <= "00000000";
       end if;

     end if;
   end process p_read;


But apart from less warnings nothing changed.

   Sietse



Article: 104452
Subject: Re: keys to the Kingdom
From: David Brown <david@westcontrol.removethisbit.com>
Date: 27 Jun 2006 22:30:38 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Let's not quibble over the price tag, and whether $10,000 is a
> meaningful hurdle.
> 
> The debate was about key security, and the consensus in the crypto
> community is that things like efuses can be read out with moderate
> effort, while battery-backed up SRAM data is either much more secure or
> even perfectly secure, i.e. has never been cracked.
> 
> Some people think batteries are a pain, others think they are just fine
> and last >15 years.
> 
> It's security vs convenience. Xilinx picked security, Altera picked
> convenience.
> The choice is yours. 
> Peter Alfke, Xilinx Applications
> 

Any security system must be convenient, or it won't be used.  A hefty 
proportion of windows users have firewall software that came with their 
machines, but it's turned off - simply because it is too inconvenient. 
When it's enabled, the firewall keeps asking these daft questions about 
whether your programs are allowed to do this or that - it's far easier 
just to turn the stupid thing off.  An advanced application level 
software firewall may theoretically be more secure than a simple 
"incoming bad, outgoing good" firewall, but it's no help if people don't 
use it.

The same thing probably applies here.  I've no experience with either 
Altera's or Xilinx's solutions, but I can understand the principle that 
it's possible to read out efuses but not sram bits.  If Altera's 
solution is more convenient, then perhaps it is more secure in that 
developers are more likely to use it?  After all, all they need to do is 
choose some options in the software - there is no need to add batteries 
to the card, and to handle the support costs of dealing with lost keys 
(users are so imaginative - "I took out the battery to make sure the 
card got a proper reset").

As to how secure Altera's solution is - the Altera guys are not idiots, 
and it is unbecoming of you to them as such.  Sure, it's possible to 
read out the efuses in theory, but my guess is you're going to have to 
do a lot more than just a couple of $5000 rounds.  I'm sure there are 
theoretical methods of breaking Xilinx's security too, such as probing 
the bit stream out of the decoder.  Since you have to get access to the 
device while power is on, it's going to be difficult - but I'm sure it 
can be done given enough time and money (and boards to practise on).  To 
be secure, all a method has to do is raise the stakes high enough that 
alternative methods are cheaper - once it is easer and cheaper to bribe 
the original engineers for a copy of the code, the device is secure enough.

Article: 104453
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: "Nathan Bialke" <nathan.bialke@gmail.com>
Date: 27 Jun 2006 13:50:36 -0700
Links: << >>  << T >>  << A >>
> After designing the Aurora protocol and implementing it, I want to
> access the data values using my PC.

I am not really sure what you are trying to do. Are you trying to route
the output of the transceiver to a RS232 UART? If so, even if you
managed to do so, it wouldn't be very useful; there's no way
multi-gigabit data rates can be sustained over RS232 (or multi-megabit,
for that matter!). Are you trying to send data values to both the MGT
and to the RS232 UART? If so, you will have to deal with the difference
in speed between the two. However, if you can live with that that,
coding a UART in HDL isn't too hard.

- Nathan


Article: 104454
Subject: Re: keys to the Kingdom
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Jun 2006 14:00:11 -0700
Links: << >>  << T >>  << A >>

David Brown wrote:
> >
> As to how secure Altera's solution is - the Altera guys are not idiots,
> and it is unbecoming of you to them as such.

David, you should be ashamed of yourself for that dumb statement.
I did the opposite, I confirmed earlier that they desigend their logic
and algorithm correctly, and explained then that they chose a different
optimization, convenience over security.

To tell me what is "unbecoming" is a baseless insult. 
Peter Alfke


Article: 104455
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 27 Jun 2006 14:06:35 -0700
Links: << >>  << T >>  << A >>
actually I just need to transmit the values on RS232 UART core. I am
not too bothered about the speed. I just want the values on the PC.
most of the RS232 UART cores(atleast the one on the opencores.org site
and one referenced by the HERON IP ) do not tell how the data is
visible in the terminal program. I have now two VHDL projects of the
RS232 but they don't work at least I don't see any data on the terminal
window.
So I am now considering sending the data to the PPC that will in turn
send it to the RS232 UART core..
Lemme know if anyone has had similar problems.
Thanks,
Vivek


Nathan Bialke wrote:
> > After designing the Aurora protocol and implementing it, I want to
> > access the data values using my PC.
>
> I am not really sure what you are trying to do. Are you trying to route
> the output of the transceiver to a RS232 UART? If so, even if you
> managed to do so, it wouldn't be very useful; there's no way
> multi-gigabit data rates can be sustained over RS232 (or multi-megabit,
> for that matter!). Are you trying to send data values to both the MGT
> and to the RS232 UART? If so, you will have to deal with the difference
> in speed between the two. However, if you can live with that that,
> coding a UART in HDL isn't too hard.
> 
> - Nathan


Article: 104456
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: Duane Clark <junkmail@junkmail.com>
Date: Tue, 27 Jun 2006 21:29:35 GMT
Links: << >>  << T >>  << A >>
Vivek Menon wrote:
> actually I just need to transmit the values on RS232 UART core. I am
> not too bothered about the speed. I just want the values on the PC.
> most of the RS232 UART cores(atleast the one on the opencores.org site
> and one referenced by the HERON IP ) do not tell how the data is
> visible in the terminal program. I have now two VHDL projects of the
> RS232 but they don't work at least I don't see any data on the terminal
> window.

You likely will need to convert the data to ASCII, if you want it to 
show up on a terminal. That is quite easy to do.


Article: 104457
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 27 Jun 2006 14:31:36 -0700
Links: << >>  << T >>  << A >>
No wonder the screen was blank..!!!
Duane Clark wrote:
> Vivek Menon wrote:
> > actually I just need to transmit the values on RS232 UART core. I am
> > not too bothered about the speed. I just want the values on the PC.
> > most of the RS232 UART cores(atleast the one on the opencores.org site
> > and one referenced by the HERON IP ) do not tell how the data is
> > visible in the terminal program. I have now two VHDL projects of the
> > RS232 but they don't work at least I don't see any data on the terminal
> > window.
>
> You likely will need to convert the data to ASCII, if you want it to
> show up on a terminal. That is quite easy to do.


Article: 104458
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 27 Jun 2006 14:44:27 -0700
Links: << >>  << T >>  << A >>
David,

Would you email me directly?

I'd like to send you the photomicrograph of a fuse that is a 1, and a 0.

Austin


David Brown wrote:
> Peter Alfke wrote:
>> Let's not quibble over the price tag, and whether $10,000 is a
>> meaningful hurdle.
>>
>> The debate was about key security, and the consensus in the crypto
>> community is that things like efuses can be read out with moderate
>> effort, while battery-backed up SRAM data is either much more secure or
>> even perfectly secure, i.e. has never been cracked.
>>
>> Some people think batteries are a pain, others think they are just fine
>> and last >15 years.
>>
>> It's security vs convenience. Xilinx picked security, Altera picked
>> convenience.
>> The choice is yours. Peter Alfke, Xilinx Applications
>>
> 
> Any security system must be convenient, or it won't be used.  A hefty
> proportion of windows users have firewall software that came with their
> machines, but it's turned off - simply because it is too inconvenient.
> When it's enabled, the firewall keeps asking these daft questions about
> whether your programs are allowed to do this or that - it's far easier
> just to turn the stupid thing off.  An advanced application level
> software firewall may theoretically be more secure than a simple
> "incoming bad, outgoing good" firewall, but it's no help if people don't
> use it.
> 
> The same thing probably applies here.  I've no experience with either
> Altera's or Xilinx's solutions, but I can understand the principle that
> it's possible to read out efuses but not sram bits.  If Altera's
> solution is more convenient, then perhaps it is more secure in that
> developers are more likely to use it?  After all, all they need to do is
> choose some options in the software - there is no need to add batteries
> to the card, and to handle the support costs of dealing with lost keys
> (users are so imaginative - "I took out the battery to make sure the
> card got a proper reset").
> 
> As to how secure Altera's solution is - the Altera guys are not idiots,
> and it is unbecoming of you to them as such.  Sure, it's possible to
> read out the efuses in theory, but my guess is you're going to have to
> do a lot more than just a couple of $5000 rounds.  I'm sure there are
> theoretical methods of breaking Xilinx's security too, such as probing
> the bit stream out of the decoder.  Since you have to get access to the
> device while power is on, it's going to be difficult - but I'm sure it
> can be done given enough time and money (and boards to practise on).  To
> be secure, all a method has to do is raise the stakes high enough that
> alternative methods are cheaper - once it is easer and cheaper to bribe
> the original engineers for a copy of the code, the device is secure enough.

Article: 104459
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: "Vivek Menon" <vivek.menon79@gmail.com>
Date: 27 Jun 2006 14:48:43 -0700
Links: << >>  << T >>  << A >>
does anybody have a function or package that converts data into ASCII??
Vivek Menon wrote:
> No wonder the screen was blank..!!!
> Duane Clark wrote:
> > Vivek Menon wrote:
> > > actually I just need to transmit the values on RS232 UART core. I am
> > > not too bothered about the speed. I just want the values on the PC.
> > > most of the RS232 UART cores(atleast the one on the opencores.org site
> > > and one referenced by the HERON IP ) do not tell how the data is
> > > visible in the terminal program. I have now two VHDL projects of the
> > > RS232 but they don't work at least I don't see any data on the terminal
> > > window.
> >
> > You likely will need to convert the data to ASCII, if you want it to
> > show up on a terminal. That is quite easy to do.


Article: 104460
Subject: Re: keys to the Kingdom
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 27 Jun 2006 14:55:48 -0700
Links: << >>  << T >>  << A >>
David,

As to convenience,  place a lithium coin cell on the pcb per the app
note.  Ask the software to generate a random key for you (or pick one
yourself), send the key to the JTAG port.  Verify the key can be written
and read, then write it in secure mode (so it can not be read out again
without it being erased immediately).  Program eeprom or other memory
with encrypted bitstream.

Done.

Not sure about Altera, as they have now told us they keep secrets from
even their customers, and you have to sign an NDA.  But, in theory, you
get a key (does their software generate random 128 bit keys?  Let us
suppose it does), program the part (How?  It is a secret! But let us
imagine it is as simple as JTAG), an then place encrypted design in the
memory.

Done.

So, we have one more step:  make sure their is a lithium coin cell on
the pcb connected to the Vbatt pin.

That is the total level of inconvenience we offer.

The benefit is that we offer all four levels of security in FIPS 140-2
compliance, and Altera offers no level of compliance at all with FIPS 140-2.

What is so important about FIPS 140-2?  It is the required security
standard for the US Federal government, as well as for banks, networks,
and others who are serious about security.

Don't need FIPS 140-2?  Then go ahead and use efuse keys.  But also be
aware of the risks.

As for reverse engineering, I can send you presentations of how efuse
technology smart cards are reverse engineered (hacked).  It is a junior
level EE project at most universities now.

Austin


David Brown wrote:
> Peter Alfke wrote:
>> Let's not quibble over the price tag, and whether $10,000 is a
>> meaningful hurdle.
>>
>> The debate was about key security, and the consensus in the crypto
>> community is that things like efuses can be read out with moderate
>> effort, while battery-backed up SRAM data is either much more secure or
>> even perfectly secure, i.e. has never been cracked.
>>
>> Some people think batteries are a pain, others think they are just fine
>> and last >15 years.
>>
>> It's security vs convenience. Xilinx picked security, Altera picked
>> convenience.
>> The choice is yours. Peter Alfke, Xilinx Applications
>>
> 
> Any security system must be convenient, or it won't be used.  A hefty
> proportion of windows users have firewall software that came with their
> machines, but it's turned off - simply because it is too inconvenient.
> When it's enabled, the firewall keeps asking these daft questions about
> whether your programs are allowed to do this or that - it's far easier
> just to turn the stupid thing off.  An advanced application level
> software firewall may theoretically be more secure than a simple
> "incoming bad, outgoing good" firewall, but it's no help if people don't
> use it.
> 
> The same thing probably applies here.  I've no experience with either
> Altera's or Xilinx's solutions, but I can understand the principle that
> it's possible to read out efuses but not sram bits.  If Altera's
> solution is more convenient, then perhaps it is more secure in that
> developers are more likely to use it?  After all, all they need to do is
> choose some options in the software - there is no need to add batteries
> to the card, and to handle the support costs of dealing with lost keys
> (users are so imaginative - "I took out the battery to make sure the
> card got a proper reset").
> 
> As to how secure Altera's solution is - the Altera guys are not idiots,
> and it is unbecoming of you to them as such.  Sure, it's possible to
> read out the efuses in theory, but my guess is you're going to have to
> do a lot more than just a couple of $5000 rounds.  I'm sure there are
> theoretical methods of breaking Xilinx's security too, such as probing
> the bit stream out of the decoder.  Since you have to get access to the
> device while power is on, it's going to be difficult - but I'm sure it
> can be done given enough time and money (and boards to practise on).  To
> be secure, all a method has to do is raise the stakes high enough that
> alternative methods are cheaper - once it is easer and cheaper to bribe
> the original engineers for a copy of the code, the device is secure enough.

Article: 104461
Subject: Preserve patent materials through a notary
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 27 Jun 2006 15:40:19 -0700
Links: << >>  << T >>  << A >>
Hi,
I read some books describing that preservation of patent ideas through
a notary is valid in the law.

Yesterday we put all patent materials into a large envelop and went to
a notary to seal it. A lawyer in the notary put notary stamps on all
papers and sealed the envelop properly with stamps too. What surprised
us is there is no date!!! There are no date stamps like a register
letter that must have a date stamp on the envelop. There is no receipt
neither.

What does It prove? What I need is a date a patent law court admits.
But here there is no date. What is wrong? What should I do next?

Thank you.

Weng


Article: 104462
Subject: Re: PicoBlaze and DDR Ram
From: "karrelsj" <karrelsj@gmail.com>
Date: 27 Jun 2006 17:00:14 -0700
Links: << >>  << T >>  << A >>
Thanks for everyones comments.  Anyone have any suggestions on getting
started monkeying around with RAM controllers?  I didn't have picoblaze
in mind for a specific task, rather just playing around getting my feet
wet.  I would like to work with a basic setup to start out.  Load
program data from RAM, and then advance into modifying a controller to
decrypt data as it brings it it.

Anyone have any good starting points to "ease" me into this world.
Implementing a RAM controller tutorial...

Thanks


Jim Granville wrote:
> karrelsj wrote:
> > Hello.
> >
> > I just started looking at Picoblaze.  Has anyone completed a Picoblaze
> > and DDR RAM implementation?  Or does anyone have any strong opinions on
> > this issue.  My main goal is to store program data on RAM and access it
> > with Picoblaze. I see OpenCores has a DDR/SDRAM controller...
> >
> > Thanks for your constructive ideas.
>
>   Do you mean a large data-space in DDR, and that the PicoBlaze runs from
> Block Ram in the FPGA ?
>   That would be do-able, and you could add features like the Serial FLASH
> devices have, which is auto-inc of Rd/Wr address, for continual access.
> ( that saves a lot of address thrashing )
>
>   If you needed more code, two bock RAMS, with reload-flip support in
> the FPGA, would allow the DDR behave like a HardDisk (from
> the code perspective).
> 
> What split and sizes do you need for Code/data ?
> 
> -jg


Article: 104463
Subject: Re: RS232 to access TX registers of Aurora using PPC (EDK)
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 28 Jun 2006 00:16:25 GMT
Links: << >>  << T >>  << A >>
Vivek Menon wrote:
> does anybody have a function or package that converts data into ASCII??

You send one nibble (4 bits) at a time. If the nibble is between 0-9, 
then add 0x30 (hex 30). If between a-f, add 0x60. It should be easy to 
figure out how to do that in VHDL/Verilog. That will give you a hex display.

Article: 104464
Subject: X-Ray Inspection System
From: zhanglingmu@gmail.com
Date: 27 Jun 2006 18:36:44 -0700
Links: << >>  << T >>  << A >>
We are specialize in the supply, installation, commissioning and
servicing of a range of industrial X-Ray Inspection System for the
electronics/semiconductor industries
PCB MLB : Inspect the drill hole
PCB panels : Excessive solder, insufficient solder,
 misalignment, and void
BGA : Bridge/Short, excessive solder, insufficient solder
CSP : Deformity
Filp Chip : Bridge/ Short
Lithium ion battery : Bridge/ Short. .
welcome to contact us:
email: zhanglingmu@gmail.com
Tel: (65)93887563
315 Outram Road Tan Boon Liat Building
Singapore 169074


Article: 104465
Subject: Re: JTAG - Boundary Scan s/w using Byteblaster or Parallel 4 cable
From: "fpgaguy" <junosnh@juno.com>
Date: 27 Jun 2006 20:40:49 -0700
Links: << >>  << T >>  << A >>

Kolja Sulimma wrote:
> Fred schrieb:
> > Does anyone know of any software, ideally freeware, which can use the above
> > JTAG interfaces to exercise other JTAG interfaces on non FPGA devices?
> >
> > In my case I'd like to read the state of pins on an unrelated device.
>
> There is JTAG code in the not very active open source project "open wince".
>
> Kolja

I use http://www.intellitech.com/products/schematiclogicprobe.asp
which lets me toggle pins with a view of the schematic - if netlist
avaialble..    It works both with Xilynx Pciii/pc4 and altera
byteblaster (no USB though).   they have all the FPGA device JTAG files
(bsdl) in their libraries.

you can get a 90 day eval license and I just renew the eval license.
They don't seem to care, i've renewed six times.  I think they are
interested in bigger fish and not their main business.

Kim


Article: 104466
Subject: PLB IPIF Master Read Failure
From: andrewgschmidt@gmail.com
Date: 27 Jun 2006 23:20:56 -0700
Links: << >>  << T >>  << A >>
I have been reading everyone's comments on how to setup a Master Read,
but I have hit a wall.  I can make the Read Request, but nothing seems
to happen after that.  I never get a write request to my slave.
I am asserting these signals in my master:
        IP2Bus_MstRdReq  <= '1';
        IP2Bus_Addr      <= mst_ip2bus_addr;
        IP2IP_Addr       <= mst_ip2ip_addr;
        IP2Bus_MstNum    <= "00001";
        master_ns        <= read_ddr;
* Where mst_ip2bus_addr and mst_1p2ip_addr are set in the slave state
machine.  Any known bugs with the PLB IPIF or things people maybe did
to get around this issue?  Thanks.


Article: 104467
Subject: Spartan3e starter kit vga mod
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Wed, 28 Jun 2006 07:05:53 GMT
Links: << >>  << T >>  << A >>
I have added some notes to www.fpgaarcade.com describing how to modify the 
Spartan kit board to have 12 bit RGB output on the VGA port.

Also included is some test pattern code / bitfile to produce some output.

/MikeJ 



Article: 104468
Subject: Re: is picoblaze worth in my project?
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 28 Jun 2006 02:39:05 -0500
Links: << >>  << T >>  << A >>
>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.

In general, if you can easily turn a hardware problem into software,
that's probably the right thing to do.

How many states will your system have?  Will a circles and arrows
drawing of your state machine fit on a page?  For anything bigger
than a page, I try hard to turn it into software.  I find it much
easier to deal with a complicated problem when thinking of it
as software.

Do you have lots of multi way branches?  Do you have enough time
to turn them into a chain of two way branches?  ...

The main disadvantage of using software is that you have to
setup and maintain a software development environment in addition
to your FPGA environment.  That's usually a lot easier after you
have done it the first time.

Another answer is to do (or try) both and see which one you like better.



-- 
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: 104469
Subject: Re: Achieving timing in Xilinx EDK designs
From: Andi <00andi@web.de>
Date: Wed, 28 Jun 2006 02:56:25 -0700
Links: << >>  << T >>  << A >>
We have a XC2VP40 with 98% silce utilization. The System contains a PPC405 300 MHz with PLB 100 Mhz and OPB 50 Mhz. On PLB side we have - plb sdram - plb emac - plb bram - plb dma ctrl ( own core) - plb user core 1 ( own core ) - plb user core 2 ( own core )

And i do not have any timing problems with ISE 8.1 and EDK 8.1. The flow needs quit a "long" time. But in the end i have (0) timing errors without planahead.

Andi

Article: 104470
Subject: Re: keys to the Kingdom
From: David Brown <david@westcontrol.removethisbit.com>
Date: 28 Jun 2006 12:13:40 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> David Brown wrote:
>> As to how secure Altera's solution is - the Altera guys are not idiots,
>> and it is unbecoming of you to them as such.
> 
> David, you should be ashamed of yourself for that dumb statement.
> I did the opposite, I confirmed earlier that they desigend their logic
> and algorithm correctly, and explained then that they chose a different
> optimization, convenience over security.
> 
> To tell me what is "unbecoming" is a baseless insult. 
> Peter Alfke
> 

I apologise for being insulting - that was not my intention.  I felt 
your earlier reply to Dave Greenfield, including "Yes, Altera can do 
logic design. Bravo! Advance to second grade!", was intentionally 
patronising, and lowering the tone of the thread (which is interesting). 
  Unfortunately, the context of that post was dropped from the thread 
(by you), so my comment appeared out of the blue - I should have made it 
in an appropriate branch.  And yes, I did read your other comments on 
the two security solutions - it was the contrast between your normal 
technical, informative and (reasonably) objective comments and that 
sarcastic dig at Dave Greenfield and Altera that annoyed me.

Article: 104471
Subject: Re: keys to the Kingdom
From: David Brown <david@westcontrol.removethisbit.com>
Date: 28 Jun 2006 12:40:52 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> David,
> 
> As to convenience,  place a lithium coin cell on the pcb per the app
> note.  Ask the software to generate a random key for you (or pick one
> yourself), send the key to the JTAG port.  Verify the key can be written
> and read, then write it in secure mode (so it can not be read out again
> without it being erased immediately).  Program eeprom or other memory
> with encrypted bitstream.
> 
> Done.
> 
> Not sure about Altera, as they have now told us they keep secrets from
> even their customers, and you have to sign an NDA.  But, in theory, you
> get a key (does their software generate random 128 bit keys?  Let us
> suppose it does), program the part (How?  It is a secret! But let us
> imagine it is as simple as JTAG), an then place encrypted design in the
> memory.
> 
> Done.
> 
> So, we have one more step:  make sure their is a lithium coin cell on
> the pcb connected to the Vbatt pin.
> 
> That is the total level of inconvenience we offer.
> 

Peter Alfke referred to Altera's solution as being more biased towards 
convenience, while Xilinx's was more biased towards security.  Since 
Peter knows a great deal more than me about both security systems, I 
assume that the difference in convenience is relevant (unless, of 
course, he was referring to convenience for Altera rather than for the 
customer).

At the moment, and for the foreseeable future, I am not using either 
Altera or Xilinx's bigger devices, and I am not overly concerned about 
security.  And I'm sure that if I did need such a design, then the 
inconvenience of having a battery would not stop me using Xilinx - other 
factors are more important.


> The benefit is that we offer all four levels of security in FIPS 140-2
> compliance, and Altera offers no level of compliance at all with FIPS 140-2.
> 
> What is so important about FIPS 140-2?  It is the required security
> standard for the US Federal government, as well as for banks, networks,
> and others who are serious about security.
> 
> Don't need FIPS 140-2?  Then go ahead and use efuse keys.  But also be
> aware of the risks.
> 

The risks must be balanced, and it's important to know them (I don't, 
obviously, but I've never needed to know).  What's important is to 
protect the IP, which means increasing the costs until it is impractical 
for someone to steal it.  You don't need a zero risk solution, you need 
something with a risk that is known to be low enough.  I presume that 
Altera will give customers more detailed information when necessary - 
although I think the Xilinx-style openness is better.

> As for reverse engineering, I can send you presentations of how efuse
> technology smart cards are reverse engineered (hacked).  It is a junior
> level EE project at most universities now.
> 

I'm following this thread out of interest, and not from a need of 
detailed knowledge.  If you have public links of interest to others 
here, post them here - others have questioned the accuracy of your 
numbers and might like to see examples.  It would of course be 
interesting to hear Altera's viewpoint as well.

As for sending anything directly to me - I appreciate the offer, but 
there is no need, and it would be a waste of your time.  Newsgroup posts 
benefit more people.

mvh.,

David


> Austin
> 
> 
> David Brown wrote:
>> Peter Alfke wrote:
>>> Let's not quibble over the price tag, and whether $10,000 is a
>>> meaningful hurdle.
>>>
>>> The debate was about key security, and the consensus in the crypto
>>> community is that things like efuses can be read out with moderate
>>> effort, while battery-backed up SRAM data is either much more secure or
>>> even perfectly secure, i.e. has never been cracked.
>>>
>>> Some people think batteries are a pain, others think they are just fine
>>> and last >15 years.
>>>
>>> It's security vs convenience. Xilinx picked security, Altera picked
>>> convenience.
>>> The choice is yours. Peter Alfke, Xilinx Applications
>>>
>> Any security system must be convenient, or it won't be used.  A hefty
>> proportion of windows users have firewall software that came with their
>> machines, but it's turned off - simply because it is too inconvenient.
>> When it's enabled, the firewall keeps asking these daft questions about
>> whether your programs are allowed to do this or that - it's far easier
>> just to turn the stupid thing off.  An advanced application level
>> software firewall may theoretically be more secure than a simple
>> "incoming bad, outgoing good" firewall, but it's no help if people don't
>> use it.
>>
>> The same thing probably applies here.  I've no experience with either
>> Altera's or Xilinx's solutions, but I can understand the principle that
>> it's possible to read out efuses but not sram bits.  If Altera's
>> solution is more convenient, then perhaps it is more secure in that
>> developers are more likely to use it?  After all, all they need to do is
>> choose some options in the software - there is no need to add batteries
>> to the card, and to handle the support costs of dealing with lost keys
>> (users are so imaginative - "I took out the battery to make sure the
>> card got a proper reset").
>>
>> As to how secure Altera's solution is - the Altera guys are not idiots,
>> and it is unbecoming of you to them as such.  Sure, it's possible to
>> read out the efuses in theory, but my guess is you're going to have to
>> do a lot more than just a couple of $5000 rounds.  I'm sure there are
>> theoretical methods of breaking Xilinx's security too, such as probing
>> the bit stream out of the decoder.  Since you have to get access to the
>> device while power is on, it's going to be difficult - but I'm sure it
>> can be done given enough time and money (and boards to practise on).  To
>> be secure, all a method has to do is raise the stakes high enough that
>> alternative methods are cheaper - once it is easer and cheaper to bribe
>> the original engineers for a copy of the code, the device is secure enough.

Article: 104472
Subject: Re: Once synthesized RAMs are vanishing in WebPACK 8.1i03
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Wed, 28 Jun 2006 12:05:07 +0100
Links: << >>  << T >>  << A >>
Sietse,,
you are right my mystake, 13 address lines makes 8K locations (sorry for 
the confusion)
anyway I synthesized your original code with ISE8.2 and works fine for me.

Device utilization summary:
---------------------------

Selected Device : 3s100evq100-5

 Number of Slices:                       0  out of    960     0% 
 Number of IOs:                         35
 Number of bonded IOBs:                 31  out of     66    46% 
 Number of BRAMs:                        4  out of      4   100% 
 Number of GCLKs:                        1  out of     24     4% 

____________________
Can you please run XST for this file only (in isolation) to see if you 
get the expected results

Aurelian

Sietse Achterop wrote:

> Aurelian Lazarut wrote:
>
>> to be more precise you have:
>> int_ram_adr <= ram_adr_i(12 downto 0);
>>
>> what about ram_adr_i(15 downto 13) who's driving them ?
>>
>> Aurash
>>
>> Aurelian Lazarut wrote:
>>
>>> you have a 8K memory but it seems from the log file that you are not 
>>> using the all the address bits,
>>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>> which means that you basically need only 1K from the total of 8K and 
>>> XST remove the rest, I think this make sense if you keep these 
>>> addresses tied to a constant.
>>> Aurash
>>
>
>    Hello Aurash,
>
> thanks for the prompt reply.
>     (the 8KB memory serves as the external RAM of the 8051)
> But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16 
> address bits and only 13 bits for the lower 8 KB are used.
> Or better, the 8KB is repeated 8 times in the 64KB address space.
> So all 13 address lines for the RAM are used, and I don't see why
> it is optimized away.
>
>   Sietse



-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 104473
Subject: Help in the platform studio(EDK)
From: "subint" <subin.82@gmail.com>
Date: 28 Jun 2006 04:19:16 -0700
Links: << >>  << T >>  << A >>
Hi,
Is there is any one who can help me in the SDK.Is it possible to modify
the sdk generated code?
regards
subin
subint wrote:
> Hi,
> I am using the platform studio first time.I like to know how i can add
> my testbenches and remove the microblaze processor from the setup.
>        I am trying to generate the controller for my V4MB lx60 board
> and i want to test the ddr in the board.From the tool(platform studio)
> i can select the pheripherals and the processor etc but didnt have any
> idea how can i use this to test my ddr.I tried to generate the hdl
> code.But all the controllers are ipcores(black box) and i wont be able
> to synthesize it using xilinx ise(library for these ipcores are
> missing).
> regards
> subin


Article: 104474
Subject: Re: Preserve patent materials through a notary
From: "Gabor" <gabor@alacron.com>
Date: 28 Jun 2006 05:45:16 -0700
Links: << >>  << T >>  << A >>
You don't say where you had your documents notarized, but I know
that when I get a document notarized in New Hampshire, the notary
enters the description in a log book, which certainly has dates.

I would suggest that you enter a date next to your signature yourself
when the documents are notarized.  The notary stamp indicates that
the signing and dating was witnessed by a reliable person and a
record kept of this witnessing.

HTH
Gabor

Weng Tianxiang wrote:
> Hi,
> I read some books describing that preservation of patent ideas through
> a notary is valid in the law.
>
> Yesterday we put all patent materials into a large envelop and went to
> a notary to seal it. A lawyer in the notary put notary stamps on all
> papers and sealed the envelop properly with stamps too. What surprised
> us is there is no date!!! There are no date stamps like a register
> letter that must have a date stamp on the envelop. There is no receipt
> neither.
>
> What does It prove? What I need is a date a patent law court admits.
> But here there is no date. What is wrong? What should I do next?
> 
> Thank you.
> 
> Weng




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