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
Thorsten Kiefer <thorstenkfr@googlemail.com> wrote: > I don't know, what is state-of-the-art for function approximation > on FPGAs. > I developed this : > http://toki.burn3r.de/html5-projects/boolean-functions.html > "Paper" (10 minutes hack) for this : > http://toki.burn3r.de/html5-projects/boolean-functions/paper.html > If I tried to implement the constructor for PBFs in VHDL, > like a Float-Core-Generator, would I need to generate > VHDL code, or can VHDL function generate intermediate gates ? I am not so sure what you are asking. In CS terms, VHDL is a compiled language, so you can't read in expressions and then execute them as VHDL code. Well, actually I am not sure that you can't in simulation, but you can't when using it for logic synthesis, which is what you do when working with FPGAs. More generally, though, some FPGAs allow partial reconfiguration which is the logic equivalent of dynamic linking. About 10 years ago, I know about someone who had an FPGA with built-in PowerPC cores, running linux on one, and then generating logic on that processor, and loading it into the FPGA. If you want more detail, you have to be more specific about what you want to do, and why you want to do it. (The reason can be a school project, but the answer will be different.) The usual reason for doing something in an FPGA instead of software is that you need to do it much faster, and/or (usually and) zillions of times. (Millions or billions can still usually be done better in software.) One problem that I know of, and an interested in doing in an FPGA, has a fairly simple operation that it does 1e19 times, every few days. Now, since the primary logic element of most FPGAs is a small RAM (look-up table), you can just configure some and load whatever values you want to load into them. (But with fixed routing.) > If I tried to implement the solve() procedure, I would need > a random number generator. Is there a Xilinx IP core for this ? Many software random number generators should be easy to implement in hardware, and for many more bits than the software versions. -- glenArticle: 156776
On Tuesday, June 24, 2014 12:14:36 PM UTC-5, Thorsten Kiefer wrote:
> But it is not possible to create a whole entity, right ? For a whole entity I need an intermediate VDHL file, right ?
Yes, the top-level module for a synthesis job is always an entity and it's architecture. The architecture could call the function concurrently, or use an explicit process (clocked or combinatorial) to call the function.
The function can be declared in a package ("used" by the entity/architecture), or in the architecture itself.
Andy
Article: 156777Hi, before downloading ISE webpack, I wanted to ask, if there is a free VHDL simulator, which is easy to compile or stable ? FreeHDL crashes on my machine, and ghdl -> I don't know how to compile. Any suggestions ? -ThorstenArticle: 156778
Am Dienstag, 24. Juni 2014 23:07:50 UTC+2 schrieb jone...@comcast.net:
> On Tuesday, June 24, 2014 12:14:36 PM UTC-5, Thorsten Kiefer wrote:
>
> > But it is not possible to create a whole entity, right ? For a whole entity I need an intermediate VDHL file, right ?
>
>
>
> Yes, the top-level module for a synthesis job is always an entity and it's architecture. The architecture could call the function concurrently, or use an explicit process (clocked or combinatorial) to call the function.
>
>
>
> The function can be declared in a package ("used" by the entity/architecture), or in the architecture itself.
>
>
>
> Andy
Thanks a lot for all your help !
I will try this as soon as I have an open source / free VHDL simulator environment.
Thorsten
Article: 156779Hi Thorsten, > if there is a free VHDL simulator, which is easy to compile or stable ? > FreeHDL crashes on my machine, and ghdl -> I don't know how to compile. there are lesser known beasts out there like nvc (it has left me with a goo= d impression) or Nick's VHDL compiler and fauhdlc (interpreter for an IR fo= r expressing a VHDL subset). fauhdlc has reached to a point of getting regu= lar ubuntu packaging. nvc is on github and looks alive (last updated four d= ays ago). nvc: https://github.com/nickg/nvc fauhdlc: http://www3.informatik.uni-erlangen.de/Research/fauhdlc/ Both are some steps from supporting the entire VHDL'93 or VHDL-2000 yet the= y are quite interesting.=20 Best regards Nikolaos Kavvadias http://www.nkavvadias.comArticle: 156780
On 6/18/2014 10:59 PM, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: > >> That entirely depends on the FPGA. There are plenty of FPGAs >> with only one power supply voltage. > > Well, many have separate I/O power pins, and you might be able to > run that at the same voltage as the core, but often the core voltage > is close to 1.0, and that is low for many I/O pins. I use FPGAs which are powered solely by 3.3 volts. Like many MCUs they use internal regulators to produce the core voltage or you can get a version that uses an external supply for the core voltage. -- RickArticle: 156781
On 6/24/2014 6:49 PM, Thorsten Kiefer wrote:
> Am Dienstag, 24. Juni 2014 23:07:50 UTC+2 schrieb jone...@comcast.net:
>> On Tuesday, June 24, 2014 12:14:36 PM UTC-5, Thorsten Kiefer wrote:
>>
>>> But it is not possible to create a whole entity, right ? For a whole entity I need an intermediate VDHL file, right ?
>>
>>
>>
>> Yes, the top-level module for a synthesis job is always an entity and it's architecture. The architecture could call the function concurrently, or use an explicit process (clocked or combinatorial) to call the function.
>>
>>
>>
>> The function can be declared in a package ("used" by the entity/architecture), or in the architecture itself.
>>
>>
>>
>> Andy
>
> Thanks a lot for all your help !
> I will try this as soon as I have an open source / free VHDL simulator environment.
There are lots of free simulators. Each FPGA vendor has a free set of
tools which includes a free simulator. If you want an open source VHDL
simulator, your options are much more limited. GHDL is the only one I
am aware of off the top of my head, but a search turned up this page
which lists some other possibilities.
http://www.vhdl.org/
--
Rick
Article: 156782On Tue, 24 Jun 2014 15:48:25 -0700, Thorsten Kiefer wrote: > Hi, > before downloading ISE webpack, I wanted to ask, if there is a free VHDL > simulator, which is easy to compile or stable ? > > FreeHDL crashes on my machine, and ghdl -> I don't know how to compile. ghdl : on most platforms you don't have to compile it, there are pre- built packages of ghdl-0.31 available, see http://sourceforge.net/ projects/ghdl-updates/ If your OS isn't covered; what do you need? If you meant you don't know how to compile your VHDL code... http://sourceforge.net/p/ghdl-updates/wiki/Using%20ghdl/ and see the ghdl manual linked there. - BrianArticle: 156783
>nba83 wrote: >> hi >> i have a custom designed board with xilinx spartan 3( xc3s400 ) with two >> ethernet phy layer (RTL8201) for a two port switch. I have a ring network >> of 10 of this board on the chain. i transmit data from the first board and >> count the number of packets from the last ethernet port of the tenth board >> to test the integrity of switch and the hdl code. >> the code in some synthesis work without error but when i add another piece >> of code for example a counter which is unrelated to the other logics and re >> synthesis the code the previous parts of my code work with error. >> i guess it is due to place and route section and timing constranits of >> ethernet phy layer. this phy layer has 2 independ transmit and receive clk >> and due to ease of pcb routing i connected these clk signals to normal pins >> not the global clk pins and now i think the timing constraints are disabled >> since i used this contraint on the pin NET "RTL_RXCLK" >> CLOCK_DEDICATED_ROUTE = "FALSE"; >> in timing reports it is said that all timing constraints are met but there >> is warning saying “The use of >> this override is highly discouraged as it may lead to very poor timing >> results” . what is the problem and >> how can i fixed the problem ?i cannot change the pcb because of the price >> and time :( is it possible to check and apply timing constraints in fpga >> editor? >> Tnx in advanced for any helpful comment >> Neda Baheri >> >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com > >The CLOCK_DEDICATED_ROUTE constraint will not disable timing analysis. >It is only a routing directive. If you have timing constraints >that cover the period, clock to output, setup and hold for this >clock, then you should still be able to see if there are timing >issues after static timing analysis. > >I generally recommend generating a verbose timing report with >"report unconstrained paths" set to a large number like 100. >This might show areas that need additional constraints. > >On the other hand, there is still the possibility that this >design has errors in clock crossing logic or asynchronous >signal synchronization. That sort of problem very often >comes and goes with a new build due to changes in placement, >and therefore changes in relative routing delays of the >poorly handled signals. > >-- >Gabor > Tnx for your helpful comment. I have 6 clock signals: 2 tx_clk(25MHz), 2 rx_clk(25MHz) for 2 Phy layers, 1 for adc sampling(1MHz) , 1 for spi(1MHz) communication. I only have period constraint for 25MHz clk signal. I don't have any idea how to set clock to output, setup and hold constraints for these clocks. and for 1MHz clocks there is no time constraint (since these clocks are so slow to set any constraints). how should I know from verbose timing report that which areas need additional constraints? and how should I apply the changes to my design? I hardly think there must be cross clocking domain issues, I have buffers to receive data from RX clock and transmit from TX clock. Tnx in advanced for any helpful comment Neda Baheri --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156784
nba83 wrote: >> nba83 wrote: >>> hi >>> i have a custom designed board with xilinx spartan 3( xc3s400 ) with > two >>> ethernet phy layer (RTL8201) for a two port switch. I have a ring > network >>> of 10 of this board on the chain. i transmit data from the first board > and >>> count the number of packets from the last ethernet port of the tenth > board >>> to test the integrity of switch and the hdl code. >>> the code in some synthesis work without error but when i add another > piece >>> of code for example a counter which is unrelated to the other logics and > re >>> synthesis the code the previous parts of my code work with error. >>> i guess it is due to place and route section and timing constranits of >>> ethernet phy layer. this phy layer has 2 independ transmit and receive > clk >>> and due to ease of pcb routing i connected these clk signals to normal > pins >>> not the global clk pins and now i think the timing constraints are > disabled >>> since i used this contraint on the pin NET "RTL_RXCLK" >>> CLOCK_DEDICATED_ROUTE = "FALSE"; >>> in timing reports it is said that all timing constraints are met but > there >>> is warning saying “The use of >>> this override is highly discouraged as it may lead to very poor timing >>> results” . what is the problem and >>> how can i fixed the problem ?i cannot change the pcb because of the > price >>> and time :( is it possible to check and apply timing constraints in > fpga >>> editor? >>> Tnx in advanced for any helpful comment >>> Neda Baheri >>> >>> >>> --------------------------------------- >>> Posted through http://www.FPGARelated.com >> The CLOCK_DEDICATED_ROUTE constraint will not disable timing analysis. >> It is only a routing directive. If you have timing constraints >> that cover the period, clock to output, setup and hold for this >> clock, then you should still be able to see if there are timing >> issues after static timing analysis. >> >> I generally recommend generating a verbose timing report with >> "report unconstrained paths" set to a large number like 100. >> This might show areas that need additional constraints. >> >> On the other hand, there is still the possibility that this >> design has errors in clock crossing logic or asynchronous >> signal synchronization. That sort of problem very often >> comes and goes with a new build due to changes in placement, >> and therefore changes in relative routing delays of the >> poorly handled signals. >> >> -- >> Gabor >> > Tnx for your helpful comment. I have 6 clock signals: 2 tx_clk(25MHz), 2 > rx_clk(25MHz) for 2 Phy layers, 1 for adc sampling(1MHz) , 1 for spi(1MHz) > communication. I only have period constraint for 25MHz clk signal. I don't > have any idea how to set clock to output, setup and hold constraints for > these clocks. and for 1MHz clocks there is no time constraint (since these > clocks are so slow to set any constraints). > how should I know from verbose timing report that which areas need > additional constraints? and how should I apply the changes to my design? > I hardly think there must be cross clocking domain issues, I have buffers > to receive data from RX clock and transmit from TX clock. > Tnx in advanced for any helpful comment > Neda Baheri > > --------------------------------------- > Posted through http://www.FPGARelated.com The ISE GUI has a utility under the process: User Constraints --> Create Timing Constraints that helps you build timing constraints for the design. As for finding the additional constraints you need, you can look at the Static Timing from the Design Summary viewer. You will see lots of entries in the report starting with the word "Unconstrained." Look at the reported worst case paths for these to see if they violate your system requirements. At 1 MHz or even 25 MHz, you're not likely to see issues with PERIOD timing. However there is always the possibility of input setup and hold or clock to output timing issues, especially if you haven't pushed all registers into the IOB's. You also state "I hardly think there must be cross clocking domain issues..." I would suggest you think again. Wherever you use a signal in a synchronous process that was not sourced by the same clock, you can have a clock-domain-crossing (CDC) issue. In state machines these can lead to lock-up, or to occasional wrong behavior. The lower your operating frequency, the less often the failure occurs, but there is no frequency above DC where it can't happen, because it has to do with setup and hold time, and not signal delay. The standard tools you get with ISE do not check for CDC issues, and you'd have to spend a lot of money to get a tool that automates this process. However, if you know your design you can go through it and check for areas of potential problem. The number one rule for CDC is that any signal must go through exactly one flip-flop where it crosses into a new clock domain. i.e. the same signal must not be sampled by two different flip-flops in the new clock domain. After going through the first flop, the Q of that flop can be sampled by multiple other flops in the new domain. If you are concerned about metastability, you can add a second flop after the first one before fanning out. i.e. consider the output of the first flop in the new domain to still be "asynchronous" because it can have unknown additional metastable delay. You can probably get a lot more information about CDC if you google for "Clock Domain Crossing." There are also a lot of discussions on this topic in the Xilinx user forums at: http://forums.xilinx.com -- GaborArticle: 156785
GaborSzakacs <gabor@alacron.com> wrote: > nba83 wrote: (snip) >> Tnx for your helpful comment. I have 6 clock signals: 2 tx_clk(25MHz), 2 >> rx_clk(25MHz) for 2 Phy layers, 1 for adc sampling(1MHz) , 1 for spi(1MHz) >> communication. I only have period constraint for 25MHz clk signal. I don't >> have any idea how to set clock to output, setup and hold constraints for >> these clocks. and for 1MHz clocks there is no time constraint (since these >> clocks are so slow to set any constraints). (snip) > At 1 MHz or even 25 MHz, you're not likely to see issues with > PERIOD timing. However there is always the possibility of > input setup and hold or clock to output timing issues, especially > if you haven't pushed all registers into the IOB's. > You also state "I hardly think there must be cross clocking domain > issues..." > I would suggest you think again. Wherever you use a signal in a > synchronous process that was not sourced by the same clock, you > can have a clock-domain-crossing (CDC) issue. In state machines > these can lead to lock-up, or to occasional wrong behavior. The > lower your operating frequency, the less often the failure occurs, > but there is no frequency above DC where it can't happen, because > it has to do with setup and hold time, and not signal delay. Note that there are two problems to worry about in clock domain cases. One is metastability, where one signal changes at just the wrong time. The second comes when multiple signals are latched by the same clock, such that some might change before, and others after, the clock edge. This is unrelated to metastability, and would happen even with zero setup and zero hold time. > The number one rule > for CDC is that any signal must go through exactly one flip-flop > where it crosses into a new clock domain. i.e. the same signal > must not be sampled by two different flip-flops in the new clock > domain. After going through the first flop, the Q of that flop > can be sampled by multiple other flops in the new domain. If you > are concerned about metastability, you can add a second flop after > the first one before fanning out. i.e. consider the output of the > first flop in the new domain to still be "asynchronous" because > it can have unknown additional metastable delay. One favorite case is passing a count value from one side of a FIFO to the other. Note that with different delays, the different bits of the counter might get latched on different clock edges. That would result in the value latched being nowhere near the desired value. If you can't be sure that it won't happen, the system has to work with the bits, no matter which side of the clock edge they are on. In the FIFO case, the fix is a gray-code counter. In gray code, only one bit changes at each transition, so that the other side gets either the new or old value, never any other. -- glenArticle: 156786
On 6/25/2014 2:40 PM, glen herrmannsfeldt wrote: > > One favorite case is passing a count value from one side of a FIFO > to the other. Note that with different delays, the different bits > of the counter might get latched on different clock edges. That would > result in the value latched being nowhere near the desired value. > > If you can't be sure that it won't happen, the system has to work > with the bits, no matter which side of the clock edge they are on. > In the FIFO case, the fix is a gray-code counter. In gray code, only > one bit changes at each transition, so that the other side gets > either the new or old value, never any other. It doesn't have to be multiple bits. It can be one bit going to multiple destinations. I had a UART in a test fixture design and was having all sorts of problems with it. In debugging it was hard to capture the fault and I spent a lot of time on this thinking it was a software problem. Eventually I found that I had made the rookie mistake of omitting the sync FF on the data input. That signal was feeding the shift register, the state machine and the error detection logic. It would sometimes change at the right time so that the old bit was seen by part of the state machine and the new bit was seen by other parts so that it would corrupt the function and therefor the data. ALWAYS sync incoming data through one FF and if you have any worries about meta stability sync through two FFs. Further, your clocks likely can be combined (other than the xmit and rcv clocks). 1 MHz SPI and ADC sampling can be derived from a 25 MHz clock. Pick one clock you will have around at all times and use that as the "master clock". When transferring data between domains, use that clock as the clock of reference. Even easier is to use say a 100 MHz clock as the master clock and bring *all* data into that domain immediately and performing all processing in that domain before passing it to a different output clock domain. -- RickArticle: 156787
Hi, this doesn't exactly answer your question. But the non-free ISIM that comes with ISE webpack is quite useful, especially in combination with gtkwave. It can cope with mixed Verilog/VHDL designs up to some (IMO fairly reasonable) size limit. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156788
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> One favorite case is passing a count value from one side of a FIFO >> to the other. Note that with different delays, the different bits >> of the counter might get latched on different clock edges. That would >> result in the value latched being nowhere near the desired value. >> If you can't be sure that it won't happen, the system has to work >> with the bits, no matter which side of the clock edge they are on. (snip of FIFO example) > It doesn't have to be multiple bits. It can be one bit going to > multiple destinations. Yes. Well, depending on how you look at it, that is multiple bits. If you can draw a line through the schematic, and it crosses multiple lines that come from one clock (including outside signals with unrelated clocks) and going to separate FFs, that is the same as multiple bits. But I agree that it is less obvious when thinking about it, compared to bits output from a counter. > I had a UART in a test fixture design and was having all sorts of > problems with it. In debugging it was hard to capture the fault and I > spent a lot of time on this thinking it was a software problem. > Eventually I found that I had made the rookie mistake of omitting the > sync FF on the data input. That signal was feeding the shift register, > the state machine and the error detection logic. It would sometimes > change at the right time so that the old bit was seen by part of the > state machine and the new bit was seen by other parts so that it would > corrupt the function and therefor the data. UART reminds me, I knew someone interfacing an 8251 UART to an Apple II, including connecting data lines D0 through D7 to D0 through D7. Unfortunately, the two didn't number the bits the same way. > ALWAYS sync incoming data through one FF and if you have any worries > about meta stability sync through two FFs. Further, your clocks likely > can be combined (other than the xmit and rcv clocks). 1 MHz SPI and ADC > sampling can be derived from a 25 MHz clock. Pick one clock you will > have around at all times and use that as the "master clock". When > transferring data between domains, use that clock as the clock of > reference. > Even easier is to use say a 100 MHz clock as the master clock and bring > *all* data into that domain immediately and performing all processing in > that domain before passing it to a different output clock domain. -- glenArticle: 156789
On 6/23/2014 1:11 AM, nba83 wrote: > hi > i have a custom designed board with xilinx spartan 3( xc3s400 ) with two > ethernet phy layer (RTL8201) for a two port switch. I have a ring network > of 10 of this board on the chain. i transmit data from the first board and > count the number of packets from the last ethernet port of the tenth board > to test the integrity of switch and the hdl code. > the code in some synthesis work without error but when i add another piece > of code for example a counter which is unrelated to the other logics and re > synthesis the code the previous parts of my code work with error. > i guess it is due to place and route section and timing constranits of > ethernet phy layer. this phy layer has 2 independ transmit and receive clk > and due to ease of pcb routing i connected these clk signals to normal pins > not the global clk pins and now i think the timing constraints are disabled > since i used this contraint on the pin NET "RTL_RXCLK" > CLOCK_DEDICATED_ROUTE = "FALSE"; > in timing reports it is said that all timing constraints are met but there > is warning saying “The use of > this override is highly discouraged as it may lead to very poor timing > results” . what is the problem and > how can i fixed the problem ?i cannot change the pcb because of the price > and time :( is it possible to check and apply timing constraints in fpga > editor? > Tnx in advanced for any helpful comment > Neda Baheri Are you aware that you can add wires to a PCB? If you are only talking about 10 boards then it would not be too hard a task to add a few wires. If you are talking about 1000 boards you should redo the board. Also, the problem created by not routing the clock into the chip on a clock pin only has to do with the timing of the I/O signals relative to the clock. Bringing the clock into the chip on a non-clock pin means the clock must be routed through the general routing with a larger variation in timing. So if you have 5 ns of setup time on your data, but run the clock on a non-dedicated clock pin your setup time at the FF may be close to 0 or even negative meaning a timing violation. -- RickArticle: 156790
Am Mittwoch, 25. Juni 2014 22:50:55 UTC+2 schrieb mnentwig: > Hi, > > > > this doesn't exactly answer your question. But the non-free ISIM that comes > > with ISE webpack is quite useful, especially in combination with gtkwave. > > It can cope with mixed Verilog/VHDL designs up to some (IMO fairly > > reasonable) size limit. > > > > --------------------------------------- > > Posted through http://www.FPGARelated.com I think, that will be my choice. BTW I use Lubuntu, and Lubuntu does not include ghdl. I meant : I don't know how to compile ghdl. Regards ThorstenArticle: 156791
On Wed, 25 Jun 2014 22:08:34 -0700, Thorsten Kiefer wrote: > Am Mittwoch, 25. Juni 2014 22:50:55 UTC+2 schrieb mnentwig: >> Hi, >> > > BTW I use Lubuntu, and Lubuntu does not include ghdl. > I meant : I don't know how to compile ghdl. Upstream of Lubuntu, there are problems or ambiguities licensing the IEEE libraries under terms acceptable to Debian. Until these are resolved somehow, official packages of ghdl are problematic. But you shouldn't need to compile ghdl : the .deb packages at [1] ought to install OK. If they don't, I'd be interested to know why not. [1] http://sourceforge.net/projects/ghdl-updates/files/Builds/ghdl-0.31/ Debian/ - BrianArticle: 156792
Hi there, we are measuring from a quadrature encoder the raw sine and cosine and need to extract the angular position [1]. The position is then fedback to a PID which drives a motor. We've been told that dither may be efficient in removing spurious harmonics due to quantization errors which may affect the control loop only few days before pcb production, therefore the only possibility was to add few resistors from the FPGA to Vref used in the opamp which feeds the ADC. Noise generated from the 4 toggling pins of the FPGA will be injected right at the input of our ADC. We met the deadline for the pcb production (great!), but unfortunately we just postpone the issue and moved it into the FPGA (imagine how happy was the fpga team!). Now I have the following questions: 1. how do I prove I need a dither generator? Indeed we didn't have even the time to figure out if we really need it. Is there a dedicated test I can perform which may undoubtly confirm the need? 2. how the dither generator noise spectrum should look like? I've read about both in-band and out of band dither but I'm still confused. 3. any reference for such generators on FPGA? A long LFSR (say 64bit) and only 4 pin used might seem silly, but is simple. OTOH I read LFSR do not provide random enough patterns therefore introducing other issues. Any help is appreciated. Al [1] by tracking demodulation. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 156793
On Sat, 28 Jun 2014 14:39:49 +0000, alb wrote: > Hi there, > > we are measuring from a quadrature encoder the raw sine and cosine and > need to extract the angular position [1]. The position is then fedback > to a PID which drives a motor. > > We've been told that dither may be efficient in removing spurious > harmonics due to quantization errors which may affect the control loop > only few days before pcb production, therefore the only possibility was > to add few resistors from the FPGA to Vref used in the opamp which feeds > the ADC. Noise generated from the 4 toggling pins of the FPGA will be > injected right at the input of our ADC. > > We met the deadline for the pcb production (great!), but unfortunately > we just postpone the issue and moved it into the FPGA (imagine how happy > was the fpga team!). > > Now I have the following questions: > > 1. how do I prove I need a dither generator? Indeed we didn't have even > the time to figure out if we really need it. Is there a dedicated > test I can perform which may undoubtly confirm the need? Calculate the worst-case inaccuracy in position due to quantization errors. This will be at a point where one ADC is reading maximum or minimum, and the other one is reading close to it's center point. If that inaccuracy if small enough to not cause you problems, then you're golden. If you don't know how small an error you need, then you must analyze your control loop, or you must build the system and give it a whirl. As a rule of thumb, your allowed quantization step should be about 1/4 or less of the desired precision of the axis, and it must be small enough that the quantization noise going into the derivative term in your controller does not heat up your motor or final amplifier, or cause undue power drain. Also, look at the ADC data sheets. If the internal noise from the ADC is greater than 1 LSB (it usually is for ADCs of more than 14 bits or so) then you're getting dither generated for you for absolutely free. In that case you may need to oversample the ADCs and average their outputs anyway, to avoid noise issues. > 2. how the dither generator noise spectrum should look like? I've read > about both in-band and out of band dither but I'm still confused. That depends on how complicated you want to get. In general dither is only going to do you any good if you accompany it by oversampling and decimating. In that case you'd either like the dither to be out of band, which you can approximate pretty well with a sigma-delta modulator on the dither signal, or you'd like the dither to be periodic, in which case you'd sample the raw ADC synchronously with updating the dither, and you'd average the ADC readings and decimate synchronous with the periodicity of the dither. > 3. any reference for such generators on FPGA? A long LFSR (say 64bit) > and only 4 pin used might seem silly, but is simple. OTOH I read LFSR > do not provide random enough patterns therefore introducing other > issues. If you oversample by a factor of 16, and if your four FPGA pins go through weighting resistors to make a 4-bit DAC, then just count from 0 to 15 and repeat. Unless you're driving an RC filter to your Vref you won't be able to do better than that. > [1] by tracking demodulation. I would capture the correct number by doing an arctan of the ADC inputs. This has worked well for me in the past, in software. You'll probably want to calculate the arctan using CORDIC or some other FPGA-ish method, but that's a nit. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 156794
Hi Tim, In comp.arch.fpga Tim Wescott <tim@seemywebsite.please> wrote: [] >> 1. how do I prove I need a dither generator? Indeed we didn't have even >> the time to figure out if we really need it. Is there a dedicated >> test I can perform which may undoubtly confirm the need? > > Calculate the worst-case inaccuracy in position due to quantization > errors. This will be at a point where one ADC is reading maximum or > minimum, and the other one is reading close to it's center point. If > that inaccuracy if small enough to not cause you problems, then you're > golden. The precision we have on the position can be directly transformed into angular precision: A = A0 + A1*sin(2*pi*opd/lambda) B = B0 + B1*cos(2*pi*opd/lambda + psi) where A/B are the sine/cosine signals, opd is the optical path difference (position in nm), lambda is the optical frequency (1550 nm) and psi a phase shift. With a precision in position of 20nm we have to have a precision in the phase accumulator which is of the order of 20/1550*2*pi ~4 deg (.00022 radian). But it looks to me a bit too big as a precision on a very sensitive optical mechanism... According to my calculations the 4 deg error corresponds to a normalized signal (A0/B0 removed and A1/B1 renormalized) of nearly 10% full scale... I guess something is wrong in my calculations! I guess though precision is not the only factor to take into account. While I can drive the motor precisely, it does not mean that I drive it smoothly instead might be rather jerky if I allow spourious frequencies to get out. > > If you don't know how small an error you need, then you must analyze your > control loop, or you must build the system and give it a whirl. As a > rule of thumb, your allowed quantization step should be about 1/4 or less > of the desired precision of the axis, and it must be small enough that > the quantization noise going into the derivative term in your controller > does not heat up your motor or final amplifier, or cause undue power > drain. But how can I hit the quantization error? Shall I consider a particular frequency for my sine/cosine waveform? IIRC quantization errors show up especially in submultiple of the ADC sampling frequency. > Also, look at the ADC data sheets. If the internal noise from the ADC is > greater than 1 LSB (it usually is for ADCs of more than 14 bits or so) > then you're getting dither generated for you for absolutely free. In > that case you may need to oversample the ADCs and average their outputs > anyway, to avoid noise issues. That is a good hint. I have an ENOB of 11.1, so in principle I have less than 1LSB noise for both distortion and noise... >> 2. how the dither generator noise spectrum should look like? I've read >> about both in-band and out of band dither but I'm still confused. > > That depends on how complicated you want to get. In general dither is > only going to do you any good if you accompany it by oversampling and > decimating. We are sampling at 250KSps a signal which is from DC to 4KHz... I'm wondering even why we are sampling with such a rate. Anyway it seems that decimating may be easily achieved. > In that case you'd either like the dither to be out of band, > which you can approximate pretty well with a sigma-delta modulator on the > dither signal, or you'd like the dither to be periodic, in which case > you'd sample the raw ADC synchronously with updating the dither, and > you'd average the ADC readings and decimate synchronous with the > periodicity of the dither. Being out of band would save me additional logic I guess. Indeed I can make it such to be filtered by the tracking demodulator. >> 3. any reference for such generators on FPGA? A long LFSR (say 64bit) >> and only 4 pin used might seem silly, but is simple. OTOH I read LFSR >> do not provide random enough patterns therefore introducing other >> issues. > > If you oversample by a factor of 16, and if your four FPGA pins go > through weighting resistors to make a 4-bit DAC, then just count from 0 > to 15 and repeat. Unless you're driving an RC filter to your Vref you > won't be able to do better than that. wouldn't that harmonic be affecting my tracking demodulator? > >> [1] by tracking demodulation. > > I would capture the correct number by doing an arctan of the ADC inputs. This is something I'm also wondering. Offset and renormalization are steps which need to be done anyway, but instead of a tracking demodulator the atan may be very simple, no loop required, no cutoff frequency...just plain easy. What about if your signals have a small phase shift? Truth is that if the phase shift error induced is not that large I could throw away the demodulator and live with the arctan... > This has worked well for me in the past, in software. You'll probably > want to calculate the arctan using CORDIC or some other FPGA-ish method, > but that's a nit. We are doing this in hardware and indeed we could have a look at the performances of the CORDIC to be used in our demodulator. Up to now nobody really looked at how we could optimize the algorithm. AlArticle: 156795
On 6/28/2014 7:39 AM, alb wrote: > Hi there, > > we are measuring from a quadrature encoder the raw sine and cosine and > need to extract the angular position [1]. The position is then fedback > to a PID which drives a motor. Are you sure that the outputs are true sine and cosine? The analog output, optical devices I have worked with, output trapezoidal waveforms with a phase shift similar to sine/cosine. BobHArticle: 156796
Hi BobH, BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote: [] > Are you sure that the outputs are true sine and cosine? The analog > output, optical devices I have worked with, output trapezoidal waveforms > with a phase shift similar to sine/cosine. The input signals are specified as sine/cosine. We do not perform system integration therefore would be up to the system engineer who specified the interfaces to make sure box A can talk to box B,Article: 156797
On Sat, 28 Jun 2014 23:16:01 +0000, alb wrote: > Hi Tim, > > In comp.arch.fpga Tim Wescott <tim@seemywebsite.please> wrote: > [] >>> 1. how do I prove I need a dither generator? Indeed we didn't have >>> even >>> the time to figure out if we really need it. Is there a dedicated >>> test I can perform which may undoubtly confirm the need? >> >> Calculate the worst-case inaccuracy in position due to quantization >> errors. This will be at a point where one ADC is reading maximum or >> minimum, and the other one is reading close to it's center point. If >> that inaccuracy if small enough to not cause you problems, then you're >> golden. > > The precision we have on the position can be directly transformed into > angular precision: > > A = A0 + A1*sin(2*pi*opd/lambda) > B = B0 + B1*cos(2*pi*opd/lambda + psi) > > where A/B are the sine/cosine signals, opd is the optical path > difference (position in nm), lambda is the optical frequency (1550 nm) > and psi a phase shift. With a precision in position of 20nm we have to > have a precision in the phase accumulator which is of the order of > 20/1550*2*pi ~4 deg (.00022 radian). 4 degrees is more like 0.06 radians. And 20 / (1550 * 2 * pi) is roughly 0.005 radians, if I'm doing the math right in my head (do double check with a calculator). > But it looks to me a bit too big as a precision on a very sensitive > optical mechanism... According to my calculations the 4 deg error > corresponds to a normalized signal (A0/B0 removed and A1/B1 > renormalized) of nearly 10% full scale... I guess something is wrong in > my calculations! > > I guess though precision is not the only factor to take into account. > While I can drive the motor precisely, it does not mean that I drive it > smoothly instead might be rather jerky if I allow spourious frequencies > to get out. > > >> If you don't know how small an error you need, then you must analyze >> your control loop, or you must build the system and give it a whirl. >> As a rule of thumb, your allowed quantization step should be about 1/4 >> or less of the desired precision of the axis, and it must be small >> enough that the quantization noise going into the derivative term in >> your controller does not heat up your motor or final amplifier, or >> cause undue power drain. > > But how can I hit the quantization error? Shall I consider a particular > frequency for my sine/cosine waveform? IIRC quantization errors show up > especially in submultiple of the ADC sampling frequency. In closed-loop systems it's usually best to treat quantization errors as an injected noise signal at the worst possible frequency. So you should analyze the loop for its response to a signal injected at the ADC, and you should see if the response to noise at the level of the quantization error and at that worst-case frequency is going to cause you a problem. >> Also, look at the ADC data sheets. If the internal noise from the ADC >> is greater than 1 LSB (it usually is for ADCs of more than 14 bits or >> so) then you're getting dither generated for you for absolutely free. >> In that case you may need to oversample the ADCs and average their >> outputs anyway, to avoid noise issues. > > That is a good hint. I have an ENOB of 11.1, so in principle I have less > than 1LSB noise for both distortion and noise... Be careful with ENOB numbers. Sometimes they're measured assuming that you're doing some averaging. Also, it looks like your input to the ADCs may have its own dither -- when you're dealing with quantization noise, random noise is actually your friend, because random noise can be averaged out, where quantization noise cannot. >>> 2. how the dither generator noise spectrum should look like? I've read >>> about both in-band and out of band dither but I'm still confused. >> >> That depends on how complicated you want to get. In general dither is >> only going to do you any good if you accompany it by oversampling and >> decimating. > > We are sampling at 250KSps a signal which is from DC to 4KHz... I'm > wondering even why we are sampling with such a rate. Anyway it seems > that decimating may be easily achieved. > >> In that case you'd either like the dither to be out of band, >> which you can approximate pretty well with a sigma-delta modulator on >> the dither signal, or you'd like the dither to be periodic, in which >> case you'd sample the raw ADC synchronously with updating the dither, >> and you'd average the ADC readings and decimate synchronous with the >> periodicity of the dither. > > Being out of band would save me additional logic I guess. Indeed I can > make it such to be filtered by the tracking demodulator. > >>> 3. any reference for such generators on FPGA? A long LFSR (say 64bit) >>> and only 4 pin used might seem silly, but is simple. OTOH I read >>> LFSR do not provide random enough patterns therefore introducing >>> other issues. >> >> If you oversample by a factor of 16, and if your four FPGA pins go >> through weighting resistors to make a 4-bit DAC, then just count from 0 >> to 15 and repeat. Unless you're driving an RC filter to your Vref you >> won't be able to do better than that. > > wouldn't that harmonic be affecting my tracking demodulator? If you average and decimate synchronously with the dither signal, then the dither signal would not show up in your decimated signal. >>> [1] by tracking demodulation. >> >> I would capture the correct number by doing an arctan of the ADC >> inputs. > > This is something I'm also wondering. Offset and renormalization are > steps which need to be done anyway, but instead of a tracking > demodulator the atan may be very simple, no loop required, no cutoff > frequency...just plain easy. What about if your signals have a small > phase shift? Then you'll have the same difficulty with you tracking generator as you would taking the atan. If the signals have a small known phase shift, you can get the correct orthogonal pair by a linear transformation (work out the math). > Truth is that if the phase shift error induced is not that large I could > throw away the demodulator and live with the arctan... > >> This has worked well for me in the past, in software. You'll probably >> want to calculate the arctan using CORDIC or some other FPGA-ish >> method, but that's a nit. > > We are doing this in hardware and indeed we could have a look at the > performances of the CORDIC to be used in our demodulator. Up to now > nobody really looked at how we could optimize the algorithm. > > Al -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 156798
Hi Tim, Tim Wescott <tim@seemywebsite.please> wrote: [] >> where A/B are the sine/cosine signals, opd is the optical path >> difference (position in nm), lambda is the optical frequency (1550 nm) >> and psi a phase shift. With a precision in position of 20nm we have to >> have a precision in the phase accumulator which is of the order of >> 20/1550*2*pi ~4 deg (.00022 radian). > > 4 degrees is more like 0.06 radians. oops I must have hit a wrong number, you are right, 4 deg *is not* .00022 radians. > > And 20 / (1550 * 2 * pi) is roughly 0.005 radians, if I'm doing the math > right in my head (do double check with a calculator). Well, I guess we both made a mistake. Given the definition of A: A = A0 + A1*sin(2*pi*opd/lambda) and a precision on opd of 20nm @ lambda=1550nm means an angular precision of: debian@debian:~$ echo '20/1550' | bc -l .01290322580645161290 in radians, or: debian@debian:~$ echo '180/(4*a(1))*20/1550' | bc -l .73930038081396543067 in degrees, which makes a little more sense w.r.t. the 4 degs I came out with earlier. [] >> But how can I hit the quantization error? Shall I consider a particular >> frequency for my sine/cosine waveform? IIRC quantization errors show up >> especially in submultiple of the ADC sampling frequency. > > In closed-loop systems it's usually best to treat quantization errors as > an injected noise signal at the worst possible frequency. So you should > analyze the loop for its response to a signal injected at the ADC, and > you should see if the response to noise at the level of the quantization > error and at that worst-case frequency is going to cause you a problem. So a sine with 1LSB amplitude at a submultiple of sampling frequency, I guess that would be the worst case you are referring to, is that right? [] >> I have an ENOB of 11.1, so in principle I have less than 1LSB noise >> for both distortion and noise... > > Be careful with ENOB numbers. Sometimes they're measured assuming that > you're doing some averaging. Also, it looks like your input to the ADCs > may have its own dither -- when you're dealing with quantization noise, > random noise is actually your friend, because random noise can be > averaged out, where quantization noise cannot. That is clear, unfortunately the incoming signal has no noise figure, instead a THD is specified. [] >>> I would capture the correct number by doing an arctan of the ADC >>> inputs. >> >> This is something I'm also wondering. Offset and renormalization are >> steps which need to be done anyway, but instead of a tracking >> demodulator the atan may be very simple, no loop required, no cutoff >> frequency...just plain easy. What about if your signals have a small >> phase shift? > > Then you'll have the same difficulty with you tracking generator as you > would taking the atan. If the signals have a small known phase shift, > you can get the correct orthogonal pair by a linear transformation (work > out the math). I had the impression the tracking demodulator was not as sensitive to the phase shift (I took for granted), but I guess I'm wrong since lately we simulated the result with a phase shift bigger than specified and the demodulator went bananas! Unfortunately the phase shift is not known, but indeed a phase shift is easy to estimated with a phase detector and corrected for with the CORDIC (in rotation mode). The signal has a max. frequency of 4KHz when the motor is moving at full throttle and we are sampling at 250KSps, it means my phase correction cannot be better than 360/(250/4) ~5.7 deg. But I guess that phase shift comes mainly from the feedback sensors relative position so should not change in time. If the motor is slowly moving we can have a much more precise measurement of the phase shift and correct for it. Is that too naive? The atan approach is in openloop and is seems easily implemented with two CORDIC, one for the phase shift correction and one for the atan...The offset removal and renormalization will still be needed though.Article: 156799
On Sun, 29 Jun 2014 07:58:50 -0700, BobH wrote: > On 6/28/2014 7:39 AM, alb wrote: >> Hi there, >> >> we are measuring from a quadrature encoder the raw sine and cosine and >> need to extract the angular position [1]. The position is then fedback >> to a PID which drives a motor. > > Are you sure that the outputs are true sine and cosine? The analog > output, optical devices I have worked with, output trapezoidal waveforms > with a phase shift similar to sine/cosine. Interesting. I've worked on transmissive optical quadrature encoders that specified a sine wave output. In the OP's case, he's computing an output based on the wavelength of a reference source, which leads me to believe that there's some sort of interferometry going on, which would be sinusoidal because that's what the peaks and valleys of the light are going to be. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
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