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 100625

Article: 100625
Subject: Re: PCB Stack
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 13 Apr 2006 21:07:43 GMT
Links: << >>  << T >>  << A >>

"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:4a6dna5Wvce536PZRVn_vA@giganews.com...
>I understand what you are saying but is there any industry standard values
> that are used. If I were to use these then I can adjust my track size to
> get the impedance I need.
>

Not really, it's up to you to work out the details but they're not terribly 
difficult to work out then you'll find that in many cases you'll carry over 
what you did to your next design since it worked so good for you last time. 
Some of the constraints you'll have are:

1.  Overall board thickness.  If you have any through hole components 
(connectors now a days can be about it but don't overlook it or you'll find 
some part where the leads won't go all the way through and won't get 
properly soldered).  .062, .093 and .125" are some common thicknesses that 
are driven by the lead length of 'typical' industry parts.

2. Available dielectric materials to use and their thicknesses.  Unless 
you're doing something exotic the material is likely FR4.  Check with PCB 
suppliers for some common thicknesses that they have and their line 
thickness/spacing constraints.

3. Balanced stackup.  Whether you work your way from top to bottom or bottom 
to top the layers that are power/ground planes need to be symmetrical. 
(i.e. Top, Plane, Plane, Bottom is the simple case for a 4 layer board).  As 
you work your way in, the thicknesses of the layers need to be symmetric as 
well.

4.  If every layer needs to have controlled impedance then adjacent to each 
and every signal layer must be a power/ground plane layer. Some examples: 10 
layers would be (Top, Plane, Sig, Sig, Plane, Plane, Sig, Sig, Plane, 
Bottom).  12 layers would be (Top, Plane, Sig, Sig, Plane, Sig, Sig, Plane, 
Sig, Sig, Plane, Bottom).  You'll find that you'll have some difficulty 
working out an 8 layer arrangement so if it has to be 8 you'll need to make 
some tradeoffs.

5.  Minimum required line and trace widths that you need to actually route 
the board.  Except for power or other high current nets you'll likely be 
better off making everything the same line width and be done with it (but 
again, different applications have their exceptions).

6.  Impedance control.  For digital applications 'many' times you don't so 
much care what the actual impedance is just that it doesn't vary from layer 
to layer since odds are you won't be able to route everything on one layer. 
If that's the situation then you may want to work out a target impedance to 
shoot for and a layer to layer difference that must be met.  As an example, 
maybe you spec that you want the impedance of each signal layer to be 55+/- 
5 ohms.  That allows the supplier a relatively wide window to shoot for. 
But you also want to constrain them so that you don't have Sig1 = 50 ohms, 
Sig2 = 60 ohms so you need to have an additional spec that says what the 
largest layer to layer impedance differential you're willing to tolerate 
will be (2 ohms maybe).  The supplier really won't have much trouble meeting 
this spec since it will likely require them to use the same material and 
thickness for most of the layers.  What will make it difficult is the actual 
impedance of a layer is important and you can't trade off either overall 
board thickness or trace width.  Working out the math to figure out a rough 
cut at the impedance and stackup ahead of time will help, if not work with 
the supplier and talk through what your requirements are and they can pop 
out a stackup for you in nothing flat since that's they're business.

The PCB supplier is generally keenly interested in nailing #1, 2 and 3 to 
minimize their cost and come up with something that they can fabricate 
economically so you can expect them to help you get those right.  #4, 5 and 
6 though generally don't impact their costs directly they really are 
constraints that they need to be able to meet so you need to be the one 
driving them to make sure that the stackup meets your product requirements 
in those areas.

KJ 



Article: 100626
Subject: Re: RGMII mode on V4 Hard Tri-EMAC core
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 13 Apr 2006 17:08:32 -0400
Links: << >>  << T >>  << A >>
"Joseph Samson" <user@example.net> wrote in message
news:TJy%f.1526$Lm5.279@newssvr12.news.prodigy.com...
>
> I have a webcase open on this issue right now. I want to use PLB_TEMAC
> with RGMII, but that combination is currently not supported. I will
> update the group when I get an answer.
>

I have a webcase open as well :) The answer I got so far reads:

