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 73825

Article: 73825
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 29 Sep 2004 21:25:36 -0400
Links: << >>  << T >>  << A >>
> > If you check out the syn directory in that archive it lists the
> > sythesis results for various FPGA's. What is interesting is the
> > frequency of operation in a Xilinx device is >3X the Altera device.
>
> If you look closer you'll see that the Altera devices used are pretty
> old...

Very old.  In this case, the best Altera part used is an EP20K100TC144-3 -- 
an original APEX 20K part, in the slowest speed grade.  That product was
manufactured at 0.25u technology.  It is being compared to a XC2V80CS144-6,
which IIRC is a 0.15u/0.13u hybrid, and is the fastest available Virtex-II
speed grade to boot.

QUICK REMINDER:  Altera numbers speed grades such that lower = faster.
Xilinx numbers things so higher = faster.

Also, I should point out that the reported speeds appear to be based on
synthesis estimates -- you really need to run place & route before you can
ever compare results between two architectures.  Synthesis performance
estimates give you a reasonable idea of how changes in a given design affect
its performance, and they *should* be tuned to give the right answer on
average over a large set of designs.  But on any given design there's no
guarantee the estimate will be close to the final P&R value, and there are
both systematic design-specific and completely random components to this
error.  In short, comparing post-synthesis Fmax across two chips on one
design is quite inaccurate.

As other users have pointed out, this core may also be optimized towards
Xilinx like architectures.  I have not looked at it and thus do not know if
this is the case.

Regards,

Paul Leventis
Altera Corp.




Article: 73826
Subject: Re:ELABORATED DISCLOSURE and continued discussion : NV on-chip memory?
From: "Guy" <guys@altera.com>
Date: Thu, 30 Sep 2004 01:29:24 GMT
Links: << >>  << T >>  << A >>
I thought I was being clear when I said not to assume I was affiliated with
Altera.  So to be clear about it, I am not employed by Altera nor do I have
the ability to know whether they are considering or Analyzing NV memory for
use in their FPGAs.  Unfortunately, when creating my original post, I did
not realize nor intend for the Altera email address to have been posted I
simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I
did not remember since it has been a long time since using Google to post
(rather than other more anonymous methods).  This lead to my reason for
disclosure.



As an FPGA industry veteran,  I am however very interested in continued
market research and discussions, which I hope you will agree, can be
beneficial to all FPGA users to create and provide vendors feedback.



AUSTIN-

