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 132075

Article: 132075
Subject: Re: Problem writing quadrature decoder
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 12 May 2008 14:15:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 12, 1:46=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> Jim Granville wrote:
>
> <snip>> It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as
>
> > count<2>.T :=3D rQuad<1> * !count<1> * !count<0>
> > =A0 =A0 =A0 # =A0!rQuad<1> * !rQuad<0> * =A0count<1> * count<0>;
> > count<2>.CLK =A0=3D =A0clk; =A0 =A0 =A0 =A0// GCK
>
> > (etc) for all higher bits
>
> <snip>
>
> Typos corrected, "+" changed to "*" where "*" is and while "#" is or.
>
> For the upper bits, the down count will happen when the rQuad is
> behind the count by 1 or 2 phases and the count[1:0] is 00 and the up
> count will happen when the rQuad is in front of the count by 1 phase
> and the count[1:0] is 11. =A0Because the logic you're using is a toggle,
> the upper bits will only change when the count[1:0] is 00 and the
> rQuad is 10 or 11 (down) or the count[1:0] is 11 and the rQuad is 00
> (up).
>
> This matches your (de-typoed) logic above.
>
> Since the count is used to judge the retained quadrant rather than a
> registered version of the quadrature inputs, the up/down toggle points
> work in nicely with the quadrant detection.
>
> - John_H

This is a general comment:
It was said that you can just "ignore the counter LSBs" if they bother
you. That is not true. Imagine the counter oscillating between 99 and
100 (if it were decimal) or between FFF and 1000. That would be pretty
upsetting.
Wow, we got the thread-count up to 63. Isn't it amazing. Never has so
much been argued (in a friendly way) about so little...
Peter

Article: 132076
Subject: Programming XCR3064xl - voltage at output stuck at 0
From: xcr3064xl <xc3064@gmail.com>
Date: Mon, 12 May 2008 14:30:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am programming Xilinx xcr3064xl device:
http://www.xilinx.com/support/documentation/data_sheets/ds017.pdf


I use the simplest possible code to drive output pins, i.e.  I simply
assign one or zero, for example:
	P43 <= '1';
or
	P43 <= '0';

The pin is mapped in an UCF file:
	NET "P43" LOC="P43" ;


It looks like whether I assign '1' or '0' makes no difference.  After
programming the voltage at the PIN is stuck at 0.01V

However, when I comment out the assignment (i.e. nothing is driving
the
pin), then the voltage goes up to approx 2.3 (that's a pull up I
guess).

The question is why
	P43 <= '1';
does not work?

VCC is 3.3V


I have tested this with two xcr3064xl devices and two programming
cables
and I did it for different pins.  Can anyone explain what is going on?

I also used an XC2XL development board by Digilient:
http://www.digilentinc.com/Products/Detail.cfm?Prod=XC2XL&Nav1=Products&Nav2=Programmable
This board contains two devices:
	- Xilinx CoolRunner-II XC2C256 CPLD
	- Xilinx XC9572XL CPLD
There were no such problems with this board/devices; everything
worked as expected. What can I be doing wrong with xcr3064xl?

K.

Article: 132077
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 09:35:32 +1200
Links: << >>  << T >>  << A >>
More info:

Jim Granville wrote:

> John_H wrote:
>> Does your synth produce an enable for each register, too?  Forcing an 
>> enable (count[1:0]!=quad) might clarify the operation a little from a 
>> human-readable standpoint.
> 
> 
> No, strange thing is ONE direction seems plausible, but the other dirn
> seems wrong.... ?
> (This was Xilinx webpack)
> What does your report say ?

Looks like a Xilinx tool bug ?
If I create a node for either dir, or dir and CEnable, then it
changes, and Webpack seems to cope better.
[ perhaps the code is too terse for it ;) ]

It creates a (bizarely named) pair of clock enables, that are
now symmetric, and look plausible.

