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
Brad, the rising edge of EMPTY is very important, since you must stop any reading once EMPTY goes High. The falling edge of EMPTY pays a price for coming from the other clock domain. It has internal re-synchronizing flip-flops, which cause a delay. It was our (my) decision to favor the rising edge and make the falling edge less precise. In your case that may confuse you. We designed this FIFO for 500 MHz asynchronous operation... Peter Alfke, from home. =============== Brad Smallridge wrote: > Hi Peter, > > Well I am in the asynchronous world, not at 500 MHz. I am using the Virtex 4 > SX35 and I read that the falling edge of EMPTY is already being synched to > the RDCLK by the primitive FIFO16. Is that not true? Yes, it's done inside, but it still takes a few clock ticks... > > My issue is that in my simulations I see the EMPTY go on for two RDCLKs, > whereas I have only written one datum into the FIFO16. Yes, I expected that, and, depending on the phase between read and write clocks, it might even be three. The horrors of asynchronous clock domains, where you cannot predict whether one clock is even a picosecond before or after the other. Peter > > BradArticle: 97651
>My issue is that in my simulations I see the EMPTY go on for two RDCLKs, >whereas I have only written one datum into the FIFO16. That's a reasonably common problem with FIFOs. There is a pipeline delay in deciding to read the FIFO and/or in updating the empty flag after you do the read. You can probably patch your code to ignore the EMPTY flag until it has had time to get the right answer. The disadvantage with that is that you can only read at half speed. (Or slower if your pipeline is longer.) I know two tricks to get around the half-speed problem. One is to use an almost-empty flag. If the FIFO is not "almost" empty then you know it won't go empty right after you read it so you can plan to read a second work and know there will be data ready. The other approach works for things like packets when you know the input side is faster than the output. Add another data bit to the FIFO (make it wider) and put an End-of-Packet flag in there. This works when the data path is faster than the empty-flag path. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97652
>http://www.onsemi.com/PowerSolutions/product.do?id=MC100EPT21DR2 Be sure to check the output with a scope. Years ago, I used a PECL=>TTL part. That was real/old, 5V TTL. The problem was that I really wanted a CMOS output and what I got was a TTL signal that only went up to 4V or so. We had to run it through an AC dead-bug to get what we wanted. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97653
Hal Murray wrote: > >http://www.onsemi.com/PowerSolutions/product.do?id=MC100EPT21DR2 > > Be sure to check the output with a scope. > > Years ago, I used a PECL=>TTL part. That was real/old, 5V TTL. > The problem was that I really wanted a CMOS output and what I > got was a TTL signal that only went up to 4V or so. We had to > run it through an AC dead-bug to get what we wanted. Good point to keep in mind. In this case though it's all 3.3v families, and LVTTL seems to have nearly the same Vih/Vil spec as LVCMOS. The part is spec'd with minimum Voh of 2.4v.Article: 97654
I'm looking to create a LUT based delay line for use in aligning DDR strobes. The target device is a V2P, I have read the application notes provided by Xilinx on this topic but can't seem to find a reference design that illustrates this usage of LUTs. Perhaps someone could point me in the right direction. Thanks in advance, BrendanArticle: 97655
Hi Jon, Some considerations as I'm working on a similar design. I assume that you will demux the incoming datastream to 125MHz @16bit. This datastream can be fed to the DDR memory (also running at 125MHz - or maybe faster to give you some headroom. Both Spartan3 and Cyclone will have 'problems' (I mean careful design of the DDR interface) at anything faster than 133MHz (or 266Mbps). Virtex2 or Stratix are then an option. However if you care about your budget, you might concider moving to another lowcost FPGA device, namely the EC or ECP of Lattice. Of course if the company's strategy is to use Altera or Xilinx, I would concider V2 or Stratix and not the Spartan/Cyclone. Best regards, Luc On Fri, 24 Feb 2006 14:31:11 -0600, "maxascent" <maxascent@yahoo.co.uk> wrote: >Hi > >I am using a 8-bit ADC with parallel LVDS outputs clocked at 250MHz. I >want to interface this to a FPGA, then place the samples into a DDR >memory. Then send the samples from memory via ethernet to a PC. Can you >recommend an FPGA from either Xilinx or Altera to do the job. > >Thanks > >JonArticle: 97656
Hi, I'm an italian student of Automation Engineering (..sorry for my academic english...). It's the first time that I post in this group. I would like to know if there is some fpga board (I've just used an Altera board for an exam of Electronic Digital Systems) that has this requirements: -low power consuption (for using with a solar panel), less than 100mA of current consumption at 3.3-1.2 V; -a non-volatile memory (eeprom...) that contains the "programs" also when it's extinguished; -a max cost of about 200 $. I thank all of you that can answer to me. Bye DuccioArticle: 97657
logjam wrote: > I want to do all sorts of things. After this I want to build an 8bit > computer using transistors. I saw one on the internet, but it didn't > look like it ran any decent software. Way to go :) Excellent way to gain grounding experience, as nobody will pay you to build one today!! The oldie moldies here are likely to enjoy gabbing about the past too. Ignore Peter, and those that are completely clueless about what drives hobbiests. They are the ones that are clueless for working only on projects that yield 8 digit dollar signs. I kept one transistor computer, actually the only small one I had worked with ... the others were much too large to pack around, especially the NCR 315 which was five rack bays plus the CRAM unit and a console. It's a rare desktop PDP-8 lab machine with the smoked plexiglass covers. If you wanted to build a transistor machine I would suggest an original PDP-8 design as it's well documented and there is lots of PDP-8 software. I would do it based on the original module design, as the boards are pretty inexpensive if done as panels, and I would use a pcb backplane instead of wirewrapping it as the original was done. I wish I had kept one drum and tube computer too ... especially a single rack one like a Bendix G15. Anybody have a G15 they want to send to a good home? > I guess the reason I came up with 75 is because that's the year of the > Altair and other computers becoming "popular"? It will be fun to see > what kind of computer I can design out of commonly available parts, > what it would have cost, and how fast it is. So far my initial > calculations are 4-4.5 million 32x32bit multiplications per second. > That is pretty fast, comparable to a 50MHz 486. There are a number of people now doing retro designs both in TTL with microprocessors, and in FPGA's for similar reasons. It's fun, good learning experience, and yields an excellent grounding in low level design and assembly processes. There are a number of folks doing this for both old home computers and early video games. > For a while I wanted to build a computer out of relays, but I'm not > that brave yet. That's a LOT of time. :) > > I've just completed the soldering on a 19,008 LED display. Talk about > current, the thing draws 130A! So, yes...I am crazy. :) Not crazy .... DRIVEN! ... something lacking in many current college graduates this day that went into engineer for the pay check, and not the love of technology. If you are half way local to Colorado, look me up. Otherwise email, there are a few of us that still love technology for the sake of technology, rather than just a paycheck. My home project has been taking a few thousand older FPGA's to build a home super computer into a desktop sized box (with water cooling, and a lot of memory, fibre channel disks, etc) .... :) It takes a lot of current too .... a few thousand amps for even a "small" super computer.Article: 97658
On Thu, 23 Feb 2006 02:08:50 -0800, logjam wrote: > Now on to my question. Is there a simple combinatorial design for > division? So far the whole schematic is made using "Combinatorial > logic"? I'm not sure that's the right word. The ALU can perform any > function without clock inputs, its also faster than a lot of the other > methods I've found. For example, calculating one partial product at a > time for multiplication. The answer is that there is no combinatorial divider that makes sense. Division is done by successive approximation. The simplest algorithm for division is a one bit per cycle operation. There is also a two bit per cycle algorithm that's pretty efficient, thats what I used in the mini-computers that I designed in the 70s and early 80s. If you have high speed multipliers, which modern FPGAs have in abundance, then the highest performance algorithm is a Newton-Raphson convergence algorithm. There are similar algorithms for square root. The clearest explanation of how to do a convergence divide is in the Cray 1 manual, if you do a Google search you should be able to find a copy on the web.Article: 97659
Brad Smallridge wrote: > Hello Group, > > I could use some advice on hooking up asynchonous FIFO16s to an SRAM > interface. Specifically I have two FIFOs on different clocks feeding the > address lines of the SRAM, on a third clock. A control circuit looks at the > two EMPTY flags to determine which fifo output should be muxed onto the > address lines. > <snipped> Brad, The Virtex4 FIFO16 flag logic has a design flaw that renders them unreliable for asynch operation. I'm rather surprised in fact that Peter did not mention it in his reply to you. Anyway, the issue is that if the read clock and write clock edges are close together, the flag logic can get corrupted, which then screws up the fifo operation when the fifo gets to the full or empty condition. To use the fifo synchronously, you have to move the read and write edges apart. The easiest way to do that is to use the falling clock for write and the rising clock for read. For async fifos, you cannot guarantee that the edges will never align, therefore for reliable operation, you cannot use the fifo16 asynchronously. You can, however use it synchronously and cascade it with a small async coregen fifo implemented in the fabric so that the net effect is an async fifo. It would be good for you to read Xilinx Answer 22462 at http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22462Article: 97660
David R Brooks wrote: > What, no vacuum tubes? I miss the sound of a mag-drum spinning up - now > that's a *real* system :-) Actually I was more impressed by the Bryant drums in the CDC (and I believe the Burroughs too) that were in Dr. Dicky's CalPoly collection, continuing to spin long after cutting power to the rack. It's been some 30+ years, but I'm still impressed with it's size, and the long rows of heads. I did keep a "little" drum, about a half cubic foot from a military computer that got scrapped at UCLA. And I also kept a 31 inch Data Products disk platter and electromagnetic linear stepper actuator with little air bellows for head loading from an XDS940 that got scrapped from Tymshare in the 70's. It's been on the wall of my office for 25 years, and I love taking "tape viewer" out and showing people the bits on the surface, which are easily visible by eye and a small glass. The travesty is that some clueless folks trashed Dr. Dicky's historical lab, which was a wonderful collection of WORKING machines from the late 50's and early 60's. I spent several months getting a badly damaged NCR315 working for him, that was probably the most valuable experience of my life. Another student/faculty member had dropped a screw driver on the power rails with the system live, shorting the negative and postive power rails, and took out nearly every germanium diode and transistor in the machine, which took a couple weeks of soldering to repair enough of the boards. Bringing the machine back up from that horrible accident was a grounding in low level computer/machine design that became an experience of a lifetime. The sequencer for that design, was a large array of magnetic cores along the top of the bays, where the cores were plused in sequence, and secondary loops from each core controlled all the major FF's and data paths for the processor design. Microcoding by wires and pulse transformers.Article: 97661
Yes, Ray, you are right. I was about to follow up with this issue once I am back at work on Monday. There is the "Achilles heel" problem that Ray mentioned, and to avoid it in asynchronous mode takes the work-aound that Ray may have listed. I have been deeply involved in this, and I am still working on a simpler work-around. If you are willing to sacrifice a few percent of top capacity, and are willing to have the two ALMOST flags at fixed locations (non-programmable and with some tolerance), which I think are not too unreasonable sacrifices, the work-around boils down to less than 3 CLBs, and of course no speed loss. We decided to not confuse the world (and ourselves) with two very different fixes. So we published the bigger, no trade-off work-around first. The smaller one will follow. Anybody interested can send me an e-mail. This has been a painful experience. ;-( Peter Alfke, still at home.Article: 97662
o fpga_toys@yahoo.com wrote: > > Ignore Peter, and those that are completely clueless about what drives > hobbiests. They are the ones that are clueless for working only on > projects that yield 8 digit dollar signs. > In my defense (I am thin-skinned) the original posting did not tell the whole story. If I had known that this is a hobbyist with a historical interest, my answer would have been far more friendly. I was very much involved in the TTL era (at Fairchild 1969 to '72), inolved in the launching of many MSI circuits, and I wrote most of the "Fairchild TTL Applications Handbook" in 1973 So I am not "completely clueless" as -toys insinuates. Peter Alfke, from home.Article: 97663
Josh Rosen wrote: > The answer is that there is no combinatorial divider that makes sense. > Division is done by successive approximation. The simplest algorithm for > division is a one bit per cycle operation. I'm not sure that long hand division is "successive approximation", as it's a clear and precise algorithm when applied by computers, and does yield a combinatorial divider that is only slightly more complex than a similar multiplier design derived from long hand multiplication. The design for such a divider is identical to a similar multiplier, but with subtraction and a mux at each stage to keep the original value if a barrow occurs. The "solution" is in the mux selectors for the quotient, and the ending value at the end of the subtractors is the remainder. This was fairly fast, and easy to implement as a bit serial/parallel design I did a while back for a distributed arithmetic problem. I suspect, but didn't figure it out, that there is a Booth Recoding analog for such a divider design. You can use the top bits of the remainer to select the shift amount, which cuts the cycles in half for a serial design, so I didn't worry it that hard.Article: 97664
"Adam Megacz" <megacz@cs.berkeley.edu> wrote in message news:x1u0azgcd0.fsf_-_@nowhere.com... > > Might be OT, but I'm interested in any pointers to the current > state-of-the-art in automatic schematic generation. By this I mean: I > give it a netlist, it draws what it thinks is a "pretty" schematic for > some heuristic definition of "pretty". Even if "pretty" means "just > barely not hideously ugly". > > In the area of mathematical graphs (spline edges, no 90-degree > requirements -- a very different problem) GraphViz is sort of the > "reference point" from which everybody else makes improvements: > > http://www.graphviz.org/ > > ... I'm looking for some similar analogous feature-point for > schematics rather than general directed graphs. And yes, I know this > will never be as good as human-drawn schematics. > doxygen and graphviz work together to produce call and dependency graphs from c , c++ source code to be inserted into doxygen produced api type docs http://www.doxygen.org maybe there is a way to use them to parse vhdl or verilog into a schematic or at least block diagrams? Doesn't altium with the lastest version of altium designer use netlists as the backend ? or have import to schematic I'll try to remember to have a look tomorrow at work AlexArticle: 97665
> > I suspect, but didn't figure it out, that there is a Booth Recoding > analog for such a divider design. You can use the top bits of the > remainer to select the shift amount, which cuts the cycles in half for > a serial design, so I didn't worry it that hard. This is the two bit at a time algorithm that I was talking about. Back in the 70s this was the most cost effective way to implement division. Modern machines, and FPGAs, have fast multipliers so convergence division is the best choice today.Article: 97666
what shall I use to convert FPGA i/o pins to 5v TTL compatible levels? 50 i/o pins, tri-state, TTL RArticle: 97667
aiiadict@gmail.com wrote: > what shall I use to convert FPGA i/o pins > to 5v TTL compatible levels? What FPGA? What I/O supply voltage? How fast? A few (older ones mostly) you can directly connect. For some such as spartan 3 you can use series resistors. (Typically ones which have internal protection diodes - the resistor limits the current to prevent burning out the diode, which limits the voltage to the input itself) For others you may want to use special level translators or perhaps 3.3 volt buffers with 5v compatible I/O. Also, what logic family are you using on the 5v side - TTL, 5v CMOS, or 5v TTL-compatible CMOS? Ordinary 5v CMOS may not see 3.3v referenced '1's as '1's - though 5V TTL and TTL compatible CMOS should.Article: 97668
There are two directions: FPGA to TTL, and TTL to FPGA Today, all the FPGAs I know still support 3.3 V as I/O supply voltage. (That may change in the future, for 3.6-V tolerance is not natural or easy in the best and fastest processes) TTL-to-FPGA: Old bipolar TTL generally stayed 1 or 2 diode drops below Vcc, but CMOS variants can swing all the way to Vcc=5.5Vmax. Most FPGAs do not tolerate >3.6 V on their pins, but most also have a clamp diode to their own Vcc. If you can rely on that diode, then use 2.5 V or 3.3 V as Vccio and put a series resistor of 100 or 220 Ohm between the FPGA and TTL pin, to limit any clamp current. FPGA-to-TTL: Usually no problem, since TTL sees anything above 2.4 V as High. There are, however, "TTL" derivatives with CMOS input thresholds that might be up to 3.5 V. In that case, you should 3-state the FPGA output, and use a pull-up resistor to 5 V (relying on the clamp diode to the 3.3 V Vcco. This is a slow pull-up, and there is a trick to temporarily enable the active pull-up to generate the first 2 V of voltage swing. 5V should today be considered an obsolete and awkward supply voltage, although it has served us well for 40 years.( In a few years, 3.3V will cause the same grief...) Peter Alfke, from home.Article: 97669
Josh Rosen wrote: > > I suspect, but didn't figure it out, that there is a Booth Recoding > > analog for such a divider design. You can use the top bits of the > > remainer to select the shift amount, which cuts the cycles in half for > > a serial design, so I didn't worry it that hard. > This is the two bit at a time algorithm that I was talking about. Back in > the 70s this was the most cost effective way to implement division. Is the two bit at a time algorithm a Booth Recoding analog, or variable shifter algorithm? > Modern machines, and FPGAs, have fast multipliers so convergence division is the > best choice today. Except for the fact that logjam is "I'm building a 64bit ALU using standard TTL devices."Article: 97670
Hai XC9500 is not initialized and .log file directing me to look for hardware config problems. I have Connected Parallel cable and using JTAG interface(assembled). All of JTAG Connections and VCC, GND connections were made properly The Part Iam tring to use :PLCC84-15. The software ( ISE3.3i) has been tried on both win-98 and Win-2000.Hardware working with Pentium IV processor. When observed on scope, I have seen glitches on TDI TDO and TCk pins.As suggested in Parallel III cable, I am using HC125 ICs. How to kill them. Any suggestions! Thanks ChelamArticle: 97671
On Sat, 25 Feb 2006 17:45:36 -0800, fpga_toys wrote: > > Josh Rosen wrote: >> > I suspect, but didn't figure it out, that there is a Booth Recoding >> > analog for such a divider design. You can use the top bits of the >> > remainer to select the shift amount, which cuts the cycles in half for >> > a serial design, so I didn't worry it that hard. >> This is the two bit at a time algorithm that I was talking about. Back in >> the 70s this was the most cost effective way to implement division. > > Is the two bit at a time algorithm a Booth Recoding analog, or variable > shifter algorithm? > >> Modern machines, and FPGAs, have fast multipliers so convergence division is the >> best choice today. > > Except for the fact that logjam is "I'm building a 64bit ALU using > standard TTL devices." It's been 25 years since I've used it so I don't remember the details precisely. As I remember there is a lookup on the MSBs of the numerator and the denominator, as I recall it only required two or three bits of each. With the two bit quotient approximation you subtract the product of the quotient and the denominator. I think you can can combine it with a Booth algorithm. As I said I don't remember all of the details, but as I recall it wasn't very hard to figure it out. I'll leave it as an exercise for the reader.Article: 97672
Josh Rosen wrote: > It's been 25 years since I've used it so I don't remember the details > precisely. As I remember there is a lookup on the MSBs of the numerator > and the denominator, as I recall it only required two or three bits of > each. With the two bit quotient approximation you subtract the product of > the quotient and the denominator. I think you can can combine it with a > Booth algorithm. As I said I don't remember all of the details, but as I > recall it wasn't very hard to figure it out. I'll leave it as an exercise > for the reader. Ok. I picked this thread up because writting a portable intrinsic for FpgaC was on my list this weekend. And it's been a few years since I last had to do this too :) All of the optimized software routings are optimized around processor and table lookup specific designs, which aren't exactly FPGA friendly. So I guess it's time to dig out the text books again :) I wish all the FPGAs, even the smaller ones did have multipliers, unfortunely most of the small FPGAs on student boards just have LUT/FFs.Article: 97673
fpga_toys@yahoo.com wrote: > I wish all the FPGAs, even the smaller ones did have multipliers, > unfortunely most of the small FPGAs on student boards just have LUT/FFs. Well, Spartan-3 and 3E have lots of multipliers, and they are about as cheap as any FPGA. Your wish has been granted... Peter AlfkeArticle: 97674
Duccio wrote: > Hi, I'm an italian student of Automation Engineering (..sorry for my > academic english...). > It's the first time that I post in this group. I would like to know if > there is some fpga board (I've just used an Altera board for an exam of > > Electronic Digital Systems) that has this requirements: > -low power consuption (for using with a solar panel), less than 100mA > of current consumption at 3.3-1.2 V; > -a non-volatile memory (eeprom...) that contains the "programs" also > when it's extinguished; > -a max cost of about 200 $. I think you will find that most of the FPGA out there will suck up more than 100 mA even if clocked slowly. Of course this depends on how large of an FPGA you have and how much of it you use. Still, it would be hard to find and FPGA board to run on 100 mA. You would do much better looking for a CPLD board. Xilinx makes two lines of low power CPLDs that can do a lot of work. One is 5 volt tolerant "XCR" and the other uses a lower voltage core "XC2". I found some boards at Digilent, https://digilent.us/Products/Catalog.cfm?Nav1=Products&Nav2=Programmable&Cat=Programmable%20Logic The XCR board claims to run from a couple of AA batteries for 60 hours. Here is one sold by Nuhorizons, but also made by Digilent... http://www.nuhorizons.com/services/development/xcrboard/xcrBoard.html You will have to contact them about the price.
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