"The developers are currently working on this matter. Both the hard_temac
and the plb_temac cores must have RGMII support included before the
interface can be used.
There is no set timeline on when this feature will be available. At the
earliest however it will be EDK 8.2.02i. This will be towards the end of
this year.
In the meantime I cannot offer you a workaround to this matter."

However, I wonder what can prevent me from instantiating the core in the top
level design and connecting to the PLB bus through a custom IP interface? Or
connecting it in the way shown in the XAPP807...

I have designed a board with RGMII in mind and now it would be very hard to
redesign it for GMII...

/Mikhail



Article: 100627
Subject: Re: RGMII mode on V4 Hard Tri-EMAC core
From: Joseph Samson <user@example.net>
Date: Thu, 13 Apr 2006 21:41:08 GMT
Links: << >>  << T >>  << A >>
MM wrote:
> "Joseph Samson" <user@example.net> wrote in message
> news:TJy%f.1526$Lm5.279@newssvr12.news.prodigy.com...
> 
>>I have a webcase open on this issue right now. 
> 
> I have a webcase open as well :) The answer I got so far reads:
> 
> "The developers are currently working on this matter. Both the hard_temac
> and the plb_temac cores must have RGMII support included before the
> interface can be used.
> There is no set timeline on when this feature will be available. At the
> earliest however it will be EDK 8.2.02i. This will be towards the end of
> this year.
> In the meantime I cannot offer you a workaround to this matter."


I just got off the phone with my webcase CAE. He says that the next 
version of PLB_TEMAC (v3) will be released with 8.1 SP2, which was 
actually supposed to be today. It has RGMII and other features.

---
Joe Samson
Pixel Velocity

Article: 100628
Subject: Re: RGMII mode on V4 Hard Tri-EMAC core
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 13 Apr 2006 17:47:07 -0400
Links: << >>  << T >>  << A >>
"Joseph Samson" <user@example.net> wrote in message
news:Uzz%f.58788$F_3.20549@newssvr29.news.prodigy.net...
>
> I just got off the phone with my webcase CAE. He says that the next
> version of PLB_TEMAC (v3) will be released with 8.1 SP2, which was
> actually supposed to be today. It has RGMII and other features.

Great news! Thanks.


/Mikhail



Article: 100629
Subject: Re: Spartan 3E Starter Kit is finally here!
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 13 Apr 2006 23:04:56 GMT
Links: << >>  << T >>  << A >>
I just got my starter kit delivered as well.  Whew.  A day before the Avnet 
Speedway seminar in town, too. 



Article: 100630
Subject: ARM Emulator
From: "morpheus" <saurster@gmail.com>
Date: 13 Apr 2006 16:12:08 -0700
Links: << >>  << T >>  << A >>
Hi,
Does anyone have an idea if there is a free ARM emulator out there. We
have GHS in house...but the s'ware guys don't have an extra license for
me...huffffff
Anyways, I am designing a cpld which is memory mapped with a PXA 255
and I need to prove out memory map architecture....I know I can
simulate but I derive more pleasure by checking chip selects for
peripherals on the scope....delight!!..
Anyways, and help/input will be appreciated.
Thanks
MORPHEUS


Article: 100631
Subject: Problem: Invalid Processor Version Number 0x00000000- EDK-7.1- latest service pack, ML310, bootloop, download bitsream
From: "chakra" <narashimanc@gmail.com>
Date: 13 Apr 2006 16:23:22 -0700
Links: << >>  << T >>  << A >>
Hi all,

Am working on ML310 board, and EDK. I get similar problem like Xilinx
Answer database 18265, 21296, but not quite. The exact problem is in
the subject and this is what I do, to land in the problem.

A. I create a project in EDK7.1 for ML310 board

1.I initialize the bootloop for PPC405_0 (mark to initialize BRAM ),
and unmark the BRAM in the project TestApp.

2.Generate Lib, Bsp , build project/userapplication,  Generate
Bitstream and update bitstream

3. When doing step 2 Software settings are :
PPC405_0:MVL linux and it has several peripherals connected to it
PPC405_1: stand alone

4.when I open XMD before downloading the bootloop(download.bit, created
after "update bitstream" command), it recognizes the ppc target.id=0

