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
We have got a Virtex-II Multimedia Board which include CF card slot. http://www.xilinx.com/xlnx/xebiz/board_detail.jsp?=3D&category=3D-21481&i= Lan guageID=3D1&key=3DHW-V2000-MLTA How to visit the files in CF cards? Can I just copy the files to the CF card? Or have to build some described files to let SystemACE recognize the file? =20 =20Article: 62926
Hi all, I have a design which takes data from an external ADC. The ADC provides a 35 Mhz clock. Currently the design feeds the input clock through a DCM and uses the 180 degree phase shifted version to sample and reassemble the ADC data. This all then passes to our system clock domain via one of the (wonderfully useful) Xilinx self addressing asychronous FIFO's. As this is for a communications system we need to perform clock recovery (actually this might be better described as carrier recovery) and the ADC provides a means to tune the clock it uses to sample with. Of course this means that the clock we are feeding into the DCM to get our internal sampling clock (and driving the SAF - in essense a block RAM) is going to be changing. Each change could be in the order of 200 Hz and performed a few thousand times a second. The total change from the clock the DCM locked with could be up to 100 KHz but I could bodge...ahem...design my way round this to make it significantly less. Although the above is working fine at the moment I am worried about the DCM loosing its lock due to the varying input clock. Can anyone suggest how much the DCM will tolerate before throwing a wobbly? Thanks, AndyArticle: 62927
takkaya <takkaya@hotmail.com> wrote in message news:5c8d9153.0311110158.db6a06b@posting.google.com... > I am targeting a Spartan IIE (400E) device with four global clock > buffers (BUFG) and four DLL's. > > But I need five clock domains 25MHz(clkin, DLL1), 50MHz (clk2x, DLL1) > and 30MHz (clkdv, DLL2), 60MHz (clkin, DLL2), 120MHz (clk2x, DLL2) in > my design. > I know that it is not allowed to use more than 2 BUFG per DLL. > I would like to use the DLL's to have a zero propagation delay and low > clock skew between output clock signals distributed throughout the > device. The primary global nets are driven by global buffers (25, 50, > 60 and 120 MHz). > The 30 MHz clock domain (internal) is not so critical, so maybe I can > use a secondary global nets? > How can I drive the secondary global nets with an output of the DLL > e.g. the 30 MHz? > Thanks in advance. Generate a /2 enable signal off the 60MHz clock and use this with the 60MHz clock to drive logic at 30MHz. You could give this a multi-cycle path constraint for P+R, but 60MHz isn't that fast so unless your device is very full you could probably get away without this. Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 62928
Dear Mr Bromley, it is the following background: The 32-bit vector can have up to 4 locations with '1', for example 0000 1000 0000 0000 0101 0000 0000 0100 The ones indicate that a data packet has been found at the different write-address-positions of a cam. In a second step I have to fulfill a second check in a separate RAM structure. For this purpose I want to create out of the 32-bit-HIT-vector 4 addresses. In the example shown that would mean that I have to create the following addresses (for the second check step): 1. b00010 2. b01010 3. b01110 4. b11011 These addresses will then be assigned sequentially to the RAM wraddress port. So is there a possibility to get these four addresses out of the 32-bit-vector within one clock cycle? Thanks a lot. Best Regards Andres V.Article: 62929
Hi Jason, "Jason Berringer" <look_at_bottom_of@email.com> writes: <snip> > I would like to see if possible some proven layouts showing where the caps > are mounted and there possition relative to the power pins (and see how > close they are). I've seen a lot of layouts where there are a few caps in > the center of the IC on the underside of the board, but this does not lend > itself nicely to the idea of being as close as possible to the pins. I have > also seen the Xilinx app note on BGA routing which is very helpful, but > again no capacitor placement is shown. > <snip> If you have solid planes (prefereably closely spaced) you don't need to worry about 'close' in the sense that you probably think of as close. If you have vias to the planes on *very* short tracks, or even better in the pad, then the planes will act as a very low impedance route for your currents. If you think of the time the energy will take to travel from capacitor to chip, the speed of light on FR4 is around 2/3c or 2e8 m/s. In 1ns, this is around 20cm. Halve this for the energy to get back and forth and even 10cm is "close". I don't have any pictures to hand, but we've done boards like this with 100MHz memory interfaces and 150MHz core DSP clocks that work fine. Does that help? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 62930
"Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0311110648.5e79e75c@posting.google.com... > The 32-bit vector can have up to 4 locations with '1', for example > > 0000 1000 0000 0000 0101 0000 0000 0100 > > I want to create out of the 32-bit-HIT-vector 4 addresses. > In the example shown that would mean that I have to create the > following > addresses (for the second check step): > 1. b00010 > 2. b01010 > 3. b01110 > 4. b11011 That is a VERY different problem from the one you first posted! > So is there a possibility to get these four addresses out of the > 32-bit-vector within one clock cycle? I'm sure it is possible, but it is certainly difficult and I cannot see a clean solution right now. However... > These addresses will then be assigned sequentially > to the RAM wraddress port. If the four RAM writes are to be sequential, why not obtain the four addresses sequentially? That would be much simpler. Use a priority encoder (as Valentin suggested) to locate the first 1 bit. Then, while you are writing to the chosen RAM location, clear that first bit to 0 and use the same priority encoder again to find the second 1 bit. Keep going like this until you have cleared the whole 32-bit input word to zero. A 32-to-5-bit priority encoder is not trivial, but it should be OK unless your clock speed is very fast. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 62931
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:<jfgqb.87097$ao4.265693@attbi_s51>... > "Michelle" <sleepymish@hotmail.com> wrote in message > news:2b3db7ca.0311050941.3dc9ee2c@posting.google.com... > > Hi, > > > > I'm a newbie to FPGA and Linux world. I have a general question > > concerning both. > > > > I have a workstation with Linux installed. A Virtex II Pro FPGA Module > > is plugged in the backplane of the workstation. I'm wondering if I > > need to write a device driver for the FPGA module in order for the > > Linux box to recognize the card? > > > > I want a software program running on the Linux machine to be able to > > poll a few registers on the FPGA module, bascially through memory map. > > Is this possible without a device driver? > > Was the board designed to work with Linux? > > Some years ago I worked with a variety of boards on Sun workstations. Sun > provided device drivers that would map memory as an I/O device so that any > device could be accessed that way. A little less convenient than a > dedicated device driver, but it did work. I don't know that Linux provides > that, though. > > -- glen Yeah I'm been looking all over the web and forums, can't seem to find anything useful.Article: 62932
alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0311051625.39437e89@posting.google.com>... > sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>... > > I have a workstation with Linux installed. A Virtex II Pro FPGA Module > > is plugged in the backplane of the workstation. I'm wondering if I > > need to write a device driver for the FPGA module in order for the > > Linux box to recognize the card? > > No. By backplane do you mean PCI? > > > I want a software program running on the Linux machine to be able to > > poll a few registers on the FPGA module, bascially through memory map. > > Is this possible without a device driver? > > You might want to try: > http://www.linuxjournal.com/article.php?sid=5442 > "User Mode Drivers" > > Which talks about writing directly to PCI memory space. > This is not a particularly nice/good/proper thing to do, but it is > quick and dirty and good for starters. > > Alan Nishioka > alann@accom.com Yes backplane as in the PCI bus of the Linux workstation. I will check out the article you suggested, thanks!Article: 62933
johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311052351.1f2db0a7@posting.google.com>... > sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>... > > Hi, > > > > I'm a newbie to FPGA and Linux world. I have a general question > > concerning both. > > > > I have a workstation with Linux installed. A Virtex II Pro FPGA Module > > is plugged in the backplane of the workstation. I'm wondering if I > > need to write a device driver for the FPGA module in order for the > > Linux box to recognize the card? > > > > I want a software program running on the Linux machine to be able to > > poll a few registers on the FPGA module, bascially through memory map. > > Is this possible without a device driver? > > > > Thanks in advance for all the help. > > > > Michelle > > > The better FPGA board makers should include a ready to go PCI device > driver. For Windows this would have been something like Numega IIRC, > but for Linux I am less sure, most of my old links are long gone > (thanks to MS ...). > > Who is the board vendor?, check their site for driver support. > > John > > johnjaksonATusaDOTcom Xilinx is the vendor.Article: 62934
Andy, 100KHz out of 35 MHz is .1/35, or 1/350, or ~2800 ppm. The spec in the data sheet is +/- 100 ppm, but that was for an instantaneous change in frequency (largest step size). 200 Hz out of 35 MHz is ~6 ppm. The DCM tracts phase changes by moving its taps. The tap movement for the CLK0/CLK180 (DLL outputs) is 6*the 2's complement of the jitter filter times the number of clocks for one tap change (~50 ps, V2, ~30ps, V2P). By changing the jitter filters to 0xFFFFh, you can now track phase changes much faster (roughly 6 clocks per tap, or 50ps in 6 35 MHz clocks, or 50ps/172ns). This is roughly 34.99MHz to 35.01 MHz (10 KHz instant step per every 6 clock cycles allowed). With the default settings, it is ~256 times slower (or 10KHz/256 ~ 40 Hz) I think you need to set your jitter filter settings to allow more change. I think you will find that this is the fastest tracking capability of any general purpose 24MHz to 420 MHz phase locked loop device in exisitence......(and you can vary it by the jitter filter values). That said, you can monitor the LOCKED signal, as it will lose lock it the tap runs off either end of the delay line for any reason. As well, if the CLOCK_IN_STOPPED status bit goes high, that is an indication that the input clock has missing pulses (really bad) and the DCM may need to be reset. The DFS has a different state machine, but also tracks frequency and phase thru tap movements, and is faster than the DLL state machine (no jitter filter at all), so the DLL is the limiting element. Austin Andyman wrote: > Hi all, > > I have a design which takes data from an external ADC. The ADC > provides a 35 Mhz clock. > > Currently the design feeds the input clock through a DCM and uses the > 180 degree phase shifted version to sample and reassemble the ADC > data. This all then passes to our system clock domain via one of the > (wonderfully useful) Xilinx self addressing asychronous FIFO's. > > As this is for a communications system we need to perform clock > recovery (actually this might be better described as carrier recovery) > and the ADC provides a means to tune the clock it uses to sample with. > Of course this means that the clock we are feeding into the DCM to > get our internal sampling clock (and driving the SAF - in essense a > block RAM) is going to be changing. Each change could be in the order > of 200 Hz and performed a few thousand times a second. The total > change from the clock the DCM locked with could be up to 100 KHz but I > could bodge...ahem...design my way round this to make it significantly > less. > > Although the above is working fine at the moment I am worried about > the DCM loosing its lock due to the varying input clock. Can anyone > suggest how much the DCM will tolerate before throwing a wobbly? > > Thanks, > > AndyArticle: 62935
> Rick,
>
> The IBIS models are based on the foundry spice models, which are pretty
> mature now, as the same transistors used for the IOs have been manufactured
> now for almost a year.
>
> Just because others have absolutely lousy IBIS models out there does not
> mean we do: We continually check the quality of the models. Yes, Spartan 3
> has preliminary models but only because it is not released to production yet
> -- it is still int he ES phase. This allows us to make changes easily as we
> discover issues. So far, no issues with IBIS.
>
> Austin
From a Xilinx S2 IBIS model..
Note " .... this model is considered preliminary as it has not been
verified by actual silicon measurement."
And this is an old part. How good do you think Xilinx models are for
the S3??
[Disclaimer] The data in this model is derived from SPICE
simulations using
modeling information extracted from the target
process. While
a great deal of care has been taken to provide
information
that is accurate, this model is considered
preliminary as it
has not been verified by actual silicon measurement.
Treat the
data in this model as preliminary until actual
silicon
verification is performed.
[Copyright] Copyright 2000, Xilinx Inc., All rights reserved
Article: 62936"Сергей Зорин" <zlogic@udm.ru> skrev i melding news:boqoau$22r0$1@hq.mark-itt.ru... > Hi, ALL. > > Problem with installation subj. > In time installation the program java.exe is under abnormal condition > finished. > It happens in WIN 98 and in WIN XP. Processor - CELERON 1700. > What to do, help me, please. My weak memory seem to remember something about java and this problem... You needed the latest java runtime environment to install this?Article: 62937
Standard disclaimer. We don't seem to get around to removing the caveats.....I'll look into that. All parts once they are in production have been verified in MY lab. By the way, folks have asked about duty cycle distortion in the outputs, and IBIS models will allow you to simulate the FAST/STRONG corner and then the SLOW/WEAK corner. You can imagine that the rise vs. fall times could be (absolute worst case) that different. Godd thing to check when you want to know "is this standard fast enough for my xxxx application?"* Austin This does use the low vcc, low temp, high vcc, high temp as part of the corners (as well as the process variation which is what you are really concerned about here), so it is more pessimistic than the reality (reality can not have a low vcc, hot rising edge with a high vcc cold falling edge), but it is still a great way to check if the IO standard you have chosen is reasonably well matched for the speed you desire. lecroy wrote: > > Rick, > > > > The IBIS models are based on the foundry spice models, which are pretty > > mature now, as the same transistors used for the IOs have been manufactured > > now for almost a year. > > > > Just because others have absolutely lousy IBIS models out there does not > > mean we do: We continually check the quality of the models. Yes, Spartan 3 > > has preliminary models but only because it is not released to production yet > > -- it is still int he ES phase. This allows us to make changes easily as we > > discover issues. So far, no issues with IBIS. > > > > Austin > > From a Xilinx S2 IBIS model.. > Note " .... this model is considered preliminary as it has not been > verified by actual silicon measurement." > And this is an old part. How good do you think Xilinx models are for > the S3?? > > [Disclaimer] The data in this model is derived from SPICE > simulations using > modeling information extracted from the target > process. While > a great deal of care has been taken to provide > information > that is accurate, this model is considered > preliminary as it > has not been verified by actual silicon measurement. > Treat the > data in this model as preliminary until actual > silicon > verification is performed. > [Copyright] Copyright 2000, Xilinx Inc., All rights reservedArticle: 62938
Comment below: "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:boqucv$8go$1$8300dec7@news.demon.co.uk... > "Vazquez" <andres.vazquez@gmx.de> wrote in message > news:eee19a7a.0311110648.5e79e75c@posting.google.com... > > > The 32-bit vector can have up to 4 locations with '1', for example > > > > 0000 1000 0000 0000 0101 0000 0000 0100 > > > > I want to create out of the 32-bit-HIT-vector 4 addresses. > > In the example shown that would mean that I have to create the > > following > > addresses (for the second check step): > > 1. b00010 > > 2. b01010 > > 3. b01110 > > 4. b11011 > > That is a VERY different problem from the one you first posted! > > > So is there a possibility to get these four addresses out of the > > 32-bit-vector within one clock cycle? > > I'm sure it is possible, but it is certainly difficult and I > cannot see a clean solution right now. However... > > > These addresses will then be assigned sequentially > > to the RAM wraddress port. > > If the four RAM writes are to be sequential, why not > obtain the four addresses sequentially? That would be > much simpler. Use a priority encoder (as Valentin > suggested) to locate the first 1 bit. Then, while > you are writing to the chosen RAM location, clear that > first bit to 0 and use the same priority encoder again > to find the second 1 bit. Keep going like this until > you have cleared the whole 32-bit input word to zero. > > A 32-to-5-bit priority encoder is not trivial, but it > should be OK unless your clock speed is very fast. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. I missed the original postings but the sequential detection sounds like a great approach from what I see above. The 32-to-5-bit priority encoder is something I worked with just recently, targeting the Virtex-II architecture with Synplify Verilog. The speeds I was able to get were greater than 300 MHz. If you're working with these tools or just want to see the approach, feel free to reply-email directly. I could probably (suggest ways to) push the speed even further with some tricks I have left. - John_HArticle: 62939
I agree that it's ugly, but what I find mind-boggling is that you can get any sort of speed-up by going off-chip! Also, I seem to recall (plz correct me if I'm wrong) that SelectMAP allows for a form of "handshaking" using the "busy" signal, which allows you to work SlaveSelectMAP at a slightly higher frequency (see Virtex-II Users guide -> Configuration -> Slave SelectMAP Programming Mode -> CCLK -> (...). Does this also work with the ICAP? What is the maximum clock frequency then? Pierre-Olivier -- to contact me directly, remove the obvious from my email address --Article: 62940
Great comments, Martin. A point I'd add to the original poster's concerns about the "swiss cheese" ground and power planes you can get with too many vias, some numerical work has shown that - at least for closely spaced ground/power pairs - the added impedance from the swiss cheese under a BGA package (much worse than a QFP) is sub-nanohenry. Don't worry so much about the holes in the plane, worry about the spacing between the planes (smaller is better, 4 mil perhaps?) and good decoupling cap attachment. Two vias are often used on each end of the decoupling caps in high speed designs to halve the impedance to the ground and power planes. The "*very* short tracks" is a noteworthy comment as well; it's easy to make a stiff decoupling cap a bit soft by adding a little track between the pad and via(s). "Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:uislr3q8a.fsf@trw.com... > Hi Jason, > > "Jason Berringer" <look_at_bottom_of@email.com> writes: > <snip> > > I would like to see if possible some proven layouts showing where the caps > > are mounted and there possition relative to the power pins (and see how > > close they are). I've seen a lot of layouts where there are a few caps in > > the center of the IC on the underside of the board, but this does not lend > > itself nicely to the idea of being as close as possible to the pins. I have > > also seen the Xilinx app note on BGA routing which is very helpful, but > > again no capacitor placement is shown. > > > <snip> > If you have solid planes (prefereably closely spaced) you don't need > to worry about 'close' in the sense that you probably think of as > close. If you have vias to the planes on *very* short tracks, or even > better in the pad, then the planes will act as a very low impedance > route for your currents. If you think of the time the energy will > take to travel from capacitor to chip, the speed of light on FR4 is > around 2/3c or 2e8 m/s. In 1ns, this is around 20cm. Halve this for > the energy to get back and forth and even 10cm is "close". > > I don't have any pictures to hand, but we've done boards like this > with 100MHz memory interfaces and 150MHz core DSP clocks that work fine. > > Does that help? > > Cheers, > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt, Solihull, UK > http://www.trw.com/conektArticle: 62941
Every clock cycle? Not gated/enabled or cleared? You split the counter into halves earlier, correct? Pre-decode the terminal count from the fast counter so you have a synchronous TC signal when the 32'hffff_ffff arrives (or 8'hff or whatever size you choose). With the synchronous TC fed to the enable of the top, slow counter you can achieve great speeds. Only a little more coordination is needed for proper enables, clears, or loads, but the design should be easy to achieve once you understand the "tricks" that will help you "retime" your synchronous designs. "Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message news:W0Vrb.67$%o4.12245@news.xtra.co.nz... > To be more precise the implementation requires the calculation of: > a = a + 1 > > When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6 > FPGA. > > Erez.Article: 62942
Dear Allan, Thank you for your answer. When you say binary format, what precisely do you mean? On the other hand I was thinking of using Xilinx NGC netlist instead of EDIF. Do you think this would help? I have read that NGC is a encrypted netlist format, and if there is no easy way of converting NGC to EDIF, than maybe it would be a solution to my problem. Best regards, Rastislav On Tue, 11 Nov 2003 10:45:47 +1100, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: >On Mon, 10 Nov 2003 23:10:39 +0100, Rastislav Struharik ><rasti@eunet.yu> wrote: > >>Hello, >> >>I would like to know does anyone knows, is it possible to reverse >>engineer an edif netlist file? I am currently developing an FPGA core. >>I would like to supply an evaluation version of the core, that would >>have all the functionality of the final core, but would operate only >>for a limited period of time. My fear is that there is a way to modify >>the evaluation version edif netlist (find and remove modules that set >>a time limit to the operation of the evaluation version), and thus >>obtain completely functional core. Can something like this be done, or >>am I being paranoid? >>Every help and clarification on this subject is most welcome. > >I think you should distribute your design in a binary format, since >it's fairly easy to reverse engineer EDIF: > >Use any text editor for editing. > >Use Aldec or Riviera for simulating. (Both tools handle a combined >VHDL / Verilog / EDIF flow). > >Use a recent version of Synplify to convert to (almost readable) >schematics. > >Regards, >Allan.1Article: 62943
As I had posted a while ago, the Virtex-II BlockRAM is surprisingly efficient as a priority encoder. Use one BlockRAM as a dual-ported 4K x 4 ROM. Feed 12 inputs as address to one port, and the next 12 bits as address to the other port. That gives you two sets of 4 outputs defining the priority-encoded position in the two 12-bit inputs separately.No problem with multiple 1s! Should work at 200+ MHz, but note that the BlockROM is a synchronous device, it operates on a clock edge! The remaining 8 inputs and the combining of the eight BlockROM outputs can be done the conventional way, but might also be done in another BlockROM (generating a second clock latency!) Peter Alfke, Xilinx ApplicationsArticle: 62944
"John_H" <johnhandwork@mail.com> wrote in message news:mt8sb.12$SZ3.1981@news-west.eli.net... [...] > The "*very* short tracks" is a noteworthy comment as > well; it's easy to make a stiff decoupling cap a bit soft by adding a little > track between the pad and via(s). Showing my age here.... when I was routinely designing PCBs around 8-10 years ago, I was often given a very hard time by assembly subcontractors if I put vias inside an SMD pad - they used to complain about solder hogging or some such manufacturing folklore. What are the up-to-date design rules for putting vias in or very close to a pad? TIA -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 62945
Erez This is a good idea for a counter, but it does not work for a general purpose incrementer where you would throw new vectors at it on every clock cycle. In that case, my suggestion of detecting FFFF and generating a wait state works well. (I hope you did not think I was just brushing the problem under the carpet. I solve it with the additional wait state ). Regarding your 2-stage prescaler, I would extend this to three stages. It gives you double the timing benefit, and it fits the 4-input LUT structure very nicely. I don't understand your item 4, but that may be just semantics. Good luck, and happy counting at 400+MHz! Peter Alfke, Xilinx Applications ========================= Erez Birenzwig wrote: > > Then when you read the counter every clock cycle once every 64K counts > you'll > get a wrong result. I don't think it's good enough.. Remember the FMUL bug ? > > Anyway I got a good answer from another list : > > 1) Build a fast 2-bit counter > 2) Build a slow 62-bit counter, with enable > 3) Use enable = q[1]&q[0] > 4) latch the slow counter using the enable as well > > You get a full 4 cycles for the carry to ripple through the upper 62 > bits. Be careful in timing analysis. Some systems let you specify that > the carry chain is a multi-cycle path. Other's force you to ignore > these paths with falsepath commands. > > (Thanks Bill for the help). > > Erez. > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3FB0230F.3FC83434@xilinx.com... > > I would suggest detecting FFFF and generating a wait state or two when > > you reach that value. The probability is one in 64K, so it should hardly > > have any impact on performance. > > > > Peter Alfke > > ================== > > Erez Birenzwig wrote: > > > > > > To be more precise the implementation requires the calculation of: > > > a = a + 1 > > > > > > When a is a 64bit vector, every clock cycle at 200MHz, using a > virtexII-6 > > > FPGA. > > > > > > Erez. > > > > > > "Peter Alfke" <peter@xilinx.com> wrote in message > > > news:3FB01875.A2C23F2F@xilinx.com... > > > > "Counter" can mean many things. > > > > If you need a synchronous counter that gives you the updated value > > > > before the next count pulse comes in, that is a demanding design and > may > > > > have timing problems at 200 MHz. > > > > > > > > If, at the other extreme, you just need a counter that can resolve 200 > ( > > > > or 500+ ) MHz, and you can wait some nanoseconds before you read the > > > > final count value, that is trivial. In the extreme case you would just > > > > concatenate 2-bit Johnson counters (at least at the input end), one > > > > slice clocking the next. And there are many variations on this theme. > > > > I built a 400 MHz frequency counter 5 years ago with > XC4002XL...Playing > > > > around, aiming at 1 GHz now. > > > > > > > > Peter Alfke, Xilinx Applications > > > > > > > > > > > > Erez Birenzwig wrote: > > > > > > > > > > Hi, > > > > > > > > > > I'm trying to write some code for a 64 bit counter for a VirtexII. > > > > > > > > > > The problem I'm facing is that it has to run at least at 200MHz, > and > > > > > therefore > > > > > a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to > > > 114MHz). > > > > > > > > > > I've tried a split approach with four smaller counters and a > selector > > > > > depending on the carry out of the previous stages but it only got me > to > > > > > about > > > > > 180MHz. > > > > > > > > > > Did anyone ever had a similar problem and solved it ? > > > > > Unfortunately I'm not familiar with a pipelined implementation, > I'll > > > be > > > > > happy > > > > > to learn one. > > > > > > > > > > Many thanks, > > > > > Erez.Article: 62946
On Mon, 10 Nov 2003 23:10:39 +0100, Rastislav Struharik wrote: > Hello, > > I would like to know does anyone knows, is it possible to reverse > engineer an edif netlist file? I am currently developing an FPGA core. > I would like to supply an evaluation version of the core, that would > have all the functionality of the final core, but would operate only > for a limited period of time. My fear is that there is a way to modify > the evaluation version edif netlist (find and remove modules that set > a time limit to the operation of the evaluation version), and thus > obtain completely functional core. Can something like this be done, or > am I being paranoid? > Every help and clarification on this subject is most welcome. > > Thanks in advance, > Rastislav Struharik You can convert the edif file into Verilog of VHDL by running the Xilinx programs edif2ngd followed by an ngd2ver or ngd2vhdl. What you get is gate level so it's not easy to work with but it's at least minimally human readable.Article: 62947
"Filled Vias" are a process that your raw-board vendor may support and are necessary for in-the-pad vias. You're still right in that unfilled vias in the pad act as solder theifs. Micro-vias (a form of blind via) are even better at giving exceptionally low impedance without acting as a sloder theif but the cost and tool support art two things I'd worry about. Chances are you'll stick with regular vias and get the spacing particulars (capacitor pad to via minimum spacing) from your board assembly house or someone else intimately familiar with the IPC recommendations. It wouldn't be a good thing to just stick those vias in the pads or a solder-flow away from the pad to act as a nice drain for the solder. These details get lost on those of us who have it ingrained upon us that the minimum spacing shall never be violated. Thanks for keeping the details alive. "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:bor6c5$je3$1$8300dec7@news.demon.co.uk... > "John_H" <johnhandwork@mail.com> wrote in message > news:mt8sb.12$SZ3.1981@news-west.eli.net... > [...] > > The "*very* short tracks" is a noteworthy comment as > > well; it's easy to make a stiff decoupling cap a bit soft by adding a > little > > track between the pad and via(s). > > Showing my age here.... when I was routinely designing PCBs > around 8-10 years ago, I was often given a very hard time by > assembly subcontractors if I put vias inside an SMD pad - they > used to complain about solder hogging or some such manufacturing > folklore. What are the up-to-date design rules for putting vias > in or very close to a pad? > > TIA > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > > > >Article: 62948
sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311110741.10ae36dc@posting.google.com>... > johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0311052351.1f2db0a7@posting.google.com>... > > sleepymish@hotmail.com (Michelle) wrote in message news:<2b3db7ca.0311050941.3dc9ee2c@posting.google.com>... > > > Hi, > > > > > > I'm a newbie to FPGA and Linux world. I have a general question > > > concerning both. > > > > > > I have a workstation with Linux installed. A Virtex II Pro FPGA Module > > > is plugged in the backplane of the workstation. I'm wondering if I > > > need to write a device driver for the FPGA module in order for the > > > Linux box to recognize the card? > > > > > > I want a software program running on the Linux machine to be able to > > > poll a few registers on the FPGA module, bascially through memory map. > > > Is this possible without a device driver? > > > > > > Thanks in advance for all the help. > > > > > > Michelle > > > > > > The better FPGA board makers should include a ready to go PCI device > > driver. For Windows this would have been something like Numega IIRC, > > but for Linux I am less sure, most of my old links are long gone > > (thanks to MS ...). > > > > Who is the board vendor?, check their site for driver support. > > > > John > > > > johnjaksonATusaDOTcom > > Xilinx is the vendor. By the way, I have a related question.... I believe the "/proc/bus/pci/devices" file in Linux lists all the devices on the PCI bus. I'm wondering if anyone knows how this file is updated or maintained? How is this file updated with the devices.? Is it updated every time the system is turned on or does the system admin update with the appropriate information? Thanks!Article: 62949
Followup to: <2b3db7ca.0311111102.31c51e50@posting.google.com> By author: sleepymish@hotmail.com (Michelle) In newsgroup: comp.arch.fpga > > By the way, I have a related question.... > > I believe the "/proc/bus/pci/devices" file in Linux lists all the > devices on the PCI bus. I'm wondering if anyone knows how this file is > updated or maintained? How is this file updated with the devices.? Is > it updated every time the system is turned on or does the system admin > update with the appropriate information? > Anything in /proc is automatically updated by the kernel. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
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