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
Peter Alfke <peter.alfke@xilinx.com> wrote: > Except I got ambitious and want to modify the counter such that it can count > low frequencies, say 1 kHz, with 6 digit accuracy (in one second, not 15 > minutes), by automatically switching to period measurement. Well, Peter, HP (now Agilent Tech) has been counting to 7 or 8 digits of accuracy and resolution per second for decades. The trick is to have two counters and a separate gate timer (digital or analog). The technique is to count both the incoming signal and a reference high-speed clock, each with their own counters. You start both at the first rising edge of the unknown signal after the start of the gate time. You stop after the first rising edge of the unknown after the end of the gate time. The number of reference signal counts gives the actual measurement time. So dividing the number of unknown signal counts by the reference count and multiplying by the reference frequency gives you the unknown frequency. With a resolution of the reference frequency divided by the gate time (thus, for a 10MHz reference lab standard, 7 digits per second). No switching to period modes or whatever needed. Reading a 1kHz frequency to the milliHertz with a 1 second gate time is quite a trip. A classic use for it was a simple circuit to catch the 32768 Hz acoustic tone coming from any digital watch to such precision combined with tweaking to correct for known time drift leading to easy setting of almost any digital watch to better than 1 second per month accuracy (from RF Design, September 1979(?)). Of course, since two counters are involved, some minor switching and processing can give frequency ratio of two unknowns, etc. With the ability to phase lock a higher clock to a really precise reference signal, your Virtex should be able to blow away HP's 1970s performance. Aren't these chips fun? Jim Horn, WB9SYN/6 Happy Altera & Xilinx (ab)user PS: Thanks for your many terrific postings and ideas!!Article: 31851
Michael Zirngibl wrote: > Is there a cheap & available FPGA starterkit > that comes with VHDL software ? > > Michael Just do a search on the comp.arch.fpga newsgroup using keywords like "FPGA start kit" and you will find a number of similar questions and answers that will guide you. As for VHDL, the low-cost/free software tools from Xilinx and Altera usually include VHDL/Verilog/AHDL/ABEL/schematic tools that you can use alone and in combination to describe your designs. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 31852
Dave Vanden Bout wrote: > Michael Zirngibl wrote: > > > Is there a cheap & available FPGA starterkit > > that comes with VHDL software ? > > > > Michael > > Just do a search on the comp.arch.fpga newsgroup using keywords like > "FPGA start kit" and you will find a number of similar questions and > answers that will guide you. As for VHDL, the low-cost/free software > tools from Xilinx and Altera usually include > VHDL/Verilog/AHDL/ABEL/schematic tools that you can use alone and in > combination to describe your designs. > > - That's correct as far as it goes but what tends to let these freebies down is the lack of a decent simulator. Xilinx's WebPACK comes with a small version of ModelSIM but the 500 line limit makes it IMHO near useless. For Verilog you will want to check out the one at http://www.icarus.com, I don't know if there's a freeware VHDL sim.Article: 31853
James Horn wrote: > > Peter Alfke <peter.alfke@xilinx.com> wrote: > > > Except I got ambitious and want to modify the counter such that it can count > > low frequencies, say 1 kHz, with 6 digit accuracy (in one second, not 15 > > minutes), by automatically switching to period measurement. > > Well, Peter, HP (now Agilent Tech) has been counting to 7 or 8 digits of > accuracy and resolution per second for decades. The trick is to have two > counters and a separate gate timer (digital or analog). > > The technique is to count both the incoming signal and a reference > high-speed clock, each with their own counters. You start both at the > first rising edge of the unknown signal after the start of the gate time. > You stop after the first rising edge of the unknown after the end of the > gate time. > > The number of reference signal counts gives the actual measurement time. > So dividing the number of unknown signal counts by the reference count and > multiplying by the reference frequency gives you the unknown frequency. > With a resolution of the reference frequency divided by the gate time > (thus, for a 10MHz reference lab standard, 7 digits per second). No > switching to period modes or whatever needed. <snip> This is called reciprocal counting, and it measures both cycles and period. In the mid-scale region, using both numbers is sensible. At very high frequencies, ( > ref Clock ) the cycles count itself is sufficently accurate. However, at very low frequencies - eg 1Hz, you might want to make the display refresh time as fast as possible ( no skips/pauses ), and so could use solely the period info. -jgArticle: 31854
"Michael Zirngibl" <greenland@vr-web.de> wrote in message news:9fm9ig$892$03$1@news.t-online.com... > Is there a cheap & available FPGA starterkit > that comes with VHDL software ? > > Michael > As Dr. Vanden Bout replied, Xess has a variety of kits available at good prices--the advantage with them is the pre-arranged peripherals, documentation that could come in handy, and HW is proven. Ours have worked quite well. If you want REALLY cheap, all you really need is JTAG to program the device of your choice. xilinx's free webpack tools and a Spartan II on a Jameco JE31 breadboard (I use a 100-pin QFP to DIP adapter I made), along with their $100 parallel III cable (which you could also make yourself) is about as cheap as it gets. Plus, with this arrangement I have plenty of breadboard space to add additional circuitry. Good luck, Jeff *********************************************** Jeffrey Vallier Sr. FW Engineer Gibson Guitar Corp. GMICS Division 1283 F Old Mtn View/Alviso Rd. Sunnyvale, CA 94089 408 734 4394 ***********************************************Article: 31855
> > Again, you aren't reading what was said. I NEVER said anyone offered a FIFO > > as a product prior to 1971. I said FIFOs were used long before 1971, > > period. Argue against what I DID say, not what I DIDN'T! > > The discussion was started because Peter claimed to have developed the > industry's first FIFO. He later clarified that he meant semiconductor > industry. Correct, agreed, and understood. Then after Peter clarified that, the discussion moved to basically "history of FIFOs"...and were there FIFOs in earlier computing devices... > If people built FIFOs out of transistors, NAND gates, or whatever > before the Fairchild part, I don't see how that qualifies as a > "semiconductor industry FIFO". Anyway, the discussion has moved away from "semiconductor industry"... If you have something interesting to say about early FIFO implementations, then I'd be interested in hearing about that.Article: 31856
> > Technically, two back to back flops IS a FIFO. "Pointers" and "flags" are > > not required to be a FIFO. > > By themselves, no. It takes some specific logic to make them behave as > a FIFO. Counters are one way of doing it, but there are certainly others. Why? Double buffering IS a FIFO. First-In-First-Out...that's what happens when you double buffer. I would not call a single buffer a FIFO though. Now, I completely understand that it is common that when talking about a FIFO, it is considered to have some flag logic, like full/empty etc., but I do not believe it is required to really be called a FIFO. One could easily encode the flags in the data in the FIFO. I don't know of any strict definition of what a FIFO is required to have, except provide a First-In-First-Out function. FIFO is really a concept, more so than a specific implementation.Article: 31857
> This is called reciprocal counting, and it measures both cycles and > period. > In the mid-scale region, using both numbers is sensible. > At very high frequencies, ( > ref Clock ) the cycles count itself is > sufficently accurate. > However, at very low frequencies - eg 1Hz, you might want to make the > display > refresh time as fast as possible ( no skips/pauses ), and so could use > solely > the period info. True. However, by using the logic I described - starting on rising edge of the unknown signal and stopping the same way - you end up with just what you describe without any logic for handling special cases. For high frequencies, the unknown signal counter just collects more counts. The accuracy is now *more* than the described number of digits per second. The microprocessor that does the actual division, base 10 conversion, and display decoding can easily determine that. The low frequency case still is controlled by the gate time that hasn't changed. Of course, for *really* low frequencies (longer than the set gate time), it slows things down but so does any other period counter (which is what it has now reverted to). Of course, the timebase counter needs sufficient bits to handle the longer count time. No special cases; fully adjustable gate time / update rate. Hard to beat! When the engineers in HP's Santa Clara division showed me this (and their fully custom IC to do it) in 1979, I was impressed. With today's FPGAs, anything less in a frequency counter is a waste. Jim Horn, WB9SYN/6Article: 31858
> Hmmm, I think if you know your compiler really good (some kind of > intimate relationship ;-) then you can also get good (dense, fast) > results for cost/speed sensitve designs. Lets say 80% of the speed, Ray > Andraka would achieve with finetuning by hand ;-)) My understanding from Ray is he uses VHDL as a netlister, only because his clients want VHDL... May be that's a secret I wasn't supposed to tell ;-)Article: 31859
Michael, Burch Electronic Designs sells the B3-SPARTAN2+ low cost FPGA Prototyping Kit. < US$120 ! It has a 200K gate (!) Spartan2 device, includes a download cable, and it works with the free Xilinx Webpack software (VHDL and Verilog supported). http://www.burched.com.au/bedspartan2.html The basic unit can be expanded with the BurchED Plug-On modules, to add resources such as SRAM, 7-seg displays, LEDs and switches, PC connectors etc. All units are in stock now. Secure online ordering is available. 10-pack and bundle deals are also available. International orders are very welcome. Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easy-to-use FPGA prototyping kits! "Michael Zirngibl" <greenland@vr-web.de> wrote in message news:9fm9ig$892$03$1@news.t-online.com... > Is there a cheap & available FPGA starterkit > that comes with VHDL software ? > > Michael > >Article: 31860
On Thu, 07 Jun 2001 00:06:46 +0100, Rick Filipkiewicz <rick@algor.co.uk> wrote: [snip] >That's correct as far as it goes but what tends to let these freebies >down is the lack of a decent simulator. Xilinx's WebPACK comes with a >small version of ModelSIM but the 500 line limit makes it IMHO near >useless. For Verilog you will want to check out the one at >http://www.icarus.com, I don't know if there's a freeware VHDL sim. http://www.symphonyeda.com/ No built in waveform viewer, but you can convert its dump format to VCD (using a free conversion tool), and then use a free VCD viewer. It compiles *much* faster than Modelsim, but doesn't simulate as quickly. I use it for syntax checking my VHDL, as it gives better (stricter) language coverage than Modelsim. Regards, Allan.Article: 31862
Rick Collins wrote: > I would not disagree with what you say about the cost of RDRAM, but this > is the first time I have heard claims that it is not as fast as it is > supposed to be. Why do you say this? Or are you really referring to its > use with the P4? Well, AFAIK, there's a little of both. With full speed, large, multilevel caches, both P4 and AMD processors are not very sensitive to raw external memory bandwidth. What slow them down in a big way is running out of code / data and waiting for it (latency). As You'll see with RDRAM & DDR data sheets below, latency is much worse for RDRAM by 25% to 100% (25/30 ns with 2 RIMM versus 15 ns for CAS2DDR) and most applications that have a very unpredictable / non sequential access pattern loose an awful lot when using RDRAM. Most real applications simply don't access RAM in long contiguous chunks, that's where the rambus catch is. Problem is the same as trying to make pizza delivery with an 18 weels truck. Sure you could deliver hundreds of them at a time, but who needs this kind of "performance" ? what peoples want is just one fresh pizza, delivered ASAP, not a zillion, delivered cold and somehow melted with the box, 1 hour later. Here too, latency matters a lot more than volume/bandwidth. If you want the numbers, here they are : RDRAM : http://www.rambus.com/developer/downloads/rdram.128s.0059-1.11.book.pdf Page 10 it states : "The t CAC parameter (latency) may be programmed to a one of a range of values ( 7, 8, 9, 10, 11, or 12 t CYCLE ). The value chosen depends upon the number of RDRAM devices on the Channel and the RDRAM timing bin." tCYCLE is 2.5 ns for the fastest (-800) parts, and 7 cycles are illegal at this speed. Best case theoretical TCAC is thus 20 ns, 25 to 30 being more typical. DDR SDRAM : http://images.micron.com/pdf/datasheets/dram/256Mx4x8x16DDR_C.pdf With so called "CL2" DDR sdram (Micron's -75Z speed grade), latency (both Read & write) is 15 ns (page 11), and unlike RDRAM, there is no ifs, no "more chips/less speed" tradeoff, no periodic / temp compensation calibration, no guesswork. The only technical advantage for RDRAM is in applications that sequentially access large amounts of data (video refresh comes to mind), and in systems (such as RDRAM's best success, the PlayStation II) where lowering chip & pin count in a very tightly controlled PCB can somehow offset RDRAM's inherently higher cost and current consumption. --------------- But to me, the worst drawback with RDRAM is not technical. It's the fact that it's a proprietary device designed by a company that looks more like a law firm than an IC design house, and that's trying to extort a toll from a whole industry with their "Lawyer Inside" (You might also call it "Lawyer on a Chip") ill fated patent-all-sue-all strategy. Infineon trial uncovered more of their questionnable practices with JEDEC and rejected all Rambus claims. Also, the case they just lost in Italy raises new very interresting points (unless you own RMBS stock !) http://www.theregister.co.uk/content/3/18764.html http://www.theregister.co.uk/content/archive/18849.html http://www.theregister.co.uk/content/archive/19198.html Lawyers are laughing all the way ... A good sign of RDRAM / DDR future are new P4 / DDR chipsets from Acer and VIA announced at Computex in Taiwan. http://www.eetimes.com/story/OEG20010605S0062 Even Intel will have their SDRAM chipset as soon as their contract with Rambus will allow them to (SDR only will be offered first, find out why): http://www.theregister.co.uk/content/3/19418.html If you look at AMD's rising market share, or the way RIMM must be subsidised by Intel, you might agree that the end of the whole thing should be a big relief for Intel. http://213.219.40.69/23050111.htm Also remember that, at the chip level, Micron and others are closing the price gap and DDR is now availiable for nearly the same low price as good quality SDR. How much of it can you get for the price of a single 128 Megs -800 RIMM ? Would you bet your next product on RDRAM ? ---------- Well, maybe this goes a bit off topic, but since Rambus started to bully SDRAM memory controllers makers (Hitachi H8 / PC chipset makers), it would be wise to keep an eye on what's to come for FPGA based controllers. Eric.Article: 31863
Burch Electronic Designs announces the B3-SUPER-VALUE-PACK prototyping kit-set. A low cost set of kits, for FPGA-CPU computer architecture enthusiasts, or for FPGA education and training. The B3-SUPER-VALUE pack includes the base B3-SPARTAN2+ board (with 200K gate (!) FPGA), download cable, SRAM, PC connectors (VGA, PS2, RS232 etc), 7 seg displays, LEDs and switches Plug-On modules. Works with the free WebPACK software (available from the Xilinx website). http://www.burched.com.au/b3supervaluepack.html The B3-SPARTAN2+ board is available separately, without Plug-Ons, at < US$120 ! It features the Spartan2 200K gate (!) device, and an on-board header programmable PLL oscillator (select any clock frequency 1 - 100MHz). http://www.burched.com.au/bedspartan2.html All units are in stock now. Secure online ordering is available. 10-pack deals for volume purchases. International orders are very welcome. Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easy-to-use FPGA prototyping kits!Article: 31864
Rick Collins <spamgoeshere4@yahoo.com> wrote > I would not disagree with what you say about the cost of RDRAM, but this > is the first time I have heard claims that it is not as fast as it is > supposed to be. The VERY first time?Article: 31865
> > > Here we go. Schematic is IMHO just practical for simple designs, but > > when complexity rises, you are lost with schematics. > > Absolutely untrue, if you know how to use the tool. In fact, one of the > most complex and fastest CPUs ever made, and its support chips, were done in > schematic, simply because HDL tools could not do the job. One of the fastest and most complex CPUs was designed using hundreds of custom cells layouted by hand using hundreds of highly skilled engineers AND proprietary inhouse skew analysis tools. This propably falls into Falk category: "Sure, a pro can always get better results than a "stupid" compiler but for what efford??" Ever seen any inhouse FPGA tools? Kolja SulimmaArticle: 31866
Eric wrote: (lots of snip) Problem is the same as trying to make pizza delivery with an 18 weels truck. > Sure you could deliver hundreds of them at a time, but who needs this kind > of "performance" ? what peoples want is just one fresh pizza, delivered ASAP, > not a zillion, delivered cold and somehow melted with the box, 1 hour later. > Here too, latency matters a lot more than volume/bandwidth. That's the nicest analogy I've seen for what I usually paraphrase, following Bill Clinton's first campaign, as: ``Its the latency, stupid'' No offence intended. Note that DDR DRAM also falls into this category of solving the easy bandwidth problem instead of the hard latency one but at least it doesn't force you into insanely expensive controllers, PCB technology, and license fees. There is an indirect latency benefit in that high bandwidth stuff like PCI traffic uses less memory time. <more snip> > Well, maybe this goes a bit off topic, but since Rambus started to bully > SDRAM memory controllers makers (Hitachi H8 / PC chipset makers), it would > be wise to keep an eye on what's to come for FPGA based controllers. > > Eric. They'll have to go after Xilinx first since the Virtex2 defines 2 ``DDR registers'' in the IOB and there have been DDR DRAM controller apps notes on their web site for ages. Great posting Eric. It should appear somewhere on a DRAM FAQ but Rambus would probably sue the FAQ hoster. In fact if I were you I would consider getting a lawyer now & moving all your assets off-shore. An interesting side note: When this came up I went I downloaded a RDRAM data sheet. What did I see on the Rambus home page ? A little picture with a hot spot marked ``New Litigation''. I think that just about says it all ...Article: 31867
On 6 Jun 2001 13:49:32 -0700, hristostev@yahoo.com (hristo) wrote: >hey, > >what a hardware designer should put in his mind(as differences and >performance criterias) once he targets ASIC or FPGA ? FPGA flip flops are "free". In ASIC they aren't. Testing an FPGA is "free". Testing an ASIC isn't. ---- KeithArticle: 31868
I noticed that Xilinx announced RapidIO support on their Web site. Is
this simply that they support LVDS IO compatible with RapidIO, or is
it a core which supports the entire RapidIO physical layer interface?
If it's the latter, how does the interface to this core look like?
Thanks
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 31869Hi, I seek some information (samples) about cooperation microcontroller(8031) and FPGA(4005XL) on the XSBoard v1.2. Thank you, TomArticle: 31870
That's way cool. What process were you running? Were you using delay lines and one shots to handshake? Bob "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3B1E7C2A.BCFB57B8@xilinx.com... > > glen herrmannsfeldt wrote: > > > There were buffer memories before FIFO, where they were loaded > > (FI) and then read out (FO) but not both at the same time. > > A card reader would read a card to a small core array, then read > > it out one character at a time. It would not read the next card > > until it was completely empty. I beleive that the FIFO's peter > > is writing about have the ability to read and write at the same > > time, or at least interleave read and write operations. > > Yes, simultaneous asynchronous write and read. > To be precise, the 3341 FIFO was really a specialized shift register, where > 4-bit parallel data was shifted in and then, on its own, "bubbled" down the > shift register until it lined up behind the last remaining entry ( or at the > output). The whole thing was a "controlled and distributed race condition", > where each 4-bit location made an asynchronous decision to transfer to the > downstream neighbor and after that, asynchronously, signal its emptiness to the > upstream neighbor. Distributed handshake, no common clock at all. > 30 years later, I can still draw you the schematic... Maybe that's where my > infatuation with tricky asynchronous circuits got started. > > Peter Alfke > > > >Article: 31871
> Ever seen any inhouse FPGA tools? Well, yeah.Article: 31873
> >The only people who need the bitstream are the people developing the back > >end tools, NOT the design entry tools. > > I was once working on a project that would have needed to know > some of the bits. Most of the design was static, but some constants > had to be changed before the data was loaded. Xilinx will tell you > where the LUT bits are, at least in the 4000 series. (So you know > which bits to ignore when you read the data out again.) > > Mostly it was loading the values for ROM compiled into the design, > in a systolic array where each chip had different values. > There are probably other projects that need similar information. Isn't that still back end tools though? Having the front end tools know the bitstream wouldn't help this as far as I can tell.Article: 31874
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