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
Dave Galloway wrote: > > I said: > >I've written a HDL compiler for a subset of C called Transmogrifier C > >(tmcc for short). The tmcc compiler lets you specify the length of each > >integer variable by using a C pragma statement. You can specify a 13 bit > >addition this way: > > >#pragma intbits 13 > > int a, b, c; > > > > c = a + b; > > > >Another, somewhat better way of doing it would have been to define new > >integer types: > > > > int13 a, b, c; > > Steve Casselman said: > Wouldn't it be better just to say bit a[13], b[13], c[13]; Then > I could write c[5] = a[2] & b[3] ; > > I think it depends on what you want to use Transmogrifier C for. If you > want to do a 13 bit addition, then having a 13 bit integer is clearer. > If you want to do a lot of twiddling of individual bits, then having a > bit vector type would be useful. > > In reconfigurable computing, I suspect that 13 bit adds are more common, > and that individual bit twiddling is less common. I want to stick with > standard C as much as possible, and I don't want to add features unless > they are really going to help. The whole argument behind using a C-based > language is the large base of C programmers and C programs, and anything > that takes us away from that has to be well justified. If you change the > language too much, you might as well use Verilog or VHDL. > > Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmcc First I want to say tmcc is good work (as is Brads and Hermans) so... In tmcc you have introduced N new types, int1 through intN. I'm just suggesting one new type bit, (ok two, bit and unsigned bit:) This seems, to me at least, to be a natural extention to short, int, and long. Steve CasselmanArticle: 2951
I second Peter Alfke's opinion: The bandwidth in this newsgroup is low
enough to justify a few occasional "off-topic" postings. Besides, sometimes
there's interesting information coming out of these as well...
Regarding the language issue for custom computers: Why do some people want to
program in C? Why don't you use the right language for the right task? If you
can use awk, tcl/tk and perl for doing specific jobs, why then would you want
to use an inadequate sequential programming language like C for describing
highly concurrent hardware?
Some people argue that students are already familiar with C from their
programming course. But then, you have to teach them a different semantics
when they describe hardware. "Everything is parallel, the syntax looks the
same, but the semantics is different!" - "Oh, I know the syntax, I feel right
at home, but huh? Why does this assignment after the increment still use the
old value? Oh! It's parallel, how confusing...".
In our experience with our own little HDL called Lola (logic language), 2nd
year CS students are able to describe quite complex hardware designs using
this language after 10 lessons. All they programmed in up to that point is
Oberon (the successor language of Pascal and Modula-2). They have no trouble
grasping the different semantics, because they never think of it as a
sequential programming language.
My thesis project is to integrate the two programming paradigms into a usable
system for describing custom computing applications. It looks promising...
Cheers,
Stefan H-M Ludwig mailto:ludwig@inf.ethz.ch
http://www-cs.inf.ethz.ch/~ludwig
Institute for Computer Systems
Swiss Federal Institute of Technology (ETH)
CH-8092 Zurich, Switzerland
Phone: 41-1-63 27301
Fax : 41-1-63 21307
Article: 2952In article 41C67EA6@aime.insa-tlse.fr, Sebastien SALAS <sebas@aime.insa-tlse.fr> () writes: >I am newbie to the FPGA world and a friend of mine asks me that SYNARIO >from DATA I/O was better than the other tools. > >One of the big advantage is to choose the family >at the end of the design (ALTERA or XILINX). > >I would like to know if somebody have use SYNARIO tool ? >I am interested in any information. > > >Regards > Sebastien, the promises of the tool seller sounds good. I think for normal designs it will work. But: If you want to use special features of a FPGA family then you must choose the family at the beginning of the designs. For instance Xilinx provides internal RAM's, input und output Flip-Flops direct in the Pad cells... If you want to change the FPGA device in such a case you must change the design sources, because not all FPGA structures are synthesizable. Bye, Peter. --------------------------------------------------------- Peter Wurbs (MAZ Hamburg GmbH, Dep. Broadband Communication) e-Mail: pwu@maz-hh.de ---------------------------------------------------------Article: 2953
In article <r9qohqcqzco.fsf@fester.cs.washington.edu> Paul Franklin <paul@cs.washington.edu> writes: If you guys are really serious about setting up another fpga group... I'm not, I'm convinced its a bad idea. The traffic here doesn't warrent it. BillArticle: 2954
I'm working on a project where I need 5 independant digital
frequency sources (Its a digital crossover). I could use PLLs to
generate the freqs, but I'd prefer a single chip application.
My idea is to implement 5 Direct Digital Synthisizers in a FPGA.
What this requires is a serially loadable/addressable 24 bit latch for
each DDS, a 24 bit adder with running count accumulation, and an
output tied to the MSB of the 24 bit accumulator.
Clock this with 2x the needed frequency and I can generate any
division of the clock (up to divide by 2) that I need.
Operation would be as follows:
uP loads each of the 24 bit latch with the value needed to generate
the frequency. The FPGA then adds this value to the 24 bit accumulator
every clock cycle, allowing it to wrap around. The MSB of the
accumulator is attached to an output port, and is the divided
frequency with an accuracy of fc/2^n (where fc = input clock freq, and
n is the number of bits in the accumulator).
It only needs to run at about 5MHz (2MHz being the max output
prequency needed).
Is this a viable project for a FPGA or am I barking up the wrong
tree?
I'm not looking for anyone to design it for me, just for pointers to
tools and info. My only previous experince with these types of devices
is with programming a PAL as an address decoder in a 68HC11 project.
Thanks for any help!
Brian
------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> -------
Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!)
============== 11 99 3D DB 63 4D 0B 22 15 DC 5A 12 71 DE EE 36 ============
Article: 2955Gentlemen, I still object to creating a new language for the following reasons: 1) Try implementing everything in VHDL, then map the "software" part into C, using existing tools. This capability exists now, and the EDA infrastructure is widespread. 2) Languages take a lot longer to define than you think - how many years did it take to get VHDL, ADA, Verilog, C++ ironed out? In 5 years when V/V++ is complete, where do you expect VHDL, etc. to be? 3) I don't believe Synplicity is a good example of a synthesizer; if they were so great, how come nobody's buying it? How come nobody is singing its praises in this (and other) newsgroups? Good synthesizers do NOT happen overnight, and you're looking for a GREAT synthesizer. 4) When you implement into hardware, you attempt to parallelize as much as possible for max. throughput. In software, you're always single-threaded (even if the OS lets you pretend you're not). You will always have two choices: a) implement your algorithm single-threaded (optimized for SW) b) implement your algorithm multi-threaded (optimized for HW) You will always be able to map into the non-optimized implementation, but it may not be market competitive (too slow, too costly). 5) Behavioral synthesis is the art of mapping an algorithm (say an FIR filter) into hardware with a user-defined clock frequency. This is really what you're looking for in your new language. Behavioral synthesis is a much different/much larger problem than simple RTL synthesis. Here's my background: - wrote a behavioral synthesizer - implemented same set of algorithms into C and VHDL (implementation looks MUCH different when you optimize for target) - implemented 2 large designs in FPGAs, simulating hardware with software. So, I think I have some experience in the area. If you think I'm wrong on my conclusions, I would like to hear it. I just don't think that V/V++ is the right answer, and even if it were, I don't see the market backing it. I'd much rather see well-defined extensions onto VHDL (if that's even needed). Regards, Erik JessenArticle: 2956
Richard Lazarus <rblazarus@tasc.com> wrote: >We have approached this topic from a compiler perspective for a number of >reasons. One (unrelated to reconfigurable computing languages) is our >long standing research into formal software analysis tools. >Compiling HLLs into an intermediate acyclic directed graph >representation has some distinct advantages over VHDL/Verilog approaches. >This approach is independent of the input HLL. Thus, legacy FORTRAN and C >programs can be compiled for these new reconfigurable architectures. >While multithreading information may or may not be present in the HLL, >our data flow graph representation "automatically" identifies independent >execution threads. This sounds like behavioral synthesis to me; it's much easier to write one, than to write one that will be market-competitive vs. people reimplementing the algorithm into hardware. I believe you underestimate the task required to make it something someone would buy. >While C++ may not be considered a multithreaded language, there exist >class libraries that provide constructs for multithreading and >synchronization. Additionally, HLLs are evolving towards providing >increasing levels of multithreading and parallel execution support. Agreed - HLLs are slowly transforming into VHDL/Verilog. :) >In contrast to VHDL/Verilog, HLLs have the advantage of great portability >and widely available tools for programming and debugging. It is our >objective that user intervention after compilation will be minimal >(assuming the program has been verified using a traditional HLL >compiler). I would have to say that there are a very wide range of tools available for VHDL/Verilog design/debug/synthesis. Proof is in the computer you're using to read this email, and the network that transmitted it. VHDL/Verilog debuggers are quite powerful, and must be able to deal well with multithreaded environments. I don't recall many C debuggers that do that well. >While VHDL/Verilog can be learned (as with any language), it will also >require that developers and companies support an additional suite of >development tools. Our product/compiler/crosscompiler could be bundled >with the reconfigurable computer unit. I taught a group of C programmers VHDL in a few hours (not the syntax, but the theory). If they had a decent CS curriculum, they know what a multithreaded language is. And that's VHDL (or Verilog). >I appreciate your comments. >Regards, >Rich Well, Rich, I gave you my comments. I'm not trying to rain on your parade, I just don't like seeing someone go down a deadend path. There are enough people doing that already. Could you please tell me specifically what you can't do in VHDL, that you could do in your approach? I must have missed something. Regards, ErikArticle: 2957
>I suspect that VHDL/Verilog tools could also be bundled with hardware. >Bill You can get VHDL simulators for $100 now (they're not great, but early C compilers weren't either). Modeltech on PC is around $3500, and it is absolutely great. I would expect VHDL tool prices to continue to drop, as companies amortize their NRE costs over more units shipped. So, tool prices shouldn't be an issue. The cost of your synthesizer (of any form) is what will kill you. They cost a LOT more to develop than a simulator. That's why I think that sticking with VHDL is the way to go. Your costs will be reasonable. Regards, ErikArticle: 2958
Can anyone tell me a good source, hopefully low-cost/no-cost, that will give me specs for using ABEL to program PLDs? Any help is greatly appreciated. MikeArticle: 2959
Shortly after the group was formed, we discussed all this, and
whether we EEs who wanted to discuss all aspects of PLDs and FPGAs
should disappear and form our own group.
I was all ready to propose a group in the sci. hierarchy, but as I
recall, there wasn't a single voice from the computing people
objecting to the status quo, so I didn't bother. At that time, the
group was running at 3 or 4 posts *per week* (and did for several
months), and so the chances of justifying a new group to the powers
that be seemed a little thin anyway.
I don't actually see the objection to the two types of user of this
newsgroup co-existing. What possible harm can it do? If you don't
want to read a thread then don't read it.
David Pashley
Article: 2960
02/26 1600 Fintronic uses Enhanced Cycle Simulation
Menlo Park, CA (Feb. 26, 1996) Fintronic USA, Inc. the supplier of high
performance hardware description language driven simulators announces today
that it has introduced enhanced cycle simulation technology (ECST) to its
FinSim verilog simulator, in addition to its already existing event-driven,
compiled and interpreted technologies.
Whereas traditional cycle-based technology only takes into account clocks as
defining cycles at which the circuit must be evaluated, the enhanced cycle
simulation technology developed by Fintronic considers general control
signals to define areas of the circuit that can be simulated with cycle-based
techniques, and utilizes state dependent critical path calculation for
accuracy of results in the presence of timing information.
As opposed to some other cycle-based products which require modifications to
existing designs and libraries in order to employ the cycle-based paradigm,
Fintronic's ECST does not require a special design methodology. The entire
Verilog language is supported. FinSim automatically identifies circuit areas
suitable for enhanced cycle simulation, event-driven simulation, interpreted
simulation, compiled simulation, etc. and simulates each such area with the
most appropriate algorithm for fastest simulation without compromising the
simulation results or the timing information associated with the results.
FinSim's enhanced cycle simulation technology is currently very effective
even in the presence of timing information and fully supports the handling
of X's and Z's as well as the the entire range of Verilog strengths.
"By using enhanced cycle simulation technology, FinSim has become more than
two times faster than VCS 2.2 on benchmarks on which VCS 2.2 was reported to
be the leading Verilog software simulator last year in a benchmark
report produced by DA Solutions. It is important to note that the high
simulation performance is achieved with little additional analysis
time", says Dr Alec Stanculescu, president of Fintronic USA.
In addition to this ground-breaking technology, FinSim also offers a new,
faster interpretation engine and an improved gate level algorithm for the
areas of the circuit which are not suitable for enhanced cycle simulation.
FinSim applies traditional compiler optimization technology such as constant
propagation, common subexpression elimination, and dead code elimination for
better performance in all the simulation paradigms used, including in
interpreted, compiled, event-driven, and enhanced cycle simulation. In
addition to the traditional compiler optimizations, FinSim performs numerous
optimizations specific to the Verilog language semantics.
Addressing the increased density of current and future designs, FinSim has
considerably reduced its memory consumption by using both newly redesigned
data structures and new technology specifically targeted at lowering memory
requirements.
Platform support:
FinSim features the highest platform versatility in the industry
by running on all popular platforms including UNIX for SUN, SGI, HP, DEC,
Windows NT, Windows 3.1 and Windows 95, Linux and Sony NEWS.
Third Party Integration:
FinSim is tightly integrated with third party graphical
environments such as SignalScan from Design Acceleration, Veribest from
Veribest Inc., Ishizue from IK Technology, Undertow from Veritools, and ECS
from Data I/O.
Pricing and Availability:
Fintronic USA's FinSim simulator featuring high performance
Verilog Simulation is priced from $995 to $20,000 depending on product
configuration and platform, and is available now. It is sold by Fintronic USA
Inc., IK Technology, and Intergraph. The Verilog Analyzer from Fintronic USA,
is currently part of products sold by Intergraph, Nextwave, ZyCAD, IST, IKT,
and IKOS. Fintronic has a Web page at http://www.fintronic.com, which can be
used for placing orders, requesting demo licenses, checking prices, etc.
Fintronic provides hotline support and software distribution via the Internet.
For more information contact Dr Alec Stanculescu, president, at
(415) 325 4474/x105 or e-mail him at alec@fintronic.com.
Mission:
Fintronic has a mission to supply the highest performance Verilog
HDL simulators available for full language design verification and timing
simulation. It is privately held and privately funded.
Acknowledgements:
Fintronic USA, Inc. acknowledges trademarks or registered
trademarks of other organizations for their respective products and services.
Article: 2961From: ludwig@inf.ethz.ch (Stefan Ludwig) Date: 5 Mar 1996 08:16:59 +0100 Organization: Dept. Informatik, Swiss Federal Institute of Technology Regarding the language issue for custom computers: Why do some people want to program in C? Why don't you use the right language for the right task? If you can use awk, tcl/tk and perl for doing specific jobs, why then would you want to use an inadequate sequential programming language like C for describing highly concurrent hardware? Some people argue that students are already familiar with C from their programming course. But then, you have to teach them a different semantics when they describe hardware. "Everything is parallel, the syntax looks the same, but the semantics is different!" - "Oh, I know the syntax, I feel right at home, but huh? Why does this assignment after the increment still use the old value? Oh! It's parallel, how confusing...". I'm confused. Surely no one is suggesting a language that claims to be based on C, but has different semantics for the same syntax. If you write: a = input; b = a + 6; a++; c = a; and input has the value 3, then the results should be a = 4, b = 9 and c = 4 in any language that is like C. A compiler (even tmcc, which is pretty simple) can find the low level parallelism in those statements, and generate a circuit that produces the three correct results in parallel, in one clock cycle. Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmccArticle: 2962
In article <313c698c.3381787@news.aa.net>, blane@aa.net (Brian C. Lane) wrote: > I'm working on a project where I need 5 independant digital > frequency sources (Its a digital crossover). I could use PLLs to > generate the freqs, but I'd prefer a single chip application. > > My idea is to implement 5 Direct Digital Synthisizers in a FPGA. > What this requires is a serially loadable/addressable 24 bit latch for > each DDS, a 24 bit adder with running count accumulation, and an > output tied to the MSB of the 24 bit accumulator. > You can easily do this in a Xilinx XC4004A or XC4005 You need five times 24 latches and 24-bit accumulator. Each latch or accumulator bit uses one half of a Configurable Logic Block ( CLB ), so you need 120 CLBs. An XC4004A has 144 CLBs in a 12x12 matrix, the XC4005 has 196 CLBs in a 14 x 14 matrix. Either part will do the job, and could run ten times faster than what you need. If you want to have more of these counters, you could use a time-sharing method, using the on-board RAM and an 8-times faster clock implementing 40 such synthesizers simultaneously You could also use the XC5004 or XC5206, which are cheaper and slower, but fast enough for your intentions. All these parts come in 84-pin PLCC packages and consume very little power. The design effort is minimal, since these devices have a dedicated carry structure for the accumulator. Lokk at page 9-18 of the Xilinx Data Book. It describes your application, calling it "Programmable Sine Wave Generator". Peter Alfke, Xilinx ApplicationsArticle: 2963
> How is Atmel doing it? > I haven't had time to try out their latest > "cache logic". Any takers out there. I used such an 'overlay' for a graphics 'engine' in an AT6005. First some 'code' to allow a RISC to load texture RAM, then code to do the graphics. It would be useful to be able to define these overlays in HDL. Mike Jones,Digital Dexterity Ltd.Article: 2964
blane@aa.net (Brian C. Lane) wrote: > > > I'm working on a project where I need 5 independant digital > frequency sources (Its a digital crossover). I could use PLLs to > generate the freqs, but I'd prefer a single chip application. > > My idea is to implement 5 Direct Digital Synthisizers in a FPGA. > What this requires is a serially loadable/addressable 24 bit latch for > each DDS, a 24 bit adder with running count accumulation, and an > output tied to the MSB of the 24 bit accumulator. > > Clock this with 2x the needed frequency and I can generate any > division of the clock (up to divide by 2) that I need. > > Operation would be as follows: > > uP loads each of the 24 bit latch with the value needed to generate > the frequency. The FPGA then adds this value to the 24 bit accumulator > every clock cycle, allowing it to wrap around. The MSB of the > accumulator is attached to an output port, and is the divided > frequency with an accuracy of fc/2^n (where fc = input clock freq, and > n is the number of bits in the accumulator). > > It only needs to run at about 5MHz (2MHz being the max output > prequency needed). > > Is this a viable project for a FPGA or am I barking up the wrong > tree? > > I'm not looking for anyone to design it for me, just for pointers to > tools and info. My only previous experince with these types of devices > is with programming a PAL as an address decoder in a 68HC11 project. > > Thanks for any help! > Why not use a loadable counter and reload it and toggle a flip- flop each time you reach the terminal count. That gives you considerably more flexibility in your divide ratios with less and faster hardware. This scheme gives you control of your output period in steps of 2tc (master clock period) and always provides a 50% duty output. With proper counter design, you can easily get a 24 bit counter running at several at times your required 5MHz in any FPGA. The counters can also be made fairly compact, so there should be no problem with running out of room in any but the smallest parts. Best of luck, and good luck with your project. -Ray Andraka Chairman, the Andraka Consulting Group 401/884-7930 FAX 401/884-7950 mailto:randraka@ids.net http://www.ids.net/~randraka/ The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs. Services include complete design, development, simulation, and integration of these devices and the surrounding circuits. We also evaluate,troubleshoot, and improve existing designs. Please call or write for a free brochure.Article: 2965
> From: ejessen@ix.netcom.com (Erik Jessen) > > 1) Try implementing everything in VHDL, This is fine for new programs but I want to be able to port the "billions and billions" of lines of code already out there. > 2) Languages take a lot longer to define .... > In 5 years when V/V++ is complete, where do you expect VHDL, etc. to be? In 5 years I expect VHDL to be where it is now. Better tools might be around but that is it. If we don't start on something like V now in 5 years we will be 5 years behind:) > 4) .... > a) implement your algorithm single-threaded (optimized for SW) > b) implement your algorithm multi-threaded (optimized for HW) Check out dave's fine work he does what he calls clock packing. > really what you're looking for in your new language. Behavioral > synthesis is a much different/much larger problem than simple RTL > synthesis. > I agree. I want the best of both worlds. I think the work done in VHDL/ verilog is the missing link and C has the largest population. I want to start be the jumping gene. > Here's my background: Everything you say make me think. I have a gut feeling I'm right. It is the same feeling that made me start writing proposals in 86. Then it was hardware/software symmetry now it is HDL/HLL synergey. > Agreed - HLLs are slowly transforming into VHDL/Verilog. :) and might over take them someday?:) > > Tmcc web page: http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmcc I down loaded this the other day. It is looking better all the time:) Steve Casselman Virtual ComputerArticle: 2966
I was just wondering whether anybody has used/implemented the Xilinks Application note "Fully PCI Compliant PCI Interface in an XC3164A-2 FPGA". I am currently in the process of making a PCI card with this as the basis. I have already come across two or three error's and I would like to know if anybody has actually managed to get it to go (And if they did, how :) ?). Cheers Gerard.Article: 2967
3eme Ecole de printemps
des Jeunes Chercheurs
en Architecture de Machines
---------------------------
21-26 Avril 1996
------------------
Cauterets - Hautes-Pyrenees
---------------------------
Le pole Ile de France du reseau doctoral en architecture des machines
et des systemes (soutenu par le MESR) organise une ecole de printemps du
21 au 26 Avril 1996 a Cauterets (Hautes-Pyrenees).
Il s'agit de proposer aux doctorants (membres du reseau doctoral ou non) de
suivre un enseignement de qualite sur les themes de recherche actuels
ayant trait aux machines informatiques. Ces cours ou seminaires seront
dispenses par des specialistes du domaine concerne.
L'ecole est le lieu ideal pour apprendre, mais aussi
pour echanger des informations et des contacts. C'est
pourquoi le nombre de participants en est limite a 50.
Les differents themes abordes seronts :
- Les reseaux de neurones : Theorie et implementation
electronique
- Les F.P.G.A
- Le Langage V.H.D.L
- Les reseaux Hauts-Debits
- L'Adequation Architecture Algorithme et le
controle de Processus
- Les Retines
- Les Multi-Chip-Modules
- Les Reseaux de Stations de Travail
- De la logique lumineuse aux processeurs optiques:
principe, perspectives et prospectives.
- Composants electroniques a matiere organique
Les differents Intervenants invites sont :
D. Demigny (Ecole Nationale Superieure d'Electronique et de ses Applications - Paris),
E. Belhaire (Institut d'Electronique Fondamentale - Orsay (91) ),
T. Bernard (Etablissement Technique Central de l'Armement -Arceuil (94) ),
N. Butterlin (Laboratoire Optique P.M Duffieux - Besancon (25) )
A. Greiner (Methodologie et Architecure des Systemes Integres - Paris (75) ),
A.B. Fonkoua (IMT - Marseilles (13) ),
Dr. Horowitz (Laboratoire Materiaux Moleculaires - Thiais (94) ),
R. Plouhinec (Dassault-Electronique - Paris).
Inscription :
Le cout de l'inscriptoin est fixe a 2000 Frs.
Cette inscription donne droit a l'hebergement,
la restauration, les cours, le support de cours
et une viste de la region de Cauterets.
Le transport n'est pas compris.
Transport :
Pour se rendre a Cauterets, il faut prendre :
- Le Train jusqu'a Lourdes, ou Tarbes, (~5Heures)
puis un car SNCF jusqu'a Cauterets
ou
- L'avion jusqu'a Tarbes (~1Heures) puis un taxi ou
un car jusqu'a Cauterets.
N.B : Une Page HTML est disponible pour tous renseignements
complementaires a l'adresse :
http://www.ief.u-psud.fr/~granado/ecole.html
---------------------------------------------------------------------------
Formulaire d'inscription
(un formulaire par personne)
A retourner avant le 1 Avril 1996
Nom : .................................................................
Prenom : ...............................................................
Institution : .........................................................
Adresse : ...............................................................
Code Postal : ............. Ville : ...............................
[ ] J'arriverai a l'aeroport de Tarbes le ... Avril 1996 a ....... .
[ ] J'arriverai a la gare Tarbes le ... Avril 1996 a ....... .
[ ] J'arriverai a gare de Lourdes le ... Avril 1996 a ....... .
[ ] J'arriverai a l'hotel par mes propres moyens.
[ ] Je repartirai le vendredi 26 au soir pour l'aeroport de Tarbes.
[ ] Je repartirai le vendredi 26 au soir pour la gare de Lourdes.
[ ] Je repartirai le vendredi 26 au soir pour la gare de Tarbes.
[ ] Si non, je partirai le ........ a .......
[ ] Je suis membre du reseau doctoral.
Les chambres retenues pour les participants sont des chambres doubles
ce qui nous permet de garder un cout de revient de l'ecole faible.
Afin de prevoir le logement de tous, veuillez preciser vos desiderata
ci-dessous.
Nous essaierons de satisfaire toutes les demandes dans la limite des places
disponibles.
[ ] Je logerai a l'hotel Aladin
[ ] Je viendrai accompagne(e)
[ ] Je desire une chambre a un lit pour deux
[ ] Je desire une chambre a deux lits
[ ] Je desire loger avec la personne suivante :
...........................................................................
Ce bulletin d'inscription peut etre renvoye par
courrier electronique a l'adresse suivante :
granado@ufr924.jussieu.fr
ou par courrier a :
Bertrand GRANADO
Universite Pierre et Marie Curie
Departement d'Electronique
Tour 12-13 E2 - piece 15 - Case 203
4, place Jussieu
F-75252 PARIS CEDEX 05
Tel. (1) 44 27 75 07
Telecopie (1) 44 27 48 37
--
Bertrand GRANADO Universite Pierre et Marie Curie
Tel. (1) 44 27 75 07 Departement d'Electronique
Secr. (1) 44 27 40 24 Tour 12-13 E2 - piece 15 - Case 203
Fax. (1) 44 27 48 37 4, place Jussieu
granado@ufr924.jussieu.fr F-75252 PARIS CEDEX 05
Article: 2968Article: 2969
Are there erasable serial PROMs for the Xilinx family? TIA Doug Shade rxjf20@email.sps.mot.comArticle: 2970
Hello, I am interested in finding any "automated" software for partitioning a design over multiple FPGAs. We are using Viewlogic Workview Office (VHDL synthesis) and targeting Xilinx FPGAs. Basically, we have a design with a large (greater than 300) number of I/O. However, we would like to design at a "nice," functional top-down hierarchical approach, as opposed to artificially breaking up the design so that it will fit in several FPGAs. So, an "automated" tool that could break up our design files would be ideal. Any information would be appreciated. Thank you in advance, Edward Leventhal Omitron, Inc. 6411 Ivy Lane Suite 600 Greenbelt, MD 20770 (301) 474-1700Article: 2971
PLDCon Program On the Web. To All Interested In Designs Using Programmable Logic. Hi, I’m the Program Chairman for this year’s PLDCon, the engineering conference for users of programmable logic. I have put the latest conference program description PLDCon’96 on my web site where I can keep it properly updated and get your comments. Check it out at http://www.best.com/~sbaker/program.htm Please send email comments about it. PLDCon will be in two places this year -- same program at each place (novel, huh). -- Boston (Burlington) April 22, 23. -- Dallas May 20, 21. Take a look and let me know what you think. Lots of thanks for your help. Stan Baker Program Chairmam PLDCon’96Article: 2972
A couple of years back, OCCAM was being touted as the language that would compile well to both opcodes and silicon. There was never any question of bolting on extensions to permit parallel-aware versions of the language, they 'just existed'. (and worked, cleanly, not a bodge in sight) Having used the language a _lot_ in embedded work, and now using VHDL for a living, I miss the clean nature of OCCAM. Things that used to be easy are now damn hard, not for any clear reason, more because VHDL feels that it was never designed to compile to silicon. It's a fine simulation language, but, as an efficient synthesis tool, I'm losing patience with it. This may be because I'm targetting FPGAs, and _care_ about gate counts, depths of logic, the immense pain of 'just dropping yet another pipeline stage' into a complex state machine, you name it, it's hard. There were projects going on into OCCAM compilers to silicon, anyone know what happened to them? Is it simply that OCCAM wasn't C, so 'must be bad' or for a real reason? Rant over. Steve Steve Wiseman, Senior H/W Engineer, SJ Research Ltd, Cambridge, England. steve@sj.co.uk +44 (0) 1223 416715Article: 2973
In article <4hld7l$57t@paperboy.ids.net>, Ray Andraka <randraka@ids.net> wrote: > blane@aa.net (Brian C. Lane) wrote: > > > > > > I'm working on a project where I need 5 independant digital > > frequency sources (Its a digital crossover). I could use PLLs to > > generate the freqs, but I'd prefer a single chip application. > > > > My idea is to implement 5 Direct Digital Synthisizers in a FPGA. > > Why not use a loadable counter and reload it and toggle a flip- > flop each time you reach the terminal count. Hold it. These are two very different designs with totally different outputs. Ray Andraka is suggesting a design that can generate any output frequency that is an integer fraction of the clock frequency. There is no jitter, and the design is well-known, but it can only generate clock frequency divided by an integer number. Brian Lane is asking for, and I was describing, a different design that can generate any frequency that is an integer multiple of the clock frequency divided by two-to-the-24. The result has a constant spacing between the possible frequencies ( whereas the simple divider has a constant spacing between possible clock-period values). A Direct Digital Synthesizer pays for this with an unavoidable jitter whenever the output period is not an integer multiple of the clock period. Different things for different applications. A 24-bit DDS, clocked at 2-to-the-24 Hz, i.e. about 16 MHz, can generate any output frequency of an integer Hz value, e.g. like 249 Hz, or 3.467 MHz. A loadable counter can generate equally as many different frequencies, but they are not evenly spaced in the frequency domain. I hope I have been sufficiently redundant. Peter Alfke, Xilinx ApplicationsArticle: 2974
In article <4hm9o7$l54@cantua.canterbury.ac.nz> vansoegi@elec.canterbury.ac.nz (Gerard van Soest) writes: I was just wondering whether anybody has used/implemented the Xilinks Application note "Fully PCI Compliant PCI Interface in an XC3164A-2 FPGA". I am currently in the process of making a PCI card with this as the basis. I have already come across two or three error's and I would like to know if anybody has actually managed to get it to go (And if they did, how :) ?). The PCI designs all concern me. Each vendor claims that the others don't work, suggesting to me that *none* of them work. We've decided to use an interface chip from PLX, though AMCC apparently makes a nice part too. Bill
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