5.when i download the bootloop(download.bit), and open XMD it doesnot
recognize the ppc Target.saying it has Invalid Processor Version No
0x00000000

Can anyone tell me where i am going wrong? I appreciate all the help.

With warm regards,
Chakra.


Article: 100632
Subject: Re: Did National cheat with the Virtex 4? Or are they just smart
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 13 Apr 2006 16:30:48 -0700
Links: << >>  << T >>  << A >>
lecroy7200,

While it is true that we don't specify a LVDS clock that high in 
frequency, the IO is perfectly capable of going way past 1.2GHz, so it 
becomes a question of duty cycle distortion on the clock resources inside.

It won't be 45/55% like the spec sheet says, but it will still have a 
perfectly good pulse there.  Obviously National is using this.  Since 
they are using it, that makes Xilinx kind of responsible for some 
support of this application.  What that means is that if you use it the 
way they did, we will support it (wiring, t-lines, terminations, paths 
used, speed grade, etc.).

Similar to the PCI interface, the basic PCI operates outside of our 
specifications, but we support it, as we have tested our PCI core in our 
parts, and found it to work just fine.

This is known as support of "application outside of specification."  If 
you are curious, there are very few of these.  PCI is the largest. 
After that, I would guess you fall into something like the National 
application (very small compared with the overall usage).

Austin

lecroy7200@chek.com wrote:

> I was watching Avnets' sponcered video with Robert Pease and Howard
> Johnson where National had a board with a ADC08D1500 dual ADC tied
> directly into a Virtex 4.  The videos, datasheets, etc may be found at:
> 
> http://www.national.com/xilinx/
> 
> The LVDS clock coming from the ADC is 750MHz.  They route this clock
> directly to the Virtex 4.  When I look at the specs. for the Virtex 4,
> this would seem to be way outside of what it is rated for.
> 
> My question is this, did National do some neat trick to make this work,
> or did they just exceed the specs of the device knowing it was not a
> production unit and did not really worry about it?  Or did I miss
> something?
> 
> Also, if anyone purchased the eval. board, I would be interested in
> hearing if U5 was populated with the LMH6550 or some other part.
> 
> Thanks
> 

Article: 100633
Subject: Re: Did National cheat with the Virtex 4
From: "Brian Davis" <brimdavis@aol.com>
Date: 13 Apr 2006 18:43:39 -0700
Links: << >>  << T >>  << A >>
>
> The LVDS clock coming from the ADC is 750MHz.  They route this clock
> directly to the Virtex 4.  When I look at the specs. for the Virtex 4,
> this would seem to be way outside of what it is rated for.
>
> My question is this, did National do some neat trick to make this work,
> or did they just exceed the specs of the device knowing it was not a
> production unit and did not really worry about it?  Or did I miss
> something?
>
IIRC:
 8 bits @ 1.5 Ghz sample clock => 16 bits @ 375 MHz DDR clk to FPGA

 The National A/D's have an on-board 1:2 demux, so at a clock rate
of 1.5 Ghz, the 8 bit samples come out 16 bits wide with the DCLK
output clock selectable as either SDR (750 Mhz) or DDR (375 MHz).

 No out of spec handwaving dispensations are required from San Jose.

 Brian

p.s.
  Re your other post, the new high-end LatticeSC parts are
claiming 2Gbps parallel LVDS I/O, with some  interesting
split-to-VTT and center-tap-cap on-chip termination modes.


Article: 100634
Subject: Re: ARM Emulator
From: onyx49@juno.com
Date: 13 Apr 2006 18:59:23 -0700
Links: << >>  << T >>  << A >>

morpheus wrote:
> Hi,
> Does anyone have an idea if there is a free ARM emulator out there. We
> have GHS in house...but the s'ware guys don't have an extra license for
> me...huffffff
> Anyways, I am designing a cpld which is memory mapped with a PXA 255
> and I need to prove out memory map architecture....I know I can
> simulate but I derive more pleasure by checking chip selects for
> peripherals on the scope....delight!!..
> Anyways, and help/input will be appreciated.
> Thanks
> MORPHEUS