You have made assumptions in your postings/responses with respect to
security.  I never mentioned the word government or any of their standards.
You have assumed once again.  Shame on you again? - Just kidding.  Anyway,
the link you provided to the xilinx website was informative
(http://tinyurl.com/496n2).



A couple of comments:

In one of my earlier posts, I did not include other options when mentioning
NV memories in SRAM fpgas, I should have included battery backed SRAM, Fuse
based methods for Key storage, distributed polygon approaches and likely
others.



One of the most important points the Xilinx link makes which Austin
neglected in his assumption that Security is no less than 100%, is the
tradeoff of security with cost.  While I did say that it was undetectable, I
did not say it was suitable for government applications (another
assumption).   So, the implication in the original posting is that there
would be a very low cost NV solution that would be super costly to reverse
engineer (order(s) of magnitude more difficult that Flash or even Antifuse)
providing a significantly lower cost solution for those non-government
applications needing high security than the solutions that Altera or Xilinx
currently offer.



A decent article talking about security from a practical perspective:
http://www.algotronix.com/content/security%20FPL%202001.pdf



Also, now coming back to government, although I am not familiar with the
specific published requirements (I add that due diligence to my to-do list),
I do believe security has been moving target with rising requirements even
for government./?   So, just as Austin says that there might be ways to
detect and capture the Volatile SRAM stored KEY thus enabling the cracking
of governement data stream there is a level of probability and cost function
involved that is the current governement requirement.  I'll bet that this
requirement and cost function will continue rise in time.



Austin - Why is it impossible to believe that a new NV memory technology can
actually exceed this probability / cost function of detecting the stored
volatile key?





As for Paul's comparison to Max II - I really do not see very many parallels
to the bulk of the discusson in this thread regarding applications for the
NV on chip memory.  Max II does have NV memory and can potentially integrate
an external solution.  I am trying to emphasize that much of this thread is
beyond that - especially with respect to larger data storage and other NV
needs (like that of  secure processor code).





More discussion?

Thanks.









"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
news:0LqdnVRXQ4PYyMbcRVn-vA@rogers.com...
> > That's a disclosure ?
> > Q: Do you work for Altera, or are affiliated with Altera ?
>
> My guess is no, this Guy guy does not work for Altera.  If he does, it's
the
> first I've heard of him and he is violating Altera posting protocol by not
> clearly stating his affiliation in each posting.  His email address is
also
> not in the format of an altera address for someone with the name Guy, and
> besides it bounces.
>
> > Q: Are Altera considering/analysing NV memory in FPGA ?
>
> We have Non-Volitile memory in our MAX II CPLD family.  A Flash block is
> used to store the device configuration program.  We also expose 8 Kb of
> Flash memory for use by the user -- for example, to absorb functions
> normally stored in off-chip serial eproms, such as a device serial number.
>
> I cannot comment on whether or not we are considering it for future FPGA
> families, except to say I doubt we would conduct market research in a
public
> forum such as this.  We typically talk to all of our big customers to get
> feedback on family plans, and this is done under NDA.
>
> Regards,
>
> Paul Leventis
> Altera Corp.
>
>




Article: 73827
Subject: Re: DISCLOSURE : NV on-chip memory?
From: austin <austin@xilinx.com>
Date: Wed, 29 Sep 2004 18:42:01 -0700
Links: << >>  << T >>  << A >>
All,

I was fooled by this posting.

Any comments I made should not in any way reflect on Altera, as the 
poster is obviously masquerading as someone who is.

I am mostly angry with myself that I reacted the way I did.

This is the second time I have been fooled (by a fake Altera poster)! 
RATS.  I should know better, as Paul, and only a select few post on 
comp.arch.fpga from Altera.

I apologize to the newsgroup.

Austin (also from home, but over the vpn network)

Paul Leventis (at home) wrote:

>>That's a disclosure ?
>>Q: Do you work for Altera, or are affiliated with Altera ?
> 
> 
> My guess is no, this Guy guy does not work for Altera.  If he does, it's the
> first I've heard of him and he is violating Altera posting protocol by not
> clearly stating his affiliation in each posting.  His email address is also
> not in the format of an altera address for someone with the name Guy, and
> besides it bounces.
> 
> 
>>Q: Are Altera considering/analysing NV memory in FPGA ?
> 
> 
> We have Non-Volitile memory in our MAX II CPLD family.  A Flash block is
> used to store the device configuration program.  We also expose 8 Kb of
> Flash memory for use by the user -- for example, to absorb functions
> normally stored in off-chip serial eproms, such as a device serial number.
> 
> I cannot comment on whether or not we are considering it for future FPGA
> families, except to say I doubt we would conduct market research in a public
> forum such as this.  We typically talk to all of our big customers to get
> feedback on family plans, and this is done under NDA.
> 
> Regards,
> 
> Paul Leventis
> Altera Corp.
> 
> 

Article: 73828
Subject: Re: MicroBlaze is now available as Open-Source!! (from independant 3rd party)
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 30 Sep 2004 02:19:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <2s0n6qF1f8t1eU1@uni-berlin.de>
By author:    "Symon" <symon_brewer@hotmail.com>
In newsgroup: comp.arch.fpga
>
> In case people start targeting MicroBlaze and its tools at vendor A's parts?
> ;-)
> Maybe not!
> Syms.
> 

Well, having an open implementation would reduce (although probably
not eliminate) vendor lock-in.

Some vendors like lock-in; users usually don't.  This, of course, can
work in reverse: "Well, we'd rather use vendor X right now because we
know there is a migration path from X to A if we should need it, and
we can use an optimized design for X."

	-hpa

Article: 73829
Subject: Re: ELABORATED DISCLOSURE and continued discussion : NV on-chip memory?
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Sep 2004 02:45:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <UjJ6d.4414$nj.1325@newssvr13.news.prodigy.com>,
Guy <guys@altera.com> wrote:
>I thought I was being clear when I said not to assume I was affiliated with
>Altera.  So to be clear about it, I am not employed by Altera nor do I have
>the ability to know whether they are considering or Analyzing NV memory for
>use in their FPGAs.  Unfortunately, when creating my original post, I did
>not realize nor intend for the Altera email address to have been posted I
>simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation I
>did not remember since it has been a long time since using Google to post
>(rather than other more anonymous methods).  This lead to my reason for
>disclosure.

