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
Richard Schwarz wrote: > > I know exactly who this is. You requested us to delay a shippment and we > did. You then complained that UPS didn't ship to you correctly and wanted > a refund for shipping costs. We checked into the matter and they said you > received the package on time. I thought the matter was resolved but > perhaps it is not.--this was DEC/JAN time frame-- > > If you would like to discuss it further, I am certainly open to this, and > wish to try and make you a happier customer. :-) I think the major mix up > for you was the request you made to delay the product's shippment. I know > how schedules are and I know even getting a package one day letter than > expected can be an issue, and we try to get the orders to our customers > as fast as we can --or on a schedule that customers wants (in this case > delayed) --. Please email me and I will do my best to try to further > resolve the problem. > If delivery on 12/30/97 gets delayed first to 1/2/98 (1), then to 1/6/98 (2), THEN to 1/7/98 (3), then the shipment is eight (8) days late. And I still had to pay $30 shipping and handling, about half of which was for the UPS 2nd day service. The reasons that I remember were as follows: Reason (1): on 1/2, you said you thought I wanted 12/30 to be the shipping date, rather than the arrival date. You said you shipped it on 12/31, and that I should receive it by 1/5. Reason (2): on 1/5, you said that the manual was not available, so you held the shipment until 1/2/98, and that I should receive it by 1/6. Even then the manual was shipped later. Reason (3): the UPS driver accidentally forgot to deliver the package on 1/6/98, even though it was on his truck; he delivered it instead the next day. The driver apologized and suggested that I get a refund, and so did the UPS carrier, but when I emailed their suggestions to you, and two weeks later inquired about the refund, you said you took my suggestion as only that, and not as a request, and that you did not pursue the matter with UPS.Article: 9426
hi, I am trying to initialize a couple of registers based on some jumper values (ie input pins) during reset asynchronously. I am using verilog for design and I've looked at the generated circuitry (in the .vo file and the .rpt file). Synthesis seems to generate CLRN and PRN inputs (one or the other not both 0 for the same register) of the DFFE using some combinational logic based on rst and jmpr inputs. Everything seems in order and the maxplus2 simulator tells me that the design should work but it doesn't. I have a flex10k board which worked for the previous iterations of this design but I can't seem to get this asynchronous initilization based on inputs other than reset functionality to work. Any ideas ? muzo WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 9427
Do you also have a pull-up on the nconfig pin? Ying Chen ying@csua.berkeley.edu -- ----------------------------------- http://www.csua.berkeley.edu/~yingArticle: 9428
zhangy wrote:
>
> Who knows the ByteBlaster circult?
Hi Zhangy,
you could try the following URL:
http://www.acte.no/freecore/blaster.htm
Cheers.
Matteo.
-----------------------------------------------------
Matteo Mascagni ¦Phone : +44 117 9075390
QSW Ltd. ¦Fax : +44 117 9075395
One Bridewell Street ¦E-mail: matteo@quadrics.com
Bristol BS1 2AA - UK ¦ mascagni@geocities.com
Article: 9429In article <35081880.4811@bham.ac.uk>, Richard Staley <r.j.staley@bham.ac.uk> wrote: > > Does anyone know the secret for getting Max+plusII v8.21 to recognise > the programmer ( MPU6 ) when running under WindowsNT4. > It's visible and working with Windows 3.1! > > Something to do with device drivers? > > Any help appreciated, > > Richard Staley , Hardware Engineer. > Yes You are right that you need a device driver. You add it by going into the control panel and then choose multimedia (yes multimedia) there you have to choose other devices and then add other device (I'm not quite sure what the correct menu names are since I've only seen swedish NT4's) You then get to show where the drivers are located and they are installed under C:\MAXPLUSII} DRIVERS (If you have installed maxplusII under c:\maxplusii ) I hope this helps ! B.R. Håkan Pettersson -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9430
Just a quick question, If I dig through the Xilinx documentation long enough, will I find the mapping of the setup ROM to the FPGA bits? In other words, could I program these parts by hand? Bit by bit. It occurred to me that on one hand, it may be a big shift register logically mapped to the internal bits. With the bits in each CLB always mapped in the same order and all CLB are lined up in order, one after another. On the other hand, the bits may be randomly mapped to allow easy fabrication of the chip. I collected a handfull of parts and then found that the design software would cost me thousands of dollars. Alot of money considering I'm just playing around. And yes, I have heard of a $250 limited useage package. In particular I have XC2018, XC2064, XC3020 and XC3064 parts. So, is this info available? Or is this another one of those closely guarded secrets? Thanks, -- Jeff Sampson Minneapolis, MN, USA (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) jsampson@pobox.com jsampson@citilink.com http://www.pobox.com/~lcd_infoArticle: 9431
Jeff Sampson <jsampson@pobox.com> wrote:
> If I dig through the Xilinx documentation long enough, will I find the
> mapping of the setup ROM to the FPGA bits? In other words, could I
> program these parts by hand? Bit by bit.
BEGIN standard_xilinx_bitfile_format_thread
{ Newbie: Can I hack the Xilinx Bitfile Format?
Several Followups: No. It's proprietary and a closely guarded secret
Several Followups: The 6000 series has an open format.
{ More followups: The 6000 has no memory and poor arithmetic }
Several Followups: Speculation on how it might be done
{ Make incremental changes to a design and record the results.
But that requires that one purchase the tools.
And it must be re-done each time they release a new type of chip. }
Several Followups: Debate on why Xilinx would keep such a thing secret
{ They're just big meanies
They are protecting their customers from reverse engineers.
They're protecting themselves from better tool writers.
}
Several Followups: Debate about why chip makers charge so much for tools
{ They need to hire programmers and support people.
It keeps the riff-raff out.
It locks the customer in
}
Mention that NeoCad once hacked xilinx bitfile format
{ they were bought by xilinx. }
}
END
Maybe this should be a FAQ?
--
Don Husby <husby@fnal.gov> Phone: 630-840-3668
Fermi National Accelerator Lab Fax: 630-840-5406
Batavia, IL 60510
Article: 9432I would recommend everybody interested to visit http://www.linuxeda.com and in particularly http://www.linuxeda.com/~freehdl Mikhail MatusovArticle: 9433
chakanp@hem1.passagen.se wrote: > Yes You are right that you need a device driver. You add it by going into the > control panel and then choose multimedia (yes multimedia) there you have to > choose other devices and then add other device (I'm not quite sure what the ..... That has done the trick! Thanks for the reply. (I'd never considered the programmer as a multimedia device.) Regards Richard.Article: 9434
Can anyone out there point me to an independent review of low cost (less than 10K dollars - preferably a lot less) FPGA vendor independent VHDL tools. Thanks Stephen King CRL sking@crl.co.ukArticle: 9435
Hi, Maybe it would be more secure to use a state machine that would generate an internal reset signal just after power-up telling all the registers that they must initialize according to the jmpr inputs. Thus your design would be full synchronous which is in my opinion less subject to incoherent behaviours. Regards E. JOLLY On Fri, 13 Mar 1998 01:57:03 GMT, muzok@pacbell.net (muzo) wrote: >hi, >I am trying to initialize a couple of registers based on some jumper values (ie >input pins) during reset asynchronously. I am using verilog for design and I've >looked at the generated circuitry (in the .vo file and the .rpt file). Synthesis >seems to generate CLRN and PRN inputs (one or the other not both 0 for the same >register) of the DFFE using some combinational logic based on rst and jmpr >inputs. Everything seems in order and the maxplus2 simulator tells me that the >design should work but it doesn't. I have a flex10k board which worked for the >previous iterations of this design but I can't seem to get this asynchronous >initilization based on inputs other than reset functionality to work. >Any ideas ? > >muzo > >WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net> --- Pour me contacter enlever "enlever." de mon adresse Email.Article: 9436
Jeff Sampson wrote: > If I dig through the Xilinx documentation long enough, will I find the > > mapping of the setup ROM to the FPGA bits? In other words, could I > program these parts by hand? Bit by bit.. snip > > So, is this info available? Or is this another one of those closely > guarded secrets? > There are over 46.000 configuration bits in the XC3064 ( proportionally fewer in the smaller parts), and their function is indeed a "closely guarded secret". First and foremost this is to protect our customers, so that their competitors cannot reverse engineer any FPGA design, where the bitstream is openly accessible. Figuring out the meaning of 46,000 bits is a formidable task, although there is a certain regularity. The location of the 16+16+bits defining the LUTs in each CLB can be made available under non-disclosure agreement, but the remaining 40,000 bits will not be divulged under any circumstance ( in the interest of our customers) A low-cost student version of the software is available at Amazon for less than $70.-, but it does not cover XC2000 and XC3000 devices. For serious new designs, I would recommend XC4000E and XC4000XL amd Spartan devices, and they are supported by the inexpensive software mentioned above. Hand-assembling 46,000 bits is not a realistic alternative. Peter Alfke, Xilinx ApplicationsArticle: 9437
Hi, We are Hunter International, a Chicago based Engineering Recruitment firm, and we are currently seeking qualified people for an excellent opportunity located in the Northwest Side of Chicago. The position is a Sr. Software Engineer with expertise in the design and networking of complex TCP/IP systems. Some of the "buzz" words and requirements are: *7 or more years of embedded systems programming. *5 or more years of C/UNIX programming. *Hands on experience with network drivers. *Hands on experience with TCP/IP. Some "pluses"... *MIPS R5000 Assembly Language Programming. *TI TMS34010 GSP Assembly Language Programming. *A BSCS or BSEE would be nice, but not critical. Experience talks here! Basic job description: The candidate will be responsible for working with the product and development teams to add new networking features to new and existing products. Will be responsible for network drivers and other low level libraries. Will work with development teams to determine higher level requirements for different products, determine what type of networking model to use for which particular product, like DIS, Client Server, etc... This is a nationwide area network. The product is something that is not only very interesting, but will be very well known, and the individual working on this team will be able to have a very recognizable achievement as a result. The company itself is very unique, and it's engineering driven. No mindless meetings or endless paper trails. If you like to design, if you like solid engineering, and if you like to be creative, then this IS the place for you. Salaries are generous, and are not based on a 'grid scale' of any sort. So if you fit in some, or all, of the basic requirements listed above, then you will be happy that you spent the time to respond to this post. Interested candidates can reach us at: Hunter International Fax: (815)356-9225, or, cleaner@starnetinc.com Hope to hear from you soon! Dave Steiger...Article: 9438
rk wrote: > > Zoltan Kocsi <root@127.0.0.1> wrote in article > <m390qhk9ln.fsf@tade.bendor.com.au>... > : "rk" <stellare@erols.com.NOSPAM> writes: > : > : > systems with differing capabilities with differing prices. a > market-driven > : > environment, to a certain extent. and it won't let companies sit on > their > : > butts, selling the same stuff for high prices year after year. i see > the > : > ambit ads, don't know what they charge, but they're slamming synopsys > in > : > them. very agressive. they want business. and they can get it in two > : > ways: take away synopsys customers for price/performance/standards > reasons > : > or be low enough in price to get other people into the business or just > : > sell multiple seats to make a better engineering environment. perhaps > : > someone with some good info on ambit can comment. > : > : Hm. You can take a look at Symplicity's stuff. You can buy their > synthesis > : for HP or Sun at AU$24k + 1 year compulsory maintenance. You can buy the > : exact same thing for Win AU$12k apiece (no contract). > : Why ? > : > : On the lower end: > : Actel's tools (VHDL synthesis and P&R) for Sun: AU$3.4k > : For Win: AU$1.7k (or free from the net with limited choice of chips). > : > : Or you can see Quicklogic: > : > : Sun: AUD$3k contains P&R > : Win: AUD$3k contains P&R, verilog simulator, editor and the Symplicity > : synthesis (verilog/VHDL). > : > : Motorola P&R for Win is free (they even send you the CD for free), for > : Sun it is not. > : > : AFAIK others are not much different either. > : > : Knowing that most of these tools are made under unix then ported to > : Win I can't really see the reason for pricing the Win tools way > : below the unix ones unless Mr. Gates offers some compensation (I'm > : not accusing, I'm just wondering ...) > : > : As for having a cheap engineering platform then Linux is just as adequate > : as Win - it is even cheaper and more stable. In addition porting unix SW > : to Linux is uncomparably simpler than to Win. Still, Linux is not on the > : EDA palette yet. > : > : Can you explain that ? > : > : Zoltan > > rk: > > that's the question and the pattern and what we've been discussing. > according to synopsys, who is porting from unix --> win and not from unix > --> linux, it's because no customer demand for linux. and someone posted > that "Mr. Gates" is offering help. and, i believe, ports to linux from > unix will mostly transfer unix users to linux. similar # of customers, two > platforms to support. win can bring in new customers and there are a lot > more win machines. Is this really true? I mean, who are these new users? I would basically think that there are a fixed number of people out there wanting to use electronic EDA tools at a given time whether they are on Unix or Win machines. In other words, I don't think that just because Synopsys is now available on a Win NT machine there are going to be a lot of people saying, "Hey, maybe I should buy that there synthesis package and make me a chip." :) Also, why should it be cheaper on NT than on Unix? That is, unless it does not work as well on NT. :) -- Russell J. Petersen ***** ***** VLSI Design Engineer *** /_ __ *** Hewlett Packard ICBD ** / / /_/ ** 3404 E. Harmony Rd. *** / *** Phone: (970) 229-7007 Ft. Collins, CO 80525 ***** ***** fax: (970) 229-6580 email: russp@valhalla.fc.hp.com All opinions are my own, of course, and reflect nothing about HP.Article: 9439
Hello All (help needed !!!)
We know that multiplying a 32bit by 32bit number requires 33 clocks when
we multiply bit by bit and shift the partial products. If we synthesize
this this will require some # of adders, say n(n-1) full adders or
n(n-2) full adders plus n half adders and n x n AND gates. Each adder is
a 1bit adder. This is parallel multiplication or known as array
multiplication.
My Goal is to perform the same multiplication of 32bit by 32bit in
reduced cyle computation & less hardware.
For Example: - If we need less hardware, then we need say 50clocks
- If we need more hardware, then we need say 16clocks
The final solution is to find a multiplication algorithm that uses less
hardware & less computation time to find the result. Please when any of
you propose an algorithm for 32bit by 32bit multiplication, (In general
n-bit by n-bit)
-specify the numbers of adders used & the type CSA, CLA, (RCA or CPA)
CSA -Carry Save Adder
CLA -Carry Look Ahead Adder
RCA -Ripple Carry Adder or Carry Propagate Adder
-specify the numbers of shift registers or AND gates or multiplexers
used
-specify the numbers of clock cycles that will be used for the
computation.
I donot know if this is silly but I will like to know if # of clock
cycles taken to compute the result can be equated to the propagation
delay. If so please explain.
The tradeoff is in this priority
1. Hardware must be less
2. Speed or computation time must be less
This feedback will be used for hardware acceleration of RAID
calculations.
All your feedback will be greatly appreciated,
With best regards - Subbu
My email is subbu@eng.adaptec.com
Article: 9440zoltan: : >Hm. You can take a look at Symplicity's stuff. You can buy their synthesis : >for HP or Sun at AU$24k + 1 year compulsory maintenance. You can buy the : >exact same thing for Win AU$12k apiece (no contract). : >Why ? todd: : The $12K Win package is a node-locked version. For $24K you : can get a floating license version for Windows (same as the : unix versions). rk: for win, w/ hdl analyst, i believe it's $20K node-locked and $40K for a floating license (recent quote from day job). however, catching up on some reading, i ran across, ee times, march 2, p. 66, article by richard goering giving an overview of new quicklogic tools. the quickworks 7, package, for instance, has synplicity synthesis tools integrated and "a new version of silos III verilog simulator simucad that includes an interactive, source-level debugging environment." it goes on to say that the "pc-based quicktools plus 7.0 offers schematic engry, p&r, timing analysis, and 3rd party tool interfaces." - available for $495. the quickworks package for windows available for $2,995. not recommending anything but it is in line with this discussion about eda tools, platforms, and markets and a data point. and note that the synplicity program is available for quite a bit less $ with a lot of other eda capability too, for this environment. interesting. opinon: for the pc/win market and small to moderate sized designs (< 100,000 gates in this family), a pc/win eda environment can be put together for < $10,000 which is capable of good engineering. and this is what is expected for a large segment of the market. me, small business person, can, well, be in business and do good engineering. if the tools cost $95,000 or $150,000, uh, no way i can afford to be an independent design engineer/consultant. similar argument for many departments in corporate environment where the attitude is that better is the enemy of good enough, if better costs A LOT more and isn't THAT MUCH better. of course, as we've discussed, some apps don't fit the pc/win model and pc/win simply is not good enough. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9441
Don Husby wrote: > > Jeff Sampson <jsampson@pobox.com> wrote: > > If I dig through the Xilinx documentation long enough, will I find the > > mapping of the setup ROM to the FPGA bits? In other words, could I > > program these parts by hand? Bit by bit. > > BEGIN standard_xilinx_bitfile_format_thread [Summary deleted] > END I had seen snipits of these threads but I hadn't seen my exact question asked. > Maybe this should be a FAQ? Actually it would. Well at least for Newbies. :-) Is there a FAQ for this group? I'll guess I'll just poke around at it if I get bored. Thanks, -- Jeff Sampson Minneapolis, MN, USA (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) jsampson@pobox.com jsampson@citilink.com http://www.pobox.com/~lcd_infoArticle: 9442
Russell Petersen wrote: > rk wrote: > > > > Zoltan Kocsi <root@127.0.0.1> wrote in article > > <m390qhk9ln.fsf@tade.bendor.com.au>... > > : "rk" <stellare@erols.com.NOSPAM> writes: > > : > > : > systems with differing capabilities with differing prices. a > market-driven > > : > environment, to a certain extent. and it won't let companies sit on > their > > : > butts, selling the same stuff for high prices year after year. i see the > > > : > ambit ads, don't know what they charge, but they're slamming synopsys in > > : > them. very agressive. they want business. and they can get it in two > > : > ways: take away synopsys customers for price/performance/standards > reasons > > : > or be low enough in price to get other people into the business or just > > : > sell multiple seats to make a better engineering environment. perhaps > > : > someone with some good info on ambit can comment. > > : > > : Hm. You can take a look at Symplicity's stuff. You can buy their synthesis > > : for HP or Sun at AU$24k + 1 year compulsory maintenance. You can buy the > > : exact same thing for Win AU$12k apiece (no contract). > > : Why ? > I am not justifying it, but a vendor does have different costs associated with development on different platforms. Of course, the cost of a software development system is probably a very small portion of a vendor's real costs! > > : On the lower end: > > : Actel's tools (VHDL synthesis and P&R) for Sun: AU$3.4k > > : For Win: AU$1.7k (or free from the net with limited choice of chips). > > : > > : Or you can see Quicklogic: > > : > > : Sun: AUD$3k contains P&R > > : Win: AUD$3k contains P&R, verilog simulator, editor and the Symplicity > > : synthesis (verilog/VHDL). > > : > > : Motorola P&R for Win is free (they even send you the CD for free), for > > : Sun it is not. > > : > > : AFAIK others are not much different either. > > : > > : Knowing that most of these tools are made under unix then ported to > > : Win I can't really see the reason for pricing the Win tools way > > : below the unix ones unless Mr. Gates offers some compensation (I'm > > : not accusing, I'm just wondering ...) > > : > > : As for having a cheap engineering platform then Linux is just as adequate > > : as Win - it is even cheaper and more stable. In addition porting unix SW > > : to Linux is uncomparably simpler than to Win. Still, Linux is not on the > > : EDA palette yet. > > : > > : Can you explain that ? > > : > > : Zoltan > > > > rk: > > > > that's the question and the pattern and what we've been discussing. > > according to synopsys, who is porting from unix --> win and not from unix > > --> linux, it's because no customer demand for linux. and someone posted > > that "Mr. Gates" is offering help. and, i believe, ports to linux from > > unix will mostly transfer unix users to linux. similar # of customers, two > > platforms to support. win can bring in new customers and there are a lot > > more win machines. > > Is this really true? I mean, who are these new users? I would > basically > think that there are a fixed number of people out there wanting to use > electronic EDA tools at a given time whether they are on Unix or Win > machines. > In other words, I don't think that just because Synopsys is now > available > on a Win NT machine there are going to be a lot of people saying, "Hey, > maybe I should buy that there synthesis package and make me a chip." :) > Also, why should it be cheaper on NT than on Unix? That is, unless it > does not work as well on NT. :) > > -- > Russell J. Petersen ***** ***** > ..snip.. > email: russp@valhalla.fc.hp.com > All opinions are my own, of course, and reflect nothing about HP. You assume that the new users are people that aren't doing design work of this type. But vendor A can get vendor B's Windows customers only if vendor A has a Windows product. Even so, there are some number of designers that work with other solutions. If there is some addition inducement (or the elimination of a perceived obstruction), a designer could move from a CPLD to an FPGA or from an FPGA to a gate array... A lot of engineers (the hardware types) cut their teeth on DOS and Win3.1. They are now comfortable with Win95 and/or Win NT. They don't know diddly about Unix and it scares them. Not scares like the "big bad wolf". But they will stay with a lower end solution to their design problem if they think using the tools for a higher end solution have a steeper learning curve. Certainly learning to use a new operating system makes the learning curve steeper. I work in a center where almost all the software people disdain the MicroSoft products. But we mainly use them for everything other than software development. The hardware people (as well as the support staff) get a warm fuzzy from Windows for now. So I would say, "Build it (under Windows) and they will come!" Excuse my dramatic flair... Rick CollinsArticle: 9443
This is a multi-part message in MIME format. --------------35E1A509F30DD170ED7DB372 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff Sampson wrote: > Don Husby wrote: > > > > Jeff Sampson <jsampson@pobox.com> wrote: > > > If I dig through the Xilinx documentation long enough, will I find the > > > mapping of the setup ROM to the FPGA bits? In other words, could I > > > program these parts by hand? Bit by bit. > > > > BEGIN standard_xilinx_bitfile_format_thread > > [Summary deleted] > > > END > > I had seen snipits of these threads but I hadn't seen my exact question > asked. > > > Maybe this should be a FAQ? > > Actually it would. Well at least for Newbies. :-) > > Is there a FAQ for this group? > > I'll guess I'll just poke around at it if I get bored. > > Thanks, > > -- > Jeff Sampson Minneapolis, MN, USA > (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) > jsampson@pobox.com jsampson@citilink.com > http://www.pobox.com/~lcd_info Jeff: Look in the Xilinx Databook. The "latest" book 1/98 page 4-50 lists the most information I've seen in public print. Xilinx doesn't want the public to know what each bits does. They are attempting to keep their customer designs secure by keeping this aspect of the technology propriatary. Since the early days of Xilinx, when I was one of their FAEs, I've known a few folks that have back engineered parts of the bit stream on a lark. One is prompted to ask why you'd need such information.... perhaps there's another, possibly more standard, approach to solving your problem. -- Ed McCauley Bottom Line Technologies Inc. Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, 908) 996-0817 FAX: (908) 996-0817 --------------35E1A509F30DD170ED7DB372 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ed McCauley Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Ed McCauley n: McCauley;Ed org: Bottom Line Technologies Inc. email;internet: edmccauley@bltinc.com title: President x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------35E1A509F30DD170ED7DB372--Article: 9444
<snip> rk: : > : > that's the question and the pattern and what we've been discussing. : > according to synopsys, who is porting from unix --> win and not from unix : > --> linux, it's because no customer demand for linux. and someone posted : > that "Mr. Gates" is offering help. and, i believe, ports to linux from : > unix will mostly transfer unix users to linux. similar # of customers, two : > platforms to support. win can bring in new customers and there are a lot : > more win machines. russell: : Is this really true? I mean, who are these new users? I would basically : think that there are a fixed number of people out there wanting to use : electronic EDA tools at a given time whether they are on Unix or Win machines. : In other words, I don't think that just because Synopsys is now : available on a Win NT machine there are going to be a lot of people saying, "Hey, : maybe I should buy that there synthesis package and make me a chip." :) : Also, why should it be cheaper on NT than on Unix? That is, unless it : does not work as well on NT. :) rk: simple. as described in another post, me, small business person (or at day job in a small group), generally won't fork over $95k or $150k or whatever for tools unless it's needed. at day job, i *have* done that, but not frequently. for small business, high-priced tools, i'm not in business and would never have started it. so, low-price, pc/win, enables me to get into business. that 'creates' seats. and at day job, everybody gets what they need since tools are low cost, affordable, and relatively easy to use. gets more people designing with eda. the amount of engineers designing with eda is definitely not fixed. i see more and more engineers all the time adding eda tools for designing their own chips. and more and more people starting their own small businesses and consultant shops, esp. with the mass lay offs we've seen over the past decade. and they are not spending $100k and up per seat. maybe hp can do that for its engineers, and they do put out free donuts and tea every day, but not typical for a small business or group. in the unix --> linux port case i would agree with you. this would not generally create any customers and would probably move a few unix users over to pc/linux, those who need to "carry their cpu cycles with them." and unix die hards generally hate win. with a passion. ;) and win people would have a hassle as all their other s/w won't run on linux. now for synopsys, will they grow with win (makes a nice example)? interesting article in ee times, early march, this move was described as a 'NOP.' i agree with that. very expensive. and if one wanted an expensive tool, yes, one would have it already as j.c. pointed out in the article, and one would have the unix boxes for it, too. but, if it's affordable, and i have to choose between, for the sake of argument, synplicity and synopsys, and they were in the same price range, i would go with synopsys to make similar environments for both pc and unix, where synopsys is the standard on our (day job) unix workstations to save training costs. and with their announced license plan, this would work. but with the intent on charging the same for win and unix seats, i don't think it will generate new seats for them and perhaps just transfer a few. unless they have a big corporate account lined up which demands s/w on win. and many companies will spin new versions of s/w for a large customer promising a big sale. why should it be cheaper on win? well, like the thread has shown, s/w is traditionally cheaper on win, even for the same version and functionality! the example, snipped from above, is synplicity on workstation was $24k, on win $12k, and bundled w/ quicklogic and other eda s/w, (see same issue of ee times), $3k total. volume. competition. (the following is general and does not apply necessarily to synopsys, which we've been using as an example. a rare disclaimer but thought i'd throw one in). the question is why is the unix s/w with such low manufacturing costs so expensive? low volume? needs a lot of support from app engineers? no competition? got people locked into a proprietary solution and can take advantage? a niche product that is a few per cent better but has *much* higher development cost? avoids public standards so everything and all libraries are custom; or, just to give you a little elbow to the ribs, is unix that hard to program? btw, i have used dos and unix for many years, win for a few, in case you haven't followed the thread. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9445
Peter Alfke wrote: > > Jeff Sampson wrote: > > So, is this info available? Or is this another one of those closely > > guarded secrets? > Figuring out the meaning of 46,000 bits is a formidable task, ... > A low-cost student version of the software is available at Amazon for > less than $70.-, but it does not cover XC2000 and XC3000 devices. I tracked down the listing at amazon.com and then found a real description at xilinx.com. I will try to get a copy of this. But it still dosen't solve my problem eith the chips I already have. (Which was my whole point.) > Hand-assembling 46,000 bits is not a realistic alternative. Not if you already have the software to do it. Making PC boards in a kitchen sink is not realistic either, but people still do it. :-) Thanks for the info, -- Jeff Sampson Minneapolis, MN, USA (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) jsampson@pobox.com jsampson@citilink.com http://www.pobox.com/~lcd_infoArticle: 9446
Ed McCauley wrote: > > Jeff Sampson wrote: > > > Don Husby wrote: > > > > > > Jeff Sampson <jsampson@pobox.com> wrote: > > > > If I dig through the Xilinx documentation long enough, will I find the > > > > mapping of the setup ROM to the FPGA bits? In other words, could I > > > > program these parts by hand? Bit by bit. > > > > > > BEGIN standard_xilinx_bitfile_format_thread > > > > [Summary deleted] > > > > > END > > > > I had seen snipits of these threads but I hadn't seen my exact question > > asked. > > > > > Maybe this should be a FAQ? > > > > Actually it would. Well at least for Newbies. :-) > > > > Is there a FAQ for this group? > > > > I'll guess I'll just poke around at it if I get bored. > > > > Thanks, > > > > -- > > Jeff Sampson Minneapolis, MN, USA > > (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) > > jsampson@pobox.com jsampson@citilink.com > > http://www.pobox.com/~lcd_info > > Jeff: > > Look in the Xilinx Databook. The "latest" book 1/98 page 4-50 lists the most > information I've seen in public print. Xilinx doesn't want the public to know > what each bits does. They are attempting to keep their customer designs > secure by keeping this aspect of the technology propriatary. Since the early > days of Xilinx, when I was one of their FAEs, I've known a few folks that have > back engineered parts of the bit stream on a lark. > > One is prompted to ask why you'd need such information.... perhaps there's > another, possibly more standard, approach to solving your problem. > > -- > Ed McCauley > Bottom Line Technologies Inc. > Specializing Exclusively in Xilinx Design, Development and Training > Voice: (500) 447-FPGA, 908) 996-0817 > FAX: (908) 996-0817 > > --------------------------------------------------------------- I think the "more standard approach" is to lay out the cash for the design software which supports these chips. :-) The reason is this, I just finished a design for a video digitizer which was done on protoboards. So I had several protoboards, lots of TTL chips and miles of wire. (It seemed like miles!) It occurred to me that defining a path through an FPGA was very similar to wiring a prototype circuit. You have to pick a gate, assign a connection to the gate input and assign a connection to the gate output. (Like you do with PLD equations.) Instead of placing a physical wire, you would place a virtual connection in a configuration. Of course I wouldn't set/clear actual bits in a raw bitmap matrix, but have a small translator convert the netlist to the configuration map. Or maybe graphically, like routing a PC board. I probably wouldn't end up with a dense design when I was done, but the chips have far more parts than I need. (At least at this point.) And someone will say "alot of work for a few hundred dollars worth of scrap parts" and rightfully so. However the old Xilinx parts are being scrapped as technology moves on. And there will be alot of them. And they are fully reprogrammable. The ones I found were even socketed. So maybe I'm crazy... I've done dumber things! -- Jeff Sampson Minneapolis, MN, USA (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) jsampson@pobox.com jsampson@citilink.com http://www.pobox.com/~lcd_infoArticle: 9447
Jeff Sampson wrote: > Ed McCauley wrote: > > > > Jeff Sampson wrote: > > > > > Don Husby wrote: > > > > > > > > Jeff Sampson <jsampson@pobox.com> wrote: > > > > > If I dig through the Xilinx documentation long enough, will I find the > > > > > mapping of the setup ROM to the FPGA bits? In other words, could I > > > > > program these parts by hand? Bit by bit. > > > > > > > > BEGIN standard_xilinx_bitfile_format_thread > > > > > > [Summary deleted] > > > > > > > END > > > > > > I had seen snipits of these threads but I hadn't seen my exact question > > > asked. > > > > > > > Maybe this should be a FAQ? > > > > > > Actually it would. Well at least for Newbies. :-) > > > > > > Is there a FAQ for this group? > > > > > > I'll guess I'll just poke around at it if I get bored. > > > > > > Thanks, > > > > > > -- > > > Jeff Sampson Minneapolis, MN, USA > > > (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) > > > jsampson@pobox.com jsampson@citilink.com > > > http://www.pobox.com/~lcd_info > > > > Jeff: > > > > Look in the Xilinx Databook. The "latest" book 1/98 page 4-50 lists the most > > information I've seen in public print. Xilinx doesn't want the public to know > > what each bits does. They are attempting to keep their customer designs > > secure by keeping this aspect of the technology propriatary. Since the early > > days of Xilinx, when I was one of their FAEs, I've known a few folks that have > > back engineered parts of the bit stream on a lark. > > > > One is prompted to ask why you'd need such information.... perhaps there's > > another, possibly more standard, approach to solving your problem. > > > > -- > > Ed McCauley > > Bottom Line Technologies Inc. > > Specializing Exclusively in Xilinx Design, Development and Training > > Voice: (500) 447-FPGA, 908) 996-0817 > > FAX: (908) 996-0817 > > > > --------------------------------------------------------------- > > I think the "more standard approach" is to lay out the cash for the design software > which supports these chips. :-) > > The reason is this, I just finished a design for a video digitizer which was done > on protoboards. So I had several protoboards, lots of TTL chips and miles of wire. > (It seemed like miles!) It occurred to me that defining a path through an FPGA was > very similar to wiring a prototype circuit. You have to pick a gate, assign a > connection to the gate input and assign a connection to the gate output. (Like you > do with PLD equations.) Instead of placing a physical wire, you would place a > virtual connection in a configuration. Of course I wouldn't set/clear actual bits > in a raw bitmap matrix, but have a small translator convert the netlist to the > configuration map. Or maybe graphically, like routing a PC board. > > I probably wouldn't end up with a dense design when I was done, but the chips have > far more parts than I need. (At least at this point.) > > And someone will say "alot of work for a few hundred dollars worth of scrap parts" > and rightfully so. However the old Xilinx parts are being scrapped as technology > moves on. And there will be alot of them. And they are fully reprogrammable. The > ones I found were even socketed. > > So maybe I'm crazy... I've done dumber things! > > -- > Jeff Sampson Minneapolis, MN, USA > (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) > jsampson@pobox.com jsampson@citilink.com > http://www.pobox.com/~lcd_info Yes, I would agree that you are crazy. I always try to be agreeable. Actually, the work you are talking about in writing a program to map the design to CLBs and perform the routing between them is an enormous task. The reason that Xilinx has to charge so much for the software is because they have dozens if not hundreds of people working to design and support this software. This routing problem is one that entire companies have been founded to solve. Neocad made their entire living on their router. Anyway, you can get this software for $99. I bought a copy to play with at home myself. If you can't afford 99 bucks to work with Xilinx parts, then you won't be able to afford the price of an eprom programmer or many other tools that just aren't worth the effort to make yourself. They even have a VHDL package for $495. This is an incredible bargain too. Both packages have limits on the size of the parts you can work with, but that limit is much larger than any design you would ever do by hand. Rick Collins redsp@yahoo.comArticle: 9448
On Fri, 13 Mar 1998 12:14:11 -0800, Peter Alfke <peter.alfke@xilinx.com> wrote: >There are over 46.000 configuration bits in the XC3064 ( proportionally >fewer in the smaller parts), and their function is indeed a "closely >guarded secret". >First and foremost this is to protect our customers, so that their >competitors cannot reverse engineer any FPGA design, where the bitstream >is openly accessible. maybe so, but it would be useful to have some more information; in particular, the location of the bits that define the contents of a ROM module. i had a design recently that included a microcoded controller. the microcode was stored in a rom module, created via logiblox. with this sort of design you have to change the rom contents occasionally, to (a) make it work, and (b) carry out simulations, with simplified test microcode. however, it seems that the only way you can do this is to recreate the logiblox module with a different MEM file. this meant that i had to go through the entire P&R procedure for each iteration, which could take several hours. there was also the risk (admittedly small) that the route would fail with new rom data. when i asked xilinx tech support if there was a better way of doing this, the reply was (a) "why would you want to change a rom?", and (b) "why don't you use a ram instead?" the best solution, of course, is to have a utility to edit the bit file directly. i would have written this myself if the required information hadn't been "a closely guarded secret". evan (ems@nospam.riverside-machines.com)Article: 9449
This is a multi-part message in MIME format. --------------2D060D191BF8C847E09E1852 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Jeff: > > > > Look in the Xilinx Databook. The "latest" book 1/98 page 4-50 lists the most > > information I've seen in public print. Xilinx doesn't want the public to know > > what each bits does. They are attempting to keep their customer designs > > secure by keeping this aspect of the technology proprietary. Since the early > > days of Xilinx, when I was one of their FAEs, I've known a few folks that have > > back engineered parts of the bit stream on a lark. > > > > One is prompted to ask why you'd need such information.... perhaps there's > > another, possibly more standard, approach to solving your problem. > > > > -- > > Ed McCauley > > Bottom Line Technologies Inc. > > Specializing Exclusively in Xilinx Design, Development and Training > > Voice: (500) 447-FPGA, 908) 996-0817 > > FAX: (908) 996-0817 > > > > --------------------------------------------------------------- > > I think the "more standard approach" is to lay out the cash for the design software > which supports these chips. :-) > > The reason is this, I just finished a design for a video digitizer which was done > on protoboards. So I had several protoboards, lots of TTL chips and miles of wire. > (It seemed like miles!) It occurred to me that defining a path through an FPGA was > very similar to wiring a prototype circuit. You have to pick a gate, assign a > connection to the gate input and assign a connection to the gate output. (Like you > do with PLD equations.) Instead of placing a physical wire, you would place a > virtual connection in a configuration. Of course I wouldn't set/clear actual bits > in a raw bitmap matrix, but have a small translator convert the netlist to the > configuration map. Or maybe graphically, like routing a PC board. > > I probably wouldn't end up with a dense design when I was done, but the chips have > far more parts than I need. (At least at this point.) > > And someone will say "alot of work for a few hundred dollars worth of scrap parts" > and rightfully so. However the old Xilinx parts are being scrapped as technology > moves on. And there will be alot of them. And they are fully reprogrammable. The > ones I found were even socketed. > > So maybe I'm crazy... I've done dumber things! > > -- > Jeff Sampson Minneapolis, MN, USA > (Toshiba T6963 and EPSON/SMOS SED1330 LCD Controllers) > jsampson@pobox.com jsampson@citilink.com > http://www.pobox.com/~lcd_info Well "So maybe I'm crazy... I've done dumber things!"............................. 1. Call and get the most recent pricing on their tools. I think you'll find it is a FAR better deal than you think. 2. On BIG advantage the "standard way" will provide is a documented, maintainable, UNDERSTANDABLE design! Re: the older parts.... beleive it or not, the older parts are still in demand. LOTS of designs out there using 2000 and 3000 series silicon. Best of luck to you. Let me / BLT / the group know if there is anything else we can do for you. -- Ed McCauley Bottom Line Technologies Inc. Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, 908) 996-0817 FAX: (908) 996-0817 --------------2D060D191BF8C847E09E1852 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ed McCauley Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Ed McCauley n: McCauley;Ed org: Bottom Line Technologies Inc. email;internet: edmccauley@bltinc.com title: President x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------2D060D191BF8C847E09E1852--
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