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
Magnus Homann wrote: > > Color me stupid, but: > > What exactly is schematic entry (as opposed to VHDL)? > > Is it like it sounds, you draw a schematic with a couple of OR, AND > and NOT? Sounds tedious to me, but some people seem to prefer it to > VHDL. > > Anyway, I have simple design in an ispLSI1032E (Lattice PLD). A couple > of statemachines and some counters. Add a PCI arbiter etc. Reasonable > enough in VHDL. > > Would it be just as easy to do this with schematic entry and hand > placement? I would like to get some insight into "the other side of > the Force". > > Thankfully, > Magnus Homann > -- > Magnus Homann Email: d0asta@dtek.chalmers.se > URL : http://www.dtek.chalmers.se/DCIG/d0asta.html > The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html Yes, schematic entry is exactly what you think. And since you seem to be at a university, I'll color you young, not stupid. From an historic standpoint, designers had absolute control of the implementation because you only got things like four two input nand gates in a 14-pin DIP. Schematics, complete with pin numbers on each gate leg, were then turned into PWBs. As we progressed into PALs and FPGAs, we retained the schematic entry approach because it was what we knew and a trained eye could trace through a design quickly. The disadvantage was that each manufacturer had their own libraries of parts and shapes. Then along came the US government in the mid 80's with the VHSIC program, which served to light a fire under the industry's collective ass and forced everybody to make denser, faster, more reliable ICs. The only surviving part of that program was a unified hardware description language (VHDL) that was devised to allow one descriptive file to port to anybody's manufacturing process. I still do schematic entry on occasion for small devices that are not supported by my company's synthesis setup, but for larger FPGAs, I've made the transition to VHDL. For me, the big advantage is that I can "design" at any PC or work station with an ASCII text editor. IMO, schematic entry is still the way to get gate level control of a design if you need to wring that last nanosecond out of the path, but it is definitely not a transportable design in that form. -- Dave P. (to reply, remove *nospam* from the e-mail address) "A man who carries a cat by the tail learns something he can learn in no other way" --Mark TwainArticle: 12476
Hi - On Mon, 12 Oct 1998 22:09:09 GMT, ems@nospam.riverside-machines.com wrote: > (1) virtex devices are, for an fpga, BIG. the web site talks about > size ranges from 250K-1M gates, within the next few months. We're in agreement here; them's big chips. > (2) IMHO, it seems extraordinary that anyone would consider shipping > one of these devices, with only the benefit of a gate level simulation > carried out in either viewsim or foundation. Why do you find it extraordinary? Granted, Verilog and VHDL are great for test bench building, and you don't have to simulate at gate level. But before you conclude that Viewsim is unfit for large-design verification, you may want to talk to Philip (the guy you responded to) about the over 250 designs he's delivered. That work. That were verified with Viewsim. And that his customers are very happy with. And we're not talking small, simple designs, either; some of them are huge. PHILOSOPHICAL MUSINGS TO FOLLOW: Before I started consulting, I managed a digital design organization that included a CAE group. I very much enjoyed helping select new CAE tools. And why not? Some of these programs are mighty neat. But then I began to realize that some of the most productive engineers were those who selected a few stable tools and became, over time, extremely proficient in their use. And that's the key: you can't become an expert tool user if you're changing tools every two weeks, or if the vendor is making significant changes to the tools or the flow every release. (It got to the point that when vendors told us they were making major changes to their tools in the interests of ease-of-use, I'd tell them, "I'm not sure we can survive another productivity improvement.") If someone becomes really good at using a tool that others consider archaic, should that someone move to another tool? Why? That's the point underpinning Philip's post: he's got a toolchain that he's extremely proficient at using, that produces solid, repeatable results, but which is no longer supported for a new device family. What's more, as he points out, the effort to provide the Viewsim support would be minimal, since much of what's needed could be taken from existing libraries. This isn't a slam against Xilinx, by the way; all CAE vendors grapple with the what-do-we-drop-and-what-do-we-keep issue. I'm sympathetic, but wish they would reconsider. END OF PHILOSOPHICAL MUSINGS. > (3) given this, the fact that neither foundation nor viewsim can > currently carry out functional simulations on virtexes seems > irrelevant. I don't agree on (2), so I can't give you this one. (And how did Foundation sneak into this discussion, anyway?) > (4) anyone paying for a virtex design, unless they've got a lot more > money than sense, will want a proper simulation. it therefore seems > sensible to take the advice on the website, and to carry out your > simulation in an HDL. to do this, write a VHDL testbench, and > instantiate the VHDL gate-level netlist produced after implementation. > it may or may not be possible to carry out 'functional' simulations, > depending on whether behavioural models of the library components are > available. this isn't ideal, but you'll have to put up with it if you > want to use schematics on a 1M-gate device. A "proper" simulation is one that thoroughly verifies the functionality of the device. I can understand why someone may prefer an HDL simulator over Viewsim, but what makes Viewsim inherently incapable of doing the job? Sure, it's old, and it's not as spiffy as some of the newer stuff. Well, a lot of us fall into that category, but we're still useful members of society. >> I don't care about timing simulation. (It is pointless anyway, but >> I wont clutter up this article with explaining why). > it's not pointless. it isolates a class of problems which cannot be > found by static analysis, and for which timing constraints cannot be > relied on to eliminate. I've used static timing analysis exclusively. In fact, I worked with a team of designers on a project that had on the order of ~150 FPGAs and CPLDs per system. The functionality was verified by unit-delay simulation, the timing with static timing analysis. This system ships in large quantities, yet I can't think of a single problem we uncovered in debug or production that would have been revealed by timing-accurate functional simulation. What kinds of problems are you referring to? We're talking synchronous design, I hope. Regards, Bob Perlman Cambrian Design WorksArticle: 12477
Hi, I am looking for suggest or recommendation for a VHDL editor. Some of the features that I would like to have are the following: 1) Color coded keywords 2) Test bench generation 3) Built-in hierarchy browser 4) Auto completion by typing only a few characters 5) Independent of any Synthesis or Simulation tool Thank you in advance.Article: 12478
bob@nospam.thanks (Bob Perlman) wrote: <snip> >But then I began to realize that some of the most productive >engineers were those who selected a few stable tools >and became, over time, extremely proficient in their use. >And that's the key: you can't become an expert tool user >if you're changing tools every two weeks, or if the vendor >is making significant changes to the tools or the flow every >release. (It got to the point that when vendors told us >they were making major changes to their tools in the >interests of ease-of-use, I'd tell them, "I'm not sure we >can survive another productivity improvement.") If someone >becomes really good at using a tool that others consider >archaic, should that someone move to another tool? Why? Agree 100% with you on this. In the past just about every project that I worked on has required some new tool. In the end, though, they all pretty much do the same thing. In the long run, it's best to find tools that will last awhile. This not only reduces learning curves, but also allows a high degree of reusability. It's cheaper too! Wade Peterson Silicore Corporation http://www.silicore.net/Article: 12479
Hi,
There are really three praticed ways of generating a sine wave.
These methods I have encountered over the a number of years
in the DSP field. These methods are for a fixed, apriori
frequency.
1.) Use a LUT where the number of terms is related to the
frequency you desire.
2.) Use a reduced number of LUT proportional to the frequency
you wish, and then interpolate. Actually some great papers using
bipartite tables and interpolation have been used similar to this by
D. D. Sarma and D. Matula.
3.) Use a resonator. A resonator uses a feedback loop with
a zero for the pole. Back in the 80's this was the preferred method
of generating the DTMF tones for phones. I am sure they use
derrivates of this today.
CORDIC works well because of the compactness of the code but it
is mainly meant for generating sine and cosine (and of course other
elementary functions w/modifications) for a given angle.
There are many other methods. However, the ones above are the ones
taught in most DSP classes. I am sure they go hand in hand with FGPA's
or ASIC's. I hope that helps a little.
Take care and have a great day!
James Stine
Lehigh University
jes6@eecs.lehigh.edu
Yves Vandervennet wrote:
> Hi everybody,
>
> does anybody know how to digitally realize a sine generator
> other than sampling a sine period and storing it in a ROM ?
> We have to integrate it in an FPGA. If anybody knows book references
> on this subject, we would be happy for a very long time.
>
> See you soon on the Web,
>
> Yves.
Article: 12480fliptron@netcom.com (Philip Freidin) wrote: >FOCUS FOCUS FOCUS > >The title of the thread is (was till I started this one): > > "Xilinx may not support schematics for Virtex?????" > >It's a real BIG issue for some of us. And this might be the >forum to find out how many people it is an issue for. This >could then lead (assuming there is sufficient outcry) to a >vendor or two fixing the problem. > >. . . .Snip long post. . . . Here's what I know about this topic: Last Wednesday, I was in a meeting with attendees from Xilinx, Viewlogic, Viewlogic's local Rep, a local consultant, and another engineer from my company that does FPGA designs. (Diablo Research has about 9 or 10 ViewDraw/ViewSim/Xilinx PC seats) The subject was 'ViewSim can not simulate Virtex.' The salesman from ViewLogic wanted our opinion on purchasing (possibly discounted) SpeedWave from Viewlogic as a solution to the lack of support for Virtex with ViewSim. We were not very receptive and made it clear that HLDs will not be useful for fast, or dense FPGA designs, until they include hierarchical floorplanning controls, like schematic capture tools have now. We users also emphasized that we have developed a set of tools and a flow that works, and did not like being told we had to change them. 1) The problem seems to be that Xilinx maps everything to LUTs and Flops, in Virtex, for back-annotated timing simulation. For some reason, this makes timing simulation, of schematics, impossible. Since timing simulation was impossible, Xilinx decided not to support functional simulation either, so did not bother to make the simulation models for any of the Virtex primitive components. 2) The 4000 series libraries work for Virtex, and, in fact, a design could be schematic captured, simulated and targeted toward Virtex using the 4000 series libraries. But the Carry logic is different and couldn't be used, and none of the new capabilities of Virtex would be available (Shift register RAM, Block RAM, and all the new I/O level support). 3) I don't see much difference between Virtex LUTs and 4000 series ROMs. We all know that ViewLogic does not simulate INIT Attributes on ROMs. Since we have been able to designs without any significant problems with the XC4000 ROMS, it seems reasonable that the LUTs are no bigger an issue, at least for functional simulation. 4) Xilinx could supply the unit delay simulation models for Virtex fairly easily since most of the models could simply be copied from the 4000 series libraries. They would have to deal with LUTs, but it seems to me, LUTs are the same as ROMs. 5) ViewLogic could improve things by adding support for the INIT attribute on ROMS. Basically they would need to auto load the ROM simulation model with the value of the INIT attribute. 6) If Both Xilinx and ViewLogic implemented the above. We would be able to do functional simulation of 100% of Virtex, and as an added benefit, would be able to properly simulate 4000 series ROM INIT Attributes. 7) We users all strongly encouraged these two Industry Giants to go away and do the right thing. 8) We were not given any promises, except that they would get back to us. Dave Decker, Diablo Research Co. LLC. Dave Decker Diablo Research Co. LLC Please use only one 'h' in mush. I'm trying to reduce the spam. "Animals . . . are not brethren they are not underlings; they are other nations, caught with ourselves in the net of life and time, fellow prisoners of the splendor and travail of the earth." Henry Beston - The Outermost HouseArticle: 12481
Hi Again, A good reference is the DSP Laboratory by Prentice Hall and I believe John Proakis from Northeastern University. Another good reference is Oppenheim and Shaffer classic DSP text book or Mannolakis (sp? sorry) and Proakis DSP text book. Alot of the elementary function generation stuff for logic can be found in Computer Arithmetic edited by Dr. Swartzlander from University of Texas at Austin and Dr. Koren's book Computer Arithmetic Algorithms. The book edited by Dr. Swartzlander's has the classic articles from Volder on CORDIC and extensions of CORDIC for most elementary functions by Walther. A new text book recently published by Jean Michele Muller is an excellent text on Elementary Functions. I think the publisher is Birkhauser (sp?) from Boston. And of course, all the Arith conferences and the book by Cody and Waite book on the Software Manual for Elementary Functions. These are just a few of the references. But, they may get you started. Take care and have a great day! James Stine jes6@eecs.lehigh.edu Yves Vandervennet wrote: > Hi everybody, > > does anybody know how to digitally realize a sine generator > other than sampling a sine period and storing it in a ROM ? > We have to integrate it in an FPGA. If anybody knows book references > on this subject, we would be happy for a very long time. > > See you soon on the Web, > > Yves.Article: 12482
IIRC, and for what this is worth, the U.S. Capstone chip (a silicon implementation of the then-classified Skipjack algorithm) used a general purpose processor running a program from an on-chip ROM which was made up with antifuses. This enabled the chip to be manufactured in a nonsecure facility, and the antifuses programmed in a secure facility. So antifuses can't be that bad. > I think antifuses aren't visible optically since a programmed >conductive antifuse differs from a non-conductive one only by a small >diffusion surface. That might be the advantage of antifuse FPGAs over >ASIC ICs. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 12483
It is rare to have a 30-page schematic, unless the designer was really incompetent. I have done designs up to 10k gates, and the cct was ~ 5 pages, each A1 size. A1 pages print fine (readable) reduced to A4 on a 600dpi printer. The long term trend, however, runs away from taking care to draw circuits **neatly**, and this is IMO one of the (other) major factors driving towards HDLs - you can just sit there and lazily type it all in. The vast majority of hardware engineers cannot draw a circuit neatly, IME. >Funny, I find a 30 page schematic hard to read. At least if I wasn't the >one to enter it. I've never met a designer yet that produced a clear >schematic for a complex design that didn't take some getting used to. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 12484
I am not sure if this is somehow equivalent to CORDIC but there is a method involving a feedback shift register (like in a CRC generator) and use weighted resistors coming off some of the outputs. There is a book called CMOS Cookbook (mine is 1978) which contains the details. I suspect CORDIC is another name for computing the Horn algorithm which is used to draw circles in most graphics chips. >Hi everybody, > > does anybody know how to digitally realize a sine generator >other than sampling a sine period and storing it in a ROM ? >We have to integrate it in an FPGA. If anybody knows book references >on this subject, we would be happy for a very long time. > >See you soon on the Web, > >Yves. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 12485
Anybody know if its possible to do a gray code counter in a Xilinx 4000xl fpga using the fast carry? I would like a 100mhz, 24 bit free running counter, but might be able to live with 50mhz. Maybe at 50mhz I wouldn't need fast carry??? Thanks DanArticle: 12486
Arthur Agababyan (arthura@sun52a.desy.de) wrote: : I want to start to design my own digital systems usind FPGA. : So far I have been mostly engaged in software design. So, : which books you could advise me to read. I have no experience : of either PLD or FPGA. I shall be very thankful if you mention : a few good books on digital design too. Since you are native German: "Das FPGA-Kochbuch", MITP-Verlag, 79 DM, 1998. List of contents, test readings, updates, etc.: http://www.fernuni-hagen.de/IT/FPGA/kochbuch Markus Wannemacher (ja, ich bin der Autor, empfehle das Buch aber trotzdem ;-)Article: 12487
Pacem wrote: > > Hi, > > I am looking for suggest or recommendation for a VHDL editor. Some of the > features that I would like to have are the following: > > 1) Color coded keywords > 2) Test bench generation > 3) Built-in hierarchy browser > 4) Auto completion by typing only a few characters > 5) Independent of any Synthesis or Simulation tool > > Thank you in advance. i suggest you look into Intrinx's Esprimo 6 (used to be called Sledgehammer) at www.vhdl.com. from what i understand, it's based on the Visual SlickEdit but has a few more bells and whistles. Namely, the functions you mention in your requirements list. you might also look into premia's codewright at www.premia.com. it's a very good, very configurable editor that can do everything you ask for except testbench generation. it's set up to edit most common software languages (c/c++, basic, perl, html, etc..) but a DLL is available that lets it speak VHDL. in addition, it emulates several other editors (vi!) so you can get all the features of codewright withou having to abandon you old faithful. hope this helps. .mj.Article: 12488
Dear colleagues, of course antifuses in Actel's FPGA fully invisible in any optical Microscope. The matter is that programming is not destroy the upper poly silicon layer which forms one of antifuse electrode. So, in optical microscope with immersion objective you don't see any differences between pro- and unpro- fuses. The electronic beam microscope also does not differ the pro- and unpro- fuses, because of absence of any float charge in the cell. It's not a EEPROM cell! But the more wonderful thing is that during work currents charging internal capacitances only(!) improve the quality of contact through programmed antifuse, what we can't say about any cells with floating gate. RomanovskyArticle: 12489
Yes, We studied DES on FPGAs in great detail. Here is an overview of our result: encr. rate CLBs used chip 99Mb/s 262 XC4008 184Mb/s 433 XC4013 402Mb/s 741 XC4028 The first one is a plain DES architecture, the other ones have two and four pipeline stages, respectively. All designs were done using a VHDL description. For more details, please refer to our SAC '98 paper which can be found as postscript file on our web site. Go to http://ece.wpi.edu/Research/crypt and click on the "Recent Publications" link. Check also Jens-Peter Kaps' MS thesis which is on the web too. Regards, Christof Bill Seiler (ccwest@ix.netcom.com) wrote: : Anyone done the Data Encription Standard in an FPGA? : Verilog would be best. : : Bill Seiler : ccwest@ix.netcom.com : : -- ************************************************************************* Christof Paar http://ee.wpi.edu/People/faculty/cxp.html Assistant Professor email: christof@ece.wpi.edu Cryptography Group phone: (508) 831 5061 ECE Department, WPI fax: (508) 831 5491 100 Institute Road Worcester, MA 01609, USA *************************************************************************Article: 12490
I don't believe you can do what you want.... A four bit Grey counter for example: 0000 0001 0010 0110 0111 0101 0100 1100 1101 1111 1110 1010 1011 1001 1000 The concept of carry, as the xilinx implements it, only works for sequential counters, that have some accumulation to base the subsequent carry bits on as they trickle the carry bit up the carry chain....and they are single bit carrys. Grey counters are usually implemented as decoders.... where a particular input gives a particular output, and you register the output... Having a 24 bit decoder is really a lot of decoding, as you have to decode every 'count' to get to the next one...since you are expecting 24 discrete 'counts'. What you could do, is implement a 4 bit Grey counter (fits in one four FMAPs).....and decode the top state (1000 - using one additional CLB, so 5 FMAPs and four flops per 4 bit 'slice') and use it as the CE the next 4 bit 'slice'. For 24 bits, you would need 6 'slices'. That would be 30 FMAPs and 24 flops is 15 CLBs for for your 24 bit counter. My guess is you could easily run at 50MHz if you mapped and relationally placed it. Austin Franklin darkroom@ix.netcom.com Dan Kuechle <dan_kuechle@i-tech.com> wrote in article <01bdf6cf$53cc4100$1f38d926@dank.i-tech.com>... > Anybody know if its possible to do a gray code counter in a Xilinx 4000xl > fpga using the fast carry? > > I would like a 100mhz, 24 bit free running counter, but might be able to > live with 50mhz. > Maybe at 50mhz I wouldn't need fast carry??? > > > Thanks > Dan >Article: 12491
Check out www.viewlogic.com for some great VHDL simulation and synthesis
tools:
Fusion/SpeedWave for VHDL simulation
FPGA Express for FPGA synthesis
John Huang wrote:
> John Huang g峹 ...
> >Hi:
> > I am looking for a good VHDL synthesis and simulation tool,
> >I hope it has fine timing simulation function, and price is lower
> >than 6000 dollars, it must do multi-vendor FPGAs,
> >please tell me which is the best fit for me
> >
> >
> >Thanks
> >
> >John Huang
> >
> >
--
*-------------------------------------------------------*
* John Willoughby W ECrC *
* Verification Marketing office: 508-303-5238 *
* Viewlogic Systems mobile: 508-254-9608 *
* 293 Boston Post Rd West fax: 508-460-7826 *
* Marlboro, MA 01752 email: jww@viewlogic.com *
* *
* "Well done is better than well said" - Ben Franklin *
*-------------------------------------------------------*
Article: 12492Austin Franklin wrote: > > I don't believe you can do what you want.... > > A four bit Grey counter for example: > > 0000 > 0001 > 0010 > 0110 > 0111 > 0101 > 0100 > 1100 > 1101 > 1111 > 1110 > 1010 > 1011 > 1001 > 1000 > > The concept of carry, as the xilinx implements it, only works for > sequential counters, that have some accumulation to base the subsequent > carry bits on as they trickle the carry bit up the carry chain....and they > are single bit carrys. Austin, You are right that the Xilinx carry can't be used for a Gray counter (at least as far as I know), but I think for the wrong reason. I believe you can do a Gray counter with a carry. This was actually beat to death a while back in this newsgroup. I will try to remember some of the useful details. First your sequence is not a valid Gray code. The second and third numbers have two bits that change between them, maybe you just left out a code. Here is the complete table. 0000 0001 0011 0010 0110 0111 0101 0100 1100 1101 1111 1110 1010 1011 1001 1000 Someone had posted that bit n toggles when you have two conditions together. First bits n-1 to 0 form the pattern 100...0. Secondly bit n+1 must be the same as bit n. The exceptions to this rule are bit 0 and bit N-1. Bit 0 simply toggles every other count and bit N-1 will toggle when bits N-3 to 0 are all 0 and bit N-2 is different from bit N-1. So bit 0 can be handled by adding a bit -1 which always toggles just to tell bit 0 when to toggle. Bit N can be done just by changing the logic as compared to the others. This is a bit of an unusual structure compared to the standard counter carry chain of c(n) = 1 when c (n-1) downto 0 are all 1. But it can be constructed as a carry chain in an ASIC. The problem with fitting it into a Xilinx is that bit n needs the carry out of bit n-2 instead of bit n-1. It also then needs the output of bits n+1, n, and n-1. As you can see that makes 4 inputs which would otherwise fit very well into a Xilinx F-Gen. I don't know a lot about the 5200 series. They use two CLBs for counters and adders, I believe. There may be a way to warp the XC5200 carry chain to perform this. Of course, this can be done in discrete logic without using the fast carry chain. It will be somewhat slower, but a lookahead approach will speed it up. If 100 MHz is needed then I think you may be out of luck. But certainly 50 MHz can be done in 24 bits. My estimate (guess) is that it would take about 1 1/2 to 2 CLBs per bit or less than 50 CLBs for 24 bits. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 12493
Rickman <spamgoeshere4@yahoo.com> wrote in article <3623C5D6.27BD374C@yahoo.com>... > Austin Franklin wrote: > > > > I don't believe you can do what you want.... > > > > A four bit Grey counter for example: > > > > 0000 > > 0001 missing 0011 > > 0010 > > 0110 > > 0111 > > 0101 > > 0100 > > 1100 > > 1101 > > 1111 > > 1110 > > 1010 > > 1011 > > 1001 > > 1000 > > > > The concept of carry, as the xilinx implements it, only works for > > sequential counters, that have some accumulation to base the subsequent > > carry bits on as they trickle the carry bit up the carry chain....and they > > are single bit carrys. > > Austin, > > You are right that the Xilinx carry can't be used for a Gray counter (at > least as far as I know), but I think for the wrong reason. I believe you > can do a Gray counter with a carry. Not with a carry per bit.....which is how the Xilinx carry logic does it... I believe you can do it with A carry, but the question was can you do it using the XILINX carry.... > This was actually beat to death a while back in this newsgroup. I will > try to remember some of the useful details. > > First your sequence is not a valid Gray code. Sorry, it would have been if one number wasn't missing...see above... The original table only had 15 entries...somehow I must have deleted one when copying it in. I believe what I have above is a valid gray counter with the missing number inserted. AustinArticle: 12494
The conversion from binary to Gray code is not too bad. The best solution might be to implement a fast binary counter, then convert the binary to Gray. I can post the algorithm to convert binary to Gray if necessary. If the output code is not important, and high speed with low EMI is the goal, perhaps a LFSR counter is the answer. What's the design goal?Article: 12495
ok. i'm stuck in a hotel room all night, so i'll take the bait - why do i think that you *can't* do a good job of simulating a large design, such as a virtex, with viewsim, or aldec's look-a-like, and why *can* you do a much better job with vhdl? note that i'm not going to pontificate about the relative merits of schematics and vhdl - the problem here is only in the simulation part of the cycle. there's no reason why you can't simulate a schematic-only design in vhdl. first of all, i'm no expert at viewsim. i've simulated one design in viewsim, and another 4 using aldec's compatible syntax, at which point i learnt vhdl instead. if i've made a mistake with viewsim's capabilities, then please correct me. the code below is a random extract from one of my viewsim/aldec CMD files, for anyone who hasn't seen one of these: (after 20ns do (assign SE0 1); after 40ns do (assign SE0 0); cycle 1; + after 20ns do (assign SE0 1); after 40ns do (assign SE0 0); cycle 1; + cycle 3; check S2PSTB_H 1; + cycle 43) * 14 your line wrapping will probably be different from mine - the '+' characters are the line terminations. in this code there's a linear sequence of delays, specified by 'after', assignments to signals or buses, using 'assign', output checks, using 'check', clock cycles, and a possible repeat construct, using (...)*n. the only significant complication on top of this basic structure is that you can read sequences of numbers from a file, to use in your 'assign' and 'check' statements, but only in a very limited manner. other points to note: 1) there's no macro capability. if you have a sequence of events that you have to carry out frequently, such as the actions required to load a control register, for example, then you have to explicitly repeat every single statement every time it's required. 2) checking for errors is very difficult. you get lots of messages on the screen, and buried in them you may find that a notification that a check statement has failed. 3) there's no decision-and-branch capability. viewsim is *not* a programming language; it mandates a linear execution of statements, with the maximum complexity being the brackets-and-fixed-number-of-repeats construct. 4) it's *incredibly* wordy, and it's next to impossible to maintain a complex script. 5) timing is very inflexible. modifying something early on in a script can lead to situations where subsequent checks fail, because the relative timing has changed. 6) all these limitations mean that you frequently have to resort to actually looking at waveforms in the display, to see if something has worked. even worse, you occasionally have to actually manually change a waveform value. in short, the term 'mickey mouse' was invented specifically for this sort of simulation. again, please correct me if i've misunderstood viewsim. now here's why you may want to use vhdl instead. 1) you can model components around your design. you can put in a processor, or a fifo, or whatever. 2) you can interact with your design; there's two-way communication between the testbench and the DUT. if your DUT writes data X to address Y in a SRAM device, then it can later read back data X from address Y. 3) you can use exactly the same testbench to test different abstraction levels of your design. you can test your behavioural concept, if you have one, you can test your RTL code, you can test your mapped design, you can test your routed design. you can even do a timing simulation on your routed design, all with the same testbench. 4) it's easy. it's much easier to write a complex testbench than to write a complex viewsim script (but, of course, much harder to learn). 5) vhdl is a programming language. you can make decisions, change control flows, whatever. you can read and write arbitrary files. you could read a file containing processor opcodes, for example, parse them in your testbench, and do something to your DUT as a result. 6) vhdl is concurrent. you can start clocks running, and have lots of things going on at once, independently. you're not restricted to the linear assign-cycle-check sequence of viewsim. 7) vhdl is stable, more or less. tools may change, as you point out, but that's not relevant. there have been minor syntax changes over the last decade, but i bet people will be using vhdl long after viewsim is deservedly buried. 8) you can write self-checking testbenches. the testbench could, for example, read stimulus from a file, apply it the DUT, check the results against a different file, and report a pass/fail on completion, together with appropriate error messages. and what do the asic vendors think? is viewsim a sign-off simulator? hardly. i use modelsim, among others, and it is. even if i ignore the issue of test vector coverage when writing my testbench, there's still a good chance that i'll 70%+, even without trying. i can then modify my testbench to get close to 100%. what sort of coverage could a viewsim script achieve? i don't know - maybe 'minimal' is the answer. in short, if you've got a small-ish design, and you think that you're good enough that you don't need a comprehensive simulation, then you may be ok with viewsim. alternatively, if you're frequently re-using your own IP modules, with little extra logic, you may also find viewsim to be good enough. if, on the other hand, your designs are starting to look like asics, then perhaps you should be using asic methodologies. evanArticle: 12496
Hi, The shift register you mention could be the Goertzel algorithm and other forms of using zero poles which I talked about in my previous post using feedback. I am not sure about the Horn algorithm, but I would be very interested in what it is. There is Horner's algorithm and also another one by an author's last name Horna, but more info on Horn would be very interesting. CORDIC is very popular and is the original algorithm used in early calculators and the 8087. James Stine jes6@eecs.lehigh.edu Peter wrote: > I am not sure if this is somehow equivalent to CORDIC but there is a > method involving a feedback shift register (like in a CRC generator) > and use weighted resistors coming off some of the outputs. There is a > book called CMOS Cookbook (mine is 1978) which contains the details. > > I suspect CORDIC is another name for computing the Horn algorithm > which is used to draw circles in most graphics chips. > > >Hi everybody, > > > > does anybody know how to digitally realize a sine generator > >other than sampling a sine period and storing it in a ROM ? > >We have to integrate it in an FPGA. If anybody knows book references > >on this subject, we would be happy for a very long time. > > > >See you soon on the Web, > > > >Yves. > > -- > Peter. > > Return address is invalid to help stop junk mail. > E-mail replies to zX80@digiYserve.com but > remove the X and the Y.Article: 12497
I saw an Altera apps note on FFTs on their web site.
If you can do a 1D then the 2D is an extension of that
but with a different addressing scheme.
You'll need enough external RAM to store the entire image in but
apart from that there shouldn't be any problems.
Note you probably won't manage real time performance (30 fps)on a mid sized
image.
Some number from the top of my head.
512 x 512 image - 262144 point FFT (2^18)
or
512 x 512 point FFT x 2 (columns/rows).
A ball park figure here is
18 passes of 256 K points.
This is about 4.5M clocks per image. - Note this ignores windowing and
assumes
data is available & writable in a single cycle.
Clocked at 70Mhz depending on the external architecture assuming only 1 FFT
engine
per chip you may get 15 fps.
The next trick is to use this data for something useful, such as optical
flow analysis etc.
Any comments on any of the guesstimates anyone ?
Andy
tom sutherland wrote in message <6u8puc$otu$1@hammer.msfc.nasa.gov>...
>Is it possible to implement a 2D-FFT on a image using an ALTERA FLEX 10K ?
>I am digitizing a camera input and can pass the data through a FPGA. The
FPGA
>has internal ram and also external ram available for storage.
>Thanks....
>
Article: 12498HTTP://www.vautomation.com Simon Bacon wrote: > > To decide between a processor core and dedicated logic, does > anyone have an indication of the price range for the various > processor cores available for FPGA targets? -- Eric Ryherd eric@vautomation.com VAutomation Inc. Synthesizable VHDL and Verilog Cores 20 Trafalgar Sq. #443 http://www.vautomation.com Nashua NH 03063 (603) 882-2282 FAX:882-1587Article: 12499
> if i've made a mistake with viewsim's > capabilities, then please correct me. I believe you're mistaken. > > 1) there's no macro capability. if you have a sequence of events that > you have to carry out frequently, such as the actions required to load > a control register, for example, then you have to explicitly repeat > every single statement every time it's required. Not so. You should be doing hierarchical command files. You can use the command 'execute filename' to 'call' another command file. It's not exactly a 'macro' but it is a way of having a main cmd file that you can make different tests from by just creating sequences of execute statements. > 2) checking for errors is very difficult. you get lots of messages on > the screen, and buried in them you may find that a notification that a > check statement has failed. Once you have a simulation that you have verified works correctly, you can output a list of vectors to a file, and then when you run it again, compare them and it will report errors if the values differ. > 3) there's no decision-and-branch capability. viewsim is *not* a > programming language; it mandates a linear execution of statements, > with the maximum complexity being the > brackets-and-fixed-number-of-repeats construct. That's not exactly true. It supports VHDL modeling, and any time I need a bus functional model, I do it in VHDL, which VHDL is a great simulation language. > 4) it's *incredibly* wordy, and it's next to impossible to maintain a > complex script. Now that's getting silly, especially coming from someone purporting to write VHDL. From your Viewsim example above, I understand you really don't know Viewsim very well. As with ANY good programming, I keep my files short and modular, and as I said just 'execute' them to create simulation sequences. > 5) timing is very inflexible. modifying something early on in a script > can lead to situations where subsequent checks fail, because the > relative timing has changed. Not true. If you do your simulations cycle based, it becomes trivial to change timing. If you do absolute or relative timing, yes, you can expect to find viewsim quite difficult. But since we are talking about synchronous digital designs here, cycle based simulation is the methodology to use. > 6) all these limitations mean that you frequently have to resort to > actually looking at waveforms in the display, to see if something has > worked. even worse, you occasionally have to actually manually change > a waveform value. OK, how else do you do it, if you don't use your eyes to look to see if the simulation is working correctly? The Force? > in short, the term 'mickey mouse' was invented specifically for this > sort of simulation. again, please correct me if i've misunderstood > viewsim. Calling it names because of your lack of understanding of it is really unnecessary. A tool is only as good as your ability to use it, and from your example and questions, my guess is you don't really know how to use this tool very well. In fact, it's one of the best design and simulation environments around. > now here's why you may want to use vhdl instead. > > 1) you can model components around your design. you can put in a > processor, or a fifo, or whatever. But that's modeling, NOT design....and I (and I'm sure many others) already do many VHDL models to simulate the design. That's got nothing to do with the source OF the design. > 2) you can interact with your design; there's two-way communication > between the testbench and the DUT. if your DUT writes data X to > address Y in a SRAM device, then it can later read back data X from > address Y. And why can't I do that with Viewsim? In fact I can. What do you think, you can only do write cycles from Viewsim, and not read cycles? Your point here is funny, and I don't think what you wrote (or what I understood you wrote) is what you meant. > 3) you can use exactly the same testbench to test different > abstraction levels of your design. you can test your behavioural > concept, if you have one, you can test your RTL code, you can test > your mapped design, you can test your routed design. you can even do a > timing simulation on your routed design, all with the same testbench. You can do ALL these with Viewsim. > 4) it's easy. it's much easier to write a complex testbench than to > write a complex viewsim script (but, of course, much harder to learn). Again, if you are proficient in Viewsim, this is not a problem. I disagree it's much easier. It is probably the same. I just copy previous cmd files I created, modify them, and I can simulate. Not so tough. > 5) vhdl is a programming language. you can make decisions, change > control flows, whatever. you can read and write arbitrary files. you > could read a file containing processor opcodes, for example, parse > them in your testbench, and do something to your DUT as a result. What's the point? Somewhere something has to change for the simulation to change? You have to change the inputs/sequence of inputs to change the outputs/sequence of outputs. If your designs do something different with the same inputs, there is something wrong with the design. > 6) vhdl is concurrent. you can start clocks running, and have lots of > things going on at once, independently. you're not restricted to the > linear assign-cycle-check sequence of viewsim. And I can do that in Viewsim too. I run many clocks concurrently. Yes, only one can be the main cycle based clock, but I have yet to have any problem with that. > 7) vhdl is stable, more or less. tools may change, as you point out, > but that's not relevant. there have been minor syntax changes over the > last decade, but i bet people will be using vhdl long after viewsim is > deservedly buried. This is quite arguable. But I'm tired of these groping points. If you like VHDL, and are proficient in it, good for you. But don't belittle someone else's testing methodology because you don't know how to use it. > 8) you can write self-checking testbenches. the testbench could, for > example, read stimulus from a file, apply it the DUT, check the > results against a different file, and report a pass/fail on > completion, together with appropriate error messages. As you can with Viewsim...... > and what do the asic vendors think? is viewsim a sign-off simulator? In fact, yes. > hardly. Funny, I've done about a half of a dozen ASICs with Viewdraw/Viewsim. I know a lot of other people who have too. > i use modelsim, among others, and it is. even if i ignore the > issue of test vector coverage when writing my testbench, there's still > a good chance that i'll 70%+, even without trying. i can then modify > my testbench to get close to 100%. what sort of coverage could a > viewsim script achieve? i don't know - maybe 'minimal' is the answer. Wrong. If you write your simulations correctly, whether VHDL or Viewsim, you will get as much coverage as you get, and it won't be different because you used VHDL or Viewsim. > in short, if you've got a small-ish design, and you think that you're > good enough that you don't need a comprehensive simulation, then you > may be ok with viewsim. You have yet to clarify what more comprehensively you can do with VHDL. The answer is NOTHING! If you know what you're doing with Viewsim, you will get as good a simulation as you can with ANY other methodology. > if, on the other hand, your designs are starting to look like asics, > then perhaps you should be using asic methodologies. And that's not the point either........ You just don't get it. I'll restate it here for clarity. If you like VHDL, and are proficient in it, good for you. Use it. But don't belittle (or prohibit) someone else's testing methodology because you don't know how to use it. Austin Franklin darkroom@ix.netcom.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