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 73800

Article: 73800
Subject: Pricing info for Synplify Pro Xilinx...
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Wed, 29 Sep 2004 19:48:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
I need ASAP the pricing information for Synplify Pro for Xilinx, for
budgetary placeholder info.

Anyone know where to find this?  Thanks.



-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73801
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Sep 2004 13:11:25 -0700
Links: << >>  << T >>  << A >>
Google says:-
Pricing and Availability

The Synplify 7.7 and Amplify 3.7 software are available now. Pricing for the
Synplify software starts at $9,500 (U.S.) and pricing for the Amplify
Physical Optimizer(TM) software starts at $29,000 (U.S.). For more
information visit Synplicity's Web site at http://www.synplicity.com.

Pro used to cost about double Synplify regular.

HTH, Syms.

"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:cjf3i3$1s2o$1@agate.berkeley.edu...
> I need ASAP the pricing information for Synplify Pro for Xilinx, for
> budgetary placeholder info.
>
> Anyone know where to find this?  Thanks.
>
>
>
> -- 
> Nicholas C. Weaver.  to reply email to "nweaver" at the domain
> icsi.berkeley.edu



Article: 73802
Subject: Re: embedded linux on FPGA?
From: tony.p.lee@gmail.com (T Lee)
Date: 29 Sep 2004 13:12:39 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4158414E.24D9E354@yahoo.com>...
> 
> One other feature is that a Forth kernal can include the full compiler. 
> So you can boot into an embedded app, or you can boot the kernal and
> quickly compile the app at startup.  Then updates can be done at a
> source level!  
> 
> But the best part is that a full Forth kernal can be well under 64 KB,
> even as small as 16 KB!  Try that with Linux!!!
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Forth is very good for small embedded design.

Nice thing about Linux is you get the the TCP/IP, nfs, gdb, NTP, telnet, ssh, 
DHCP, DNS, file system, SNMP etc for free.

Debug complex software with gdb, strace, tcpdump in Linux running 
PPC is not any different than debug it on x86.  

I am using Linux on VP2 ppc , once the linux is up, port NTP, DHCP, SNMP, gdb,
strace, tcpdump take very little time, most of the time spent on integration
and testing.  Once it works, it works as reliable as gdb, tcpdump on your
desktop PC.

-Tony

Article: 73803
Subject: Re: High speed counters on Xilinx CoolRunner-II
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 29 Sep 2004 13:13:20 -0700
Links: << >>  << T >>  << A >>

Not true. An LFSR counter uses the same number of flip-flops as a binary or
a Gray counter (if we disregard the fact that LFSR normally excludes one
state). The trouble with LFSR is that any math is impossible in that code,
but it is very easy to reverse the direction of count.
BTW, the fastest counter is always a binary ripple counter, where the
frequency resolution is determined by only one flip-flop's toggle rate.
But you have to wait a while to read out data, after disabling the count.
I remember that the original posting promised to do that.
Peter Alfke
================
> From: Laurent Gauch <laurent.gauch@DELETE_CAPSamontec.com>
> Newsgroups: comp.arch.fpga
> Date: Wed, 29 Sep 2004 20:20:51 +0200
> To: "Robert S. Grimes" <rsg@payload.com>
> Subject: Re: High speed counters on Xilinx CoolRunner-II
> 
> 
> Do you real need binary counter in your application?
> 
> If you are searching to speed your design, try a LSFR architecture of
> your counter -> you will use more Flip-Flops but you will increase the
> speed !
> 
> 


Article: 73804
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Wed, 29 Sep 2004 20:17:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <2s0j7fF1c0cu3U1@uni-berlin.de>,
Symon <symon_brewer@hotmail.com> wrote:
>Google says:-
>Pricing and Availability
>
>The Synplify 7.7 and Amplify 3.7 software are available now. Pricing for the
>Synplify software starts at $9,500 (U.S.) and pricing for the Amplify
>Physical Optimizer(TM) software starts at $29,000 (U.S.). For more
>information visit Synplicity's Web site at http://www.synplicity.com.
>
>Pro used to cost about double Synplify regular.