This seems a shallow excuse, as you are STILL posting with a forged
altera address in the from line.  

If I was an altera lawyer, I'd already have the subpoena to google in
the mail...


Oh, and just to respond to the rest of the post:

Some standards exist for a very good reason.

AES in an FPGA is ~500-1000 slices, 10 BlockRAMs, and ~10 cycles at >50 MHz
in a "soft" core.

Thus, for medium-medium high security applications, using the SRAM
based bitfile encryption as the security keystone costs 1 Litium cell,
~1000 slices, and 10 BlockRAMs.  

Hardly a huge expense, and a significant win over nonvolatile cells.
Especially since the battery itself can be used to form a nice bit of
potting/intrusion detection as an additional bit of security.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73830
Subject: Re: embedded linux on FPGA?
From: hamilton <hamilton@deminsional.com>
Date: Wed, 29 Sep 2004 20:57:30 -0600
Links: << >>  << T >>  << A >>


T Lee wrote:
> 
> Forth is very good for small embedded design.
> 
> -Tony

Forth is the perfect hacker language.
Write it once and no one else will able to read it again.

Every time I follow up on a forth project, I have to re-write it in C
so it can be read by future programmers.

Sorry Tony, I just don't by it.

hamilton AT dimensional DOT com


Article: 73831
Subject: Re: Xilinx Timing Constraints
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 29 Sep 2004 19:58:36 -0700
Links: << >>  << T >>  << A >>
OK well how do you apply a restraint to a path then?



Article: 73832
Subject: Xilinx SRL16 test
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 29 Sep 2004 20:05:52 -0700
Links: << >>  << T >>  << A >>
OK. What is wrong with this code?  I am expecting to initiate the SRL16 with
some sort of pattern, then loop it around continuously in a 10 bit pattern,
put it to a pad where I can see it with a scope.  I get a one little blip
but not much.


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity srltest is
 port(
 clk : in std_ulogic;
 q   : out std_ulogic );
end srltest;

architecture Behavioral of srltest is

 component SRL16
 -- synthesis translate_off
 generic (
 INIT: bit_value:= X"1001");
 -- synthesis translate_on
 port (Q : out STD_ULOGIC;

 A0 : in STD_ULOGIC;
 A1 : in STD_ULOGIC;
 A2 : in STD_ULOGIC;
 A3 : in STD_ULOGIC;
 CLK : in STD_ULOGIC;
 D : in STD_ULOGIC);
 end component;
 -- Component Attribute specification for SRL16
 -- should be placed after architecture declaration but
 -- before the begin keyword
 -- Enter attributes in this section
 -- Component Instantiation for SRL16 should be placed
 -- in architecture after the begin keyword

 signal feedback : std_ulogic;

begin

 SRL16_INSTANCE_NAME : SRL16
 -- synthesis translate_off
 generic map(
 INIT => X"7878" )
 -- synthesis translate_on
 port map (Q => feedback ,
 A0 => '0',
 A1 => '1',
 A2 => '0',
 A3 => '1',
 CLK => clk,
 D => feedback );

 q <= feedback;

end Behavioral;



Article: 73833
Subject: Re: Chipscope Pro and VHDL
From: "Antti Lukats" <antti@case2000.com>
Date: Wed, 29 Sep 2004 20:10:10 -0700
Links: << >>  << T >>  << A >>

<Vivek> wrote in message news:ee8920f.-1@webx.sUN8CHnE...
> I was reading the manuals for Chipscope Pro and I am a bit confused. Does
ChipScope Pro generate some sort of VHDL block that you place in your design
and connect the appropriate signals to?
>
> Or does it generate some vhdl code which you paste into a block?
>
> I am using chipscope pro 6.2i. If anyone has information in regards to
this, pleas elet me know. Thanks
>
> Vivek

not quite but close, CS core gen generates edif files that you can use in
verilog vhdl or schematics core inserter insertst the cores directly to
netlist so you would not see them at all.

coregen generates example files that provide the template you must use to
access the cores.
you need to connect the control port(s) from icon to all the actual cores
and connect the signals and clock thats it

antti
ebook.openchip.org