I have a book by Arnold Berger
"Hardware and Software Organization"
which is supposed to have an instruction set simulator for the
ARMV3
ISBN 0-7506-7886-0

Good luck,
Dave


Article: 100635
Subject: humble suggestion for Xilinx
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 13 Apr 2006 19:52:05 -0700
Links: << >>  << T >>  << A >>


Since the max serial-slave configuration rate on things like Spartan3
chips is, what, 20 MHz or something, you might consider slowing down
the CCLK input path, and/or adding some serious hysteresis on future
parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads
and stubs and vias and such, so may not be as pristine as a system
clock. CCLK seems to be every bit as touchy as main clock pins, and it
really needn't be.

John


Article: 100636
Subject: Re: humble suggestion for Xilinx
From: John_H <johnhandwork@mail.com>
Date: Fri, 14 Apr 2006 05:53:30 GMT
Links: << >>  << T >>  << A >>
John Larkin wrote:
> 
> Since the max serial-slave configuration rate on things like Spartan3
> chips is, what, 20 MHz or something, you might consider slowing down
> the CCLK input path, and/or adding some serious hysteresis on future
> parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads
> and stubs and vias and such, so may not be as pristine as a system
> clock. CCLK seems to be every bit as touchy as main clock pins, and it
> really needn't be.
> 
> John

John,

Are your suggestions for the CCLK generated by the Xilinx device or the 
CCLK received by the Xilinx device?

I think the max speed is up to 66 MHz these days in the Spartan3E.  It 
may not be LVDS rates but it's not 4000 series logic, either.

- John_H

Article: 100637
Subject: PROG_B and JTAG
From: "Marco" <marco@marylon.com>
Date: 14 Apr 2006 00:22:52 -0700
Links: << >>  << T >>  << A >>
Hi,
I'll not use PROG_B with my Spartan3, should I just pull-it up with
10k?
Is it true that I can alway access the FPGA through the JTAG port even
if the M0-M2 are hardware-set for slave/master serial? 
Thanks, Marco


Article: 100638
Subject: Re: PROG_B and JTAG
From: "Antti Lukats" <antti@openchip.org>
Date: Fri, 14 Apr 2006 09:53:52 +0200
Links: << >>  << T >>  << A >>
"Marco" <marco@marylon.com> schrieb im Newsbeitrag 
news:1144999372.724233.229220@u72g2000cwu.googlegroups.com...
> Hi,
> I'll not use PROG_B with my Spartan3, should I just pull-it up with
> 10k?
> Is it true that I can alway access the FPGA through the JTAG port even
> if the M0-M2 are hardware-set for slave/master serial?
> Thanks, Marco
>
yes m0,m1,m2 are dont cared for JTAG but PROG_B *must* be high or jtag 
config will fail, there I think it supposed to be internal pullup on prog_b 
but at least with xilinx virtex I have seen that external pullup is also 
required, so better have it in place

antti 



Article: 100639
Subject: Re: humble suggestion for Xilinx
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 14 Apr 2006 03:03:17 -0700
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On a pcb, CCLK is often a shared SPI clock, with lots of loads
> and stubs and vias and such, so may not be as pristine as a system
> clock. CCLK seems to be every bit as touchy as main clock pins, and it
> really needn't be.
>

What it's really saying is that when designing a PCB, CCLK should be
treated with as much care and respect as any other clock signal so you
won't have lots of loads, stubs and vias and such.

KJ


Article: 100640
Subject: Re: PCB Stack
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Fri, 14 Apr 2006 05:27:10 -0500
Links: << >>  << T >>  << A >>
Thanks all for the advice. Regarding my stack I was planning to do this :-

Top
Gnd
Power
Mid1
Mid2
Power
Gnd
Bottom

Does the above seem sensible or would it be better to use 10 layers?

Cheers

Jon

Article: 100641
Subject: Re: PCB Stack
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 14 Apr 2006 12:50:26 +0200
Links: << >>  << T >>  << A >>
maxascent schrieb:
> Thanks all for the advice. Regarding my stack I was planning to do this :-
> 
> Top
> Gnd
> Power
> Mid1
> Mid2
> Power
> Gnd
> Bottom

As you are likely to have more than two power supply voltages you should
substitute one of the ground planes by another power plane. For
impedance control it does not matter what the electrical potential of
the plane is.