Thanks, but I recall there being a cheaper Xilixn only verson or
sometihng.  And a press release won't due for the budget info I need.


-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73805
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: "John_H" <johnhandwork@mail.com>
Date: Wed, 29 Sep 2004 20:29:30 GMT
Links: << >>  << T >>  << A >>
So call Synplicity.
Telephones.  They work great.
The number's on their site.

"Nicholas Weaver" <nweaver@soda.csua.berkeley.edu> wrote in message
news:cjf58g$1soh$1@agate.berkeley.edu...
> In article <2s0j7fF1c0cu3U1@uni-berlin.de>,
> Symon <symon_brewer@hotmail.com> wrote:
> >Google says:-
> >Pricing and Availability
> >
> >The Synplify 7.7 and Amplify 3.7 software are available now. Pricing for
the
> >Synplify software starts at $9,500 (U.S.) and pricing for the Amplify
> >Physical Optimizer(TM) software starts at $29,000 (U.S.). For more
> >information visit Synplicity's Web site at http://www.synplicity.com.
> >
> >Pro used to cost about double Synplify regular.
>
> Thanks, but I recall there being a cheaper Xilixn only verson or
> sometihng.  And a press release won't due for the budget info I need.
>
>
> -- 
> Nicholas C. Weaver.  to reply email to "nweaver" at the domain
> icsi.berkeley.edu



Article: 73806
Subject: Re: MicroBlaze is no available as Open-Source!! (from independant 3rd party)
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 29 Sep 2004 22:42:41 +0200
Links: << >>  << T >>  << A >>
tails_naf@yahoo.com (Tails) writes:

> "Antti Lukats" <antti@case2000.com> wrote in message news:<cjc3ae$ves$01$1@news.t-online.com>...
> > "Roman Zeilinger" <Patrick.Bateman23@gmx.at> wrote in message
> > http://www.opencores.com/pdownloads.cgi/list/aemb
> 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... 

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 73807
Subject: Re: FPGAs as a PCI (target) controller
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Wed, 29 Sep 2004 20:43:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <cZC6d.131610$MQ5.82914@attbi_s52>
By author:    ben@ben.com (Ben Jackson)
In newsgroup: comp.arch.fpga
> 
> First you need to google for the "PCI Local Bus Specification" PDF.
> You will find bootleg copies.  The 2.1 I've found is easier to use
> than 2.2 because it has a working table of contents.
> 

Let me also recommend this book:

http://www.amazon.com/exec/obidos/tg/detail/-/0976086506/qid=1096490517/sr=8-15/ref=sr_8_xs_ap_i15_xgl14/103-4256124-3515027?v=glance&s=books&n=507846

	-hpa

Article: 73808
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: nospam <nospam@nospam.invalid>
Date: Wed, 29 Sep 2004 21:49:44 +0100
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> wrote:

>So call Synplicity.
>Telephones.  They work great.
>The number's on their site.

Web sites also work great, some people actually put information on them so
other people don't have to telephone them to ask simple questions. 



Article: 73809
Subject: Re: MicroBlaze is now available as Open-Source!! (from independant 3rd party)
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Sep 2004 14:19:19 -0700
Links: << >>  << T >>  << A >>
In case people start targeting MicroBlaze and its tools at vendor A's parts?
;-)
Maybe not!
Syms.
"E.S." <emu@ecubics.com> wrote in message
news:FaA6d.56$hO4.19@fe39.usenetserver.com...
> Jon Beniston wrote:
>
> > How long before Xilinx try to get them to remove it do we reckon?
>
> Why do you think, they should ?
>
>



Article: 73810
Subject: Re: NV on-chip memory?
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Sep 2004 14:30:02 -0700
Links: << >>  << T >>  << A >>
Guy,

Undetectable?

Go fool somebody who can be easily fooled.

I have been told that any NV technology can be cracked by techniques 
available today.

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.

To de-cap the device, and remove the flip chip from the package, all the 
while retaining power to the BB RAM bits, and then going through 11 
layers of metal is something I would like to see! (Perhaps a determined 
attacker with an infinite budget could do it, though....can never be 
absolutely sure).

