Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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... PeterArticle: 132076
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
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: 132078Peter 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 ;) -jgArticle: 132079
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 ? -jgArticle: 132080
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.. ? -jgArticle: 132081
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_HArticle: 132082
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) ? -jgArticle: 132083
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. -aArticle: 132084
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
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: 132086Jim 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. - JohnArticle: 132087
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 PollumArticle: 132088
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. -jgArticle: 132089
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, uchennaArticle: 132090
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_HArticle: 132091
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. -jgArticle: 132092
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 SulimmaArticle: 132093
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
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_HArticle: 132095
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, XilinxArticle: 132096
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.. ) -jgArticle: 132097
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-1082Article: 132098
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. > -jgArticle: 132099
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:
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