rQuad<1> := quad<1>;
rQuad<0> := quad<0>;

dir = count<1>
     $ count<0> * !rQuad<0>
     # !count<0> * rQuad<1>;

--Created node, seems to be CE_DOWN
rQuad<0>.COMB =  !count<0> * !count<1> * rQuad<1> * dir
	      # !count<0> * !count<1> * rQuad<0> * dir;

--Created node, seems to be CE_UP
rQuad<1>.COMB =  count<0> * count<1> * !rQuad<1> * !dir
	      # count<0> * count<1> * rQuad<0> * !dir;


count<3>.T := rQuad<0>.COMB * !count<2>
	   # rQuad<1>.COMB * count<2>;

Given rQuad<1> is a Quad registered input, seeing rQuad<1>.COMB
used as something tool-created, is strange....

Wonder what a brand new Xilinx tool chain does here....?

-jg





Article: 132078
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 09:43:56 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Wow, we got the thread-count up to 63. Isn't it amazing. Never has so
> much been argued (in a friendly way) about so little...

Not only that: the 'so little' is reducing even more, as the
register count is falling ;)

-jg


Article: 132079
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 09:55:07 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> Jim Granville wrote:
> <snip>
> 
>>It Created Logic on Count (above the 2 LSB's) BOOLEAN EQNS as
>>
>>count<2>.T := rQuad<1> * !count<1> * !count<0>
>>	   #  !rQuad<1> * !rQuad<0> *  count<1> * count<0>;
>>count<2>.CLK  =  clk;	// GCK
>>
>>(etc) for all higher bits
> 
> <snip>
> 
> Typos corrected, "+" changed to "*" where "*" is and while "#" is or.
> 
> For the upper bits, the down count will happen when the rQuad is
> behind the count by 1 or 2 phases and the count[1:0] is 00 and the up
> count will happen when the rQuad is in front of the count by 1 phase
> and the count[1:0] is 11.  

Ah, yes - I missed the 2-phase instance. In my code, only
one-quadrant is used for count, and a 2 quadrant delta is ignored
by MSBs and can be flagged as an error.
LSBs lock on the next clock.

It could be the 2 quadrant instance is also contained in here, just not
so visible ?

dir = count<1>
	$ count<0> * !rQuad<0>
	# !count<0> * rQuad<1>;

rQuad<1>.COMB =  count<0> * count<1> * !rQuad<1> * !dir
	   # count<0> * count<1> * rQuad<0> * !dir;

rQuad<0>.COMB =  !count<0> * !count<1> * rQuad<1> * dir
	   # !count<0> * !count<1> * rQuad<0> * dir;

Which brings the question: How would you recode your version to
Trap a 2 Quadrant error and not propogate a MSB count on it ?

-jg




Article: 132080
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 09:58:21 +1200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Looks like a Xilinx tool bug ?

No. John has pointed out the 2-quad delta in his code causes a clock,
so the eqn result is not as symmetric as I was expecting. PBKAC.

> If I create a node for either dir, or dir and CEnable, then it
> changes, and Webpack seems to cope better.
> 
> It creates a (bizarely named) pair of clock enables, that are
> now symmetric, and look plausible.

Likely behaves the same, just the 2-quad case is less visible.. ?

-jg


Article: 132081
Subject: Re: Problem writing quadrature decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 12 May 2008 15:27:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jim Granville wrote:
<snip>
>
> Which brings the question: How would you recode your version to
> Trap a 2 Quadrant error and not propogate a MSB count on it ?
>
> -jg

I hope you agree that the original upper bits were performing
properly.  The LSbits can carry through from a similar argument, I
imagine.  Just figure the four count[1:0] quadrants in order are 00,
01, 10, and 11 while the corresponding rQuad quadrants are 00, 01, 11,
and 10.  If these were LUTs and not counters, the 2 LSbits would be
entirely dependent on rQuad and count[1:0] in one level of 4-input LUT
logic.

There should be NO illegal codes in a properly working system after
initialization.  I use the starting quadrature input phase to move the
starting count to a range of -2 to +1, inclusive.  During this init,
the "illegal" phase will help move a 180 degree out-of-phase starting
code to a count of -2.  After this init, any instance of 180 degrees
out of phase (((rQuad-count[1:0])&2'h3)==2'h2) is an illegal code and
CANNOT be properly interpreted.  The illegal code could set a flag but
only after the first few clocks of the initialization have fed through
the system.  It might be the best way to gate the signal is to use the
first time the count is outside the -2 to +1 initialization range.

I don't know the proper way to apply a "preserve" attribute in XST to
guarantee that these flops don't get optimized to high steady states
independent of the init state with the opposite "reg name=1'b0;"
Synplify may not yet support this form of register initialization
though XST tries to do the right thing.

reg gate = 1'b0;
reg err = 1'b0;
always @(posedge clk)
begin
  if( count>8'h1 & count < 8'hfe )  gate <= 1'b1;
  if( gate & ( ((rQuad-count[1:0])&2'h3)==2'h2 ) ) err <= 1'b1;
end

The err does not reset in this code snippet.

- John_H

Article: 132082
Subject: Re: Programming XCR3064xl - voltage at output stuck at 0
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 10:54:20 +1200
Links: << >>  << T >>  << A >>
xcr3064xl wrote:
> I am programming Xilinx xcr3064xl device:
> http://www.xilinx.com/support/documentation/data_sheets/ds017.pdf
> 
> 
> I use the simplest possible code to drive output pins, i.e.  I simply
> assign one or zero, for example:
> 	P43 <= '1';
> or
> 	P43 <= '0';
> 
> The pin is mapped in an UCF file:
> 	NET "P43" LOC="P43" ;
> 
> 
> It looks like whether I assign '1' or '0' makes no difference.  After
> programming the voltage at the PIN is stuck at 0.01V
> 
> However, when I comment out the assignment (i.e. nothing is driving
> the
> pin), then the voltage goes up to approx 2.3 (that's a pull up I
> guess).
> 
> The question is why
> 	P43 <= '1';
> does not work?
> 
> VCC is 3.3V
> 
> 
> I have tested this with two xcr3064xl devices and two programming
> cables
> and I did it for different pins.  Can anyone explain what is going on?
> 
> I also used an XC2XL development board by Digilient:
> http://www.digilentinc.com/Products/Detail.cfm?Prod=XC2XL&Nav1=Products&Nav2=Programmable
> This board contains two devices:
> 	- Xilinx CoolRunner-II XC2C256 CPLD
> 	- Xilinx XC9572XL CPLD
> There were no such problems with this board/devices; everything
> worked as expected. What can I be doing wrong with xcr3064xl?
> 
> K.

- What does the fitter report file say ?
- Does the fuse-file change with the two compile choices ?
- You could try something a little more complex : PinA = !PinB
   and see what that does ?.
It's hazy, but ISTR issues with XCR devices and static pin
defines (or similar) ?

-jg



Article: 132083
Subject: Re: How to input an analog signal to FPGA board for processing?
From: Andy Peters <google@latke.net>
Date: Mon, 12 May 2008 16:51:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 11, 11:53 pm, Vagant <vladimir.v.koroste...@rambler.ru> wrote:
> Hello,
> I am a beginer and have a basic question.
> My project implemented on FPGA board (which is Spartan3E-1600
> Microblaze Development Kit) includes ADC and is supposed to do some
> digital signal processing of an analog RF signal from 'outside
> world'.
> How I can input an analog signal to my FPGA?

Do you have the manual for the board? Hint: it's Xilinx p/n UG257.

The section "Analog Capture Circuit" starts on Page 75 of That Fine
Document.

Header J7, which is a bog standard 0.1"-center pin strip, is the input
to the two ADCs.

You'll probably have to make a cable or adapter so you can use those
pins. If you are incapable of making such an adapter, you probably
shouldn't be messing around with FPGAs.

-a

Article: 132084
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 12:52:42 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> Jim Granville wrote:
> <snip>
> 
>>Which brings the question: How would you recode your version to
>>Trap a 2 Quadrant error and not propogate a MSB count on it ?
>>
>>-jg
> 
> 
> I hope you agree that the original upper bits were performing
> properly.  The LSbits can carry through from a similar argument, I
> imagine.  Just figure the four count[1:0] quadrants in order are 00,
> 01, 10, and 11 while the corresponding rQuad quadrants are 00, 01, 11,
> and 10.  If these were LUTs and not counters, the 2 LSbits would be
> entirely dependent on rQuad and count[1:0] in one level of 4-input LUT
> logic.

Correct, but it seems to vary
- My Code uses just 1 and 2 Product terms, because I split the 2 LSB out
and effectively code binQuad = {rQuad[1],^rQuad[1:0]} in registers.
( which has an implicit next-clock-lock )
- but my code is more lines, and 'splits' the counter, which is
not as 'visually appealing' :)

- Your code compiles to either 4.TFF & 6.TFF PT, with a DIRN node or
4.TFF & 3.DFF  PT on  no Dirn node.
- which I think is the +2 complicating things ?

I think the problem is fundamental : with one counter line,
if you code to remove the +2 case, you do not sync, but leaving it
in, means you propogate an error.... :(

I suppose you could rule that it WILL sync on the next quad click,
and so that could be tolerable, to allow just +/-1 ?
(effectively this is a hold-on-illegal ?)

> 
> There should be NO illegal codes in a properly working system after
> initialization.  I use the starting quadrature input phase to move the
> starting count to a range of -2 to +1, inclusive.  During this init,
> the "illegal" phase will help move a 180 degree out-of-phase starting
> code to a count of -2.  After this init, any instance of 180 degrees
> out of phase (((rQuad-count[1:0])&2'h3)==2'h2) is an illegal code and
> CANNOT be properly interpreted.  

It could be a sensor error, or a rate error (clk too slow), which
is why I am keen to catch it.

-jg



Article: 132085
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 13:17:32 +1200
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> I suppose you could rule that it WILL sync on the next quad click,
> and so that could be tolerable, to allow just +/-1 ?
> (effectively this is a hold-on-illegal ?)

Using this rule, I re-coded as

wire OutByOne = ( count[1:0]-binQuad == 2'b01 )
               | ( binQuad-count[1:0] == 2'b01 );
   always @(posedge clk)
   begin
     rQuad <= quad;
     if ( OutByOne )
       count <= count + (dir ? -8'h1 : +8'h1);
   end

and this compiles to identical MSBs, and
LSBs of Count0 = 2PT.DFF and Count1 = 4PT.TFF
and this code I think can only ever INC or DEC the
counter by one.

So we have achieved one counter line, and no count at all on illegal
(an improvement over my Auto-sync which would snap the 2 LSBs on error)
- minor point, as Error state is rare.
The slight hike in resource, is probably worth it ?

-jg



Article: 132086
Subject: Re: Problem writing quadrature decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 12 May 2008 18:58:11 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> Jim Granville wrote:
>>
>> I suppose you could rule that it WILL sync on the next quad click,
>> and so that could be tolerable, to allow just +/-1 ?
>> (effectively this is a hold-on-illegal ?)
> 
> Using this rule, I re-coded as
> 
> wire OutByOne = ( count[1:0]-binQuad == 2'b01 )
>               | ( binQuad-count[1:0] == 2'b01 );
>   always @(posedge clk)
>   begin
>     rQuad <= quad;
>     if ( OutByOne )
>       count <= count + (dir ? -8'h1 : +8'h1);
>   end
> 
> and this compiles to identical MSBs, and
> LSBs of Count0 = 2PT.DFF and Count1 = 4PT.TFF
> and this code I think can only ever INC or DEC the
> counter by one.
> 
> So we have achieved one counter line, and no count at all on illegal
> (an improvement over my Auto-sync which would snap the 2 LSBs on error)
> - minor point, as Error state is rare.
> The slight hike in resource, is probably worth it ?
> 
> -jg

There is NO protection from illegal states.  If you get an illegal state 
because BOTH input channels have flipped polarity, the first input that 
comes back to correct polarity might not be the correct one giving you a 
count of -1 instead of +1 that should occur; the bouncing continues, 
possibly coming back through the original phase back to where it SHOULD 
have been with the +1 count but with a -3 instead.  There CANNOT be 
protection from the illegal state, only an indicator that it happened.

If the 180 degree phase difference is removed from the init in my code, 
the 180 degree difference will stay until a change in the encoder 
finally happens.  I'd recommend keeping the "illegal code" treatment as 
a negative step of 1 for init purposes.  That is the ONLY time it SHOULD 
occur.

- John

Article: 132087
Subject: Re: Programming XCR3064xl - voltage at output stuck at 0
From: Dave Pollum <vze24h5m@verizon.net>
Date: Mon, 12 May 2008 19:02:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 12, 4:30 pm, xcr3064xl <xc3...@gmail.com> wrote:
> I am programming Xilinx xcr3064xl device:http://www.xilinx.com/support/documentation/data_sheets/ds017.pdf
>
> I use the simplest possible code to drive output pins, i.e.  I simply
> assign one or zero, for example:
>         P43 <= '1';
> or
>         P43 <= '0';
>
> The pin is mapped in an UCF file:
>         NET "P43" LOC="P43" ;
>
> It looks like whether I assign '1' or '0' makes no difference.  After
> programming the voltage at the PIN is stuck at 0.01V
>
> However, when I comment out the assignment (i.e. nothing is driving
> the
> pin), then the voltage goes up to approx 2.3 (that's a pull up I
> guess).
>
> The question is why
>         P43 <= '1';
> does not work?
>
> VCC is 3.3V
>
> I have tested this with two xcr3064xl devices and two programming
> cables
> and I did it for different pins.  Can anyone explain what is going on?
>
> I also used an XC2XL development board by Digilient:http://www.digilentinc.com/Products/Detail.cfm?Prod=XC2XL&Nav1=Produc...
> This board contains two devices:
>         - Xilinx CoolRunner-II XC2C256 CPLD
>         - Xilinx XC9572XL CPLD
> There were no such problems with this board/devices; everything
> worked as expected. What can I be doing wrong with xcr3064xl?
>
> K.

For you 3064XL's that aren't working, are the power and ground wiring
the same as the Digilent board?  Do you have bypass caps the same as
or similar to the Digilent board?  If your problem chip is a PC44
package, then pin 43 is an input-only pin.  Pick another pin that can
do I/O.

-Dave Pollum

Article: 132088
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 14:39:37 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> Jim Granville wrote:
> 
>> Jim Granville wrote:
>>
>>>
>>> I suppose you could rule that it WILL sync on the next quad click,
>>> and so that could be tolerable, to allow just +/-1 ?
>>> (effectively this is a hold-on-illegal ?)
>>
>>
>> Using this rule, I re-coded as
>>
>> wire OutByOne = ( count[1:0]-binQuad == 2'b01 )
>>               | ( binQuad-count[1:0] == 2'b01 );
>>   always @(posedge clk)
>>   begin
>>     rQuad <= quad;
>>     if ( OutByOne )
>>       count <= count + (dir ? -8'h1 : +8'h1);
>>   end
>>
>> and this compiles to identical MSBs, and
>> LSBs of Count0 = 2PT.DFF and Count1 = 4PT.TFF
>> and this code I think can only ever INC or DEC the
>> counter by one.
>>
>> So we have achieved one counter line, and no count at all on illegal
>> (an improvement over my Auto-sync which would snap the 2 LSBs on error)
>> - minor point, as Error state is rare.
>> The slight hike in resource, is probably worth it ?
>>
>> -jg
> 
> 
> There is NO protection from illegal states.  If you get an illegal state 
> because BOTH input channels have flipped polarity, the first input that 
> comes back to correct polarity might not be the correct one giving you a 
> count of -1 instead of +1 that should occur; the bouncing continues, 
> possibly coming back through the original phase back to where it SHOULD 
> have been with the +1 count but with a -3 instead.  There CANNOT be 
> protection from the illegal state, only an indicator that it happened.

Correct (I said similar earlier) which is why I prefer to flag it
as well, - the hold-on-illegal suggests you _missed_ an edge, but have 
no way of knowing if it was CW or CCW.
A novice might not realise there even ARE illegal states.

In a FPGA with trucklods of resource, you could run an Error counter,
and read it periodically as a sensor integrity check.

> If the 180 degree phase difference is removed from the init in my code, 
> the 180 degree difference will stay until a change in the encoder 
> finally happens.  I'd recommend keeping the "illegal code" treatment as 
> a negative step of 1 for init purposes.  That is the ONLY time it SHOULD 
> occur.

It's a philosphy thing I guess, I prefer to keep any error away from
the counter, and think the one-click to lock at power up, is no
real problem - a Quad system always has power up problems anyway.

It gets moot, because a system with frequent errors needs remedy
either way!.

A user might complain more about a double-step (which they will see)
than a late-step
(which they will hardly notice a few degrees on a knob?

Peter's Anti-Jitter block can bolt on the front of any of these, if
you want to avoid flicker effects.

-jg



Article: 132089
Subject: xsa-50 issues
From: uche <uraniumore235@hotmail.com>
Date: Mon, 12 May 2008 19:55:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
hey guys,

i have an xsa-50 board by xess. i ran into some issues when trying to
test the board using the GXTEST software tool that i downloaded and
nothing works. in the past, i used the board and everything ran fine.
i get an error saying "the interface CPLD of your XSA Board is not
responding!!" I have checked the power source and and downloading
cable.
please help asap.

thanks,
uchenna

Article: 132090
Subject: Re: Problem writing quadrature decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 12 May 2008 20:36:00 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
<snip>
> 
> Correct (I said similar earlier) which is why I prefer to flag it
> as well, - the hold-on-illegal suggests you _missed_ an edge, but have 
> no way of knowing if it was CW or CCW.
> A novice might not realise there even ARE illegal states.
<snip>

There ARE NO illegal states unless the system is very hosed such as the 
extreme shock problems mentioned earlier.  If the system is being jarred 
to that degree, the count will make no sense especially if the bounce is 
many 10s (100s?) of bogus transitions on both channels.

There is no missing an edge because it isn't edges we're tracking, it's 
quadrants.  As long as the encoder visits each quadrant there will be NO 
missed counts and therefor no post-init illegal states.

I allow the phase difference between the quad inputs and the count of 
180 degrees on startup to transition to the count of -2 in a stable manner.

- John_H

Article: 132091
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 13 May 2008 17:48:21 +1200
Links: << >>  << T >>  << A >>
John_H wrote:

> Jim Granville wrote:
> <snip>
> 
>>
>> Correct (I said similar earlier) which is why I prefer to flag it
>> as well, - the hold-on-illegal suggests you _missed_ an edge, but have 
>> no way of knowing if it was CW or CCW.
>> A novice might not realise there even ARE illegal states.
> 
> <snip>
> 
> There ARE NO illegal states unless the system is very hosed such as the 
> extreme shock problems mentioned earlier.  

Correct: A correctly operating, Quadrature encoder with good clk margin, 
should have no illegal states.

> If the system is being jarred 
> to that degree, the count will make no sense especially if the bounce is 
> many 10s (100s?) of bogus transitions on both channels.

Also, if your sensor is damaged/worn/dirty, then this will be one way to 
sense that.

> 
> There is no missing an edge because it isn't edges we're tracking, it's 
> quadrants.  As long as the encoder visits each quadrant there will be NO 
> missed counts and therefor no post-init illegal states.

Suppose the CLK is too slow, relative to the Quad signals ?

Now, you WILL have a 'missing edge', and as CLK freq is
a design choice, knowing you have made an error is a good
thing :)

This is a real-word interface, and the real-world can throw
some failure modes into the mix....

I'm looking for an encoder that uses SPCO contacts,
(allows micro-power encoder), but that seems to be unobtanium.

-jg






Article: 132092
Subject: Re: 5 V oscillator output to GCLK
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 13 May 2008 00:01:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Mai, 23:33, Jon Elson <el...@wustl.edu> wrote:
>  A long clock trace (bad idea, anyway) fed with a series resistor is essentially
> a lumped-constant low-pass filter.

No. It is a transmission line with an impedance matched driver. You
can get any
frequency accross that setup that you like.


>  I'm not sure how fast Spartan III
> is, but if the Tr got slowed to tens of nS it would be really dangerous.

The setup will not change the rise time of the signal. The slew rate
will be halved,
because the voltage swing is halved, but that's it.
The receiver will see the same waveform as the source with halve the
voltage.

But other posters where correct with noting that the oscillator needs
to be capable
to drive a 100R transmission line, which might not be the case.

Kolja Sulimma

Article: 132093
Subject: Re: Problem with PlanAhead on Partial Reconfiguration on ML403
From: G_Abgrall <Gael.Abgrall@gmail.com>
Date: Tue, 13 May 2008 00:29:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Up ?

Excuse me but I still have this problem and it's very important for me
to work with PlanAhead.

Regards,

Gael Abgrall.

Article: 132094
Subject: Re: Problem writing quadrature decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 13 May 2008 06:10:35 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
<snip>
> 
> Suppose the CLK is too slow, relative to the Quad signals ?
> 
> Now, you WILL have a 'missing edge', and as CLK freq is
> a design choice, knowing you have made an error is a good
> thing :)

Consider a shaft running at an outrageous 100k rpm and a 1024 phase per 
revolution encoder.  That's about 1.6 MHz to guarantee operation.  Of 
someone shooses to use a slower clock, they sure aren't doing their job. 
  An error indicator isn't going to help much in that situation.  It's a 
little like having a warning system in your shoe that says "your foot is 
on fire."  Is it really useful?  Sure it could happen, but come on....

> This is a real-word interface, and the real-world can throw
> some failure modes into the mix....
> 
> I'm looking for an encoder that uses SPCO contacts,
> (allows micro-power encoder), but that seems to be unobtanium.
> 
> -jg

Rather than exotic metal contacts, how about using an optical encoder? 
It's hard to bounce 2 channels of light at the same time.

- John_H

Article: 132095
Subject: Re: Virtex XCV1000E-6FG860C
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 13 May 2008 09:54:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 8, 10:26=A0am, jon <j...@pyramidemail.com> wrote:
> Need help on =A0a Virtex XCV1000E-6FG860C . I am short 500 pieces and
> the only parts I see are coming from China brokers. Please call with
> any quantity that you can supply. I need them ASAP.
>
> Jon E. Hansen
>
> (949)864-7745

Jon, before we discuss illegitimate resellers:
You can still order these parts from Xilinx, if you place an order
through your favorite distributor.
You must order before June 1 (i.e. very soon) but you can schedule
delivery over the next 12 months.
The reason for the "last time buy" is the complexity of the package.
It is cavity-down, which makes it hard to manufacture, and it also
mirrors the pin-out compared to conventional packages, causing lack of
compatibility.
All you have to do is place the order (pronto!) and schedule delivery
through a year.
No need to investigate shady deals...
Peter Alfke, Xilinx

Article: 132096
Subject: Re: Problem writing quadrature decoder
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 14 May 2008 07:34:08 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
> Jim Granville wrote:
>> I'm looking for an encoder that uses SPCO contacts,
>> (allows micro-power encoder), but that seems to be unobtanium.
>>
>> -jg
> 
> 
> Rather than exotic metal contacts, how about using an optical encoder? 
> It's hard to bounce 2 channels of light at the same time.

The problem with optical encoders is power consumption.
You can pulse them with low duty cycles to save power, but
suddenly that clock speed issue becomes important...
(as does the power of the oscillator, used to derive the
pulses.. )

-jg


Article: 132097
Subject: Need help on ASIC/ASSP FGPA-based prototyping and verification survey
From: "John Blyler" <jblyler@extensionmedia.com>
Date: Tue, 13 May 2008 12:58:33 -0700
Links: << >>  << T >>  << A >>
Hi all. I'm running a brief survey on "ASIC/ASSP (FPGA-based) prototyping 
and verification tools and pratices." If you have experience in this area, 
I'd appreciate your feedback (see below). Thx! -- John

Dear Chip Design reader,

Please participate in a short online survey for an important study on 
"ASIC/ASSP prototyping and verification tools" that will help your hardware 
and software suppliers make informed decisions that will benefit you, by 
Friday, May 16th.  It should take just a few minutes to complete.  Please 
click here (www.chipdesignmag.com/survey).

Extension Media is the publisher of technical trade journals including Chip 
Design and Embedded Intel? Solutions, email newsletters, websites, market 
studies such as Chip Design Trends ?The Slowing of Moore's Law and its 
implications on the Chip Design market" and customized market research 
services. We are a recognized editorial leader in the semiconductor-EDA and 
board level technology markets.

Respondents to our survey will remain strictly confidential. We recognize 
that your time is valuable and in return for completing our survey you will 
also be entered in a drawing to win one of twelve (12) $50 Amazon.com gift 
certificates. In addition, you will receive a free copy of the aggregated 
results of this survey once completed.

To take the survey, please click on the following link: 
http://www.chipdesignmag.com/survey

Your participation is greatly valued and appreciated.  Thank you for working 
with us on this project!

Best Regards,

John Blyler
Editorial Director
Extension Media LLC
jblyler@extensionmedia.com
(503) 614-1082 



Article: 132098
Subject: Re: Programming XCR3064xl - voltage at output stuck at 0
From: xcr3064xl <xc3064@gmail.com>
Date: Tue, 13 May 2008 13:10:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> xcr3064xl wrote:

> - What does the fitter report file say ?
> - Does the fuse-file change with the two compile choices ?

I cannot check that at the moment. I will check and post the result
tomorrow.


> - You could try something a little more complex : PinA = !PinB
>    and see what that does ?.

I am pretty sure I have tried this in the process but will try again.


> It's hazy, but ISTR issues with XCR devices and static pin
> defines (or similar) ?

I've googled for it but with no luck so far.

K.

> -jg

Article: 132099
Subject: Re: Programming XCR3064xl - voltage at output stuck at 0
From: xcr3064xl <xc3064@gmail.com>
Date: Tue, 13 May 2008 13:17:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dave Pollum wrote:

> For you 3064XL's that aren't working, are the power and ground wiring
> the same as the Digilent board?  Do you have bypass caps the same as
> or similar to the Digilent board?

I'm using a different xilinx device (compared to the Digilent board)
but power and ground look OK.

> If your problem chip is a PC44
> package, then pin 43 is an input-only pin.  Pick another pin that can
> do I/O.

It's VQ44. But I've tried other pins as well, e.g. pin 14.

K.

>
> -Dave Pollum



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