Otherwise, to determine the state of a NV technology by electron 
microscope, electron microscope charge probing, ..... (put in your 
favorite fancy tool here) is considered to be a 'known' method of attack.

That is why our federal government does not even consider the use of non 
volatile storage for keys in their standard for equipment (FPIS-41).

Let alone something that has to be really secure (which has to have even 
better methods for protection built into it).

So assuming a determined attacker (which you must assume, as assuming an 
average attacker is just wishful thinking) you can not seriously make a 
statement like you just did.

And any claim of obscurity is also just wishful thinking.  Any secret 
that prevents someone from understanding the security is automatically 
assumed to be know to a determined attacker.  The government also tells 
you that.  Go read about how obscurity fails.  All the time.  Over and 
over (and folks still do not learn).

http://en.wikipedia.org/wiki/Security_through_obscurity

That is why we are FPIS-41 compliant.  That way, there is no obscurity. 
AES 256 is well known, well understood, we use battery backed (one 
industrial lithium coin cell lasts for a lifetime powering up to 8 
devices, literally from -40C to +100C) RAM for the keys, and keys go 
away when power is removed .

http://tinyurl.com/496n2

Since the method you propose does not conform with FIPS-41, why do you 
bother at all to use it for anything to do with security?  Why not just 
call it a 'baby gate' to prevent 'domestic accidents'.

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

Austin

Guy wrote:
> Nicholas - please see below responses.
> Thanks.
> 
> nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote in message news:<cjc7cp$qg0$1@agate.berkeley.edu>...
> 
>>In article <a11322d6.0409271941.e71e499@posting.google.com>,
>>Guy <guys@altera.com> wrote:
>>
>>>quick survey...
>>>
>>>Would it be of value to provide cheap on-chip one time programmable
>>>memory in an FPGA like Cyclone II?
>>>Say 1-10Mbit depending on density.
>>
>>Would it slow down the fab or up the cost?
> 
> 
> See response to Jim - our goal is a standard fab process so cost would
> simply be driven by it's area.
> 
> 
>>>It would be field or user programmable either via a programmer (very
>>>fast) or by user logic.
>>>
>>>It would be very secure (anti-copy) for:
>>>secure s/w code with on-chip processor
>>>secure data storage
>>>configuration data(s) 
>>>etc.
>>
>>There is already a more secure mechanism for this: SRAM-based
>>encryption keys used to load encrypted bitfiles.  That mechanism can
>>be used to bootstrap a large non-volatile store, with a keystone of
>>the SRAM-based encyption key which is probably significantly harder to
>>reverse/crack than on-chip static bits.
> 
> 
> Just to point out, the mechanism you are referring to for SRAM based
> devices require the programming of NV memory to hold this mentioned
> security Key.  ALthough the encryption is super strong from the data
> perspective, analyzing the physical NV memory currently being used
> (EEPROM/EPROM/or FLASH) is not very difficult to extract the Key and
> thus crack the encrypted data.    This NV technology adds
> manufacturing premium to the whole wafer cost, which is traded off for
> the value of the feature.  We are looking into removing this process
> premium via the NV technology discussed in the thread.  Also, the
> memory technology being discussed is actually undetectible and thus
> can not be cracked.  Does this sound good to anyone?  What
> applications do users envision needing true anti-piracy/copy of the
> actual FPGA configuration/functionality?   I'll probably start another
> thread on this.
> 
> 
>>Thus the "savings" by putting it on-chip are not security, but the
>>cost savings of not needing a large external Flash PROM.
> 
> 
> So, based on above paragraph, savings is realized in both external NV
> integration onto the chip and ultimate Security of data via encryption
> and security of the actual Key.
> 
> Thanks.

Article: 73811
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: Wed, 29 Sep 2004 17:36:41 -0400
Links: << >>  << T >>  << A >>
On Wed, 29 Sep 2004 21:49:44 +0100, nospam wrote:

> "John_H" <johnhandwork@mail.com> wrote:
> 
>>So call Synplicity.
>>Telephones.  They work great.
>>The number's on their site.
> 
> Web sites also work great, some people actually put information on them so
> other people don't have to telephone them to ask simple questions.