Kolja Sulimma

Article: 100642
Subject: Re: Cyclone II EP2C70 dev kits, where are they?
From: "Karl" <karlIGNORETHISPART@chello.nl>
Date: 14 Apr 2006 05:02:04 -0700
Links: << >>  << T >>  << A >>
> If anyone knows of any 2C70 boards, do let us know.

You're lucky !

The Lead-Free / RoHS compliant version of the Cyclone II based DSP
board will be with the EP2C70 !

Kind regards,

Karl.


Article: 100643
Subject: Re: PCB Stack
From: John_H <johnhandwork@mail.com>
Date: Fri, 14 Apr 2006 13:24:04 GMT
Links: << >>  << T >>  << A >>
maxascent wrote:
> Thanks all for the advice. Regarding my stack I was planning to do this :-
> 
> Top
> Gnd
> Power
> Mid1
> Mid2
> Power
> Gnd
> Bottom
> 
> Does the above seem sensible or would it be better to use 10 layers?
> 
> Cheers
> 
> Jon

Personally, I like your stackup.  Having chopped-up power planes is fine 
as long as certain precautions are taken:

  Make sure the power islands aren't fed over tiny tracks
  Place adequate decoupling on the power islands
  Have adequate decoupling caps near plane splits
    (to provide a decent return current path)

Every time a signal changes layers, there's a chance to introduce 
crosstalk through common return paths.  A sprinkling of decoupling caps 
and/or ground/ground connections helps reduce the current loops that can 
make EMI/EMC nasty in addition to the crosstalk issues.

Article: 100644
Subject: Re: humble suggestion for Xilinx
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 14 Apr 2006 06:50:28 -0700
Links: << >>  << T >>  << A >>
On 14 Apr 2006 03:03:17 -0700, "KJ" <Kevin.Jennings@Unisys.com> wrote:

>John Larkin wrote:
>> On a pcb, CCLK is often a shared SPI clock, with lots of loads
>> and stubs and vias and such, so may not be as pristine as a system
>> clock. CCLK seems to be every bit as touchy as main clock pins, and it
>> really needn't be.
>>
>
>What it's really saying is that when designing a PCB, CCLK should be
>treated with as much care and respect as any other clock signal so you
>won't have lots of loads, stubs and vias and such.
>

And what I'm saying is that treating it as such shouldn't be
necessary. 

John



Article: 100645
Subject: Re: humble suggestion for Xilinx
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 14 Apr 2006 06:53:58 -0700
Links: << >>  << T >>  << A >>
On Fri, 14 Apr 2006 05:53:30 GMT, John_H <johnhandwork@mail.com>
wrote:

>John Larkin wrote:
>> 
>> Since the max serial-slave configuration rate on things like Spartan3
>> chips is, what, 20 MHz or something, you might consider slowing down
>> the CCLK input path, and/or adding some serious hysteresis on future
>> parts. On a pcb, CCLK is often a shared SPI clock, with lots of loads
>> and stubs and vias and such, so may not be as pristine as a system
>> clock. CCLK seems to be every bit as touchy as main clock pins, and it
>> really needn't be.
>> 
>> John
>
>John,
>
>Are your suggestions for the CCLK generated by the Xilinx device or the 
>CCLK received by the Xilinx device?
>

In serial-slave mode, the FPGA receives CCLK.

>I think the max speed is up to 66 MHz these days in the Spartan3E.  It 
>may not be LVDS rates but it's not 4000 series logic, either.

Right. Improving the noise immunity of the CCLK receiver would have
exactly one practical result: more FPGAs would configure.

John



Article: 100646
Subject: what wrong of this counter ?
From: "kelvins" <kelvins.huang@gmail.com>
Date: 14 Apr 2006 07:51:05 -0700
Links: << >>  << T >>  << A >>
Hi all,
    i have a problem, the code as below, the all condition
signals(excludes rst_n)
 is generated by  posedge clk_in. I have run in simulation the counter
"count" is normal.
 the new "count" is generated by posedge clk_in. but when I use FPGA
emulation
 and observe the new "count" in sometime is generated by negedge
