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
Topic: Upcoming Seminars and Events for FPGA Users April, 1998 =========== IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM'98) 15-17 April, 1998, Napa Valley, California, USA. Cypress Semiconductor's VHDL Primer, 9 April, 1998. Web-based seminar requires pre-registration and download. Find out more on The Programmable Logic Jump Station at http://www.optimagic.com/conferences.html#Apr98.Article: 9476
You can evaluate our tools for free at: http://www.associatedpro.com/aps Stephen King wrote: > 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.uk -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9477
A fairly simple project might be connectiong some AtoD converters to the FPGA and filtering the inputs in the FPGA. You could then send them back through D to As and into speakers or an oscilloscope or spectrum analyzer. For low cost tools and examples in order to complete your project you might check our website at: http://www.associatedpro.com/aps Antonio Rosa wrote: > Hi, i would like to develop an one semester project with an FPGA. > This project should make something with advantages when compared to > microcontrollers/microprocessors such as working with multiple > sensors.... does anybody has an idea? > > Thanks! > Antonio Rosa > > > p.s: please email the idea > > > > mail: arosa@mail.telepac.pt -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 9478
Here's an upcoming event you may be interested in: Praegitzer Technical Symposium May 12, 1998, 7:30 a.m. - 3:00 p.m. Sheraton Tara Hotel , Nashua, NH An all-day event featuring discussions on important issues and trends in the PCB industry. Admission is free but space is limited to the first 400 respondents. Email symposium@pii.cOm to reserve your seat today. For more information, please contact Sonya Seyle via phone at 503.221.7421 or email at sonya_seyle@kvo.c*m Be sure to visit Praegitzer's Web site at http:www.pii.c*m (Please replace "*" with an "o") -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9479
Its hard to call companies like Xilinx "Meanies" for keeping its bitmaps secret. It really ends up more a matter of protecting the customer. With a bit of time and test cases one can use the Xilinx software to decode the memory map. I'm aware of several people who have (at least one disasterously). But the real issue is wheither an FPGA user can take advantage of it. One not only needs to know what the bits does, but how the device is programming those bits. There are a number of "illegal" programming combinations (things that cause Vdd shorts!) for all FPGAs and knowing the memory bitmap doesn't help you here. Knowing the bitmap and the programming personality is what the software is for. Besides...how many people still pro gram their computers in octal.Article: 9480
I was once working on such an application. It was almost like the post that needed to change a ROM. The one I was working on was an array processor where each processor element needed to have a look-up table programmed into it. But as mentioned, it isn't hard to find ROM tables and stuff the bits into the bitstream. However, the design also needed a 16 bit binary adder to add a constant. To do this required finding the bits in the carry logic, and modifying them to change the constant. The extra logic to store these constants (16 16 bit constants per XC4013) was not available. However, the project never got built, so I didn't need to find out where those bits were. I do believe, though, that this is close to the "uncommon" application mentioned. The required bits would be generated by a program, based on an input file, so documentation would not be a problem. -- glen Ed McCauley <edmccauley@bltinc.com> writes: >This is a multi-part message in MIME format. >--------------733CC5D50035A2854133574D >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit >For all the "uncommon" applications so far presented, a modification of the >original source followed by an M1 or PPR run with the guide option would have >addressed the situations. Standard, readable source, no long run times, >consistent placement and timing results.Article: 9481
This is a multi-part message in MIME format. --------------8B3ED71EEFE7B10CC7B9466E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G. Herrmannsfeldt wrote: > logic, and modifying them to change the constant. The extra logic to > store these constants (16 16 bit constants per XC4013) was not available. Another solution could have been to create 1 16 bit rom (8 CLBS, 4013 has 576) and simply apply the appropriate 4-bit address to select the needed constant. Another could have been a 16-bit register that the uP could write to. Another could have been a 16-bit RAM (8 or 16 CLBs depending on single or dual-port) that the micro could write thus loading 16 constants at uP speeds and then allowing the micro OR the Hardware to select which of the 16 constants to use. ...... just throwing out food for thought for those currently in process ........ -- 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 --------------8B3ED71EEFE7B10CC7B9466E 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 --------------8B3ED71EEFE7B10CC7B9466E--Article: 9482
Peter Alfke <peter.alfke@xilinx.com> wrote: > The designer who created the FPGA-based design obviously knows what's > going on in the design, and the GUI can show it in excruciating detail. > Giving him/her the meaning of gezillion configuration bits adds no new > information. Only the rip-off artist would profit... This is not true. Several people have posted applications where it would be very helpful to have access to the bit-stream mechanics. I, for one, face a problem where I will have 1024 front-end FPGA chips that will gather data and encode it. Each of these chips is nearly identical with the exception of of a few ID bits and translation tables. Now, one could imagine a bunch of ways of maintaining this, but none of them would be as simple and elegant as having software-level access to the bitstream generation. If Xilinx wants to do more than pay lipservice to the concept of reconfigurable computing, it will eventually have to provide such a facility. Note that this doesn't mean that I want to disassemble existing bits streams. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9483
In article <6ekihr$5j4@pumpkin.cdepot.net>, Mark Markham wrote: >Besides...how many people still program their computers in octal. To use your analogy, there is still a lot of people who : - debug programs are asm level - try to make compilers/assemblers better OG.Article: 9484
Don Husby wrote: > .......Several people have posted applications where it would > be very helpful to have access to the bit-stream mechanics. I, for > one, face > a problem where I will have 1024 front-end FPGA chips that will gather > data > and encode it. Each of these chips is nearly identical with the > exception of > of a few ID bits and translation tables. The location of the look-up table bits has always been available from Xilinx ( under non-disclosure, but I am working on simplifying that ) . There are not many requests, perhaps it is not widely known. The remaining 90% of the configuration bits control the interconnect structure ( remember: "We sell interconnect, the logic is free") are not divulged. So I think we can satisfy every reasonable requirement. Peter Alfke, Xilinx Applications.Article: 9485
Princeton Information < www.princetoninformation.com > is seeking Ten (10) Senior Digital Design Engineers............ Digital FPGA Hardware Engineer -High Speed Digital Modem Technology Job Description: You will participate in the design and development of a flexible communications system breadboard utilizing FPGA's (ASIC) for Motorola's Celestri (tm) Modem Technology development program. These are specialized high-speed modems (Mbps) installed in satellites. Celestri is a multi-year, $13 billion project that will provide high-bandwidth packet switching - connections (e.g., internet) in outer SPACE!!! Celestial Data Communications for the 21st Century!!! BS/MS in Electrical Engineering +4 to 6 years of experience required. Familiarity with FPGA based design limitations and mitigation methods. Willingness to accept responsibility & technical challenge Ability to work independently and on a team Focus on customer satisfaction Location: Phoenix/ Chandler, AZ Duration: Full Time Salary and Temp to Permanent or out right contract consulting Pay Rate: Open See our Website: < www.princetoninformation.com > Email your resume TODAY!!! => < clientserver@msn.com > Princeton Information 1201 South Alma School #1125 Mesa, Arizona 85210 (602) 655-7600 FAX => (602) 655-7052Article: 9486
SENIOR SOFTWARE ENGINEER POSITION Ricoh Silicon Valley is engaged in an innovative image computing project involving FPGAs. We have need for a Senior Software Engineer to join a small team of hardware and algorithm specialists in research in novel FPGA-based reconfigurable computing. The complete job description of duties and responsibilities can be viewed at our Web site at: http://www.crc.ricoh.com/jobs/ssejob.html To apply, please fax resumes to 650-854-8740, Attn: HR dept., or send e-mail to jobs@crc.ricoh.com. We will attend FCCM'98 in Napa Valley, CA April 15-17, and would be happy to meet applicants at that time. The California Research Center of Ricoh Silicon Valley, Inc. is a small lab focusing on information technologies for future office automation environments, such as image compression, uses of the world wide web and document technologies. The lab is very close to Stanford University and in easy driving distance to San Francisco, San Jose, and Santa Cruz, and many Bay Area natural and cultural attractions. Ricoh Silicon Valley is an equal opportunity employer and encourages qualified women and minorities to apply. Applications must already be qualified to work in the USA. Further information is available at: http://www.crc.ricoh.com. Specific questions can be addressed to mbaxter@rsv.ricoh.comArticle: 9487
Don Husby wrote: > Peter Alfke <peter.alfke@xilinx.com> wrote: > This is not true. Several people have posted applications where it would > be very helpful to have access to the bit-stream mechanics. I, for one, face > a problem where I will have 1024 front-end FPGA chips that will gather data > and encode it. Each of these chips is nearly identical with the exception of > of a few ID bits and translation tables. > > Now, one could imagine a bunch of ways of maintaining this, but none of them > would be as simple and elegant as having software-level access to the > bitstream generation. If Xilinx wants to do more than pay lipservice to the > concept of reconfigurable computing, it will eventually have to provide such > a facility. > > Note that this doesn't mean that I want to disassemble existing bits streams. I guess I am missing something. Why can't you diddle the bits for the ID and translation tables using the XACT design editor? This tool allows you to edit by hand the LUT contents, the CLB configuration and all of the interconnect. Why is this not sufficient for your needs? Certainly you can generate a unique bitstream from the XNF file (or what ever it is at this point in the design process). The only limitation would be going backwards from the bitstream to the XACT design editor. I doubt if Xilinx supports that. Rick Collins redsp@yahoo.comArticle: 9488
rk: : >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. stu: : But, does this have something to do with the long standing : relationship between Synplicity and Quicklogic. I wouldn't be : surprised if Quicklogic had some involvement at the start-up and so : lever appropriate access to the product at low (or possibly zero?) : cost. : : I presume it'll only support QL devices, and won't be upgradeable to : other vendors, will it? rk: hi stu, still can't quite fully answer your question as i don't know if synplicity bundles with any other vendors, but i do have more information about pricing for this product, giving us a nice sample. here are the relative price levels for the same product, with over an order of magnitude difference from top to bottom (iirc, top two lines are tied in $): unix pc/win - floating pc/win - node locked (1/2 the line above) pc/win - single vendor <---- new point, ~ 40% of line above (no discount on hdl analyst though) pc/win - bundled w/ q-logic s/w + tools ( $3k for the whole bundle) anyways, just some data. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9489
Hi, I am looking to use Ram capability in XC4000 family, How can I access and use it. e.g. for arithmatic operations. ThanksArticle: 9490
I=B4m looking for a SYNOPSIS synthesizable SDRAM-controller=20 - for up to 143 MHz clock frequency (an integrated PLL for programmable clock-rates would be great)=20 - and SDR support (DDR support would be great to) The macro will be implemented in 0.25um ASIC technology. Can somebody give me a contact address or company name? Thank you! Martin Vorbach martin.vorbach@scrap.de Fon +49 721 97243 35 Fax +49 721 97243 28Article: 9491
spamgoeshere1@yahoo.com wrote: > I guess I am missing something. Why can't you diddle the bits for the ID and > translation tables using the XACT design editor? This tool allows you to edit by > hand the LUT contents, the CLB configuration and all of the interconnect. Why > is this not sufficient for your needs? Certainly you can generate a unique > bitstream from the XNF file (or what ever it is at this point in the design process). > The only limitation would be going backwards from the bitstream to the XACT design > editor. I doubt if Xilinx supports that. As I said, there are many proposed solutions to this problem. The idea of editing 1024 versions of the chip with the Xact editor each time I make even a minor design change is probably the least desirable of any that I could think of. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9492
Oh, Thank you! Do you happen to have one for Viewlogic ;-) That is an even much more annoying key! I hear it can not be cracked...Article: 9493
we have found an organization called OpenIP to trade and exchange IP without any fee or only less fee. Main goal is the development of cores and IP by multiple parties, which exchange the source and development using a web page. For managing the development we use a configuration-management software sponsored by Perforce Inc. (http://www.perforce.com). Our starting project is the further development of the Amulet-software, which was developed until some months by Brad Myers et. al. from Carnegie Mellon=20 University (http://www.cs.cmu.edu/~amulet). Everybody, who is interested in participating on the development of = free cores and IP should contact me. Also developers or companies, which are able to=20 share developments for free or less fee should contact me. Also I=B4m interested in response by people which are looking for free cores, so that we can find out, which parts are required for developing. The development of the cores should be done using VERILOG or VHDL. BUT: WE DO NOT WANT TO TRADE OR EXCHANGE ILLEGAL OR HACKED SOFTWARE OR CORES. SUCH REQUESTS WILL BE REJECTED AND WE WILL CONTACT THE MANUFACTURER OF THIS PARTS! The organization is up to now sponsored by three parties 1. Realax Software AG, a virtual reality software company (http://realax.com) 2. Perforce Inc., which develops configuration-management software (http://www.cs.cmu.edu/~amulet) 3. SCRAP GmbH, which develops computer hard- and software. We are still looking for more sponsors. We are still using the SCRAP-homepage to start the project. Later on we will use a server by the address http://www.OpenIP.org, but this is still under development. Best regards Martin Vorbach martin.vorbach@scrap.de Fon +49 721 97243 35 Fax +49 721 97243 28Article: 9494
In article <350F2442.485B9D00@yahoo.com>,
Rick Collins <spamgoeshere1@yahoo.com> wrote:
>Don Husby wrote:
>
>> Peter Alfke <peter.alfke@xilinx.com> wrote:
>> This is not true. Several people have posted applications where it would
>> be very helpful to have access to the bit-stream mechanics. I, for one, face
>> a problem where I will have 1024 front-end FPGA chips that will gather data
>> and encode it. Each of these chips is nearly identical with the exception of
>> of a few ID bits and translation tables.
>>
>> Now, one could imagine a bunch of ways of maintaining this, but none of them
>> would be as simple and elegant as having software-level access to the
>> bitstream generation. If Xilinx wants to do more than pay lipservice to the
>> concept of reconfigurable computing, it will eventually have to provide such
>> a facility.
>>
>> Note that this doesn't mean that I want to disassemble existing bits streams.
>
>I guess I am missing something. Why can't you diddle the bits for the ID and
>translation tables using the XACT design editor? This tool allows you to edit by
>hand the LUT contents, the CLB configuration and all of the interconnect. Why is
>this not sufficient for your needs? Certainly you can generate a unique bitstream
>from the XNF file (or what ever it is at this point in the design process). The
>only limitation would be going backwards from the bitstream to the XACT design
>editor. I doubt if Xilinx supports that.
I think what he wants is to take all of the possible bitstreams for his
application (each generated with XDE), XOR them together and store the
differences from a "master" one. It would be a kind of compression...
Someone should write a program to automate this process... I.E., it would
generate a test design, run makebits and store the xor difference between
the result and a blank design. This would probably get you pretty close to
a reverse engineered bit-stream format. Then you just need to adapt a few
of those berkeley tools, and voila, a freeware xilinx design system :-)
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 9495> Which version of NT were you trying to run PeakVHDL on? Same as you... NT 4.0 with SP 3. > I have been using > PeakVHDL (4.21a) on NT4 + service pack3 for some time now and it is more stable > than some of Microsoft's own products. As described in the service pack 3 > readme file you have to reinstall the service pack each time you install a new > application. You only have to reinstall SP 3 each time you install a new application that overwrites something that SP 3 upgraded! Anyway, David Pullerin from Accolade can reproduce it and is busily investigating its cause. He's been working at it for awhile now, and if it were as simple as reinstalling service pack 3, I think he would already have it licked. ---Joel KolstadArticle: 9496
Greetings, I am trying to make an xchecker download program to run on Linux. I have found the schematics on Xilinx's web page, but can find no information on any of the "commands" that are obviously being stored in the XC3042 and/or SRAM. Any help you can provide would be appreciated. Thanks in advance. -- Tony L. Keiser The Department of Electrical and Computer Engineering The University of Illinois in Urbana-Champaign <a href="http://www.students.uiuc.edu/~akeiser">Lame Page</a>Article: 9497
Hi, I would like to know if anyone else has been using the cypress ISR (in-circuit reprogrammable) CPLDs and would have any comments on their download cable device programmer and programming the devices in general. One thing I have found is that the error messages from the programming software are innaccurate, but I won't be able to try programming a device until I can get a prototype board built - and I don't want to commit to the cypress part in my design if it turns out their system is flaky. Any comments appreciated, -RobArticle: 9498
"Rob Semenoff" <robert_semenoff@phoenix.com> writes:
>Hi,
>I would like to know if anyone else has been using the cypress ISR
>(in-circuit reprogrammable) CPLDs and would have any comments on their
>download cable
>device programmer and programming the devices in general.
>One thing I have found is that the error messages from the programming
>software are
>innaccurate, but I won't be able to try programming a device until I can
>get a
>prototype board built - and I don't want to commit to the cypress part in
>my design
>if it turns out their system is flaky.
>Any comments appreciated,
>-Rob
I've used them and they seem fine. Make SURE you put a decoupling
capacitor (0.1uF or so) on the programming voltage pin on your side
(near your part).
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9499Antonio Rosa wrote: > Hi, i would like to develop an one semester project with an FPGA. > This project should make something with advantages when compared to > microcontrollers/microprocessors such as working with multiple > sensors.... does anybody has an idea? > > Thanks! > Antonio Rosa > > > p.s: please email the idea > > > > mail: arosa@mail.telepac.pt Something I have wanted to do for a long time is to make a pulse width modulated analog output from a digital signal. For this you will need a very high speed clock. 100 MHz is not too high. The samples that you want to D to A are loaded into a counter and counted down. A second counter counts through the maximum period. The first counter outputs a 1 until it reaches a count of 0 when it outputs a 0. This output remains at 0 until the second counter reaches a count of 0. Then the next sample is loaded and the process repeats. This will produce a pulse with an average DC level proportional to the sample loaded into the counter. With an appropriate low pass filter on the output, this should produce reasonable sound without analog amplifiers. The limitation of this design is that you need an extremely high speed clock to reach the upper limit of human hearing with reasonable dynamic range. For example, 16 bits require 65536 clock pulses per sample X 40,000 sample per second = 2,560,000,000 Hz or 2.5 GHz clock speed. But at telephone quality, 12 bits, 4,096 x 8,000 = 32,000,000 Hz or 32 MHz. This is within the range of an FPGA. It would allow the production of audio without ADC, analog amps, ect. A simple LC filter should be enough to smooth the output. This can be improved by using a pulse train that interleaves the 1's and the 0's of each clock cycle to produce a higher speed pulse train than the audio sample rate. This could be a very good class project. Rick Collins redsp@yahoo.com
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