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
The best FPGA solution for PCI applications is offered by QuickLogic. They have FPGA's with embedded PCI interfaces at reasonable prices. Unlike other FPGA vendors, there is no charge for the PCI IP. They offer both Target only (QL5030) and Master/Target (QL5332) 32bit 33 Mhz cores along with a 64 bit 66 Mhz device (QL5064). In addition to the PCI core, the parts offer user logic gates that can be programmed using VHDL or Verilog. QuickLogic offers free programmed samples through there WebAsic program and you can get a 30 day Software evaluation license to use the tools. You should check out their web site at www.quicklogic.com for additional information. "Joey Oravec" <joey@sun.science.wayne.edu> wrote in message news:9lesog$f65$1@cwis-1.wayne.edu... > 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: 34201
Peter Alfke <peter.alfke@xilinx.com> wrote in message news:3B7AAEDB.47875520@xilinx.com... > Since your two clock frequencies are fundamentally phase-coherent, albeit > perhaps with a certain unpredictable tolerance, you can cross the clock-domain > boundary simply by using the opposite edge of the higher frequency clock. This > does cut into your timing budget, but is safe otherwise. > > Peter Alfke > Peter, I imagine this is the safest bet. Are you being particularly cautious because of the way this guy's clocks are arranged wrt the dlls - they don't look unusual to me. I ask because several XAPPs do not seem to take this ultra safe approach eg. XAPP214 p4 does not appear to take any 1/4 phase precautions also previous (Xilinx) answers in this group have implied that same phase data/control transfer is perfectly ok. A couple of tick box answers to clarify: 1. [ ] Are you mad! Don't ever cross between 1x & 2x domains w/o 1/4 phase precautions 2. [ ] Only cross between domains in same phase when using dlls in mode/configuration X 3. [ ] Crossing between domains in same phase is possible but 1&2x clocks must be on the same quadrant/branch of the clock tree 4. [ ] <enter own reply here> Regards, FredArticle: 34202
Mark Borgerson <mark@oes.to> wrote in message news:<3B75CFBC.72D93B07@oes.to>... > I've put together my first design targeting a Coolrunner CPLD and > gotten it to compile and generate the output files. I would > now like to edit the .ucf file so that I can arrange pins > to simplify layout on my PCB. Apparently, there are two > options: > > 1. Generate the default .ucf file with the 'lock pins' process, then > edit the .ucf file as text with notepad. The problem I'm having > is that if I go back and click on Edit UCF file under User > Constraints, Notepad opens with a blank file in the My Documents > directory. There is also a XILPerl window showing a file not > found error. Have I missed the setup of a Path variable or > something of this sort?? > > 2. If I manually open the Constraints Editor and try to open > the default UCF file I generated, I also need to provide the > name of a .NGD file. But my design process so far has not > produced a .NGD file! Have I missed a step somewhere?? > > Any help or hints would be greatly appreciated. The web pack tools > seem to be great stuff for free tools, but it seems that there > is a definite learning curve! > > Mark Borgerson XESS corporation provide a tutorial on using Webpack, that you may find useful. It's a pdf file. Find it on the www.xess.com website, click tutorials and download Introduction to Webpack 3.1. You may even find my book some use - there's a walkthrough on using Webpack with ABEL, targeted at Coolrunner. I find that, following a Lock Pins command, I *do* get a ucf file that I can edit. It's in the folder that I specified when setting up the project. It's just possible that My Documents is not a suitable place for your project. Some of the software doesn't like spaces in folder names! If possible stick to DOS names. Good luck. Once you get your first design downloaded to real hardware it's all plain sailing!!!Article: 34203
hmurray-nospam@megapathdsl.net (Hal Murray) writes: > >We are working on a design in an XC4000 about 64K gates and are having a > >problem with register replication. The P$R tool is replicating a FF that > >is the critical element of a cross clock domain synchronizer. I call > >this a "bad thing". > > Did you spot this by eyeball? Or did you encounter a problem and track > it back? > > The normal synchronizer setup is a FF, a short wire, then another FF, > with both FFs running on the same clock. > > So I assume it replicated the second FF. I thought his comment was equivalent to replicating the first FF. But Im not sure what he tried to do anyway. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 34204
The easiest way we found to memory map the device is to remain inactive during the initial bootup of the BIOS & OS, and then map the accelerator card into memory right after the standard SDRAM address space. The limitation here is that 1) the sdram on the card is only usable by accelerator-aware applications, and 2) the accelerator card must be plugged into a memory slot on the motherboard numbered higher than the rest of the standard memory modules. Both of these aren't big limitations for us. The biggest problem is that we'll need a slightly different driver for every major chipset we use the card with; right now we've standardized on the Intel 440BX chipset since it is so ubiquitous, cheap, and relatively high-performance. We are also doing all of our development in Linux, which makes writing new drivers pretty easy. Luke On Thu, 16 Aug 2001, Dave Feustel wrote: > 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: 34205
Is there any publically available info on Xilinx's upcoming Virtex Pro series of FPGAs? Thanks.Article: 34206
I recently worked on a Acex 1K30 design. I found Altera's app. note AN116 "Configuring APEX 20K, FLEX 10K, & FLEX 6000 Devices" to be very helpful. I have not looked at AN116 for the last few months, but the version I last down loaded had not been updated for the ACEX family yet. This app. note is still helpful since ACEX is basically the same as the FLEX 10K parts. Table 24 in the AN116 indicates whether or not the pins are available in User Mode. http://www.altera.com/literature/an/an116.pdf Hope this helps. Gerald "Andrew Gray" <s9813479@student.up.ac.za> wrote in message news:997947985.88785@nntp.up.ac.za... > Hi > > Can anyone tell me what the following pins are used for when they are not > used as user IO pins: > > nCEO > CS > nCS > nRS > nWS > DEV_OE > DEV_nCLR > INIT_DONE > RDY_nBSY > > Thank You > > Andrew Gray > > >Article: 34207
There are many configurations that "work". My concern is whether or not they are "safe". In the configuration you describe, the net I'd be using to drive logic and the net used to provide feedback are not the same. Therefore, the DLL will not be able to account for skew on the net I'm using. It's very hard to imagine it even being possible, but what if the 66 MHz net were so heavily loaded that it wiped out the 1/4 cycle of clock skew? Anyhow, thanks for the suggestion nonetheless. It would save me the work of adjusting the clock polarity elsewhere in the design, and Virtex 2 is more generous with BUFG(MUX) so it's okay to use an extra one. Cheers, Jamie "Philip Freidin" <philip@fliptronics.com> wrote in message news:dhqmnt8oii8p0bel5taqqnj4dffh9sacdb@4ax.com... > I created a test design to see what could be done. Here is a possible > solution: > > 33MHz mhz goes thru IBUFG then BUFG to be your clk_33 > > Output of IBUFG also goes to DCM CLKIN > > DCM CLK2X goes to a BUFG, its output goes to CLKFB > DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66 > > (assume that the two BUFGs are reasonabbly matched. Remember that you > will be adding more loads to the CLK_66 net) > > I ran the design successfully through M3.3.08i > > PhilipArticle: 34208
Dave, There is a whole range of designs/cores in process. See the TNF announcement: http://www.xilinx.com/terabit/index.htm Every single interface to all of those company's logos (parts) are DDR. Austin Dave Feustel wrote: > 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: 34209
Marc, There is an answer record for this that suggests a 120 ohm reisistor to keep the current into the io pin at less than 10 ms. I suggest you simulate the pair of chips in IBIS, no resistor at all could be the result if the current is already less than 10 mA. Many 5V parts use a stacked nmos output structure for TTL compatibility, and can not source much current at all. If the output is full cmos, then a resistor will be required. Its value is related to the maximum source current of the output at 3.3 V. This is in the IBIS model as the IV curve, and can be directly viewed for the strong/fast/cold operating voltage/process/temperature corner, or used in the simulation automatically. Austin Marc Battyani wrote: > There is a Xilinx app note (vtt002) about using 5V devices with Virtex > devices but it states explicitely that this does not work with Virtex-II. > > I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL > compatible so no pb to drive them from the Virtex-II but I have to read > values form these ADs. > > So what are the solutions for this ? (small ones please...) > > Thanks > > Marc BattyaniArticle: 34210
Does paging cause any problems? Is there a mailing list that I could subscribe to and follow your progress? Dave "Luke Roth" <roth@harp.cse.psu.edu> wrote in message news:Pine.SOL.4.33.0108161004300.1797-100000@harp.cse.psu.edu... > The easiest way we found to memory map the device is to remain > inactive during the initial bootup of the BIOS & OS, and then map the > accelerator card into memory right after the standard SDRAM address space. > The limitation here is that 1) the sdram on the card is only usable by > accelerator-aware applications, and 2) the accelerator card must be > plugged into a memory slot on the motherboard numbered higher than the > rest of the standard memory modules. Both of these aren't big limitations > for us. > The biggest problem is that we'll need a slightly different driver > for every major chipset we use the card with; right now we've standardized > on the Intel 440BX chipset since it is so ubiquitous, cheap, and > relatively high-performance. We are also doing all of our development in > Linux, which makes writing new drivers pretty easy. > Luke > On Thu, 16 Aug 2001, Dave Feustel wrote: > > > This looks interesting. How do you deal with cpu memory mapping?Article: 34211
hello all, yes, this really sounds like a stupid question. but on a second thought may be not: i have a VHDL-design which is currently under verification in RTL simulations. in parallel i have generated a bitstream for the first tests in real hardware. in order to achieve a reasonable timing on the FPGA (Xilinx Virtex) i created a floorplan using area constraints for certain blocks/hierarchies in the design. while the design is subject to modifications on RTL during the verification i need to generate new bitstreams for the hardware tests every now an then. the netlist every time i do a new synthesis differs that much from the previous version that i am not able to re-use the floorplan data as they are. unfortunately my synthesis-tool fatals when i try to do a sort of incremental synthesis, i have to generate a complete netlist every time. so i need to update the old floorplan with the new netlist which basically is a task to be done interactively / manually. all the rest of the flow (from modified RTL code to bitstream generation) is make-automated. but i have to interrupt this processing in order to do some, always the same mouse-clicks in the floorplanner-gui just to restart the same automated process afterwards. so, is there a possibility to run the Xilinx floorplanner (m3.1iSP8) in batch mode? i don't want to modify or even create the floorplan itself, i just want to update an existing one with a new netlist. any help is appreciated. cheers! olafArticle: 34212
How about just an accumulator? Continue to add the fraction of full-scale corresponding to your frequency ratio and you could use the MSbit of the accumulator as your clock (or use the rollover as a clock enable). Since you're working from 2.95MHz to 4.26MHz, your accumulator values would be about .085 to .059 of full scal when clocked by 50MHz. How precise does your frequency need to be? That will determine the size of your accumulator. You'll get a little jitter on your clock (+/- 10nS max) but it sounds like that might be a non-issue for you. Pierre de Vos wrote: > 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: 34213
Jamie Sanderson schrieb: > > Hi; > > I have a question regarding the DLL and clock to clock skew with Xilinx > Virtex2 devices. I have two groups of logic which I want to run at different > speeds. One group is at 33 MHz, and the clock net is driven without using a > DLL (ibufg directly to bufg). This is defined in their PCI core. > The other logic would benefit from running at a higher speed, but I want to > avoid any metastability issues with crossing clock domains. My questions are 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. > as follows: Should I feed the DLL using the bufg output, or should I tap > into the ibufg output? Secondly, will the software automatically account for Feed it with the first BUFG output, because you want to phase align to this clock net. > any skew between the clock nets? In other words, will it make sure that > setup/hold times are met when crossing from a register on the 33 MHz domain > and the 33*n MHz domain? Or, do I have to somehow figure out what skew is AFAIK NO. > and write an appropriate constraint? Finally, does it matter if I were using > the 2x DLL output, as opposed to the frequency synthesis output? Hmm, should be no difference. -- MFG FalkArticle: 34214
Olaf Reichenbaecher wrote: > > hello all, > > yes, this really sounds like a stupid question. but on a second thought may be not: > i have a VHDL-design which is currently under verification in RTL simulations. in parallel i have generated a bitstream for the first tests in real hardware. in order to achieve a reasonable timing on the FPGA (Xilinx Virtex) i created a floorplan using area constraints for certain blocks/hierarchies in the design. > while the design is subject to modifications on RTL during the verification i need to generate new bitstreams for the hardware tests every now an then. the netlist every time i do a new synthesis differs that much from the previous version that i am not able to re-use the floorplan data as they are. unfortunately my synthesis-tool fatals when i try to do a sort of incremental synthesis, i have to generate a complete netlist every time. so i need to update the old floorplan with the new netlist which basically is a task to be done interactively / manually. all the rest of the flow (from modified RTL code to bitstream generation) is make-automated. but i have to interrupt this processing in order to do some, always the same mouse-clicks in the floorplanner-gui just to restart the same automated process afterwards. > so, is there a possibility to run the Xilinx floorplanner (m3.1iSP8) in batch mode? i don't want to modify or even create the floorplan itself, i just want to update an existing one with a new netlist. > > any help is appreciated. > > cheers! > > olaf I'm not sure it can really help you, but you can do a manual floorplanning using wildcard in UCF files, just define some instance group using the area group command (see axemple below). Of course it requires a non flattened netlist so that instances names reflect the orginal hierachy of your design. Here is an example : INST TARGET/PROC/PE_3/* AREA_GROUP = PE_3_GRP; AREA_GROUP PE_3_GRP COMPRESSION = 2; AREA_GROUP PE_3_GRP RANGE = CLB_R8C55:CLB_R19C63 ; this will map all primitives (LUT,DFFS,etc) of the module TARGET/PROC/PE_3 to the CLB area CLB_R8C55:CLB_R19C63. Hope it can help. steven StevenArticle: 34215
--------------15D9D941924A7B1912A0F910 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Philip, I was on a call today with a customer who needs a X2, X3, and a X4 clock, both internally, and externally. And, they had to transfer data between the three new clock domains, both internally, and externally. By the time they were done dreaming, they had used nine DCM's, multiple FIFO's, (just to tranfer the internal data) and I began to get a little nervous. Not that it couldn't work, I am sure with the proper timing constraints it would eventually work, but that they were adding unnecessary complexity to a simple problem. Whatever happened to using the x4 clock as the source (an external oscillator was being used at x1 anyway), and use clock enables everywhere, and keep the thing synchronous? Totally synchronous design = best guarantee of success! Not that DCM's aren't great, but why use a new featured when the old way is probably still the best way, especially since the whole thing was synchronous at the X4 rate? With a totally synchronous design, they would still get to use the DCM's for the CLKDV /2, /3 outputs to control the clock enables. They would still need them to deskew the external clock outputs. I can understand using the DCM to deskew clocks, control phase thru the variable fine phase shift feature, or generate a 7/8, or 17/13 clock for a turbo codec. Just because it is there, doesn't mean you have to use it .... Austin Philip Freidin wrote: > I created a test design to see what could be done. Here is a possible > solution: > > 33MHz mhz goes thru IBUFG then BUFG to be your clk_33 > > Output of IBUFG also goes to DCM CLKIN > > DCM CLK2X goes to a BUFG, its output goes to CLKFB > DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66 > > (assume that the two BUFGs are reasonabbly matched. Remember that you > will be adding more loads to the CLK_66 net) > > I ran the design successfully through M3.3.08i > > Philip > > On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" <jamie@nortelnetworks.com> > wrote: > >"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. > > > > > > Philip Freidin > Fliptronics --------------15D9D941924A7B1912A0F910 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Philip, <p>I was on a call today with a customer who needs a X2, X3, and a X4 clock, both internally, and externally. And, they had to transfer data between the three new clock domains, both internally, and externally. <p>By the time they were done dreaming, they had used nine DCM's, multiple FIFO's, (just to tranfer the internal data) and I began to get a little nervous. Not that it couldn't work, I am sure with the proper timing constraints it would eventually work, but that they were adding unnecessary complexity to a simple problem. <p>Whatever happened to using the x4 clock as the source (an external oscillator was being used at x1 anyway), and use clock enables everywhere, and keep the thing synchronous? Totally synchronous design = best guarantee of success! <p>Not that DCM's aren't great, but why use a new featured when the old way is probably still the best way, especially since the whole thing was synchronous at the X4 rate? With a totally synchronous design, they would still get to use the DCM's for the CLKDV /2, /3 outputs to control the clock enables. They would still need them to deskew the external clock outputs. <p>I can understand using the DCM to deskew clocks, control phase thru the variable fine phase shift feature, or generate a 7/8, or 17/13 clock for a turbo codec. <p>Just because it is there, doesn't mean you <b>have</b> to use it .... <p>Austin <p>Philip Freidin wrote: <blockquote TYPE=CITE>I created a test design to see what could be done. Here is a possible <br>solution: <p>33MHz mhz goes thru IBUFG then BUFG to be your clk_33 <p>Output of IBUFG also goes to DCM CLKIN <p>DCM CLK2X goes to a BUFG, its output goes to CLKFB <br>DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66 <p>(assume that the two BUFGs are reasonabbly matched. Remember that you <br>will be adding more loads to the CLK_66 net) <p>I ran the design successfully through M3.3.08i <p>Philip <p>On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" <jamie@nortelnetworks.com> <br>wrote: <br>>"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message <br>><a href="news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com">news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com</a>... <br>> <br>>> I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think <br>>> that allows me to use rising edge clocks everywhere, while providing a <br>>> quarter clock period of setup/hold between the clock domains. <br>> <br>>Hmm, this gives me a mapper error <br>> <br>>ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not <br>> <br>>driven by the CLK0 or CLK2X pin of the same DCM. <br>> <br>>Errors found during the mapping phase. Output files will not be written. <br>> <br>>That's annoying... Back to the drawing board. <br>> <br>> <p>Philip Freidin <br>Fliptronics</blockquote> </html> --------------15D9D941924A7B1912A0F910--Article: 34216
> The best FPGA solution for PCI applications is offered by QuickLogic. I don't know if it's "the best", but it certainly is very good...but has one major drawback..those parts are expensive and they are OTP.Article: 34217
There is really no reason you can not make 25MHz, much less 33MHz with your FPGA...if you're in an appropriate part, and your logic is "correct". What part are you using, and what is causing your PCI interface to be so slow? Please be very specific in this answer if you could, and I might be able to help you. "Joey Oravec" <joey@sun.science.wayne.edu> wrote in message news:9lesog$f65$1@cwis-1.wayne.edu... > 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: 34218
> The safest option would be to get a motherboard that can be underclocked in > BIOS. I've successfully used the Abit SA6R, setting FSB to 60 MHz, clock > ratio to 4:4:1, resulting in 15 MHz PCI. > > Alternatively, you can check if you motherboard is supported by CPUCooL > (http://www.podien.onlinehome.de/). It can change the PLL settings on many > motherboard, even if the BIOS doesn't support that. Even better, it can be > changed *runtime*, thus you can throttle your clock without rebooting > in-between each attempt (as long as you don't lock up the system.....) > > Regards, > - Olaf That is very good information, Olaf. Thank you.Article: 34219
"Austin Lesea" <austin.lesea@xilinx.com> wrote > Marc, > > There is an answer record for this that suggests a 120 ohm reisistor to keep > the current into the io pin at less than 10 ms. > > I suggest you simulate the pair of chips in IBIS, no resistor at all could be > the result if the current is already less than 10 mA. > > Many 5V parts use a stacked nmos output structure for TTL compatibility, and > can not source much current at all. If the output is full cmos, then a > resistor will be required. Its value is related to the maximum source > current of the output at 3.3 V. This is in the IBIS model as the IV curve, > and can be directly viewed for the strong/fast/cold operating > voltage/process/temperature corner, or used in the simulation automatically. Thanks, a resistor is fine for me. But why do you state in vtt002.pdf that : "Note: This does not apply to the Virtex-II family of devices, which are 3.3 V compliant only." Is there another app note for the Virtex-II ? MarcArticle: 34220
Go to http://www.xilinx.com/events/seminars/xtremedsp.htm Follow the link to "Go to Video On Demand Page*" (you will need to be registered, it's free) Then download the PDF for section 7. The last bunch of pages covers V-II-P Philip On Thu, 16 Aug 2001 14:16:27 GMT, "Dave Feustel" <dfeustel1@home.com> wrote: >Is there any publically available info on >Xilinx's upcoming Virtex Pro series of FPGAs? > >Thanks. > Philip Freidin FliptronicsArticle: 34221
Marc, There are a bunch of parts one can use to bridge the 5V <--> 3.3V gap. Basically, they're the usual sort of buffer types: '245, '541, '573, '573, '823. They're in various logic families: LPT, FCT, etc. See the Pericom or IDT web sites for examples. Look for devices that have 3.3V power rails and are 5V tolerant. -andy Marc Battyani wrote: > > There is a Xilinx app note (vtt002) about using 5V devices with Virtex > devices but it states explicitely that this does not work with Virtex-II. > > I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL > compatible so no pb to drive them from the Virtex-II but I have to read > values form these ADs. > > So what are the solutions for this ? (small ones please...) > > Thanks > > Marc BattyaniArticle: 34222
Martin Rice wrote: > <<SNIP>> > XESS corporation provide a tutorial on using Webpack, that you may > find useful. It's a pdf file. Find it on the www.xess.com website, > click tutorials and download Introduction to Webpack 3.1. > > You may even find my book some use - there's a walkthrough on using > Webpack with ABEL, targeted at Coolrunner. > > I find that, following a Lock Pins command, I *do* get a ucf file that > I can edit. It's in the folder that I specified when setting up the > project. It's just possible that My Documents is not a suitable place > for your project. Some of the software doesn't like spaces in folder > names! If possible stick to DOS names. I got the .ucf file all right. The problem was that when I click the 'edit ucf file' entry in the project manager, it trys to find the file in 'my documents'. My project lives in a folder in the XILINX folder. I did find it was simply easier to open the folder in the windows explorer and double-click the .ucf file. Notepad opens with the file and I'm set to go. > > Good luck. Once you get your first design downloaded to real hardware > it's all plain sailing!!! I'm looking forward to that moment! The parallel port programmer and first 5 chips are here from Xilinx. The PC board should be here Monday. It was a blast doing the PCB layout! After I got the schematic together, I loaded the netlist and looked at the rats nest while rotating the part. Massive net crossovers! So I edited the CPLD pin assignments to simplify the layout and got the PCB laid out in about 1/3 the time it took to do the same job with SSI and MSI parts. Parts cost will be down by about 50% over the MSI solution, too! THIS IS COOL STUFF! <VBG> I'll look over the XESS tutorial. Thanks for the pointer. Mark BorgersonArticle: 34223
Kevin Brace wrote: > I recently fired up Insight Electronics Spartan II PCI > development board (http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.html) > with my own PCI IP core (I didn't use Xilinx's PCI IP core), and even > though the timing analyzer told me that some of the input signals > require around 12ns Tsu, and around 15ns Tval for output signals, the > board was recognized as a PCI device by the BIOS, and Windows 98 > detected the PCI card automatically at startup. > This means that the PCI card with my PCI IP core worked even though > the timings were not being met. > The motherboard had 430TX chipset on it, and the PCI bus ran at 33MHz. > My theory that the reason PCI card worked is that the PCI card used > some of the Tprop (10ns. bus propagation time (the time signals travel > on the PCB)) to meet the Tsu/Tval requirements. > For the P&R (Place & Route), I used the the one that came with > WebPack, and used only a User Constraint File to specify the timings I > wanted. > Since the PCI card with my PCI IP core that violated the timings > worked okay at 33MHz, I will suspect that your problem is not the > timings, but with your state machine design. Don't forget that the timing analyzer reports worst-case numbers, and the real part may be substantially better. The next batch of chips may not be as good, or you could run into problems as the chassis heats up, or whatever. Methinks you're lucky. You should buy a lottery ticket! -andyArticle: 34224
I'm with Falk here. Buy a target device (like the 9030), and let that handle all of your PCI stuff. The 9030 has a local bus that can be clocked from essentially DC to 60 MHz, and it does a lot of stuff for you. You shouldn't be reinventing the wheel unless you've got a Real Good Reason to do so! -andy Joey Oravec wrote: > > 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 > ^^ ~~ ^^
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