This sort of pricing is never on websites, you have to call them and
negotiate a deal. 

Article: 73812
Subject: Re: NV on-chip memory?
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Sep 2004 14:48:23 -0700
Links: << >>  << T >>  << A >>
Post Script:

By the way, a number of folks mistakenly belive that our FPGAs 'require' 
batteries. (??!!!???HUH???)

That is not true.

You only require a battery if you want to keep the keys alive when power 
is removed when using the encrypoted bitstreams.

If you do not use encryption, then you should leave the BBRAM Vcc pin alone.


As for NVRAM, there are lots of useful things it would be nice to have 
it there for.

Since there is perfectly good NVRAM processes available for larger 
(older) transistor technologies, there are lots of products that are 
available with those features.

For us 'leading edge' FPGA types, we 'only' have standard CMOS process 
available.

Austin

Article: 73813
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 29 Sep 2004 22:48:55 +0100
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
>
> Thanks, but I recall there being a cheaper Xilixn only verson or
> sometihng.  And a press release won't due for the budget info I need.

If you have to ask the price, you can't ....



Article: 73814
Subject: Re: Microblaze : ilmb_Cntrl
From: Madhura <madhura@ece.ualberta.ca>
Date: Wed, 29 Sep 2004 14:56:51 -0700
Links: << >>  << T >>  << A >>
I have used a memory of 64K.
Without the linker script, the following are the memory sizes :

mb-size TestApp/executable.elf
   text data bss dec hex filename
  44368 96 1032 45496 b1b8 TestApp/executable.elf

Thanks,
Madhura

Article: 73815
Subject: DISCLOSURE : NV on-chip memory?
From: guys@altera.com (Guy)
Date: 29 Sep 2004 14:57:04 -0700
Links: << >>  << T >>  << A >>
It was suggested that I provide a disclosure.  It should not be
assumed that I am affiliated with Altera or that Altera has intent to
create features as discussed in this thread.  The name and email you
see on the posting is a known mechnaism through which I was able to
obtain New Group access.

Either way, thank you for continuing the discussion.





nweaver@soda.csua.berkeley.edu (Nicholas Weaver) wrote in message news:<cjc7cp$qg0$1@agate.berkeley.edu>...
> In article <a11322d6.0409271941.e71e499@posting.google.com>,
> Guy <guys@altera.com> wrote:
> >quick survey...
> >
> >Would it be of value to provide cheap on-chip one time programmable
> >memory in an FPGA like Cyclone II?
> >Say 1-10Mbit depending on density.
> 
> Would it slow down the fab or up the cost?
> 
> >It would be field or user programmable either via a programmer (very
> >fast) or by user logic.
> >
> >It would be very secure (anti-copy) for:
> > secure s/w code with on-chip processor
> > secure data storage
> > configuration data(s) 
> > etc.
> 
> There is already a more secure mechanism for this: SRAM-based
> encryption keys used to load encrypted bitfiles.  That mechanism can
> be used to bootstrap a large non-volatile store, with a keystone of
> the SRAM-based encyption key which is probably significantly harder to
> reverse/crack than on-chip static bits.
> 
> Thus the "savings" by putting it on-chip are not security, but the
> cost savings of not needing a large external Flash PROM.

Article: 73816
Subject: Re: DISCLOSURE : NV on-chip memory?
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 29 Sep 2004 15:42:13 -0700
Links: << >>  << T >>  << A >>
Guy,

Either you represent Altera, or you do not.

There is no in between.

I do not have that luxury, and neither do you.

State who who represent.

You do more damage to Altera by posing as you do.

If you wish to remain anonymous, get a yahoo.com email account.

If you wish to do market research in Altera's name (or by their leave), 
fine; say so.  If you are not doing market research in Altera's name (or 
by their leave), don't use it.

Austin

"Fool me once, shame on you. Fool me twice, shame on me."

Article: 73817
Subject: Cheaper way to get Xilinx Core generator
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 29 Sep 2004 15:45:19 -0700
Links: << >>  << T >>  << A >>
Is there a way to get Xilinx core generator without having to buy the
$2495 ISE foundation i.e. To be able to use online (free) Xilinx cores
with free ISE webpack ?

