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
> kim tae-chang wrote: > > > > Is there any site from where I can down load a free max+plus ll(ALTEAR > > COMPANY) simulator and runs on Windows 95 environment. > > This simulator must handle big projects (up to 10k gates) in timing > > simulation. > > There is only one _free_ MAX+plus II software. It's available at > http://www.altera.com > > For big projects and with timing, the software is $$$. about US$2k,also, you cant simulate on the demo. BrettArticle: 14226
John, welcome to comp.dsp! Well, you already know that I am a strong proponent for schematic based design for FPGAs, so you might be a little surprised by the following response. The way I see it, HDLs do have real advantages, however there are some serious disadvantages when applied to high performance FPGA designs. As I see it, the two real advantages that HDLs have over schematics for FPGA design are: a) Access to archived designs. A schematic design requires a compatible viewer or hardcopy to read an archived design. As schematic entry tools evolve, some of the older formats get dropped, so some legacy designs may no longer be readable, and all designs are inaccessible to someone without the correct reader. On the other hand a text based design can be read by any text editor capable of accessing a file the size of the design file (notepad will probably not cut it for more complicated designs). b) Significantly enhanced simulation capabilities. VHDL brings with it the ability to simulate using behavioral models in place of a detailed circuit simulation using the same toolset as used with the detail design simulation. This provides the ability to simulate a design or design fragment before the detail design is done (helps to avoid getting to far down the wrong path). Verified portions of the design can also be aliased to behavioral models to cut down on the computational power required to do the simulation. There are several other "benefits" bandied about by the marketing types, which, depending on the context have some degree of truth: a) Design readability. A well done hierarchical schematic is generally more readable than HDL code...its the picture is worth a thousand words thing. However, in my experience, the average engineer does not do a very good schematic. The number one crime is the lack of or improper use of a hierarchy. Schematic based design does not naturally impose hierarchy, so the temptation is to create a flat schematic. Sixty plus pages of flat schematic are next to impossible to read. Almost as bad are the hierarchical designs that have not been logically partitioned. To keep schematics readable, the schematic at each hierarchical level should be limited to one page, the page should be fairly sparse (probably no more than 10 symbols) and the hierachical blocks should be logically partitioned so that each is a complete function to itself. All this takes some time to do, but there are rewards for following a strict discipline. It can be difficult to resist the urge to squeeze one more thing (many times over) onto a page. HDLs on the other hand, naturally encourage hierarchy in the design which leads to legibility. Also, certain circuit elements lend themselves to a textual description; examples are state machines and combinatorial decoders. We've all seen examples of both that wind up being a jumbled mess of AND and OR gates wired in some incomprehensible manner. <I do use a schematic methodology for one-hot state machines that makes the schematic look like a flow chart to make schematic statemachines easy to construct and understand> b) Design reuse. This is more of an issue of properly using hierarchy. A design that is hierarchically broken down into successivly smaller complete functional units lends itself to reuse regardless of the capture methodology. The fact that HDLs encourage good hierarchical breakdown makes HDL design fragments natural for reuse. In schematics, you need to work at it. c) Design portability. This again is partly a hierarchy issue. If the design is properly broken into a hierarchy, it can be retargeted at a different technology by simply changing the library for the lowest levels of the hierarchy. This requires libraries for the different technologies to have the same interfaces to the upper levels: for schematics it means the same symbol names, shapes, sizes, pin locations etc. For HDLs it means pretty much the same thing. Where the different vendors have really not standardized in this area, the user needs to create a translation library to smoothly transition from one technology to another. Developing unified library elements is a sizable task, and one I don't think the one FPGA design a year crowd wants to embark upon. Now the translation is a little easier in HDLs, because the graphic elements (pin locations and symbol size) are no longer in the equation. This is a small consolation. Where HDLs have the big advantage is when synthesis is used to infer the low level structure of the design. If that is the case, there is little the user needs to do to port the design...assuming he did not go to low level construction. The problem with synthesizing from a higher level description is that you give up the control of the design implementation and placement. The cell granualarity in most FPGAs is not handled well with current synthesis, although significant improvements have been made mostly with libraries of primitive functions targeted at specific devices. In high performance/density designs you usually lose to much when you relinquish control of the implementation to the synthesizer. d) Ease of entry. Proponents of VHDL often state that a design can be entered faster in textual form. IMHO, it really depends on the design and your design objectives. State machines, for example can be easily entered and later grokked in a textual format. The state machine implementation can be controlled do some degree with the coding style and with synthesis option switches. On the other-hand dataflow and memory intensive designs tend to be easier to do with a schematic. A true advantage textual descriptions have over schematics is the ability to easily accommodate parameterized elements (for instance data path elements whose implemented bit width is dependent on context), something that is quite difficult to do with schematics. Generally for schematics, some macro generator is used to produce a symbol and an optimized implementation. For schematic entry, there is usually no synthesis (Altera MaxPlus II is an exception), so the implementation is explicit. The place and route tools will do some boolean minimization and such to improve the design. In schematics, this is easily overridden if there is a reason for a particular implementation using mapping constructs and placement attributes. These are applied directly to the affected schematic symbol. Applying similar implementation and design constraints in VHDL is tedious (akin to writing a textual netlist of the circuit). Applying placement constraints is inconsistent from tool to tool, and those constraints in some cases are not hierarchical. For low level design control, the schematic entry method is considerably easier to do. So the bottom line is HDLs do give significant advantages for simulation and archiving, and depending on the project, may also provide advantages by synthesizing the design details. For FPGA designs other than low performance ones, the cost of synthesis is currently too high in terms of lost performance and density to achieve the advantages from high level (RTL) synthesis. That cost can be circumvented by low level instantiation, but it is currently more painful than doing the same low level designs in schematic form. Keep in mind, that the designs I do are typically DSP data path designs with sample rates between 40 and 100 MHz, and often in slower speed grade devices. -- -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: 14227
I don't know for sure, but I assume that if you don't specify one of those options, the default is to NOT pack FFs into the IOBs. Dominic Reitman wrote: > > I've only done functional simulation and it operates ok, it's when I > download the bit file to the FPGA that I physically test an expensive wire. > Also, is there anyway to make that IOB setting from the DOS prompt? the > syntax for the "map" command shows settings to pack FF/latches into input, > output, or both types of IOB's (map -pr i|o|b ...). > > Thanks > Nick > > Rickman wrote: > > > Here is my guess as to what is happening. I think your circuit is being > > synthesized correctly. But the FF is being pushed into the IOB of the > > input port. The messages above indicate this. The warning may be from > > the fact that the input and output IOB are now connected by a wire. > > > > If you go to the project manager and select "Implementation" and > > "Implementation Option" you will get the options dialog box. On the line > > that says "Implementation" click the "Edit Template" button and a new > > dialog box will come up. Find the "Pack I/O Registers/Latches into IOBs > > for:" control. Select "OFF". Now click OK and OK again. Now redo your > > Implementation. and you should get a good result. > > > > When you say that the output follows the input without waiting for the > > clock, are you running a simulation, or testing a chip? If a simulation, > > is it a functional simulation or timing (after place and route)? > > > Rick Collins -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 14228
Synopsys, are you listening??? VHDL-93 NOW! Andy Peters wrote: > > Ido Kleinman wrote in message <77lek9$5mo$1@news2.inter.net.il>... > > >I've been using Foundation 1.4 with it's Metamor synthesis for a while now, > >and I've got a few working designs. > >I recently moved to Foundation 1.5 and it's FPGA Express synthesis - > > In case it wasn't clear from Evan's post: Metamor is a VHDL'93-compliant > tool, FPGA Express is VHDL'87-compliant (with a couple of '93 things thrown > in). The problems you're having are a result of Synopsys still living in > the Reagan era. > > >1. FPGAEXP won't accept: > >if (LowerAddressBus > X"01F0") then > > >LowerAddressBus is just a std_logic_vector(15 downto 0). > > >it yells about type mismatch between left/right binary operand. The X seems > >to be disturbing - it would only accept Binary notation without any prefix > >to the " character so I have to write: > > The X"xxxx" construct is valid only for bit vectors in '87. (See Evan's > comments.) SLVs are fine with it with '93. That's why Metamor was happy and > FPGA Express was not. > > >I tried using based literals such as 16#01F0# and variations - and it won't > >work. Any solution, or I will have to do all my comparisons in Binary? > > Make sure you've included ieee.std_logic_arith.all and > ieee.std_logic_unsigned (or signed) and do a conversion: > > if (LowerAddressBus > CONV_STD_LOGIC_VECTOR(X"01F0", 16) then > > which of course is a Synopsys work-around. > > >2. My inhibit_buf attribute on my global Clk signal wasn't accepted! What's > >the attribute for inhibiting insertion of IBUFs/OBUFs/etc on FPGAEXP? I > >don't want my clock signal buffered with a standard IBUF, that why I > usually > >instanciate a BUFG/BUFGS for it and inhibit other buffers on the pad in the > >code. > > FPGA Express is smart enough to recognize a clock as a clock (based on > sensitivity lists and how the signals are used in processes), so you don't > need to inhibit the IBUF on your clock signal. A BUFG is automagically > instantiated for you. > > >3. After I made the annoying adjustments to my code, my previously working > >simulation files yielded strange new results in which some output signals > >were defined as "????" - what's this? I thought std_logic "only" has 9 > >states... > > Sounds like a VHDL'87 vs '93 problem. What simulator are you using? Make > sure you compile all of your sources as VHDL'87 now! > > >4. What about my two-dimensional arrays? I am not trying to synthesize > >anything special - just some better-looking-VHDL multi-bit look-up > tables... > > FPGAEXP won't support it? > >Forever? > > With Synopsys, who knows? Maybe when VHDL'2K comes out. Then they'll be at > the '93 level. > > -- andy > ------------------------------------------ > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters@noao.edu > > "In the beginning, there was darkness. And it was without form, and void. > And there was also me!" > -- Bomb #20, John Carpenter's "Dark Star" -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 14229
C Kuethe wrote: > > In a dusty old storage closet here, I dug up an XACT XC-DS21 evaluation > kit, complete with demo board and dongle. I installed XACT on an IBM box, > 486 w/ 16M ram. Unfortunately, when I try to run the software, I get an > error to the effect of "can't find the key." Xkey reports no valid keys. I > checked the key on other machines and check my bios settings to make sure > that it wasn't the parallel port failing, but no machine found any keys. > > Does anyone have any idea on where to go from here? > > Be Well, > Chris > > -- > Chris Kuethe: System Administrator - U of A Math Dept > http://www.[math.]ualberta.ca/~ckuethe/ > pager: 403.917.6448 office: CAB553, x1704 cell: 903.9475 > wargames@edmc.net ckuethe@ualberta.ca > ckuethe@math.ualberta.ca ckuethe@gecko.math.ualberta.ca I seem to remember that the old keys were nothing but a downcounter that was reset to its internal value, then clocked until the output changed. The number of clocks was the key "value". I don't know for sure, but I think the number 157 might have some magical properties in this context. I will try to find my old notes. If you hav e the number and know which pins are toggling, you can make a new key from a PAL. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 14230
In article <36A6BD35.52386799@ids.net>, Ray Andraka <randraka@ids.net> writes: Nice info. Thanks. > a) Access to archived designs. A schematic design requires a compatible > viewer or hardcopy to read an archived design. As schematic entry tools > evolve, some of the older formats get dropped, so some legacy designs may no > longer be readable, and all designs are inaccessible to someone without the > correct reader. On the other hand a text based design can be read by any text > editor capable of accessing a file the size of the design file (notepad will > probably not cut it for more complicated designs). I consider collecting up postscript/pdf versions of the schematics to be part of the archive-and-release process. For PCBs, I assume the layout system makes a text format wirelist of the board. I want two versions. One is sorted by signal name showing all the parts and their pins where each signal goes. The other is sorted by part showing the signals connected to each pin. I'm not quite sure what part of an FPGA design corresponds to the "wirelist". I usually save various intermediate files as part of the archive-and-release process. For FPGAs up to the size of a 3090, printing things on 11*17 paper is often useful. -- These are my opinions, not necessarily my employers.Article: 14231
I don't want to get into an argument here, but it's time that someone actually explained why people use VHDL. There are a lot of people in this newsgroup (.fpga) who will defend the use of schematics, but few who will bother to argue the case for VHDL. There are only two significant reasons to make the large investment required to convert to the xHDL flow: simulation, and synthesis. Ray has covered the simulation advantage. However, there are two points he didn't explicitly mention. The first is that you can simulate the system around your device, and the interaction with your device, as well as simulating the device itself. It would be foolish for anyone developing a large-NRE device not to carry out a system-level simulation. The second is that you can use the same testbench to carry out a simulation at any stage of the design: behavioural (during device definition and analysis), RTL (after coding), post-synthesis, and post-PAR. The second reason is, of course, synthesis. If you have a large device, limited manpower, a limited budget, and a tight schedule, then you need a synthesiser. If you quantify these 4 parameters for your own circumstances, then you may well decide that synthesis is not appropriate for you. There are other circumstances in which synthesis may not be appropriate. If you only produce DSP designs, for example, and your devices simply reuse existing technology blocks, then a synthesiser is unnecessary. By the way, the PAR tool is absolutely *not* the appropriate place to carry out synthesis or optimisation. A synthesiser must have knowledge of the low-level architecture, and must have the ability to iterate between boolean and gate-level optimisations in order to meet constraints. An 'optimising' PAR tool will simply break this cycle. It's true that first-generation FPGA synthesis tools may have relied on an optimising back end, but this isn't normally the case now. If you discover that your synthesiser is producing a gate-level representation, and is then relying on the PAR tool to translate this into CLBs, or whatever, then you should get new tools or silicon. As an aside, it's occasionally said here that the VHDL flow produces designs that are slow or inefficient (it's obviously true that synthesis may occasionally produce non-optimal results; this is what constraints are for. If the constraints fail, try something else). However, this now seems to have been replaced with the statement 'Ok, you can do exactly what you want with VHDL, but you have to write a netlist'. I guess that I'm the source of this statement, so perhaps I can clarify it: you can do exactly what you want with VHDL, by writing a structural description, which is precisely what you're doing with a schematic. Both are equivalent to netlists, and both will require additional attributes for precise placement and routing. The VHDL looks like VHDL, and nothing like an EDIF or XNF netlist. Whether you choose schematics or VHDL depends on your individual circumstances. There's a large learning curve and significant expense in the VHDL route, so it shouldn't be undertaken lightly. EvanArticle: 14232
Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote: > kim tae-chang wrote: >> Is there any site from where I can down load a free max+plus ll(ALTEAR >> COMPANY) simulator and runs on Windows 95 environment. >> This simulator must handle big projects (up to 10k gates) in timing >> simulation. > There is only one _free_ MAX+plus II software. It's available at > http://www.altera.com > For big projects and with timing, the software is $$$. So is there ANY way to do free FPGA work yet? Like little projects for home? There's a collection of things around, but each have drawbacks. ActiveVHDL is very nice, but the demo (a) is simulation-time limited, and (b) expires after 1 month. It also appears to use a LOT of RAM, but I don't mind that so much. I gather this is pretty expensive. Synopsis have an FPGA Express demo, for VHDL. But the design size is limited to something quite small, and then there's no way to route the output netlist anyway. Altera have the MAX+PLUS II baseline. It can synthesize and compile AHDL or schematics. It can't do VHDL, but I can live with AHDL (although the help doesn't really make a very good tutorial). But you can't simulate it, and the device range is reasonably limited. So what other options are there? I want to be able to enter a design, either in an HDL or schematics (preferably the former), simulate it, and route it for a device I can get reasonably easily. (Xilinx is the easiest to get in Melbourne in my experience.) I've used Mentor, XACT 5.2, XACT M1.4 and Synopsis at uni and at work, and it's frustrating not to be able to get this stuff for home. If the manufacturers concentrated on selling chips and gave the software away, they might just sell a few more chips! I imagine that for a startup company, the cost of software tools could be quite important. For a home user it is obviously crucial. Hamish -- Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au Rising Software Australia Pty. Ltd. Developers of music education software including Auralia & Musition. 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 Internet: http://www.rising.com.au/Article: 14233
In article <783359$ds2$1@pulp.ucs.ualberta.ca>, C Kuethe <ckuethe@gpu.srv.ualberta.ca> wrote: > In a dusty old storage closet here, I dug up an XACT XC-DS21 evaluation > kit, complete with demo board and dongle. I installed XACT on an IBM box, > 486 w/ 16M ram. Unfortunately, when I try to run the software, I get an > error to the effect of "can't find the key." Xkey reports no valid keys. I > checked the key on other machines and check my bios settings to make sure > that it wasn't the parallel port failing, but no machine found any keys. > > Does anyone have any idea on where to go from here? > > Be Well, > Chris > > -- > Chris Kuethe: System Administrator - U of A Math Dept > http://www.[math.]ualberta.ca/~ckuethe/ > pager: 403.917.6448 office: CAB553, x1704 cell: 903.9475 > wargames@edmc.net ckuethe@ualberta.ca > ckuethe@math.ualberta.ca ckuethe@gecko.math.ualberta.ca > > Another idea may be to install the newest drivers for the Sentinel or Rainbow dongle. Xkey is a DOS program, when running under Windows NT it requires a driver to access the dongle, maybe under Win95/98 too. Hope this helps Klaus -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14234
Please forgive me the terms in this e-mail, since I am using "synthesis" and "compilation" interchangeably. > I used synplicity on a Xilinx 40150. The versions I used were: > 5.0.6, 5.0.7 and 5.0.8. Before getting to know synplicity, I > used Synopsys's FPGA Compilor on a Xilinx 4036. All works were > done on SUN workstations. Here is a summary of problems that > I have seen: > > 1. Crashing the WS from 5.0.6 to 5.0.7 when browsing the design > under technology view. 5.0.8 seemed to fix the problem although > there exist a Solaris patch to fix the a video card bug. > > 2. Running out of memory on 5.0.7. There is a memory leakage > problem that eats up all 1Gbytes of RAM in our Ultra. 5.0.8 > fixed this problem. > > 3. Doing mapping forever on 5.0.6. The design ran for 20 hours > and still not done! 5.0.8 fixed this problem. We got the same problem with a Sun sparcSTATION 4. I think it is something like "compilation deadlock", since we have seen for hours long harddisk is running away. We tried to fix this problem by exiting and rerunning the program and it worked 60%. > 4. Misleading CLB usage count. In the beginning, I used the stats > reported in the .srr file to estimate how big the device would be. > Big mistake, as a lot of CLBs are used as route through and > the final size is 20% bigger (roughly). Exactly. The number of CLB's used in Design Manager are given ca 1.2 - 1.5 times the number of CLB in Synplify. This is a very important issue, and must be fixed somehow. > 5. Timing estimation is way off. At one time, we have hundreds > of timing violation from par. The par figure reported was like > 19 nanosecong worst than that estimated by synplicity. Overall > synplicity's estimate is always too optimistic. I agree. Timing estimations are sometimes unbelievable, for example if there are multiple clocks in the design, and if there are slack information for one of external clocks, output logs show slacks of a very different region of the chip which is not running at that clock. We got an 8.192 MHz external PCM clock and slack information related to this clock include regions running at 25 MHz!!! > These are the worst problem that I have. There are many more. On the > plus side, the compile speed is very high compare to the FPGA > compiler. On the 4036 design, it was like 180 seconds vs 3.5 hours. > As well, the support is excellent. Every call is answered very > quickly with work around that works. The tool has improved a lot > since the beginning but is still being developed. At the end, > we decided to stay with synplicity inspite of its many problems. We have used 3.0c, 5.0.7 and 5.0.8 version of Synplify. I must say that the compilation speed is very fast. Our target technology was XC40110XV. FPGA Express compiled the chip in 1.5 hours whilst Synplify 5.0.7 compiled in 4 minutes and 5.0.8 in 2 minutes!! It is a promising time to make Tcl-base algorithmic iterations. In addition, you must pay attention to design with multiple clocks when synthesizing Synplify. You can define a constraints file which include constraints of the clocks. But synthesizer wants to enter a global clock frequency value. Our examinations show that the fastest result of synthesizer are around the frequency region where most of logic are running. For example, if you have 25 MHz and 10 MHz external clocks are if the regions running at 10 MHz are 80% of the chip, then the global frequency around 10 MHz gives best results. But not always ;-) UtkuArticle: 14235
ems@riverside-machines.com.NOSPAM writes: > I don't want to get into an argument here, but it's time that someone > actually explained why people use VHDL. There are a lot of people in > this newsgroup (.fpga) who will defend the use of schematics, but few > who will bother to argue the case for VHDL. Intuitively, I would like to argue for VHDL or other text-based description formats, too, but I find it hard to find really convincing arguments. I think you can currently do _more_ with text based `languages' because they are better understood from a language design point of view. But I see no fundamental reason why graphical tools could not catch up. With textual languages, you can specify the grammar and formal rules for what each construct means, for example. They allow for much more powerful abstraction mechanisms, because they do not pretend to be intuitive to begin with. With schematic layout things, I think we still haven't a really good separation between the `format' and the tool used to edit it, like we have for text languages. And the tools for working with text are just plain better and more mature than the ones for graphical descriptions. I do not think the old saying "a picture is worth a thousand words" can really be used as an argument here. The other way around is just as true: "a word is worth a thousand pictures". We should and can have both. Schematic tools produce static, declarative descriptions, AFAICS, while textual languages allow for a more active, procedural descriptions. Take the GENERATE statement in VHDL. How many schematic capture tools support such a thing? Would it be useful? I think yes. [Note, I know next to nothing about the current state of the art in schematic capture, so these are actually not rhetoric questions.] What is really needed is a way to combine the best of both worlds, as always. Allow the intuitive design of structural relationships via graphical nets, just like you would use them on a white board when reasoning about them with your colleagues. Allow for more abstract notions like parameterized repetition of subnets, conditionals, and support for `higher order schematics'. Allow for the seamless integration of things that are better described textually, like actual pieces of software that runs on your hardware or high-level algorithmic signal munching. > There are only two significant reasons to make the large investment > required to convert to the xHDL flow: simulation, and synthesis. Insofar as schematic descriptions are `inferior' to textual ones, you can certainly convert your schematic into the textual form and then simulate and synthesize that. What's more important, IMO, are the thoughts you can't think and teh things you can't say in your schematic. - Marius -- Go Meta!Article: 14236
Peter wrote: > > The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977! Mine is actually early 90's. This series, i.e. "Op-Amp Cookbook", etc., is right up there with the bible, "Art of Electronics". > There is also an algorithm called Cordic. I have no info but a post in > comp.arch.fpga should elicit a response from one of the very helpful > contributors there. I did a quick net search, and turned up a few papers by Ray Andraka, that give a very good introduction. As such, I would like a few of the CORDIC experts out there to recommend a good reference text on CORDIC specifically, and distributed math, or atleast a hardware oriented algorithm book more generally. I have some great texts in my library that are "software oriented". Seems the computer science world likes to assume that a register oriented or traditional DSP architecture, with a multiplier, is being used. Xilinx apnotes, and other papers have always been where I have needed this sort of information, but a good general text on the matter would be nice. Any suggestions? Regards, Erik Widding Birger Engineering, Inc. > > >Peter wrote: > >> There is a way to get > >> digital-precision sinewaves from a feedback shift register arrangement > >> - email me if you need more info; I have a book. Get the whole thing > >> into a small FPGA. > > > >What is the name of the book? > > -- > Peter.Article: 14237
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_01BE4542.1F6D51EE
Content-Type: text/plain;
charset="koi8-r"
Dear colleagues,
I am considering using FPGA for 1ns-accurate measurements.
As well as I understand, it is hardly possible to feed 1GHz clock
frequency into FPGA.
My questions are:
1) Has anybody used some kind of frequency prescaler in connection
with FPGA?
What prescalers are suitable for such purpose? Does
anybody know VHF counters with internal stages accessible (which is
necessary to obtain lowest bits of the counter)?
2) Is it possible for XILINX Virtex to generate 1 GHz internally,
through it's on-chip PLL?
3) Is Altera's on-chip PLL capable of such frequencies?
Thanks,
Alex Sherstuk
sherstuk@amsd.com <mailto:Sherstuk@amsd.com>
AMSD Company
------_=_NextPart_001_01BE4542.1F6D51EE
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Q: Counting GHz pulses - ?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2 FACE=3D"Arial">Dear colleagues,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial"> I am considering using FPGA for =
1ns-accurate measurements.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As well as I understand, it is hardly =
possible to feed 1GHz clock frequency into FPGA.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">My questions are:</FONT>
<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">Has anybody used some =
kind of frequency prescaler in connection with FPGA?</FONT></LI>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What prescalers are suitable for such =
purpose? Does anybody know VHF counters with internal stages accessible =
(which is necessary to obtain lowest bits of the counter)?</FONT></P>
</UL><LI><FONT SIZE=3D2 FACE=3D"Arial">Is it possible for XILINX Virtex =
to generate 1 GHz internally, through it's on-chip PLL? </FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Is Altera's on-chip PLL capable of =
such frequencies?</FONT></LI>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> Alex Sherstuk</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> </FONT> <A =
HREF=3D"mailto:Sherstuk@amsd.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">sherstuk@amsd.com</FONT></U></A>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> AMSD =
Company</FONT>
</P>
<BR>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01BE4542.1F6D51EE--
Article: 14238> C to Netlist Compiler (nlc): > Given a program written in a ``small subset of C++ with a few extensions,'' > nlc compiles the program into an FPGA configuration. ftp://lslsun5.epfl.ch/pub/ nlc, the work of Christian Iseli, is located at ftp://lslsun.epfl.ch/pub/ E. -- Emeka MOSANYA Ecole Polytechnique Fédérale de Lausanne Laboratoire de Systèmes Logiques Email: Emeka.Mosanya@epfl.ch ------------------------------------- "Au premier jour, l'homme créa Dieu"Article: 14239
I have an apology to Synplify users. I have found out why PAR was taking 5x as long. Even though I thought that there were no timing constraints in fact the PAR run from Synplicity was using constrains. This relates to a Xilinx MAP problem. In both cases the tools produced this situation: A clock buffer: CLK ---> <BUFG> ---> CLK_int Related timespec: NET "CLK " PERIOD = 1000 nS HIGH 50%; The problem is that without doing something the MAP program won't propagate this timespec through the clock buffer. You need to put either a TNM_NET spec on CLK or do what synplicity does and add the constraint NET CLK_int TNM CLK i.e. give the internal net a timegroup name the same as the pin name. In the XNF file this comes out as SIG,CLK_int,TNM=CLK. Spectrum does neither of these things. The result is that the pcf file induced by Spectrum has no BEL list for the timespec but that from Synpliciity does! The question arises as to why putting 1 MHz timespec puts the P&R time up by a factor of 5! I would have thought that in this case a purely random placement would almost certainly meet the spec. Looking at the results of PAR I get something like 50 MHz. I susspect I'll need to play with some PAR options to stop it working itself to death unnecessarily.Article: 14240
have a look at: http://devil.ece.utexas.edu/ Erik Widding wrote: > > Peter wrote: > > > > The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977! > > Mine is actually early 90's. This series, i.e. "Op-Amp Cookbook", etc., > is right up there with the bible, "Art of Electronics". > > > There is also an algorithm called Cordic. I have no info but a post in > > comp.arch.fpga should elicit a response from one of the very helpful > > contributors there. > > I did a quick net search, and turned up a few papers by Ray Andraka, > that give a very good introduction. As such, I would like a few of the > CORDIC experts out there to recommend a good reference text on CORDIC > specifically, and distributed math, or atleast a hardware oriented > algorithm book more generally. > > I have some great texts in my library that are "software oriented". > Seems the computer science world likes to assume that a register > oriented or traditional DSP architecture, with a multiplier, is being > used. Xilinx apnotes, and other papers have always been where I have > needed this sort of information, but a good general text on the matter > would be nice. > > Any suggestions? > > Regards, > Erik Widding > Birger Engineering, Inc. > > > > > >Peter wrote: > > >> There is a way to get > > >> digital-precision sinewaves from a feedback shift register arrangement > > >> - email me if you need more info; I have a book. Get the whole thing > > >> into a small FPGA. > > > > > >What is the name of the book? > > > > -- > > Peter. Opinions expressed herein are my own and may not represent those of my employer.Article: 14241
Unfortunately, I have also found very little in the way of texts that emphasize hardware algorithms rather than software ones. One text I have found useful, is EE Swartzlander's computer arithmetic. It can be difficult to obtain, as it is out of print. That text can also be a little hard to read as it is a collection of key papers on algorithms such as Volder's original CORDIC paper, Walther's CORDIC extensions etc. As far as CORDIC goes, I've seen mention of the CORDIC algorithm in one or two texts, but that is usually only a page or two, and in at least one case the information was not entirely accurate. The lack of tutorial information on the CORDIC algorithm was one of the motivators for writing the CORDIC paper (which can be obtained from my website). So far, I have not seen anything that even comes close for explaining the CORDIC algorithm. There is an on-line bibliography at utexas which lists over 200 CORDIC papers. I have a link to that bibliography on the CORDIC page on my website (I'm too lazy to go look up the url, and besides that will get you to my website). While the page is accessible, I don't think it is being maintained anymore, as I have recieved no replies to suggestions for additional papers or updates to urls from Shaoyun in the past two years. If I could get permission (Shaoyun are you out there?) I'd be happy to transfer the bibliography to my site and maintain it. Now for the Don Lancaster books... I can't speak for the Op-Amp Cookbook, but I did have copies of the TTL and CMOS cookbooks back in the mid 70's. As I became more experienced, I found that many of the design tips he espoused in his books are actually pretty poor design practice. The books are fine for the hobbyist, but should not be relied on as a 'bible' for stuff that is going into production. If nothing else, his books did prompt me to understand the internals of chips to a degree that I might not have otherwise. For example, it is simply amazing what you can do with a 555 timer aside from the obvious timing applications. Erik Widding wrote: > Peter wrote: > > > > The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977! > > Mine is actually early 90's. This series, i.e. "Op-Amp Cookbook", etc., > is right up there with the bible, "Art of Electronics". > > > There is also an algorithm called Cordic. I have no info but a post in > > comp.arch.fpga should elicit a response from one of the very helpful > > contributors there. > > I did a quick net search, and turned up a few papers by Ray Andraka, > that give a very good introduction. As such, I would like a few of the > CORDIC experts out there to recommend a good reference text on CORDIC > specifically, and distributed math, or atleast a hardware oriented > algorithm book more generally. > > I have some great texts in my library that are "software oriented". > Seems the computer science world likes to assume that a register > oriented or traditional DSP architecture, with a multiplier, is being > used. Xilinx apnotes, and other papers have always been where I have > needed this sort of information, but a good general text on the matter > would be nice. > > Any suggestions? > > Regards, > Erik Widding > Birger Engineering, Inc. > > > > > >Peter wrote: > > >> There is a way to get > > >> digital-precision sinewaves from a feedback shift register arrangement > > >> - email me if you need more info; I have a book. Get the whole thing > > >> into a small FPGA. > > > > > >What is the name of the book? > > > > -- > > Peter. -- -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: 14242
This is a multi-part message in MIME format. --------------F22A00F97E223914A03120CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If anyone knows something about power consumption in FPGAs or if you want to discuss about it, please, send me an e-mail. Thank you. --------------F22A00F97E223914A03120CE Content-Type: text/x-vcard; charset=us-ascii; name="garcia.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Andres Garcia Content-Disposition: attachment; filename="garcia.vcf" begin:vcard n:Andres David;GARCIA GARCIA tel;pager:http://www-elec.enst.fr/~garcia/index.html tel;fax:(33-1)45-80-40-36 tel;home:(33-1)40-78-68-32 tel;work:(33-1)45-81-78-03 x-mozilla-html:FALSE org:E.N.S.T.;Communications and Electronics Department version:2.1 email;internet:garcia@elec.enst.fr title:PhD Student adr;quoted-printable:;;46, Rue Barrault=0D=0A75634, Paris 13 Cedex.=0D=0AFrance.;;;; fn:Garcia G. Andres D. end:vcard --------------F22A00F97E223914A03120CE--Article: 14243
Erik Widding <widding@ieee.org> wrote in article <36A72744.79B17423@ieee.org>... > I did a quick net search, and turned up a few papers by Ray Andraka, > that give a very good introduction. As such, I would like a few of the > CORDIC experts out there to recommend a good reference text on CORDIC > specifically, and distributed math, or atleast a hardware oriented > algorithm book more generally. Kai Hwang's book on Computer Arithmetic, published in late 70's has a reasonable exposition, and references to the original publications - CORDIC was invented in the 50's. For more references, look any recent Proceedings of the IEEE Int. Conf. on Computer Aritmetic - there are always articles on CORDIC which will help you trace more recent publications. Euthymios KapposArticle: 14244
Hamish Moffatt wrote:<...snip...> > So is there ANY way to do free FPGA work yet? Like little projects for home? > <...snip...> > So what other options are there? I want to be able to enter a design, > either in an HDL or schematics (preferably the former), simulate it, > and route it for a device I can get reasonably easily. (Xilinx is the easiest > to get in Melbourne in my experience.) > > <...snip...> > Hamish > -- > Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au > > Rising Software Australia Pty. Ltd. > Developers of music education software including Auralia & Musition. > 31 Elmhurst Road, Blackburn, Victoria Australia, 3130 > Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA Toll Free: 1-888-667-7839 > Internet: http://www.rising.com.au/ Get the Xilinx Student Edition Tools. They are about $75 (US). About as close to free as they come. You will get support for CPLD's and small FPGA's -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14245
Shaoyun is still there, and continues to maintain the site. I heard from him today. Ray Andraka wrote: > I have a link to > that bibliography on the CORDIC page on my website (I'm too lazy to go look up > the url, and besides that will get you to my website). While the page is > accessible, I don't think it is being maintained anymore, as I have recieved no > replies to suggestions for additional papers or updates to urls from Shaoyun in > the past two years. If I could get permission (Shaoyun are you out there?) I'd > be happy to transfer the bibliography to my site and maintain it. -- -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: 14246
If you haven't already considered using ECL, here are some components that should do the job: SY89424 - 60MHz to 1 GHz frequency synthesiser for your reference clock SY100E137 - 8 bit 1.8 Ghz (min) ripple counter for time interval count from the Synergy Semiconductor online databook at http://www.synergysemi.com/databook/ (under ClockWorks and ECLinPS) Also Motorola is good for ECL parts, data and app notes, but the data is a bit less easy to browse: http://www.mot-sps.com/logic You will also need PECL/TTL translators, if, as is likely, you want to run the ECL from +5 and Ground. The Motorola ECL databooks and app. notes will be very helpful if ECL is new to you. I doubt that you will find a GHz PLL/VCO on an FPGA anytime soon, though this could have some interesting applications. Maybe as an embedded block in an FPGA destined for RF comm? regards, Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 14247
Rickman wrote in message <36A6BF07.BCAE24B0@yahoo.com>... >Synopsys, are you listening??? > >VHDL-93 NOW! Aww, Rick, they're not listening. Bastids. -- a ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.edu "In the beginning, there was darkness. And it was without form, and void. And there was also me!" -- Bomb #20, John Carpenter's "Dark Star"Article: 14248
Khaled benkrid wrote in message <36A8CAB1.8011E8FD@qub.ac.uk>... >Hi All! > >I am using FPGA express 1.2 (comes with Foundation 1.3 Student edition). > >I have the following warning when optimizing my designs: >" Port XX has no net attached to it-no pad cell inserted in this port >FE-PADMAP-2". These ports are inputs in my design, so it is a problem >for me. I want to know how to work around this. Assuming schematic entry. Make sure the wire's actually attached to the port. (Trust me. Been there, done that.) Make sure you've put an IBUF on the schematic after the port. -- a ------------------------------------------ Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters@noao.edu "In the beginning, there was darkness. And it was without form, and void. And there was also me!" -- Bomb #20, John Carpenter's "Dark Star"Article: 14249
OF course, schematics are of no use at all in the design of complex state machines. And, I'd hate to have to draw schematics to determine whether to use 1-hot or binary coded for size and/or speed in a particular application. It is extremely easy to whip out implementation experiments with an HDL. My rule of thumb is that any design above about 5K gates will get to market faster with an hdl (assuming a working design flow than you understand). And, what about multiple designers working together on 1 design. Schematics can get real messy (just getting the interface names correct is a pain). Also, Schematics are much more difficult to modify and maintain as the project moves forward and inevitably changes. The art of drawing a good schematic is *much* more time consuming than cranking out well commented hdl. But, my favorite aspect of hdl's is the "print on error only" test bench. bruce Ray Andraka wrote in message <36A6BD35.52386799@ids.net>... >John, welcome to comp.dsp! > >Well, you already know that I am a strong proponent for schematic based design >for FPGAs, so you might be a little surprised by the following response. > >The way I see it, HDLs do have real advantages, however there are some serious >disadvantages when applied to high performance FPGA designs. As I see it, the >two real advantages that HDLs have over schematics for FPGA design are: > >a) Access to archived designs. A schematic design requires a compatible >viewer or hardcopy to read an archived design. As schematic entry tools >evolve, some of the older formats get dropped, so some legacy designs may no >longer be readable, and all designs are inaccessible to someone without the >correct reader. On the other hand a text based design can be read by any text >editor capable of accessing a file the size of the design file (notepad will >probably not cut it for more complicated designs). > >b) Significantly enhanced simulation capabilities. VHDL brings with it the >ability to simulate using behavioral models in place of a detailed circuit >simulation using the same toolset as used with the detail design simulation. >This provides the ability to simulate a design or design fragment before the >detail design is done (helps to avoid getting to far down the wrong path). >Verified portions of the design can also be aliased to behavioral models to >cut down on the computational power required to do the simulation. > >There are several other "benefits" bandied about by the marketing types, >which, depending on the context have some degree of truth: > >a) Design readability. A well done hierarchical schematic is generally more >readable than HDL code...its the picture is worth a thousand words thing. >However, in my experience, the average engineer does not do a very good >schematic. The number one crime is the lack of or improper use of a >hierarchy. Schematic based design does not naturally impose hierarchy, so the >temptation is to create a flat schematic. Sixty plus pages of flat schematic >are next to impossible to read. Almost as bad are the hierarchical designs >that have not been logically partitioned. To keep schematics readable, the >schematic at each hierarchical level should be limited to one page, the page >should be fairly sparse (probably no more than 10 symbols) and the hierachical >blocks should be logically partitioned so that each is a complete function to >itself. All this takes some time to do, but there are rewards for following a >strict discipline. It can be difficult to resist the urge to squeeze one more >thing (many times over) onto a page. HDLs on the other hand, naturally >encourage hierarchy in the design which leads to legibility. Also, certain >circuit elements lend themselves to a textual description; examples are state >machines and combinatorial decoders. We've all seen examples of both that >wind up being a jumbled mess of AND and OR gates wired in some >incomprehensible manner. <I do use a schematic methodology for one-hot state >machines that makes the schematic look like a flow chart to make schematic >statemachines easy to construct and understand> > >b) Design reuse. This is more of an issue of properly using hierarchy. A >design that is hierarchically broken down into successivly smaller complete >functional units lends itself to reuse regardless of the capture methodology. >The fact that HDLs encourage good hierarchical breakdown makes HDL design >fragments natural for reuse. In schematics, you need to work at it. > >c) Design portability. This again is partly a hierarchy issue. If the design >is properly broken into a hierarchy, it can be retargeted at a different >technology by simply changing the library for the lowest levels of the >hierarchy. This requires libraries for the different technologies to have the >same interfaces to the upper levels: for schematics it means the same symbol >names, shapes, sizes, pin locations etc. For HDLs it means pretty much the >same thing. Where the different vendors have really not standardized in this >area, the user needs to create a translation library to smoothly transition >from one technology to another. Developing unified library elements is a >sizable task, and one I don't think the one FPGA design a year crowd wants to >embark upon. Now the translation is a little easier in HDLs, because the >graphic elements (pin locations and symbol size) are no longer in the >equation. This is a small consolation. Where HDLs have the big advantage is >when synthesis is used to infer the low level structure of the design. If >that is the case, there is little the user needs to do to port the >design...assuming he did not go to low level construction. The problem with >synthesizing from a higher level description is that you give up the control >of the design implementation and placement. The cell granualarity in most >FPGAs is not handled well with current synthesis, although significant >improvements have been made mostly with libraries of primitive functions >targeted at specific devices. In high performance/density designs you usually >lose to much when you relinquish control of the implementation to the >synthesizer. > >d) Ease of entry. Proponents of VHDL often state that a design can be entered >faster in textual form. IMHO, it really depends on the design and your design >objectives. State machines, for example can be easily entered and later >grokked in a textual format. The state machine implementation can be >controlled do some degree with the coding style and with synthesis option >switches. On the other-hand dataflow and memory intensive designs tend to be >easier to do with a schematic. A true advantage textual descriptions have >over schematics is the ability to easily accommodate parameterized elements >(for instance data path elements whose implemented bit width is dependent on >context), something that is quite difficult to do with schematics. Generally >for schematics, some macro generator is used to produce a symbol and an >optimized implementation. > >For schematic entry, there is usually no synthesis (Altera MaxPlus II is an >exception), so the implementation is explicit. The place and route tools will >do some boolean minimization and such to improve the design. In schematics, >this is easily overridden if there is a reason for a particular implementation >using mapping constructs and placement attributes. These are applied directly >to the affected schematic symbol. Applying similar implementation and design >constraints in VHDL is tedious (akin to writing a textual netlist of the >circuit). Applying placement constraints is inconsistent from tool to tool, >and those constraints in some cases are not hierarchical. For low level >design control, the schematic entry method is considerably easier to do. > >So the bottom line is HDLs do give significant advantages for simulation and >archiving, and depending on the project, may also provide advantages by >synthesizing the design details. For FPGA designs other than low performance >ones, the cost of synthesis is currently too high in terms of lost performance >and density to achieve the advantages from high level (RTL) synthesis. That >cost can be circumvented by low level instantiation, but it is currently more >painful than doing the same low level designs in schematic form. Keep in >mind, that the designs I do are typically DSP data path designs with sample >rates between 40 and 100 MHz, and often in slower speed grade devices. >-- >-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/~randraka > >
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