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
A very good source for students is: http://www.digilentinc.com/ If you choose Xilinx Webpack for Linux (free download), and then you can buy the small Spartan 3E board: http://www.xilinx.com/tools/webpack.htm (download webpack) and http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,721&Prod=BASYS2 (3E pcb) which is commonly used at many universities and schools (so there is a lot of stuff on the web sites of universities and schools). Programming tools (the JTAG programming cable) used with Linux are always a bit tough to get to work (just read the posts on the subject) as support of USB isn't as trivial as it is with 'Windoze.' AustinArticle: 143726
On Oct 20, 4:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > (snip) > > >> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > >> ESA/370, ESA/390, and z/Architecture. > > (snip) > > >> Even more, z/ can operate on code using 64, 31, or 24 bit addressing > >> as appropriate, and instructions change as the addressing mode changes= . > > How are the bits in the address bus numbered? =A0I would find it > > extremely confusing to deal with an address where the lsb is numbered > > N where N varies depending on the size of the address range. > > If by 'address bus' you mean the physical hardware, that is a separate > question from the architecture. =A0 > > Otherwise, the numbering changed in z/, but is internally consistent. > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > for example, and the address as stored in the PSW is bits 40 to 63. > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > That only comes up in reading the descriptions of the instructions. > > In actual coding, (software) one can write a loop in whichever > way one wants. =A0The hardware will execute it independent of the > thought process of the programmer. > > It never confused me. > > -- glen This discussion has been about the hardware from the first post. I don't care much what people do in their heads with a programming language. We were talking about connecting different buses in the hardware. One was numbered 15 downto 0, IIRC and the other was 0 to 31. If I understood the OP's problem, he was connecting the two buses incorrectly. His real problem was that he was thinking his problem was something to do with how the language interprets negative numbers in the various data types. In reality, I think he was confused about how to connect a 16 bit bus to a 32 bit bus and preserve sign. We haven't heard back from him, so I'm not sure how he fixed it. RickArticle: 143727
On Oct 21, 7:16=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > glen herrmannsfeldt wrote: > > rickman <gnu...@gmail.com> wrote: > >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > (snip) > > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > >>> ESA/370, ESA/390, and z/Architecture. > > > (snip) > >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressing > >>> as appropriate, and instructions change as the addressing mode change= s. > > >> How are the bits in the address bus numbered? =A0I would find it > >> extremely confusing to deal with an address where the lsb is numbered > >> N where N varies depending on the size of the address range. > > > If by 'address bus' you mean the physical hardware, that is a separate > > question from the architecture. =A0 > > > Otherwise, the numbering changed in z/, but is internally consistent. > > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > > for example, and the address as stored in the PSW is bits 40 to 63. > > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > > That only comes up in reading the descriptions of the instructions. > > This is "nice and consistent" ?? =A0The bit numbering for the same addres= s > varies according to the size of the register, and the significance of a > bit of a given number varies according to the register, the bit width, > and the machine variant. =A0I'll agree that much of this is hidden from > the programmer, and that you can get used to it, but it's still > inconsistent and it's still messy. > > I've dealt with this in the context of PPC microcontrollers - it is a > big pain in the neck, and it's very easy to get wrong. =A0Virtually > everything else in the electronics world numbers bits consistently from > 0 for the LSB - the PPC sticks out like a sore thumb and means that you > need to invert the bus numbering when connecting it to external memory. > =A0 Internally, when programming these things, you get the joys of > figuring out which bits are which in the documentation, and how that > corresponds to reality. =A0The manual might tell you a hardware register > is theoretically 64 bits, with the field you are interested in from bits > 56 to 59. =A0However, perhaps only the lower 32 bits of the register are > implemented, so the actual bits are 24 to 27. =A0You then have to > translate this into sensible bit numbers, 4 to 7, so that you can use > them in software. =A0All in all, reverse bit numbering is a big waste of > time and effort, and a big cause of mistakes. > > And for PPC devices (at least, those I have looked at) with 64-bit > architectures, the external databus is numbered consistently with the > 32-bit devices. =A0Thus the LSB of the data and address buses stays at 31= . > =A0 So the upper half of the databus runs from D-1 to D-32 as the MSB. > Internally, of course, the registers are numbered with bit 0 as the MSB > and bit 63 as the LSB. =A0Thus bit 0 in a data register corresponds to pi= n > D-32 on the PPC, matching net D63 on any external memory bus. > > Yes, "nice and consistent" is just the phrase... > > > In actual coding, (software) one can write a loop in whichever > > way one wants. =A0The hardware will execute it independent of the > > thought process of the programmer. > > I was under the impression that programming was about getting the > hardware to execute /dependent/ on the thoughts of the programmer! > > > It never confused me. > > I've not use the Power architecture, only some PowerPC devices, but I > have to admit it has confused me on occasion, and irritated and > frustrated me more often than that. > > mvh., > > David I didn't realize that the microBlaze used a little endian bus numbering convention. That is a good reason to avoid it... a small reason, but a reason nonetheless. Actually, the main reason to avoid proprietary IP like microBlaze is the fact that it is proprietary. I prefer to use one of the available CPUs that are open source and can be ported to chips from any vendor or even an ASIC. RickArticle: 143728
On 22 =D0=BE=D0=BA=D1=82, 20:27, doug <x...@xx.com> wrote: > Alex wrote: > > On 22 =C3=8F=C3=8B=C3=94, 18:19, doug <x...@xx.com> wrote: > Jitter and stability are two different things. Jitter makes noise on > the signal. But, generating a signal in an FPGA is not going to be > quiet anyway as it is not meant for clean signals. Even running a > clock just thru the FPGA will make it much too noisy for certain > communications work. We found this out the hard way years ago. Well, it's helpful. I am interested - what are other boards available for a student which could be used for cleaner (than in FPGA-based) signal generation? For example, would SHARC signal processor boards allow cleaner signal generation than Xilinx FPGA-based boards?Article: 143729
On 22 =CF=CB=D4, 20:26, austin <aus...@xilinx.com> wrote: > DLL jitter, > > Is +/- ~ 50 ps about the input frequency. > > It has no effect on frequency, whatsoever. > > What goes in to a DLL (DCM), comes out. =9AIt is a delay line, with > taps. > > What goes in MUST come out (at exactly the same frequency, with a > small amount of added jitter). > > The DFS (frequency synthesizer) part of the DCM has a bit more jitter > (nominally 3 times the tap size, + and -), its output frequency is > also exact (by the M/D ratio specified). > > Austin Okay. I am just a beginner and was easily confused by Ben Jones' comment earlier in this topic when he wrote that "But I would be surprised if you ever needed to worry about 50ppm frequency drift in an FPGA application. The DLL jitter will be an order of magnitude greater than that... "Article: 143730
Thanks for your comments. I guess I don't like Xilinx's GPIO IP very much because they take up a lot of slices to implement (as far as GPIO goes). My application requires a few GPIO IPs along with other IPs, and I find that Im running out of room on my Spartan 3AN device. Im new at this, so im sure theres ways around it. But for a newbee like me, I wish there were simple GPIO IPs that doesn't take a lot of logic to implement. I guess this is where custom IP comes in handy. Best Regards --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 143731
On 22 =D0=BE=D0=BA=D1=82, 23:23, doug <x...@xx.com> wrote: > Alex wrote: > > On 22 =D0=BE=D0=BA=D1=82, 20:27, doug <x...@xx.com> wrote: > > >>Alex wrote: > > >>>On 22 =C3=8F=C3=8B=C3=94, 18:19, doug <x...@xx.com> wrote: > > >>Jitter and stability are two different things. Jitter makes noise on > >>the signal. But, generating a signal in an FPGA is not going to be > >>quiet anyway as it is not meant for clean signals. Even running a > >>clock just thru the FPGA will make it much too noisy for certain > >>communications work. We found this out the hard way years ago. > > > Well, it's helpful. > > > I am interested - what are other boards available for a student which > > could be used for cleaner (than in FPGA-based) signal generation? > > For example, would SHARC signal processor boards allow cleaner signal > > generation than Xilinx FPGA-based boards? > > The issue on any of the complex digital circuits is that the > transitions of the incoming clock get modulated by the digital > noise from the other circuits. This is of very little importance > for digital work other than introducing some jitter. It is > very important for generating clean analog waveforms. If you > want a relatively clean programmable oscillator look at the > Analog Devices DDS line. Their parts work very well and > the programming is pretty easy. Thanks for advice!Article: 143732
How does XilFATFS support the above function?Article: 143733
Alex wrote: > On 22 окт, 20:27, doug <x...@xx.com> wrote: > >>Alex wrote: >> >>>On 22 ÏËÔ, 18:19, doug <x...@xx.com> wrote: > > >>Jitter and stability are two different things. Jitter makes noise on >>the signal. But, generating a signal in an FPGA is not going to be >>quiet anyway as it is not meant for clean signals. Even running a >>clock just thru the FPGA will make it much too noisy for certain >>communications work. We found this out the hard way years ago. > > > Well, it's helpful. > > I am interested - what are other boards available for a student which > could be used for cleaner (than in FPGA-based) signal generation? > For example, would SHARC signal processor boards allow cleaner signal > generation than Xilinx FPGA-based boards? > The issue on any of the complex digital circuits is that the transitions of the incoming clock get modulated by the digital noise from the other circuits. This is of very little importance for digital work other than introducing some jitter. It is very important for generating clean analog waveforms. If you want a relatively clean programmable oscillator look at the Analog Devices DDS line. Their parts work very well and the programming is pretty easy.Article: 143734
On Oct 23, 4:00=A0am, Alex <vict...@gmail.com> wrote: > Hence, I am interested - if I will use a clock with, for example, > 0.001ppm time stability then would it be possible to generate few MHz > frequency in 0.1Hz steps? Would DLL jitter prevent this or not? (I am > going to use Spartan3E 1600E Microblaze Development Kit). You should explain what frequencies you want, as talking in ppm on one hand, and 0.1Hz on the other does not help. Also, is absolute precision important, or do you simply want a 0.1Hz step size 50ppm numbers are the absolute error, and not the stability. Stability is usually a LOT better than that, and then there is jitter to consider, but a good Xtal will be a few ps, or just under 1 ps You are also better to think in the time-domain, rather than frequency. So, if we take your "generate few MHz frequency in 0.1Hz steps" and reality check 1000000Hz with 1000000.1Hz, the actual period difference you are asking for, is 10e-14, or 100 femto seconds (if you really want every cycle to be 1000000.1 Hz). Now, compare that with the Austin's DLL jitter of 50ps, or even a good Xtal Osc of 2ps, and you can see the problem. So, having decided every-cycle precision is not practical, you hve to decide over what time you need this 0.1Hz. Suppose you need it over 100ms, then you can generate 99,999 cycles of 1.00us, and one cycle ofArticle: 143735
On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote: > So, having decided every-cycle precision is not practical, you have to > decide over what time you need this 0.1Hz ? > Suppose you need it over 100ms, then you can generate 99,999 cycles of > 1.00us, and one cycle of ( oops, Hit the wrong button...) Finishing that example: in a pure digital domain For a 100ms time average, of your 1000000.1 Hz, we generate 99,999 cycles of 1,00us and one cycle 10ns less Frequency is then Cycles.Time =3D 100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001 So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of greater than 100ms, with a 10ns timebase. That certainly is FPGA doable. Over 10.00 seconds, you will get 10000001 edges (etc) -jgArticle: 143736
On Oct 22, 10:14=A0pm, "hvo" <hai...@synrad.com> wrote: > Thanks for your comments. > > I guess I don't like Xilinx's GPIO IP very much because they take up a lo= t > of slices to implement (as far as GPIO goes). =A0My application requires = a > few GPIO IPs along with other IPs, and I find that Im running out of room > on my Spartan 3AN device. =A0 > > Im new at this, so im sure theres ways around it. But for a newbee like m= e, > I wish there were simple GPIO IPs that doesn't take a lot of logic to > implement. > > I guess this is where custom IP comes in handy. > > Best Regards > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com the smalles and easiest is to use FSL bus it allows very small resource usaga GPIO like io access, I have done it many projects some microfpga designs as example use "FSL ASIO" IP core what is configurable IP with 1 to n (n can be 1000+) I/O and connection to FSL the FEATURE (or problem) is of the ASIO core is that you can access GPIO pins only one at a time, what is sometimes nice, and sometimes a problem Antti PS it seems Antti-Brain october issues is going to be much more pages then usual i hope the content is of some interest tooArticle: 143737
On Oct 22, 8:14=A0pm, rickman <gnu...@gmail.com> wrote: > On Oct 21, 7:16=A0am, David Brown <da...@westcontrol.removethisbit.com> > wrote: > > > > > > > glen herrmannsfeldt wrote: > > > rickman <gnu...@gmail.com> wrote: > > >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrot= e: > > > (snip) > > > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > > >>> ESA/370, ESA/390, and z/Architecture. > > > > (snip) > > >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressin= g > > >>> as appropriate, and instructions change as the addressing mode chan= ges. > > > >> How are the bits in the address bus numbered? =A0I would find it > > >> extremely confusing to deal with an address where the lsb is numbere= d > > >> N where N varies depending on the size of the address range. > > > > If by 'address bus' you mean the physical hardware, that is a separat= e > > > question from the architecture. =A0 > > > > Otherwise, the numbering changed in z/, but is internally consistent. > > > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > > > for example, and the address as stored in the PSW is bits 40 to 63. > > > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > > > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > > > That only comes up in reading the descriptions of the instructions. > > > This is "nice and consistent" ?? =A0The bit numbering for the same addr= ess > > varies according to the size of the register, and the significance of a > > bit of a given number varies according to the register, the bit width, > > and the machine variant. =A0I'll agree that much of this is hidden from > > the programmer, and that you can get used to it, but it's still > > inconsistent and it's still messy. > > > I've dealt with this in the context of PPC microcontrollers - it is a > > big pain in the neck, and it's very easy to get wrong. =A0Virtually > > everything else in the electronics world numbers bits consistently from > > 0 for the LSB - the PPC sticks out like a sore thumb and means that you > > need to invert the bus numbering when connecting it to external memory. > > =A0 Internally, when programming these things, you get the joys of > > figuring out which bits are which in the documentation, and how that > > corresponds to reality. =A0The manual might tell you a hardware registe= r > > is theoretically 64 bits, with the field you are interested in from bit= s > > 56 to 59. =A0However, perhaps only the lower 32 bits of the register ar= e > > implemented, so the actual bits are 24 to 27. =A0You then have to > > translate this into sensible bit numbers, 4 to 7, so that you can use > > them in software. =A0All in all, reverse bit numbering is a big waste o= f > > time and effort, and a big cause of mistakes. > > > And for PPC devices (at least, those I have looked at) with 64-bit > > architectures, the external databus is numbered consistently with the > > 32-bit devices. =A0Thus the LSB of the data and address buses stays at = 31. > > =A0 So the upper half of the databus runs from D-1 to D-32 as the MSB. > > Internally, of course, the registers are numbered with bit 0 as the MSB > > and bit 63 as the LSB. =A0Thus bit 0 in a data register corresponds to = pin > > D-32 on the PPC, matching net D63 on any external memory bus. > > > Yes, "nice and consistent" is just the phrase... > > > > In actual coding, (software) one can write a loop in whichever > > > way one wants. =A0The hardware will execute it independent of the > > > thought process of the programmer. > > > I was under the impression that programming was about getting the > > hardware to execute /dependent/ on the thoughts of the programmer! > > > > It never confused me. > > > I've not use the Power architecture, only some PowerPC devices, but I > > have to admit it has confused me on occasion, and irritated and > > frustrated me more often than that. > > > mvh., > > > David > > I didn't realize that the microBlaze used a little endian bus > numbering convention. =A0That is a good reason to avoid it... a small > reason, but a reason nonetheless. > > Actually, the main reason to avoid proprietary IP like microBlaze is > the fact that it is proprietary. =A0I prefer to use one of the available > CPUs that are open source and can be ported to chips from any vendor > or even an ASIC. > > Rick- Hide quoted text - > > - Show quoted text - Hi, MicroBlaze use big-endian byte-ordering and big-endian bit ordering. This is a legacy from PowerPC and CoreConnect bus. It's not only PowerPC who uses big-endian ordering. As much as the msb bit number changes for big-endian so does the lsb bit number for little-endian. In my earlier years before MicroBlaze I only used little-endian bit ordering and I had to change to big-endian for MicroBlaze. It took some time but now when I define a vector bus it tends to be big-endian. I don't have much of a preference anymore. it's just two different ways of defining a vector. I do however prefer big-endian byte order since when dumping bytes from memory will show the word in the right order. We tend to write numbers with the most significant numbers to the left and that is how big-endian is storing bytes within a word. But I'm not sure if big-endian byte order and little-endian bit order is a good idea. It might be too confusing. G=F6ranArticle: 143738
"Andy Botterill" <andy@plymouth2.demon.co.uk> wrote in message news:4ae0966d$0$17520$bed64819@gradwell.net... > Scorpiion wrote: .. > > The ISIM simulator does work under linux. > > I have no knowledge of VHDL simulators for linux. > It is called Modelsim DE (just released) The good news is that it includes PSL/SVA so assertions are no longer reserved for the big boys :-) Hans www.ht-lab.com > The officially supported o/s is RHEL and I think vista. > > Support for the design process I don't know. Andy >> >> I have looked at some of Xilinks and Alteras homepages and it seams that >> they have software for Linux. But it would be good to hear from someone >> with experince how the different software packages work? (if some company >> have better software than other, or someones software is better for the >> Linux platform) >> >> I'm just not sure where to start and some genereal tips on Linux and >> CPLD/FPGAs would also be good to hear... :) >> >> Regards, Robert >>Article: 143739
Le Thu, 22 Oct 2009 10:42:15 -0700, austin a écrit : > Programming tools (the JTAG programming cable) used with Linux are > always a bit tough to get to work (just read the posts on the subject) > as support of USB isn't as trivial as it is with 'Windoze.' Are you sure of that ? Xilinx windrv ported to linux is a nightmare. I'm using this library <http://www.rmdir.de/~michael/xilinx/> fairly support cable III, cableIV and this one http://www.digilentinc.com/Products/ Detail.cfm?NavPath=2,395,716&Prod=XUP-USB-JTAG i'm using for the moment. You can read the XAPP502 if you want to deeply embed programming CPLD/ FPGA. As an example PROGRAM, CCLK, DIN, INIT, DONE signals are quite easily driven by a microcontroller to do the job with a .bit or .rbt file. After a discussion with M. Delorie in this very ng, i found XAPP058 a bit complicated for my needs ... HabibArticle: 143740
Goran_Bilski wrote: > On Oct 22, 8:14 pm, rickman <gnu...@gmail.com> wrote: >> On Oct 21, 7:16 am, David Brown <da...@westcontrol.removethisbit.com> <snip to save space> >> I didn't realize that the microBlaze used a little endian bus >> numbering convention. That is a good reason to avoid it... a small >> reason, but a reason nonetheless. >> I don't actually know much about the MicroBlaze - I can only refer to the PPC, which I have used (not in FPGAs). But I'd agree with you here - having big-endian bit numbering would definitely count against the MicroBlaze as far as I am concerned. I think it would be especially painful in FPGA designs, since tools can often automatically connect up buses (at least, that was the case when I did some work with the Nios and Quartus a few years ago). If you've got some components with big-endian bit numbering, and some with small-endian bit numbering, something's going to get mixed up pretty quickly. >> Actually, the main reason to avoid proprietary IP like microBlaze is >> the fact that it is proprietary. I prefer to use one of the available >> CPUs that are open source and can be ported to chips from any vendor >> or even an ASIC. >> That's another discussion entirely - good points, but they need their own branch or thread. >> Rick- Hide quoted text - >> >> - Show quoted text - > > Hi, > > MicroBlaze use big-endian byte-ordering and big-endian bit ordering. > This is a legacy from PowerPC and CoreConnect bus. > It's not only PowerPC who uses big-endian ordering. > The PPC is perhaps not alone in using big-endian bit numbering, but it is certainly one of only a very few processors. All the 32-bit processor families that I have worked with are big-endian. This includes MIPS, PPC, ColdFire (68k), AVR32 and Nios. Some of these (like MIPS and PPC) can handle little-endian data to some extent, but are naturally big-endian. The only two major little-endian 32-bit architectures I can think of are ARM and x86. I don't know why most "modern" designs are big-endian. There are good reasons why older CISC designs (such as VAX and x86) are little-endian - for one thing, it makes it easier to write multi-byte arithmetic functions, and it makes it easier to convert integer sizes. There seems to be a fair correlation between RISC and big-endian - certainly when you move from an architecture oriented around accessing memory, working with 8 bits at a time to an architecture oriented around keeping data in registers, and working with a full 32-bit register at a time, then the key advantages of little-endian ordering are no longer relevant. However, of those architectures, the only one which uses big-endian bit numbering is the PPC. Preferences and experiences are, of course, personal. Some people have strong opinions about which endianness they prefer (just ask the Lilliputeans), others are happy to mix and match. > As much as the msb bit number changes for big-endian so does the lsb > bit number for little-endian. > > In my earlier years before MicroBlaze I only used little-endian bit > ordering and I had to change to big-endian for MicroBlaze. > It took some time but now when I define a vector bus it tends to be > big-endian. > I don't have much of a preference anymore. it's just two different > ways of defining a vector. > > I do however prefer big-endian byte order since when dumping bytes > from memory will show the word in the right order. > We tend to write numbers with the most significant numbers to the left > and that is how big-endian is storing bytes within a word. > > But I'm not sure if big-endian byte order and little-endian bit order > is a good idea. It might be too confusing. > It's the most common arrangement, in my experience. > GranArticle: 143741
austin <austin@xilinx.com> wrote: > Programming tools (the JTAG programming cable) used with Linux are > always a bit tough to get to work (just read the posts on the subject) > as support of USB isn't as trivial as it is with 'Windoze.' Xc3sprog at sourceforge is also supposed to work out of the box for many cable and devices. I am interessted in cases where it doesn't. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 143742
> Okay. I am just a beginner and was easily confused by Ben Jones'
> comment earlier in this topic when he wrote that "But I would be
> surprised if you ever needed to worry about 50ppm frequency drift in
> an FPGA application. The DLL jitter will be an order of magnitude
> greater than that... "
Hi Alex,
Sorry to confuse you!
What I meant was that in a typical FPGA design, one or more of your
clocks is likely to come from a DLL-based clock management block,
which usually has an output jitter on the order of 100s of
picoseconds. That is, even if the cycle time of your clock is 10ns
when averaged over a few microseconds, the actual time elapsed between
one active edge and the next might vary by 1% or more. This is
certainly not the same as frequency accuracy/stability - but if your
task is to produce a highly precise clock output, it's probably a
bigger barrier to your application.
I didn't go to time school, though, so don't pay *too* much attention
to what I say. :-)
-Ben-
Article: 143743
doug <xx@xx.com> wrote:
>
>
>Nico Coesel wrote:
>
>> doug <xx@xx.com> wrote:
>>
>>
>>>
>>>Alex wrote:
>>>
>>>
>>>>Hi Ben,
>>>>
>>>>Thank you for reply.
>>>>
>>>>I actually worry about clock's time stability because I want to design
>>>>FPGA-based oscillator whose frequency can be set in 0.1 Hz steps.
>>>>Whether 50 ppm clock's stability is good enough to be used for such
>>>>design?
>>>
>>>You need to look at the difference between accuracy and resolution and
>>>stability. A DDS will give you a resolution proportional to the number
>>>of bits in the accumulator. The accuracy of the divide ratio is
>>>absolute. The accuracy of the output frequency is proportional to the
>>>accuracy of the oscillator. If you output a 10MHz signal with a
>>>reference oscillator whose stability over temperature and time is 50ppm,
>>>the output frequency can vary by 500Hz. At a couple of ppm per degree,
>>>the frequency would wander perhaps 20Hz per degree. This means a .1Hz
>>>resolution is not very useful. For this to be meaninful, you would
>>>need a stability of .01ppm. If, however, you are doing this at 20KHz,
>>>then the .1Hz corresponds to 5ppm and it is not so awful to use the
>>>50ppm stability oscillator.
>>
>>
>> Sorry, but this is all wrong!
>
>No, is is just fine.
No, in your claims the drift gets worst at lower frequencies. However,
ppm as a relative error indicator is constant across all output
frequencies so your claims must be false.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 143744
-jg <jim.granville@gmail.com> wrote:
>On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote:
>> So, having decided every-cycle precision is not practical, you have to
>> decide over what time you need this 0.1Hz ?
>> Suppose you need it over 100ms, then you can generate 99,999 cycles of
>> 1.00us, and one cycle of
>
>( oops, Hit the wrong button...)
>Finishing that example: in a pure digital domain
>
>For a 100ms time average, of your 1000000.1 Hz, we generate
>99,999 cycles of 1,00us and one cycle 10ns less
>Frequency is then Cycles.Time =3D
>
>100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001
>
>So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of
>greater than 100ms, with a 10ns timebase.
>That certainly is FPGA doable.
It certainly is. Years ago I build a DPLL in an FPGA that way for
synchronising to an E1 line. It has a range of +/- 200ppm in less than
0.5ppm steps. Its just a matter of skipping or inserting extra clock
cycles each frame.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 143745Goran_Bilski <goran.bilski@xilinx.com> wrote: (snip) > MicroBlaze use big-endian byte-ordering and big-endian bit ordering. > This is a legacy from PowerPC and CoreConnect bus. > It's not only PowerPC who uses big-endian ordering. > As much as the msb bit number changes for big-endian so does the lsb > bit number for little-endian. (snip) > I do however prefer big-endian byte order since when dumping bytes > from memory will show the word in the right order. > We tend to write numbers with the most significant numbers to the left > and that is how big-endian is storing bytes within a word. The VAX/VMS DUMP program prints the HEX data right to left, and the ASCII data left to right with the address in the middle. Big endian avoids strange solutions like that. -- glenArticle: 143746
Nico Coesel wrote: > doug <xx@xx.com> wrote: > > >> >>Nico Coesel wrote: >> >> >>>doug <xx@xx.com> wrote: >>> >>> >>> >>>>Alex wrote: >>>> >>>> >>>> >>>>>Hi Ben, >>>>> >>>>>Thank you for reply. >>>>> >>>>>I actually worry about clock's time stability because I want to design >>>>>FPGA-based oscillator whose frequency can be set in 0.1 Hz steps. >>>>>Whether 50 ppm clock's stability is good enough to be used for such >>>>>design? >>>> >>>>You need to look at the difference between accuracy and resolution and >>>>stability. A DDS will give you a resolution proportional to the number >>>>of bits in the accumulator. The accuracy of the divide ratio is >>>>absolute. The accuracy of the output frequency is proportional to the >>>>accuracy of the oscillator. If you output a 10MHz signal with a >>>>reference oscillator whose stability over temperature and time is 50ppm, >>>>the output frequency can vary by 500Hz. At a couple of ppm per degree, >>>>the frequency would wander perhaps 20Hz per degree. This means a .1Hz >>>>resolution is not very useful. For this to be meaninful, you would >>>>need a stability of .01ppm. If, however, you are doing this at 20KHz, >>>>then the .1Hz corresponds to 5ppm and it is not so awful to use the >>>>50ppm stability oscillator. >>> >>> >>>Sorry, but this is all wrong! >> >>No, is is just fine. > > > No, in your claims the drift gets worst at lower frequencies. No, there is no claim the drift get worse at lower frequencies. Read the sentence again. However, > ppm as a relative error indicator is constant across all output > frequencies so your claims must be false. The calculations were fine. >Article: 143747
Nico Coesel wrote: > -jg <jim.granville@gmail.com> wrote: > > >>On Oct 23, 11:51=A0am, -jg <jim.granvi...@gmail.com> wrote: >> >>>So, having decided every-cycle precision is not practical, you have to >>>decide over what time you need this 0.1Hz ? >>>Suppose you need it over 100ms, then you can generate 99,999 cycles of >>>1.00us, and one cycle of >> >>( oops, Hit the wrong button...) >>Finishing that example: in a pure digital domain >> >>For a 100ms time average, of your 1000000.1 Hz, we generate >>99,999 cycles of 1,00us and one cycle 10ns less >>Frequency is then Cycles.Time =3D >> >>100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001 >> >>So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of >>greater than 100ms, with a 10ns timebase. >>That certainly is FPGA doable. > > > It certainly is. Years ago I build a DPLL in an FPGA that way for > synchronising to an E1 line. It has a range of +/- 200ppm in less than > 0.5ppm steps. Its just a matter of skipping or inserting extra clock > cycles each frame. > This works fine for locking to a fixed frequency over a narrow range and many of us have used it. The deficiency of it is that it is fine for digital clocks but is bad for analog signals. For generating arbitrary frequencies, you are better off using a DDS. The DDS is even available as a coregen element for Xilinx (the digital part anyway).Article: 143748
On 23 =CF=CB=D4, 13:47, Ben Jones <benj...@gmail.com> wrote: > > Okay. I am just a beginner and was easily confused by Ben Jones' > > comment earlier in this topic when he wrote that "But I would be > > surprised if you ever needed to worry about 50ppm frequency drift in > > an FPGA application. The DLL jitter will be an order of magnitude > > greater than that... " > > Hi Alex, > > Sorry to confuse you! > > What I meant was that in a typical FPGA design, one or more of your > clocks is likely to come from a DLL-based clock management block, > which usually has an output jitter on the order of 100s of > picoseconds. That is, even if the cycle time of your clock is 10ns > when averaged over a few microseconds, the actual time elapsed between > one active edge and the next might vary by 1% or more. This is > certainly not the same as frequency accuracy/stability - but if your > task is to produce a highly precise clock output, it's probably a > bigger barrier to your application. > > I didn't go to time school, though, so don't pay *too* much attention > to what I say. :-) > > =9A =9A =9A =9A-Ben- Okay, Ben! Thanks a lot for helpful replies. :-)Article: 143749
On 23 =CF=CB=D4, 02:03, -jg <jim.granvi...@gmail.com> wrote: > On Oct 23, 11:51=9Aam, -jg <jim.granvi...@gmail.com> wrote: > > > So, having decided every-cycle precision is not practical, you have to > > decide over what time you need this 0.1Hz ? > > Suppose you need it over 100ms, then you can generate 99,999 cycles of > > 1.00us, and one cycle of > > ( oops, Hit the wrong button...) > Finishing that example: in a pure digital domain > > For a 100ms time average, of your 1000000.1 Hz, we generate > 99,999 cycles of 1,00us and one cycle 10ns less > Frequency is then Cycles.Time =9A=3D > > 100000/(99999*1.0u + (1u-10n)) =3D 1000000.10000001 > > So, you _can_ generate 1MHz to 0.1Hz increments, over multiples of > greater than 100ms, with a 10ns timebase. > That certainly is FPGA doable. > > Over 10.00 seconds, you will get 10000001 edges (etc) > > I will need that stability over time scale larger than 100ms indeed. Thank you for helpful reply!
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