Article: 73834
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: Ken McElvain <ken@synplicity.com>
Date: Wed, 29 Sep 2004 20:21:32 -0700
Links: << >>  << T >>  << A >>
Since you have a ".edu" address it might be that you
want it for an educational cause.   If so, then the
price will be a small flat fee for a bunch of copies.

Nicholas Weaver wrote:
> I need ASAP the pricing information for Synplify Pro for Xilinx, for
> budgetary placeholder info.
> 
> Anyone know where to find this?  Thanks.
> 
> 
> 


Article: 73835
Subject: Re: ELABORATED DISCLOSURE and continued discussion : NV on-chip memory?
From: "Guy" <guys@altera.com>
Date: Thu, 30 Sep 2004 03:38:43 GMT
Links: << >>  << T >>  << A >>
Nicholas -
First, I have made my disclosure which unfortunately was taking 3-9 hours to
post by Google which exacerbated this whole thread - sorry.  I will continue
under this
Moniker until the end of this thread at which point I will move on to a new
user name.  I attempt to remain anonymous for now as have many individuals
on news groups do for various reasons.



Anyways, I did not understand your point about the cost of a standard
solution for AES solution.  That was my whole point that potentially using a
huge cost of detection NV technology would save costs in different ways:  on
chip NV configuration storage reducing system costs (battery, cpld, external
config data).



As far as security for Key storageI did say there weren't alternatives that
already exist, I was exploring the benefits of this new alternative.  Then
the conversation moved to other secure data storage.  AES is current, before
it were many other encryption standards, as time marches on, Secure becomes
a non-absolute changing value.  I am posing an alternative that might
provide an equal or greater cost function of obtaining a stored Key than
volatile/battery SRAM etc.



Thanks.





"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:cjfs04$25cm$1@agate.berkeley.edu...
> In article <UjJ6d.4414$nj.1325@newssvr13.news.prodigy.com>,
> Guy <guys@altera.com> wrote:
> >I thought I was being clear when I said not to assume I was affiliated
with
> >Altera.  So to be clear about it, I am not employed by Altera nor do I
have
> >the ability to know whether they are considering or Analyzing NV memory
for
> >use in their FPGAs.  Unfortunately, when creating my original post, I did
> >not realize nor intend for the Altera email address to have been posted I
> >simply thought it was a log-in procedure, a GOOGLE NEWS GROUP limitation
I
> >did not remember since it has been a long time since using Google to post
> >(rather than other more anonymous methods).  This lead to my reason for
> >disclosure.
>
> This seems a shallow excuse, as you are STILL posting with a forged
> altera address in the from line.
>
> If I was an altera lawyer, I'd already have the subpoena to google in
> the mail...
>
>
> Oh, and just to respond to the rest of the post:
>
> Some standards exist for a very good reason.
>
> AES in an FPGA is ~500-1000 slices, 10 BlockRAMs, and ~10 cycles at >50
MHz
> in a "soft" core.
>
> Thus, for medium-medium high security applications, using the SRAM
> based bitfile encryption as the security keystone costs 1 Litium cell,
> ~1000 slices, and 10 BlockRAMs.
>
> Hardly a huge expense, and a significant win over nonvolatile cells.
> Especially since the battery itself can be used to form a nice bit of
> potting/intrusion detection as an additional bit of security.
> -- 
> Nicholas C. Weaver.  to reply email to "nweaver" at the domain
> icsi.berkeley.edu



Article: 73836
Subject: Re: ELABORATED DISCLOSURE and continued discussion : NV on-chip
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 30 Sep 2004 16:01:25 +1200
Links: << >>  << T >>  << A >>
Guy wrote:

> As far as security for Key storageI did say there weren't alternatives that
> already exist, I was exploring the benefits of this new alternative.  Then
> the conversation moved to other secure data storage.  AES is current, before
> it were many other encryption standards, as time marches on, Secure becomes
> a non-absolute changing value.  I am posing an alternative that might
> provide an equal or greater cost function of obtaining a stored Key than
> volatile/battery SRAM etc.

  These things do not have to be mutually exclusive : you could deploy
obscurity AND Volatile Keys AND NV cyphers AND UniqueID Seeds, all 
together in the maximal designs.
  Each one hikes the time/cost to crack the system.
  In most commercial systems, you only need to hike it above the cost
of development (or possibly above litigation risk-cost, as you may be 
doing some of this to make it impossible to verify patent infringement ;)
  In government/banking etc, the data payloads give different cost
