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
Robert Sefton wrote: > Just a couple of points to add to the discussion: > > > Has the move to VHDL reduced design entry time? > > On intial entry I'd give VHDL the edge. But when a module has to > be ripped up to add something or make other changes I think VHDL > is significantly faster. I always wanted my schematics to look > pretty and it's much easier to re-format a text file than a > multi-sheet schematic. Also, you can't beat the unlimited space > for comments in a text file. > > > 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. This is true. Working with the floorplanner can be cryptic with a synthesized design as well. > > > On the other hand, source control programs like ClearCase work > much better with text files than schematics. If you plan to use > source control (vital for large projects) an HDL is the way to go. > Viewlogic files are ascii text files, so they can be put under source control the same way. > > Is design reuse easier? > > We built a large library of VHDL modules (counters, muxes, FIFO > controllers, etc.) that is built around vendor (in this case > Lucent) library elements. The modules are parameterized using > generics and are built optimally for the target architecture. All > the low-level grunt code of building these things is buried in the > library. Great resource for a big project. I don't know how this > could be done with schematics. Someone has to write the library, > though. I've done that to some degree in schematics by building a library of one and two bit placed slices. It's a lot faster to build a placed arbitrary width widget out of these blocks than starting fresh each time or hacking up a crowded page of primitives. I rarely have to use FMAPs in my day to day work even though much of what I do is placed in the schematics because the FMAPs are in the slices. This also gets a significant design reuse. > > > > Bottom line: Was it worth it? > > Yes. You may not have a choice eventually. I think the FPGA > vendors would prefer to quit supporting schematic entry > completely. Hopefully some day the HDL flow will be improved to > the point that there is no reason to use schematics any more. > No reason in whose opinion. Xilinx already tried that when they introduced Virtex. There is, and I think will likely continue to be a place for both design entry methods. I do use both, and like each for different reasons. -- -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: 19001
Dragon wrote: > I had the impression that metastability only occurs at the D inputs. If the > GSR deasserts and violates the flop's setup time, can the flop still go > metastable? Most certainly. In this case, the reset/set may go away close enough to a clock edge when the D input is a '1'. Presto, instant metastability. -- -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: 19002
I think EPIC is a piece of %*&$ compared with the old XDE as far as stability and user friendliness goes. Dragon wrote: > Amen! Its a shame EPIC doesn't feel more like the Floorplanner. When we > migrated to M1 I hoped for something like that. I must admit EPIC is worlds > better than the XACT editor, but still falls way short of user-friendly. BTW, > anyone know if Xilinx plans to upgrade the Floorplanner to include the > Virtex flow? Anyone see M2 yet? M2 has a floorplanner for Virtex. The inclusion of the floorplanner was a key piece I needed before I started recommending VIrtex to my customers. Before that, I generally recommended against Virtex unless you absolutely needed the block RAM. The Virtex tools are still not quite ready for prime time, but they are close enough. M2 has been out for quite a while now. -- -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: 19003
Dragon wrote: > > > I believe Spartans are simply XC4000's without RAM capability. Outsideof > this, what holds true for XC4000's should hold true for Spartans. > No, they are without the async RAM capability. They still have the sync RAM. They also don't have the WANDs, and all the parallel configuration modes are gone. It is also I die shrink, and doesn't come in the higher power packages. Otherwise, the architecture is pretty much the same. For most designs, you won't notice the difference between spartan and 4KE 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: 19004
"Dirk Bruere" <artemis@kbnet.co.uk> writes: >Joseph C. Su <sujosep@sympatico.ca> wrote in message >news:cEo_3.62916$up3.99009@news21.bellglobal.com... >> Do you think it is realistic for an undergraduate design project to >> undertake the task of implementing TCP/IP on FPGA ( i dare not to use the >> term "pld" anymore), given a team of three not very smart students? TCP is an unrealistic thing to implement on an FPGA - no matter what the time frame, no matter who is doing it. A good TCP has some very complex sub-algorithms. Moreover, another problem is that a protocol such as TCP is extremely hard to understand and define fully, and it is unlikely for some undergraduates to even understand the problem fully in a 1-semester time frame. These two issues are a recipe for disaster. Once upon a time, I wrote a software TCP on my own in 1 semester as part of my MIT undergraduate thesis. Because of the difficulty, the TCP became the *entire* thesis - and in those days I used to win programming contests for my speed at programming. I had a working single-process TCP already (PC/IP) and the "TCP Implementer's Guide" which is part of RFC793. I barely got it working and then I "de-tuned it" so that it would work with slightly flakey other types of TCP's. This was a very full one semester project, about 4 hours a day (the whole afternoon) From Jan 1st through May 10th. If you are looking for a network protocol for hardware implementation, why not look at XTP (express transfer protocol, designed by Greg Chesson in the late 1980's). This protocol would be much easier to implement in hardware. Also, you would have to add a lot of structure to the problem ( such as decomposing the problem into correct sub problems before giving it to the undergraduates ). Don Gillies - t_dgilli.x@qualcomm.x.com - Planetwide Software, Inc. (consultant) / Globalstar Satellite CDMA Project, Qualcomm Inc., 6455 Lusk Blvd San Diego, California 92121 - phone: 619-651-2326. Adjunct Professor of EE, UBC, Vancouver BC Canada V6T 1Z4 http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.html (remove x's to reply by email)Article: 19005
Hi - >> > Bottom line: Was it worth it? >> >> Yes. You may not have a choice eventually. I think the FPGA >> vendors would prefer to quit supporting schematic entry >> completely. Hopefully some day the HDL flow will be improved to >> the point that there is no reason to use schematics any more. >> > >No reason in whose opinion. Xilinx already tried that when they >introduced Virtex. There is, and I think will likely continue to be a >place for both design entry methods. I do use both, and like each for >different reasons. There's support, and then there's *support*. Years ago I worked on a project where we did Xilinx FPGA designs with the Cadence Concept schematic capture tool, then used a Cadence/Xilinx-supplied netlister to create XNF files (I say "Cadence/Xilinx" because ownership of the tool bounced between the two companies for a while). The netlister was an absolute abomination; it never worked quite right, and updates to accommodate new devices and features were always months behind updates to the Viewlogic netlister. We also used Viewlogic to support one or two designs that were done in Viewdraw. On one occasion I got a maintenance agreement covering both the Viewlogic and Cadence netlisters and, as these agreements often do, it listed the serial numbers of each tool. The Viewdraw netlister serial number was around 1200, while the Cadence netlister was around 10. And at that point an all-too-obvious lesson was driven home: make sure that the tools you're depending on for product shipment are not only supported, but are used by lots of other people who are going to scream loudly when they don't work. (But I'm willing to go out on a limb and try something new, or something very old, as long as it's not mission-critical.) I've used both schematic entry and Verilog HDL for FPGA design. Each has its strengths and weaknesses, and I'd like to see both options remain available indefinitely. But I'm concerned that if there are X people doing schematic capture and 50X doing HDL design, support for schematic design may continue to exist in name only. Another person who's sad to see useful tool chains disappearing, Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 19006
> I had the impression that metastability only occurs at the D inputs. If the > GSR deasserts and violates the flop's setup time, can the flop still go > metastable? Yes. If you open up the D ff and look inside at the gates or transistors, it boils down to the same problem. The key words are setup and hold. Any signal described that way on the data sheet will have metastability problems if you don't meet the specs. A clock qualifier is the other one I can think of right now. Note that an asynchronous set/reset input doesn't have any metastability problem on the going-active transition, only when going inactive, and then only if the data on the D input would cause a state change. Synchronous inputs can have troubles on both edges. -- These are my opinions, not necessarily my employers.Article: 19007
Ray Andraka wrote: > > On the other hand, source control programs like ClearCase work > > much better with text files than schematics. If you plan to use > > source control (vital for large projects) an HDL is the way to go. > > Viewlogic files are ascii text files, so they can be put under source > control the same way. A "diff" between successive versions of a Viewlogic schematic text file is unlikely to be helpful, whereas a "diff" between two successive versions of a piece of VHDL is likely to be quite informative :-) Jonathan BromleyArticle: 19008
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 Greg Neff <gregneff@my-deja.com> wrote in message news:81cjav$opg$1@nnrp1.deja.com... > In article <38398D1C.A7B9E445@ids.net>, > Ray Andraka <randraka@ids.net> wrote: > > Don Husby wrote: > > > (snip) > > > > > > I agree that schematics are still the best way to enter a design. > I just > > > thought I would beat my head against the VHDL wall one more time > before > > > going back to schematics. > > > > I've been using, no beating my head against the wall, with VHDL > lately too. > > I'm doing it for two reasons: First I have some customers who bought > the VHDL > > thing hook, line, and sinker (try to convince them they're wrong!), > and for my > > own stuff because it allows me to parameterize functions pretty > easily. I'm > > beginning to wonder if I'll ever see the return on the design > investment for > > those parameterized thingies though. > > > (snip) > > I having been using schematic entry for FPGAs, probably because I have > been drawing schematics since before the days of PALs, let alone > FPGAs. I am now considering taking the leap to VHDL entry, but I am > not convinced that there will be a benefit in either time to design or > design quality. The above comments seem to be indicative of those like > myself, who are highly skilled at schematic entry for FPGAs. > > I'm not talking about a situation where a team of engineers is > designing a mega-gate FPGA. I am more interested in small to mid-range > (say, up to 100K gate) designs that are being entered and maintained by > one person. > > I would be interested to hear from those people that have gone through > the VHDL learning curve. > > Has the move to VHDL reduced design entry time? > Has the design quality improved (fewer problems)? > Is design debugging easier? > Is design maintenance easier? > Is design reuse easier? > Did you get to the point where VHDL is more efficient than schematics? > If so, how long did it take to get to this point? > Bottom line: Was it worth it? > > I would like to hear from Don and Ray, to see if they consider > themselves to be still on the learning curve, or if they truly think > that VHDL is not worth the hassle. > > -- > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.com > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 19009
In article <81cqsb$pb$1@news.fsr.net>, pladow@gocougs.wsu.edu () wrote: [Most snipped] Agreed, particularly: > On a final note, I'm not saying that schematic entry is worthless. In > fact, > I use it often. For low-level design, we do VHDL entry. We then > generate > symbols and link them to the VHDL. Using schematic entry, we connect > all > the designs together in the top level. We then simulate the top-level > with > all the blocks together. > > Also, schematics serve as a visual que to data-flow. I like to see data > enter on the left-hand block, progress through the pipelines, and come > out of > the right-hand block. It also makes it easy to document what parts of > the > design are in different stages of completion. But in this role, the > top level > is nothing more than a glorified block-diagram. But I will admit, > hooking > up the top level in schematic form is much easier than in VHDL! But, > if I > needed to changed the top level layout later, I'd rather do it in VHDL. I take exactly the same approach. Top level block diagrams are much easier to understand than text, but when things start getting detailed, schematics are not my choice. This may be a question of background. I've been writing software as long as I've been doing electronics (>25 years, man and boy), and I find an exactly parallel situation there. Flowcharts, UML, visual programming, etc, are all good tools for design, and you can do a lot by pushing icons around, but at the end of the day, you need C++ or assembler or whatever to get the real work done. -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.ukArticle: 19010
email address is altered to prevent spam. I'd recommend the part only if you hate yourself and are looking for a reason to end it all ;) Jokes aside, we've been trying to use this part, and there's a lot of pain involved. Another thread regarding Lucent parts brings up many of these points. Have you found a proto-board based on this part? If so, I'd like to hear about it, but I don't think it exists because I've spent mucho time looking through all the lists at optimagic and other sites to no avail. Like someone else pointed out, Xilinx & Altera make FPGA's and hardly anything else. Lucent makes so many types of products it would be nearly impossible for one list them all. Who's gonna try harder? We're in the process of getting Xilinx's PCI design kit. One thing I like about it is the ability to target anything from a cheap Spartan (is there really any FPGA competition for Spartan's market?) to the biggest Virtex. I'll know more when it's in hand. Lucent's tools are now behind the times. Xilinx bought Neocad, old news, but the Lucent back-end tools haven't changed a lot since then. A bit rough around the edges. I'm not sure how Lucent explains their continuing rights to the NeoCAD software since the Xilinx buyout. I think they took the existing codebase and found new programmers to take over the code and go in their own direction, but I'm speculating. A problem you'll immediately find is that so far as I can tell the OR3TP12 is EXCLUSIVELY FOR VHDL/Verilog. That's the way the core parameters are passed and it's your only option. The core setup tool is a pain too since you can't save your settings to revise them later. It fleshes out a VHDL/Verilog template and you can't go back to the GUI to tweak settings later. Write them down ! We're using Synplify for the VHDL, FYI. There's a lot of nifty things the hardwired core allows you to do, but there's also the drawback of it being considerably more effort for them to roll out new chips. Your only option right now is the pared-down OR3C/T55 -sized device (sans about 4 rows for the PCI core) with other parts "coming soon now" for quite some time now. Our local apps engineer went back to the plant to "help roll out the next device" or something, which left us without good support. The hardwired core has many bugs, and the downside of these bugs is that it's not a simple fix being hardwired and all. The core setup software had a bug we were stuck with for quite some time before receiving an update -- the BYTES were OUT OF ORDER in the 32-bit words. How the hell do you miss something like that in testing? Luckily, it WAS software. My guess is that if you go with the part you will feel very alone with whatever problems you come across. We sure do. One good way to judge your FPGA vendor: go see how many application notes they have. Lucent's got maybe 10 or 20 total on the web. Xilinx has probably a thousand or more scattered across the Xcell Journal and general app notes. I like that. The Xilinx PCI design kit comes with a board based on the core and a reference design. PCI is complicated as hell and that reference can save MONTHS. Something to think about! BW Edward Wallington wrote: > Hi, > has anyone put a design into production using the OR3TP12 on a card in a > PC? > (this is Lucent's part FPGA, part hardwired ASIC PCI core) > > Which synthesis route / tools did you use? > Any gotcha's ? Did it work perfectly? > > Thanks > > Ed. > > -- > Edward Wallington - Chief Hardware Engineer > Cambridge Research Systems Ltd. > Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719 > http://www.crsltd.comArticle: 19011
Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>... >Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>... >>>>**Symplify (simulates the HDL design fine all the time) >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >>I missed 1 SW: >>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time) > > >Did you use timing constraints and are they being met? > Think it is not important. The input of the shift register is at one input pin and the output of the shift register (last bit) at another (output) pin. A logic "1" should after some time (Tclk * N+eventual timing problems) cause a logic "1" and a "0" a "0". I used this simple TEST design just for this insensibility (if the delay is not important to me). But the output is sometimes (in dependence of cell positions) stuck at "0" or "1" (it does not change)! __________________________________________________________________________ Filip S. Balan Faculty of Electrical Engineering and Computer Science Institute of Electronics Smetanova 17 SI-2000 Maribor Slovenia Phone: +386 62 220 7202 Fax: +386 62 211-178 E-mail: balan@uni-mb.si __________________________________________________________________________Article: 19012
Dear friend, Yesterday I have got following message from Xilinx Alliance design manager WARNING:Timing:33 - Clock nets using non dedicated resources were found in this design. Clock skew on these resources will not be automatically addressed during path analysis. To create a timing report that analyzes clock skew for these paths, run trce with the '-skew' option. But I'm sure to use only dedicated clock resources. And place all my clock nets on bufg or bufgp. 1. How can I find out which net exactly or in which component Xilinx means. 2. I have never started trce manualy. Is it any say to Design manager to run trce with -skew option. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!Article: 19013
On Tue, 23 Nov 1999 17:49:13 -0500, Ray Andraka <randraka@ids.net> wrote: > > >Dragon wrote: > >> >> >> I believe Spartans are simply XC4000's without RAM capability. Outsideof >> this, what holds true for XC4000's should hold true for Spartans. >> > >No, they are without the async RAM capability. They still have the sync RAM. >They also don't have the WANDs, and all the parallel configuration modes are >gone. It is also I die shrink, and doesn't come in the higher power packages. >Otherwise, the architecture is pretty much the same. For most designs, you won't >notice the difference between spartan and 4KE devices. I recall that there was a post in this news group some time ago that said that someone had tried downloading a 4000e bit stream to a Spartan part, and it had functioned exactly like the 4000e part. Makes sense when you think about it - a significant amount of Xilinx's (or any other vendors') overheads will come from the costs of developing software, so they can save a lot of money and get to market quicker if they make the costdown parts exactly equivalent to the originals, at least for the initial rev of silicon. Earlier today a Xilinx rep told me that they already have support for the Spartan-2 parts in their current software (even though they won't even announce the family until next year). This implies to me that the Spartan-2 will be bitstream compatible with Virtex. I may be wrong of course. Allan.Article: 19014
Hello and a good day out there, I'am searching for the pin-out of a programming cable used for a MACH445, i.e. to program it from a PC parallel port ... I couldn't find any information to this topic - is it a secret 8-? I know that AMD's MACH is nowadays a M4-128/64 from Lattice. Thank you for any hint to my request. Sincerely, GuidoArticle: 19015
Hello again, (sorry) I forget to say that I intend to use the old AMD MACHXL2.1 software to download the jedec file ... Thanks, GuidoArticle: 19016
Hi, As I see from the Question, Design is about 80K, i want to know gate count of Sequential elements( No. of Flops), If it is possible Group the all the flops in to new Heireachy, then do scan insertion for new module. Grouping can be done with reference to cell name, If All sequential elements are at one place, hope routing is easy. * Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is BeautifulArticle: 19017
In article <hAo7OGCUqVpuedBjHwKsQ44FTFG5@4ax.com>, John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote: (snip) > We actually don't spend much time debugging uP code or FPGAs because of our > philosophy: design carefully, document and comment thoroughly, check it before > you fire it up, and keep it beautiful at all times. I dislike habitual use of > simulation because it tends to lead designers toward a hack-and-test mode, and > one can never really test quality into anything. So far, we've had zero > hardware/software/FPGA bugs in the products we've shipped that have FPGAs. > > Anyway, we do fairly hairy FPGA designs using schematics, and the stuff comes > out fast and relatively easy. I just thought *somebody* ought to express that > opinion. > (snip) I think that Ray was commenting on those engineers that use the "burn and learn" approach to design, which is very risky and unpredictable. If I understand your comment correctly, you are trying to avoid a similar "simulate and learn" approach. Although neither is a good design methodology, I would imagine that it would still be better to learn at the simulate stage, as opposed to the hardware stage. The "correct by design" approach (which is what I think you are promoting) still requires some sort of method to validate and verify "correctness". Complete specifications, careful and well documented designs, and design reviews are obvious requirements to implement a correct by design methodology. Still, I find it hard to believe that simulations are not faster and more reliable than manual analysis when it comes to validating a design. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19018
This might not be strictly an FPGA question, but does anyone know if it is currently possible to get obselete microprocessors emulated on fpgas or other platforms. I need a seamless cross over from an old one time 8749 to something which looks electronically the same when in circuit. Any suggestions or ideas gratfully received. Mark email pleydellm@microsense.co.ukArticle: 19019
Filip S. Balan wrote: > [...] > Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>... > > > >Did you use timing constraints and are they being met? > > > > Think it is not important. The input of the shift register is at one input > pin > and the output of the shift register (last bit) at another (output) pin. A > logic > "1" should after some time (Tclk * N+eventual timing problems) cause a logic > "1" and a "0" a "0". > I used this simple TEST design just for this insensibility (if the delay is > not important to me). > But the output is sometimes (in dependence of cell positions) stuck at "0" > or "1" (it does not change)! Hello Filip, I'm not familiar with the Atmel parts, but an idea: do you use a dedicated clock net, or normal routing resources for the clock? By using normal routing recources, it's possible that the clock delay from flipflop n to flipflop n+1 ist greater than the data delay. In this case, at the active clock edge flipflop n+1 will not take the "old" value of flipflop n, but the new. Greetings WernerArticle: 19020
Jonathan Bromley wrote: > > Ray Andraka wrote: > > > On the other hand, source control programs like ClearCase work > > > much better with text files than schematics. If you plan to use > > > source control (vital for large projects) an HDL is the way to go. > > > > Viewlogic files are ascii text files, so they can be put under source > > control the same way. > > A "diff" between successive versions of a Viewlogic schematic text file > is unlikely to be helpful, whereas a "diff" between two successive > versions of a piece of VHDL is likely to be quite informative :-) > Viewlogic files are not cannonized, the order of elements output into one is dependent on the state of a database image (which also depends on the order it is read in from text sources). Without recourse to a program for ordering the file, you can treat them the same way you would a binary file, every check adds the current file to its archive. Way back when, we used to have a program for cannonizing gem files. (A 2D editor used for chip layout/design, and schematic entry written by Gary Tarolli). There is no pressing need for cannonization for viewlogic files - disk space is relatively cheap. and you'd be hard pressed to generate schematics bigger than Now what would be interesting would be visual differences. The same could be said about HDLs, it would be nice to be able to view them in the abstract, including differences. -- remove "no_spam_" from Reply-to addressArticle: 19021
Filip S. Balan wrote in message <81g8ar$h47$1@strelovod.uni-mb.si>... >Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>... >>Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>... >>>>>**Symplify (simulates the HDL design fine all the time) >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>>I missed 1 SW: >>>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time) >> >> >>Did you use timing constraints and are they being met? >> > > >Think it is not important. The input of the shift register is at one input >pin >and the output of the shift register (last bit) at another (output) pin. A >logic >"1" should after some time (Tclk * N+eventual timing problems) cause a logic >"1" and a "0" a "0". >I used this simple TEST design just for this insensibility (if the delay is >not important to me). >But the output is sometimes (in dependence of cell positions) stuck at "0" >or "1" (it does not change)! perhaps if you post your code... -- ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu The secret of Slurm is on a need-to-know basis.Article: 19022
"Joseph C. Su" wrote: > > Do you think it is realistic for an undergraduate design project to > undertake the task of implementing TCP/IP on FPGA ( i dare not to use the > term "pld" anymore), given a team of three not very smart students? That's cool! How about designing a floating point unit in a FPGA with three novice math students? Or a nuclear bomb with some undergraduate physics students? Or... Armin :-)Article: 19023
Werner Dreher wrote in message <383C0406.3E4D@informatik.uni-tuebingen.de>... >[...] > >Hello Filip, > >I'm not familiar with the Atmel parts, but an idea: >do you use a dedicated clock net, or normal routing resources for the >clock? By using normal routing recources, it's possible that the clock >delay from flipflop n to flipflop n+1 ist greater than the data delay. >In this case, at the active clock edge flipflop n+1 will not take the >"old" value of flipflop n, but the new. > >Greetings >Werner This is all true, but... in this case the overall delay from input to output pin would be even smaller. If the clock period (tried down to 10MHz ) would be shorter then the data delay, then the overall delay from input to output pin would raise (let's say cca. 2x). Would any of this circumstances stuck my output ?? Filip S. Balan Faculty of Electrical Engineering and Computer Science Institute of Electronics Smetanova 17 SI-2000 Maribor SloveniaArticle: 19024
"David G. Koontz" wrote: ...snip... > Way back when, we used to have a program for cannonizing gem > files. (A 2D editor used for chip layout/design, and schematic > entry written by Gary Tarolli). There is no pressing need for > cannonization for viewlogic files - disk space is relatively cheap. > and you'd be hard pressed to generate schematics bigger than > Now what would be interesting would be visual differences. The > same could be said about HDLs, it would be nice to be able to > view them in the abstract, including differences. This would be a very useful tool indeed for people using schematic capture as a front end. But it is unlikely that anyone will ever create such a tool. The problem as I see it is that even though there are a large number of people still using schematics in full or in part to design FPGAs, there is a prevailing attitude among the tool vendors that schematic capture is going the way of the dodo bird. As a result, the tools largely stagnate as the vendors work harder and harder on HDL front ends. In the end, this becomes a self fulfilling prophesy since you can't buy what they don't sell. I have already been told by two FPGA vendors that they will not be supporting schematic capture at some point in the future. To me this is a bit like Microsoft saying they will stop supporting assembly language programming in the future. If they want to do it there is nothing we can do about it except to learn C++. Then they were right to do it. -- 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.com
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