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
In article <3F0AE7CC.68F9D9D0@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >I need to vent a little steam. So at risk of making myself look stupid >(or more stupid) I will do it here. Silly question, why not drive over to Frys or whatever and stick a $10 ethernet card in your system? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 57851
Mike wrote: > I declared a std_logic_vector(7 downto 0) (inout type) entity port > in my VHDL program. In the testbench, I will try > to assign some value to this port. But after synthesis > using Synopsys Design Compiler, I found this port wouldn't > accept the value from signal assignment in the test bench > and the value of this port becomes "XX". Post your code. Your output enable logic is likely the problem. -- Mike TreselerArticle: 57852
You haven't really given us enough information - you should post a little more about the problem; are you getting an error or warning from the simulation, and if so, what exactly is happening around the time of the error. Also we need to know a little more about your application. Are you using the same clock for both ports of the ram (i.e. are CLKA and CLKB driven from the same BUFG). If so, there is one condition where reading and writing to the same address is legal - if the port doing the write is set to "READ_FIRST" (an attribute set on the RAM), then the data returned from the read port is the previous contents of the RAM. You also don't specify if the two ports of the RAM are the same widths. That being said, you say that you have "logic to avoid hits over the same address", meaning you are (trying to) guarantee that you never attempt a simultaneous read and write to the same address. In the past, we have had some problems with the simulation models of the CoreGen RAMs; we definately had situations where the model would erroneously declare a read/write conflict (i.e. there have been bugs in the simulation models in the past). So, the question is, are you sure there is no conflict. It should be easy to verify by looking at the waveforms (capuring all the inputs and outputs of the Dual Port RAM in question). If you are getting an error, look at the waveforms around this error to determine if you are indeed writing and reading to the same address (or similar addresses) at the same time. Remember, if the port wirths of the two ports are not the same, then the "same address" from the point of view of the RAM is not simply ADDRA == ADDRB; if portA is 16 bits wide and portB is 4 bits wide then a contention exists when ADDRB/4==ADDRA Avrum "Nap" <nap@4plus.com> wrote in message news:4ca417fe.0307040701.52e71a46@posting.google.com... > Hi guys. > > I'm working on a project using a HW platform with an XC2V300FG676-5. > In my design I used Dual Ports BRAM produced by Coregen 4.2i (in Fndtn > 4.2i). In simulation of the logic I faced the following problem: > I wrote data on Port#A but when tried to read them back using port#B I > realized that have been altered. Xilinx claims in Answer Record 10462 > that this condition > has to do with conflict resolution over the BRAM (same Read address on > Port#B with write address on port#A). The answer they provide does not > help me at all because I have alot and complicated logic in order to > avoid hits over same address. Does anybody knows if this condition > affects only simulation? > > Thanks in advanced > NapArticle: 57853
On Tue, 8 Jul 2003 14:33:20 +0200, "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote: >Hello, > >I want to make a phase measurement at 100MHz with a NCO at 200+ MHz >This NCO will have a 32 bit phase accumulator and a 32 bits phase offset. The >output will be only one bit. >I will use a phase comparator followed by an integrator (digital or analogic >if needed). >At 100MHz the NCO output will be very very noisy but if I integrate it for a >rather long time (10ms) will it have a 0 mean ? >Can I implement this in an FPGA or should I use a DDS chip (AD9854) ? >Where can I find some maths on this subject ? Do you need to know the spectrum of the noise, or just the peak to peak value? I sometimes find myself in the situation of having to work out the spectral characteristics of the phase noise (jitter) of the msb of a phase accumulator. E.g. if I am using a post-NCO PLL (as Peter A. suggested) then I only care about the phase noise components at offset frequencies less than the loop bandwidth of the PLL. I don't know of a closed form expression for spectrum of the noise, but it's trivial to work out the spectrum with a spreadsheet (once you know how). This is much easier that trying to measure the spectrum in the lab. (Reply if you are interested in the method.) BTW, Peter's trick of reducing the jitter by a factor of 4 (I assume) relies on using a 4 phase clock. This is almost certainly worth the effort if you are trying to reduce the jitter. I have a worked example that uses a 2 phase clock (actually it uses both edges of a single clock) in my free fractional N divider generator, at this web site: http://fractional_divider.tripod.com/ (Note: some web proxies don't like domain names with underscores.) Allan.Article: 57854
The terminology here is a bit tricky - there are three different things here - IBUF, IBUFG and BUFG. An IBUF is a "regular" IOB configured as an input. An IBUFG is one of (depending on the size of your device) 16 IOBs on the device that can be configured as a "global clock input" These IOBs have special dedicated connections to some of the clocking resources in the FPGA. The output of an IBUFG has a dedicated route to - the CLKIN of all/some of the DLLs/DCMs on the same side of the chip (depends on version and family) - the CLKFB of all/some of the DLLs/DCMs on the same side of the chp - the input of the BUFG directly in line with the IBUFG These dedicated routes are provided so that timing to these resources is guaranteed by design. A BUFG is the global buffer that drives the low skew global clock nets of the FPGA. There are a lot of rules about the use of these clocks (refer to the handbook), but the global clock nets (and hence, effectively the BUFGs) can be used to clock all the clockable devices (slice FFs, IOB FFs, BRAM clocks) with a guaranteed clock skew. The BUFG can be configured to be a BUFGMUX or BUFGCE (which both effectively use two BUFGs). That being said, you can use a DCM without a BUFG, and still have access to the phase shift and deskew mechanisms of the DCM. You MUST drive the CLKFB with something combinationally related to CLK0 or CLK2X - you cannot feed a divided clock back into CLKFB. For example, you can connect your input clock via an IBUFG to CLKIN of the DCM, connect CLK0 to an OBUF, connect (on the board) the OBUF to a second IBUFG, and connect the output of the second IBUFG back to the CLKFB of the DCM. This will effectively keep the output clock (the output of the OBUF) in phase with the input clock (or phase shifted according to the fine phase shift of the DCM). Unfortunately, this doesn't help you with a divided clock; the net from the CLK0 to the OBUF will use general routing, and hence will have different timing from P&R run to run. So for example, if you run the CLKDIV of the DCM to a second OBUF, there is no guaranteed phase relationship between the two OBUFs (the routing of the two nets can be quite different). If you have even one BUFG available, then there are other options (using the DDR flops in the IOBs). I presume you are using Virtex II or II-pro (since you talk about phase shift). Remember, that the clocks in Virtex-II are quadrant based, so if you can free up a BUFG for use in even one quadrant, you have some options. What part are you using, and how many global clocks do you need? Avrum "John" <jfornews@rogers.com> wrote in message news:3F0A04F8.6080107@rogers.com... > Be carefull. Usually when you instantiate a ibufg, you are actually > instantiating a IOB configured as an input, and a bufg. You only want to use an > IOB as the input and make sure it is loc'd to a clk input pin location. > > As for your div/2, you can divide the input to the dll by 2 using the > CLKIN_DIVIDE_BY_2 parameter. Don't know if this helps because the clk0 will be > div/2 since the dll is dividing the input to the dll. > > > > > > Markus Meng wrote: > > Hi All, > > > > some notes I could not figure out directly from one of the XAPP132, 174 > > from Xilinx. If I want to drive an Off-Chip device with half of the clkin > > frequency > > without using a GBUF driver, can I feedback the devided signal from the obuf > > driving the pin through an IBUFG and still having the DLL functionality of > > phase > > shift an duty cycle correction. I read that the feedback signam MUST be > > clkout > > or 2xclkout. The problem is that I am running out of GBUF's in my design ... > > > > markus > > > >Article: 57855
Hi Fellows, How can I synthesize multiple file one by one using xilinx compiler in MAKEFILE script. I have done using only one file but when I enter multiple files in "VHDL= ....." field thenI get the following error. make: *** No rule to make target `VIR3.vhd,VIR3_1.vhd,VIR3_2.vhd Rgds MACEIArticle: 57856
Hi, I am having trouble with the GCLK feature in my design. Basically my code is a 4 way handshaking protocol between my PC and the FPGA on one hand and another 4 way handshaking with an asynchronous chip on the other. I am providing a clock to the system through the GCLK0 pin using an oscilltor. I further require edge tests on three lines that I receive from the computer and the chip - which means they are inferred as clock signals. A total of 4 clocks. However when I try to implement the design the engine complains that my design is too large Number of GCLKs: 6 out of 4 150% Number of GCLKIOBs: 1 out of 4 25% I cannot understand why this is so. I take the input from my CLKIOB and pass it through a clock divide routine that I wrote and use that signal as my global clock. The rest of the three lines go through BUFGs befor entering the design. I would loke to pass my divided clock through a BUFG so that it does not suffer from skew. To see what the problem might be I implemented another design which has only one clock - the global clock that I divide and pass through a BUFG but still the engine reports Number of GCLKs: 3 out of 4 75% Number of GCLKIOBs: 1 out of 4 25% I was not clear on how this inference is taking place - possibly because of IOB placements that are hardwired and result from clock test or bad clock management. Could someone advice on how to remedy the situation. Would a Clkdll help? I am not very clear on how it will solve the problem with the multiple clock lines or even how it broadly works. Thanks UdayanArticle: 57857
Tim Hogard wrote: > I have the need to duplicate the code that is in one Altera EPC2 > to another one on an identical bit of hardware. The device has a > 10 pin JTAG connector. > > Is there a low cost, easy way to suck the bits out and put them > into the other EPC2? I also have a .jbc file as well if that makes > it easier. > > I was doing a flash upgrade but the device reset before it finished > resulting it a dead bit of hardware. To get it fixed, it has to > be sent 1/2 world away and tech support hasn't ever done that and > don't know if they can even fix it so I'm looking for a better > option if one exists. It's been a while I last used MaxPlus2 or Quartus2. Don't they allow reading the EPC2, assumed the protection bit is not set ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 57858
Can anyone tell me good books or web sites related to following. 1. MAKE file for VHDL ( XILINX) 2. Implementation of Coding using FPGA Rgds MACIEArticle: 57859
Udayan <udayan@jhu.edu> wrote:
: Hi,
: I am having trouble with the GCLK feature in my design.
: Basically my code is a 4 way handshaking protocol between my PC and
: the FPGA on one hand and another 4 way handshaking with an
: asynchronous chip on the other.
: I am providing a clock to the system through the GCLK0 pin using an
: oscilltor.
: I further require edge tests on three lines that I receive from the
: computer and the chip - which means they are inferred as clock
: signals.
: A total of 4 clocks.
: However when I try to implement the design the engine complains that
: my design is too large
: Number of GCLKs: 6 out of 4 150%
: Number of GCLKIOBs: 1 out of 4 25%
: I cannot understand why this is so. I take the input from my CLKIOB
Look at the synthesis report (*.syr) and at the graphical representation of
your circuit ("View RTL Schematics"). It will give you a glimpse of what is
going on. Then rethink the way you wrote your HDL implementation. In the
synthesis report, the "Clock information" might be the most important
thingto look at.
Bye
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 57860"rickman" <spamgoeshere4@yahoo.com> wrote in message <SNIP> > I am not looking for champagne on a beer budget, but I would sure like > to be able to pour them both into the same glass. Isn't that a bit of redneck perspective -champagne in Budweiser glass ? ;o)Article: 57861
Geeze .... I'm glad altera doesn't waste valuable time on your problem , they have real work to do. They have standardized on the ethernet interface, if you have a desktop spend $15 and buy one, if you have a laptop without one you may have to spend twice that on a USB version or something. You must have lots of time and little work. On Tue, 08 Jul 2003 11:48:28 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >I need to vent a little steam. So at risk of making myself look stupid >(or more stupid) I will do it here. > >I have been trying to get the Quartus 3.0 software and a license since >last Thursday. I tried three times over the weekend to download it, but >the slow modem link I have to use would not complete the entire transfer >without a problem. I think I have that licked as my brother tells me he >has downloaded it for me. > >But I have been trying to get a license file that does not require an >Ethernet interface and am getting nowhere. I have received several >emails from Altera people who say that they support this and I need to >contact my local FAE or the main office. I have tried to do both. All >of the FAEs I know are either on vacation or in California at training. >Calling both 800 numbers has gotten me nowhere since I reach people who >are the "first line" and always have to refer it to someone else. I >have left about half a dozen voice mails, sent easily a dozen emails, >spoken with two types of support and still I have not heard back from >anyone at Altera about this. > >Right now I have been holding for about 15 minutes waiting for a third >number to connect me with a person. I know that if I was this hard to >get ahold of no one would *ever* buy any of my products! > >-- > >Rick "rickman" Collins > >rick.collins@XYarius.com >Ignore the reply address. To email me use the above address with the XY >removed. > >Arius - A Signal Processing Solutions Company >Specializing in DSP and FPGA design URL http://www.arius.com >4 King Ave 301-682-7772 Voice >Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57862
> I made this statement because one of my clients is in a marketplace > (military and medical) where they ship systems for years and years because > the customers don't care about the costs they just don't want to rewrite > or requalify software. That's your client, not us. > You don't seem to understand that Xilinx isn't removing support for the > old devices, they aren't adding support for those devices to new tools. ISE is not a new tool, just a new release with no support for Spartan. > Periodically Xilinx completely rewrites some component. They do this > because the requirements change for each new generation. Are you talking for Xilinx now? Are they also a client of yours? > part. If you were to add support for old parts into the new tools you > would expect that the new tools to be riddled with bugs for that part for > the simple reason that nobody is using that tool set on that part, and > therefore nobody is finding the bugs. I expect Xilinx to maintain a certain level of quality in their software, and I would not expect the tools to be riddled with bugs, ever! > Anyone who uses a brand new part > knows how buggy the tools can be for the first six months or so. Now > imagine that you are the only person in the world that was using that > part, the bugs would never get fixed. And the part would never be made. > That's exactly the situation that an > obsolete part would be in if it were supported by the newest tools. It > would be like the part was perpetually in beta release. The fact they are unable to isolate the sections of code that are unique to a given part tells me the code is poorly structured. So the code may grow. It's not like a modern PC is resource limited. ISE currently ships with 6 CDs. Do you think I really care if it ships with seven? Again, I have not seen the case you are describing with Altera's router. Try to be more data driven with your comments.Article: 57863
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3F0AE7CC.68F9D9D0@yahoo.com... > I have been trying to get the Quartus 3.0 software and a license since > last Thursday. I tried three times over the weekend to download it, but > the slow modem link I have to use would not complete the entire transfer > without a problem. I think I have that licked as my brother tells me he > has downloaded it for me. Get a download manager like Gozilla or something. The can resume a aboarded download. -- Regards FalkArticle: 57864
You didn't mention the radix of each stage. Divide by 4 is too much if
it is a radix2 butterfly. If it is radix 2, the gain is at most 2, not
4. The max output from an FFT occurs when all the input energy falls
into one output bin, which implies the input is a pure sinusoid with a
frequency that is an integer multiple of the sample time. If the input
is white noise, the output signal energy is going to be spread evenly
among all the output bins, in effect dividing the input signal by N. As
you can see, this results in a fairly wide dynamic range. If you know
the nature of your input, you can scale accordingly. If not, you need
to either carry extra bits or you can use dynamic scaling such as a
block floating point scheme.
Bob wrote:
> Hello,
>
> I have constructed a 256 pt complex fft. My scaling is causing
> problems as the outputs from each stage are divided by 4 to avoid
> overflow. The input data and the twiddle factor coeffs are 16 bits
> wide (Q15). My problem is that when the data arrives at the last two
> butterfly stages of the FFT, it is non-existant, due to all the
> scaling beforehand. All inputs to these stages are zero. Thus I get
> nothing at the output.
>
> How can I work around this?
>
> Many thanks
>
> Bob
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 57865On Tue, 08 Jul 2003 12:55:42 -0700, lecroy wrote: >> I made this statement because one of my clients is in a marketplace >> (military and medical) where they ship systems for years and years >> because the customers don't care about the costs they just don't want >> to rewrite or requalify software. > > That's your client, not us. > >> You don't seem to understand that Xilinx isn't removing support for the >> old devices, they aren't adding support for those devices to new tools. > > ISE is not a new tool, just a new release with no support for Spartan. ISE is just the GUI front end for the tools, it's not the important part of the Xilinx tool suite. The key elements are the mapper (map), the place and router (par), and the timing analyzer (trce). Xilinx is also now doing a synthesis tool of their own (XST) which is one more piece of the puzzle that has to be supported for each device. I was told by Xilinx that map was rewritten for the 5.x release. The 6.x release is going to be 64 bit as well as supporting native Linux, so that means that every important piece of the tool chain is subject to major changes. Which means in turn that the tool set has to be QAed on every part that it supports. The more parts that they have to support the harder the QA job is. >> Periodically Xilinx completely rewrites some component. They do this >> because the requirements change for each new generation. > > Are you talking for Xilinx now? Are they also a client of yours? I'm not talking for Xilinx, but I do talk to them all the time. With any complex piece of software, not just Xilinx's, you have to make choices when you go forward that requires you to lose some features that you had in the past in order to improve support for the things that you need to do in the future. To give you an example from a field completely unrelated to this one, last week Adobe announced a new version of their video editing software, Premiere. As of this release they are no longer supporting Macs, just XP. Premiere was originally written for the Mac and for years was a Mac only product but now the number of Mac users is to small for Adobe to bother doing a Mac port. When they did a radical rewrite they choose that moment to drop Mac support. The same thing goes for Xilinx and Spartans. No one is doing new designs with the original Spartan family, so it's not worth Xilinx spending any money putting in support for Spartans in their new tool sets. The old tools are completely adequate for doing anything that you need to do with a Spartan. Just because there is a new better faster tool set available doesn't mean that the old stuff has suddenly vanished from the face of the earth. Disk space is cheap, you can have as many versions of the tools as you want on a system, all you have to do to switch between one rev and another is change an environment variable. >> part. If you were to add support for old parts into the new tools you >> would expect that the new tools to be riddled with bugs for that part >> for the simple reason that nobody is using that tool set on that part, >> and therefore nobody is finding the bugs. > > I expect Xilinx to maintain a certain level of quality in their > software, and I would not expect the tools to be riddled with bugs, > ever! All software has bugs and x.0 software has lots of bugs. Xilinx is actually better than most but whenever they add a new family or do a major rewrite there are bugs. I did an Altera Stratix design last year and every piece of software in their design chain was broken, starting with the Verilog models which wouldn't even compile. I've never had that level of problems with Xilinx but I've certainly encountered my share of bugs in their stuff over the years. > >> Anyone who uses a brand new part >> knows how buggy the tools can be for the first six months or so. Now >> imagine that you are the only person in the world that was using that >> part, the bugs would never get fixed. > > And the part would never be made. My point is that the support for an old part in a new tool wouldn't be any better than the initial beta release of a new part. The difference being is that with a new part lots of people are using it so that the software bugs get found and fixed. With the obsolete part there will be hardly anyone using it so the bugs aren't going to get found, the fixes aren't going to get made, and the software quality will be beta forever. With the tool set that existed at the end of the parts mainstream life the software was mature. You benefit from the years of cumulative bug fixes that had been applied, that's the stuff you want to be using if you have to make a change to an old part. > Again, I have not seen the case you are describing with Altera's router. > Try to be more data driven with your comments. As I said before my experience with Altera has been much worse then with Xilinx. The kind of bugs that I encountered with the Altera tool set indicated that they hadn't done any QA at all. In all fairness I was doing a Stratix design which was a beta part at the time so you would expect all sorts of problems.Article: 57866
This is an FPGA question; I removed comp.lang.vhdl from this followup. If you put your clock signal on a GCK pin, and ISE recognizes it as a clock signal, the GBUF gets added automatically. (ISE adds a GBUF to almost everything it recognizes as a clock) At 30 MHz, the only constraints you will (probably) need is to lock down the pin numbers. Typically, the 2nd constrain you add is the clock speed (the 1st being the pinout). Other constraints are added to help the software meet the speed constraint. (pre-assigning locations, that kind of stuff) Hope that helps, SH7 On Thu, 3 Jul 2003 22:13:22 -0400, "Jason Berringer" <look_at_bottom_of@email.com> wrote: >Hello all, > >I would like to know a couple of things if anyone could help or point me to >a file etc. I'm using Webpack from Xilinx, and a Spartan XC2S100 and I've >been messing around with writing simple project to get familiar with VHDL >and programming the board. I'm curious to know if I have to instantiate a >global clock buffer each time I sythesis my design, or if I simply make sure >that my clock goes to a GCK pin is that enough? Also I'm a little confused >as to what constraints are and how they might help my designs. For example >if I have a 30 MHz clock going to a GCK pin do I have to put constraints on >it or are constraints primarily used for very complex designs? > >Sorry if this seems like small question, but it is somewhat confusing from >the documents that I have read, and since I haven't had any problems with >any of my projects (without using any constraints) I was not all that >worried. Now that I'm getting into bigger designs I figured that it was time >to start figuring this out. > >Any and all help is greatly appreciated. > >Thanks > >Jason >Article: 57867
"Allan Herriman" <allan_herriman.hates.spam@agilent.com> > On Tue, 8 Jul 2003 14:33:20 +0200, "Marc Battyani" > <Marc.Battyani@fractalconcept.com> wrote: > >I want to make a phase measurement at 100MHz with a NCO at 200+ MHz > >This NCO will have a 32 bit phase accumulator and a 32 bits phase offset. The > >output will be only one bit. > >I will use a phase comparator followed by an integrator (digital or analogic > >if needed). > >At 100MHz the NCO output will be very very noisy but if I integrate it for a > >rather long time (10ms) will it have a 0 mean ? > >Can I implement this in an FPGA or should I use a DDS chip (AD9854) ? > >Where can I find some maths on this subject ? > > Do you need to know the spectrum of the noise, or just the peak to > peak value? The spectrum I think. In fact I need to have a very precise phase lock (0.1%). The frequency lock is already ok as I have the reference clock. > I sometimes find myself in the situation of having to work out the > spectral characteristics of the phase noise (jitter) of the msb of a > phase accumulator. E.g. if I am using a post-NCO PLL (as Peter A. > suggested) then I only care about the phase noise components at offset > frequencies less than the loop bandwidth of the PLL. I thought about filtering and integrating the phase error after the phase comparator. I don't think I need a PLL as I'm not synthesising a frequency. > I don't know of a closed form expression for spectrum of the noise, > but it's trivial to work out the spectrum with a spreadsheet (once you > know how). This is much easier that trying to measure the spectrum in > the lab. > (Reply if you are interested in the method.) Sure, please explain how to do it, I'm really interested. > BTW, Peter's trick of reducing the jitter by a factor of 4 (I assume) > relies on using a 4 phase clock. This is almost certainly worth the > effort if you are trying to reduce the jitter. > I have a worked example that uses a 2 phase clock (actually it uses > both edges of a single clock) in my free fractional N divider > generator, at this web site: > http://fractional_divider.tripod.com/ > (Note: some web proxies don't like domain names with underscores.) Thanks, I will look at it. MarcArticle: 57868
"John_H" <johnhandwork@mail.com> wrote > "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote > > > > I want to make a phase measurement at 100MHz with a NCO at 200+ MHz > > This NCO will have a 32 bit phase accumulator and a 32 bits phase offset. > The output will be only one bit. > > A 1-bit output will give you NCO phase noise that has a range of 5nS > peak-to-peak based only on the single bit output. The only exception to > this value is when you run at a fractional value such as 100 MHz from the > 200MHz clock where the accumulator acts as a divide-by 2. [I guess all > frequencies will be a fractional relation - 1329046/2^32 is still a > fraction. The arguement applies to small whole number fractions such as > 3/16.] The way to get good performance from the system is to use the full > DDS - an NCO with a D/A such as those very nifty Analog Devices parts. > > > I will use a phase comparator followed by an integrator (digital or > analogic > > if needed). > > At 100MHz the NCO output will be very very noisy but if I integrate it for > a > > rather long time (10ms) will it have a 0 mean ? > > If you compare the phase to a noise-free reference that is precisely the > desired frequency, the low-passed output of the phase comparator will > conceptually be the phase offset between your NCO and the noise-free > reference. I say conceptually because this is not a practical test. If > you're trying to figure out of the phase noise is "lopsided," you should > find the phase comparator output is some form of sawtooth. If the frequency > is very close to a fraction of the 200MHz clocking frequency, your phase > comparator output will appear to recover from a step function while the > reality is that it's a very long sawtooth. Your frequency give you results > with phase variations that are much closer in time where it's hard to see > the longer term sawtooth characteristics beyond the very large, high > frequency variations you see without the lowpassing. Yes I don't want to have a 23mHz noise (100MHz / 2^32) > > Can I implement this in an FPGA or should I use a DDS chip (AD9854) ? > > The NCO can be implemented in the FPGA. You could drive a D/A with the FPGA > though it's recommended that the D/A's clock be sourced direclty from your > low phase-noise source rather than passing the clock through the FPGA. The > DDS chips with integrated D/As are the best for this kind of thing. If I need to have more than 1 bit of resolution for the output I will use a stand alone DDS. > > Where can I find some maths on this subject ? > > Unfortunately, the maths are a little loose on the phase noise results. > I've only seen textbook treatment of simple jitter: a sinusoidal phase > variation. The Bessel function is a result of the Fourier of the > > sin(wt+Psin(at)) > > kind of form (ah, my kingdom for an ohmega, phi, or alpha on this keyboard). > The Bessels give you only a slight idea of what happens in the NCO realm. > The investigations I did went through a theoretical setup I described above. > Determine the time domain of the phase comparator output from your NCO > compared to the "ideal" noise-free reference mathematically. The pattern > will repeat when the NCO accumulator values repeat which will happen at > least every 2^32 cycles. This time-domain result might be what you seek. > The frequency domain interested me, so I took the FFT of the time domain. > > If you're only interested in close-in phase noise and higher frequencies are > a non-issue, there are ways to increase the peak-to-peak phase noise while > decreasing the close-in phase noise. A google on "MASH" and "frequency > synthesis" might bring up results on that advanced subject. Ok I will look at this MarcArticle: 57869
"Peter Alfke" <peter@xilinx.com> wrote in > I have been playing around with the idea of a 32-bit DDS circuit at 200 > MHz ( as a digitally controlled VCO) and I know some tricks to reduce > the timing uncertainty from the obvious 5 ns by a factor of 4. Then I > was going to use an external PLL to reduce it further. > These are just ideas... I'm trying to have an almost all digital solution. I would rather use a DDS rather than a PLL as I'm not generatin a frequency. I just want to lock on the phase. (I have the reference frequency) I'ts a kind of DLL... MarcArticle: 57870
MACIE, Check out the xilinx website I remember seeing a document for vhdl coding for xilinx FPGA. Also check out the answers database for using the automated tool functionality to script up your synthesis run. Jon vhdl_uk@yahoo.co.uk (MACEI'S) wrote in message news:<fdfcada5.0307081038.6f1c5d22@posting.google.com>... > Can anyone tell me good books or web sites related to following. > 1. MAKE file for VHDL ( XILINX) > 2. Implementation of Coding using FPGA > > Rgds > > MACIEArticle: 57871
I am doing my Ph.D research related to partial dynamic reconfiguration of FPGAs. I need a few real designs to test my work. Can someone tell me where I can get them from? The more frequently the design reconfigures a part of the FPGA, the better it will work for me. I expect the design to be in Verilog, VHDL, EDIF or NGD format. Any help in this regard will be deeply appreciated. Thanks, AmanArticle: 57872
Marc Battyani wrote: > > "Peter Alfke" <peter@xilinx.com> wrote in > > I have been playing around with the idea of a 32-bit DDS circuit at 200 > > MHz ( as a digitally controlled VCO) and I know some tricks to reduce > > the timing uncertainty from the obvious 5 ns by a factor of 4. Then I > > was going to use an external PLL to reduce it further. > > These are just ideas... > > I'm trying to have an almost all digital solution. I would rather use a DDS > rather than a PLL as I'm not generatin a frequency. > I just want to lock on the phase. (I have the reference frequency) I'ts a > kind of DLL... Sounds challenging : If I have this right You have 100MHz 'incomming' (hopefully very clean and phase stable :) You want to lock to 0.1%, (or 10ps), nominally 200MHz local Osc You can tolerate longer lock acquire times Analog Phase locked loops work because they integrate the phase-magnitude errors, - In a digital system, edge resolution of 10ps may be just possible, but I'm not sure you can get any error-proportional siganl. Go-right/Go-Left control is likely to be swamped by the phase-noise of the DDS signal..... -jgArticle: 57873
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:befj4b$94c@library2.airnews.net... <snip> > I just want to lock on the phase. (I have the reference frequency) I'ts a > kind of DLL... </snip> You could use the dynamic phase shift capabilities of the Xilinx DCMs. The slight caveat there is that the phase isn't a 360 degree "wraparound" phase, but a +/- 180 (or +/- 360?) degree shift. If you need to nudge your phase too far one direction, you'd need to have two DCMs and a real good understanding on how to get one to pick up where the other is leaving off. The update rate isn't good for matching frequencies beyond several 10s of ppm frequency error, but if your frequency is *ded* on and all you want is to get your phase to match, the DCMs let you nudge the phase forward and backward. The DCMs are absolutely superb for some things. If you're trying to "nudge" an NCO to match your phase (or perhaps a frequency offset >100ppm), you will get those system-clock-period sized phase jumps. Peter's technique would cut that system clock into quarters to cut the error by a factor of 4 but you still get the phase hit when you have to "adjust" your divide by 2.Article: 57874
H. Peter Anvin <hpa@zytor.com> wrote: > > For Ethernet cards, too; for most it's trivial to flash a new MAC > address permanently. You need hardware-specific tools to do it, but > virtually all modern Ethernet cards have the MAC address in a serial > EEPROM of some sort. all 3com cards used to come with a floppy that let you set it. so did most ne2000 clones. for same macs you could use smoething similar to nat for translation, or just a vlan switch ... but ... what would be the point? you could just write a driver that returned the mac you wanted without any hardware changes. overzealous software licencing check schemes are fundametaly the wrong way. > > You can still, obviously, not have two Ethernet cards with the same > MAC address on the same network. > > -hpa -- Sander +++ Out of cheese error +++
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