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 Antti, No comment means that we could be coming out any time. Max II is pretty awesome in many ways (performance, cost per logic function, etc.). There are some applications where non-volatility and RAM would be handy, and these aren't addressed by Max II. We've got that feedback and will factor it into future architecture decisions -- but its always a trade-off of the cost (die-size impact) of adding additional features vs. the size of the market that those additional features will open to us. Regards, - PaulArticle: 102651
Hello all, I recently learned/heard that when implementing a IIR digital filter of direct form I, the gain has to be finely adjusted with an additionnal module on the output. Otherwise, the 0dB level will not be perfectly reached in your passband (filter is low pass) and e.g. consequently a digital value that is suppose to be 40000.0000 will be 4000.0001. Essentially, I imagine this output module to be a multiplier of 1.0000000XXXX or 0.99999XXX I was led to believe this problem does not arise with digital filter implementations of direct form II. Is this true ? Looking over the flow diagrams of the 2 type of filters, I do not understand why one form would require a gain adjustement and the other would not. P.S The filter is being implemented in an FPGA, not in a DSP. P.S The passband ripple is tiny, below 1e-4dB All help will be appreciated. Regards -RogerArticle: 102652
Ed McGettigan wrote: > > The bitch ... is that Xilinx requires users to use the Xilinx usb > > adapter to program, then unplug the Xilinx usb JTAG interface, from a > > possibly live board, then plug another 3rd party (or home grown) JTAG > > into the board to do testing or configuration of non-xilinx > > device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG > > interface when it's necessary to reprogram a Xilinx part on the JTAG > > chain. > > There is no truth to this assertion. Our devices can be configured > by many, many, many different means. Hundreds, if not thousands, of > pages are available on www.xilinx.com describing how to take a generated > bitstream and use it configure a device. Then where is the documentation which describes the API for the Xilinx USB JTAG interface/cable/adapter?Article: 102653
Luc, -snip- > Maybe one day someone will be able to build a configurable or > programmable ADC. (Austin, is this allready patented? Yes, it is. I did (for Xilinx). Since then, I also believe our IC Design Centre (note spelling) in Dublin, Ireland has also filed quite a few more on that subject. You are correct, however. It is very hard to make everyone happy, so we have to see just how many smiles we get for a proposed feature, and weigh that against the costs (area, yield, market gained/lost, competition, etc). It really doesn't matter what it is: PCI? PCIe? EMAC? PPC? PLL? DLL? ECC? FIFO? MGT? they are require some study, and we may not get them right the first time we do them (since anything new is a real risk). Quite a balancing act. AustinArticle: 102654
Antti, The heat is really on now. Since we announced the LX50, LX85 and LX110, all sampling (and already sampled), the heat up on North 1st Street has got to be intense. "No comment" could also mean "Oh Crud!" Three days, 5 hours since V5, and counting ..... Tick, tick, tick, tick .... No pressure, really. Take your time. Tick, tick, tick, tick .... Austin Paul Leventis wrote: > Hi Antti, > > No comment means that we could be coming out any time. >Article: 102655
Hi, Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX series for a synchronous design, meaning i will be using only one clock for whole design. Obviously if the main clock is running at 100 MHz, i would have software components on FPGA running at different clock speed like 80 Hz or 200 Hz. To acheive this i would have to divide the system clock. Xilinx suggest to use DCM for this purpose but to me it is confusing as it is location dependent. Does it mean i have to move my logic some how to the same area where DCM is or did i interpretate it wrong. Plus DCM out put clock can drive multiple software components. is it true? ThanksArticle: 102656
You call it "synchronous design" but then you mention 80 MHz and 200 MHz. Be careful with multiple clock domains. Any domain crossing is fraught with danger. A DCM usually drives a global clock line, which -as the name implies- can drive anywhere on the chip. Somebody else told you specificlly to do more reading and studying first, and I concur... Peter AlfkeArticle: 102657
Well when i said synchronous, i ment the 80 and 200 Hz clock will be extracted from the global clock. Now can i use DCM at that point where i want 80 Hz derived from system clock. Previously i know its been done by dividing the system clock , Reading DCM i think it can do the same job without clock skew and jitter. I wanted to know if DCM placment does have any impact ???Article: 102658
I was axcited when I read "carry lookahead" with respect to V5. But when looking at the diagrams in the user guide it looks to me like ripple carry. I do not want to be picky, but carry lookahead means to me (poly)logarithmic growth of delay with respect to adder length. The timing model (as far as I understood it) suggests that the delay grows linearly with the adder length. Now what is it, ripple carry or lookahead. It is clear that FPGAs with linear layout of adders ultimately approximate linear delay/adder length but if wire delay is already the dominant problem, then a more compact arrangement like along a Sierpinsky curve could be used. There is paper from Hosler, Hauck and Fry from 97 which discusses several adder designs with respect to FPGAs, but in 65nm wire delay, even with optimal buffering would have to be considered. AndreasArticle: 102659
Fizzy wrote: > Hi, > > Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX > series for a synchronous design, meaning i will be using only one clock > for whole design. Obviously if the main clock is running at 100 MHz, i > would have software components on FPGA running at different clock speed > like 80 Hz or 200 Hz. To acheive this i would have to divide the system > clock. Just to be clear, since you say you are dividing 100MHz to get 200 Hz. Are the "80" and "200" really Hz, or MHz? If they are Hz, then a DCM won't help.Article: 102660
Fizzy schrieb: > Well when i said synchronous, i ment the 80 and 200 Hz clock will be > extracted from the global clock. Now can i use DCM at that point where > i want 80 Hz derived from system clock. Previously i know its been done DCM ist for "high-speed stuff" only. 24 MHz++. Ok, there are few exceptions. But to cut this story short. Use ordinary counters to get 80 Hz and 200Hz. Regards FalkArticle: 102661
Duane, Location (in this case) doesn't matter. The tools take care of the timing through the use of the global clocks. In your case, your divider will have to divide by a very large number, to get to 80 Hz. DCMs can not do that. The CLKDV is good for 1.5, 2, 2.5, 3, 4, 5 ....15. The CLKFX is good for M and D ranging from 2, to 31. The input frequency must be greater than 24 MHz, or if using the DFS only, greater than 1 MHz - and the CLKFX must then be greater than 24 MHz. Austin Duane Clark wrote: > Fizzy wrote: > >> Hi, >> >> Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX >> series for a synchronous design, meaning i will be using only one clock >> for whole design. Obviously if the main clock is running at 100 MHz, i >> would have software components on FPGA running at different clock speed >> like 80 Hz or 200 Hz. To acheive this i would have to divide the system >> clock. > > > Just to be clear, since you say you are dividing 100MHz to get 200 Hz. > Are the "80" and "200" really Hz, or MHz? If they are Hz, then a DCM > won't help.Article: 102662
Then if that's the case DCM is only for high frequency what are my option to have low skew and jitter on clock. Actually let me explain a little bit so i can ask the question properly. I am designing an application which will run on 200 Hz (Hertz just). I ahve system clock running at 100 MHz. I have PowerPC405 running at 100 Mhz. The custom design is connected to PPC405 through PLB. What is the best way to clock now. What i was thinking earlier is to have on chip clock comming to DCM and extract the required clock from it (200 Hz) but you guys saying its not possible so waht are my options?Article: 102663
Fizzy, Divide it down using CLB's which implement a synchronous counter. Use the output as a clock. Or use the carry output as a clock enable. Austin Fizzy wrote: > Then if that's the case DCM is only for high frequency what are my > option to have low skew and jitter on clock. Actually let me explain a > little bit so i can ask the question properly. I am designing an > application which will run on 200 Hz (Hertz just). I ahve system clock > running at 100 MHz. I have PowerPC405 running at 100 Mhz. The custom > design is connected to PPC405 through PLB. What is the best way to > clock now. What i was thinking earlier is to have on chip clock comming > to DCM and extract the required clock from it (200 Hz) but you guys > saying its not possible so waht are my options? >Article: 102664
It is carry-look-ahead over 4 bits, ripple-carry between these 4-bit slices. The "effective ripple" delay is 21 ps per bit, and that's what counts. And it includes the wire-delay. Yes, the carry delay grows linearily with the bit-length, but it is a very short delay per bit. Peter Alfke, Xilinx ApplicationsArticle: 102665
Can i use multiple DCM to extract the required frequency ?? like Dasiy chainArticle: 102666
Paul Leventis wrote: > Hi Antti, > > No comment means that we could be coming out any time. > > Max II is pretty awesome in many ways (performance, cost per logic > function, etc.) Yes, cost/FF is ok, but the 'cost/size of the smallest device' have taken quite a hike with this family. So it missed quite a large chunk of 7000 and 3000 markets. Leaves AnaChip, Atmel, Lattice, Xilinx in the low power, small package arena. > There are some applications where non-volatility and > RAM would be handy, and these aren't addressed by Max II. We've got > that feedback and will factor it into future architecture decisions -- > but its always a trade-off of the cost (die-size impact) of adding > additional features vs. the size of the market that those additional > features will open to us. You could always just admit it was an oversight, instead of using 40 odd words to say the same thing... :) -jgArticle: 102667
dand2k <dand@oz.net> wrote: >Which Spartan3 device are you using? There is an eratta for the >XC3S1500 stating that some of the engineering sample parts have a >readback bug in them. You might want to search the Xilinx support >website for readback failures, or consult the eratta pages for the >device you are using. Is there a workaround .. ?Article: 102668
Fizzy, No, you can not (cascade DCMs to get 80Hz). The DCM internal structures must be able to fit an entire clock period in the delay lines to operate. The largest delay line will hold a 24 MHz period (~ 40 ns). To hold an 80 Hz period would take far too large a structure. That is what counters are made for. Austin Fizzy wrote: > Can i use multiple DCM to extract the required frequency ?? like Dasiy > chain >Article: 102669
A friend and I have come up with some interesting ideas that involve messing around with DVI interfaces, and we'd like to physically implement them. Neither of us has a whole lot of knowledge in the way of FPGAs, just that they're faster for low-level tasks than a firmware-based controller would be. We have the basic resources for board production and schematic design, but we need some direction, especially what to look for in the way of FPGA selection (some microcontroller-like functionality is desired, multiple hardware I2C interfaces are needed), and where we can get TMDS transmitters and receivers. We're going to be pushing the limits of DVI. Dual link, high frequency (more than the single link limit of 165 MHz). The ability to buffer rows of pixel data is likely needed, depending on how critical timing is for TMDS transmitters. Since we have so little knowledge of FPGA technology, we're looking for someone to work with us on this project. Experience with generating DVI signals is needed. We'd like this project to go commercial, but until we build up some momentum (hope of a working prototype, working prototype, working prototype that works...) it's just a neat thing to work on.Article: 102670
Guys/Gals, I was lucky enough to score a Digilent Spartan 3e sample pack board. This board is interesting in that it can only (generally) boot from JTAG or NOR FLASH (BPI). It also is interesting because it has a push-button power switch, instead of a normal switch or jumper. On an unrelated note, I modded my board by routing four unused inputs and CCLK to the unused 5 pins on the 40-pin connector. At first, I thougth I could use CCLK to drive the pushbutton, but the datasheet indicates that a clock is present during configuration for BPI mode. That would most assuredly cause problems for the LTC 2950 power control chip. So, I started looking around on the board, and noticed that the configuration mode pins were fairly clear, and become GPIO (except for M2) after configuration. I also noticed that both BPI UP/DOWN and JTAG require M1 to be high, or unconnected (since the pins have internal pull-ups). I figure it should be a cince to run M1 to the pushbutton - since the pullup will keep the pin high during configuration. After configuration, the design would be able to turn its own power off. After configuration, the design could turn itself off by driving the line low. Next, with a bit of careful design, and use of tri-states, it should be possible to emulate an open-collector output, and run the M1 pin offboard to allow the power to be controlled by both the onboard Spartan FPGA and offboard logic on a remote board. This would essentially entail running a cable between the M1 jumper position and the remote board. The first problem with this idea is possible contention between the FPGA and the remote logic. This is solveable by bringing up the external board first and having it briefly drive the signal low to begin the power up sequence on the sample back board, then tri-state its output. To make sure the signal is solidly high - and because during operation, both will be tri-stated, an external pull-up is added on the Spartan board's Vcc. Once configuration of the Spartan is complete, both devices switch between low and tri-state to control power. The remote board can sense when the Spartan board is powered by looking at the I/O pin, allowing status to be read dynamically, rather than stored in a FF. This should work, as it will take several hundreds of nanoseconds, or even microseconds, for the power supplies to stabilize enough that the Spartan 3E can begin configuration. So long as the control signal is brief enough trigger the LTC 2950, but not so long as to confuse the Spartan 3E (since we are manipulating a mode control pin), I don't see why this shouldn't work. Another problem would be that the remote board would, during it's own configuration, pull-up the GPIO line to its own Vccio - which would drive M1 while the Spartan is unpowered, causing latchup. I think that a diode circuit could be used to prevent this, but I'm still not sure how to wire it. Is this a doable circuit, or am I risking damage to the Spartan 3e board doing this? What would be a good way to handle the potential latch-up problem, or is there one? Thanks, -SethArticle: 102671
Peter Alfke wrote: > It is carry-look-ahead over 4 bits, ripple-carry between these 4-bit > slices. > The "effective ripple" delay is 21 ps per bit, and that's what counts. > And it includes the wire-delay. > Yes, the carry delay grows linearily with the bit-length, but it is a > very short delay per bit. > Peter Alfke, Xilinx Applications Hi Peter, Any of the Xilinx guys do a performance study for wider adders with this new carry architecture in relation to carry select or Brent-Kung FPGA implementations, or maybe able to offer revised versions of those for the V5 given new tradeoffs with the 6-LUT and carry changes? Have fun! JohnArticle: 102672
thank you. I got it.Article: 102673
Ed McGettigan <ed.mcgettigan@xilinx.com> writes:
> Xilinx software is designed to work with Xilinx communication cables
> and some selected 3rd party equipment. Our software is tightly
> coupled to the communication hardware and we do not provide general
> access to the driver/software APIs.
That's the part that we're questioning. If you had a publicly
documented API for the interface between Impact and the driver, you
could get two main benefits:
1) Third party hardware that came with drivers supporting your API,
so they could work with Impact.
2) Third party software (e.g., JTAG debuggers for various soft core
processors and the like) that could work with Xilinx cables (or with
the third party hardware in part 1).
Cost: A few weeks of an engineer's time to document the API. I suspect
that there's already an API document which would simply need to be
sanitized for public release.
Drawbacks:
1) Availability of third-party cables that work with Impact might
slightly reduce sales of PCIV and PCUSB. Presumably Xilinx doesn't
view PCIV and PCUSB as a major profit center, and it would overall
be of greater benefit to Xilinx's bottom line to have more third
party support even if it might slightly reduce the sales of PCIV and
PCUSB.
2) The API would be semi-frozen. Xilinx could change it with future
software releases, but then the third-party drivers and software
would have to be revised by those third parties. However, since
JTAG seems to be a reasonably mature interface, and Xilinx
presumably understands their own requirements for the JTAG API, it
seems unlikely that the API would need to be revised very often.
Eric
Article: 102674Hey, We are facing this error in generating the bitstream in XPS 7.1. NgdBuild:76 - File "C:/ledplease/implementation/mb_opb_wrapper.ngc" cannot be merged into block "mb_opb" (TYPE="mb_opb_wrapper") because one or more pins on the block, including pin "Sl_DBusEn<3>", were not found in the file. Please make sure that all pins on the instantiated component match pins in the lower-level design block (irrespective of case). If there are bussed pins on this block, make sure that the upper-level and lower-level netlists use the same bus-naming convention. NgdBuild:604 - logical block 'mb_opb' with type 'mb_opb_wrapper' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'mb_opb_wrapper' is not supported in target 'spartan3'. please help us out.. wt do these errors mean?? how to get rid of them?? thanks in advance.. SAVS
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