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
Le mer Michel wrote: > Ken Coffman wrote: > > > The conversion from binary to Gray code is not too bad. The best solution > > might be to implement a fast binary counter, then convert the binary to > > Gray. > > > > I can post the algorithm to convert binary to Gray if necessary. > > > > If the output code is not important, and high speed with low EMI is the > > goal, perhaps a LFSR counter is the answer. > > > > What's the design goal? > > What is the meaning of LFSR? LFSR is a Linear Feedback Shift Register counter, which is also known as a pseudorandom number generator. It consists of a shift register whose serial input is fed with the one bit sum of selected taps off the shift register. Careful selection of the taps will yield a (2^n)-1 long sequence. LFSR counters do provide a compact and high speed solution in an FPGA because the feedback equation is simple and can usually be implemented in a single level of logic. In Xilinx FPGAs, the shift register can be implemented in the embedded CLB Ram, making an extremely compact counter. However, LFSRs can be more power hungry than other counters because on average more bits are changing at a time. I suspect this may affect emi as well. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 12626
In article <362CEB40.3C3DA393@visicom.com>, jsmith@visicom.com wrote: > This is a multi-part message in MIME format. > --------------48F2F213E8EFF132AE74780E > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Rick Filipkiewicz wrote: > > > Watching this seemingly eternal schematics vs. HDL argument I find myself, > > typically, agreeing with both sides. Schematics for their intuitive nature, > > at least for datapath stuff - state machines are more problematic. > > Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic, > at least one-hots. If you want to get fancy, the FF > carrying the state can be wrapped in a symbol with one or two > (or more) inputs: enter (for a transitional state active for only > one cycle), enter and exit, enter and hold, choose your own combo's. > The transition logic is usually a simple sum of products applied > to either of the two state control inputs. Almost as easy to read > as a state diagram. Also, you know what it will compile into, as > opposed to one SM -> HDL -> netlist tool I've looked at, > which ended up producing circuits 50% to 100% larger than the > schematic. And a 100% larger circuit is likely to run half-fast. > > Portability --> HDL > Performance --> Schematic > This is almost an exact description of our One-Hot State Machine library. You can download it free from our website: http://www.memecdesign.com/free-lib.htm It is a library of schematic symbols (Xilinx only), each composed of simple flip flops or gates, that allow you to design One-Hot Algorithmic State Machines simply by wiring the appropriate symbols together. The beauty of this method is that there is no special compile step and that the completed schematic looks like a flowchart of your algorithm. We have libraries for Workview Office and Foundation as well as a user's guide. -- Rob Weinstein Memec Design Services - Phoenix rob_weinstein@memecdesignDOTcom -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 12627
Nick Gent <nickg@sqf.hp.com> writes: > So, for design capture, simulation, and place/route do you swear by that > button-infested GUI with it's 'at-a-glance' 'ease-of-use' > 'fully-integrated-look-&-feel'..., or, do you go for the > 'rocket-science' > 'light-the-blue-touch-paper-and-retire' script approach, and amaze your > friends? Well, I think they put GUI on everything for (tongue half in cheek): - It is not the engineer who buys it but the 'purchasing officer', so it is more important how does it look than how well does it work. - It is declared that unix is dead, Windows is the only way to go and Windows needs a GUI. It is also known (from the same source) that scripting is a result of a conceptual error in unix anyway. - It requires cheaper engineers to crank out spiffy looking buttons with animated 3D icons for the old tool internals than to come up with say a new, improved technology mapper so the GUI is more cost-effective. > My preferences are probably obvious from the title :-) Guess mine :-) > My message to the vendors would be: less GUIs, cheaper tools with > powerful scripting and plenty of script-based app notes etc. Now seriously, do you think they listen ? > Telecommunications Network Test Division > Hewlett-Packard Telephone: +44 131 331 Ooops, they *might* listen to *you* ... Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 12628
ememka@my-dejanews.com writes: > Does somebody know where to find schematics for Lattice > isp DOWNLOAD cable ? In the Lattice data book. The latest I have is the '96, it's on page 6-96 in that one. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 12629
muzo wrote: > To me this argument is similar to C vs assembly debate. People argued that you > couldn't write a decent/efficient OS in C; now we have real time embedded kernels > which are mostly done in C. Time to market and cost of development (vs cost of > square mm of silicon) will make sure that synthesis tools are good enough to be > used by vast majority of designer. as the chips get bigger, cheaper, and consume less power, less effieient implementations will be fine, as it's not worth the extra costs to make them better. here costs are tools, engineering time, and delays in schedule. however, you note that efficient kernels are written *mostly* in C. and that syntheis tools will be good enough for the *vast majority* of designers. i agree. and we can still buy assemblers for when they are needed. and we still should be able to use schematics for when they are needed. and for critical sections, either from a functional or performance point of view, the output of the synthesis tools needs to be examined, as for some projects the outputs of compilers were examined (although is mostly gone now). we have used the profiling tools to identify key sections of code that were good candidates for hand coding. in the fpgas, area counts and static timing analyzers are the tools. of course, it took quite a while for the software compilers to get good and accurate - now, with the hgh cpu speeds and good quality compilers there is a very decreased need for assembly code. but not none. however, i do not think that hdl synthesizers are where programming language compilers are. while it is often hard for a human to outcode a good optimizing compiler, it is trivial to outperform a vhdl synthesizer for many circuits of reasonable size. rkArticle: 12630
just to add on a bit to what ray said .... there are a few implications of using the LFSR - one is that the circuit needs a reset to operate and the other is that there is, for most implementations, a lockup state [which is obviously why the reset is needed]. these features are application dependent on whether they are important and the lockup state can be dealt with, at the cost of some extra logic and speed or a watchdog on the side. as far as power, while there are more bits changing, the 'logic cloud' is essentially eliminated, and may more than compensate. i had a book with articles that talked about power as a function of various structures, by earl swartzlander, formerly of trw, on special purpose processors and remember they went over things like this. unfortunately i lent it out and it is gone. anybody have a copy [please post exact title, i want to get it again]? rk ----------------------------------------------- Ray Andraka wrote: > Le mer Michel wrote: > > > Ken Coffman wrote: > > > > > The conversion from binary to Gray code is not too bad. The best solution > > > might be to implement a fast binary counter, then convert the binary to > > > Gray. > > > > > > I can post the algorithm to convert binary to Gray if necessary. > > > > > > If the output code is not important, and high speed with low EMI is the > > > goal, perhaps a LFSR counter is the answer. > > > > > > What's the design goal? > > > > What is the meaning of LFSR? > > LFSR is a Linear Feedback Shift Register counter, which is also known as a > pseudorandom number generator. It consists of a shift register whose serial > input is fed with the one bit sum of selected taps off the shift register. > Careful selection of the taps will yield a (2^n)-1 long sequence. > > LFSR counters do provide a compact and high speed solution in an FPGA because > the feedback equation is simple and can usually be implemented in a single > level of logic. In Xilinx FPGAs, the shift register can be implemented in the > embedded CLB Ram, making an extremely compact counter. However, LFSRs can be > more power hungry than other counters because on average more bits are changing > at a time. I suspect this may affect emi as well. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randrakaArticle: 12631
rk <stellare@NOSPAMerols.com> wrote: >i had a book with articles >that talked about power as a function of various structures, by earl swartzlander, >formerly of trw, on special purpose processors and remember they went over things >like this. unfortunately i lent it out and it is gone. anybody have a copy >[please post exact title, i want to get it again]? Is this it ? Application Specific Processors (Kluwer International Series in Engineering and Computer Science, 380) by Earl E. Swartzlander (Editor) Hardcover (June 1997) Kluwer Academic Pub; ISBN: 0792397924 orderable at www.clbooks.com muzo WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 12632
that's it, thanks. rk muzo wrote: > rk <stellare@NOSPAMerols.com> wrote: > > >i had a book with articles > >that talked about power as a function of various structures, by earl swartzlander, > >formerly of trw, on special purpose processors and remember they went over things > >like this. unfortunately i lent it out and it is gone. anybody have a copy > >[please post exact title, i want to get it again]? > > Is this it ? > Application Specific Processors (Kluwer International Series in Engineering and > Computer Science, 380) > by Earl E. Swartzlander (Editor) > > Hardcover (June 1997) > Kluwer Academic Pub; ISBN: 0792397924 > > orderable at www.clbooks.com > > muzo > > WDM & NT Kernel Driver Development Consulting <muzok@pacbell.net>Article: 12633
I am trying to do a project and needed an estimate of how many ASICs are used in a switch, in a hub and in a router. I am sure someone on this group has a good idea and would really appreciate a response from someone. Regards HimanshuArticle: 12634
In article <70jor8$4ks@aristotle.cs.purdue.edu>, Himanshu Pokharna <pokharna@cs.purdue.edu> writes >I am trying to do a project and needed an estimate of how many ASICs are >used in a switch, in a hub and in a router. I am sure someone on this group >has a good idea and would really appreciate a response from someone. It depends a bit on what protocol, how many ports, how many pins per port, whether hub switch or router, and on how long is your piece of string. The question is quite right though in asking for most technologies how many *ASICs per port*. The industry *ought* to be offering many *ports per ASIC*. The IEEE 1355 protocol does. It was designed to make switching very simple. It resulted in a 32-port 100MBaud switch in 1993 technology. An 8-port GBaud switch uses a tiny proportion of the area of an ASIC fitting a 208-pin package. 4Links have been putting 100 MBaud 1355 into FPGA. An ART port (Asynchronous Receiver Transmitter), including FIFOs and flow-control, fits the 100 CLBs of the XCS05, the smallest, cheapest, Xilinx FPGA claimed to be $2.95 this quarter. A simple 4-port routing switch can be made with these chips plus a 64-macrocell PLD, making a total of around 20k FPGA gates, probably more like 10k ASIC gates. An RS232 port uses about the same amount of logic as the 1355 ART port, even though RS232 is 25 to a few thousand times slower. I'd be interested to hear corresponding figures for Ethernet, USB, and FireWire, for both hubs and switches. Paul -- Paul Walker 4Links phone/fax paul@4Links.co.uk P O Box 816, Two Mile Ash +44 1908 http://www.4Links.co.uk Milton Keynes MK8 8NS, UK 566253Article: 12635
Marko, I've added a schematic for a buffered parallel port cable and
programming board that allows you to program Lattice Semiconductor's
ispLSI1016, ispLSI2032, and ispGAL22V10 devices. This is for folks that
don't have Lattice's ISP Starter Kit. You can download the archive from my
web page at:
http://www.teleport.com/~thandley/Wilbure.htm
Note, Lattice has updated the interface for 3.3V devices and I need to
update my schematic. For 5V devices, the schematic is fine.
- Tom
In article <70its7$cr4$1@nnrp1.dejanews.com>, ememka@my-dejanews.com wrote:
>Hello,
>
>Does somebody know where to find schematics for Lattice
>isp DOWNLOAD cable ?
>
>Thanks for any help.
>Marko.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Article: 12636
John L. Smith wrote:
> Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic,
> at least one-hots.
<snip interesting stuff about making schematics look like state
diagrams>
>
> Portability --> HDL
> Performance --> Schematic
Whilst I generally agree with most of what has been said, I can't fully
accept the "performance->schematic" axiom. People used to say much the
same about high-level languages and compilers. But then two things
happened:
(1) compilers got better at optimisation (much better!)
(2) folk began to recognise that the freedom of expression inherent in
a high level language allowed them to implement sophisticated but
hard-to-understand optimisations at a much higher level of
abstraction
For example: If you are searching a table and the only way you know how
is
to do a linear search, then assembler will win over a high-level
language
any day. But have you ever tried doing a hash table in assembler? Or
a balanced binary tree? OK, it's possible, but using a HLL you get all
the
inherent performance improvement (some orders of magnitude, in some
cases)
of the more sophisticated technique, **with minimal risk of erroneous
code**,
whilst suffering only the ???20% performance hit of HLL-vs-assembler for
the comparable algorithm.
Bottom line:
The performance gain from using the right algorithm is often hugely
greater
than the performance gain from using an optimal implementation method.
If the right algorithm is hard to understand or difficult to implement,
you
are more likely to get it right by using the highest-level tools at your
disposal. The performance cost of using such tools will be
insignificant.
Improvement (1) is just about beginning to happen (slowly) with HDLs.
Improvement (2) is really waiting for mainstream acceptance of higher
levels of abstraction than RTL, so that we can code useful algorithms
in our hardware. Meanwhile, we are still fiddling around just like the
early compiler users: the good designers will exploit HDL for its
portability and parameterisability, whilst learning how to write HDL
code
that's synthesis-friendly so the performance stays OK. Mediocre
designers will go on getting sub-optimal results as usual. And no, I
don't know with any precision where I fall on that spectrum of
design competence:-)
Jonathan Bromley
Article: 12637
Hi,
In the Lattice's application note an8003.pdf you may find an information
how to build your own DOWNLOAD cable.
The other reference which I used is the following article.
I hope this helps.
Alex
Re: Lattice ISP devices - diy cables?
From theo@marketto.demon.co.uk (Theo Markettos)
Date Sun, 28 Dec 1997 22:13:12 GMT
Newsgroups alt.comp.hardware.homebuilt
Message-ID <19971228.221312.58@marketto.demon.co.uk>
References 1
In article <34a6a51e.1031337@news.source.co.uk>,
duncan@ironhorse.source.co.uk (Duncan Entwisle) wrote:
> PRR
>
> I can't justify the 50-odd ukp for the cable for programming the
> Lattice devices using their starter software (especially as I suspect
> that its basically doing little more than parallel to serial
> conversion).
It's less than that - it's a 74VHC244 buffer, with an AND gate for JTAG
selection. I assume you've got their starter CD - I've got two copies of
it,
so can comment for version 1.0 and version 4.0.
With v1.0 the cable schematic is given in the promotional info for their
cable (in one of the big PDF files). This is for the ispDOWNLOAD cable
v1.0. With v4.0 you have to be a little more cunning - it can be found in
Application Note 8003 which details 'The Basics of One-Wire ISP with an
IrDA
Example' (it's in AN8003.PDF). This is the newer ispDOWNLOAD cable v2.0
which supports JTAG and 3V operation.
It uses a 74VHC244 and an unmarked AND gate with an inverter on one input -
my version seemed to work quite happily with a 74LS244 (or HC244) and
74LS00.
All the inputs (from the cable point of view) have 10K pull-ups, and the
outputs have a 100pF to ground and then a 100R series resistor.
My total investment in ISP to get a working system was:
3.23 UKP for an ispLSI2032
~0.10 UKP for the phone call to my local distributor to order the CD and
2032
~2.00 UKP for the cable (had bits to hand, so didn't need to pay for them)
Total 5.33 UKP
Compare this with other manufacturers who charge thousands of pounds just
for
a basic system.
> Are there any diy cable schematics out there, so that I can use their
> software? (It seems a little "not-nice" to have cheap development
> software to entice people to try it, and then to charge a fortune for
> the cable to actually connect to the device - when the device is
> theoretically electrically simple to program).
One very nice thing about v4.0 CD is that they provide the source code for
their programming routines (ispCODE), which creates all sorts of
interesting
possibilities for self-modifying hardware. They also publish the full
programming spec in one of the data sheets, so you could hand craft the
programming code if you didn't want to use their C routines.
It's just a shame you can't do anything with their bigger devices with
shelling out for their design software (even simple equation based designs
need it).
> I know that some of the regulars on here use the Lattice devices, and
> hope that I'm lucky and some of you will have a more cost effective
> solution - thanks.
Reflashable hardware is so nice...
Cheers,
Theo
--
Theo Markettos Home: theomarkettos@letterbox.com
Liphook Work: marketto@prl.research.philips.com
Hampshire
UK Web site, including HardBack pages
http://www.marketto.demon.co.uk/
Article: 12638Rita Madarassy <madarass@cats.ucsc.edu> wrote in article <70814q$ra9@darkstar.ucsc.edu>... > In article <01bdf929$1e70db90$55f65ecf@drt1>, > Austin Franklin <darkroo3m@ix.netcom.com> wrote: > >> > Try doing a functional simulation....I believe the underlying > >simulation > >> > libraries are not there.... > >> > >> >>I believe that is because the Virtex timing files were not in place > >when they > >> shipped F1.5 however, the timing models are coming. > > > >That was the point. The FAEs said that Xilinx has NO plans on providing > >these, or supporting ANY schematic tools for Virtex. > > I do not understand how anyone would make a big deal about this. > Mentor Graphics uses vhdl models to simulate their schematic > capture tool and it works great. Then you don't understand what the problem is. If you did, then you'd understand why it's a big deal. AustinArticle: 12639
Rickman wrote: > > > > > > attribute enum_encoding : string; > > > attribute enum_encoding of StateType : type is "one hot"; > > > > > > Once the synthesizer sees this it should not only synthesize your FFs as > > > one-hot, but should understand to only look at one FF to decode each > > > state. For example this is the code I use to assign a name to the IDLE > > > state output signal. > Sorry, I left out the case statement since I thought that was "obvious" > ;^( That wasn't quite my point. What I was asking is what can you do WITHIN the language spec. if the ``one hot'' attribute statements are rejected or ignored by the compiler/synthesiser. Maybe all known synthesisers DO accept this construction ? I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87).Article: 12640
>Bryn Wolfe <b.wolfe@ieee.org> >Date: 10/20/98 4:42 PM Eastern >Does anybody have footprints for Altera's BGA packages? I would try your local Altera FAE, or their hotline. I know at Lattice, that's where the fastest answers are. Mike Thomas LSC FAEArticle: 12641
Rick Filipkiewicz wrote: > > Rickman wrote: > > > > > > > > > attribute enum_encoding : string; > > > > attribute enum_encoding of StateType : type is "one hot"; > > > > > > > > Once the synthesizer sees this it should not only synthesize your FFs as > > > > one-hot, but should understand to only look at one FF to decode each > > > > state. For example this is the code I use to assign a name to the IDLE > > > > state output signal. > > > Sorry, I left out the case statement since I thought that was "obvious" > > ;^( > > That wasn't quite my point. What I was asking is what can you do WITHIN the > language spec. if the ``one hot'' attribute statements are rejected or ignored > by the compiler/synthesiser. Maybe all known synthesisers DO accept this > construction ? I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87). I don't know if the attribute "one hot" is part of the standard or not. Maybe Paul could help us here. I do know that it works with Metamor. That is the tool I used. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12642
Rickman <spamgoeshere4@yahoo.com> wrote: > Gareth Baron wrote: > > I would suspect that Xilinx and the other FPGA companies are basing thier > > decisions on the "must get it out quick" attitude, as who could possibly > > hand craft a 2 Million Gate FPGA (Virtex in the future) ? > > > > IMO, this should not be their decision but should be their customers'. > > That would be great if Xilinx had unlimited resources. But in the real > world they have limited dollars to spend on developing tools. One would > assume that they have decided that supporting the use of schematic tools > with the Virtex chips has reached the point of diminishing returns in > terms of how many customers would use them. > > Xilinx can't always give everyone everything they want. This may just be > getting too expensive for them. So I am sure that if people call Xilinx > and tell them that these tools are still "required", they will spend the > time and money to support them. Yeah, like the time Xilinx decided that their PPR software didn't need to do re-entrant placement and routing. After all, the 4000 series marked the dawn of a new age where the software did it all for you and you didn't need to do ANY hand placement or routing. It only took a year or two for them to fix this "bug" in their system.Article: 12643
look at http://www.frontierd.com. Frontier Design has developed A|RT library , a library to handle fixed point in the c or c++ language. They also have A|RT Builder, a program that translates this c automatically into synthesizable vhdl or verilog. junsc@sysic.hei.co.kr wrote in article <703q97$c1n$1@nnrp1.dejanews.com>... > Hi, All > > The problem is that I'm very new to this fixed point arithmetics coding and > FPGA implementation. > > Is there any good web/ftp site related to fixed point arithmetics HDL coding, > especially Verilog and FPGA insight. Tutorial and examples would be great. >Article: 12644
Rickman <spamgoeshere4@yahoo.com> wrote: > Rick Filipkiewicz wrote: >> Rickman wrote: >> > > > attribute enum_encoding : string; >> > > > attribute enum_encoding of StateType : type is "one hot"; >> > > > >> > > > Once the synthesizer sees this it should not only synthesize your FFs as >> > > > one-hot, but should understand to only look at one FF to decode each >> > > > state. For example this is the code I use to assign a name to the IDLE >> > > > state output signal. >> >> > Sorry, I left out the case statement since I thought that was "obvious" >> That wasn't quite my point. What I was asking is what can you do WITHIN the >> language spec. if the ``one hot'' attribute statements are rejected or ignored >> by the compiler/synthesiser. Maybe all known synthesisers DO accept this >> construction ? I'll try it with Metamor (VHDL-93) & Synopsis (VHDL-87). > I don't know if the attribute "one hot" is part of the standard or not. > Maybe Paul could help us here. It's not part of the language--it may be part of the standard synthesis package. It will no doubt be part of the standard synthesis subset. Paul -- Paul Menchini | mench@mench.com | "Se tu sarai solo, Menchini & Associates | www.mench.com | tu sarai tutto tuo." P.O. Box 71767 | 919-479-1670[v] | -- Leonardo Da Vinci Durham, NC 27722-1767 | 919-479-1671[f] |Article: 12645
C A L L F O R P A P E R S
THE SEVENTH ANNUAL
IEEE SYMPOSIUM ON FIELD PROGRAMMABLE
CUSTOM COMPUTING MACHINES
Napa, California
April 21-23, 1999
http://www.fccm.org
PURPOSE: To bring together researchers to present recent work in the
use of reconfigurable logic as computing elements. This symposium
will focus primarily on the current opportunities and problems in this
new and evolving technology for computing. Contributions are
solicited on all aspects of custom computing, including but not
limited to:
Architecture of reconfigurable computing devices and systems,
including coprocessors, attached processors, and hybrids.
Languages, compilation techniques, tools, and environments for
programming and run time support;
Application domains;
Prototyping for architecture emulation.
SUBMISSIONS: Authors are invited to send submissions for either full
length papers (10 page maximum) or extended abstracts (2 page maximum)
for posters by January 8, 1999, to Jeffrey Arnold. Please indicate
whether you seek consideration as a full paper or as a poster.
Notification of acceptance will be sent in early March. Final papers
will be due on the first day of the Symposium. The proceedings will
be published following the Symposium.
Authors are encouraged to submit PostScript or PDF manuscripts by FTP.
Format and submission instructions are available on the FCCM web page
(www.fccm.org), or authors can contact Jeffrey Arnold (jmarnold@znet.com).
Authors are also encouraged to bring demonstrations of their work.
Space will be made available during the demo event to be held
Wednesday, April 21. Details will be available on the web page.
SPONSORSHIP: The IEEE Computer Society and the Technical Committee on
Computer Architecture.
CO-CHAIRS:
Kenneth L. Pocek
Intel
Mail Stop RN6-18
2200 Mission College Boulevard
Santa Clara, California 95052
Voice: 408-765-6705 Fax: 408-765-5165
kenneth_pocek@ccm.sc.intel.com
Jeffrey M. Arnold
10686 Mira Lago Terrace
San Diego, CA 92131
Voice: 619-547-9257 Fax: 619-547-9010
jmarnold@znet.com
PROGRAM COMMITTEE:
Peter Athanas, Virginia Tech.
Donald Bouldin, University of Tennessee, Knoxville
Duncan Buell, Center for Computing Sciences
Michael Butts, Synopsys
Steve Casselman, Virtual Computer Corp.
Pak Chan, Univ. California, Santa Cruz
Andre DeHon, Univ. California, Berkeley
Apostolos Dollas, Technical Univ. of Crete
Scott Hauck, Northwestern Univ.
Brad Hutchings, Brigham Young Univ.
Tom Kean, Algotronix, Ltd.
Phil Kuekes, HP Labs.
Wayne Luk, Imperial College
John McHenry, NSA
Robert Parker, Institute for Information Sciences
Viktor Prasanna, University of Southern California
Herman Schmit, Carnegie Mellon University
Mark Shand, Compaq System Research Center
Satnam Singh, Xilinx
Stephen Smith, Altera Corp.
Roger Woods, The Queen's University of Belfast
--
Jeffrey M. Arnold jmarnold@znet.com
10686 Mira Lago Terrace Tel: 619-547-9257
San Diego, CA 92131 Fax: 619-547-9010
USA
Article: 12646In article <01bdfce5$8fcfc2f0$25f65ecf@drt1>, Austin Franklin <darkroo2m@ix.netcom.com> wrote: > > >Rita Madarassy <madarass@cats.ucsc.edu> wrote in article ><70814q$ra9@darkstar.ucsc.edu>... >> In article <01bdf929$1e70db90$55f65ecf@drt1>, >> Austin Franklin <darkroo3m@ix.netcom.com> wrote: >> >> > Try doing a functional simulation....I believe the underlying >> >simulation >> >> > libraries are not there.... >> >> >> >> >>I believe that is because the Virtex timing files were not in place >> >when they >> >> shipped F1.5 however, the timing models are coming. >> > >> >That was the point. The FAEs said that Xilinx has NO plans on providing >> >these, or supporting ANY schematic tools for Virtex. >> >> I do not understand how anyone would make a big deal about this. >> Mentor Graphics uses vhdl models to simulate their schematic >> capture tool and it works great. > >Then you don't understand what the problem is. If you did, then you'd I remember you. You are the guy who claims viewsim supports concurrency because you can generate a clock signal right? You are also the guy who does not know what a vhdl testbench is, probably the only person n this newsgroup. >understand why it's a big deal. > >Austin >Article: 12647
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDFD39.6A7A6C45 Content-Type: text/plain; charset="koi8-r" I am using XC4005E-2 at 136 MHz - it works! -----Original Message----- From: yves@px.uk.com (Yves Tchapda) [mailto:yves@px.uk.com] Posted At: Wednesday, October 14, 1998 2:46 PM Posted To: comp.arch.fpga Conversation: 100 MHz FPGA Subject: 100 MHz FPGA Hi, We are developing a high bandwidth switch architecture and we need to test each switch interface at maximum speed of 100MB/s, which with an 8-bit interface requires a clock of 100MHz. Is there any FPGA out there that would be able to sustain pumping data at this rate? I thought of using a slower clock and a 32-bit interface from the FPGA and then probably use a CPLD to multiplex the data to the switch 8-bit interface. But there are problems associated with this. Any suggestions? Dr Yves Tchapda e-mail yves@px.uk.com ------_=_NextPart_001_01BDFD39.6A7A6C45 Content-Type: text/html; charset="koi8-r" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>RE: 100 Mhz FPGA</TITLE> </HEAD> <BODY> <BR> <P><FONT SIZE=2>I am using XC4005E-2 at 136 MHz - it works!</FONT> </P> <P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From: yves@px.uk.com (Yves Tchapda) [<A HREF="mailto:yves@px.uk.com">mailto:yves@px.uk.com</A>]</FONT> <BR><FONT SIZE=2>Posted At: Wednesday, October 14, 1998 2:46 PM</FONT> <BR><FONT SIZE=2>Posted To: comp.arch.fpga</FONT> <BR><FONT SIZE=2>Conversation: 100 MHz FPGA</FONT> <BR><FONT SIZE=2>Subject: 100 MHz FPGA</FONT> </P> <BR> <P><FONT SIZE=2>Hi,</FONT> <BR><FONT SIZE=2> We are developing a high bandwidth switch architecture and we need to</FONT> <BR><FONT SIZE=2>test each switch interface at maximum speed of 100MB/s, which with an</FONT> <BR><FONT SIZE=2>8-bit interface requires a clock of 100MHz. Is there any FPGA out</FONT> <BR><FONT SIZE=2>there that would be able to sustain pumping data at this rate? I</FONT> <BR><FONT SIZE=2>thought of using a slower clock and a 32-bit interface from the FPGA</FONT> <BR><FONT SIZE=2>and then probably use a CPLD to multiplex the data to the switch 8-bit</FONT> <BR><FONT SIZE=2>interface. But there are problems associated with this. Any</FONT> <BR><FONT SIZE=2>suggestions?</FONT> </P> <P><FONT SIZE=2>Dr Yves Tchapda</FONT> <BR><FONT SIZE=2>e-mail yves@px.uk.com</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01BDFD39.6A7A6C45--Article: 12648
>What is the meaning of LFSR? >What is the meaning of LFSR? Linear Feedback Shift Register, a method of generating pseudo-random number sequences. Simple feedback logic (therefore fast) but the output code sequence (while predictable and repeatable) intelligible (hence lower noise, the count bits change at random and you don't get repetitive overflows at harmonics of the clock rate). The best explanation is in Clive Maxfield's Designus Maximus book.Article: 12649
In article <362DB291.164EDD5@brookes.ac.uk>, Jonathan Bromley <jsebromley@brookes.ac.uk> writes >John L. Smith wrote: >> Even SMs can be drawn clearly and in an easy to follow mannerwith a schematic, >> at least one-hots. ><snip interesting stuff about making schematics look like state >diagrams> >> >> Portability --> HDL >> Performance --> Schematic > >Whilst I generally agree with most of what has been said, I can't fully >accept the "performance->schematic" axiom. People used to say much the >same about high-level languages and compilers. But then two things >happened: >(1) compilers got better at optimisation (much better!) >(2) folk began to recognise that the freedom of expression inherent in > a high level language allowed them to implement sophisticated but > hard-to-understand optimisations at a much higher level of >abstraction That is a commonly held belief but IMHO it is an over simplification, what actually happened was - 1) The underlying processors had facilities added to aid the efficiency of high level languages - things like h/w stacks, frame pointers etc etc 2) Language design itself got better making good compilers easier to write and (more especially) easier to use. This is what made your (2) possible. Fortran 1 is actually little better than assembler for coding complex algorithms. Actually compilers still aren't that good at optimisation as such, but the task has been made easier (or maybe less necessary) by changes in their "operating environment". Many so called optimisations made by current compilers are essentially get arounds for architectural features like delayed branches that have themselves been added in the knowledge that the compiler could handle them! >For example: If you are searching a table and the only way you know how >is >to do a linear search, then assembler will win over a high-level >language >any day. But have you ever tried doing a hash table in assembler? Or >a balanced binary tree? OK, it's possible, but using a HLL you get all >the >inherent performance improvement (some orders of magnitude, in some >cases) >of the more sophisticated technique, **with minimal risk of erroneous >code**, >whilst suffering only the ???20% performance hit of HLL-vs-assembler for >the comparable algorithm. Only if you use a suitable HLL and most early HLL s weren't much good at those kinds of task. > >Bottom line: >The performance gain from using the right algorithm is often hugely >greater >than the performance gain from using an optimal implementation method. True >If the right algorithm is hard to understand or difficult to implement, >you >are more likely to get it right by using the highest-level tools at your >disposal. The performance cost of using such tools will be >insignificant. but are the current generation of HDL's genuinely High level in the sense that software HLL s are? Speaking as a S/w person primarily (but with a strong h/w interest and involvement) current so-called highlevel HDL s are only high level in places elsewhere (particularly when timing/synchronisation is involved) they seem toi me to be more comparable to assembly language - maybe even microcode! > >Improvement (1) is just about beginning to happen (slowly) with HDLs. but does the FPGA cell design need to be bent to the requirements of HDL's? (I'm working by analogy here - but I would be interested to know if anyone has a "hard" answer to this question) >Improvement (2) is really waiting for mainstream acceptance of higher >levels of abstraction than RTL, so that we can code useful algorithms >in our hardware. Yes! > Meanwhile, we are still fiddling around just like the >early compiler users: the good designers will exploit HDL for its >portability and parameterisability, whilst learning how to write HDL >code >that's synthesis-friendly so the performance stays OK. Mediocre >designers will go on getting sub-optimal results as usual. And no, I >don't know with any precision where I fall on that spectrum of >design competence:-) Same as programmers! :¬) -- Richard Cant
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