thresholds.
-jg


Article: 73837
Subject: Re: ELABORATED DISCLOSURE and continued discussion : NV on-chip memory?
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Sep 2004 05:23:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>,
Guy <guys@altera.com> wrote:
>Nicholas -

>First, I have made my disclosure which unfortunately was taking 3-9
>hours to post by Google which exacerbated this whole thread - sorry.
>I will continue under this Moniker until the end of this thread at
>which point I will move on to a new user name.  I attempt to remain
>anonymous for now as have many individuals on news groups do for
>various reasons.

Actually, most on this newsgroup are DELIBERATELY non-anonymous.  If
you want to verify me, or Peter Aflke, or Ray Andraka, or just about
everybody else on this newsgroup post under their own names because it
tells alot, and can be used as a pointer to their copus of work.

EG, Ray Andraka is a top flight FPGA engineer, able to get things to
fit that others would give up on.  

While I'm a slighly loony ivory tower academic, who's better at coming
up with ways to destroy systems.


> Anyways, I did not understand your point about the cost of a
> standard solution for AES solution.  That was my whole point that
> potentially using a huge cost of detection NV technology would save
> costs in different ways: on chip NV configuration storage reducing
> system costs (battery, cpld, external config data).

Just accept that Nonvolatile cells are vastly easier to probe, because
to probe a volatile cell, you have to remove the chip, and probe the
signals under several layers, without disturbing the power supply.  It
IS doable, mind you, but its a lot more work.

Thus the plaintext key which holds the rest of the system together
(eg, the bitfile encryption key) is best stored in volatile cells, and
are specified as such in many places.

The AES point is that you have an AES key embedded in the bitfile,
that is used to on the fly encrypt/decrypt a large external store.
Thus to crack the store, you need to get either the encrypted AES key
by either doing an analysis on the soft-core encrypter OR on the
hard-core bitfile loader to get the bitfile's key which is protecting
the AES key.

Thus the keystone of unencrypted data is the volatile SRAM of the
bitfile encryptor, which should be harder to extract than data stored
in nonvolatile cells.



Also, since you are posting anonymously (falsly), remember that
neither Xilinx nor Altera will willingly slow down the circuits, and
adding fab steps would be a big No-Go unless the payoff is really,
REALLY big.

As I've said, one can use the existing bitfile encryption, a battery,
an external flash, and about ~1000 slices of glue to create a large
nonvolatile protected store, which will be more secure than efectively
any solution which just uses nonvolatile storage.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73838
Subject: Re: ELABORATED DISCLOSURE and continued discussion : NV on-chip memory?
From: "Guy" <guys@altera.com>
Date: Thu, 30 Sep 2004 06:26:41 GMT
Links: << >>  << T >>  << A >>
Nicholas-
Thanks for the response.  Unfortunately because of my current employeement,
I can not post as myself like I have done in the past.  I recognize that
value and promise in due time, I will do it again.  (After this thread I
will change to a different anonymous moniker).

You raise good points, but it appears that you are making assumptions about
NV memory detection when you mention probing - doesn't that assume that
there is actually a charge (a la flash) stored?  What if there was some
other storage mechanism, almost like an un readable ROM bit?

Would you agree that if the difficulty/cost of extracting a KEY from this NV
memory exceed that of the battery/SRAM storage, then it could very well be
considered a superior mechanism? This is what I would like to explore.

 Also, don't forget the fact that one would not even need to store a key for
the configuration data since it would be stored on chip in this NV memory.

I'll be back in the morning.


