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
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:3CF3AEFA.C44CB629@mail.com... > 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, This is not true at all. For the phase accumulator, there a N settings for the increment (N is the number of bits here) for which you will get a perfect (integer) clock divider. No jitter, just harmonics. If you hit a setting very close to on of the "perfect" increments (when the increment is a power of 2), then you will get jitter with very low frequency. This is much harder to filter. For all interested, I got a pdf about theory of DDS (also spectral analysis), its a PHD work (not mine). But its all german only. -- MfG FalkArticle: 43651
Falk, Very interesting. I built and used DDFS for 12 years, and I never saw the behavior you describe, in theory or in practice. Since I have a resident German-speaker nearby (sorry, Peter!), I think both he and I would appreciate the pdf file to look at. I found it trivial to filter out the sidebands, and was not hindered at all. Austin Falk Brunner wrote: > "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > news:3CF3AEFA.C44CB629@mail.com... > > 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, > > This is not true at all. For the phase accumulator, there a N settings for > the increment (N is the number of bits here) > for which you will get a perfect (integer) clock divider. No jitter, just > harmonics. > If you hit a setting very close to on of the "perfect" increments (when the > increment is a power of 2), then you will get jitter with very low > frequency. > This is much harder to filter. > For all interested, I got a pdf about theory of DDS (also spectral > analysis), its a PHD work (not mine). > But its all german only. > > -- > MfG > FalkArticle: 43652
"Not true at all."
Could you elaborate on what's not true rather than dismissing my comments in
whole?
1) 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.
2) Using just the MSB of the phase accumulator or the MSB of the
phase-to-sine lookup, the jitter is [a maximum of] the master clock
period. [I realize it will be zero in subharmonic cases, thanks]
3) 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.
(I'm assuming you don't disagree with item 4) since you didn't quote it.)
If you have a sinusoidal DDS with a filtered DAC output there is no jitter even
for "a setting very close to on of the "perfect" increments (when the increment
is a power of 2)." You absolutely have jitter you cannot filter out if you
only use the MSB. In the case of the DDS with a filtered DAC your system noise
is limited by the phase word resolution in the phase to sine lookup, the noise
in the DAC, and the aliased frequencies that weren't filtered out in the analog
sinusoid.
My DDS background came from the development of a jitter generation test
equipment design for telecom testing with very stringent inherent jitter
requirements.
Falk Brunner wrote:
> "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag
> news:3CF3AEFA.C44CB629@mail.com...
> > 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,
>
> This is not true at all. For the phase accumulator, there a N settings for
> the increment (N is the number of bits here)
> for which you will get a perfect (integer) clock divider. No jitter, just
> harmonics.
> If you hit a setting very close to on of the "perfect" increments (when the
> increment is a power of 2), then you will get jitter with very low
> frequency.
> This is much harder to filter.
> For all interested, I got a pdf about theory of DDS (also spectral
> analysis), its a PHD work (not mine).
> But its all german only.
>
> --
> MfG
> Falk
Article: 43653Austin Lesea wrote: > > Falk, > > Very interesting. I built and used DDFS for 12 years, and I never saw the > behavior you describe, in theory or in practice. > > Since I have a resident German-speaker nearby (sorry, Peter!), I think both he > and I would appreciate the pdf file to look at. > > I found it trivial to filter out the sidebands, and was not hindered at all. > Falk Brunner wrote: <snip> > > If you hit a setting very close to on of the "perfect" increments (when the > > increment is a power of 2), then you will get jitter with very low > > frequency. > > This is much harder to filter. > > For all interested, I got a pdf about theory of DDS (also spectral > > analysis), its a PHD work (not mine). > > But its all german only. <paste> > John_H wrote: > > > > "Not true at all." > > > > Could you elaborate on what's not true rather than dismissing my comments in > > whole? Falk's comment makes sense, but the others are also corrrect in that the peak error is master-clock related. I think what Falk refers to is not the peak error, but its average freqency, and it will be very like the 'beat' patterns seen in Delta Sigma ADC's where for values very close, but not exact to a balance case, you get the lowest beat effects. The trick is to flip from time-domain thinking, to (beat) frequency domain thinking ? Depending on the design, this lowest frequency of error could be the most detrimental (eg audible), and the hardest to filter. - jgArticle: 43654
Jim, I once was very concerned about extremely low frequency sideband energy (wander). Since I could not demonstrate that it ever occurred, in practice, I was puzzled if there was a mathematical basis for the observation. I asked a PhD mathematician that worked for me to analyze the DDFS, and let me know if very low frequency sidebands were a possibility (which would make the DDFS useless for telecom sync applications). He was able to "prove" that such low frequency sidebands were not possible (with any practical power) in the application, and I was surprised by his result, even though the product had never shown any wander behavior at all (impossible to filter it out -- so I would see it). I admit that I was dealing with a specific set of frequencies, but this "proof" was a general case, and did not depend on the value of the constant. At the time, I was convinced of this "proof" (on paper). Since I have long since lost all that information, I would appreciate someone who could point me to a mathematical analysis that shows what the output spectrum looks like without having to actually measure it. The "proof" I referred to did not actually perform an FFT, but showed that the low frequencies could not exist. More useful might be a mathematical representation that one could perform an FFT on. Capturing the output of a logic simulator, and doing an FFT on that is not at all interesting, as I can do that already. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Falk, > > > > Very interesting. I built and used DDFS for 12 years, and I never saw the > > behavior you describe, in theory or in practice. > > > > Since I have a resident German-speaker nearby (sorry, Peter!), I think both he > > and I would appreciate the pdf file to look at. > > > > I found it trivial to filter out the sidebands, and was not hindered at all. > > Falk Brunner wrote: > <snip> > > > If you hit a setting very close to on of the "perfect" increments (when the > > > increment is a power of 2), then you will get jitter with very low > > > frequency. > > > This is much harder to filter. > > > For all interested, I got a pdf about theory of DDS (also spectral > > > analysis), its a PHD work (not mine). > > > But its all german only. > <paste> > > John_H wrote: > > > > > > "Not true at all." > > > > > > Could you elaborate on what's not true rather than dismissing my comments in > > > whole? > > Falk's comment makes sense, but the others are also corrrect in > that the peak error is master-clock related. > I think what Falk refers to is not the peak error, but its average > freqency, and it will be very like the 'beat' patterns seen in > Delta Sigma ADC's where for values very close, but not exact to > a balance case, you get the lowest beat effects. > > The trick is to flip from time-domain thinking, to (beat) > frequency domain thinking ? > > Depending on the design, this lowest frequency of error > could be the most detrimental (eg audible), and the hardest to filter. > > - jgArticle: 43655
As an example, a 100 MHz phase accumulator generating 10.0001 MHz will produce one cycle every 10 master clocks for much of the output pulse train. When the value below the MSbit finally accumulates enough to push the MSB over one cycle - a single instance of 9 master clocks rather than 10 - the effect is a full 10 ns shift in the "average" phase position. This event occurs at about 100 Hz with a 10 ns peak jitter value. A 32 bit phase accumulator value of 1999AA61 will add up to 10000A7CA in 10 cycles. In 9999 output cycles, the A7CA "remainder" has accumulated to a large enough value (19999AAD6) that it will move the phase accumulator value over by one master clock position, 1/10th the full phase value. The beat frequency is about 1 kHz. If I slipped a digit somewhere, my apologies. I think the math works out. I'll work the general technique for you later tonight. I don't have the original MathCad files, only the memory of my developments that I correlated between estimations and FFTs. Austin Lesea wrote: > Falk, > > Very interesting. I built and used DDFS for 12 years, and I never saw the > behavior you describe, in theory or in practice. > > Since I have a resident German-speaker nearby (sorry, Peter!), I think both he > and I would appreciate the pdf file to look at. > > I found it trivial to filter out the sidebands, and was not hindered at all. > > Austin > > Falk Brunner wrote: > > > "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > > news:3CF3AEFA.C44CB629@mail.com... > > > 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, > > > > This is not true at all. For the phase accumulator, there a N settings for > > the increment (N is the number of bits here) > > for which you will get a perfect (integer) clock divider. No jitter, just > > harmonics. > > If you hit a setting very close to on of the "perfect" increments (when the > > increment is a power of 2), then you will get jitter with very low > > frequency. > > This is much harder to filter. > > For all interested, I got a pdf about theory of DDS (also spectral > > analysis), its a PHD work (not mine). > > But its all german only. > > > > -- > > MfG > > FalkArticle: 43656
Kevin Neilson wrote: > 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. During STA of some implementations of our XCV2000E application, we had to wait for 1 hour in some cases. I think there is a strong corelation between number of failing paths and TRCE / TimingAnalyzer runtime. UtkuArticle: 43657
Ray Andraka wrote: > > 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. Excellent, thanks Ray. I actually got around the problem in this instance by using a generate loop to more effectively create my large buffer, rather than the hierarchy of schematics I originally used. Now it creates a buffer that's precisely as large as I specify (at synthesis time), and does so in very reasonable time. Cheers, JohnArticle: 43658
John, That is what I thought it would do, too. But it never did. The space bewteen sideband frequencies is independent of the constant, and depends only on the number of bits of resolution (size of the adder/register). The magnitude of the sidebands is more difficult to predict. I look forward to examining the paper. Especially since reality (lab measurement) seems to disagree with the the analysis you put forward. I have no answers, just what the spectrum analyzer and wander analysis shows. Austin John_H wrote: > As an example, a 100 MHz phase accumulator generating 10.0001 MHz will produce one > cycle every 10 master clocks for much of the output pulse train. When the value > below the MSbit finally accumulates enough to push the MSB over one cycle - a > single instance of 9 master clocks rather than 10 - the effect is a full 10 ns > shift in the "average" phase position. This event occurs at about 100 Hz with a > 10 ns peak jitter value. > > A 32 bit phase accumulator value of 1999AA61 will add up to 10000A7CA in 10 > cycles. In 9999 output cycles, the A7CA "remainder" has accumulated to a large > enough value (19999AAD6) that it will move the phase accumulator value over by one > master clock position, 1/10th the full phase value. The beat frequency is about 1 > kHz. > > If I slipped a digit somewhere, my apologies. I think the math works out. > > I'll work the general technique for you later tonight. I don't have the original > MathCad files, only the memory of my developments that I correlated between > estimations and FFTs. > > Austin Lesea wrote: > > > Falk, > > > > Very interesting. I built and used DDFS for 12 years, and I never saw the > > behavior you describe, in theory or in practice. > > > > Since I have a resident German-speaker nearby (sorry, Peter!), I think both he > > and I would appreciate the pdf file to look at. > > > > I found it trivial to filter out the sidebands, and was not hindered at all. > > > > Austin > > > > Falk Brunner wrote: > > > > > "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > > > news:3CF3AEFA.C44CB629@mail.com... > > > > 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, > > > > > > This is not true at all. For the phase accumulator, there a N settings for > > > the increment (N is the number of bits here) > > > for which you will get a perfect (integer) clock divider. No jitter, just > > > harmonics. > > > If you hit a setting very close to on of the "perfect" increments (when the > > > increment is a power of 2), then you will get jitter with very low > > > frequency. > > > This is much harder to filter. > > > For all interested, I got a pdf about theory of DDS (also spectral > > > analysis), its a PHD work (not mine). > > > But its all german only. > > > > > > -- > > > MfG > > > FalkArticle: 43659
Austin Lesea wrote: > Jim, > > I once was very concerned about extremely low frequency sideband energy (wander). > Since I could not demonstrate that it ever occurred, in practice, I was puzzled if > there was a mathematical basis for the observation. I asked a PhD mathematician > that worked for me to analyze the DDFS, and let me know if very low frequency > sidebands were a possibility (which would make the DDFS useless for telecom sync > applications). > > He was able to "prove" that such low frequency sidebands were not possible (with any > practical power) in the application, and I was surprised by his result, even though > the product had never shown any wander behavior at all (impossible to filter it out > -- so I would see it). > > I admit that I was dealing with a specific set of frequencies, but this "proof" was > a general case, and did not depend on the value of the constant. At the time, I was > convinced of this "proof" (on paper). The "specific set of frequencies" was where I was getting great results in the Fractional-N synthesis development for the Telecom apps. No low frequency artifacts given a good choice of master clock for the desired T carrier and CEPT standards. The low frequency artifacts for "close-in beat frequencies" were seen in the FFTs I took of the phase comparator signal in my MathCad simulations. Very real. The master clock was tailored to make the closest beat frequency in th 10s of kHz offset. Easy to filter out with the PLL loop filter. > Since I have long since lost all that information, I would appreciate someone who > could point me to a mathematical analysis that shows what the output spectrum looks > like without having to actually measure it. > > The "proof" I referred to did not actually perform an FFT, but showed that the low > frequencies could not exist. More useful might be a mathematical representation > that one could perform an FFT on. > > Capturing the output of a logic simulator, and doing an FFT on that is not at all > interesting, as I can do that already. > > Austin > > Jim Granville wrote: > > > Austin Lesea wrote: > > > > > > Falk, > > > > > > Very interesting. I built and used DDFS for 12 years, and I never saw the > > > behavior you describe, in theory or in practice. > > > > > > Since I have a resident German-speaker nearby (sorry, Peter!), I think both he > > > and I would appreciate the pdf file to look at. > > > > > > I found it trivial to filter out the sidebands, and was not hindered at all. > > > Falk Brunner wrote: > > <snip> > > > > If you hit a setting very close to on of the "perfect" increments (when the > > > > increment is a power of 2), then you will get jitter with very low > > > > frequency. > > > > This is much harder to filter. > > > > For all interested, I got a pdf about theory of DDS (also spectral > > > > analysis), its a PHD work (not mine). > > > > But its all german only. > > <paste> > > > John_H wrote: > > > > > > > > "Not true at all." > > > > > > > > Could you elaborate on what's not true rather than dismissing my comments in > > > > whole? > > > > Falk's comment makes sense, but the others are also corrrect in > > that the peak error is master-clock related. > > I think what Falk refers to is not the peak error, but its average > > freqency, and it will be very like the 'beat' patterns seen in > > Delta Sigma ADC's where for values very close, but not exact to > > a balance case, you get the lowest beat effects. > > > > The trick is to flip from time-domain thinking, to (beat) > > frequency domain thinking ? > > > > Depending on the design, this lowest frequency of error > > could be the most detrimental (eg audible), and the hardest to filter. > > > > - jgArticle: 43660
--------------B792C41ACC5A554B10223E58 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I know that a lot of people really like bit bashing in VHDL, however, as yet another option, there is an addressable shift register (ASR) block in the Xilinx System Generator v2.1, that may be suitable for your application. The ASR block abstracts the SRL16 primitive into an user-specified depth and width (addressable) delay line, which is quite useful (e.g. in implementing digital filters). I wouldn't recommend System Generator if all you want is the ASR block, any more than recommend a jack hammer to set a thumbtack. But if you are building an arithmetic data path and want access to the underlying Virtex primitives for speed and compactness, it's worth a look. It's straighforward to use the tool to build the dual-ported RAM based design Peter alludes to if you prefer this implementation (and there's a synch FIFO if that's what you want...). Caveat: you need a MATLAB and Simulink license (yes, for FPGA design!), but there are free eval copies of these available from The MathWorks, Inc. ( http://www.mathworks.com/web_downloads/ ) if you'd like to kick the tires. A 90-day free eval of System Generator can be downloaded here. --jim John Williams wrote: > Hi folks, > > I've created an addressable shift register, which has data_in, d_clk, > and tap_sel inputs, and a data_out output. The idea is that data are > clocked in on d_clk, and tap_sel chooses which data value (tap) is > expressed on the output. I'm using 8 of these things to create a > byte-wide structure. > > I'm creating such registers up to 500 entries long, so it obviously > takes a fair while to synthesise (targetting Virtex 300K). One of the > messages I get during synthesis is: > > WARNING:Xst:738 - 2072 flip-flops were inferred for signal > <shift_buffer>. You may be trying to describe a RAM in a way that > is incompatible with block and distributed RAM resources available on > Xilinx devices, or with a specific template that is n > ot supported. Please review the Xilinx resources documentation and the > XST user manual for coding guidelines. Taking advanta > ge of RAM resources will lead to improved device usage and reduced > synthesis time. > > I've done a web search for addressable shift register but not founding > anything specific. My design appears to work (ie behavioural sim > matches post P&R sim, and I'm happy about that), but if there's a > recommended "best practice" then I'd like to know about it. > > From this warning, can anyone suggest how I might better implement such > a beast? My code follows for those interested. It's pretty short and > self-explanatory. > > Thinking about it, I guess in a way I'm creating an addressable FIFO, > except that instead of updating the write pointer (and morhping the read > address appropriately), I'm shifting all of the data every clock tick. > Would I maybe be better rewriting this as a FIFO? > > Cheers, > > John > > -- an addressable shift register > -- data are clocked in on d_clk, and shifted right one place each time > -- tap_sel chooses which register value is expressed on data_out > -- this is a fully synchronous design, with a one clock delay between > -- d_clk and the data > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > use work.conv_types.all; > > entity shifter is > Port ( reset: in std_logic; > data_in : in std_logic_vector(7 downto 0); > d_clk : in std_logic; > tap_sel : in std_logic_vector(pix_sel_width-1 downto 0); > data_out : out std_logic_vector(7 downto 0)); > end shifter; > > architecture behavioral of shifter is > > type my_buffer_type is array (7 downto 0) of > std_logic_vector(line_len-1 downto 0); > signal shift_buffer: my_buffer_type; > > begin > > process(d_clk,reset,shift_buffer,tap_sel) > begin > if(d_clk'event and d_clk='1') then > for i in 7 downto 0 loop > shift_buffer(i) <= shift_buffer(i)(line_len-2 downto 0) & > data_in(i); > end loop; > end if; > end process; > > tap_output: > for i in 7 downto 0 generate > data_out(i) <= shift_buffer(i)(conv_integer(tap_sel)); > end generate; > > end behavioral;Article: 43661
Austin Lesea wrote: > > John, > > That is what I thought it would do, too. But it never did. The space bewteen > sideband frequencies is independent of the constant, and depends only on the number of > bits of resolution (size of the adder/register). The magnitude of the sidebands is > more difficult to predict. > > I look forward to examining the paper. Especially since reality (lab measurement) > seems to disagree with the the analysis you put forward. > > I have no answers, just what the spectrum analyzer and wander analysis shows. <paste> > Jim, > > I once was very concerned about extremely low frequency sideband energy (wander). > Since I could not demonstrate that it ever occurred, in practice, I was puzzled if > there was a mathematical basis for the observation. I asked a PhD mathematician > that worked for me to analyze the DDFS, and let me know if very low frequency > sidebands were a possibility (which would make the DDFS useless for telecom sync > applications). > > He was able to "prove" that such low frequency sidebands were not possible (with any > practical power) in the application, and I was surprised by his result, even though > the product had never shown any wander behavior at all (impossible to filter it out > -- so I would see it). The key here is 'any practical power'. In John_H's examples, the average frequency is achieved by majority /N, and some small % of /N-1. In the 10MHz + 100Hz example, just one cycle in 100,000 swallows :- a tough call for any analog instrument. These would challenge any spectrum analyser, or frequency counting wander scheme, so it is not surprising they are hard to see on the bench. A fast, reciprocal frequency counter could catch this. Consider a 1ms gate time, 1GHz T clock, it will show 10,000.0KHz 9 times, and ?? the 10th time. To yield an average of 10,000.1KHz, says this 10th reading should be 10,001.0KHz - which does not balance. Working the other way, 100Hz is +10ppm @ 10MHz, the /9 is 11.11'MHz, or +11.11'%, 111.1'ppt, 111,111ppm this needs an application rate of 1/11,111 to give nett 10ppm, ~900Hz rate. So, seems the true step rate is 900Hz, so the freq ctr numbers need a respin, but the idea is correct: A short gate time will show 2 numbers. Peter A. was working on a freq counter, & we discussed reciprocal schemes - check on his progress :-) The phase step should also be visible on the control signal of a VCXO locked to such a signal, whilst averaging instruments will tend to mask it. -jg > > Austin > > John_H wrote: > > > As an example, a 100 MHz phase accumulator generating 10.0001 MHz will produce one > > cycle every 10 master clocks for much of the output pulse train. When the value > > below the MSbit finally accumulates enough to push the MSB over one cycle - a > > single instance of 9 master clocks rather than 10 - the effect is a full 10 ns > > shift in the "average" phase position. This event occurs at about 100 Hz with a > > 10 ns peak jitter value. > > > > A 32 bit phase accumulator value of 1999AA61 will add up to 10000A7CA in 10 > > cycles. In 9999 output cycles, the A7CA "remainder" has accumulated to a large > > enough value (19999AAD6) that it will move the phase accumulator value over by one > > master clock position, 1/10th the full phase value. The beat frequency is about 1 > > kHz.Article: 43662
On Tue, 28 May 2002 11:49:43 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >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? I use Excel. Really. It isn't practical to do an FFT. There's another way, that reverses the order of the sampling and the spectrum analysis, which allows you to work out the jitter contribution of each aliased harmonic (of the original "ideal" square wave) separately. It's simple and works. The number of bits in the DDS only affects the frequency accuracy, and not the jitter. You only need to know the the clock and output frequencies to calculate the jitter. BTW, I described a method to halve the jitter of the MSB in this article: http://groups.google.com/groups?threadm=3A6B754C.C30B53EF%40agilent.com This is also implemented in my fractional-N divider generator, available here: http://fractional_divider.tripod.com/ Regards, Allan. >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, 1759 >Article: 43663
Jim Hwang wrote: > [ snip info about system generator ] Thanks Jim. With a bit of thought I was able to write a generic addressable shift register module that instantiates as many SRL16s as needed for a given address bus width, so for now my problem is solved. I'll take a look at system generator some day, it sounds interesting. Cheers, JohnArticle: 43664
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C2067E.A97F3F90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Jim,
Prior to Verilog 2001, IMO the lack of a generate statement is a big =
hole in Verilog.
Some synthesis tools such as Synplify infer the SRL16 from specific =
Verilog coding style, although there is a bug that causes Synplify to =
miss the inference if the tap delay is 2. I guess John's synthesis tool =
won't make the inference, or he has a coding style issue. In VHDL he =
could just generate the appropriate blocks of srl16's.
Regards,
"Jim Hwang" <jim.hwang@xilinx.com> wrote in message =
news:3CF41384.1E7A2681@xilinx.com...
John,
I know that a lot of people really like bit bashing in VHDL, however, =
as yet another option, there is an addressable shift register (ASR) =
block in the Xilinx System Generator v2.1, that may be suitable for your =
application. The ASR block abstracts the SRL16 primitive into an =
user-specified depth and width (addressable) delay line, which is quite =
useful (e.g. in implementing digital filters). I wouldn't recommend =
System Generator if all you want is the ASR block, any more than =
recommend a jack hammer to set a thumbtack. But if you are building an =
arithmetic data path and want access to the underlying Virtex primitives =
for speed and compactness, it's worth a look. It's straighforward to =
use the tool to build the dual-ported RAM based design Peter alludes to =
if you prefer this implementation (and there's a synch FIFO if that's =
what you want...). Caveat: you need a MATLAB and Simulink license (yes, =
for FPGA design!), but there are free eval copies of these available =
from The MathWorks, Inc. ( http://www.mathworks.com/web_downloads/ ) if =
you'd like to kick the tires. A 90-day free eval of System Generator =
can be downloaded here.
--jim
John Williams wrote:
Hi folks,
I've created an addressable shift register, which has data_in, =
d_clk,
and tap_sel inputs, and a data_out output. The idea is that data =
are
clocked in on d_clk, and tap_sel chooses which data value (tap) is
expressed on the output. I'm using 8 of these things to create a
byte-wide structure.
I'm creating such registers up to 500 entries long, so it obviously
takes a fair while to synthesise (targetting Virtex 300K). One of =
the
messages I get during synthesis is:
WARNING:Xst:738 - 2072 flip-flops were inferred for signal
<shift_buffer>. You may be trying to describe a RAM in a way that
is incompatible with block and distributed RAM resources available =
on
Xilinx devices, or with a specific template that is n
ot supported. Please review the Xilinx resources documentation and =
the
XST user manual for coding guidelines. Taking advanta
ge of RAM resources will lead to improved device usage and reduced
synthesis time.
I've done a web search for addressable shift register but not =
founding
anything specific. My design appears to work (ie behavioural sim
matches post P&R sim, and I'm happy about that), but if there's a
recommended "best practice" then I'd like to know about it.
From this warning, can anyone suggest how I might better implement =
such
a beast? My code follows for those interested. It's pretty short =
and
self-explanatory.
Thinking about it, I guess in a way I'm creating an addressable =
FIFO,
except that instead of updating the write pointer (and morhping the =
read
address appropriately), I'm shifting all of the data every clock =
tick.
Would I maybe be better rewriting this as a FIFO?
Cheers,
John
-- an addressable shift register
-- data are clocked in on d_clk, and shifted right one place each =
time
-- tap_sel chooses which register value is expressed on data_out
-- this is a fully synchronous design, with a one clock delay =
between
-- d_clk and the data
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.conv_types.all;
entity shifter is
Port ( reset: in std_logic;
data_in : in std_logic_vector(7 downto 0);
d_clk : in std_logic;
tap_sel : in std_logic_vector(pix_sel_width-1 downto 0);
data_out : out std_logic_vector(7 downto 0));
end shifter;
architecture behavioral of shifter is
type my_buffer_type is array (7 downto 0) of
std_logic_vector(line_len-1 downto 0);
signal shift_buffer: my_buffer_type;
begin
process(d_clk,reset,shift_buffer,tap_sel)
begin
if(d_clk'event and d_clk=3D'1') then
for i in 7 downto 0 loop
shift_buffer(i) <=3D shift_buffer(i)(line_len-2 downto 0) &
data_in(i);
end loop;
end if;
end process;
tap_output:
for i in 7 downto 0 generate
data_out(i) <=3D shift_buffer(i)(conv_integer(tap_sel));
end generate;
end behavioral;
Article: 43665As with Allan's post, without MathCad I also went to Excel and resurrected my "beat frequency generator" with a "closest fraction" progression. If you find the closest fractions to the phase accumulator fraction in increasing precision, you find the beat frequencies. The method I use is obvious when viewed graphically but not as easy to explain. I'll happily share the little Excel spreadsheet with anyone who wants to see it. In the example you present, 0x12AB3120BA81/0x1000000000000 is about 0.072924681. The "best fraction" sequence for this value is 1/14 3/41 7/96 94/1289 85/11697 16966/232651 119615/1640254 700724/9608873 1521063/20858000 and I really start to doubt Excel's accuracy around this point (error 7.6E-15). If I had a "real" tool I'd use it to do integer math. These values mean that you have jitter a frequencies of master clock freq / fraction denominator for each beat identified above. My memory gets a bit rough here but I believe the jitter values decreasing amplitude after the first two to an absolute value (ns) of the master clock period divided by the fraction's denominator *two* previous. This estimation is a good first order attempt but not spectrally accurate since the waveforms are sawtooths and there will be some energy in these spurs lost to higher order, lower power, lower frequency sidebands; mixing may make the values a bit less obvious when the first few fractions aren't too far from each other. Also note that these estimates are for the time domain phase error, not the clock's spectrum since - as you know - the Bessel functions start to make the jitter look uglier in that spectral domain rather than the phase jitter function's spectral domain. Summarizing, the values of jitter I'd expect to see from the fractions above for a 100 MHz master clock are 10 ns at 7.143 MHz 10 ns at 2.439 MHz 714 ps at 1.042 MHz 244 ps at 77.58 kHz 104 ps at 8549 Hz 7.8 ps at 430 Hz .85 ps at 61 Hz and smaller and lower in frequency. The low close-in jitter amplitudes for your practical example will give good results in a PLL passband but the 8.5 kHz value might be a concern depending on the application. 77 kHz should be filtered heavily and 7.8 ps is hardly worth noting. A better fraction might be 55/128 for demonstration purposes. The pattern repeats nicely every 128 master clock cycles - good clean FFT, nice graphs. The fractions are 1/2 3/7 55/128 There's an up/down/up/down going on in the phase accumulator with a swing on the order of 55 (up55/down73). There are 3 cycles (6 up/down ticks) followed by another up-tick of 55 for a 7 master clock grand total of an increase of 1. The additional up-tick can be seen as a sawtooth overlaid on the up55/down55 combination that's up55/down9/down9/down9/down9/down9/down9 which accounts for the up55/down73 asymmetry. But what about that leftover 1? When it rolls over, it drops the phase offset down by 18, the magnitude of the asymmetry just noted. 128/7 = 18 2/7. The gain of 18 from that leftover one gets dropped 18 by adding the extra two cycles of up55/down73. Total phase accumulator value at the end is zero. Lots of words that good graphs can show. I hope this starts to give insights. Looking at the graphs considering the phase accumulator value over time to be "deviation from ideal phase," the time domain deviation and phase-offset frequency domain through FFTs can be found. The same fractions are extendable beyond where FFTs become impractical. Happy Synthesis! - John_H Austin Lesea wrote: > > 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: 43666
Has anyone tried to use the data2bram software for this purpose? Regards Patrik Eriksson Martin wrote: > When you want to initialise the contents to '0' then you're fine off as this is done by default. > So you just need to initialise the RAM for functional simulation. > > But if you'd like to initialise the RAM with some values different from '0' you have to do some more work. > a) init for simulation > b) init for synthesis > see the code below: > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > --pragma translate_off > --unisim library for simulation. Here a behavioural model of the BRAM is stored. > library unisim; > use unisim.vcomponents.all; > --pragma translate_on > > entity brama is > Port ( clk, we, en : in std_logic; > di1:in std_logic_vector(3 downto 0); > addr: in std_logic_vector(9 downto 0); > addr2: in std_logic_vector(9 downto 0); > dummy:out std_logic; > data: out std_logic_vector(3 downto 0); > data2: out std_logic_vector(3 downto 0) > ); > > end brama; > > architecture Behavioral of brama is > > component RAMB4_S4 > -- synopsys translate_off > > --declaration of the RAM-contents to have some pre-laoded values. These values will be > --used for SIMULATION in all components if they are not overridden by direct values for > --the instantiated component. > generic ( > INIT_00 : bit_vector := X"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; > INIT_01 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_02 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_03 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_04 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_05 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_06 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_07 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_08 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_09 : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0a : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0b : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0c : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0d : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0e : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > INIT_0f : bit_vector := X"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"); > > -- synopsys translate_on > > port (DI : in STD_LOGIC_VECTOR (3 downto 0); > EN : in STD_logic; > WE : in STD_logic; > RST : in STD_logic; > CLK : in STD_logic; > ADDR : in STD_LOGIC_VECTOR (9 downto 0); > DO : out STD_LOGIC_VECTOR (3 downto 0)); > end component; > > attribute INIT_00: string; > attribute INIT_01: string; > attribute INIT_02: string; > attribute INIT_03: string; > attribute INIT_04: string; > attribute INIT_05: string; > attribute INIT_06: string; > attribute INIT_07: string; > attribute INIT_08: string; > attribute INIT_09: string; > attribute INIT_0a: string; > attribute INIT_0b: string; > attribute INIT_0c: string; > attribute INIT_0d: string; > attribute INIT_0e: string; > attribute INIT_0f: string; > > --pre-loaded values for BRAM myBRAM. These will be the ones used for synthesis > attribute INIT_00 of myRAMB : label is "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; > attribute INIT_01 of myRAMB : label is "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"; > attribute INIT_02 of > -- Patrik Eriksson | patrik.eriksson@netinsight.net Net Insight AB | phone: +46 8 685 04 89 Västberga Allé 9 | fax: +46 8 685 04 20 SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.netArticle: 43667
John Williams wrote: > > Hi swier, > > > I guess John's synthesis tool won't make the > > inference, or he has a coding style issue. In VHDL he could just generate the > > appropriate blocks of srl16's. > > I'm using FPGA Express under ISE4.2i. In the end I did use the generate > statement to achieve what I needed. > > Here comes a mini-rant regarding my likely coding style issue: > > Where oh where is it written down clearly and concisely the coding style > required to "hand hold" the synthesis tools? I ask this because I've > discovered from personal experience that there's a precise way a state > machine must be written to synthesise properly, a precise way to > instantiate a readback in a Xilinx device (and not the way documented > BTW), and so it goes... In altera-leonardo spectrum and xilinx webpack, the help manuals on synthesis or coding styles/templates is the best place to look. Including one extra assignment in eg. a simple counter process, can make it get implemented as random logic. By keeping each process simple to look like a basic thing such as a known counter or flip-flop template, is the best way to get the synthesizer to work efficiently. Just keep processes simple and split things into simple concurrent statements wherever suitable. > The other day I told a colleague that "synthesis is a lie", and I was > only half joking! I'm starting to feel that it's all a big kludge and > that to get the results you expect you need to conform very closely to a > particular coding style or pattern, for the synthesis tools to get it > right. You need to still think in terms of how each piece of code translates to hardware. Infact, it's better to solve your problem by imagining a hardware circuit, then writing the code for it. > That's all fine - don't get me wrong, I'm still impressed that the > transformation from a VHDL program to a circuit can be automated at all, > but I feel it's all a bit of a black art. Is this stuff written down > anywhere? I guess I'm looking for a clear description of the inference > rules. It's simple when you get used to it. The coding styles manual will make things clear by showing the recognized templates. > Does anyone share my feelings on this subject, or can the illuminati > possibly lend some of their wisdom on the topic? Think of a hardware machine first. Don't think in terms of a software solution. Unlike software, VHDL doesn't *do* what you want, it only describes the machine that does the things you want. -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / \ \/\/ \__\/ \__\/Article: 43668
Hi Russell, > > In altera-leonardo spectrum and xilinx webpack, the help manuals on > synthesis or coding styles/templates is the best place to look. I realised this about 20 ns after I pressed "send", which is why I cancelled the post! I've just printed out the XST manual and will start going through the Coding Techniques chapter. RTFM, as they say! > It's simple when you get used to it. The coding styles manual will > make things clear by showing the recognized templates. Indeed. > > Does anyone share my feelings on this subject, or can the illuminati > > possibly lend some of their wisdom on the topic? > > Think of a hardware machine first. Don't think in terms > of a software solution. Unlike software, VHDL doesn't *do* > what you want, it only describes the machine that does the > things you want. That's a good tip - I guess I'm still in some ways trying to map conventional languages (C,C++, Matlab etc) onto VHDL... ah well, experience is a great teacher. I'm getting there bit by bit, with a lot of help from this NG too I should add.. Cheers, JohnArticle: 43669
Thanks for your response but I am really afraid to use Chip Scope. The reason is the following: ILA uses the same clock as the data you want to monitor and writes them in block RAMs as I have read in the Chip Scope manual. Manual says that you can monitor signals up to 155MHz (thats the frequency of my FPGA's clock), I am afraid that if I use Chip Scope I will get many timing errors because I have already done some floorplanning to succeed no timing errors. So if I implement ILAs and get timing errors I think its difficult for me to succeed no timing errors again. "Jay" <kayrock66@yahoo.com> wrote in message news:d049f91b.0205261958.7e28e739@posting.google.com... > While there is no substitute for using simulation to find bugs, > sometimes there is no substitute for viewing the real system operate. > Get it, it rocks. You'll wonder how you lived without it. I use it > with the USB cable, and get an error every time I connect, but after > that it seems to work alright. Also, sometimes while waiting for a > trigger, it will false trigger and provide no trace data. > > p.s. I think the Altera equivalent product is included free with > Quartus 2. > > > "H.L" <alphaboran@yahoo.no-spam.com> wrote in message news:<aci7ln$1k7l$1@ulysses.noc.ntua.gr>... > > Hello all, > > I have read few weeks ago in xilinx site about the Chip Scope, seems like a > > good solution for testing a FPGA. I am thinking to purchase it but first I > > would like some comments about this tool from someone who have used it. Can > > someone help me on this? > > > > Greetings, > > HarrisArticle: 43670
This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C206FA.ED0343C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why not use a port extender? This should easily solve your problem... = I used one when i needed to extend I cable I was using to program = microcontrollers. adrianArticle: 43671
Hello there, I have a design in vhdl for a Virtex E. It is composed of 4 interfaces: A, B, C and D. I am using FPGAExpress and ISE4.2i. Timings are A BIT tight but I finally managed to have A and B working. Then I tried to change the constraints on C and D. I have re-routed the design and got C and D working perfect but A and B stopped working. I would like to have a constraint file containing the location of interface A and B to be able to re-use it and make sure that other routing would have A and B working. I know that it is possible to define a macro that would include a relative placement and to instantiate it in a top level, but it is quite long to generate in my case as the design is very big. I have played with the Floorplanner and the FPGAEditor and didn't manage to export anything interesting. Could anyone help me ? Thank for your help. Philippe.Article: 43672
Dear all, I have to make some changes in an old project created in Foundation 2.1i schematic editor and it consists of four schematic sheets (no hierachy - just flat model). A "connect-by-name" feature allows me to connect nets with the same name although they exist on different sheets. That works fine. But I can't see it working for buses. Two buses with the same name placed on two sheets are not connected! How can I solve this problem? Thanks in advance DanielArticle: 43673
Hello, ... >> I have no answers, just what the spectrum analyzer and wander analysis shows. > <paste> Yes certainly quite hard to measure, if not impossible in some cases. However I've seen this effect quite clearly while using a DDS as reference for a pll locking a millimeter wave oscillator in the 92GHz range. The dds (24bits,100MHz ck) at about 20MHz output was mutiplied by 4608 (that is 256 times in a pll to 5.12GHz and 2 times in a doubler and 9 times in the mmW PLL harmonic mixer) (the aprox 6Hz step translates to about 28Khz at the output) We could observe a wobling spanning about 30KHz mooving slowly, and dependent on the N input of the DDS. Need to mention that the phase noise of the 92GHz oscillator itself was in the range of 50KHz+ and obviously this effect had no impact on the application, even if the wobling were 10 times worst wouldn't be a problem. It was found by accident by noticing a strange up and down on the frequency counter periodically. But it was funny to confirm theory. Luis Cupido. P.S. all things were using a unique 10MHz reference, including the freq. counter.Article: 43674
Joe, I have the disks of version 5.0.1 Gerard "Joe" <xact_needed@yahoo.com> wrote in message news:d491b88d.0205261928.384e36e4@posting.google.com... > 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)
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