clk_in. what happen
 to this situation? it cannot same as simulation result.
I am using Quartus 5.0 for compiling and fitting, the timing report is
OK.
Hope someone could give me some suggestion to this situation, thanks a
lot.

############################################################
always @(negedge rst_n or posedge clk_in)
  if ( !rst_n )  begin
       count <=4'b0;
  end else  begin
     if ( inst_en ) begin
         count <=4'b0;
     end else begin
        if ( op_state ) begin
             if( count==`OP_CNT )  count <=4'b0;
             else if ( !c_sel )   count <= count + 1;
        end else if (byte_state) begin
             if( count==`BYTE_CNT )  count <=4'b0;
             else if ( !c_sel )   count <= count + 1;
        end else if ( addr_state ) begin
             if( count==`ADDR_CNT )  count <=4'b0;
             else if ( !c_sel )   count <= count + 1;
        end else if ( data_state ) begin
              if ( inst==`AA_wr || inst==op_program ) begin
                   if( count==`BYTE_CNT )  count <=4'b0;
                   else if ( !c_sel && hold_wr )   count <= count + 1;
              end else begin
                   if( count==`BYTE_CNT )  count <=4'b0;
                   else if ( !c_sel && hold_rd )   count <= count + 1;
              end
        end
     end
  end
##############################################################


Article: 100647
Subject: Xilinx USB Platform Cable not working anymore (linux)
From: "Gerr" <gertvierman@hotmail.com>
Date: 14 Apr 2006 07:53:28 -0700
Links: << >>  << T >>  << A >>
(Google didn't allow me to reply to the original thread, so I copied
the previous message in myself)

On Mon, Jan 9 2006 6:27 pm, Gilles Georges wrote :

> I just tried the cable with same board on a Win XP computer and it
> works. I previously downgrade to cpld firmware V4 (taken in a ISE 6.3
> linux install) => not working under linux but working under windows.
> Then i upgrade to version 6 and still working under windows.
>
> Going back to my Linux workstation nothing works.
>
> There is a strange thing with Impact, the "CPLD version" differs with
> the "CPLD file version" while the two match on Windows.
>
> Connecting to cable (Usb Port - USB22).
> Checking cable driver.
> File version of /local/xilinx/bin/lin/xusbdfwu.hex = 1018(dec), 03FA.
> File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1018(dec), 03FA.
>   Max current requested during enumeration is 150 mA.
>   Cable Type = 3, Revision = 0.
>   Setting cable speed to 6 MHz.
> Cable connection established.
> Firmware version = 1018.
> CPLD file version = 0006h.
> CPLD version = 0021h.
>
> Any idea.

I've got the same problem here: the USB cable works fine with windows,
but using linux, the CPLD version is mis-read, and the only thing
happening is the firmware being updated. (which takes almost an hour,
hilarious!). I'm using ISE 8 instead of 6, but the symptoms are the
same.

I just contacted Gilles in private to see if he found any solution to
this issue yet. His workaround is the same as mine: use a windows
machine for programming with the USB platform cable. I'm sure that's
not what xilinx had in mind, when the published the Linux drivers for
this cable.

Does anybody have this cable working yet, running a 2.6 linux kernel ?


Article: 100648
Subject: Re: PCB Stack
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 14 Apr 2006 09:47:11 -0700
Links: << >>  << T >>  << A >>
1 GND plane in an 8-layer stack? I was under the belief that yes, a
power plane can serve as a return path for a signal, but it's not
preferred or equal over a GND plane. I would think partitioning the
power planes is a safer bet than cutting another GND layer.


Article: 100649
Subject: Spartan 3 chips in power up
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 14 Apr 2006 09:47:57 -0700
Links: << >>  << T >>  << A >>
I have looked at the data sheet and they say very clearly that the
Spartan 3 is held in reset until all three power supplies are fully up.
 But the range of voltages is very wide, with reset being released when
the Vcoo on Bank four is as low as 0.4 volts.

I get a lot of grief from the FPGA firmware designers on every little
nit and pic that they don't like about the board design.  I need to
know that this will keep the FPGA in reset and all IOs tristated
whether the various power voltages are above or below the internal
reset threshold, up to the point of being configured.




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