what do you think?
"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:cjg594$28r1$1@agate.berkeley.edu...
> In article <7dL6d.4447$nj.3468@newssvr13.news.prodigy.com>,
> Guy <guys@altera.com> wrote:
> >Nicholas -
>
> >First, I have made my disclosure which unfortunately was taking 3-9
> >hours to post by Google which exacerbated this whole thread - sorry.
> >I will continue under this Moniker until the end of this thread at
> >which point I will move on to a new user name.  I attempt to remain
> >anonymous for now as have many individuals on news groups do for
> >various reasons.
>
> Actually, most on this newsgroup are DELIBERATELY non-anonymous.  If
> you want to verify me, or Peter Aflke, or Ray Andraka, or just about
> everybody else on this newsgroup post under their own names because it
> tells alot, and can be used as a pointer to their copus of work.
>
> EG, Ray Andraka is a top flight FPGA engineer, able to get things to
> fit that others would give up on.
>
> While I'm a slighly loony ivory tower academic, who's better at coming
> up with ways to destroy systems.
>
>
> > Anyways, I did not understand your point about the cost of a
> > standard solution for AES solution.  That was my whole point that
> > potentially using a huge cost of detection NV technology would save
> > costs in different ways: on chip NV configuration storage reducing
> > system costs (battery, cpld, external config data).
>
> Just accept that Nonvolatile cells are vastly easier to probe, because
> to probe a volatile cell, you have to remove the chip, and probe the
> signals under several layers, without disturbing the power supply.  It
> IS doable, mind you, but its a lot more work.
>
> Thus the plaintext key which holds the rest of the system together
> (eg, the bitfile encryption key) is best stored in volatile cells, and
> are specified as such in many places.
>
> The AES point is that you have an AES key embedded in the bitfile,
> that is used to on the fly encrypt/decrypt a large external store.
> Thus to crack the store, you need to get either the encrypted AES key
> by either doing an analysis on the soft-core encrypter OR on the
> hard-core bitfile loader to get the bitfile's key which is protecting
> the AES key.
>
> Thus the keystone of unencrypted data is the volatile SRAM of the
> bitfile encryptor, which should be harder to extract than data stored
> in nonvolatile cells.
>
>
>
> Also, since you are posting anonymously (falsly), remember that
> neither Xilinx nor Altera will willingly slow down the circuits, and
> adding fab steps would be a big No-Go unless the payoff is really,
> REALLY big.
>
> As I've said, one can use the existing bitfile encryption, a battery,
> an external flash, and about ~1000 slices of glue to create a large
> nonvolatile protected store, which will be more secure than efectively
> any solution which just uses nonvolatile storage.
> -- 
> Nicholas C. Weaver.  to reply email to "nweaver" at the domain
> icsi.berkeley.edu



Article: 73839
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 30 Sep 2004 06:29:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
Out of curiosity I ran a couple of syntheses+P&R using Quartus II
4.1SP2 Web Edition.  This is just synthesizing the mb_cpu as a top
level, with all ports going to auto-assigned pins (presumably,
internal use could be faster.)  Frequency is as reported by Quartus
timing analysis.  I obviously didn't do anything fancy to try to make
it any faster.

None of these inferred any memory or DSP blocks.

Device		Optimization	LEs used	Frequency

EP1C4F324C7	Balanced	2930		 60.99 MHz
EP1C4F324C7	Speed		3010		 76.38 MHz
EP1C4F324C6	Speed		3010		 84.21 MHz

EP1S10F484C7	Area		2849		 70.55 MHz
EP1S10F484C7	Balanced	2931		 71.89 MHz
EP1S10F484C7	Speed		3011		 71.60 MHz(!)
EP1S10F484C5	Balanced	2931		 90.88 MHz

EP2C8F256C8	Balanced	2993		 59.27 MHz
EP2C8F256C8	Speed		3075		 60.72 MHz
EP2C8F256C6	Speed		3085(?!)	 81.27 MHz

EP2S15F484C5	Balanced	2502		 94.79 MHz
EP2S15F484C5	Speed		2580		 92.83 MHz(!)
EP2S15F484C3	Balanced	2504(?!)	126.04 MHz

A few surprises:

