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
For those interested, I have a list of various FPGA-based boards at: http://www.netcom.com/~optmagic/index.html#Boards -- Steven Knapp E-mail: optmagic@ix.netcom.com Programmable Logic Jump Station: http://www.netcom.com/~optmagic Steve Nordhauser <nords@intersci.com> wrote in article <3331C41C.189@intersci.com>... | Richard Schwarz wrote: | > | > Stuart Clubb wrote: | > | > Try Aptix at: | > http://www.aptix.com | > | > Probably not cheap, but looks_real_nice. :-) | > | > Take a look at | > http://www.erols.com/aaps . | > | > The ST-FPGA module has 4 XILINX 208pin QFP chips and a ton of IO pins. | > The board was originally developed for ASIC design testing.You can put | > whatever type chips you want on the boards. | | I'm using a board from Giga Operations that is very expandable. | Their support is excellent and the features are very useful. | http://www.gigaops.com | | Steve Nordhauser |Article: 5876
Sorry for a minute, but i'm starting to work with xilinx xc4003A. I have a serial prom xc1765 on the board near the fpga and I made some connections (if I understood ...) between the chips in agreement with xilinx "Programmable Logic Data Book" (PLDB) using "Master Serial Mode" programming scheme. These connection are (/ means a low active pin): FPGA PROM /progr (pin 55) -------> reset (pin 4) done (pin 53) -------> /ce (pin 3) din (pin 71) -------> data (pin 1) cclk (pin 73) -------> clk (pin 2) PBLD suggests to use a pull-up resistor (2 to 8 kohm) on done pin of FPGA. But my FPGA doesn't work !!!!!! I think that the prom send correctly its program inside the FPGA (i see the bitstream on a scope), then the prom goes in idle state and the FPGA too !!! After this step nothing happen ...... Any suggestion ????? P.S. sorry for my english !!!!Article: 5877
In article <33320105.7612@sr.hp.com>, Greg Quintana <gregq@sr.hp.com> wrote: > Anyone have equations for FIFOs that could be used in a xilinx part? > -- I wrote and published an app note: Synchronous and asynchronous FIFO Designs, which is available on our web-site ( www.xilinx.com ) look under XC4000 app naotes. Here is the performance: 16 x 16 uses 23 CLBs, runs at 65 MHz synchronously ( read and write clock are the same ) or at 50 MHz asynchronously. Both cases allow simultaneous full-speed read and write. Yes, there is asynchronous arbitration. 32-deep, 8-wide takes 28 CLBs and runs at 50 MHz and 40 MHz as descibed above. 64 x 8 uses 48 CLBs and runs at the same 50 or 40 MHz, Just to give you a feel. If you are interested, sned me e-mail, and I can fax you some improvements. Sorry, no VHDL, but the memory design is very straightforward, and the controller, although clever, I think :-), is really quite simple. It can be implemented in any XC4000E, or XC4000EX, or the new XC4000XL ( 3.3-V) parts, and will operate faster on these upcoming -2 and -1 devices. Peter Alfke, Xilinx ApplicationsArticle: 5878
In article <5gs1aq$pjv@waterloo.algor.co.uk>, rick@camden.algor.co.uk (Rick Filipkiewicz) wrote: > Much worse than not having a second source for the physical parts is having > the FPGA vendor as the only source for the Place&Route tools. While I can understand your desire to have a second source for your contiinuing purchases of components, (for reasons of assured availabilty and lowest possible pricing), I fail to see your disappointment in a single source for the tools. When you buy them from the component supplier, you can be sure that they are as close as possible to the real silicon, as up-to-date as possible, and you are also buying a heavily subsidized piece of software. There should be no doubt about it: The major FPGA houses sell their software tools at a bargain basement price, a price that does not really do justice to the development cost ( plus whatever royalties must be paid ). As you know, there once was a company called NeoCad who tried to develop and sell software without any subsidy from the silicon, and they did not survive. It became pretty obvious that you cannot sustain a 50-(wo)man development effort on the kind of software revenues that this market is willing to provide. You need an income of 15 to 25 million dollars per year, otherwise you fall below critical mass. ( These numbers are my estimates, not authorized by Xilinx ). Peter Alfke, Xilinx ApplicationsArticle: 5879
Johannes Soelhusvik wrote: > > Does anyone have a simple solution to the design of an 8-bit simple > divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA > (xc4000 series). The circuit must take up as little space as possible > (bit serial solution?). > > -- > Johannes Sølhusvik > ABB Corporate Research > Electronic Systems Dept. > P.O. Box 90 > N-1361 Billingstad > Norway > Tel: +47 66 84 34 28 > Fax: +47 66 84 35 41 > Email: jso@nocrc.abb.no Am I correct in assuming that you just want the integer portion of the division? Is speed important? If not, just count the number of times C can be subtracted from B before the result passes through zero. 8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit of control logic. Say 12 CLBs total, worst case result in 256 clocks (dividing by 1). You DID ask for a simple solution :) regards, tomArticle: 5880
Only because the -A is faster, so is less tolerant to designs which use interconnects to route the clock to a shift register (or a counter). In the old 3064, I used to assign a L (long line) attribute (in Viewdraw) to any net which was used to carry such a clock, and that always worked fine. The skew (checked using the XACT die layout display) was very small, less than 1ns. The trouble is that the -A parts, especially the faster ones, appear to have their logic elements faster by a *larger* factor than their interconnects, so interconnect delays become more important. I have had several cases of the *same* bitstream failing to work in a newer device. In some cases it was this clock skew, and in others it was the use of the -i switch in "xnfmap -cosi" which gives you slightly better packing density but introduces a small hold time to D-types - again this was never a problem in the 3000 devices. But as old hands here will point out, one should not be doing any of the above anyway. In any Xilinx FPGA, one is supposed to use the global clock nets to route a common clock to all D-types, and use the clock enables to choose which one actually gets clocked. This is fine, except it is more laborious to design that way, and a right pain sometimes. And it is a problem when using an FPGA to prototype an ASIC (a VERY common use for FPGAs, unfortunately for their manufacturers) which needs to be low power, because the very last thing you want to do in such an ASIC is to have the whole thing going up and down at X MHz. I know for a fact that with the older 3000 parts lots of people used to do designs the same way I did. And Xilinx engineers were quite happy about that. They told you to attach the L attribute, and/or attach something like SC=1 (skew less than 1ns) and everyone was happy. Now, I always use common clocks for structures which need "concurrent" clocking. With the faster versions of the -A parts especially, one needs to be 100% by the book, else it just won't work. >could you elaborate a little please, i don't understand and i'd like to as it >means i don't understand the difference between the 2 architectures. i'm >currently using some A's with bit streams designed for non-A's and >you have worried me! > Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiserve.com.Article: 5881
Roger Kinkead <roger@rkhost.demon.co.uk> wrote:
:In article: <33315AAB.3416@ids.net> Ray Andraka <randraka@ids.net> writes:
:>
:> Kent wrote:
:>
:> > I am curious to know if anyone else has been able to instantiate a basic
:50
:> > Mips processor in less than 10% of a 3090, or a "vector processor" in a
:> > little more than 200 CLBs. Is there some big secret about the 3090 you
:> > guys have been keeping quite, or is there something I am missing here?
:>
:> No big secret. The design is just well tailored to the FPGA
:> architecture. I suspect the 'nanoprocessor' is a simple RISC engine
:> (very few instructions) with hooks to permit specialized instructions to
:> be added.
:<SNIP>
:
:If anyone is interested, it is possible to view/download/print patents at IBM
:patent server (www.ibm.com/patent I think it is?). Along with other
:interesting things, you can pull down Metalithic's 5,361,373 patent which may
:explain many things to you.
:
:Hope at least some of this helps.
:
The IBM patent server is at http://patent.womplex.ibm.com
Hit "Number Search" with the above number, and up it comes. The
abstract is pretty sparse (they usually are), just saying "let's use a
lot of FPGA's to do this".
[Wasted lines to fool this newsreader]
-- Dave Brooks <http://www.iinet.net.au/~daveb>
PGP public key via <http://www.iinet.net.au/~daveb/crypto.html>, or servers
"From" line rigged to foil spambots: daveb <at> iinet.net.au
Article: 5882Tom Burgess wrote: > > Johannes Soelhusvik wrote: > > > > Does anyone have a simple solution to the design of an 8-bit simple > > divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA > > (xc4000 series). The circuit must take up as little space as possible > > (bit serial solution?). > > > > -- > > Johannes Sølhusvik > > ABB Corporate Research > > Electronic Systems Dept. > > P.O. Box 90 > > N-1361 Billingstad > > Norway > > Tel: +47 66 84 34 28 > > Fax: +47 66 84 35 41 > > Email: jso@nocrc.abb.no > > Am I correct in assuming that you just want the integer portion of > the division? Is speed important? If not, just count the number of > times C can be subtracted from B before the result passes through zero. > 8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit > of control logic. Say 12 CLBs total, worst case result in 256 clocks > (dividing by 1). You DID ask for a simple solution :) > If the remainder is needed, it can easily be obtained from the residue in the subtractor using an extra 8 bit register. The subtraction can also be done bit serially, although CLB savings is somewhat offset by increased complexity in control. -Ray Andraka, P.E. Chairman, the Andraka Consulting Group 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://www.ids.net/~randrakaArticle: 5883
Greg Quintana wrote: > > Anyone have equations for FIFOs that could be used in a xilinx part? > -- > > Greg Quintana You may find that is more cost effective to use standard FIFOs. Implementing large FIFOs on an FPGA uses a lot of silicon.Article: 5884
In article <peter-2103971824560001@appsmac-1.xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:
>...I fail to see your disappointment in a single source for the tools.
>When you buy them from the component supplier, you can be sure that they
>are as close as possible to the real silicon, as up-to-date as possible...
Oddly enough, when I buy an EPROM programmer, I don't buy it from the
company that sells the EPROMs, and yet it generally seems to be up to date
with the silicon. Of course, it helps that the EPROM programming specs
are published openly. However, even for things like PALs where the specs
are secret (oddly enough, sometimes from the same companies who openly
publish EPROM programming specs), the programmer manufacturers simply have
agreements with the chip suppliers that give them access to current info.
>...you are also buying a heavily subsidized piece of software. There
>should be no doubt about it: The major FPGA houses sell their software
>tools at a bargain basement price, a price that does not really do justice
>to the development cost ( plus whatever royalties must be paid ).
Then why don't they sell them at the cost of duplication and distribution,
plus any applicable royalties? I don't see them charging $100 per copy
for their databooks, which are similarly subsidized.
Alas, not all chip suppliers are smart enough to see that they will sell
more chips if they make a firm commitment to a competitive market in
support tools. If the objective is to sell more chips, it makes no sense
to artificially restrict the prices and functionality of support tools by
maintaining a monopoly position.
--
Committees do harm merely by existing. | Henry Spencer
-- Freeman Dyson | henry@zoo.toronto.edu
Article: 5885
In article <VA.00000002.253d88f6@eng13>,
Greg Smith <gregs@uniquesys.com> wrote:
>>...one need not assume actual malice. There is always a
>>tradeoff between performance and easy implementation, and big companies can
>>cope with implementation difficulties relatively easily, so naturally their
>>design ideas are biased strongly toward maximum performance.
>
>Yes. We are now in an era where standards (and I am referring to actual, not
>ad hoc, standards) are being designed with the assumption that ASICs,
>and other technologies such as connectors, will be developed specifically
>for the standard...
Note that exonerating the big companies of malice is not the same as
saying that they have the best interests of us all at heart. Such complex
standards *are* a bad thing, harmful to the industry and the customers.
Often we would be better off with a bit less performance and rather easier
implementation. (The decision to change Ethernet from 3Mbps to 10Mbps
probably delayed its widespread market acceptance by at least a decade,
and has spawned a lot of pointless reinventions of the wheel in areas
that would have been better served by a cheap and simple Ethernet.)
It would be a forward step if we could figure out a way to get smaller
players -- and better yet, customers -- more actively involved in the
standard-setting. The problem is that the big companies are also the ones
who can spare the resources for major involvement in standards work, so
their voices are disproportionately heard even in standards whose
development processes are open to all (and some aren't).
There is a secondary and more fundamental problem in that any standard
developed by the current players (large or small) will be biased toward
people who are already in the industry. They can see that it impacts
them and that there is incentive to get involved. This is much less
obvious to the folks who might try to enter the industry next year.
>Consider that SCSI-1 was drafted at a time when it was assumed
>that all SCSI interface circuits would be built with 74XX TTL - there's
>a standard which has turned out to have very long legs.
Exercise for the student: what might one infer from this about the
need, or lack thereof, for complexity in standards?
--
Committees do harm merely by existing. | Henry Spencer
-- Freeman Dyson | henry@zoo.toronto.edu
Article: 5886>As you know, there once was a company called NeoCad who tried to develop >and sell software without any subsidy from the silicon, and they did not >survive. They should have charged a lot less money !! But I really mean that. I recall examining their product at an FPGA seminar (organised by a distributor) a few years ago, and their prices were more or less identical to those charged by Xilinx, and (then) others. Very high - too high for the majority of very small firms, and the large firms are not so worried about price, and are happier to buy their P&R tools from the silicon vendor. The early Neocad s/w was not exactly bug-free, either. At that time, Xilinx's s/w was quite good, in fact I still use your s/w from that era. Therefore, there was little point in anyone using their products. OK, they could pack more into an FPGA than anyone else. But how many FPGAs are packed to the limit? Very few in fact. I know someone who uses a 5-figure/month number of the XC3030, and he gets them so cheap that he uses them even when they only replace a handful of HC chips. If you are going to compete, in any business, you have to offer something *special*. If you are going to compete with someone as established as Xilinx, you have to offer something *very* special. I think they missed an opportunity to make FPGA tools available to a much wider user base than exists at present.Article: 5887
Peter Alfke wrote: > <some stuff deleted - this is re sole-source tools> > > When you buy them from the component supplier, you can be sure that they > are as close as possible to the real silicon, as up-to-date as possible, > and you are also buying a heavily subsidized piece of software. There > should be no doubt about it: The major FPGA houses sell their software > tools at a bargain basement price, a price that does not really do justice > to the development cost ( plus whatever royalties must be paid ). They are also free to play games with the software to push new silicon and frustrate the competition, e.g. the arbitrary freezeout of 3000 from XACT performance(TM) features. The limits of the possible (in terms of timely delivery of useable software) seem to shrink somewhat when you are a subsidized component (cost center) in a megacorp. As a user, I would rather see the specs released and the whole software thing spun off to private industry and let the best FPGA packer win. > As you know, there once was a company called NeoCad who tried to develop > and sell software without any subsidy from the silicon, and they did not > survive. I guess being assimilated by the Xilinx entity equates to non-survival? I have not yet seen results from the FPGA foundry / XACT merger and do not think it wise to hold my breath. > It became pretty obvious that you cannot sustain a 50-(wo)man development > effort on the kind of software revenues that this market is willing to > provide. You need an income of 15 to 25 million dollars per year, > otherwise you fall below critical mass. ( These numbers are my estimates, > not authorized by Xilinx ). All you need is a few brilliant (wo)men - and a bit of help from Xilinx on device data. If Xilinx supplied decent basic tools - free! and let the free market do the fancy stuff, I believe in the end Xilinx would sell a lot more chips and make more money than by selling tools as a loss leader. The token cost (one or 2 K$) is a major barrier for the engineer who wants to switch from brand Y. anyway - love your app notes - regards tom.Article: 5888
Anthony Ellis wrote:
Given that I have $8000 to spend on tools and want to do the
following:
FPGA VHDL development - just the VHDL coding, debugging and
simulating.
Independent of FPGA vendor.
Will use customer's back end tools as required. Typical VHDL
design
bureau.
Front end schematic capture tools to interface with
Coopers&Cyan as well
as PCAD PCB tools.
I currently use Workview Office tools and Speedwave. Need tools for
my own
business now and would like some alternatives.
Any recommendations?
Anthony "LogicWorks"
I know you wanted FPGA independent tools but check out the tools at:
http://www.erols.com/aaps
The packages are very reasonable (currently only XILINX)
Also check out my web page for the following non-vendor specific tools:
EXEMPLAR
MODEL TECHNOLOGIES
ACCOLADE VHDL
CAPILANO Design Works
My links page:
http://www.erols.com/links.html
--
__________________________________________________________
Richard D. Schwarz, President
Associated Professional Systems (APS)
3003 Latrobe Court, Abingdon, Maryland 21009
Phone: 410-569-5897 Fax: 410-661-2760
Email: aaps@erols.com Web site: http://www.erols.com/aaps
--- FPGA Solutions/Test Boards/ EDA Software ---
--- SIGTEK Spread Spectrum & Communications Equipment ---
Article: 5889
Henry Spencer wrote:
In article <peter-1903971555490001@appsmac-1.xilinx.com>,
Peter Alfke <peter@xilinx.com> wrote:
>A single source must and will use multiple fab lines ( to protect
against
>accidents ) and must be forthcoming in price reductions. I think we
in the
>FPGA world have done that...
Tell that to Altera's FLASHlogic customers. Incidentally, how many
price
reductions have there been on Xilinx's development software lately?
The biggest reason why the customers do still like having second
sources
is that it insulates them from the management whims of a sole
supplier.
Sure, Intel will deliver... but will it deliver the parts you want?
Or
will it decide, to pick a purely hypothetical example :-), that it
won't
ship Pentiums at more than 200MHz because that would compete with
the
Pentium II (which they annoyingly decided wouldn't be
socket-compatible
with anything that came before)?
--
Committees do harm merely by existing. | Henry
Spencer
-- Freeman Dyson |
henry@zoo.toronto.edu
Check out the XILINX tool prices at:
http://www.erols.com/aaps
These kits with the APS-X84 boards are very reasonable and will work to
make the tool kits very accessible and will help all concerned (XILINX,
ALDEC,APS, and of course the all important USERS).
--
__________________________________________________________
Richard D. Schwarz, President
Associated Professional Systems (APS)
3003 Latrobe Court, Abingdon, Maryland 21009
Phone: 410-569-5897 Fax: 410-661-2760
Email: aaps@erols.com Web site: http://www.erols.com/aaps
--- FPGA Solutions/Test Boards/ EDA Software ---
--- SIGTEK Spread Spectrum & Communications Equipment ---
Article: 5890Hans Tiggeler wrote: In article <5gd0vp$4cp@mtinsc03.worldnet.att.net>, c-d-symes@worldnet.att.net says... > >In article <01bc30ac$e2c746b0$0307e38f@zimbo>, > "Joel Kolstad" <Joel.Kolstad@Techne-Sys.com> wrote: >>> any experience with Accolade-Tools (VHDL-Simulation and FPGA-Synthesis) ? >> >>I downloaded their demo and it died a horrible death under NT 4.0. >> >And it's REAL unstable under W95 My 3.06b none limited evaluation copy works fine under Win95. It does have some problem, like sometimes you get multiple minimize/maximize close buttons, and its got some other "features", but it never crashed my machine. Under NT 3.51 the screen is not updated correctly when running PeakSIM. To solve this problem you have to minimize/maximize your screen or zoom in/zoom out. Accolade is bringing out updated quite regularly. Sure it can not compete with V-Systems but than again V-Systems has been around a lot longer than Accolade and is not in the same price range. If you do have a problem, send them to Accolade Technical support and if they ignore you than you know were to complain :-) Hans. SSTL UK I must say that the Accolade support group is very helpful na dquick to respond. Their VHDL simulator is in a price range that will allow many more users to access a good VHDL simulator. We will be using it to test many of our FPGA VHDL designs, and hope to work close with David Pellerin in integrating some other future products. His approach of downloading constantly updated demo software will always leave him open to critique , but in the long run this critique will aid him in wringing out the difficulties mentioned above. Anyone doing development in the ever-changing PC and Windows environment knows this will always be an on going process. I found the Accolade tools to have some very nice features, which the Model Tech simulator (which we also have) does not have. I would not hesitate to check them out. -- __________________________________________________________ Richard D. Schwarz, President Associated Professional Systems (APS) 3003 Latrobe Court, Abingdon, Maryland 21009 Phone: 410-569-5897 Fax: 410-661-2760 Email: aaps@erols.com Web site: http://www.erols.com/aaps --- FPGA Solutions/Test Boards/ EDA Software --- --- SIGTEK Spread Spectrum & Communications Equipment ---Article: 5891
In article <33342E96.4AC1@mindspring.com>, Brad and Renea Ree <rbree@mindspring.com> wrote: > You may find that is more cost effective to use standard FIFOs. > Implementing large FIFOs on an FPGA uses a lot of silicon. That depends on the size of the FIFO on the speed rquirements, and on the number of available I/O pins. I assume that the internal FIFO wins when it is up to 32 levels deep, and/or when the required speed is faster than 30 MHz. Very large FIFOs, kilo-words deep, must obvously stay outside the FPGA. Peter Alfke, Xilinx ApplicationsArticle: 5892
In article <5guk98$sf6@sirio.cineca.it>, mauro@uxla01.lamel.bo.cnr.it (Mauro Fiorini) wrote: > FPGA PROM > > /progr (pin 55) -------> reset (pin 4) change this > > done (pin 53) -------> /ce (pin 3) change this > > din (pin 71) -------> data (pin 1) > > cclk (pin 73) -------> clk (pin 2) > > It's sunday afternoon, and I just want to give you a sure solution: Program the SPROM for active Low RESET. Then drive the SPROM RESETbar from INITbar of the XC40003A Drive the SPROM CEbar from LDCbar of the FPGA. This is the absolute best way, and is also the one we document on page 4-68 of our data book. The problem with your board is most likely that DONE is configured to go High early ( that's the default ) so it disables the SPROM when several bits are still needed. ( see page 13-27 of the Sept 96 data book, or 14-27 of the July 96 book. Of course, you could also try configuring in your present scheme with DONE configured to go High late. Not my recommendation, but may be easier for you. Ciao Peter Alfke, Xilinx ApplicationsArticle: 5893
ICCIMA'98
9-11 February 1998
Monash University, Gippsland Campus, Churchill, Australia
F I R S T C A L L F O R P A P E R S
The conference will include sessions on theory, implementation and
applications, as well as the non-technical areas of challenges in
education and technology transfer to industry. There will be both oral
and poster sessions. Accepted full papers will be included in the
proceedings to be published by World Scientific. Several well-known
keynote speakers will address the conference.
Special Sessions:
Artificial Intelligence and Logic Synthesis: intelligent algorithms
for logic synthesis; functional decomposition in machine learning,
pattern recognition, knowledge discovery and logic synthesis;
evolutionary and reconfigurable computing with FPGAs. Chair: Lech
Jozwiak, Eindhoven University, Netherlands.
Multimedia Information Retrieval: segmentation of audio, image and
video; feature extraction and representation; semi-automatic text
annotation techniques; indexing structure; query model and retrieval
methods; feature similarity measurement; system integration issues;
prototype systems and applications. Chair: Guojun Lu, Monash
University, Australia.
Pre-Conference Workshops and Tutorial:
Proposals for pre-conference workshops and tutorials relevant to the
conference topics are invited. These are to be held on Saturday 7th
February and Sunday 8th February at the conference venue. People
wishing to organise such workshops or tutorials are invited to submit
a proposal at the same time as submission deadline for papers. The
accepted proposals will be advertised.
Special Poster Session:
ICCIMA'98 will include a special poster session devoted to recent work
and work-in-progress. Abstracts are solicited for this session (2 page
limit) in camera ready form, and may be submitted up to 30 days before
the conference date. They will not be refereed and will not be
included in the proceedings, but will be distributed to attendees upon
arrival. Students are especially encouraged to submit abstracts for
this session.
Invited Sessions
Keynote speakers (key industrialists, chief research
scientists and leading academics) will be addressing
the main issues of the conference.
Important Dates:
Submission of papers received latest on: 7 July 97
Notification of acceptance: 19 September 97
Camera ready papers & registration received by: 24 October 97
Submission of Papers
Papers in English reporting original and unpublished research results
and experience are solicited. Electronic submission of papers via
e-mail in postscript or Microsoft Word for Windows format directly to
the General Chair are acceptable and encouraged for the refereeing
process. If not submitting an electronic version, please submit three
hard copy originals to the General Chair. Papers for refereeing
purposes must be received at the ICCIMA 98 secretariat latest by 7
July 1997. Notification of acceptance will be mailed by 19 September
1997.
Page Limits
Papers for refereeing should be double-spaced and must include an
abstract of 100-150 words with up to six keywords.
The accepted papers will need to be received at the ICCIMA 98
secretariat by 24 October 1997 in camera ready format. A final
preparation format for the camera-ready papers will be provided upon
notification of acceptance. Camera ready papers exceeding 6 pages
(including abstract, all text, figures, tables and references etc.)
will be
charged an extra fee per page in excess to the normal registration.
Evaluation Process
All submissions will be refereed based on the following criteria by
two reviewers with appropriate background.
originality
significance
contribution to the area of research
technical quality
relevance to ICCIMA 98 topics
clarity of presentation
Referees report will be provided to all authors.
Check List
Prospective authors should check that the following items are attached
and guidelines followed while submitting the papers for refereeing
purpose.
* The paper and its title page should not contain the name(s) of
the author(s), or their affiliation
* The paper should have attached a covering page containing
the following information
-title of the paper
-author name(s), Affiliation, mail and e-mail addresses, phone
and fax numbers
-Conference topic area
-up to six keywords
* The name, e-mail, phone, fax and postal address of the contact
person should be attached to the submission
Visits and Social Events
Industrial and sight seeing visits will be arranged for
the delegates and guests. A separate program will be
arranged for companions during the conference.
General Chair:
Henry Selvaraj
Gippsland School of Computing
& Information Technology
Monash University,
Churchill, VIC, Australia 3842
Henry.Selvaraj@fcit.monash.edu.au
Phone: +61 3 9902 6665
Fax: +61 3 9902 6842
International Programme Committee:
Abdul Sattar, Griffith University, Australia
Andre de Carvalho, University of Sao Paulo, Brazil
Bob Bignall, Monash University, Australia
Brijesh Verma, Griffith University, Australia (Programme Chair)
Dinesh Patel, Surrey University, UK
Henry Selvaraj, Monash University, Australia
Hyunsoo Lee, University of Yonsei, Korea
Jan Mulawka, Warsaw University of Technology, Poland
Jong-Hwan Kim, Korea Advanced Institute of Science &
Technology, Korea
Lech Jozwiak, Eindhoven Univ. of Tech, Netherlands
Marek Perkowski, Portland State University, USA
Michael Bove, MIT Media Laboratory, USA
Mikio Takagi, University of Tokyo, Japan
Nagarajan Ramesh,Tencor Instruments, USA
Ramana Reddy, West Virginia University, USA
Regu Subramanian, Nanyang Tech University, Singapore
Sargur Srihari, State University of New York, USA
Shyam Kapur, James Cook University, Australia
Sourav Kundu, Kanazawa University, Japan
S. Srinivasan, IIT, Madras, India
Subhash Wadhwa, IIT, Delhi, India
Tadeusz Luba, Warsaw University of Technology, Poland
Vishy Karri, University of Tasmania, Australia
Xin Yao, University of New South Wales, Australia
International Liaison
Asian Liaison:
Regu Subramanian, Network Technology Research
Centre, Nanyang Technological University, Singapore
U.S. Liaison:
Marek Perkowski, Portland State University, USA
European Liaison:
Tadeusz Luba, Warsaw University of Technology,
Poland
Organising Committee:
Bob Bignall, Monash University, Australia
Baikunth Nath, Monash University, Australia
Vishy Karri, University of Tasmania, Australia
Syed M. Rahman, Monash University, Australia
Bala Srinivasan, Monash University,Australia
Cheryl Brickell, Monash University, Australia
Andy Flitman, Monash University, Australia
Lindsay Smith, Monash University, Australia
Further Information:
Conference Email :
iccima98@fcit.monash.edu.au
Conference WWW Page:
http://www-gscit.fcit.monash.edu.au/~iccima98
Article: 5894I've been developing a soundcard with a xilinx chip (xc400x) used as a custom dsp among other things. It is required that a large number of sample be replayed simultaneously at different sample rates each. I've thought of a scheme were all of each samples parameters are held in large shift registers. The resampling block gets everything from the registers for each sample and outputs it into an accumulator - in the end everything is oversampled and output to a DAC My largest problem now is that the registers must be loadable with new values. Erm.. how am I going to do that without multiplexing? I could have a special control unit that loads the register whenever it is at the start/end of the register "loop" - what is the best way to implement this? -- Christos Dimitrakakis --------------------- mailto:mbge4cd1@fs4.eng.man.ac.uk mailto:mbge4cd1@afs.mcc.ac.uk http://www.man.ac.uk/~mbge4cd1Article: 5895
Tom Burgess wrote: > > Johannes Soelhusvik wrote: > > > > Does anyone have a simple solution to the design of an 8-bit simple > > divider (A=B/C, A,B and C being 8-bit variables) for a xilinx FPGA > > (xc4000 series). The circuit must take up as little space as possible > > (bit serial solution?). > > > > -- > > Johannes Sølhusvik > > ABB Corporate Research > > Electronic Systems Dept. > > P.O. Box 90 > > N-1361 Billingstad > > Norway > > Tel: +47 66 84 34 28 > > Fax: +47 66 84 35 41 > > Email: jso@nocrc.abb.no > > Am I correct in assuming that you just want the integer portion of > the division? Is speed important? If not, just count the number of > times C can be subtracted from B before the result passes through zero. > 8 bit counter (4 CLBs), registered 8-bit subtractor (4 more), a bit > of control logic. Say 12 CLBs total, worst case result in 256 clocks > (dividing by 1). You DID ask for a simple solution :) > > regards, tom First of all, thanks very much for responding to my query. I confirm that I just want the integer portion of the division. And your suggested solution is nice and simple, but I do not have time to go through as many as 255 clock cycles (worst case). What can I do to reduce this to say 32 ? -- Johannes Sølhusvik ABB Corporate Research Electronic Systems Dept. P.O. Box 90 N-1361 Billingstad Norway Tel: +47 66 84 34 28 Fax: +47 66 84 35 41 Email: jso@nocrc.abb.noArticle: 5896
Hi, does anybody know if there's a possibility to use the ZYCAD-Tool 'browse' via scripts on a Solaris plattform ? 'browse' seems to use Perl-Scripts to execute the desired commands !? Can I also use these to controll browse from a terminal that doesn't have an X11-environment ? As a first step it would be ok, if I can call the 'auto_configure'-command. I tried to simply execute it in the $INCA_ROOT/commands/USER_CELL-directory, but that did not work. It only produced the following output: -I- setting 'LOG' = 'yes' -I- setting 'DEBUG' = 'no' -I- setting 'SAVE' = 'yes' -I- Re-execute: Yes Command failed 'i d' Please help. Michael. -- +--------------------------------+-------------------------------------+ | Michael Niechziol | email: minie@uni-paderborn.de | | 33104 Paderborn / Germany | minie@c-lab.de | +--------------------------------+-------------------------------------+Article: 5897
"Anthony Ellis" <aelogic@iafrica.com> wrote: >Given that I have $8000 to spend on tools and want to do the following: > FPGA VHDL development - just the VHDL coding, debugging and simulating. >Independent of FPGA vendor. > Will use customer's back end tools as required. Typical VHDL design >bureau. > > Front end schematic capture tools to interface with Coopers&Cyan as well >as PCAD PCB tools. Check out the Orcad Express system. It will target any of the major FPGA's, and is well within the price you specify. Check it out at http://www.orcad.comArticle: 5898
Mon, Mar 24, 1997
Here is my composite answer to several responses:
If you expect cheaper FPGA software from a third party, forget it. Anybody
who wants to underbid the manufacturer¹s subsidized software will
inevitably go bankrupt. The idea of five smart guys in a garage writing
superb software for peanuts ( if only Xilinx would reveal its secrets) is
worse than an urban legend, it is utter nonsense.
High-quality software at many times the present price ( the Synopsys and
Mentor model) is a more feasible idea, but highly unlikely. Who needs it?
Expect the best and least expensive software always from your chip
supplier. Hhe will supply it forever, and he will keep the price low,
because that¹s in his best interest. Software hasn't gotten cheaper, but
ever so much better. Like $ 2000 PCs that don't get cheaper, they just
become much better $ 2000 PCs.
Regarding assured chip availability, Altera set an ugly example,
abandoning its Intel stepchild, and I don¹t intend to defend that :-).
Xilinx bends over backwards to assure continued supply. For 12 years, we
never dropped any of our FPGAs, and even now, as some of our devices have
become senior citizens, we keep making them for the rest of the decade (
or millennium ), give ample warning, and also refer you to an ³after-life
supplier² ( cute name). There is no reason to assume that a second source
would stick with it any longer. A second source lacks the emotional
attachment, it will drop an obsolete and unprofitable part much sooner.
As time goes on, we update our parts and move them to newer processes,
which makes them faster and cheaper. But we made sure that the XC3000A is
a true superset of the XC3000, same as the XC4000E is of the XC4000. Even
the bitstreams can stay the same. You get a better device at a lower
price, but you have to make sure that your designs are free of race
conditions. That is the price of progress. Without it, we would become a
museum shop.
³Burning down of a fab² is not an issue. Fabless companies find it quite
easy to use multiple fabs, even in multiple countries.
An EPROM programmer is a piece of hardware that IC houses don¹t like to
make, sell, service, and maintain. But it causes us a nasty delay in
product introductions until we finally manage to convince the
manufacturers to add a socket or an algorithm.
Regarding free software. Everybody knows that software has a value and a
cost. It would be a very tough decision to give it away. The analogy with
data books doesn¹t hold: The component data book in Xilinx takes on
average one man-year per year, which is one percent of the software
effort. ( I know, I did it for six years). The cost of printing and
shipping 100,000 books far exceeds the cost of generating and typesetting
the content.
I don¹t want to come across as a defensive smart-ass, but I thought I owed
you some answers.
Keep pushing us by demanding the impossible. That keeps us on our toes.
Peter Alfke, Xilinx Applications
Article: 5899In article <33328507.501E@kiemw.ericsson.se>, FT/KD Patrik Eriksson <emwepa@kiemw.ericsson.se> wrote: > When i try to configure one XC4010E with XCHECKER something goes wrong. > It seems as at the end of the cofiguration the FPGA drives INIT low. > What can be wrong? > > -- > Ericsson Saab Avionics AB Telephone: +46 8 757 30 00 > Torshamnsgatan 32C Direct: +46 8 757 30 00 > Kista Telefax: +46 8 404 41 20 > S-164 84 STOCKHOLM E-mail: Patrik.E.Eriksson@emw.ericsson.se You should have a look at Xilinx-Web page. There are an Application note especially for loading the FPGAs. It is always good, to have a look for the first 20-40 Config bits. Are they correct? The cable shouldnt be very long (up to 50cm). Wilfried Eisele eisele@litef.de
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