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
> 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 traditionally implemented in software. Go talk to some software guys and get them to show you the code. There are a lot of corners you can cut, but you have to understand what you are doing before you can do that. TCP/IP Illustrated, Volume 1 by Stevens is a good place to start. It's 576 pages. For a class project, I'd suggest something like a simple UDP server. Somebody sends you a packet. You grap some data, say the temperature, and send it back. If that's too easy, consider using TFTP to send or receive a file. (File means a chunk of data that's too big to fit in a single packet.) -- These are my opinions, not necessarily my employers.Article: 18976
| |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. | Hi, I've done all my FPGA designs as schematics. The thing I like about this form is... 1. Suppose one of my engineers designs an FPGA, and asks for my help, or even quits and leaves it up to me to finish the design. Or, equivalently, we revisit something that was done a year ago and that nobody really remembers. Well, I can look at a good schematic and absorb it in seconds, and can often spot a bug in minutes. The schematic is parallel and visual. Picking up someone else's code (C, assembly, or, I suspect, HDL) is a much slower process. 2. I wouldn't dream of designing an FPGA without understanding the underlying architecture. It's fairly easy to draw a schematic that optimizes the design to the part architecture. If it's Xilinx, I'd want to avoid, say, 6-input AND gates if I can, or put in pipeline flops where I know they fit into the cell structure. 3. It seems to me that I see a lot of newsgroup posts that ask for help getting the HDL to do what the user wants; say, to use the Xilinx hard carry chain, or to put the flipflops in the right places. That's seldom a problem for us using schematics. We spend very little time fighting (or for that matter even learning) the tools. 4. A good schematic is VERY readable. Sheet 1 is the block diagram with table of contents, sheet 2 is register map (if any), and the rest is carefully labeled and commented. 5. We don't simulate, so that aspect of HDL is not useful to us. We just design carefully, compile, and test. After all, it IS an FPGA, and not a piece of silicon that will take six weeks and $100K to change. When we do find a problem, the cause is generally (almost always) right in front of our faces on the schematic, so we fix it quickly. 6. Inner blocks are sometimes easier expressed as logic equations, so the guts of, say, a decimal counter can be coded in a language. This then becomes a defined schematic symbol which fits right in. That's OK. 7. Coding standards are easy, even for beginners. I give them my neatest schematic and say 'make it look like that'. And I can review it in minutes. I like schematics because they are so visual and parallel, and that suits the way I see and think. Others, who have a more sequential or verbal mentality, may well prefer logic expressed as text. But schematic design is fast and efficient for us, and a six-month learning curve for VHDL is time I would never recover. John you can see some of my designs at www.highlandtechnology.comArticle: 18977
Ray Andraka wrote: > Even working at the RTL level, you really should be designing to the > architecture if you want good quality results. A design aimed at an architecture will not be a stellar performer in a different architecture, but it can be moved. That might just be enough to avoid needing to redo an older design. -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 18978
Greg Neff wrote: > Thank you for you detailed response. I absolutely agree that proper > synchronous design practices are required. This is true for FPGAs, no > matter what design entry method is used. My concern is how to enforce > these design rules in VHDL. In a schematic I can force a global buffer > to be used for clock distribution. How hard is it to do this in VHDL? Depends somewhat on the target family. Synthesis tools will almost always use a global buffer for clock. I've seen one case that they didn't, and the solution as to instantiate a global buffer primitive. Also, high fanout logic signals sometimes need global buffers for speed (can't do this in all targets). > Also, for synchronizing registers I can define a special timing > constraint that will guarantee the extra setup time margin needed > between synchronizing registers, to reduce the probability of > metastability. How hard is it do this in VHDL? I've done this with Xilinx. The path I followed was to put a timing constraint between the registers in question in the Xilinx ".ucf" file, which is fairly easy to do. A warning: Xilinx tools will duplicate registers in an attempt to improve speed and/or routing. There is a switch (to map or par) you had best set. I also did some floorplanning to make sure that this didn't happen again. -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 18979
Greg Neff wrote: > 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'm in a similar boat, but let's say from 1 to 3 people. ------------------------------ > I would be interested to hear from those people that have gone through > the VHDL learning curve. me too. ------------------------------ > Has the move to VHDL reduced design entry time? for certain types of problems. i don't know how many times i've had to draw muxes for reading out a number of different quantities, putting together items of different lengths to pack them into a word, etc., etc., etc. vhdl is far superior for that. complex state machines are much faster in vhdl, too, although one has to be careful about the unused state problem, which vhdl is poor at (note that synplicity is working on this with their "safe" mode). there are other situations where there is redundancy that you don't want the tool to eliminate and you have to ensure that the tool does what you think you are telling it to do. another factor with vhdl is that the tools are constantly changing and the output that you get with one version is not necessarily the same as within another. while with schematics you can only share reasonable with someone who has a compatible tool (i happen to use viewlogic), which is a pain, vhdl can be "shared" with anyone who happens to have notepad or an old version of wordstar. however, the design (the actual gates) is less portable since your pal reviewing it or adding to it can not see the same output that you get. you have to e-mail him a structural netlist to toss into the simulator. that doesn't provide insight into the design, just a simulatable model. for example, it's easy in vhdl to generate a poor circuit in hardware although it looks fine at the vhdl level. ------------------------------- > Has the design quality improved (fewer problems)? don't think it matters that much, if one discounts unfamiliarity with the language (and tools) while ramping up on the "learning curve." of course, one can't really discount that. vhdl makes it harder to see the flow of signals and their relationships so in some cases it would hurt (pipelined designs, circuits with feedback). for certain state machines, it makes it easier to see. -------------------------------- > Is design debugging easier? i'd say harder, since you can't see (easily and clearly) the design that is generated in hardware. as an example, take the output of some vhdl and put it into your favorite schematic generator. using schematic entry, where each signal and instance is labelled, it's trivial to talk to the chip (for probe) or the tools (for analysis). -------------------------------- > Is design maintenance easier? again, depends on the circuit. for a lot of systems the flow of a well drawn schematic wins easily. for modifying a complicated state machine with a bunch of different cases when a system engineer CHANGES HIS MIND AGAIN is easier in vhdl. -------------------------------- > Is design reuse easier? it can be in two ways. one, it's easier to parameterize the design. and two, i can write my own software that algorithmically generates a design. that's easy since the design entry is ascii text. writing software to generate schematics is more difficult; i haven't tried the interface to viewlogic for that yet. -------------------------------- > Did you get to the point where VHDL is more efficient than schematics? again, depends on the design i'm doing. for certain areas yes. -------------------------------- > If so, how long did it take to get to this point? variable. for certain designs, a few months. since i've had some critical projects (day job) my phase-in of vhdl was longer than it might otherwise have been. it is not a simple learning curve, although that may also be a factor of my age and the length of time using schematics. --------------------------------- > Bottom line: Was it worth it? yes. while the above concentrated on design for synthesis, vhdl for writing test benches is a powerful tool, too, that has some nice advantages in certain cases. rkArticle: 18980
Symphony EDA is pleased to announce support for the Xilinx
UniSim and SimPrim libraries in "VHDL Simili". We are proud
to add these Xilinx libraries to our list of supported vendor
libraries (Altera, Cypress, etc.) with more to come.
"VHDL Simili" is a VHDL Compiler/Simulator environment with
the following features.
-- VERY FAST Compiler and Simulator
-- VHDL 93
-- Vital/SDF support
-- Tested with Programmable Logic Vendor Libraries
-- Designed for the serious VHDL professional
-- Optimized for easy internet downloads
-- Much much more ...
VHDL Simili is FREE with no gimmicks/strings attached and
without any limits on the number/size of your VHDL files,
simulation run time, etc.
Please visit us at
http://www.symphonyeda.com
to find out more and download the software (3.2MB).
Haneef D. Mohammed
Symphony EDA
haneef@symphonyeda.com
Article: 18981In article <gDXZ3.34919$YI2.1673968@typ11.nn.bcandid.com>, "Erich Wagner" <ewagner@pdq.net> wrote: > Is anyone actively using Altera's JAM technology? What are your experiences? We too have used it most successfully over the last 9 months. We have a PCI-based board with a 10k50E on it. The board uses a proprietary PCI-local bus bridge so we don't have a bootstrap problem. We use a MAX7128 to act as a local bus target, providing three memory locations whose bits match those of a byteblaster. We ported the Altera jam player to Linux/Alpha (not totally trivial, as there are numerous 32-bit long assumptions). It now forms a routine part of a device driver since it takes less than 2s to download the flex code. Derek Roberts AT&T Labs Cambridge Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18982
>>**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) Filip S. Balan balan@uni-mb.siArticle: 18983
John Larkin wrote: All good comments, well except for this one: > |5. We don't simulate, so that aspect of HDL is not useful to us. We > just design carefully, compile, and test. After all, it IS an FPGA, > and not a piece of silicon that will take six weeks and $100K to > change. When we do find a problem, the cause is generally (almost > always) right in front of our faces on the schematic, so we fix it > quickly. I wouldn't dream of sending a design to a customer without first simulating it. I intensely dislike the politics of being in the Lab. Some time spent in simulation makes sure that the design works the first time, and more importantly that you have an opportunity to check all the boundary conditions. How long do you spend in the lab debugging? -- -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: 18984
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? -- ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Creation Science" is oxymoronic.Article: 18985
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: 18986
Hi there, nearly half a year before I bought an Hyperstone Eva Kit (E32) with CODEC Board and from this time on I had trouble with. The whole system seems to fool me. After request at hyperstone.de I got some new software (dsp-library, header files new compiler) piece by piece but the whole thing isn't working yet. It's a pity because the Hyperstone concept is good and documentation well done (not always at conformity with the sample application). The main drawback is that there is no place to look in working application software other than the little stuff I got included with the kit. Has somebody bought it too an has further experince with - any help is welcome --jensArticle: 18987
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. 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. > 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. > 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. RJSArticle: 18988
Utku Ozcan wrote: > I have a question which close to this discussion: > > We are using Spartan-XL and we intend to use TWO individual resets > in the chip..... > From 2, I understand that it is possible to use two resets and one > reset can be asserted to GSR routing and the other one must be used then > in normal routing. But 2 is correct only for XC4000 devices, since > the item is "Startup Block for XC4000 and XC5200", there is not the > word "Spartan" at the header title of the item. > I believe Spartans are simply XC4000's without RAM capability. Outsideof this, what holds true for XC4000's should hold true for Spartans. > If Xilinx is true, then I conclude that when I want to use more than > one reset in Spartan or XC4000, then routing will be worse, since > I mustn't use GSR usage for a correct operation and the resets will > use normal routing resources. That will make the routing more difficult. > You can still connect the local reset net to a global buffer (not GSR) andpossibly improve routing. You will likely have to do this by instantiating a BUFG component in your HDL code. I doubt Synplify will have the insight to do this automatically. Be careful you don't run out of global buffers though. You can only use 4 globally! > If Synplify is true, then I conclude that when I want to use more > than one reset in XC4000 and XC5200, and when I want to assign one > of the two reset signals to the GSR routing, then routing will be > used efficiently. > Yes. However the GSR net will set or reset ALL flops in the FPGA. > Which is correct? > > UtkuArticle: 18989
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?
- Craig
Hal Murray wrote:
> Speaking of GSR being slow, that brings up the whole Metastability mess
> again. This probably isn't statistically important since GSR doesn't
> change very often.
>
> Note that even if you have plenty of time, you can't use GSR to reset
> the whole chip if you have two or more asynchronous clocks. At
> least you can't do it cleanly. Even if you only have one clock,
> you also have to make sure that the signal connected to GSR is
> clocked by that clock rather than a junk IO from a microprocessor
> that's running on a different clock.
>
> --
> These are my opinions, not necessarily my employers.
Article: 18990In article <383A8CB2.2A97473F@ids.net>, Ray Andraka <randraka@ids.net> wrote: > > > John Larkin wrote: > > All good comments, well except for this one: > > > |5. We don't simulate, so that aspect of HDL is not useful to us. We > > just design carefully, compile, and test. After all, it IS an FPGA, > > and not a piece of silicon that will take six weeks and $100K to > > change. When we do find a problem, the cause is generally (almost > > always) right in front of our faces on the schematic, so we fix it > > quickly. > > I wouldn't dream of sending a design to a customer without first simulating > it. I intensely dislike the politics of being in the Lab. Some time spent > in simulation makes sure that the design works the first time, and more > importantly that you have an opportunity to check all the boundary > conditions. How long do you spend in the lab debugging? > > -- > -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 > > Politics notwithstanding, I have to agree with Ray on this one. Typical lab testing may only cover three quarters of the logic. As Ray pointed out, boundary conditions may or may not be encountered during testing. Also, error recovery logic will not be exercised under nominal conditions. Simulation is the fastest way to find out how the logic will respond to low probability events, or conditions that are hard to produce in the lab. In the lab, can you force a state machine to an illegal state to make sure that it recovers? It can be damn hard to figure out what is going on inside an FPGA, because you can't poke around the logic with a scope or logic analyzer. I have never regretted the time to build and run a good simulation. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18991
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?
- Craig
Ray Andraka wrote:
> EPIC is _NOT_ a floorplanner. It is an editor, and a PITA at that. I'd take the
> old the Xact 6.0 XDE and floorplanner over the current tools any day if they
> would support the current 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
Article: 18992
John Larkin wrote:
> Hi,
>
> I've done all my FPGA designs as schematics. The thing I like about
> this form is...
>
> 1. Suppose one of my engineers designs an FPGA, and asks for my help,
> or even quits and leaves it up to me to finish the design. Or,
> equivalently, we revisit something that was done a year ago and that
> nobody really remembers. Well, I can look at a good schematic and
> absorb it in seconds, and can often spot a bug in minutes. The
> schematic is parallel and visual. Picking up someone else's code (C,
> assembly, or, I suspect, HDL) is a much slower process.
> 4. A good schematic is VERY readable. Sheet 1 is the block diagram
> with table of contents, sheet 2 is register map (if any), and the rest
> is carefully labeled and commented.
>
I might agree up to ten sheets.
At 100 sheets it might take me over 10,000 seconds
to absorb the design intent.
> 2. I wouldn't dream of designing an FPGA without understanding the
> underlying architecture. It's fairly easy to draw a schematic that
> optimizes the design to the part architecture. If it's Xilinx, I'd
> want to avoid, say, 6-input AND gates if I can, or put in pipeline
> flops where I know they fit into the cell structure.
I agree if speed or gate packing is the main concern.
However you might be surprised how smart the best synthesizers
are getting and how cheap fpga gates are getting.
> 3. It seems to me that I see a lot of newsgroup posts that ask for
> help getting the HDL to do what the user wants; say, to use the Xilinx
> hard carry chain, or to put the flipflops in the right places. That's
> seldom a problem for us using schematics. We spend very little time
> fighting (or for that matter even learning) the tools.
For every such trouble post there are probably 100 happier
but unreported instances where a more capable synthesizer
inferred the the structure just fine.
> 5. We don't simulate, so that aspect of HDL is not useful to us. We
> just design carefully, compile, and test. After all, it IS an FPGA,
> and not a piece of silicon that will take six weeks and $100K to
> change. When we do find a problem, the cause is generally (almost
> always) right in front of our faces on the schematic, so we fix it
> quickly.
I do simulate because I really hate connecting those little
logic analyzer clips to to 32 bit buses.
> 6. Inner blocks are sometimes easier expressed as logic equations, so
> the guts of, say, a decimal counter can be coded in a language. This
> then becomes a defined schematic symbol which fits right in. That's
> OK.
I agree. Once you start down this slope you might discover
that the function in the block is growing toward the IO pins.
> 7. Coding standards are easy, even for beginners. I give them my
> neatest schematic and say 'make it look like that'. And I can review
> it in minutes.
I might give them a code example and do the same thing.
> I like schematics because they are so visual and parallel, and that
> suits the way I see and think. Others, who have a more sequential or
> verbal mentality, may well prefer logic expressed as text. But
> schematic design is fast and efficient for us, and a six-month
> learning curve for VHDL is time I would never recover.
I used to agree with you. Now I draw the boxes and circles in my
notebook and get on with hacking and sim'ing code.
-Mike Treseler
Article: 18993Greg Neff wrote: > In article <383A8CB2.2A97473F@ids.net>, > Ray Andraka <randraka@ids.net> wrote: > > > > > > John Larkin wrote: > > > > All good comments, well except for this one: > > > > > |5. We don't simulate, so that aspect of HDL is not useful to us. We > > > just design carefully, compile, and test. After all, it IS an FPGA, > > > and not a piece of silicon that will take six weeks and $100K to > > > change. When we do find a problem, the cause is generally (almost > > > always) right in front of our faces on the schematic, so we fix it > > > quickly. > > > > I wouldn't dream of sending a design to a customer without first > simulating > > it. i guess i could dream it, but for other than trivial designs it would be a nightmare. ------------------------------------------------------------------------------------- > > I intensely dislike the politics of being in the Lab. Some time spent > > in simulation makes sure that the design works the first time, and more > > importantly that you have an opportunity to check all the boundary > > conditions. How long do you spend in the lab debugging? i do sort of enjoy lab work ... but often in a lab, when things don't work, the fingers usually start pointing and right at the fpga, typically. it pays to have the thing designed correctly and working out of the box. normally, this is what happens. you wind up getting dragged into the lab anyways, it seems, but that's another story. it's just best to have the stuff work and spend no time debugging, just verifying. ------------------------------------------------------------------------------------- > Politics notwithstanding, I have to agree with Ray on this one. > Typical lab testing may only cover three quarters of the logic. As Ray > pointed out, boundary conditions may or may not be encountered during > testing. Also, error recovery logic will not be exercised under > nominal conditions. Simulation is the fastest way to find out how the > logic will respond to low probability events, or conditions that are > hard to produce in the lab. In the lab, can you force a state machine > to an illegal state to make sure that it recovers? It can be damn hard > to figure out what is going on inside an FPGA, because you can't poke > around the logic with a scope or logic analyzer. I have never > regretted the time to build and run a good simulation. i generally agree with this ... it's very easy in simulation, for example, to have an input arrive during all states of your state machine. actually, vhdl test benches make this task relatively easy and clean. in the lab, it is far more difficult. it's just easier to work, for certain problems, in the simulator. for some others, it's easier in the hardware (such as very long sequences, like working on large format, 2-D detectors). however, you can poke around in at least some fpgas. because of the apps i have, i most often use the actel devices which allow you to address, in real-time, any two arbitrary points. this can be used equivalently to a scope on a circuit board, where i would like to probe each signal during operation (both for good logic levels and transitions and waveforms). now you just hook up the scope probes and dial them in from the console. stu (haven't seem him much around lately) had some nice things to say about the orca system, where it could shoot wires very quickly, bringing out internal points. of course, this is easy to do when you design with schematics. with vhdl, things are hidden quite a bit, making it tougher to walk through the design. that's a bit scary ... i had one guy walk into my office (day job) did a whole chip in vhdl, it didn't work, and wanted to probe inside, it was a pain. anyways, especially with vhdl, i think rigorous simulations will gain in importance. ------------------------------------------------------------------------ rk The world of space holds vast promise stellar engineering, ltd. for the service of man, and it is a stellare@erols.com.NOSPAM world we ahve only begun to explore. Hi-Rel Digital Systems Design -- James E. Webb, 1968Article: 18994
On Mon, 22 Nov 1999 23:59:25 GMT, Greg Neff <gregneff@my-deja.com> wrote: >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. > >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. I moved away from schematic entry a few years back, not quite on purpose. But it wasn't all at once. :-] At first, using viewlogic for Xilinx 4k designs, I found Xabel to really speed up the design process: I put control logic in Xabel source files, and instantiated them in my schematics. I could tweak the low-level code without changing my schematic (until it required I/O changes.) Where I needed to control timing/logic levels, I wrote my code to control which signals went through only 1 logic level; the tool was dumb (smart?) enough to follow the partitioning of the logic as it was written, when I broke up equations into multiple parts. Printing the schematic was a pain, and for the one Xilinx 3k design I had, the Xilinx tools required unique instantiations in my hierarchy--so I had eight "unique" sets of hierarchical elements. Maintaining the schematics was definitely a major pain with the 3k series, just an annoyance for the 4k. Then I learned verilog, and unfortunately didn't have (or know how to use?) a schematic front end. So the top level of my design was in hdl, and it took a while for me to get used to it. > >Has the move to VHDL reduced design entry time? I think so. I stumble over syntax errors, I make typos, etc. With experience some of these decrease, and at least I become more adept at finding them. But more significant would be the reduction in time for design changes. And being able to compare, automatically, current and past iterations with a simple file compare. (This, of course, assumes you haven't overwritten your previous version(s).) >Has the design quality improved (fewer problems)? WYSIWYG was somewhat the rule for shematic-based designs: you use a 5-input NAND gate, that is what you get. (Assuming it maps nicely to your target technology.) With HDLs (Xabel, verilog, VHDL, ...), the synthesis tool goes through some optimization algorithms, which may or may not do things the way you would like. Some of them have even been known to optimize out global buffers that have been instantiated (or even use incorrect elements, such as a latch without an enable instead of one with.) So you have to learn the synthesis tool and work around its limitations. >Is design debugging easier? I think so; at least if you can get quick feedback from your simulator. >Is design maintenance easier? Much. >Is design reuse easier? Others have made good points. I haven't done any designs > 100k gates, and I haven't developed my own procedures or generics. But I find that it is really easy to use an 8-bit shift register as a serial-to-parallel converter, and also as a parallel-to-serial converter. Oh, I need a clock enable this design? A short time later, module done and simulated. Need a different size? The right way is to use paramaters/generics, but it is quick and easy to also just copy the module and change the indices. I.e., you don't need to be an expert to leverage an old design to create a new one that is similar in structure. >Did you get to the point where VHDL is more efficient than schematics? I believe so. >If so, how long did it take to get to this point? Well, in regards to leaf nodes of the design, it is almost no time. Other than that, it takes a little getting used to--but so did the idea of hierarchical schematic design. >Bottom line: Was it worth it? Yes. > >-- >Greg Neff >VP Engineering >*Microsym* Computers Inc. >greg@guesswhichwordgoeshere.com > Jason T. Wright Senior Engineer CG Technologies EricssonArticle: 18995
This is a multi-part message in MIME format. --------------07282AF9ACBFC3713783D9E7 Content-Type: multipart/alternative; boundary="------------94805CE7C6302745D2EADB38" --------------94805CE7C6302745D2EADB38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Both VHDL and Verilog code is freely availible for this application note. Just download, ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip for both versions of the code. -- Brian Michael G Wrighton wrote: > Hi, > We're in need of a FIFO implemented with the Virtex's Block RAM. I've > found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block > SelectRAM+" available from the cores page. This is precisely what we > need except for that it is written in Verilog and our environment is > VHDL. I'd be willing to try this co-simulation trick to integrate the > two languages, but I wonder if anyone knows of a VHDL version of this > freely available. Also, I've heard the mixing VHDL and Verilog can > result in some pretty hairy problems. Any comments on that front? > > Thanks, > MGW -- ------------------------------------------------------------------- / 7\'7 Brian Philofsky (brian.philofsky@xilinx.com) \ \ ` Xilinx Design Engineer hotline@xilinx.com / / 2100 Logic Drive 1-800-255-7778 \_\/.\ San Jose, California 95124-3450 1-408-879-5199 ------------------------------------------------------------------- --------------94805CE7C6302745D2EADB38 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Both VHDL and Verilog code is freely availible for this application note. Just download, <A HREF="ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip">ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip</A> for both versions of the code. <br> <p>-- Brian <br> <br> <p>Michael G Wrighton wrote: <blockquote TYPE=CITE>Hi, <br>We're in need of a FIFO implemented with the Virtex's Block RAM. I've <br>found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block <br>SelectRAM+" available from the cores page. This is precisely what we <br>need except for that it is written in Verilog and our environment is <br>VHDL. I'd be willing to try this co-simulation trick to integrate the <br>two languages, but I wonder if anyone knows of a VHDL version of this <br>freely available. Also, I've heard the mixing VHDL and Verilog can <br>result in some pretty hairy problems. Any comments on that front? <p>Thanks, <br>MGW</blockquote> <pre>-- ------------------------------------------------------------------- / 7\'7 Brian Philofsky (brian.philofsky@xilinx.com) \ \ ` Xilinx Design Engineer hotline@xilinx.com / / 2100 Logic Drive 1-800-255-7778 \_\/.\ San Jose, California 95124-3450 1-408-879-5199 -------------------------------------------------------------------</pre> </html> --------------94805CE7C6302745D2EADB38-- --------------07282AF9ACBFC3713783D9E7 Content-Type: text/x-vcard; charset=us-ascii; name="brianp.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brianp.vcf" begin:vcard n:Philofsky;Brian tel;fax:(408) 879-4442 tel;work:1-800-255-7778 x-mozilla-html:TRUE org:<BR><H1 ALIGN="CENTER"><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx" ALIGN="CENTER"> Design Center version:2.1 email;internet:brianp@xilinx.com title:<H3 ALIGN="CENTER"><img src="http://bennyhills.fortunecity.com/deadparrot/108/homer.gif" alt="Homer" align="center"> Design Engineer adr;quoted-printable:;;2100 Logic Drive=0D=0ADept. 2510;San Jose;CA;95124-3450;USA x-mozilla-cpt:;25776 fn:<H3 ALIGN="CENTER">Brian Philofsky end:vcard --------------07282AF9ACBFC3713783D9E7--Article: 18996
Michael, Thanks for the advice. I'm still having problems. We didn't design the board which is one of the problems. One thing I noticed is that you guys put the config pins on "000" for configuration. We put them on 101 for "JTAG mode" I thought that is what it had to be on to config through the JTAG port. Again, the JTAG programmer software says that the device is programmed, but it is like the device never goes through it's startup sequence. DONE never goes high. When I have access to the board again, I'll try configuring with the pins on "000". The other thing I noticed is that you mention the program pin. We don't manipulate this pin. Should we??? You mention that it is for PROM configuration. Again, we are trying to program via JTAG. Should we have to pull the PROGRAM pin low and then let it go high to program via JTAG??? Tom > > > Hi Tom, > > We'v done JTAG configuration of virtex > XCV300 with XChecker and also with a > selfmade interface for parallelport > (Application Note Xilinx). There were no > problems. I think the pullup on init is > ok (we have the same). > I will tell you the other configuration > pins for orientation: > >Article: 18997
Xilinx has an appnote xapp131h.zip that seems to have both. I have not used it yet. In article <3839CF63.2544310F@arl.wustl.edu>, Michael G Wrighton <mgw1@arl.wustl.edu> wrote: > Hi, > We're in need of a FIFO implemented with the Virtex's Block RAM. I've > found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block > SelectRAM+" available from the cores page. This is precisely what we > need except for that it is written in Verilog and our environment is > VHDL. I'd be willing to try this co-simulation trick to integrate the > two languages, but I wonder if anyone knows of a VHDL version of this > freely available. Also, I've heard the mixing VHDL and Verilog can > result in some pretty hairy problems. Any comments on that front? > > Thanks, > MGW > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18998
Ray Andraka <randraka@ids.net> writes: >parts. It's kind of a cross between an RCA 1802 (anyone remember those things?) I remember them, though I never used one. THere are also come CDP1802's somewhere near jupiter right now. Maybe someone from JPL who reads this will fill in the details. -- glenArticle: 18999
On Tue, 23 Nov 1999 07:46:42 -0500, Ray Andraka <randraka@ids.net> wrote: > > >John Larkin wrote: > >All good comments, well except for this one: > >> |5. We don't simulate, so that aspect of HDL is not useful to us. We >> just design carefully, compile, and test. After all, it IS an FPGA, >> and not a piece of silicon that will take six weeks and $100K to >> change. When we do find a problem, the cause is generally (almost >> always) right in front of our faces on the schematic, so we fix it >> quickly. > >I wouldn't dream of sending a design to a customer without first simulating >it. I intensely dislike the politics of being in the Lab. Some time spent >in simulation makes sure that the design works the first time, and more >importantly that you have an opportunity to check all the boundary >conditions. How long do you spend in the lab debugging? Ray, Since you deliver designs, you need to know that they are correct. If you mess up, your customer gets hurt and that's obviously bad for your business. Our situation is different, in that, around here, one or at most two engineers do an entire design, and the customer sees only the finished product. And the lab is just down the hall and is politics-free. Testing and debug are in fact often social occasions... everybody wants to see how the latest widget is coming along, and everybody has ideas when there's a problem. 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. John
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