- Sometimes "Balanced" gives a faster design than "Speed"
- Sometimes the number of LEs/ALUTs change when the only thing changed
  is the speed grade of the devices.

	-hpa (who wishes Web Edition supported EP2S60 so I could
         afford to get a devel kit while they're shipping with those :)

Article: 73840
Subject: Re: NV on-chip memory?
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 30 Sep 2004 01:35:44 -0500
Links: << >>  << T >>  << A >>
> I have even been told that reading out the state of our battery backed 
> key memory can be done today.

> The reason why I do not believe the latter, is that they have to do it, 
> while keeping the battery backed memory power ON.

Just because we don't know how to do it yet doesn't mean
that somebody else doesn't know how to do it.  Or that it
can't be solved with enough money.

On the other hand, if it's cheaper to use social engineering
or a rubber hose, then it's good enough.

How long do your bits last if I just disconnect the battery?
(leakage vs capacitance) What if the chip is cold?


> Don't bother to argue with me.  It is the NSA, CIA, etc. you would have 
> to convince.

Only if that's his market.  Maybe what he is thinking about is good
enough for some high volume commercial applications.

-- 
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: 73841
Subject: Re: Xilinx Read First Write First
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 30 Sep 2004 01:40:47 -0500
Links: << >>  << T >>  << A >>
>The Virtex-4 FIFO has an optional "fall-through" mode, where data written
>into an empty FIFO immediately appears on the read output port.
>Responding to a different thread: The Virtex-4 FIFO generate FULL and EMPTY
>flags and ALMOST FULL and ALMOST EMPTY flags, all internally synchronized
>(rising and falling edges) to the relevant clock domain. We just finished
>testing asynchronous operation at 500 MHz read clock rate, with no error in
>>10e14 "going empty" cycles.
>Peter Alfke, Xilinx Applications

Neat.  Thanks.

Can you measure the metastability parameters?

-- 
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: 73842
Subject: Re: FPGAs as a PCI (target) controller
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 30 Sep 2004 01:57:58 -0500
Links: << >>  << T >>  << A >>
>* PCI 32-bit design -- about 2^25 bus clock cycles
>* PCI 64-bit design -- about 100 ms
>* Any PCI-X design -- about 100 ms
>
>The reason a 32-bit PCI design has so much more
>time is that it does not need to be ready to see
>the busmode/buswidth broadcast which takes place
>at the rising edge of reset.

Could I grab the mode/width info with a small amount of
external logic?  (and pass it to the FPGA when its ready)

-- 
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: 73843
Subject: Re: Read back FPGA configuration
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 30 Sep 2004 02:05:48 -0500
Links: << >>  << T >>  << A >>

>(by the way, http://tinyurl.com is a cool way to minimize the pain of 
>long URLs)

Yes, but please include the full URL too.  You never know when some
nice service might vanish.


> http://tinyurl.com/7xemy

In this case, it's:
http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=alpa_rosetta


-- 
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: 73844
Subject: Re: VHDL Project Verilog open core compatibility?
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 30 Sep 2004 07:07:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <48eaa469.0409291100.3ae7062a@posting.google.com>
By author:    cyd@spectrum.montana.edu (Cy Drollinger)
In newsgroup: comp.arch.fpga
>
> I am interested in the compatibility of a VHDL project instantiating a
> verilog open core, floating point arthmetic block. Is this possible
> and if it is not is there another way to use a verilog open core
> inside a VHDL project, a transform of some kind?
> 

It depends on your software.  Both Xilinx ISE and Altera Quartus
support it just fine, but if you're using other tools it's up to each
tool.

	-hpa

Article: 73845
Subject: configuration time
From: "Sunil Shukla" <shukla@uq.edu.au>
Date: Thu, 30 Sep 2004 17:39:52 +1000
Links: << >>  << T >>  << A >>
Hi Guys,

IS it possible to estimate FPGA configuration time without actually actually
porting the bitmap file to FPGA. By looking at the size of the bitmap file
or the size of the core.

Thanks,
Sunil



Article: 73846
Subject: Re: FPGAs as a PCI (target) controller
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Thu, 30 Sep 2004 07:41:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <IJKdnQvu6JrrM8bcRVn-iA@megapath.net>
By author:    hmurray@suespammers.org (Hal Murray)
In newsgroup: comp.arch.fpga
>
> >* PCI 32-bit design -- about 2^25 bus clock cycles
> >* PCI 64-bit design -- about 100 ms
> >* Any PCI-X design -- about 100 ms
> >
> >The reason a 32-bit PCI design has so much more
> >time is that it does not need to be ready to see
> >the busmode/buswidth broadcast which takes place
> >at the rising edge of reset.
> 
> Could I grab the mode/width info with a small amount of
> external logic?  (and pass it to the FPGA when its ready)
> 

Yes, you'd have to latch REQ64# if you're doing a 64-bit design, and
FRAME#, IRDY#, DEVSEL#, STOP# and TRDY# if you're doing a PCI-X
design, on the rising edge of RST#.

You'd have to worry about bus loading, though.

Also, all of this apply if you're doing a plugin card.  If you know
ahead of time what kind of bus you're plugging into, things are a bit
different.

	-hpa

Article: 73847
Subject: Re: Evaluation Board for Xilinx Virtex
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 30 Sep 2004 08:31:00 GMT
Links: << >>  << T >>  << A >>
On Wed, 29 Sep 2004 21:08:14 +0200, André Schekatz <andre.schekatz@ruhr-uni-bochum.de> wrote:

>How to find a Evaluation board for Xilinx Virtex II
>
>Hallo,
>please can anybody help me?
>I want to program a Virtex II or Virtex Pro FPGA Chip. Anybody knows an 
>evaluation board to program this chips? I want to make a fast analogue 
>digital converter and I want to make a performance check. Fist I wand to 
>create a program with mathlab and than by hand with VHDL. Please can 
>somebody tell me a good Evalation Board? I have a gadget of 1500$.

The usual place to start a board search is:

   http://www.fpga-faq.com/FPGA_Boards.shtml



===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

Article: 73848
Subject: Re: PSL pros and cons
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Thu, 30 Sep 2004 09:15:34 GMT
Links: << >>  << T >>  << A >>
Hi KVM,

From my limited exposure to the language (I've just done an introduction
course),

Pros:
1) Very powerful formal language, or assert statement on steroid for
hardware engineers :-)
2) Easy to learn, most of the constructs are logical.
3) Most EDA vendors seem to support it.
4) There are even some vendors which can translate your embedded PSL
constructs into hardware monitor.
5) PSL can be embedded in your code (hardware engineer) or put into a
separate vunit (verification engineer).
6) PSL is a full formal language, a subset can be used in dynamic
simulation.

