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
Sylvain Munaut wrote: > > Simon wrote: > > Sylvain Munaut wrote: > >> Thanks for your answer. > >> > >> I was indeed planning 2 x 16 bits chips as I don't know any 32 bits ones. > >> > >> I've also seen some reference to a micro app note about terminations, > >> I'll have a look. > >> > >> IIRC, the best way to connect two chips would be > > > > > > (perhaps something missing ?) > > Yes ;) > I meant that I should avoid T in the lines but instead put the chips inline. iow, the tracks go from fpga to first chip then from there to the second one. And avoid going from the fpga then split in two branch, one to chip1 the other to chip2. > > > I'm thinking of the same sort of thing - it depends on how much RAM you > > want, but there's a Micron 1Mx32x4 chip I found (Farnell order #5088793) > > that's a TSOP package that might be of interest... > > That chip would be more that enough in fact I was planning for 8Mbytes. But with 32 bit width, I'll have 16Mb, that's ok. > But these are SDRam, not DDR. Well I'll see what I take because DDR seem harder to drive than SDR and I also'd like to spare space in the FPGA, else I won't have any space to put stuff that could use the extra bandwidth. Even more important than avoiding T connections, is keeping them short, very short. You can even drive a star arrangement if you can keep all traces to about 1 inch (2.5 cm) or so. The reflections are then a small fraction of the rise time and will not be significant. Or you can make every memory pin a separate net and use simple series resistors (which can be integrated in some FPGAs) on the outputs. Point to point drivers are very simple and hard to screw up. Also, if you are at all concerned about a long life for your product, you should go with DDR. SDRAM is already on the way down the curve and will only get more expensive in the future (unless we have another bust cycle). 32 bit parts are niche parts like most SRAM, 16 bit parts are more mainstream, but not quite jellybean while the 8 bit parts which are used widely in PCs are fully commodities which will be the low cost per bit of any memory. You can even get them in extra small packages (which are used for laptops). I don't know if any of this is a consideration for you. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71851
M.Randelzhofer wrote: > Hi ng, > > i try to understand the Xilinx Spartan2 pinout data sheet. > Some VCCO's at different banks have the same pin number. > > See: > http://direct.xilinx.com/bvdocs/publications/ds001_4.pdf > > E.g. XC2S100-TQ144 pin16 or pin53 and many others. > > The mistakes are so regularly, that i wonder if i miss anything here... > > Thanks for any eye openings. > > MIKE > > > It is just to have the same table for all the package. Laurent www.amontec.comArticle: 71852
I have asked my friends in Spartan-land to add a sentence at the bottom of the pin-out table explaining this "pin-economy" trick. One redundant sentence can save a lot of irritation... Peter AlfkeArticle: 71853
glen herrmannsfeldt wrote: > (previously snipped question about high speed time measurements) > > Peter Alfke wrote: > >> Here are my thoughts for a fairly simple implementation. If I recall, the >> original post asked for a report of the arrival time of input pulses >> (let's >> assume rising edges) with a resolution of 1 ns. > > > (snip) > > If I understand the way it is done in some experiments requiring > sub nanosecond timing, they call it a TDC, time to digital converter, > and it seems to work by generating a ramp signal, and digitizing > it with a flash A/D converter at the trigger point. Maybe a 100MHz > counter, and the sawtooth/ADC to get the low order bits. It might > take some calibration, but numbers in the 100ps range seem to be > easily obtained. 100MHz and a 6 bit ADC would give > 10ns/64 or 156.25ps. > > -- glen > how closely matched are the IOs assuming you stay within the same bank? 1ns is only about 140mm of trace on FR4 -LasseArticle: 71854
Hi Philip, Thanks for the link! As you say, a pretty good article. There's one little thing I'd like to say! I prefer the circuit Rick presented here on CAF over the one presented in fig.3. Search Google Groups for subject "Async logic in FPGAs" in comp.arch.fpga . Rick's circuit works well even if the signal to be synchronised can clock faster than the synchronising clock. Of course, some of the faster clock's transitions can still be missed, but any burst of, for example, two fast clocks on the input signal will (almost*) always be caught by at least one clock enable in the synchronised domain. A practical example of this is debouncing a switch input with a slow clock. Imagine a key switch input being sampled at 1kHz. The circuit in Fig.3 could miss the key press if the bouncy signal has an even number of rising edges. Rick's circuit gets the bugger (almost*) everytime! Cheers, Syms. * Metastability is always possible, no matter how remote that possibility. In the 1kHz example the synchronising circuit could stay metastable for 1ms! "Philip Freidin" <philip@fliptronics.com> wrote in message news:6u7rg016f8rbp2oc49lnr5t1mrc56gatr1@4ax.com... > There is a fairly well written article on crossing clock domains > that has been published this week. The online version is at: > > http://www.chipdesignmag.com/display.php?articleId=32&issueId=5 > > There is a minor problem with the figure numbers in the text (off by one) > but it is pretty obvious. > > PhilipArticle: 71855
Hi all, I have been using the xilinx ultraContrller design pretty succesfully but I need to add/change the peripheral setup. The design comes with 32 bit GPIO and a software based serial communication and some memory, none of which are connected on the PLB or OPB. In fact there is no OPB or PLB instantiated in the design. The serial communication drivers are blocking and I would like to change this to nonblocking. I believe i need to add a plb UART to make it nonblocking. Is this correct? and to do this I also need to add a PLB bus. Does it make more sense to create a new EDK project and add a plb bus, plb uart and plb gpio instead of builing on what I have already. I have tried this but have had very little luck getting the connections correct and then figuring out how to do the memory layout. Suggestions for a newbie to using EDK successfully would be much appreciated. Thanks MattArticle: 71856
Hi I'm playing around w/ a Xess XSA-50 board for a summer project. I'd like to configure the onboard Xilinx Spartan fpga via the prototyping header pins instead of the parallel port. I'm finding this quite complicated so far, even after (because of) reading the tiny section in the XSA documentation dedicated to programming w/ the header pins; any advice on it from those more experienced? The clocking sequence and configuration bitstream will be coming from another Xilinx fpga that's being streamed the .bit configuration file from a computer. I've already erased the CPLD on the XSA-50 so that it doesn't interfere w/ the configuration but the Spartan doesn't even seem to be acknowledging the process. Thanks for reading cargopatch@gmail.comArticle: 71857
140 mm is a long distance, almost six inches in Imperial units :-) With careful lay-out you can avoid errors down to <100 ps, perhaps even 50 ps. Peter Alfke > From: Lasse Langwadt Christensen <langwadt@ieee.org> > Organization: Cybercity > Newsgroups: comp.arch.fpga > Date: Mon, 02 Aug 2004 23:12:17 +0200 > Subject: Re: 1GHz FPGA counters > > glen herrmannsfeldt wrote: >> (previously snipped question about high speed time measurements) >> >> Peter Alfke wrote: >> >>> Here are my thoughts for a fairly simple implementation. If I recall, the >>> original post asked for a report of the arrival time of input pulses >>> (let's >>> assume rising edges) with a resolution of 1 ns. >> >> >> (snip) >> >> If I understand the way it is done in some experiments requiring >> sub nanosecond timing, they call it a TDC, time to digital converter, >> and it seems to work by generating a ramp signal, and digitizing >> it with a flash A/D converter at the trigger point. Maybe a 100MHz >> counter, and the sawtooth/ADC to get the low order bits. It might >> take some calibration, but numbers in the 100ps range seem to be >> easily obtained. 100MHz and a 6 bit ADC would give >> 10ns/64 or 156.25ps. >> >> -- glen >> > > how closely matched are the IOs assuming you stay within the same bank? > 1ns is only about 140mm of trace on FR4 > > -Lasse > >Article: 71858
Well it seems that the board I need doesn't exist or at least no one knows of one and therefore I will need to design it myself. Like I said earlier, I don't know much about PCB design, so if someone could refer me to a good guide that would be great. Also, what software would be best to use considering what I require for my PCB (40x30x10 mm, flash ROM, oscillator, FPGA), also consider I'm running Windows XP. Thanks for any help. -DAGArticle: 71859
Sylvain Munaut wrote: <snip> > That chip would be more that enough in fact I was planning for 8Mbytes. > But with 32 bit width, I'll have 16Mb, that's ok. > But these are SDRam, not DDR. Well I'll see what I take because DDR seem > harder to drive than SDR and I also'd like to spare space in the FPGA, > else I won't have any space to put stuff that could use the extra > bandwidth. With wider memory, you get more Bytes/ns, and I would suggest a look at std Sync SRAM, as well as the Celluar PSRAM from Micron, as these are getting to this Size in a single device. Package may be more an issue ? A single RAM device will be much easier to route, than many devices. -jgArticle: 71860
I know (from my own experience) that it is tempting to design something small and neat. But I have also seen many failures when there just was not enough room to complete the design properly. My advice is: Think twice ( or thrice) before committing to a very tight footprint. Peter Alfke =================== > From: daragoth@kuririnmail.com (Daragoth) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 2 Aug 2004 15:49:18 -0700 > Subject: Re: Compact FPGA Board? > > Well it seems that the board I need doesn't exist or at least no one > knows of one and therefore I will need to design it myself. Like I > said earlier, I don't know much about PCB design, so if someone could > refer me to a good guide that would be great. Also, what software > would be best to use considering what I require for my PCB (40x30x10 > mm, flash ROM, oscillator, FPGA), also consider I'm running Windows > XP. Thanks for any help. > > -DAGArticle: 71861
Daragoth wrote: > Well it seems that the board I need doesn't exist or at least no one > knows of one and therefore I will need to design it myself. Like I > said earlier, I don't know much about PCB design, so if someone could > refer me to a good guide that would be great. Also, what software > would be best to use considering what I require for my PCB (40x30x10 > mm, flash ROM, oscillator, FPGA), also consider I'm running Windows > XP. Thanks for any help. > > -DAG Did you look at the ones at www.quickcores.com - they are smaller than your target size ? -jgArticle: 71862
Hi Symon, On Mon, 2 Aug 2004 14:15:01 -0700, "Symon" <symon_brewer@hotmail.com> wrote: >Hi Philip, >Thanks for the link! As you say, a pretty good article. >There's one little thing I'd like to say! I prefer the circuit Rick >presented here on CAF over the one presented in fig.3. Search Google Groups >for subject "Async logic in FPGAs" in comp.arch.fpga . Or in the archive at www.FPGA-FAQ.com article 59400. >Rick's circuit works >well even if the signal to be synchronised can clock faster than the >synchronising clock. Of course, some of the faster clock's transitions can >still be missed, but any burst of, for example, two fast clocks on the input >signal will (almost*) always be caught by at least one clock enable in the >synchronised domain. I agree, Rick's design is a better way to pass the flag than Roy's figure 3. >A practical example of this is debouncing a switch input with a slow clock. >Imagine a key switch input being sampled at 1kHz. The circuit in Fig.3 could >miss the key press if the bouncy signal has an even number of rising edges. >Rick's circuit gets the bugger (almost*) everytime! >Cheers, Syms. > >* Metastability is always possible, no matter how remote that possibility. >In the 1kHz example the synchronising circuit could stay metastable for 1ms! I have added links to both of these articles, and also some articles by Peter Alfke at the end of the FAQ page on metastables at http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm Thanks again for the ref to a good article, Philip =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 71863
On 2 Aug 2004 15:49:18 -0700, daragoth@kuririnmail.com (Daragoth) wrote: >Well it seems that the board I need doesn't exist or at least no one >knows of one and therefore I will need to design it myself. Like I >said earlier, I don't know much about PCB design, so if someone could >refer me to a good guide that would be great. try http://alternatezone.com/electronics/files/PCBDesignTutorialRevA.pdf >Also, what software >would be best to use considering what I require for my PCB (40x30x10 >mm, flash ROM, oscillator, FPGA), also consider I'm running Windows >XP. Thanks for any help. You could try this freeware version: http://www.cadsoft.de/freeware.htm >-DAG Philip Philip Freidin FliptronicsArticle: 71864
Peter Alfke wrote: > 140 mm is a long distance, almost six inches in Imperial units :-) > With careful lay-out you can avoid errors down to <100 ps, perhaps even 50 > ps. > Peter Alfke > it's about the same as the distance around a FF1152 package ;) -Lasse > >>From: Lasse Langwadt Christensen <langwadt@ieee.org> >>Organization: Cybercity >>Newsgroups: comp.arch.fpga >>Date: Mon, 02 Aug 2004 23:12:17 +0200 >>Subject: Re: 1GHz FPGA counters >> >>glen herrmannsfeldt wrote: >> >>>(previously snipped question about high speed time measurements) >>> >>>Peter Alfke wrote: >>> >>> >>>>Here are my thoughts for a fairly simple implementation. If I recall, the >>>>original post asked for a report of the arrival time of input pulses >>>>(let's >>>>assume rising edges) with a resolution of 1 ns. >>> >>> >>>(snip) >>> >>>If I understand the way it is done in some experiments requiring >>>sub nanosecond timing, they call it a TDC, time to digital converter, >>>and it seems to work by generating a ramp signal, and digitizing >>>it with a flash A/D converter at the trigger point. Maybe a 100MHz >>>counter, and the sawtooth/ADC to get the low order bits. It might >>>take some calibration, but numbers in the 100ps range seem to be >>>easily obtained. 100MHz and a 6 bit ADC would give >>>10ns/64 or 156.25ps. >>> >>>-- glen >>> >> >>how closely matched are the IOs assuming you stay within the same bank? >>1ns is only about 140mm of trace on FR4 >> >>-Lasse >> >> > >Article: 71865
I've got a minor DSP/comm task to put in an FPGA: Complex demod to baseband, CIC+decimate+FIR LPF chain, magnitude estimate, some FSK and DPSK data to interpolate, correlate and extract, plus other sundry tasks. I'd like to model this all in untimed/behavioral floating-point, have a quick way to evaluate filtering options (including IIR, varying lengths and structures/forms) and quantization effects, with automatic conversion to a somewhat optimal fixed-point implementation that a tool can automatically write out as VHDL (RTL, not behavioral). Parameterizable block diagram entry is a plus. Probes/sinks with FFT and time plots and file writes at nodes of interest are also desireable. (SUMMARY: design/analyze at high level, let tools do dirty, low-level work.) Maybe I ask too much ;-) but it seems like this is such a common problem and flow that solutions would abound. However, I've been out of the DSP world for a while, and don't know what the best, cheapest, or most productive tool options are... What would the gurus of comp.dsp and comp.arch.fpga suggest? I have access to MathCad, Matlab (with FDAT), Simulink, and possibly LabView (National Instruments?) and (Cocentric System Studio (Synopys) but am not fluent with them. I've entered the design in Cadence/CoWare's SPW, but am getting frustrated with it -- not as easy to explore different architectures as I had hoped. I suppose Ptolemy is an option, if the learning curve is not staggering. Agilent has some Ptolemy add-ons for fixed-point analysis and optimization, but they're not free or in my company's budget for this project. Any and all constructive suggestions are very much appreciated; thanks in advance... MarkJArticle: 71866
Mark wrote: > What would the gurus of comp.dsp and comp.arch.fpga suggest? > > I have access to MathCad, Matlab (with FDAT), Simulink, Do you know the Xilinx extension to Simulink, which is called SystemGenerator? You can set up a behavioral simulation within Simulink. From this simulation you go to VHDL code just by pressing a button. I tried it in a small task, and it worked really fine. Certainly, it will not make the best out of the possibilities VHDL provides - and there's a good chance that it wastes lots of the resources of an FPGA. But I always ended up with synthesized code which did what it was expected to. This tool chain is rather new - and will need some time to mature, but even if it won't solve your task completely, it might be a good starting point for evaluation. BernhardArticle: 71867
Peter Alfke wrote: > I have asked my friends in Spartan-land to add a sentence at the bottom of > the pin-out table explaining this "pin-economy" trick. > One redundant sentence can save a lot of irritation... > Peter Alfke > Thanks Peter LarryArticle: 71868
Dear All, Is it possible to generate 1843200 Hz clock using a 10 MHz clock in vhdl. If yes, would it be possible to give me the algorithm and I will try to implement it. I did a clock divider, but it does work only when the quotient is a power of 2. Looking forward to hear from u, Best regards, John.Article: 71869
thx Victor, it is working now. Best regards, John "Victor Schutte" <victors@mweb.co.za> wrote in message news:<cel9fb$e5u$1@ctb-nnrp2.saix.net>... > Before downloading type in: > > nr -t > > > Enter a view times to see if NIOS dumps memory. If nothing happens check you > port/cable. Make sure the pins are correctly connected to the Rx and TX via > your FPGA. > > Did you successfully downloaded a program before? > > > Looking at your 1st post it seems that if was actually downloading. If it > downloads and then stops/terminates then your program is crashing. Are you > compiling standard examples on the dev. board or have you modified your > hello_nios.c or running on your own board? One of the main problems I have > found was a dry joint/ missing pin on one of the addr/data lines. The > program downloads , but the memory is only receiving garbage. After > completion the Go command sends it to the execution point where it basically > runs random code. To verify this make sure you can do the 'nr -t' thing. If > you can then check your target memory e.g. 0x1000000 with "m1000000". If it > dumps memory then try and change it e.g. "m1000000:1234". Recheck the memory > with "m1000000" to verify that the memory is writeable and that the correct > data is stored. Also make sure that the next memory word is not altered > (very common). > > Good luck > > Victor > > "John" <johngalil@hotmail.com> wrote in message > news:46532e21.0408011924.5693e366@posting.google.com... > > "Subroto Datta" <sdatta@altera.com> wrote in message > news:<D87Pc.3805$tF3.2388@newssvr32.news.prodigy.com>... > > > Before downloading the srec, make sure that you have programmed the FPGA > > > device on the board using the programming file generated by Quartus. > > > > > > Hope this helps. > > > > > > - Subroto Datta > > > Altera Corp. > > > > Dear Subroto, > > > > Do u mean the .sof file? > > > > if you meant the .sof file, yes I did download it to the stratix chip > > before running the .srec! > > > > Thank you, > > johnArticle: 71870
On 2 Aug 2004 23:17:11 -0700, johngalil@hotmail.com (John) wrote: >Dear All, > >Is it possible to generate 1843200 Hz clock using a 10 MHz clock in >vhdl. If yes, would it be possible to give me the algorithm and I will >try to implement it. I did a clock divider, but it does work only when >the quotient is a power of 2. http://fractional-divider.tripod.com/ contains a perl script that generates fractional-N dividers in both VHDL and Verilog. It used 28 ff for your exact frequency ratio. Relaxing the frequency tolerance to 0.1% (this is a baud rate generater, right?) reduced the size to 12 ff. Regards, Allan.Article: 71871
Hello ng, what's the expected supply current of spartan-3 VCCAUX 2.5V ? I saw in the datasheet, that it's quiescent current is in the range of vccint. Is it in general in the range of vccint ? Does it depend mainly on the usage of the DCM'S ? Is a 150mA regulator sufficient ? Is an analog regulator preferred over a switching type ? I want to use an X3S200 or X3S400 part. Thanks for any info MIKEArticle: 71872
hi, The freeware winfilter can generate VHDL code for fir filter (8 or 16-bit) coefficients. http://wwww.winfilter.20m.com Regards, Adrian Mark wrote: > I've got a minor DSP/comm task to put in an FPGA: > > Complex demod to baseband, CIC+decimate+FIR LPF chain, magnitude > estimate, some FSK and DPSK data to interpolate, correlate and > extract, plus other sundry tasks. > > I'd like to model this all in untimed/behavioral floating-point, have > a quick way to evaluate filtering options (including IIR, varying > lengths and structures/forms) and quantization effects, with automatic > conversion to a somewhat optimal fixed-point implementation that a > tool can automatically write out as VHDL (RTL, not behavioral). > Parameterizable block diagram entry is a plus. Probes/sinks with FFT > and time plots and file writes at nodes of interest are also > desireable. (SUMMARY: design/analyze at high level, let tools do > dirty, low-level work.) > > Maybe I ask too much ;-) but it seems like this is such a common > problem and flow that solutions would abound. However, I've been out > of the DSP world for a while, and don't know what the best, cheapest, > or most productive tool options are... > > What would the gurus of comp.dsp and comp.arch.fpga suggest? > > I have access to MathCad, Matlab (with FDAT), Simulink, and possibly > LabView (National Instruments?) and (Cocentric System Studio (Synopys) > but am not fluent with them. > > I've entered the design in Cadence/CoWare's SPW, but am getting > frustrated with it -- not as easy to explore different architectures > as I had hoped. > > I suppose Ptolemy is an option, if the learning curve is not > staggering. Agilent has some Ptolemy add-ons for fixed-point analysis > and optimization, but they're not free or in my company's budget for > this project. > > Any and all constructive suggestions are very much appreciated; thanks > in advance... > > MarkJ -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----Article: 71873
Hi, I have written VHDL code which generates standard VGA Timing signals; 640 x 480 resolution 60Hz refresh rate. My question is this; my test monitor is a SONY SDM-S93 which has a resolution of 1280 x 1024, the HSync, VSync and Blanking periods all meet with the specifications of the monitor. However how does the monitor know that i will only use 640 out of a possible 1280 dots per line, and 480 lines out of 1024? Do i have to send it some control info via the DC0-3 pins? I understand that the monitor can display lower resolutions because this can be done inside windows! When selecting 640x480 resolution in windows the screen is stretched to fill the monitor; does this mean that the graphics card is always running at the 1280x1024 frequency and adds pixel data to fill the screen? Thanks for the help. MattArticle: 71874
I don't know of any ready-to-use solution for this, so I guess you will have to design your own. You could use a user-JTAG module in your design (have a look at BSCAN_SPARTAN3 in the libraries guide). This will allow you get data in and out of your FPGA through the JTAG port. Then you will need a little logic to interface the JTAG module with your SRAM controller. On the PC side, you will need to write a small application that writes the data to your JTAG controller (parallel cable III or IV). A so-called "Tcl/JTAG Interface" which provides all the basic JTAG functions is available from Xilinx and comes with the Chipscope Pro Software ; have a look at the Chipscope manual. Hope this helps. Have fun, Guy. Vivek Joshi wrote: > I had a question on whether you can use Chipscope pro to load an external SRAM connected to the FPGA. I want to use ChipSCope Pro to load data into an SRAM, is there a way to automate this, any suggestions or comments regarding this? Is this a feasible idea?
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