Sumit

Article: 73818
Subject: Re: Pricing info for Synplify Pro Xilinx...
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 29 Sep 2004 22:56:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
nospam <nospam@nospam.invalid> wrote:
: "John_H" <johnhandwork@mail.com> wrote:

: >So call Synplicity.
: >Telephones.  They work great.
: >The number's on their site.

: Web sites also work great, some people actually put information on them so
: other people don't have to telephone them to ask simple questions. 

You never tried a web site of a normal german distributor:

All it's normally says is : Call!

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 73819
Subject: Re: Cheaper way to get Xilinx Core generator
From: "kpatel -at- xilinx -dot- com" <"kpatel -at- xilinx -dot- com">
Date: Wed, 29 Sep 2004 17:04:52 -0600
Links: << >>  << T >>  << A >>
Sumit,

The ISE BaseX configuration comes with CORE Generator and is priced at 
$695.  It can be purchased from the Xilinx online store here:
http://www.xilinx.com/xlnx/xebiz/onlinestore.jsp?sGlobalNavPick=PURCHASE

I hope this helps.

Regards,
Kamal Patel
Xilinx Apps


Sumit Gupta wrote:

>Is there a way to get Xilinx core generator without having to buy the
>$2495 ISE foundation i.e. To be able to use online (free) Xilinx cores
>with free ISE webpack ?
>
>Sumit
>  
>

Article: 73820
Subject: Re: NV on-chip memory?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 30 Sep 2004 11:42:26 +1200
Links: << >>  << T >>  << A >>
Guy wrote:

> HI JIM -  PLease see below.
> thanks.
> 
> Jim Granville <no.spam@designtools.co.nz> wrote in message news:<d4k6d.5778$mZ2.508657@news02.tsnz.net>...
> 
>>Guy wrote:
>>
>>
>>>Let me first say thank you for your responses.
>>>To address some of the questions / comments:
>>>I realize that not everyone will extract the same application or value
>>>from the on-chip NV memory, however, since it has the potential to
>>>provide or support different applications, general enough value may be
>>>justified for inclusion.
>>
>>Since this is Horizon gazing, what about looking into FPGA+MRAM - then
>>you can offer SRAM to all users, and do not have to do a RAM/OTP die 
>>trade off - plus it is much easier to explain to users.
>>[FPGA designers are not always the most hardware literate :) ]
>>
> 
> One thing we are striving to do, in order to keep cost minimal, is to
> stay away from non standard CMOS processes.  MRAM although by itself
> shows huge promise for density/speed/cost, will add non-linear cost to
> SoCs due to non-standard process needed and thus premium for the
> entire SoC, not just the MRAM portion.  Good idea though.  Let's
> assume a technology has been identified that does meet this goal for
> the assumptions I originally described.

Understood, this was a tad tongue in cheek... (but you will need to
watch MRAM, longer term)

<snip>
>>Any values/estimates on write times / write energies / Block sizes ?
>>
> 
> As you allude, NV memory often does have assymettrical write/read
> times.
> A goal of ours is to support no slower than 50us per write word.  At
> 64bit word, this is 1.28Mkbps.  I believe many applications will be
> immune from write time consideration since many will preprogram the
> data.  In circuit logging may consider this but due to OTP and finite
> size (~10mbit), I assume 1.28mbps is fine?  What do you think?  As far
> as write power, a goal is <2mW DC per bit.  Assume min block sizes of
> 1 or 2Mbit.

  Wider words would increase the bit rate, but would need larger
charge pumps.
  > 1Mbps, means 1-2 seconds of storage, so peak speed is not
likely to bother many designs. ie if someone really wants 1Mbps
they probably have other storage.

  NV Write memory would be more use for Audit trail/timetag/blackbox/
and in some cases environment or fault logging.

  With the wide paths, you could use edge-time compression,
and I presume a RAM FIFO could go in front of the NV Write,
so the average rate might be 20K edges/50us per 64 bit stamp,
but short pulses/bursts could be captured at much higher peaks,
probably to the ~250MHz chip speed ?

