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
Hi cecilia, > in short: > how can I include a library in a project compiled with the quartus II > ?someone has been able to do this??? You don't need to compile the package. You just include it in your project file list somewhere at the top. So, from the menu: Project->Add/remove files in Project Best regards, BenArticle: 80026
<jaxato@gmail.com> schrieb im Newsbeitrag news:1109614802.159759.97770@f14g2000cwb.googlegroups.com... > It actually failed, as I was thinking, in hardware. Hmm, bad. > It sound reasonable to say that in order for this circuit to be > actually usable, we either need to put constrains on the clock > netlists, or to manually route the clock selector circuit so that it > minimizes the delay to the counters it is driving, or, as I did, to use > a bufg component so as to use the FPGA chip's clock plane. As far as I remeber it was a counter which should run at 5.something MHz or 1/3 of this. I just cant believe that this is a real design challenge? Whats the point? Just use a BUFG for clock distribution and create a CE (clock enable) which is either always HIGH or HIGH every 3rd clock cycle. Works right out of the box. Regards FalkArticle: 80027
Michel Billaud wrote: > Jeremy Stringer <jeremy@_NOSPAM_endace.com> writes: > > >>One thing I guess you could consider is that the GPL can make things >>difficult for companies that want to integrate your IP block into a >>commercial product, because of the requirement to redistribute source >>code. > > Well, not a big problem. Such companies are free to contact the author > for a different licensing of the same source if they have different > needs. That is true, yes. It is something that definitely needs to be handled before work starts though, otherwise it's just a risk factor :) I guess it would be no more work than buying an IP core, except that there's no guarantee of getting a different licence. JeremyArticle: 80028
Preben Holm wrote: >> You can code as above, with taps, and a single MUX, or you could have >> a first stage that can select a choice of divide by /1/2/5/10, as a >> clock enable into following cascaded /10 stages that select >> 10/100/1000/10000 etc. > > > I dont't what you mean by that! > What are taps? I only know taps from the DCM's (and I can't see that I > can use that for this) > > How will you use the MUX? Please sketch some VHDL or components for me > so I can see the idea? Take a look at some Microcontroller data sheets, for how they implement prescaler Counter Taps + MUX selection. A good example is in the Atmel AT90PWM2 SPI Clock prescaler, Page 182... [This has 3 SFR bits selecting one of 8 Binary weighted taps, via an 8 way MUX] -jgArticle: 80029
And what if I have limited resources available to me. It will be fairly straight forward to use bufg, but currently, im using 4/4 of them on my old virtex chip. cheers JacquesArticle: 80030
If I was a fpga manufacturer I would put 1 or 2 people in this newsgroup just for answering questions. That would be the most effective publicity possible, I guess. regards, Benjamin PS: Hello Peter :)Article: 80031
Hi all, I am thinking of using RocketIO for serializing a very simple parallel data flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24 Gb/s. At the receiving end I need to resynchronize the data to the original 70 MHz clock (The clock can be made available to both FPGAs). I was wondering if someone could point me in the right direction (should I be using Aurora?) as I am feeling a little overwhelmed with the amount of the information on RocketIO, most of which seems not too relevant to my simple case... Thanks, /MikhailArticle: 80032
Hi All, I am trying to sim my design that deals with data transfer between my FPGA and a microcontroller with a 16-bit multiplexed data/address bus. In my design, I am using flags (data_in_enable, data_out_enable) to pick/put data from/onto the bus. Does anyone have an idea how to model the simulation (especially Procssor read cycle) I appreciate all the responses Thanks MorpheusArticle: 80033
<jaxato@gmail.com> schrieb im Newsbeitrag news:1109624213.293668.101720@f14g2000cwb.googlegroups.com... > And what if I have limited resources available to me. It will be fairly > straight forward to use bufg, but currently, im using 4/4 of them on my > old virtex chip. You can also use local routing. Give the constaint NET my_poor_clock uselowskewlines; in the ucf. If you dont have too much logic on that net (say a two dozens of FlipFlops), the P&R can use secondary routing ressources to route the clock. The result will be reliable, the only difference is that the clock delay is usually longer then on a bufg. Regards FalkArticle: 80034
"morpheus" <saurster@gmail.com> wrote in message news:1109626822.079164.162460@l41g2000cwc.googlegroups.com... > Hi All, > I am trying to sim my design that deals with data transfer between my > FPGA and a microcontroller with a 16-bit multiplexed data/address bus. > In my design, I am using flags (data_in_enable, data_out_enable) to > pick/put data from/onto the bus. > Does anyone have an idea how to model the simulation (especially > Procssor read cycle) > I appreciate all the responses > Thanks > Morpheus > I would say Bus Functional Model (BFM). Try a google of BFM in tis group for a start. -NewmanArticle: 80035
"Anthony Fremont" <spam@anywhere.com> wrote in message news:<XEgUd.59752$cW2.29137@fe2.texas.rr.com>... > ;-) Also, if he's looking to sell these, he will need to obtain a > license from Phillips. IANAL, but AFAIK Patents expire 17 years after their publishing date. For the I2C patent US000004689740A was published August 27th 1887, so it should be expired by now. Maybe it is also covered by another patent.... Kolja SulimmaArticle: 80036
I am using v2pro 100 device with core clk speed of 200 mhz and am running rocket io, aurora and supporting logic at 156.25Mhz. I am noticing unusually high skews on these clocks. here is an excerpt from par report. +-------------------------+----------+------+------+------------+-------------+ | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)| +-------------------------+----------+------+------+------------+-------------+ | core_clk | BUFGMUX6S|Yes | 6096 | 1.175 | 2.654 | +-------------------------+----------+------+------+------------+-------------+ | ssp_tx_gclk1 | BUFGMUX2S|Yes | 169 | 0.267 | 2.508 | +-------------------------+----------+------+------+------------+-------------+ | ssp_tx_gclk2 | BUFGMUX0S|Yes | 169 | 0.158 | 2.631 | +-------------------------+----------+------+------+------------+-------------+ | core_clk_dv2 | BUFGMUX1P|Yes | 1358 | 1.120 | 2.604 | +-------------------------+----------+------+------+------------+-------------+ | nfclk | BUFGMUX7P|Yes | 2012 | 1.411 | 3.196 | +-------------------------+----------+------+------+------------+-------------+ Although this skew might be for two flops which are at farthest in the chip and probably not in the path it still does seem mighty large. Is there anything we can do to reduce this skew. We are using DCM and these clock as well. samirArticle: 80037
Hi Mikhael, If you have Xilinx CORE Generator installed, you can generate an Aurora module for your application. A single lane full-duplex Aurora module with a 4-byte streaming parallel interface will fit. CORE Generator will give you the source code for the module, which you can integrate with your design. You'll need to provide a 140 Mhz reference clock to run the RocketIO; the module will provide a 70 Mhz clock derived from the reference clock for the parallel interface. The TX interface is a data port plus a ready signal and a data valid signal. The RX interface is a data port plus a data valid signal. RocketIO uses Clock Data Recovery (CDR) which means the data you receive will be synchonized to a 70 Mhz clock recovered from the serial input. Unless you need the clocks on both devices to be exactly in phase, you wont need to provide the same clock to both FPGAs. If this sounds like it might work for you, you should take a look at the Aurora Reference Design User Guide in the downloads section of the Xilinx Aurora lounge (www.xilinx.com/aurora -> Click the Access Lounge button for the Aurora Reference Design at the bottom of the page: the user guide is the second link.) Regards, Nigel MM wrote: > Hi all, > > I am thinking of using RocketIO for serializing a very simple parallel data > flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit > word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24 > Gb/s. At the receiving end I need to resynchronize the data to the original > 70 MHz clock (The clock can be made available to both FPGAs). > > I was wondering if someone could point me in the right direction (should I > be using Aurora?) as I am feeling a little overwhelmed with the amount of > the information on RocketIO, most of which seems not too relevant to my > simple case... > > > Thanks, > /Mikhail > >Article: 80038
hmurray@suespammers.org (Hal Murray) writes: > Beware. Modern LDO regulators have restrictions on the ESR of the > filter caps. Too low or too high and they oscillate. [...] > I think older non-LDO type linear regulators are easier to work with. > But they often don't go down to 1.2V. Even LDOs that go to 1.2V are fairly uncommon. National has one, the LP3881ES-1.2 ($2.58 from Digikey in quantity 100). That seems quite expensive, but it is well documented. The typical application shows 4.7uF tantalums for the input and output filters, says that 4.7uF is the recommended minimum for both the input and output filter capacitors, and gives a range of output capacitor ESRs for which it is stable (dependent on load current). They point out that aluminum electrolytics have high ESR below 10C, and often have their ESR specified only at low frequencies. Ceramic capacitors have too low an ESR for stability. Someone else in this newsgroup brought to my attention the very inexpensive Sharp 1.2V LDO, PQ012FZ ($0.66 from Digikey in quantity 100), but the data sheet doesn't describe the requirements for the capacitance and ESR of the filter caps. The test circuit shown in the data sheet has a 0.33uF on the input, and a 100uF 50V on the output, but no ESR or specific capacitor type is mentioned. EricArticle: 80039
Kolja Sulimma wrote: (someone wrote) >>;-) Also, if he's looking to sell these, he will need to obtain a >>license from Phillips. > IANAL, but AFAIK Patents expire 17 years after their publishing date. > For the I2C patent US000004689740A was published August 27th 1887, so > it should be expired by now. > Maybe it is also covered by another patent.... As someone else said, though, it is also trademarked. If you don't call it I2C you may be safe, but again, IANAL. -- glenArticle: 80040
I've put together a webpage on the performance of NCSim and Xilinx tools on various systems, specifically a dual PIII, dual Xeon, Athlon 64 3400+ and an Athlon 64 3800+. http://www.polybus.com/linux_hardware/index.htmArticle: 80041
Hi everybody, I have to interface a 8-bit microcontroller (ATMega128, running at 16MHz) to a Xilinx Spartan-II FPGA. The FPGA will have several roles. It should be an address latch (the bus has address/data multiplexed), an address decoder (to generate chip selects) and a peripheral accessible through memory-mapped registers. As the bus is asynchronous, I suppose I'll have to over-sample the signals. Could anyone direct me to some documentation about asynchronous bus interfaces for FPGAs ? The FPGA main clock runs at 24MHz, and I'd like to know if this will be enough (the clock can be doubled using a DLL if needed). Thanks in advance for your help. Laurent PinchartArticle: 80042
MM wrote: > Hi all, > > I am thinking of using RocketIO for serializing a very simple parallel data > flow from one Xilinx FPGA to another. The data flow is a stream of 16-bit > word pairs running at approximately 70 MHz, i.e. the total data rate is 2.24 > Gb/s. At the receiving end I need to resynchronize the data to the original > 70 MHz clock (The clock can be made available to both FPGAs). > > I was wondering if someone could point me in the right direction (should I > be using Aurora?) as I am feeling a little overwhelmed with the amount of > the information on RocketIO, most of which seems not too relevant to my > simple case... The Aurora module is a pretty good match for that, I would think. Yes it looks like a lot of info, mut mainly you will be concerned with TX_DIN and TX_WR (and perhaps TX_DST_RDY) on the write side, and RX_SRC_RDY and RX_DOUT on the receive side. They are simple handshaking signals which do exactly what the names imply, so the core is really easy to use. Read the section on clocking several times, though ;) Unfortunately, getting the simulation up and running is a bit of a pain. Only Swift simulation models are provided for the RocketIO, and I think I spent most of a day researching these and getting them going in Modelsim, but they work fine after that. It was well worth the trouble; the simulation is pretty good fidelity. -- My real email is akamail.com@dclark (or something like that).Article: 80043
The computer must give you some strobe that indicates valid data. Do a worst-case analysis whether your FPGA clock guarantees capture within that window. Otherwise implement dirct data capture in the IOB and postpone the synchronization to 24 MHz. Always assume worst-case timing and phasing... Peter AlfkeArticle: 80044
Samir, Does your clock go to any non-clock inputs? Like a IOB.O pin, or a LUT? If not, maybe you could bend the FPGA in half and connect together the far ends of the clock distribution network? Cheers, Syms. "skherich" <skherich@gmail.com> wrote in message news:1109629899.156496.233370@l41g2000cwc.googlegroups.com... > I am using v2pro 100 device with core clk speed of 200 mhz and am > running rocket io, aurora and supporting logic at 156.25Mhz. > I am noticing unusually high skews on these clocks. here is an excerpt > from par report. > > +-------------------------+----------+------+------+------------+----------- --+ > | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max > Delay(ns)| > +-------------------------+----------+------+------+------------+----------- --+ > | core_clk | BUFGMUX6S|Yes | 6096 | 1.175 | > 2.654 | > +-------------------------+----------+------+------+------------+----------- --+ > | ssp_tx_gclk1 | BUFGMUX2S|Yes | 169 | 0.267 | > 2.508 | > +-------------------------+----------+------+------+------------+----------- --+ > | ssp_tx_gclk2 | BUFGMUX0S|Yes | 169 | 0.158 | > 2.631 | > +-------------------------+----------+------+------+------------+----------- --+ > | core_clk_dv2 | BUFGMUX1P|Yes | 1358 | 1.120 | > 2.604 | > +-------------------------+----------+------+------+------------+----------- --+ > | nfclk | BUFGMUX7P|Yes | 2012 | 1.411 | > 3.196 | > +-------------------------+----------+------+------+------------+----------- --+ > Although this skew might be for two flops which are at farthest in the > chip and probably not in the path it still does seem mighty large. Is > there anything we can do to reduce this skew. We are using DCM and > these clock as well. > > samir >Article: 80045
"Laurent Pinchart" <laurent.pinchart@skynet.be> wrote > The FPGA main clock runs at 24MHz, and I'd like to > know if this will be enough (the clock can be doubled using a DLL if > needed). Laurent, No, you can't. From DS001 FCLKINLF Input clock frequency (CLKDLL) Min(-6) 25 Max(-6) 100 Min(-5) 25 Max(-5) 90 MHz Cheers, Syms.Article: 80046
Hello Is there a Virtex4 FX eval board available yet? We want to begin working with the on-chip Gig Ethernet mac. PeteArticle: 80047
Symon wrote: >> The FPGA main clock runs at 24MHz, and I'd like to >> know if this will be enough (the clock can be doubled using a DLL if >> needed). > No, you can't. > From DS001 > FCLKINLF Input clock frequency (CLKDLL) Min(-6) 25 Max(-6) 100 Min(-5) 25 > Max(-5) 90 MHz Oops, you're right. I'll then use a 25MHz main clock, or keep the current one if 24MHz turns out to be enough. My initial question still applies though :-) Laurent PinchartArticle: 80048
> The computer must give you some strobe that indicates valid data. > Do a worst-case analysis whether your FPGA clock guarantees capture > within that window. > Otherwise implement dirct data capture in the IOB and postpone the > synchronization to 24 MHz. > Always assume worst-case timing and phasing... The microcontroller has read, write and address strobe signals. The problem is that the bus is asynchronous, which means that the FPGA might sample the signals when they are not in a defined logic state. This implies meta-stability problems if I remember my classes properly. What are the basic guidelines to handle such problems ? Laurent PinchartArticle: 80049
"Laurent Pinchart" <laurent.pinchart@skynet.be> wrote in message news:4223a767$0$30170$ba620e4c@news.skynet.be... > > The FPGA will have several roles. It should be an address latch (the bus has > address/data multiplexed), an address decoder (to generate chip selects) > and a peripheral accessible through memory-mapped registers. > I don't know what peripheral you want to implement, but for an address latch / decoder an FPGA sounds like an overkill. Spartan-II is not expensive, but consider the power supply and sereal EEPROM etc. A CPLD may be a simplier solution. Say 9572?
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