Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 156775

Article: 156775
Subject: Re: A new domain for FPGAs ? Function approximation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 24 Jun 2014 20:53:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen




Article: 156776
Subject: Re: A new domain for FPGAs ? Function approximation
From: jonesandy@comcast.net
Date: Tue, 24 Jun 2014 14:07:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 156777
Subject: A free VHDL simulator
From: Thorsten Kiefer <thorstenkfr@googlemail.com>
Date: Tue, 24 Jun 2014 15:48:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Any suggestions ?

-Thorsten

Article: 156778
Subject: Re: A new domain for FPGAs ? Function approximation
From: Thorsten Kiefer <thorstenkfr@googlemail.com>
Date: Tue, 24 Jun 2014 15:49:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 156779
Subject: Re: A free VHDL simulator
From: Nikolaos Kavvadias <nikolaos.kavvadias@gmail.com>
Date: Tue, 24 Jun 2014 16:05:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi 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.com

Article: 156780
Subject: Re: PLA? PAL? PLD? GAL?
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Jun 2014 00:18:01 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 156781
Subject: Re: A new domain for FPGAs ? Function approximation
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Jun 2014 00:35:29 -0400
Links: << >>  << T >>  << A >>
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: 156782
Subject: Re: A free VHDL simulator
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 25 Jun 2014 11:05:31 GMT
Links: << >>  << T >>  << A >>
On 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.

- Brian

Article: 156783
Subject: Re: problem with xc3s400 place and rout section
From: "nba83" <12020@embeddedrelated>
Date: Wed, 25 Jun 2014 06:36:25 -0500
Links: << >>  << T >>  << A >>
>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

Article: 156784
Subject: Re: problem with xc3s400 place and rout section
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 25 Jun 2014 10:05:46 -0400
Links: << >>  << T >>  << A >>
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

-- 
Gabor

Article: 156785
Subject: Re: problem with xc3s400 place and rout section
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 25 Jun 2014 18:40:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
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. 

-- glen

Article: 156786
Subject: Re: problem with xc3s400 place and rout section
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Jun 2014 16:06:09 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 156787
Subject: Re: A free VHDL simulator
From: "mnentwig" <24789@embeddedrelated>
Date: Wed, 25 Jun 2014 15:50:55 -0500
Links: << >>  << T >>  << A >>
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

Article: 156788
Subject: Re: problem with xc3s400 place and rout section
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 25 Jun 2014 20:52:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 156789
Subject: Re: problem with xc3s400 place and rout section
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Jun 2014 17:53:47 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 156790
Subject: Re: A free VHDL simulator
From: Thorsten Kiefer <thorstenkfr@googlemail.com>
Date: Wed, 25 Jun 2014 22:08:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Thorsten

Article: 156791
Subject: Re: A free VHDL simulator
From: Brian Drummond <brian3@shapes.demon.co.uk>
Date: Thu, 26 Jun 2014 09:07:04 GMT
Links: << >>  << T >>  << A >>
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/

- Brian

Article: 156792
Subject: [cross-post] dither generator on fpga
From: al.basili@gmail.com (alb)
Date: 28 Jun 2014 14:39:49 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: [cross-post] dither generator on fpga
From: Tim Wescott <tim@seemywebsite.please>
Date: Sat, 28 Jun 2014 10:38:48 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 156794
Subject: Re: [cross-post] dither generator on fpga
From: al.basili@gmail.com (alb)
Date: 28 Jun 2014 23:16:01 GMT
Links: << >>  << T >>  << A >>
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.

Al

Article: 156795
Subject: Re: [cross-post] dither generator on fpga
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Sun, 29 Jun 2014 07:58:50 -0700
Links: << >>  << T >>  << A >>
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.

BobH



Article: 156796
Subject: Re: [cross-post] dither generator on fpga
From: al.basili@gmail.com (alb)
Date: 29 Jun 2014 15:30:17 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: [cross-post] dither generator on fpga
From: Tim Wescott <tim@seemywebsite.please>
Date: Sun, 29 Jun 2014 11:16:40 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 156798
Subject: Re: [cross-post] dither generator on fpga
From: al.basili@gmail.com (alb)
Date: 29 Jun 2014 18:01:01 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: [cross-post] dither generator on fpga
From: Tim Wescott <tim@seemywebsite.really>
Date: Sun, 29 Jun 2014 23:19:15 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search