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
What are you trying to do (design)? Why did you choose Handel-C? why not VHDL or Verilog? Roberto wrote: > Hi all. > I must develop a software for a Digilent 2-SB (with chip Xilinx Spartan 2E) > coupled with a Digilent Digital I/O 4 > I decided to use Handel-C for development , but i don't know what i must > study to start > I downloaded manuals for both digilent devices (only 14 pages). > Could you counsil me any books or links for beginners? > Thanks very muchArticle: 96051
Hi, I am using XPower to do some power estimation on a design . When I look at the advanced report I notice that the power estimation for logic bels always turn out to be 0.1mW. I am doing probabilistic estimation and when I change my clock frequency ,the total power consumed does change but this does not change the numbers on the power consumed by the bels. Is this an issue with xpower or do I need to do anything to get the right numbers for power consumed by logic bels? I am using ISE 8.1i and implemented my design on Virtex4 (4vsx25). Thanks for all your help, priyaArticle: 96052
"Erik Widding" <widding@birger.com> wrote in message news:1138508679.802556.42560@g14g2000cwa.googlegroups.com... > Sean Durkin wrote: >> I see what you're getting at. But I'd still need to supply the ISERDES >> with a 1/3-divided clock to get a 6bit-output (this is the clock the >> ISERDES output is registered with). That clock I don't have, I'd need to >> use a DCM or something to generate it. The sample clock on the other >> hand I get from the ADCs along with the data. The whole point of using >> the ISERDES is to save on clock nets, DCMs etc., and simply use what I'm >> supplied with. > > No need for 1/3 divide. No need to use more than one clock coming back > from the ADCs either, the sample clock. There are two issues with > clocking, frequency and phase. > You still need the /12 clock, from the ADC, in order to locate each sample boundary, right? Bob -snipped the rest-Article: 96053
Kolja Sulimma schrieb: > For those ADCs it is not necessary to route both the full clock and the > 1/6 clock to the FPGA. Of course it's not neccessary, but if that's what you're provided with, naturally you look for ways to make it work with that, that's all I'm saying. At first glance, all you need to do is feed the data into two ISERDES in master/slave mode, clock them with the fast clock, hook up the slow clock to the CLKDV-inputs and that's it. And since the clocks you get from the ADCs are perfectly edge-aligned, and the data is perfectly phase-aligned, and you can use the Virtex4-IO-Clocks for everything, theoretically there should be no need whatsoever for any phase-shifting. Instantiate two ISERDES per channel and you're done, no need for anything else, the perfect solution! Now if you start looking more closely it turns out it doesn't work that way. The whole point of the original posting was to find out if I've missed something and you could still do it like that. Of course there's dozens of other ways to do it, and I appreciate all of your suggestions. cu, SeanArticle: 96054
I want to develop driver (support for rtos system) for platform xilinx sparten3e. I don't know which can choose 32 bit processor Open IP-Core.Article: 96055
Erik Widding schrieb: > No need for 1/3 divide. No need to use more than one clock coming > back from the ADCs either, the sample clock. Ah, OK. I thought the ISERDES outputs were always registered with CLKDV. I just "found" the combinatorial output. :) > There are two issues with clocking, frequency and phase. > > The frequency is not an issue because all of your ADCs and all FPGA > resources are receiving from the same clock source (I would hope). Yes, but not all ADCs neccessarily run with the same sampling frequency. At the moment I have one clock source on the board feeding the FPGA. In the FPGA I generate the sample clocks for the ADCs. Those clocks can be different for each ADC (meaning, it's possible I'll have one ADC running at 70MHz, another one at 40MHz and so on; but of course the system has to be designed for the "worst case" of 70MHz). So yes, theoretically everything's coming from the same clock source, but it's going through DCMs and PLLs inside the FPGA and the ADCs, and then I'm not sure about anything anymore. > The phase issue can be broken into two parts, one of global phase, > and a second of bit to bit skew across the channels. The global > phase can be taken care of by using the sample clock output of one of > the ADCs to feed the FPGA. See above, usually it has to be the other way around. OK, I can still use the sample clocks I get back from the ADCs to run the receiving parts in the FPGA, but that's 4 more clock nets, which I admit I have a lot more of in Virtex-4. I've been looking at external programmable clock sources, but up to now using the FPGA was the easiest way to do it. > As temperature changes in the system, and > delays on ADC and FPGA buffers change, they will change together. > This of course assumes that the ADCs in different discrete packages > are subject to the same thermal conditions. ... and the FPGA is as well, which is highly unlikely. In some cases they're not even on the same board. Or the FPGA runs hotter because it has some other stuff to do as well. > The issue of bit skew across all channels can be accounted for > without the ISERDES and the delay element in the IO pin. Your ADC > ouputs all of the necessary test patterns to null the channel to > channel skew. This calibration step would be performed at power up. Yes, that's what I'm doing at the moment, but using DCMs in Virtex2 Pro to shift the fast clock from the ADCs. > You will only need one DCM in the FPGA to multiply up to your bit > clock from the single ADC sample clock, to drive the ISERDES. This > will also get you the proper duty cycle and phasing of the sample > clock in the FPGA to make the suggestion in my previous post work. > > You should need one DCM and two clock nets to get this working > regardless of the number of channels. Well, considering the fact that I potentially have 4 different sample clocks, I'm back at 4 DCMs and 8 clock nets, which is exactly what is needed in the current solution. And potentially I'll have to hook up 8 or even more ADCs to one FPGA, so you see where this is going. As I said in another post: When I first read about the ISERDES, it seemed like the perfect thing: run it with the fast clock from the ADCs, hook up the sample clock to the CLKDV-input, and you're done. No DCMs neccessary, maybe a little delay-tuning here and there, that's it. And with the IO- and regional clocks available in Virtex-4, this would've worked for lots and lots of ADCs running at whatever frequencies. The whole point of my original posting was to find out if there isn't still a way to do it like that. Obviously there are lots of more elegant ways to do it than xapp774, now that Virtex-4 is available. But I do see that your way is probably the most elegant if all the clocks are the same. And there are cases when I need exactly that, so I'll probably be implementing it like that at least in some cases. So, thanks a lot for your insight and this suggestion, it's really helpful! cu, SeanArticle: 96056
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:43dab83f@clear.net.nz... > Antti Lukats wrote: >> my guess about the 3 IR bits not supported was based on fact that as >> soon as reverted >> the ARM into ICE mode with longer IR register everything started to work >> again. > > .. perhaps the Atmel device itself has Bypass problems in the other mode ? > > -jg > the mode that has problems is the boundary scan mode not ICE mode so I do not want to belive that the bypass instruction in boundary scan mode is not implemented properly. Atmel is sure know to have weird silicon bugs, but this time I am relatilvly sure there is no issue with bypass instruction. -- Antti Lukats http://www.xilant.comArticle: 96057
Bob wrote: > You still need the /12 clock, from the ADC, in order to locate each sample > boundary, right? Yupp, that you would have to generate using a DCM. But the clever thing about this is that since you're running the FPGA with the sample clock from the ADC, and the DCM generates a perfectly edge-aligned /12 clock, you have perfect phase relationship between all clocks and data channels, it all fits together perfectly, regardless of the number of channels (assuming that the sample clock is the same for all channels). cu, SeanArticle: 96058
"Mahmoud" <mahmoud.kassem@gmail.com> ha scritto nel messaggio > What are you trying to do (design)? > Why did you choose Handel-C? why not VHDL or Verilog? i yet studied VHDL and i would like to study a new language as Handel-C. Do you counsil me VHDL? why?Article: 96059
If you have to choose a C language I would recommend you check out SystemC which might be better on your CV than Handel-C :-) You can download a free event based simulator from OSCI. The userguide contains some examples for VHDL/Verilog designers. I would also check out Opencores's sc2v SystemC to Verilog converter, http://www.systemc.org/web/sitedocs/library_2_1.html http://www.opencores.org/projects.cgi/web/sc2v/overview Hans. www.ht-lab.com "Roberto" <gioeroby@NOSPAMlibero.it> wrote in message news:Dm2Df.150825$65.4246679@twister1.libero.it... > > "Mahmoud" <mahmoud.kassem@gmail.com> ha scritto nel messaggio > >> What are you trying to do (design)? >> Why did you choose Handel-C? why not VHDL or Verilog? > > i yet studied VHDL and i would like to study a new language as Handel-C. > Do you counsil me VHDL? why? >Article: 96060
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >I've set up a wiki space for discussion of ideas for an open source XDL tool >suite. For those not familiar with wikis, they are collaborative web spaces >that can be edited by anyone (for now it is editable by anyone; if there are >problems we can restrict edit access to approved authors) or by a >select set of individuals. They're used quite commonly for software projects >now as they are great for discussion of features, todo lists, idea boards, etc. > >If you had tools that could parse and programatically generate XDL how would >you use them? Some suggestions have been made in other recent threads here on >comp.arch.fpga, now let's collect those ideas in the wikispace that I've setup >here: >http://thoughtfiz.stikipad.com/XDL_Tools/ Thanks Phil... ummm... is there any way to access it? it keeps asking me to login (which I don't mind, except that I don't have an account, and there's no "register" button :-) >There is a Feature Request page you'll see on the home page. You can go to >that page and edit it or you can add comments to any page by clicking on the >'Discuss' link at the right hand side of the page. well that's one "feature request" but you'll forgive me for not posting it in the right place :-) - Brian (who is almost sorry for "pushing" XDL having seen what the discussion degenerated into)Article: 96061
"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com... > On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: > >> >>I've set up a wiki space for discussion of ideas for an open source XDL >>tool >>suite. For those not familiar with wikis, they are collaborative web >>spaces >>that can be edited by anyone (for now it is editable by anyone; if there >>are >>problems we can restrict edit access to approved authors) or by a >>select set of individuals. They're used quite commonly for software >>projects >>now as they are great for discussion of features, todo lists, idea boards, >>etc. >> >>If you had tools that could parse and programatically generate XDL how >>would >>you use them? Some suggestions have been made in other recent threads >>here on >>comp.arch.fpga, now let's collect those ideas in the wikispace that I've >>setup >>here: >>http://thoughtfiz.stikipad.com/XDL_Tools/ > > Thanks Phil... > > ummm... > > is there any way to access it? > > it keeps asking me to login (which I don't mind, except that I don't > have an account, and there's no "register" button :-) > >>There is a Feature Request page you'll see on the home page. You can go >>to >>that page and edit it or you can add comments to any page by clicking on >>the >>'Discuss' link at the right hand side of the page. > > well that's one "feature request" but you'll forgive me for not posting > it in the right place :-) > > - Brian > (who is almost sorry for "pushing" XDL having seen what the discussion > degenerated into) Hi Brian, agree 'degenerated' is a mild word for whats happened - XDL has been around for pretty long time and if those interested in the use of XDL have not done so far, well that is not the fault of Xilinx (and its license policy). hum, as of the Phil's setup thing, it looked weird that someone is password login authorization protecting websites about some Open-Source discussion. At first I did not want to register at all, then did come back determined to register, but failed to register completly as there seems to be no way to access the pages at all :( Antti Lukats http://help.xilant.com/XDL:ToolsArticle: 96062
Sean Durkin schrieb: > And since the clocks you get > from the ADCs are perfectly edge-aligned, They are not. They are out of phase between 330ps and 860ps at the ADC (according to the datasheet). They will be more out of phase once they arrive inside your FPGA. You will not get away without delay buffers at these data rates. Kolja SulimmaArticle: 96063
Larry Doolittle wrote: > > or just sit down and release the XDL formats and library > > interfaces, along with the exposed chip architectures and > > routing that all of the above listed projects have already > > fully disclosed. > > Whoa, where did "library interfaces" come from? Now you're talking > software, not just documentation. Drop that item from your wish > list. You'll raise fewer hackles. > > The "exposed chip architectures" are very sensitive to Xilinx, but > I think they would listen to a reasoned argument that information > of that type can not be put back in the bottle. Too much of it is > already out there in the patent literature, for example. I know it's a huge mouthfull for Xilinx to swallow. But let's face it, that just publishing the file format for XDL isn't enough. An project that then publishes an XDL output file which would instantiate a design, is then releasing the library interfaces and chip geometry information. Any project that posts a synthesis tool that generates library calls with placement/routing information would be publishing the library interfaces and chip geometry/routing details of the device. While some of this is in the data sheets, most of it is not. Just documenting the XDL file format would leave nearly all the university projects listed in violation of the EULA because of the IP inside the XDL files themselves, and the programs which generate/manipulate them.Article: 96064
Larry Doolittle wrote: > While I despise terms like this in an EULA, they almost make sense > when discussing the running software itself. The most egregious > consequences come from trying to apply them to documentation, as > Xilinx's license does. It's not just the documentation, but the intermediate files themselves, such as the wealth of IP that can be extracted from an XDL file from an instantiated design of any significant size. Much of that IP becomes obscured in the bitstream, especially without the source and intermediate files to correlate the bitstream to. Any project that release intermediate files which use a significant part of the libraries, and other IP cores, does in fact disclose IP which is either directly usable in other non-xilinx designs, or is very easily converted/reverse engineered, rendering the reasons behind the strict EULA terms moot. Files which contain fully routed designs, with back annotated timing information disclose a wealth of internal IP about Xilinx product ... if not nearly all. The younger generation has played fast and loose with IP now for about a decade. Many do not take the time to read the EULA's or employment contracts they sign, or any other legal document for that matter. I've sat on both sides of the table over the last 35 years, doing faculty sponsored security research (AKA hacking), reverse engineering, and defending my employer/company after others breaches and claims. This whole series of threads has a common theme in that people do not know what the legal requirements are that they are commited to, and frequently assume completely contrary to the exact terms they are bound. We see this in the vast theft of music and other IP on the internet, and the huge number of P2P proponents claiming it was legal to ignore copyright restrictions against illegal "broadcasting" and "distribution" of music, videos, movies, and computer programs/data because there was no profit involved, or that P2P downloading servers are different from other forms of pay-per-view content on demand broadcasting services. We see in retrospect that the high court rules against P2P using the standard that if it looks like theft, it is theft. We see the same theme in handling other industries IP, such as Xilinx restricted IP. While I took a lot of heat over the JHDLBits disclosure that after a year, the project was held up in negotiation with Xilinx for IP release, is exactly an example of not negotiating the exact terms of the licenses and disclosure at the begining of a project rather than wading thru all the ramifications in difficult discussions about just what can and can not be released at the end. That it apparently was resolved to everyones satisfaction, which is great, but the lesson is to take note that these issues need to be resolved before your project gets a C&D letter along with a huge claim for damages from the release of another companies IP. Many years ago the universities got up in arms when AT&T tried to enforce the proprietary interests in UNIX that were being violated by teaching the source code in class rooms. The issue of educational sites handling NDA restricted material, particularly in the form of EULA's needs to be carefully addressed by our schools. Here we have a long list of schools treating the IP in Xilinx's ISE software with the same degree of care they would a software title like Norton Utilities. And we have Xilinx employees advocating the same, dispite the very very strict EULA terms. We also have the most respected posters in this forum doing the same. I'm just tring to be open, honest and ethical in FpgaC's handling of this Xilinx IP - which in order to get equal access as all these other projects means confronting the issues and hopefully getting Xilinx to realize the cat is way out of the bag, isn't likely to be going back in, so we should look at the defacto state of their IP and adjust the licenses to reflect actual use -- or do the very nasty thing of sending everyone C&D letters and forcing all these schools to treat the Xilinx IP with the degree of care the EULA requires. The kill the messenger reality is a bit tough sometimes ...Article: 96065
Simon Peacock wrote: > This is also true.. but that is NOT what a C programmer calls C code ;-) > If you are going to write Boolean equations in C then you might as well use > one of the "official" languages as others can help. > my two cents :-) > > Simon > > P.S. I didn't see any sin functions :-) Sorry ... but the arithmetic functions in every synthesis tool are reduced to the boolean equations too ... FpgaC included. My point is that C based HLL's, or even the HLL versions of them, can do just as good a job at both the boolean's and the arithmetics, as you will see in VHDL doing arithmetics. Nope .... but didn't you get the point that better arithmetics are on the list of development projects for FpgaC? And that working with someone to implement them in a useful way would just add to the value of FpgaC?Article: 96066
Well I just started the download so I think it is really there. I'll know for definate in about 2 hours. I got the notification on the 20th Jan and I don't think we are on the advanced list for distribution. As with any of the major vendor software releases I would ideally wait for a service pack or two to be released before use on a really critical project. However if it has features you need today then go ahead and hope that the internal distribution that goes on Xilinx, before release, has picked up the major bugs. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development Board. http://www.enterpoint.co.uk "Eric Smith" <eric@brouhaha.com> wrote in message news:qhy811jiqo.fsf@ruckus.brouhaha.com... > John Adair wrote: >> EDK 8.1 is available from late last week to existing customers by the >> download mechanism. > > I just spoke to someone in Xilinx Customer Service, and she said that > although they had expected the official release of EDK 8.1 to occur this > past Monday, that apparently it did not, and she's not sure when it will > be. > > The same thing happened with ISE 8.1; some customers were able to > download it before the official release, but others were not. > > It seems reasonable to expect that the official release will occur > soon. > > EricArticle: 96067
For all of those that have asked me "can you make us one" here is your chance to win one. The Raggedstone1 RS1-1500 special is only available under certain circumstances and not normally sold as a one off product so we're not selling it but giving it away it. Competition details are here http://www.enterpoint.co.uk/competition/comp1_7_3_2006.html . Entries by 5th March 2006. John Adair Enterpoint Ltd. - Home of Raggedstone1. The $90 Spartan3 Development Board. http://www.enterpoint.co.ukArticle: 96068
Larry Doolittle wrote: > That's a long list. I should spend more time with Google. Yep ... it's almost temping to spend a few days in Google, print out all the projects, highlite all the infringements, and send them to Xilinx legal. I understand that any trade secret or proprietary interests that Xilinx then chooses to leave in the public, by not acting with due diligence to protect, would fall into the public domain (if it hasn't already). They would still have copyright on all the materials, but fair use under copyright would allow full access to "interfaces" and just being able to use, discuss, and program in support of the product without the very restrictive EULA interference. This would allow public documentation of the interfaces for all objects viewable from the intermediate ISE files, in addition to what was already openly documented in the ISE manuals. That would certainly greatly open the field for open source development to augment the Xilinx tool chain. E.I. duPont deNemours & Co., Inc. v Christopher, 431 F.2d 1012 (5th Cir. 1970), cert. denied, 400 U.S. 1024 (1971). is the citation normally used to describe this. The bottom line is that if they do not take every step to protect their rights in trade secrets, that right will be denied, and all claimed rights will be forfeited. Thus it would be fair game for open source development to fully use any and all information found both in ISE and all the university projects that contain this information as well, as the foundation in the ISE EULA would be completely breached.Article: 96069
"Sean Durkin" <smd@despammed.com> wrote in message news:443kkjF6j7sU1@individual.net... > Bob wrote: >> You still need the /12 clock, from the ADC, in order to locate each >> sample >> boundary, right? > Yupp, that you would have to generate using a DCM. But the clever thing > about this is that since you're running the FPGA with the sample clock > from the ADC, and the DCM generates a perfectly edge-aligned /12 clock, > you have perfect phase relationship between all clocks and data > channels, it all fits together perfectly, regardless of the number of > channels (assuming that the sample clock is the same for all channels). > > cu, > Sean Simply dividing the sample clock by 12 (using a DCM) doesn't give you the boundary of the 12bit sample. You only have a one-in-twelve chance of getting it right. There is no way to deduce the sample boundary by inspecting the serial data stream. BobArticle: 96070
Hi John, "But it's never good design practice to have tristates with multiple sources; " I disagree with your opinion. Tristate gates are used everywhere in an ASIC chip with no exception of FPGA. BLOCK RAM in Xilinx chip has to use tristate to get the selected data to output. In my opinion, there are two types of tristate buses: 1. Passive. It works well for interrupt system. If one of sources is to assert, it pulls down the bus. If it is to deassert, tristate the output and leave the bus to return high state by a pullup. It cannot be used for fast data transactions. 2. Active. It works well for any multiple mutually exclusive sources to drive a data bus. The example is BLOCK RAM in Xilinx FPGA. In a normal FPGA design, the tristate bus can be safely used for the last stage of data output. This type of tristate buses is active because only one source drives the data bus at each clock, either high or low, there is no limit on its driving data. In my many designs, tristate data bus for the last stage of data outputs is much better than combinational logic. I will do a comparison between a tristate bus and its logic equilance for Xilinx chip to see if there is any impact on the performance. I have been always using tristate bus for my last stage of data outputs. By the way, there is an patent from Xilinx: 5,677,638 "High Speed Tristate Bus with Multiplexers for Selecting Bus Driver". It deals with what you want to know. One trick is you always can find the most secret or core technology of Xilinx by reading their patents. All patents must meet a requirement that can be implemented by people in the art. We always belong to the people in the art. In my opinion, there are many smart and brand new ideas imbedded in the 1100 patents of Xilinx that give you many lessons, teaching and experiences that couldn't get from college or textbooks, but they also expose many points that can be further improved. Altela seems to adopt another type of strategies and tries to keep its secrets as commercial ones. Recently Alterla has gotten few patents. I don't know why. WengArticle: 96071
wtxwtx@gmail.com wrote: > Hi John, > "But it's never good design practice to have tristates with multiple > sources; " > > I disagree with your opinion. If an unseasoned engineer is developing code or if the code can be targeted by engineers months later into an architecture where the tristates are no longer "equivalent" tristate functionality, problems may arise. The tools will not exclude two drivers active at once. The new architecture with the real internal tristate might go pfffft. To Dominik's credit (the original poster) he's trying to find out about the less-than-clear practice of synthesis providing tristate emulation. Careless use of tristates is especially bad if a later retargeted architecture is an ASIC. If you know everything you're getting into, tristates with multiple *simultaneous* sources is fine but the code can't be moved to an architecture where the internal tristate bus contention will fry the device (any implementation with one source active at a time is fine, but multiple active drivers is not - perhaps this nuance wasn't communicated well before). As I stated in the original reply, I indeed designed a multiple-simultaneous-source tristate bus in the FPGA architecture where the behavior of the tristate emulation was very clear. It would not be good design practice to do this willy-nilly but only to do it when it's guaranteed there will be no disasterous side effects now or for other engineers later. And as you pointed out, it is just my opinion. - John_HArticle: 96072
Dear Friends. Well i am quite new to this FPGA thing...My project is on Video Compression and i want it to implement in Xilinx platform. I am finding really difficult in acquiring the video frames and is it possible to do it in simulator mode( AND NOT REAL TIME......!)??. It would be really helpful if anybody could guide me. I have the latest Xilinx ISE 8.1i..is this platform sufficient or do i need something else?? please guide someone..it is really important.Article: 96073
Marco T. wrote: > Hallo, > Is it possible to connect a FSL peripheral to a XCL channel of Xilinx > Multi-Channel Sdram Controller? > > I would read data from memory and send it out the fpga. Yes, this should be fine. The signal interface is identical, you just need to make your FSL peripheral talk the XCL protocol. See pp 51-54 of the MicroBlaze refernce guide. Regards, JohnArticle: 96074
Sean Durkin wrote: > > Sounds good, but the half-rate logic would still be running at 210MHz > in my case. I need more deserializing, need to make it slower :) > Once you have the DDR data reclocked successfully off the local clock domain onto your global clock, you can use a straightforward demux to lower the data rate as much as you'd like, generating the lower rate clock with a DCM; those V4 phase-matched-divider widgets could probably be used in place of a DCM for the sub-rate clock. Your original post seemed to be looking for a method of obtaining complementary internal output signals from only one LVDS input pin. I was trying to point out that that capability already exists in the V2 derived parts, and most likely in V4 as well (esp. with the V4 differential clock tree, I'd expect one to get inverted clocks for free with no local inversion skew penalty, but I haven't checked this yet). DDR clocking notes: One tricky bit on V2, getting that same local clock on a global clock network, is made easier in S3E by provision for local clock pins to drive the global clock network; I'd expect that something similar exists in V4. Another DDR clock alternative in V2 is to use an IBUFGDS_DIFF_OUT to directly drive your 0/180 DDR clocks without getting a DCM involved. A/D Clocking notes: You seem to be saying in another post that you source variable rate A/D sample clocks directly from the FPGA; perhaps I misunderstood that post. Clocking high speed A/D's with an FPGA generated clock is a very bad idea, as the inherent DCM & SSO jitter will quickly render the sub-ps RMS A/D aperture jitter specs useless, giving you maybe a handful of effective bits worth of data at the rated A/D input bandwidth. Brian
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