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
Hi Volker. If the 10K10 is like the 6016 I used once, you need to pull down the nCONFIG line (I think) the first time you program (and if you ever corrupt the EPC2) otherwise it tristates the JTAG I/Os until its knows what they are configured as! I put a jumper on my board for this purpose, there may be one on your EV board. Altera have an App note on this somewhere, try a search on their website (http://www.altera.com surprise surprise :). If you can't find it, let me know and when I get into work I'll check what I did last time. Cheers, Martin On Wed, 24 Nov 1999 20:52:43 -0800, Volker Kalms <ea0038@uni-wuppertal.de> wrote: >Hi all, > >Since a quarter of a year I discover the beatiful world of >AHDL and VHDL. Until now everithing worked fine. But now I would >be very grateful for a little help. > >Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured >by Ing. Buero Lindmeier) in my hands. This evaluation board contains >an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the >ALTERA MAX+plusII (v 9.1) software......no problem to this point. > >Two weeks ago I purchased an configuration EPROM (EPC2LC20), which >could optional plugged into my evaluation board.I set up the MAX plus >JTAG chain due to the requirements (as far as I would say), performed >an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus >detected the additional device in the JTAG Chain. >But when I try to Program the .pof file to the EPROM I get the message: >Unrecognized device or socked empty. > > >What am I doing wrong????? From my point of view I changed nearly every >parameter in the MAX plus setup. > >I hope there is somebody out there, who could give me a hint how to get >this EPROM configured. > > >MANY THANKS IN ADVANCE!!! > >Best regards, > >Volker Martin Thompson martin@the-thompsons.freeserve.co.uk http://www.the-thompsons.freeserve.co.uk/Article: 19076
--------------DE4E380CE448689455AEF959 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all The following site is a great place to get a new hardware free. The catch is that you will have to earn points by referring your friend to sign up and using these points to bid for cool hardware e.g sega dreamcast, hifi, plam V. Visit the site below to sign up and also tosee what they are offering now. www.rocket8.com Have Fun and start bidding --------------DE4E380CE448689455AEF959 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all <p>The following site is a great place to get a new hardware free. The catch is that you will have to earn points by referring your friend to sign up and using these points to bid for cool hardware e.g sega dreamcast, hifi, plam V. Visit the site below to sign up and also tosee what they are offering now. <p> <a href="http://www.rocket8.com/teezer.asp?referredby=1830">www.rocket8.com</a> <p>Have Fun and start bidding <br> <br> <br> </html> --------------DE4E380CE448689455AEF959--Article: 19077
Many years ago I dismantled an IEEE488 to RS232 converter. It contained only a 27512 EPROM and a 22V10. (Plus of course a MAX232 and other irrelevant stuff like that.) There was no micro. I thought about this afterwards, and I could conclude only that this was some really ingenious design where the 27512 contained a complex state machine. I have seen a normal microprocessor implementation of a IEEE488-RS232 converter (IEEE488 being a listener only, not a controller) and it was a few k of 8051 code. So doing it in a state machine is not trivial task, but this shows there are some damn clever people around. >>Depends what you mean by 'hardware implementation'. Do you mean single chip >>micro using a gate array? State machine that is not quite single chip micro, >>or 'random logic' with TCP/IP hardwired - no microcode? > >Oh no, the microcode myth again. Is there something wrong with it if it >is microcoded? It is possible to build slow vertically microcoded >processors, but it is also possible to build fast horizontal microcoded >processors. Many processors could be build to run about as fast with >about the same amount of logic microcoded or hardwired. > >However, for TCP/IP I would suggest a simple vertical (small instruction >word) processor, almost a simple FSM (state machine) implementation. >In FPGA with an external ROM it might not be bad. You could even write >a C compiler for it! Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 19078
Austin Franklin wrote: > > Rickman <spamgoeshere4@yahoo.com> wrote in article > > Is there a reason that you didn't call Xilinx support on this issue? I > > don't always find them helpful on subtle or complex issues, but they are > > usually pretty good on a basic question like this. I expect you would > > have had an answer in a day or less. > > I did call/email Xilinx support on this issue. What they said was 'it > works for me'. > > I don't just sit around for days trying to figure things out because I have > nothing better to do, when a simple phone call/email would suffice. I even > called another Xilinx 'expert', who is prolific in this group, and all FPGA > Editor did for him was crash...so, he was no help. > > I was hoping someone here had actually USED the tool, encountered the same > problem, and already figured out a solution to the problem. I also post my > findings in hope that someone, who does a DejaNews search, and is looking > to solve the same problem, finds the post. If people post questions here, > and the solutions, they are available 24 hours a day...and with no wait. > > I also email support@xilinx.com with the problem/solution in hopes that > they 1) fix the 'problem' in a future release and 2) put the 'solution' in > their 'answer base'. I would guess by the tone of your message that you are pretty frustrated over this. I definitely feel your pain. I have also gotten the "it works for me" answer to problems. More often I can't even get the first line of defence at Xilinx to understand the question. So even if they take me seriously and go to the next level to get an answer to the question, the answer is usually to the wrong question. I understand why this happens so much. It is a matter of limited knowledge resources and economics. If you spend a lot of money teaching people how your parts and software operate, you don't want to waste their talents by having them answer the phones. But the current system really doesn't work very well for the customer. I know that there are many different forms of support too. But I have found that about half of the time if I look in the online documentation and the web databases, I can't find what I want unless I know where to look. When I call the hotline, they seem to have a much better grasp on how to find the solution since they are very familiar with the answer tools. But this just continues the problem of a steep learning curve from the development tools to the documentation tools!!! So I have been down that same road as you and have hit most of the potholes you have. I got off the bus before I started working with the Virtex parts. I am now working with the Lucent Orca parts and feeling the same pain in a different way. The tools are the Viewlogic tools and so far things are working ok. But the few times I have called Lucent support, I have not seen much of a difference from Xilinx. From what I have read in this newsgroup, I can expect the support to get very thin if I try using any of the advanced features. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 19079
malino@primenet.com wrote: > > Things change so do the way we design, either keep up with the industry or > become obsolite. I have been doing digital designs for 30 years and find > that I must keep up with current design techniques of become unemployed. > > Walt I guess this is the ultimate yawn in a newsgroup. The original topic of discussion is so uninteresting that the topic changes and the thread continues on without anyone even acknowledging the fact. I guess that is the answer to my question. Few engineers are even interested enough in the Lucent Orca parts to even discuss why they don't use them??!! -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 19080
I guess you should try WITH Xilinx implementation tool (Alliance or Foundation) In the design manager tool of Alliance before you start implementing FPGA go into the implementation options and click the line called" Pack registers into IOBs for" : you get a, b,c, d options select the one you want . Hope these helps. Abdul Rafeeq. In article <lt903q9pnj.fsf@mis.dtek.chalmers.se>, Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: > "Jamie Sanderson" <jamie@nortelnetworks.com> writes: > [...] > > I would much rather the synthesis tool be > > responsible for the placement of the flip-flops, rather than Xilinx's > > mapper. > > Watch out what you wish for! With the new Altera Apex family and their > P&R tool Quartus, that's exactly what you got. Now the problem is > reversed: How to get Synplify to put the FFs in the I/O pads! In my > case, I wanted a registered output enable. That register is available > in the I/O pad of Altera. However, Synplify still wants to use a > regular FF instead. The high fan-out and the long distance to the I/O > pads makes the timing too slow. > > Oh well... > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19081
Eugene B. Hogenauer's paper, 'An Economical Class of Digital Filters for Decimation and Interpolation' was published in: IEEE Transactions on Acoustics, Speech, and Signal Processing, Vol. ASSP-29, NO. 2, April 1981. The Cascaded Integrator-Comb (CIC) filters work well in FPGAs whenever you have to interpolate or decimate 2's compliment signals while lowpass filtering them at the same time. The filters give the response of FIR filters with all the coefficients set to 1. These are also called 'box car' filters because their impulse response looks like a rectangular box car. This type of filter requires no real multiplication, which makes them relatively small and well suited for FPGAs. The CIC implementation avoids the use of long shift register delay lines you might think would be necessary for such a filter. This efficiency is compounded because of the decimation/interpolation especially when the CIC stages are cascaded. The architecture consists of accumulators, subtractors, and a small number of pipeline delays. A 'must have' addition to your DSP bag of tricks. Dave Decker Diablo Research Co. LLC On Thu, 25 Nov 1999 10:57:12 GMT, "Mariotto" <mariotto@libero.it> wrote: >Where I could find information on realizations of CIC filters supposed from >E.B. Hogenauer in FPGA? >Thank you. > >Claudio Casagrande > >e-mail:mariotto@libero.it > >Article: 19082
> I would guess by the tone of your message that you are pretty frustrated > over this. Frustrated? HA! That's an understatement! And they ask me the most STUPID question they can possibly every ask "Why do you want to use that tool anyway?...NO ONE uses it". DAMN does that piss me off. I need to use THAT tool because with it, I can fill in the blanks that THEIR documentation leaves out...like what is the best IOB to use for the RESET input, where the hell IS the upper right and left corner of the die, with relation to the package...and just WHAT did the tools do to my logic? These, and many other questions can be answered with this tool...but their attitude is, "hey, the OTHER tools work just fine, so you don't really need that tool, Oh, and by the way, NO ONE uses it anyway"...GRRRRRRRR.Article: 19083
Do you keep up to date with the errata from Lucent ? There were some rather nasty bugs in the silicon that they found too late, and many of them fall in the "likely to be encountered with practically any design" category. Your lost reads/writes sounds like one of the bugs with the FIFO logic. Don't have it in front of me to cite. If you haven't read it, be sure to do so. DO NOT TRUST THE DATASHEET! note-- The September 99 release of the datasheet FAILED to correct the erroneous tables noted in the March 99 release of the datasheet. Don't know where the errata went, but there were some crucial FIFO tangle-ups that need to be worked around. And as an aside, to all you chip vendors out there, when you change a datasheet, please NOTE THE CHANGES. On a rather large datasheet it is rather hard to hunt for the changes. Edward Wallington wrote in message ... >Our system basically works, but we get stability problems in some PC's >(my guess >is that it is chipset dependent, but there could be other factors at >play). This can >appear as lost / corrupted reads or writes. > >The workarounds we have found are: >Fclk: (fifo clocks) we suspect there is a problem if the fifos are >clocked with a signal that is slow (10MHz) w.r.t. the pci bus. >The core seems to get tangled up with a subsequent transaction. You get >target ready keep going low. Answer: >clock it quicker! > >There also appears to be issues if you leave a dead clock cycle between >requesting the address and requesting the data, >(we have a pipeline stage), you end up with a short data phase. This may >be a timing problem on our part, but has anyone >else found anything similar? One thing lucent don't spell out is that >the signals from the core appear / disappear on FALLING >edges of the fifo clocks (look carefully at the timing diagrams). Our >data was disappearing half a clock before we were registering it! >Article: 19084
rafeeqs@excite.com writes: > I guess you should try WITH Xilinx implementation tool (Alliance or > Foundation) In the design manager tool of Alliance before you start > implementing FPGA go into the implementation options and click the line > called" Pack registers into IOBs for" : you get a, b,c, d options select > the one you want . > Hope these helps. I didn't know that Xilinx tools could handle Altera devices... I'm just saying that giving more power to the synthesis tool, might not always be a good idea, if you remove some possibilities of the P&R to override the placement from the synthesis tool. Homann > Abdul Rafeeq. > > In article <lt903q9pnj.fsf@mis.dtek.chalmers.se>, > Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: > > "Jamie Sanderson" <jamie@nortelnetworks.com> writes: > > [...] > > > I would much rather the synthesis tool be > > > responsible for the placement of the flip-flops, rather than > Xilinx's > > > mapper. > > > > Watch out what you wish for! With the new Altera Apex family and their > > P&R tool Quartus, that's exactly what you got. Now the problem is > > reversed: How to get Synplify to put the FFs in the I/O pads! In my > > case, I wanted a registered output enable. That register is available > > in the I/O pad of Altera. However, Synplify still wants to use a > > regular FF instead. The high fan-out and the long distance to the I/O > > pads makes the timing too slow. > > > > Oh well... > > > > Homann > > -- > > Magnus Homann, M.Sc. CS & E > > d0asta@dtek.chalmers.se > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 19085
> Where I could find information on realizations of CIC filters supposed from > E.B. Hogenauer in FPGA? > Thank you. You may have a look at this paper (you can download it at http://ditec.ugr.es/~agarcia/bin/cicrns.ps.gz): A. García, U. Meyer-Bäse and F. J. Taylor, "Pipelined Hogenauer CIC Filters Using Field-Programmable Logic and Residue Number System," Proc. of 1998 IEEE International Conference on Acoustics, Speech and Signal Processing ICASSP'98 (Seattle WA, May 11-15), vol. 5, pp. 3085-3088. CIC filters are very suitable option for FPGA implementation, since they provide multiplication free FIR structures. Even more, precision may be adapted in every stage without harming the final response of the system. The original paper from Hogenauer contains all the mathematical support for these structures. Hope it helps. -- _______________________________________________________ Antonio Garcia Dpto. de Electronica y Tecnologia de Computadores Universidad de Granada Campus Universitario Fuentenueva E-18071 GRANADA (Spain) Voice: +34-958248996 Fax: +34-958243230 e-mail: agarcia@ditec.ugr.es WWW: http://ditec.ugr.es/~agarcia/ _______________________________________________________Article: 19086
On Fri, 26 Nov 1999 10:30:11 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Michael Schmid wrote: > >> >> Hi Bill, >> >> I think the same way like you with the >> configuration pins (and also the Xilinx >> Datasheet). JTAG works in every >> configuration mode. The init pin must be >> high (Tom has this and we too). For JTAG >> configuration toggling of the program >> signal shouldn't be necessary, you're >> right. But do you know what happens if >> Tom has the program pin low or floating? >> This could explain why I can program my >> virtex via JTAG (program is stable high >> after several time) and Tom isn't able >> to (maybe pulldown on program). What do >> you think? >> >> Bye, >> >> Michael >> >> mlschmid@iis.fhg.de > >If JTAG works in all modes then any idea why there are special mode pin >settings for JTAG ? > >rick@algor.co.uk If the device has already been configured, by any mechanism, then you can reconfigure it over the JTAG interface. It doesn't matter what the mode pins are. However, if you want to configure an unconfigured device via JTAG, then you should set the mode pins to select JTAG configuration. I'm pretty sure that this is covered in the docs somewhere. A colleague of mine did an XCV300 board about 9 months ago, and we had a discussion at the time about whether to pull down or pull up INIT. It wasn't clear, and he decided to pull it down, using a JTAG mode. The JTAG loading was always flakey, and I started poking around when I got particularly annoyed once. I swapped the pulldown for a pullup, and I managed to convince myself that it worked better, but it still wasn't reliable. It's reliable now, but we had several other problems. We had a real problem getting Compaq portables to download, for example. The worst problem was simply software patches - early M1.5's were unusable, and you really need to be on M2.1. There's also a new requirement to go through a startup/shutdown sequence, which I've lost track of - I can't remember if 2.1 does this, or if it's coming in the next release... ? EvanArticle: 19087
On Mon, 22 Nov 1999 06:07:05 +0200, "Anthony Ellis - LogicWorks" <a.ellis@logicworks.co.za> wrote: >Sorry. Thids is not an FPGA question but I am sure you all use similar >tools. > >Has anyone any comment on the PADS schematic capture tool as compared to say >Orcad or Protel. >I am looking for a good, reasonable cost, front end for PCB designs - >Win85/98 based. >Someting with good hierarchy support rather than "dumb" busses and blocks. > > >Anthony >-- >LogicWorks - Electronic Development Services > Anthony Ellis > Cell: 082 4453285 > Phone 27-(0)12 9988062 > > I'll just repeat what Tom said, with somewhat more emphasis - PADs schematic capture is completely, totally, utterly *useless*. It would be a complete waste of time and money if it was free, and it costs 800 UKP here. If you want hierarchy, as you say, then steer well clear of it (can you believe that a "hierarchical" tool actually joins together nets in separate lower-level blocks?). Its only possible selling point is that your layout engineer, if he's also using PADs, can back-annotate easily. But, having said that, I've spent years doing schematics with Orcad and Futurenet, with PADs layout, and this wasn't a problem. The old DOS Orcad was infinitely better, and even Windoze Orcad is much better. Haven't tried Protel, but I've heard that it's pretty good, and it has a fairly cheap signal integrity add-on. EvanArticle: 19088
On Tue, 23 Nov 1999 17:20:06 GMT, Robert Sefton <rsefton@home.com> wrote: >> Is design maintenance easier? > >One major advantage of schematics over VHDL for FPGAs that I >haven't seen mentioned is guided routes. I remember re-spinning >designs through the old XACT tools (ppr) using the guided route >option in a couple of minutes (vs. 2-3 hrs for a complete >re-route) after a minor change. With the VHDL/synthesis path >guided route is not an option. The only way to significantly >reduce place and route times is to lock everything down, which is >a pain in VHDL. Stuart Clubb, of Saros Technology, has written a useful app note on incremental synthesis and guided P&R for HDLs. The answer is simply that - synthesise hierarchically, and incrementally for mods, and you can still do guided P&R. This means that you can modify down to the entity/architecture level. I don't think this app note has got as far as Xilinx or Exemplar yet. I've copied this to Stuart and hopefully he can provide details on where to get it from. EvanArticle: 19089
On Mon, 22 Nov 1999 19:52:22 -0800, "John Doe" <h2p@hotmail.com> wrote: >Leonardo Spectrum is a pretty good synthesis tool except for "1" thing.... >printing your schematics. > >I have asked their support team time and time again to fix the built in >schematic viewer and for 20k+ a seat you think they would do that right??? >NO. Instead the only reply that I got was I can either use the old >schematic viewer that will not show higher levels of your design (i.e. you >get 300 plus pages to print out) or use the new schematic tool and use cut >and paste. CUT AND PASTE!!! Has anyone seen the quality of the schematic in >the first place. If you were to print that out in say Word you would get 1 >big black drawing. > >This is just a gripe. I am disapointed that Exemplar and other companies >cant seem to get their shit together and make some quality software (not >just the engine but the user interface!!!). I also got the 'netscope' answer for a similar question a few months ago, but the disti did also say that there was a 'very much better' schematic viewer on the way... soon? EvanArticle: 19090
On Thu, 25 Nov 1999 07:46:30 -0800, Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid> wrote: >Sorry for smal typing error in programm, >it must be so: > library ieee; use ieee.std_logic_1164.all; > entity LT is > port (o : out std_logic ; > r : in std_logic ; > s : in std_logic ); > end; > architecture LT of LT is > begin > process (R,S) > begin > if R='0' then o <='0'; > else if S='0' then o <='1'; > end if; > end if; > end process; > end; If I've understood you correctly (and I'm not sure that I have), then the flop you describe doesn't give the correct behaviour - the problem is when both S and R are asserted (low), and R rises. In this case the (corrected as necessary) VHDL should produce a '1' output, but the flop will still give a '0' output. I'm not convinced, though - I'd rather see a known working piece of VHDL and a diagram of the resulting gates. But, in general: 1) if your technology library doesn't have an SR element, dont attempt to code one. I would have been *really* surprised if your synth had created an async feedback circuit for you. 2) If you actually code a transparent latch, then Spectrum will create a latch if your technology library supports one - I've done this with Virtex, which does have latches. > 2. Does it in principaly normal design praxis to use level sensitive > latches? Depends. This used to be common in, for example, micros with 2-phase clocking. The justification was (a) that the latch was smaller and faster than an equivalent flop, and (b) designers could use 'time borrowing' to increase system performance. This could lead to significant performance improvements. However, times have changed. Timing analysis tools can't cope with time borrowing, and deep-submicron ASIC design means that latches have little advantage anyway, since routing delays now predominate. They also increase power consumption. So, if you want a rule, and you're interested in reuse, don't use latches. But, like all rules, break it if you understand it. EvanArticle: 19091
Please feel free to circulate the following position announcements: Position: President Location: San Francisco Bay Area Get in on the ground level: start-up in the area of intellectual property reuse (design reuse) for system-on-a-chip. The system-on-a- chip marketplace is expected to grow from $5.9 billion in 1999 to $15.7 billion in 2003. Seeking President to work with CEO. Responsibilities: - Drive/implement business strategy - Help raise initial and subsequent venture capital rounds - Identify and create industry alliances/partnerships - Help assemble core team Requirements: - Background in semiconductor industry; understanding of intellectual property reuse desired. - Ability to work with business and technical personnel Please email your resume to ipreuse@my-deja.com Position: Chief Operating Officer Location: San Francisco Bay Area Get in on the ground level: Ground level start-up in the area of intellectual property reuse (design reuse) for system-on-a-chip. The system-on-a-chip marketplace is expected to grow from $5.9 billion in 1999 to $15.7 billion in 2003. Responsibilities: - Implement business strategy - Run day-to-day operations of start-up company - Identify and create industry alliances/partnerships Requirements: - Background in semiconductor industry; understanding of intellectual property reuse desired. - Ability to work with business and technical personnel Please email your resume to ipreuse@my-deja.com Position: Consulting Design Engineers Location: San Francisco Bay Area Get in on the ground level: Ground level start-up in the area of intellectual property reuse (design reuse) for system-on-a-chip. The system-on-a-chip marketplace is expected to grow from $5.9 billion in 1999 to $15.7 billion in 2003. Responsibilities: - Provide technical and process consulting in the area of design reuse Requirements: - EE degree; Background in semiconductor industry; technical understanding of intellectual property reuse. Please email your resume to ipreuse@my-deja.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19092
A long time ago, before the dark ages when people stopped thinking what their design is doing and allowing stuff like computers, vhdl, verilog and others to rule the world, there were a few widespread methods of implementing state machines using PROM's and shift regs or counters. Heck, people were designing those with just pencil and paper. Peter wrote in message ... > >Many years ago I dismantled an IEEE488 to RS232 converter. It >contained only a 27512 EPROM and a 22V10. (Plus of course a MAX232 and >other irrelevant stuff like that.) There was no micro. > >I thought about this afterwards, and I could conclude only that this >was some really ingenious design where the 27512 contained a complex >state machine. >Article: 19093
Hi, I'm selling a full Altera MAX+Plus II package, V9.01. It's new and still sealed (I never used it). This package is their "Magnum" product which supports full VHDL. Great for DSP design. Includes manual, CD-ROM and dongle. I can transfer registration to you upon purchase. Originally $7000, will sacrifice for $1000 including shipping. - Chris fidonews2@my-deja.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19094
Supposedly you can use RLOC=R0C0.F.S0. The tools accept it, but the mapper doesn't seem to recognize it. I've got Xilinx looking at a related problem right now for the placement of the flip-flops in a specific location within the slice (.FFX and .FFY). If anyone else has found a solution, I'd like to know about it too. Gordon Hollingworth wrote: > Can anybody tell me how it is possible to specify the F or G LUT for the > LUT4 symbol? Is there anyway of doing it in the Virtex device? -- -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: 19095
I agree with most of John Larkin's 22 Nov. 1999, comments. (Except that I do simulate what's fast and bench test what takes too long to simulate) I am so glad to hear schematic capture being so forcefully defended. I lament the slow downward spiral of toolmaker support for schematic capture. With an exhaustive library of floorplanned low-level parts, schematic capture can be fast, and efficient. Schematic capture supports hierarchical relative floorplaning for high speed, dense designs that place and rout in 1/10 the time of non placed designs. (I have recently asked both Exemplar and Synplicity for examples of code that show hierarchical nested RLOCs being used but without success.) For readers of this thread, trying to weigh the merits of HDLs vrs. schematic capture I suggest, that the schematic capture method be considered not on its own, but as augmented by an exhaustive source of low level counters, muxes, accumulators, etc. all optimally RLOCed. I submit that this combination is a powerful competitor to HDLs, especially for DSP designs. (The recent Xilinx Xcell article on the Fliptronics tools, highlights the library generator I find indispensable.) ( See: http://www.fliptronics.com) 1) A fair amount of the bandwidth of this newsgroup is used discussing how to trick various HDL synthesizers into inferring what you really want. Each time, I scratch my head and wonder why they don't just state what they want by drawing a schematic? 2) Why do HDL people generally use schematics to explain their designs to others? Because schematics are easier to understand? 3) Why do high level, graphical entry methods exist, that generate HDL as an output? So people who are mandated to use HDLs because of some constraint, can use schematics to capture their HDL? 4) It's likely that the time saved on the very first pass through Place and Rout, by adding floorplaning to an FPGA DSP design, is greater than the time it takes to add the floorplaning. The time saved by subsequent place and routs is gravy. 5) The above floorplaning also enables tighter packed, faster running, and more consistent designs. If you're on the schematic vrs. HDL fence, give a good library generator a chance. It will give your schematic capture tool new life and a lot more speed. Dave Decker there is only one 'h' in my real email adr.Article: 19096
Does anyone have any info' about the Clearlogic Vs. Altera
bust-up ? I was thinking of using ClearLogic because the cost saving is
quite dramatic but, if they're going to suddenly withdraw their service
'cos Altera have successfully sued them I'll be in deep Do-Do's.
Anyone know anything.
--
Pat
Article: 19097In article <383ec3a9.739463@nntp.best.com>, bob@nospam.thanks (Bob Perlman) wrote: > Hi - > > On Fri, 26 Nov 1999 13:12:49 +0100, "Ahmad A." > <aa939788@oak.cats.ohiou.edu> wrote: > > >Hi.. > >Can any one tell me where can I find Free, Student edition, or Shareware HDL > >editor? > > > >Thank you in advanced. > >Ahmad. > > > > One editor I've been very happy with is UltraEdit. It's easy to use, > loaded with features and, while not an HDL editor as such, has > configurable syntax coloring. There are syntax coloring files > available for Verilog, VHDL, and just about any other programming > language you can think of. And the price is right: use it free for a > month or so, then pay $30 if you like it. > Similar comments apply to TextPad http://www.textpad.com Similar price, evaluation, syntax colouring etc. Also handles big netlists (>8MB) very gracefully. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19098
I certainly find this to be true. It takes me several times longer to do a placed [RLOCs in the source] design in VHDL than it does in schematics. That's because in order to RLOC the HDL, you need to structurally instantiate the design all the way down to the primitive level, which is just a textual netlist of the design. The synthesis vendors could help greatly in this regard by adding an RLOC like attribute that could be placed on inferred components to allow inferred components to be relatively placed (this would be for arithmetic elements in particular). As I've stated before, to me, the advantages of HDL lie in the simulation and the ability to realize parameterized circuit generators. There are also a number of customers out there that have bought into the whole HDL thing foisted upon us by the EDA vendors who insist on a design being done in an HDL without regard to what is best for the application. Given a choice, I'd rather use the schematics if I have to do placement (it is also easier to see and fix long paths in the design). Unfortunately, the FPGA vendors have bought into the HDL thing lock, stock and barrel. I suspect a big part of that is their desire to portray the parts as simple to use. Admitting that doing placement by hand improves performance hurts the marketing. Xilinx is guilty of this for the Virtex in several respects. First, Virtex is not fully supported in the Xilinx schematic libraries (particularly for the virtex-unique primitives like the SRL16), and I'm beginning to doubt it ever will. The 2.1i mapper still doesn't seem to use precise placement constraints (in ohterwords you can't specify which half of the slice a primitive is to go in), but it isn't smart enough to consistently figure out where to place a primitive when it does matter. Dave Decker wrote: > I agree with most of John Larkin's 22 Nov. 1999, comments. (Except > that I do simulate what's fast and bench test what takes too long to > simulate) I am so glad to hear schematic capture being so forcefully > defended. > > I lament the slow downward spiral of toolmaker support for schematic > capture. With an exhaustive library of floorplanned low-level parts, > schematic capture can be fast, and efficient. Schematic capture > supports hierarchical relative floorplaning for high speed, dense > designs that place and rout in 1/10 the time of non placed designs. > (I have recently asked both Exemplar and Synplicity for examples of > code that show hierarchical nested RLOCs being used but without > success.) > > For readers of this thread, trying to weigh the merits of HDLs vrs. > schematic capture I suggest, that the schematic capture method be > considered not on its own, but as augmented by an exhaustive source of > low level counters, muxes, accumulators, etc. all optimally RLOCed. I > submit that this combination is a powerful competitor to HDLs, > especially for DSP designs. (The recent Xilinx Xcell article on the > Fliptronics tools, highlights the library generator I find > indispensable.) ( See: http://www.fliptronics.com) > > 1) A fair amount of the bandwidth of this newsgroup is used discussing > how to trick various HDL synthesizers into inferring what you really > want. > Each time, I scratch my head and wonder why they don't just state what > they want by drawing a schematic? > > 2) Why do HDL people generally use schematics to explain their designs > to others? > Because schematics are easier to understand? > > 3) Why do high level, graphical entry methods exist, that generate HDL > as an output? > So people who are mandated to use HDLs because of some constraint, can > use schematics to capture their HDL? > > 4) It's likely that the time saved on the very first pass through > Place and Rout, by adding floorplaning to an FPGA DSP design, is > greater than the time it takes to add the floorplaning. The time saved > by subsequent place and routs is gravy. > > 5) The above floorplaning also enables tighter packed, faster running, > and more consistent designs. > > If you're on the schematic vrs. HDL fence, give a good library > generator a chance. It will give your schematic capture tool new life > and a lot more speed. > > Dave Decker > there is only one 'h' in my real email adr. -- -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: 19099
Dear All, I am willing to do a performance analysis of FPGAs, DSPs and Pentium III MMX microprocessors for highly parallel DSP applications such us Image Processing. I am interested in particular in the use of MMX technology in PENTIUM III general purpose microprocessors. With clock frequencies reching 500 MHz, I may expect them to outperform both FPGAs and DSP in some applications (e.g. 2D convolution). Has anybody done a similar case study? Do you know any valuable references on this issue? Any comment will be highly appreciated. Thanks in advance. G.
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