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 folks, Probably a simple question, any pointers appreciated. I've sucessfully created my addressable shift register using the Virtex SRL16 primitive (thanks to Nick Weaver for the tip), and have developed the computational logic that sits around it, which I'm now testing. The problem is, since I'm creating quite large registers (1Kx8) they take forever to map (approx 15-20 mins using ISE4.2i). Can I some how save the mapping/translate results so that when I make changes to a different part of the design, I don't need to remap this shift buffer, the design of which is more or less "frozen"? Obviously the place and route will change, but that's not the time-consuming part of my process. I've seen references here to things like hard macros, is that what I'm looking for? Thanks, JohnArticle: 43626
The main issue here is that a corrupt DIP4 value in the Payload control word could imply either 1. An error in the Data burst preceding the Payload Control OR 2. The channel number in the Paylod control word could be corrupt. Thus data following the Payload control would be interpreted for an incorrect channel. Any comments on this Kannan aaghate@ctd.hcltech.com (Abhishek Ghate) wrote in message news:<3f258c50.0205270734.88ae00a@posting.google.com>... > This is regarding SPI4-02.0 phase(system packet interface level4) document. > Suppose a Payload Control Word(PCW) follows an Idle Control > Word(ICW) and has a DIP4 error then should we consider the > data following it as an invalid one. > > Similarly suppose we have a PCW with > SOP and EOP information and also has a DIP4 Error, then > what is the status of the data preceding and following PCW? > Should we have to consider both of them as invalid or only data > preceding PCW as invalid? > > AbhishekArticle: 43627
Petter Gustad wrote:
>
>
>
> Is the NGD file actually encrypted? I thought it was only an
> undocumented binary format?
>
Actually, NGO is the file format (Native Design Object) in
question.
Okay, NGO is not actually encrypted (Yes, I was able to see LUT and FF
names of my design when I opened it yesterday . . . ), but the format is
proprietary.
To me, that's adequate.
> I've just used Synopsys FPGA Compiler II to create an EDIF netlist
> which was read into Quartus II (I like the TCL support). An immediate
> EQN file is created which is neither binary or encrypted, but I would
> describe it as "obfuscated".
>
Yes, I already knew that a .EQN does display the LUT equations,
but I don't believe it is a proprietary netlist format I am looking for.
> Would it be possible for you to distribute your core with the Altera
> IP core program? There must already be a mechanism to protect your
> IP.
I am not interested in joining such a distribution program.
> I know that you can download and simulate some of the IP's. Other's
> like the Altera PCI core you can even upload to a device, but it will
> only operate for two days or so. That's what I call try before you
> buy.
>
> Petter
> --
>
Yes, I am aware that Altera encrypts their IP cores.
It looks like they distribute their IP cores in .tdf files which are
normally AHDL text files, but the .tdf files of an IP core are totally
encrypted.
Does anyone know if there is such a thing as an EDIF to an encrypted TDF
converter?
Such a program will do the same thing Xilinx's EDIF2NGD does.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43628--------------22E15A5858083B502E8EB243 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks everybody for your answers, I will try to extend the JTAG cable by adding axtra drivers for the JTAG signals. My PLD (3128) is not capable of driving signals into long cables because of capacitance of these wires. With extra drivers on the JTAG signals I can achieve that. Wim > -----------------------------------Article: 43629
Hello folks, Recently I did a design (Xilinx Spartan-II) that required data to be passed from a 33MHz domain to a 425kHz domain. I did this using an Asynchronous FIFO and all was well. Now for another design: If I have 4 registers being clocked at 25MHz (with data coming in on each clock) and these 4 registers are to be multiplexed in turn into one register at 100MHz (i.e. the MUX and storage register are being clocked at 100MHz), do I need to worry about metastability? I would guess that I do, unless I used one of the CLKDLLs to divide the 100MHz clock down by 4 to 25MHz (thus making the 25MHz synchronised to the 100MHz in some way?) - would this ensure no metastabilty problems and allow me to just wire up the MUX to the 4 registers without any intervening Asynchronous FIFO or whatever? Thanks for your time, KenArticle: 43630
Does anyone can offer me a free xc2v-6000 BF957 orcad symbol !!!!!tahnk you very much!!!Article: 43631
I used this playxsvf.exe successfully the last week, but losing hours !!! For hours, I had the same problemes, with a Coolrunner. bug example: If you don't use the verify option, when you are creating the .svf, the playxsvf.exe will finish successfully, but in reality, your divice stays blank !!! The bug is becoming from the WebPack 4.1 ! The .svf is not generated correctly, and the TAP controller of the CPLD don't work correctly. Use the new webpack version 4.2. But using WEBPACK 4.2, I had a new problem in first lines of .svf about the device ID. Just try to copy the lines begining by // Loading device with 'idcode' intruction. SIR ... SDR ... in your last .svf generated with webpack 4.1. and replace it in your new .svf If you have other problems, maybe I can help you NB: use the verbose option of the playxsvf.exe, it's powerful Laurent amontec Hanks Lee wrote: > Hi Experts, > > I'm new to CPLD in-system-programming. We use the method metioned in > Xilinx App-note xapp058. We could successfully covert the svf code to > xsvf code, however we could not program the device with their > playxsvf.exe. An error was shown at the end of programming. We can Get > Device ID, Erase, Blank Check the device with playxsvf.exe. Does > anybody encounter this kind of problem before? Did we do something > wrong? > > Thanks, > > Hanks >Article: 43632
My VHDL can be successfully simulated by ActiveHDL, and can be synthesised by Mentor Leonardo. But when using Altera MaxPlus. I get the following message: Error: Unknown problem in e:\traf\traf.vhd (%DLS-F-NULLArg, Null Node argument to Kind.) What's wrong? I can't even guess from this garbage string!! Can anyone give me some strange solution to this problem. My teacher force me to use MaxPlus II. I have no choice. Thanks.Article: 43633
"Robert O. Taniman" <bobchen74@yahoo.com> wrote in message news:abjqkg$ck0$1@dinkel.civ.utwente.nl Hi Robert, A second thought.... Have you got some sort of timing constraint on the synthesis in the UCF file. If you're new to FPGAs its possible to overlook this requirement. Use something like... ####TIMING CONSTRAINTS ##### NET "Clk" TNM_NET = "Clk"; TIMESPEC "TS_Clk" = PERIOD "Clk" 50 MHz HIGH 50 %; ############################ Naturally there are a mass of more complicated ways to put timing constraints on the synthesis. These can be found in the literature. If you are nearly there with your current timing then simply do multiple Place&Route with the constraints until the chip passes. If not follow the more radical Xilinx tips, previously referenced, to speed it up, the biggest improvement being "reduce the number of layers of logic". Any serious design needs to have all timing problems resolved. That is, if it's only for your own use as an amusement then you could live with the odd glitch, otherwise I'd fix it. Best regards Phil -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 43634
The MSB is a squarewave sampled by the master clock frequency, so if the frequency setting
is not a submultiple of the master clock frequency you get error at the transitions that
translates into jitter. Likewise, multiple bits out of the DDS are a phase ramp
(sawtooth) sampled at the master clock frequency.
Marty wrote:
> My coment is based on info from the AD 9854 data sheet. There is a
> short discussion of jitter from DDSs and PLLs. The PLL contributes
> some jitter to the final output, but is less than the jitter of a PLL
> by itself.
>
> I seem to recall an article from about 10 or more years ago that
> stated that no output from the phase accumulator would provide a good
> square wave. That is probably why AD connects the comparator to the
> filtered sinewave output of the DDS.
>
> Marty
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3CEE572B.D07F18FC@andraka.com>...
> > Depends on the number of bits you use from the DDS. If you use the DDS to create
> > a sinewave, convert it to analog, filter it then use a comparator it can be better
> > than a PLL. If you just take the MSB to create a square wave, then your jitter is
> > up to a cycle of your master clock.
> >
> > Marty wrote:
> >
> > > Jitter from a DDS is lower than a PLL!
> > >
> > > Marty
> > >
> >
> > --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
--
--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: 43635
I'm sure he would if he had block RAMs. Unfortunately he is using is an XCS30XL (based on the 4K
architecture), which does not have any Block RAMs. Floorplanning and reducing the number of levels of
logic will improve PAR performance considerably. PAR slows down not so much due to design complexity, but
more due to time constraints that are a challenge to meet for the number of logic levels in the design.
As an experiment, relax your time constraints by, say, half of the current design frequency and note the
drastic reduction in PAR time (it is not a linear curve, so YMMV).
Jay wrote:
> The P&R times seem to go up exponentially after you cross a certain
> design density threshold. Our experence has been that our time was
> better spent doing logic reduction to get back behind knee in the
> curve instead of twiddling the control knobs or building faster
> machines.
>
> Can you convert any of those distributed rams to block ram?
>
> Regards
>
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<acdjad$otrng$1@ID-84877.news.dfncis.de>...
> > Hello,
> >
> > we have a design with a XCS30XL, which is utilized to 96%.
> > Bad thing is, P&R takes about 30!!! minutes on a Athlon 500. The design uses
> > a lot of TBUFs and DP-RAMS.
> > Are there some tricks to speed up things? Some floorplanning? Timing
> > constraints?
--
--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: 43636
Joe,
As I recall, the 2K was phased out of the tools before XACT6. Perhaps my
memory is not correct though. I do have the old disks around here
somewhere, although there is no guarantee mine are in any better shape
than yours.
Joe wrote:
> I'm desperately seeking a copy of the old Xilinx XACT Design Editor (I
> just need the XACT.EXE application and the 2018 data files). Version
> 5.1, 5.2, 5.2.1, or 6.0, which can still edit 2018 LCA files would be
> fantastic! I need one of these versions since I have to make a minor
> update to an old 2018 LCA design.
>
> I've got the dongle, but the floppies have become damaged and
> unreadable over the years. Please, if anyone can help please contact
> me at xact_needed@yahoo.com.
>
> Any help much appreciated,
> Joe.
>
> P.S> Only using yahoo to prevent spam to my real email address
> (already had 4 spams at the yahoo one)
--
--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: 43637
You can avoid resynthesizing by separating that portion out and synthesizing
it separately (be sure turn turn off I/O insertion), then instantiating it
in your top level design as a black box (ie, no code under it). Then when
you run the xilinx translate, make sure both the top level design and your
sub-design's edif files are in the same directory or that the sub-level's
design directory is in the macro search path.
John Williams wrote:
> Hi folks,
>
> Probably a simple question, any pointers appreciated.
>
> I've sucessfully created my addressable shift register using the Virtex
> SRL16 primitive (thanks to Nick Weaver for the tip), and have developed
> the computational logic that sits around it, which I'm now testing. The
> problem is, since I'm creating quite large registers (1Kx8) they take
> forever to map (approx 15-20 mins using ISE4.2i).
>
> Can I some how save the mapping/translate results so that when I make
> changes to a different part of the design, I don't need to remap this
> shift buffer, the design of which is more or less "frozen"? Obviously
> the place and route will change, but that's not the time-consuming part
> of my process. I've seen references here to things like hard macros, is
> that what I'm looking for?
>
> Thanks,
>
> John
--
--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: 43638--------------0CC4E19F13C2EF54580B1E46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick, The spice models are encrypted because they contain the foundry's technology files (highly proprietary). A smart technologist can figure out exactly how a foundry is building their transistors from examining the details of the technology models. We have encrypted spice models only for customers who sign NDAs, and who have the latest Avant! Hspice. The IBIS models are developed from these spice models. The latest version of Hspice accepts IBIS models, so the need for spice models has actually diminished. Virtex II ushered in a new age of high speed designs, and as such, an effort was made to support such designs with better modeling resources. Austin rickman wrote: > Checking the Xilinx web site it looks like you can download IBIS models > for various devices including the Spartan IIe devices. However, these > files do you no good if you don't have IBIS simulator which seem to cost > even more than a logic or HDL simulator. > > I also found that there are spice models available for the VirtexII > parts. But not for any other devices. Since Spice is much more > available, any idea why the Spice models are not available for parts > other than the VII? > > -- > > 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: 43639
No reason you can't put the function of the 'specialized chip' such as an FFT
into the FPGA for the applications that need it. Even for a bit serial
implementation, you wind up with a potential for a significant processing
advantage over doing it in the DSP microprocessor. We offer 8 and 16 point FFT
kernel cores for Xilinx Virtex families that run at up to 250 MS/sec, for
example.
Manfred Muecke wrote:
> differ in the final algorithm to be implemented. I think for using
> specialized chips (such as for FFT) the needed MIPS are too low and
> the required diversity is to high. DSP+FPGA as separate chips would be
> a solution, but a SOPC would be a better one (interfaces, board,
> flexibility).
>
> \Manfred
--
--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: 43640wangyin101@hotmail.com (yin wang) writes: > My VHDL can be successfully simulated by ActiveHDL, and can be > synthesised by Mentor Leonardo. But when using Altera MaxPlus. I get > the following message: > > Error: Unknown problem in e:\traf\traf.vhd (%DLS-F-NULLArg, Null Node > argument to Kind.) > If you have synthesised it in Leonardo, you shouldn't need to use MP2 on the VHDL files, which the message above seems to imply... > What's wrong? I can't even guess from this garbage string!! I don't know what the message means, but I would think that you are going about the process wrong... what you need to do is take the EDIF (traf.edf maybe?) output of Leonardo into MP2 and run Compile on that. This should run the fitter operation to fit whatever Leonardo has synthesised into whatever device you choose. Does that help? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 43641
I hope you all don't mind but to try to get more hits I am posting this on two forums: I have several designs for which I need to view all paths that fail my timing constraints. I have attempted this using the Timing Analyzer provided with Foundations 3.1 as well as ISE 4.1. With both versions of the software I have the following problem: The default number of failed constraints reported by the timing software is three paths. However, there are many more paths that are failing. I have incrementally bumped up the number of failing paths to be reported each time notcing a longer time to return results. Eventually, the number of paths I request appears to lock the system. I have tried using two different computers... the older of the two is a PII 400 with 512 MB of RAM and a couple GB of free hard drive space, the other system is a P3 700 with ~750 MB of RAM and several GB of free hard drive space. If anyone has seen this problem before or been able to rectify it I would appreciate any input. ThxArticle: 43642
I thought the classic DDS was more than just a Phase Accumulator and included the (co)sine lookup tables for driving a DAC to get a true sinusoid. Using just the MSB of the phase accumulator or the MSB of the phase-to-sine lookup, the jitter is the master clock period. If you actually use a DAC to generate the sinusoid - not the phase ramp - then you just need to do a good job of filtering so the aliased sinusoids don't get into your baseband signal, creating jitter. The higher the clock rate versus the baseband frequency, the easier the analog filter design. Ray Andraka wrote: > The MSB is a squarewave sampled by the master clock frequency, so if the frequency setting > is not a submultiple of the master clock frequency you get error at the transitions that > translates into jitter. Likewise, multiple bits out of the DDS are a phase ramp > (sawtooth) sampled at the master clock frequency. > > Marty wrote: > > > My coment is based on info from the AD 9854 data sheet. There is a > > short discussion of jitter from DDSs and PLLs. The PLL contributes > > some jitter to the final output, but is less than the jitter of a PLL > > by itself. > > > > I seem to recall an article from about 10 or more years ago that > > stated that no output from the phase accumulator would provide a good > > square wave. That is probably why AD connects the comparator to the > > filtered sinewave output of the DDS. > > > > Marty > > > > Ray Andraka <ray@andraka.com> wrote in message news:<3CEE572B.D07F18FC@andraka.com>... > > > Depends on the number of bits you use from the DDS. If you use the DDS to create > > > a sinewave, convert it to analog, filter it then use a comparator it can be better > > > than a PLL. If you just take the MSB to create a square wave, then your jitter is > > > up to a cycle of your master clock. > > > > > > Marty wrote: > > > > > > > Jitter from a DDS is lower than a PLL! > > > > > > > > Marty > > > > > > > > > > --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 > > -- > --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, 1759Article: 43643
John, If the clock frequency is high enough, and the jitter is tolerable from the 1/clock, then you may use the MSB without having to add all of that extra circuitry. If you look at the spectrum of the MSB, you will see where the sidebands are, and then you may determine if that will cause a problem if you use it "raw." Austin John_H wrote: > I thought the classic DDS was more than just a Phase Accumulator and included the (co)sine > lookup tables for driving a DAC to get a true sinusoid. Using just the MSB of the phase > accumulator or the MSB of the phase-to-sine lookup, the jitter is the master clock period. If > you actually use a DAC to generate the sinusoid - not the phase ramp - then you just need to > do a good job of filtering so the aliased sinusoids don't get into your baseband signal, > creating jitter. The higher the clock rate versus the baseband frequency, the easier the > analog filter design. > > Ray Andraka wrote: > > > The MSB is a squarewave sampled by the master clock frequency, so if the frequency setting > > is not a submultiple of the master clock frequency you get error at the transitions that > > translates into jitter. Likewise, multiple bits out of the DDS are a phase ramp > > (sawtooth) sampled at the master clock frequency. > > > > Marty wrote: > > > > > My coment is based on info from the AD 9854 data sheet. There is a > > > short discussion of jitter from DDSs and PLLs. The PLL contributes > > > some jitter to the final output, but is less than the jitter of a PLL > > > by itself. > > > > > > I seem to recall an article from about 10 or more years ago that > > > stated that no output from the phase accumulator would provide a good > > > square wave. That is probably why AD connects the comparator to the > > > filtered sinewave output of the DDS. > > > > > > Marty > > > > > > Ray Andraka <ray@andraka.com> wrote in message news:<3CEE572B.D07F18FC@andraka.com>... > > > > Depends on the number of bits you use from the DDS. If you use the DDS to create > > > > a sinewave, convert it to analog, filter it then use a comparator it can be better > > > > than a PLL. If you just take the MSB to create a square wave, then your jitter is > > > > up to a cycle of your master clock. > > > > > > > > Marty wrote: > > > > > > > > > Jitter from a DDS is lower than a PLL! > > > > > > > > > > Marty > > > > > > > > > > > > > --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 > > > > -- > > --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, 1759Article: 43644
hi... I have a problem... if I use a delay in fpga... How can I do? Have any delay cell builtin library? thank you...Article: 43645
I think the secret is to wait longer. Timing Analyzer appears dead while it's working, and I think it might even appear under the task manager as "not responding", but I think the results to finally show up if you wait an eon or two. This doesn't seem to make sense to me though. It would seem that it would have to find all the failing paths in order to give you the three slowest. Finding more failing paths doesn't seem like it should take more time. <ae> wrote in message news:ee76e68.-1@WebX.sUN8CHnE... > I hope you all don't mind but to try to get more hits I am posting this on two forums: > > I have several designs for which I need to view all paths that fail my timing constraints. I have attempted this using the Timing Analyzer provided with Foundations 3.1 as well as ISE 4.1. With both versions of the software I have the following problem: > > The default number of failed constraints reported by the timing software is three paths. However, there are many more paths that are failing. I have incrementally bumped up the number of failing paths to be reported each time notcing a longer time to return results. Eventually, the number of paths I request appears to lock the system. > > I have tried using two different computers... the older of the two is a PII 400 with 512 MB of RAM and a couple GB of free hard drive space, the other system is a P3 700 with ~750 MB of RAM and several GB of free hard drive space. > > If anyone has seen this problem before or been able to rectify it I would appreciate any input. > > ThxArticle: 43646
Absolutely. The (worst) sidebands can even be determined mathematically, no spectrum analysis required. I just learned "DDS" with devices that produced sine waves and texts that spoke of the system level implementation with DACs intact. The "phase accumulator only" approach isn't pure DDS in my opinion from that background. The higher the master clock, the smaller the jitter. So true. Austin Lesea wrote: > John, > > If the clock frequency is high enough, and the jitter is tolerable from the 1/clock, then you may > use the MSB without having to add all of that extra circuitry. > > If you look at the spectrum of the MSB, you will see where the sidebands are, and then you may > determine if that will cause a problem if you use it "raw." > > Austin > > John_H wrote: > > > I thought the classic DDS was more than just a Phase Accumulator and included the (co)sine > > lookup tables for driving a DAC to get a true sinusoid. Using just the MSB of the phase > > accumulator or the MSB of the phase-to-sine lookup, the jitter is the master clock period. If > > you actually use a DAC to generate the sinusoid - not the phase ramp - then you just need to > > do a good job of filtering so the aliased sinusoids don't get into your baseband signal, > > creating jitter. The higher the clock rate versus the baseband frequency, the easier the > > analog filter design. > > > > Ray Andraka wrote: > > > > > The MSB is a squarewave sampled by the master clock frequency, so if the frequency setting > > > is not a submultiple of the master clock frequency you get error at the transitions that > > > translates into jitter. Likewise, multiple bits out of the DDS are a phase ramp > > > (sawtooth) sampled at the master clock frequency. > > > > > > Marty wrote: > > > > > > > My coment is based on info from the AD 9854 data sheet. There is a > > > > short discussion of jitter from DDSs and PLLs. The PLL contributes > > > > some jitter to the final output, but is less than the jitter of a PLL > > > > by itself. > > > > > > > > I seem to recall an article from about 10 or more years ago that > > > > stated that no output from the phase accumulator would provide a good > > > > square wave. That is probably why AD connects the comparator to the > > > > filtered sinewave output of the DDS. > > > > > > > > Marty > > > > > > > > Ray Andraka <ray@andraka.com> wrote in message news:<3CEE572B.D07F18FC@andraka.com>... > > > > > Depends on the number of bits you use from the DDS. If you use the DDS to create > > > > > a sinewave, convert it to analog, filter it then use a comparator it can be better > > > > > than a PLL. If you just take the MSB to create a square wave, then your jitter is > > > > > up to a cycle of your master clock. > > > > > > > > > > Marty wrote: > > > > > > > > > > > Jitter from a DDS is lower than a PLL! > > > > > > > > > > > > Marty > > > > > > > > > > > > > > > > --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 > > > > > > -- > > > --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, 1759Article: 43647
John, I was never able to find a closed form mathematical analysis (method) for doing an FFT on the MSB. If you had a 48 bit DDFS, and set it to some odd value, like 12AB3120BA81 hex? Or even a 12 bit DDFS.....? How do you do it? Austin John_H wrote: > Absolutely. The (worst) sidebands can even be determined mathematically, no spectrum analysis > required. > > I just learned "DDS" with devices that produced sine waves and texts that spoke of the system level > implementation with DACs intact. The "phase accumulator only" approach isn't pure DDS in my opinion > from that background. > > The higher the master clock, the smaller the jitter. So true. > > Austin Lesea wrote: > > > John, > > > > If the clock frequency is high enough, and the jitter is tolerable from the 1/clock, then you may > > use the MSB without having to add all of that extra circuitry. > > > > If you look at the spectrum of the MSB, you will see where the sidebands are, and then you may > > determine if that will cause a problem if you use it "raw." > > > > Austin > > > > John_H wrote: > > > > > I thought the classic DDS was more than just a Phase Accumulator and included the (co)sine > > > lookup tables for driving a DAC to get a true sinusoid. Using just the MSB of the phase > > > accumulator or the MSB of the phase-to-sine lookup, the jitter is the master clock period. If > > > you actually use a DAC to generate the sinusoid - not the phase ramp - then you just need to > > > do a good job of filtering so the aliased sinusoids don't get into your baseband signal, > > > creating jitter. The higher the clock rate versus the baseband frequency, the easier the > > > analog filter design. > > > > > > Ray Andraka wrote: > > > > > > > The MSB is a squarewave sampled by the master clock frequency, so if the frequency setting > > > > is not a submultiple of the master clock frequency you get error at the transitions that > > > > translates into jitter. Likewise, multiple bits out of the DDS are a phase ramp > > > > (sawtooth) sampled at the master clock frequency. > > > > > > > > Marty wrote: > > > > > > > > > My coment is based on info from the AD 9854 data sheet. There is a > > > > > short discussion of jitter from DDSs and PLLs. The PLL contributes > > > > > some jitter to the final output, but is less than the jitter of a PLL > > > > > by itself. > > > > > > > > > > I seem to recall an article from about 10 or more years ago that > > > > > stated that no output from the phase accumulator would provide a good > > > > > square wave. That is probably why AD connects the comparator to the > > > > > filtered sinewave output of the DDS. > > > > > > > > > > Marty > > > > > > > > > > Ray Andraka <ray@andraka.com> wrote in message news:<3CEE572B.D07F18FC@andraka.com>... > > > > > > Depends on the number of bits you use from the DDS. If you use the DDS to create > > > > > > a sinewave, convert it to analog, filter it then use a comparator it can be better > > > > > > than a PLL. If you just take the MSB to create a square wave, then your jitter is > > > > > > up to a cycle of your master clock. > > > > > > > > > > > > Marty wrote: > > > > > > > > > > > > > Jitter from a DDS is lower than a PLL! > > > > > > > > > > > > > > Marty > > > > > > > > > > > > > > > > > > > --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 > > > > > > > > -- > > > > --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, 1759Article: 43648
Hello all, I use a CLKDLLHF in a Virtex-E FPGA. The CLK0 output pin goes to a BUFG and the buffer's output is used as my internal clock and as the feedback of the DLL. Also I make use of the CLKDV clock after I pass it from a BUFG. I want the first clock (the identical of the DLL's input) to be an output, I add an OBUF and I see in the FPGA editor that all connections are OK but in the timing simulation the output signal is denoted as X , I think the above connections are valid so why is that happening? I really want this clock to be the output, to be exact I need a clock signal with the same period with the internal.. I dont care about the skew of this clock only for the period. Best Regards, HarrisArticle: 43649
I am working on a design that involves three XC4062XL chips, for purposes here I will refer to them as 'Chip 1', 'Chip 2', and 'Chip 3'. This is the order in which they are connected, that is Chip 1 is first in the chain, Chip 2 second and Chip 3 third. I was passed down this design and at the time was not familiar with the 'Startup Pin synchronization' option in the FPGA implementation configuration options. For this design, it was necessary to enable this option for both Chip 2 and Chip 3 to allow them to finish configuring on startup. While the project has been successfully compiled and loads active, what baffles me is this: Originally to create FPGA HEX files that would load completely in the system I was had to make the Bitgen process of implementation use the 'old' PCF file that was provided to me instead of the PCF file generated during my own recompile for both Chip 1 and Chip 2. In hindsight, I checked the Chip 1 and Chip 2 PCF files for any kind of constraint that would have indicated to me that the Synchronize Startup Pin should have been enabled... but I could find no such information of constraint setting in the 'old' PCF files, nor my new PCF from the working compile for which I set this option. Any ideas on where the Synchronize Startup Pin data is stored? How could it be that if this was the only setting I was missing and it is not in the PCF file yet when I swapped the 'old' PCF file in the compile was fine?
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