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
> You should be able to do this in the UCF file. You will need > to know the exact name of each signal though. It will look > something like this: > > net "bus_name[0]" loc=a12; > net "bus_name[1]" loc=b12; > net "bus_name[2]" loc=c8; > net "bus_name[3]" loc=d5; > > One way to get the final output names (might not have "[ ]" ) is > to run the design without the "loc" constraints, bring up the result > in the FPGA editor, and then poke around the I/O cells to see > what the final names look like. The .PAD file is probably also > useful. > > Here are two lines from one of my .PAD files: > > | io_c13 (L01P_1) | OUTPUT | C13 | LVTTL | 12 | SLOW | | > | io_d12 (L02P_1) | OUTPUT | D12 | LVTTL | 12 | SLOW | | > > Here are the two lines from my .UCF FILE > > NET io_d12 LOC = D12; > NET io_c13 LOC = C13; > > While not a bus, it at least shows the syntax > > Philip > Thanks for the reply! I may have to do something like that. I did get another reply however that I wanted to share with anyone else that may have to do this in the future. Thanks again. Dave. >Select the Hierarchy->Hierarchy Push tool and click on the IPAD16 symbol. This will bring up a window in which all the individual IPADs are visible. Then you can right-click on each IPAD and select the Symbol Properties entry in the pop-up menu that appears. Then place the pin assignment in the Parameters window.Article: 34152
Alternatively, as part of my research (I'm a grad student at Penn State) we're building an FPGA accelerator card which resides on the SDRAM memory bus. Much faster than PCI (up to 133MHz x 64 bits vs 33MHz x 32 bits) and _much_ lower latency. Our current board has a Virtex XCV300 and 64MB of SDRAM, sufficient for quite a few interesting applications. There are some limitations with this approach - for example, there are no nice interrupt facilities as available on the PCI bus - but other than that it seems like a great solution. We're testing our first board now, it will interesting to see what kind of performance we can acheive with this method. If you're interested in some more (admittedly a bit outdated) information, check out www.cedcc.psu.edu/smartdimm/ Luke Roth On Wed, 15 Aug 2001, Dave Feustel wrote: > I've been thinking about the i/o interface obstacle that exists between > cpu and pci-bus mediated fpga accelerators for a couple of days now. > I have come to the conclusion that the way to have *really* fast > fpga accelerators is to put a hardwired cpu on the fpga chip along > with the accelerator logic and make the entire application run > directly from the fpga. You now can get fpgas with ARM, Powerpc > and or other custom cpus preprogrammed into them and still have > lots of room for your accelerator logic. IP cores for almost every > commonly used peripheral are available to be incorporated onto > the fpga chip - leave off the interfaces you don't need. > Put the whole thing on a PCI card and plug it into your pc to > make development easier(download through the pci bus). > > "Mike Butts" <mbutts@realizer.com> wrote in message news:3B758FB0.B98CA76A@realizer.com... > > Dave Feustel wrote: > > > The real short version is > > > that the PCI bus interface is so slow relative to the > > > speeds of the cpu and accelerator that it usually > > > isn't worth adding an accelerator if the interface > > > is via the PCI bus. > > > > This is often, but not necessarily true. Accelerator architecture > > totally depends on your application. This is exactly what Philip > > meant by "how long should a piece of string be". Not ridicule, > > just maybe a little drier wit than we're used to... > > > > If your application depends on lots of back-and-forth > > between the host and the card in its core kernel, PCI is usually > > a barrier. Many early research projects in this field found this > > out the hard way. It's not the bandwidth that matters in such > > cases, it's the latency, the round-trip time for a single operation. > > > > PCI, especially as implemented in modern PCs and workstations, > > can be very bad at that. Mark Shand gave an excellent and > > most useful paper about this at FCCM '97, that anyone using PCI > > must study: > > Laurent Moll and Mark Shand. Systems performance measurement on > > PCI Pamette. In FPGAs for Custom Computing Machines > > (FCCM'97). IEEE, April 1997. > > http://www.research.compaq.com/SRC/staff/shand/bib.html > > > > If, on the other hand, your app is a self-contained kernel that > > grinds away mostly on its own, PCI can be fine. Often signal > > processing apps are like this, with the signal I/O direct to > > the card. > > > > I believe a very big win for reconfigurable computing is for > > apps that demand lots of parallel memory bandwidth, since the > > processor-memory bottleneck is so fundamental to conventional > > computing. I'm working with a project at Oregon Graduate Institute > > lately to develop a neural network accelerator. In our case, it's all > > about memory bandwidth. I/O to/from the host is orders of > > magnitude less. We're planning a PCI card with as many SDRAM DIMMs > > as we can hook up to some FPGAs for them to grind away on matrix- > > vector multiplies in parallel at 100 MHz. PCI will just control > > and program the card, and feed inputs and collect results at a > > lazy and latency-insensitive pace. > > > > So tell us more about your application, and maybe we can give you > > better advice. > > > > --Mike > > >Article: 34153
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:3B7BF014.2A82A301@gmx.de... > Jamie Sanderson schrieb: I don't know how to "schrieb"... ;) > We discussed this some time ago. Conclusion was. > > Use the DLL to double the clock BUT dont transfer datas from one clock > domain to the other on the same clock edge. Because when the clock nets > are loaded very unequal, skew can be an issue, even with the DLL. > This is a advice from Ray Andraka. He can explain this more detailed. Makes sense to me. I was hoping the software would do better than assume zero skew introduced by the DLL. Peter Alfke emailed me with similar advice. I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think that allows me to use rising edge clocks everywhere, while providing a quarter clock period of setup/hold between the clock domains. Thanks! JamieArticle: 34154
"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com... > I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think > that allows me to use rising edge clocks everywhere, while providing a > quarter clock period of setup/hold between the clock domains. Hmm, this gives me a mapper error ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not driven by the CLK0 or CLK2X pin of the same DCM. Errors found during the mapping phase. Output files will not be written. That's annoying... Back to the drawing board.Article: 34155
I've done this with other types of PLDs. You need to make 2 inverters in the PAL. The non-inverted output connects to the input via a capacitor, or a resistor and capacitor in series. The inverting output connects via a resistor to the input. It is the same circuit you make from a CMOS logic gate. You take the clock from the second inverter's output. In article <140820011643075782%penfold@deadbeat.edu>, Eric Inazaki <penfold@deadbeat.edu> wrote: >I have a PLD circuit which requires a clock signal. I'm thinking it'd >be really nice if I could use some of the otherwise unused gates (along >with a cap and a couple of resistors) to generate the clock. Is this >a bad idea, doomed to failure or is this sort of thing done all the >time? With respect to timing circuits in general, can PLDs be used in >place of discreet logic gates? In this particular case I'm using a >Lattice ispLSI1016E. > >thanks, >eric -- -- kensmith@rahul.net forging knowledgeArticle: 34156
We have a development board with two Spartan II FPGAs on it, used for wireless systems development using a Texas Instruments DSP Starter Kit. It provides a total development environment at a very reasonable price.. For more information, checkout www.southwestsoftware.com/sw6x100.htm Regards, Walt "Ali" <aelmousa@yahoo.com> wrote in message news:4eede02c.0108140256.6fd35d23@posting.google.com... > Hello All, > > I am looking for reasonably priced development boards that use FPGAs. > The boards should be for application development and not for testing > purposes. They should use the PCI bus interface in a PC. I am not > interested in going into the details of programming the PCI interface > if an FPGA is used for that purpose. > > It is preferable to have parts of the PCB board available for in-house > circuit additions also. Memory subsytem is not very important on the > board. > > Any help with knowledge of availability of such boards, vendor > addresses, web pointers, prices etc will be greatly appreciated. > > Thank you. > > AliArticle: 34157
Hi, I'm looking for a device that has very small setup and hold requirement. I'm trying to use this device to capture a 250 MHz DDR bus with single ended HSTL level. Ideally, I would like the device to require not more than 300 ps of setup and hold window. My gross data window is 2ns, but after the driver clk to data skew, edge rate effect, board effect, etc... I don't have much margin left. It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed at 690 ps of setup and 0 hold. Does anyone know any other device that's better?? Any help would be greatly appreciated! THanks, AdrianusArticle: 34158
Hi, I need to to generate a synthesised frequency of Fin * 65536 where 45Hz < Fin < 65Hz. Does anybody know of a VHDL core that can do this. I have FLEX6016, reference CLK=50MHz. Regards PierreArticle: 34159
I discover a major performance problem with Modelsim When your simulating a design using a ram the memory array is usually describe that way in verilog: reg [mem_with - 1 :0] my_memory [0: mem_deep - 1]; If your memory deep is more than a couple to hundred (mine is 521k for example) you can't even display a single memory location (16 bit) without having all your system ressources used and all you ram used (i have 1Gb or ram and it use all) If you'r lucky and patient and you PC doesn't crash when you drag your memory location from the signal window to the wave window don't think your done. Running a simulation is just impossible the sumulator just rumm forever to do nothing. I think the worste about it is that I contact them to report the problem but they don't seems to care about it. If any of you know a "smart" simulator that is able to handle that kind of case let me know. Regards FredArticle: 34164
Do you recall what kind of PLD you used? Also, what frequency were you running? Thanks, eric On 15 Aug 2001 18:25:12 GMT, Ken Smith <kensmith@rahul.net> wrote: > >I've done this with other types of PLDs. You need to make 2 inverters in >the PAL. The non-inverted output connects to the input via a capacitor, >or a resistor and capacitor in series. The inverting output connects via >a resistor to the input. It is the same circuit you make from a CMOS >logic gate. You take the clock from the second inverter's output. > >In article <140820011643075782%penfold@deadbeat.edu>, >Eric Inazaki <penfold@deadbeat.edu> wrote: >>I have a PLD circuit which requires a clock signal. I'm thinking it'd >>be really nice if I could use some of the otherwise unused gates (along >>with a cap and a couple of resistors) to generate the clock. Is this >>a bad idea, doomed to failure or is this sort of thing done all the >>time? With respect to timing circuits in general, can PLDs be used in >>place of discreet logic gates? In this particular case I'm using a >>Lattice ispLSI1016E. >> >>thanks, >>eric > > >--Article: 34165
Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>... > I have a PLD circuit which requires a clock signal. I'm thinking it'd > be really nice if I could use some of the otherwise unused gates (along > with a cap and a couple of resistors) to generate the clock. Is this > a bad idea, doomed to failure or is this sort of thing done all the > time? With respect to timing circuits in general, can PLDs be used in > place of discreet logic gates? In this particular case I'm using a > Lattice ispLSI1016E. > > thanks, > eric I've used a two-inverter circuit oscillator, using gates inside a Coolrunner (Xilinx) PLD. The circuit goes: inverter between nodes A and B inverter between nodes B and C 100nF between C and A 10k between A and B I got nice square waves at B and C; exponential decay at A, 1.7ms period. Unfortunately, the signal generated was useless as a clock for further circuits inside the CPLD! Not sure why... the square waves had nice clean edges. I guess the chip didn't like the slow edges at A. I think your inverter/buffer circuit would have the same problem since there is an exponential decay waveform at the input to the buffer. BTW, I think your circuit would work (in non-CPLD implementation) if you replace R2 with short. I ended up using 555. R from output to threshold/trigger; C from threshold/trigger to GND. Gives nice output. Rarely seen this simple circuit published. Only drawback I know is that output doesn't go rail to rail for bipolar version (but does for CMOS). Have fun.Article: 34166
Jim Granville wrote: > > Martin Rice wrote: > > > > Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>... > > > I have a PLD circuit which requires a clock signal. I'm thinking it'd > > > be really nice if I could use some of the otherwise unused gates (along > > > with a cap and a couple of resistors) to generate the clock. Is this > > > a bad idea, doomed to failure or is this sort of thing done all the > > > time? With respect to timing circuits in general, can PLDs be used in > > > place of discreet logic gates? In this particular case I'm using a > > > Lattice ispLSI1016E. > > > > > > thanks, > > > eric > > > > I've used a two-inverter circuit oscillator, using gates inside a > > Coolrunner (Xilinx) PLD. The circuit goes: > > inverter between nodes A and B > > inverter between nodes B and C > > 100nF between C and A > > 10k between A and B > > > > I got nice square waves at B and C; exponential decay at A, 1.7ms > > period. > > > > Unfortunately, the signal generated was useless as a clock for further > > circuits inside the CPLD! Not sure why... the square waves had nice > > clean edges. I guess the chip didn't like the slow edges at A. I > > think your inverter/buffer circuit would have the same problem since > > there is an exponential decay waveform at the input to the buffer. > > What looks 'clean' to even a 100Mhz Scope may not be a clean-enough > clock signal, especially if it comes from a slow-slew oscillator! > > > BTW, I think your circuit would work (in non-CPLD implementation) if > > you replace R2 with short. > > The second R is not needed for timing, what it does is provide > overdrive > protection, and also improves stability. > Without it, you try and drive nominally 50% beyond the rails on the > RC node. > We have used 1R, and two equal C's to avoid both the overdrive, > and the very 'sensistive' node that an R.R.C oscillator gives. > But you take a hit in absolute tolerance, as C's are lower tolerance > than R's. > > A good challenge for students, is to get them to design a LR oscillator > ! > > > > I ended up using 555. R from output to threshold/trigger; > > C from threshold/trigger to GND. Gives nice output. Rarely seen this > > simple circuit published. > > Probably because of > a) The nasty loads often seen on 555 lash-ups :-) > b) The Bipolar 555's did not go rail-rail on the output > so Freq tolerance is not as good. > > You are right tho, a single RC two terminal config works, > ( same as HC14/40106 circuit) and well with a CMOS version > - which are just ~25c. > > Because C555's are 'everywhere', they are a better education/prototype > choice than TinyLogic, but I have seen designers swear they will never > ship anything with a 555 in it :-) > > > Only drawback I know is that output doesn't > > go rail to rail for bipolar version (but does for CMOS). > > -jg I would just use the good old fashioned Schmitt triggers. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.Article: 34167
Adrianus, Virtex II is (less than) 300 ps for the DDR setup and hold in the clock forwarded case using the DCM. The DDR clock forwarded interface requires a combination of system features to be used, and we just finished characterizing the combinations. For the non-clock forwarded DDR case, the larger numbers apply. We have released a DDR spec available to the FAE's to cover these interfaces. Single ended HSTL is another matter. 250 MHz is 500 Mb/s, and HSTL isn't the best interface to use at these frequencies. Signal integrity is going to be a PhD thesis, and coupling, noise, and jitter will be a tough system design road to travel down. I suggest you run some simple IBIS simulations to look at duty cycle, and rise and fall times of the HSTL standards at this frequency. Austin Xilinx FPGA Lab Adrianus wrote: > Hi, > > I'm looking for a device that has very small setup and hold > requirement. I'm trying to use this device to capture a 250 MHz DDR > bus with single ended HSTL level. Ideally, I would like the device to > require not more than 300 ps of setup and hold window. My gross data > window is 2ns, but after the driver clk to data skew, edge rate > effect, board effect, etc... I don't have much margin left. > > It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed > at 690 ps of setup and 0 hold. Does anyone know any other device > that's better?? > > Any help would be greatly appreciated! > > THanks, > AdrianusArticle: 34168
Hi, surely somebody else has run into this before. I am doing a prototype with a PCI interface and there isn't a prayer of making it work at 25mhz bus transfer (my slowest machine available) without a lot of effort. What would you do to easily slow things down? I know DINI group has a card for $600 that will halve the PCI clock and another for $3k which is more flexible. There's PCI-PCI bridge IP available but that's also expensive. Unfortunately I'm cheap and I'm thinking there must be a better inexpensive solution. Any thoughts? -- O..O Arcade machine collection: (----) http://www.science.wayne.edu/~joey/arcade/ ( >__< ) IRC - EFNet #rgvac: demigod2k ^^ ~~ ^^Article: 34169
I have a small board with a Virtex-E and XC18V01 PROM soldered to the board. The JTAG port is connected to the PROM only. The JTAG Programmer software talks to the Multilinx pod via serial port 1, and that works. The software can figure out the JTAG chain and the PROM chip automatically. I can then get the chip ID, signature and run an empty check with no problem, so the Multilinx hardware and my PWB seem OK. When I load up an MCS file created by promgen (Yes, I selected the correct package for the XC18V01), it all falls apart. I get "JTAG chain not defined correctly" and "check BSDL file" warnings and whatnot. I can't even do the chip ID and empty check as I could before. :-\ Everything is fine until I incorporate the PROM file. Could there be some sort of disconnect between promgen and the JTAG programmer? It almost seems as if the part data in the MCS file is wrong, and fouls up the chain definition in the JTAG Programmer. To generate the MCS file, I used: promgen -w -u 0 -x xc18v01 -p mcs bitfile.bit I think it's -p for the file type... I forget. ??? Thanks very much in advance if anyone has an idea. -- - Quiet Desperation - "The mass of men lead lives of quiet desperation." -- Henry David ThoreauArticle: 34170
Martin Rice wrote: > > Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>... > > I have a PLD circuit which requires a clock signal. I'm thinking it'd > > be really nice if I could use some of the otherwise unused gates (along > > with a cap and a couple of resistors) to generate the clock. Is this > > a bad idea, doomed to failure or is this sort of thing done all the > > time? With respect to timing circuits in general, can PLDs be used in > > place of discreet logic gates? In this particular case I'm using a > > Lattice ispLSI1016E. > > > > thanks, > > eric > > I've used a two-inverter circuit oscillator, using gates inside a > Coolrunner (Xilinx) PLD. The circuit goes: > inverter between nodes A and B > inverter between nodes B and C > 100nF between C and A > 10k between A and B > > I got nice square waves at B and C; exponential decay at A, 1.7ms > period. > > Unfortunately, the signal generated was useless as a clock for further > circuits inside the CPLD! Not sure why... the square waves had nice > clean edges. I guess the chip didn't like the slow edges at A. I > think your inverter/buffer circuit would have the same problem since > there is an exponential decay waveform at the input to the buffer. What looks 'clean' to even a 100Mhz Scope may not be a clean-enough clock signal, especially if it comes from a slow-slew oscillator! > BTW, I think your circuit would work (in non-CPLD implementation) if > you replace R2 with short. The second R is not needed for timing, what it does is provide overdrive protection, and also improves stability. Without it, you try and drive nominally 50% beyond the rails on the RC node. We have used 1R, and two equal C's to avoid both the overdrive, and the very 'sensistive' node that an R.R.C oscillator gives. But you take a hit in absolute tolerance, as C's are lower tolerance than R's. A good challenge for students, is to get them to design a LR oscillator ! > I ended up using 555. R from output to threshold/trigger; > C from threshold/trigger to GND. Gives nice output. Rarely seen this > simple circuit published. Probably because of a) The nasty loads often seen on 555 lash-ups :-) b) The Bipolar 555's did not go rail-rail on the output so Freq tolerance is not as good. You are right tho, a single RC two terminal config works, ( same as HC14/40106 circuit) and well with a CMOS version - which are just ~25c. Because C555's are 'everywhere', they are a better education/prototype choice than TinyLogic, but I have seen designers swear they will never ship anything with a 555 in it :-) > Only drawback I know is that output doesn't > go rail to rail for bipolar version (but does for CMOS). -jgArticle: 34171
DDR interfaces to Spartan/Virtex chips would seem to be sufficiently common that a reference design would be worth while. Is there such a reference design in the works? Thanks. "Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3B7AF3FA.4A934374@xilinx.com... > Adrianus, > > Virtex II is (less than) 300 ps for the DDR setup and hold in the clock > forwarded case using the DCM. The DDR clock forwarded interface requires > a combination of system features to be used, and we just finished > characterizing the combinations. > > For the non-clock forwarded DDR case, the larger numbers apply. > > We have released a DDR spec available to the FAE's to cover these > interfaces. > > Single ended HSTL is another matter. 250 MHz is 500 Mb/s, and HSTL isn't > the best interface to use at these frequencies. Signal integrity is > going to be a PhD thesis, and coupling, noise, and jitter will be a tough > system design road to travel down. > > I suggest you run some simple IBIS simulations to look at duty cycle, and > rise and fall times of the HSTL standards at this frequency. > > Austin > Xilinx FPGA Lab > > Adrianus wrote: > > > Hi, > > > > I'm looking for a device that has very small setup and hold > > requirement. I'm trying to use this device to capture a 250 MHz DDR > > bus with single ended HSTL level. Ideally, I would like the device to > > require not more than 300 ps of setup and hold window. My gross data > > window is 2ns, but after the driver clk to data skew, edge rate > > effect, board effect, etc... I don't have much margin left. > > > > It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed > > at 690 ps of setup and 0 hold. Does anyone know any other device > > that's better?? > > > > Any help would be greatly appreciated! > > > > THanks, > > Adrianus >Article: 34172
This looks interesting. How do you deal with cpu memory mapping? "Luke Roth" <roth@harp.cse.psu.edu> wrote in message news:Pine.SOL.4.33.0108151347090.7311-100000@harp.cse.psu.edu... > Alternatively, as part of my research (I'm a grad student at Penn > State) we're building an FPGA accelerator card which resides on the SDRAM > memory bus. Much faster than PCI (up to 133MHz x 64 bits vs 33MHz x 32 > bits) and _much_ lower latency. Our current board has a Virtex XCV300 and > 64MB of SDRAM, sufficient for quite a few interesting applications. > There are some limitations with this approach - for example, there > are no nice interrupt facilities as available on the PCI bus - but other > than that it seems like a great solution. We're testing our first board > now, it will interesting to see what kind of performance we can acheive > with this method. If you're interested in some more (admittedly a bit > outdated) information, check out www.cedcc.psu.edu/smartdimm/ > Luke Roth > > On Wed, 15 Aug 2001, Dave Feustel wrote: > > > I've been thinking about the i/o interface obstacle that exists between > > cpu and pci-bus mediated fpga accelerators for a couple of days now. > > I have come to the conclusion that the way to have *really* fast > > fpga accelerators is to put a hardwired cpu on the fpga chip along > > with the accelerator logic and make the entire application run > > directly from the fpga. You now can get fpgas with ARM, Powerpc > > and or other custom cpus preprogrammed into them and still have > > lots of room for your accelerator logic. IP cores for almost every > > commonly used peripheral are available to be incorporated onto > > the fpga chip - leave off the interfaces you don't need. > > Put the whole thing on a PCI card and plug it into your pc to > > make development easier(download through the pci bus). > > > > "Mike Butts" <mbutts@realizer.com> wrote in message news:3B758FB0.B98CA76A@realizer.com... > > > Dave Feustel wrote: > > > > The real short version is > > > > that the PCI bus interface is so slow relative to the > > > > speeds of the cpu and accelerator that it usually > > > > isn't worth adding an accelerator if the interface > > > > is via the PCI bus. > > > > > > This is often, but not necessarily true. Accelerator architecture > > > totally depends on your application. This is exactly what Philip > > > meant by "how long should a piece of string be". Not ridicule, > > > just maybe a little drier wit than we're used to... > > > > > > If your application depends on lots of back-and-forth > > > between the host and the card in its core kernel, PCI is usually > > > a barrier. Many early research projects in this field found this > > > out the hard way. It's not the bandwidth that matters in such > > > cases, it's the latency, the round-trip time for a single operation. > > > > > > PCI, especially as implemented in modern PCs and workstations, > > > can be very bad at that. Mark Shand gave an excellent and > > > most useful paper about this at FCCM '97, that anyone using PCI > > > must study: > > > Laurent Moll and Mark Shand. Systems performance measurement on > > > PCI Pamette. In FPGAs for Custom Computing Machines > > > (FCCM'97). IEEE, April 1997. > > > http://www.research.compaq.com/SRC/staff/shand/bib.html > > > > > > If, on the other hand, your app is a self-contained kernel that > > > grinds away mostly on its own, PCI can be fine. Often signal > > > processing apps are like this, with the signal I/O direct to > > > the card. > > > > > > I believe a very big win for reconfigurable computing is for > > > apps that demand lots of parallel memory bandwidth, since the > > > processor-memory bottleneck is so fundamental to conventional > > > computing. I'm working with a project at Oregon Graduate Institute > > > lately to develop a neural network accelerator. In our case, it's all > > > about memory bandwidth. I/O to/from the host is orders of > > > magnitude less. We're planning a PCI card with as many SDRAM DIMMs > > > as we can hook up to some FPGAs for them to grind away on matrix- > > > vector multiplies in parallel at 100 MHz. PCI will just control > > > and program the card, and feed inputs and collect results at a > > > lazy and latency-insensitive pace. > > > > > > So tell us more about your application, and maybe we can give you > > > better advice. > > > > > > --Mike > > > > > > >Article: 34173
In article <irqlnt4nqj2v1uunb4eh5r7qed4cc29041@4ax.com>, Eric Inazaki <einazaki@mac.com> wrote: >Do you recall what kind of PLD you used? Also, what frequency were >you running? In one case is was a T.I. TICPAL22V10Z running at about 5KHz. In another case it was an I.C.T. 7024 running at about 100KHz I've also made XTAL oscillators using PALs a the inverter. -- -- kensmith@rahul.net forging knowledgeArticle: 34174
In article <e00c15a3.0108151347.3b07add1@posting.google.com>, Martin Rice <jmrice@ntlworld.com> wrote: [.. RC oscillator on Cool runner...] >Unfortunately, the signal generated was useless as a clock for further >circuits inside the CPLD! Not sure why... the square waves had nice >clean edges. I guess the chip didn't like the slow edges at A. There are some funnies in the Cool-Runner that I doubt have ever been documented. If you use it for a XTAL oscillator, it is best to use up another whole cell just to buffer the signal going to the clock pin. I think the transistors in the input circuits respond up to the GHz range to funnies on the edge. >I ended up using 555. R from output to threshold/trigger; >C from threshold/trigger to GND. Gives nice output. Rarely seen this >simple circuit published. Only drawback I know is that output doesn't >go rail to rail for bipolar version (but does for CMOS). The output of the LM555 can have cross over distortion on it. If you use Pin 7 (I think) the open collector transistor driving a resistor makes quite a nice logic signal. -- -- kensmith@rahul.net forging knowledge
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