Cons:
1) Only supported by high-end $$$ EDA tools (like Modelsim SE) which will
limit its uptake.
2) During my PSL course I felt that I needed another language to check my
PSL.
3) Easy to create spaghetti code (unreadable constructs).
4) Requires a different mindset, i.e. engineer who do not use assert
statements (other than to stop the simulator) or never heard of OVL will not
use it.
5) They created different flavoured version for VHDL and Verilog, so you can
not write generic PSL. It shouldn't be too difficult  to write a translator
between the two flavours but I have seen it yet.
6) Some EDA vendors only support the Verilog flavour

If you want to learn language, get yourself onto a PSL course to make sure
you learn how to think in PSL, secondly get yourself a tool which can
generate VHDL from a drawn waveform, this will enable you to create simple
stimulus for your PSL assertions. Get Ben Cohen's book,

I definitely like the language and will use it for my next design,

Regards,
Hans.
www.ht-lab.com


"Kumar Vijay Mishra" <vizziee@yahoo.com> wrote in message
news:889cd7c9.0409290603.252ba577@posting.google.com...
> Hi.
>
> I would like to know the pros and cons of having Property
> Specification Language now offered with ModelSim 6.0. What is its
> future? In this respect, what is assertion-based verification (ABV)?
> And why all this now?
>
> Thanx in advance.
>
> KVM.



Article: 73849
Subject: Enabling clock generation
From: ALuPin@web.de (ALuPin)
Date: 30 Sep 2004 02:39:24 -0700
Links: << >>  << T >>  << A >>
Hi,

I have a PLL in my design. This PLL generates two clocks which are
used in my design.
Now I want to cut these clocks from the design and generate my own
clocks for simulation.
The testclocks 'l_sdram_clk' and 'l_sdram_clk_90' are going to run
when the PLL is locked so that I use the 'l_pll_locked' signal to 
enable the generation of the clocks.
I try that by using GENERATE. But the simulation shows that
'l_sdram_clk' and 'l_sdram_clk_90' remain undefined.

How can I solve that problem ?

I would appreciate your help.

Rgds
André


Here's the code:

architecture xy of zx is

...
signal l_pll_locked : std_logic;
-- This signal comes out of the PLL, it gets '1' in the simulation

test_1: if (l_pll_locked='1') generate
process
begin
  l_sdram_clk <= '1'; wait for 3.75 ns;
  l_sdram_clk <= '0'; wait for 3.75 ns;
end process;
end generate;

test_2: if (l_pll_locked='1') generate
process
begin
  l_sdram_clk_90 <= '1'; wait for 1.875 ns;
  l_sdram_clk_90 <= '0'; wait for 3.75 ns;
  l_sdram_clk_90 <= '1'; wait for 1.875 ns;
end process;
end generate;

...
end architecture xy;



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