> 
>>What about Read-While-Write - which is a common drawback in FLASH.
>>
> 
> Not sure I understand your read-while-write - does this imply dual
> port?  IF so, for cost considerations and area optimization, we are
> only anticipating single port NV blocks.

No. In FLASH one problem is that while writing, the same block cannot
be sensibly data-read [HV write lines vs LV read sense].

Thus you often see split banks, so you run code from
one bank, to write to the other bank & vice versa.
Some newer devices 'stall the core' for the Twp, which gives cleaner
software.

  With a Twp of 50us, it sounds like you will not be able to read from 
the same block for that time. You could add the 'stall/wait' HW signal, 
so any soft uC would not try to read for that time ?

Summary:
  Unless you hit a hard-ceiling, I would not limit the access to 
16/32/64 bits - wider comes for free inside a FPGA, and there will be 
apps we
have not thought of.

  I also see NV memory as opening more scope for smaller/tiny Soft uC.
By going op-code sequential, you can save FPGA resource on the slower 
stuff, and keep it for the fast stuff, where it really matters.

  eg older design approach is to have a fast uC, running interrupts to
handle small, but hard real-time critical tasks.

  This FPGA+NV memory would allow a TinySoftuC per Task, to/from 
DualPort memory, and then a larger/slower CPU like NIOS could handle 
from there.

  This would mean it needs to be partitioned, so rather than ONE block,
you can have (say) eight smaller blocks ?

  To give a real example, consider a MotorController, you need quite fast
PWM control, but with maybe adaptive dead-band, and overload handling,
and some noise spreading, or interpolation, plus a local safe-reset.
  Then you have the much slower, 'what speed do you want code', operator 
code, etc.

-jg


Article: 73821
Subject: Re: DISCLOSURE : NV on-chip memory?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 30 Sep 2004 11:53:06 +1200
Links: << >>  << T >>  << A >>
Guy wrote:
> It was suggested that I provide a disclosure.  It should not be
> assumed that I am affiliated with Altera or that Altera has intent to
> create features as discussed in this thread.  The name and email you
> see on the posting is a known mechnaism through which I was able to
> obtain New Group access.

That's a disclosure ?
Q: Do you work for Altera, or are affiliated with Altera ?
Q: Are Altera considering/analysing NV memory in FPGA ?


Article: 73822
Subject: Re: DISCLOSURE : NV on-chip memory?
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Wed, 29 Sep 2004 20:37:28 -0400
Links: << >>  << T >>  << A >>
> 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: 73823
Subject: Re: DISCLOSURE : NV on-chip memory?
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Sep 2004 00:41:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <cjfdo5$jb01@cliff.xsj.xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>Guy,
>
>Either you represent Altera, or you do not.
>
>There is no in between.
>
>I do not have that luxury, and neither do you.
>
>State who who represent.
>
>You do more damage to Altera by posing as you do.
>
>If you wish to remain anonymous, get a yahoo.com email account.

Or drop me an email and I'll get you a gmail account.

>If you wish to do market research in Altera's name (or by their leave), 
>fine; say so.  If you are not doing market research in Altera's name (or 
>by their leave), don't use it.

And if you are not affiliated with Altera, be prepared for a visit
from the guys in well-tailored suits.  Ash Lawyers Durubultuk...
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73824
Subject: Re: Spartan-3 VCCIO ramp up time
From: brimdavis@aol.com (Brian Davis)
Date: 29 Sep 2004 17:48:12 -0700
Links: << >>  << T >>  << A >>
Steven Knapp wrote:
>
> No, not unless the transient drops the VCCO supply down toward ground, in
> which case the application would violate a variety of specification.
>

 Sorry if my first post wasn't clear: I'm not concerned about
a spec-violating external VCCO supply transient, but rather an
internal VCCO rail transient, self-inflicted by the FPGA due to
end-of-configuration DCI startup current in the leaded packages.

  See my other post from earlier today for a better wording
of the question. 

  The SSO guidelines would normally provide some insight into
a max limit on the transient current, but the VQ/TQ/PQ SSO specs
were changed from a blank column in previous S3 datasheets to
not-even-mentioned in the latest datasheet.

Brian



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