Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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.eduArticle: 73801
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.eduArticle: 73802
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. -TonyArticle: 73803
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
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.eduArticle: 73805
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.eduArticle: 73806
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
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 -hpaArticle: 73808
"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
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
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
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
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. AustinArticle: 73813
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
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, MadhuraArticle: 73815
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
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
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 ? SumitArticle: 73818
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
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
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. -jgArticle: 73821
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
> 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
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.eduArticle: 73824
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:
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