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 139275

Article: 139275
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 21:26:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 4:50 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> -jg <Jim.Granvi...@gmail.com> wrote:
> > - but that's always FPGAs problem, and one reason the business
> > as a whole, has low growth : The high-volume designs move to ASICs,
> > so FPGAs chase the pioneer (and low-med volume) sockets...
>
> And as mask costs (and other NRE) increase, the crossover
> point moves up.  Also, as low end FPGAs get cheaper.
>
> There is an article that says that low end Spartan's,
> I believe S3E, were supposed to be in the $2 range.

Still, there is no comparison between an FPGA and an ASIC.  Any design
implemented in a $2 FPGA could be designed as an ASIC in a process
that has NRE costs a fraction of the NRE cost that was paid for the
FPGA, will fit on a much smaller die than the FPGA and would provide a
huge lifetime cost savings for any volume over 100,000 or so.  BTW,
that $2 price tag is for qty 250,000 typically.

Sure, there will be new designs that use FPGAs for prototyping and
even initial production.  Smaller volume runs will use FPGAs for the
entire run.  FPGAs will also be used when the ability to upgrade or
otherwise modify the design in the field is important.  But none of
this applies to standard automotive apps.  In that market, cost is the
driving factor.  They don't need small; they don't need low power;
they don't need light; they need *cheap*!

I will say that power is becoming an issue in automotive apps.  They
are now placing specs on the "off" current drawn by devices so that
the battery is not drained in a week of the car sitting unused.

But this conversation about the automotive market started with the
issue of 5 volt operation of semiconductors.  5 volt operation may be
a major issue in automotive apps, but that will not drive FPGA designs
because FPGAs don't suit automotive apps.  They just plain cost too
much!

Rick

Article: 139276
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 Mar 2009 21:39:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 12:49 pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 24, 6:36 pm, Prevailing over Technology <steve.kn...@prevailing-
>
>
>
> technology.com> wrote:
> > On Mar 23, 9:01 am, rickman <gnu...@gmail.com> wrote:
>
> > > I was reading the data sheet the other day and I noticed that these
> > > parts have 5 volt compatible I/Os on three of the four banks.  I'm
> > > pretty impressed with that... until I read that the fourth bank is not
> > > even 3.3 volt tolerant!!!  What's up with that?
>
> > [snip]
>
> > I've talked to them about that also.  All I can say at this point is
> > watch this space.  I think they plan on some sort of 3.3V support in I/
> > O Bank 3.
>
> > [snip]
>
> > > One other thing I noticed, they seem to be changing the planned
> > > packaging, which is not surprising I suppose.  In the package list,
> > > they flag compatible pinouts using the same package.  But I don't see
> > > the 04 and 08 as being compatible in the 196 pin package.  This
> > > package was added since rev 1.1 of the data sheet, so it is surprising
> > > to me that these would not be compatible.
>
> > The 'L04 and 'L08 are _almost_ pin compatible in the 196-pin package.
> > There is a table on page 62 in the data sheet that shows the
> > differences.  The real differences are if you use differential I/O and
> > if you use the Global Buffer INput (GBIN) pins in banks 2 and 3.  If
> > you use single-ended I/O and direct clock inputs in those banks, then
> > both devices are pin compatible in the 196-pin package.
>
> > > The CS132 package looks pretty interesting.  The main reason that I
> > > avoid BGAs is the PCB requirements to provide routing from the inner
> > > pins.  This package looks like it might be routable without running
> > > traces between the pads or even vias within the pads.  But the
> > > innermost 16 pads seem to mess this up.  Anyone have a good routing
> > > layout for this package?  What PCB design rules are required to use
> > > this package?
>
> > There are some examples layouts from the iCEman65 development board.
> > The board uses the 284-ball chip-scale BGA package (CB284) which is a
> > superset of the 132-ball package (CB132).  The inner balls are
> > identical.
>
> > A PDF version of the layout appears in the user guide beginning on
> > page 44.http://www.siliconbluetech.com/media/iCEmanBoardUserGuide.pdf
>
> > The Gerber files are available as well.  Note that the link on their
> > website apparently points to an old version (Should be Rev. D).http://www.siliconbluetech.com/media/iCEman65GerbersRevB.zip
>
> > -- Steven K. Knapp
> >    Prevailing Technology, Inc.
> >    www.prevailing-technology.com
>
> Steven,
>
> iceMAN65 is multilayer PCB, Rick asked how i made it on 2 layers :)
>
> well i have to say that the SB easyBGA is not that easy, mostly
> because of the inner vcc/gnd pads, so most of the inner free space
> is wasted to route out vccint and vccio
> also some other pins are rather hard to route on 2 layers
>
> so bga 0.5 with 3 outer rows only could actually be easier
> as the easyBGA as it leaves large space in the middle

But with three rows, one row has to be routed between the pads of the
other two.  If you are going to do that you  might as well use four
rows.  Still, you need a lot of room in the middle for vias and they
still have to be pretty small.  I thought 10 mil holes were ok until
Sunstone "rounded up" my drill holes to 13 mils because they didn't
want to plate 10 mil holes.  Even at 13 mils they couldn't make it
work and some 30 % of the boards they produced did not pass electrical
test.  Then some 6% of the assembled boards had open vias after the
soldering process.  I hate to think how many of them will be failing
in the field.  Fortunately this batch was for internal testing for my
customer and will not be shipped to their customers.  Any failures
will be sent back to me without recriminations.

After experiences like this I am reluctant to work in very small
feature sizes on boards.  To route between pads on 0.5 mm (~20 mil)
centers would require what, maybe 3 or 4 mil trace/space?  I've never
pushed below 5 mil.

Rick

Article: 139277
Subject: Re: Silicon Blue last datesheet correct URL
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 22:38:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 6:39=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 24, 12:49 pm, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 24, 6:36 pm, Prevailing over Technology <steve.kn...@prevailing-
>
> > technology.com> wrote:
> > > On Mar 23, 9:01 am, rickman <gnu...@gmail.com> wrote:
>
> > > > I was reading the data sheet the other day and I noticed that these
> > > > parts have 5 volt compatible I/Os on three of the four banks. =A0I'=
m
> > > > pretty impressed with that... until I read that the fourth bank is =
not
> > > > even 3.3 volt tolerant!!! =A0What's up with that?
>
> > > [snip]
>
> > > I've talked to them about that also. =A0All I can say at this point i=
s
> > > watch this space. =A0I think they plan on some sort of 3.3V support i=
n I/
> > > O Bank 3.
>
> > > [snip]
>
> > > > One other thing I noticed, they seem to be changing the planned
> > > > packaging, which is not surprising I suppose. =A0In the package lis=
t,
> > > > they flag compatible pinouts using the same package. =A0But I don't=
 see
> > > > the 04 and 08 as being compatible in the 196 pin package. =A0This
> > > > package was added since rev 1.1 of the data sheet, so it is surpris=
ing
> > > > to me that these would not be compatible.
>
> > > The 'L04 and 'L08 are _almost_ pin compatible in the 196-pin package.
> > > There is a table on page 62 in the data sheet that shows the
> > > differences. =A0The real differences are if you use differential I/O =
and
> > > if you use the Global Buffer INput (GBIN) pins in banks 2 and 3. =A0I=
f
> > > you use single-ended I/O and direct clock inputs in those banks, then
> > > both devices are pin compatible in the 196-pin package.
>
> > > > The CS132 package looks pretty interesting. =A0The main reason that=
 I
> > > > avoid BGAs is the PCB requirements to provide routing from the inne=
r
> > > > pins. =A0This package looks like it might be routable without runni=
ng
> > > > traces between the pads or even vias within the pads. =A0But the
> > > > innermost 16 pads seem to mess this up. =A0Anyone have a good routi=
ng
> > > > layout for this package? =A0What PCB design rules are required to u=
se
> > > > this package?
>
> > > There are some examples layouts from the iCEman65 development board.
> > > The board uses the 284-ball chip-scale BGA package (CB284) which is a
> > > superset of the 132-ball package (CB132). =A0The inner balls are
> > > identical.
>
> > > A PDF version of the layout appears in the user guide beginning on
> > > page 44.http://www.siliconbluetech.com/media/iCEmanBoardUserGuide.pdf
>
> > > The Gerber files are available as well. =A0Note that the link on thei=
r
> > > website apparently points to an old version (Should be Rev. D).http:/=
/www.siliconbluetech.com/media/iCEman65GerbersRevB.zip
>
> > > -- Steven K. Knapp
> > > =A0 =A0Prevailing Technology, Inc.
> > > =A0 =A0www.prevailing-technology.com
>
> > Steven,
>
> > iceMAN65 is multilayer PCB, Rick asked how i made it on 2 layers :)
>
> > well i have to say that the SB easyBGA is not that easy, mostly
> > because of the inner vcc/gnd pads, so most of the inner free space
> > is wasted to route out vccint and vccio
> > also some other pins are rather hard to route on 2 layers
>
> > so bga 0.5 with 3 outer rows only could actually be easier
> > as the easyBGA as it leaves large space in the middle
>
> But with three rows, one row has to be routed between the pads of the
> other two. =A0If you are going to do that you =A0might as well use four
> rows. =A0Still, you need a lot of room in the middle for vias and they
> still have to be pretty small. =A0I thought 10 mil holes were ok until
> Sunstone "rounded up" my drill holes to 13 mils because they didn't
> want to plate 10 mil holes. =A0Even at 13 mils they couldn't make it
> work and some 30 % of the boards they produced did not pass electrical
> test. =A0Then some 6% of the assembled boards had open vias after the
> soldering process. =A0I hate to think how many of them will be failing
> in the field. =A0Fortunately this batch was for internal testing for my
> customer and will not be shipped to their customers. =A0Any failures
> will be sent back to me without recriminations.
>
> After experiences like this I am reluctant to work in very small
> feature sizes on boards. =A0To route between pads on 0.5 mm (~20 mil)
> centers would require what, maybe 3 or 4 mil trace/space? =A0I've never
> pushed below 5 mil.
>
> Rick

Rick

minimum hole size that is done without HDI is usually 0.3mm =3D 13mils

so it was your fault if you designed with 10mils

any halfway decent PCB fab should be able todo 0.3mm drilled holes
and 6 mils track/space. you need of course immersion gold plating
for the PCB's. my proto fab doesnt do that so for the 1 off proto
boards
i use chemical tinning. production boards are made in taiwan with
immersion gold. The boards are 0.8mm thick and we have no problems
with the yield so far.

Antti













Article: 139278
Subject: Re: Which ISE Webpack version for S3A..?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 22:53:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 1:46=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> I'm about to start a project on an Spartan3A (200) in VHDL - having seen =
a few comments here about
> ISE problems I was wondering if I'd be best using the Webpack v 9.2 that =
came with the devboard or
> downloading the latest 10.1 ?
> Is there anything in V10 that would be worth the doubtless colossal downl=
oad ?
> Or anything sufficiently broken in either version to be a big deal?

each ISE version has more bugs..

one already sufficient reason to get 10.1 is that from 10.1 the
installation folder is name properly
( same as Altera is doing Quartus\90\.. )

now Xilinx also has
Xilinx\10.1\ISE
Xilinx\10.1\EDK
..

i used to have many parallel xilinx installs and had to always rename
the folders to reflect the version
now this is done by the installer :)

Antti





Article: 139279
Subject: Re: Antti Processor
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 24 Mar 2009 23:14:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 10:56=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 24, 8:30=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > it is being developed :)
> > well it is actually NPU version 2
> > (where NPU stands for my node processor unit - a not finished design
> > concept)
>
> > some features
> > * optimized for streaming media, that is clocked data streams (serial
> > flash, SD card, etc..)
> > * PC is optional
> > * Stack is optional
> > * minimum number of registers: 0
> > * minimum size of internal RAM: 0
> > * no reset pin needed (input stream can force reset)
> > * operand widths: 1 to unlimited
> > * address space: unlimited
> > * minimal configuration : 0 LUT/0 FF (1 Block ROM + IOB F/F's)
>
> > there are some compromises of course, say 32 bit ALU operation
> > would take 40 clock cycles for the operation itself + some more
> > clocks to select the operands and operation type. shorter operation
> > will be less clock cycles, but still rather slow in terms of clock
> > cycles
> > otoh as the serialized nature allows operation at higher fabric speeds
> > then the overall performance could be rather good.
> > Quad SPI memories can stream data at 320MBit/s, in modern
> > FPGA NPU2 could easily run at 320mhz, what would give some
>
> > >5 MIPS for 32 bit operations what is not that bad at all
>
> > the Processor is currently designed using EXCEL
>
> > main problem would be the tool support, as the assembler/compiler
> > would =A0need to be generated based on the processor description, there=
 is no
> > fixed =A0instruction set at all, and pretty much all features of the pr=
ocessor
> > are =A0configurable, also variables and constant can be of different wi=
dths,
> > so the =A0compiler should know how wide variables to use, not only 8/16=
/32 but
> > they =A0can really be any size with single bit granularity
>
> interesting - Sounds like a nice blank canvas :)
>
> Does it have skip opcodes ?
>
> A register frame pointer, for when registers are in BRAM ?
>
> The ability to run a 'dual-core' by time-slot allocating multiple
> register/flag sets ?
> (probably dictates a second SO8 memory?)
>
> -jg

Hi Jim,

you are right the work-sheet is mostly empty :)

well there arent many opcodes defined yet at all
think of it at engine with serialized microcode
so the opcodes are made up from microcode
microcode slots are 2 bit each and can hold
either 2 bit instruction or 1 instruction 1 data or 2 data bits

so the opcodes are not fixed, and can have variable length
only special registers are fixed in length (address pointers..)
any software accessible VARIABLES and constants can
have user defined widths with 1 bit granularity and 1 bit
start address granularity too

Antti















Article: 139280
Subject: Re: Exporting AccelDSP generated Fixed Point C-Code to MicroSoft
From: Moazzam <moazzamhussain@gmail.com>
Date: Tue, 24 Mar 2009 23:24:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 19, 6:35=A0pm, Moazzam <moazzamhuss...@gmail.com> wrote:
> Hi,
> I am using Xilinx AccelDSP Synthesis tool to rapidly prototype image
> processing algorithms. In one of my tasks, I need to incorporate the
> code generated from AccelDSP to my existing project in Microsoft
> Visual Studio as a function call.
>
> I simply added all the source files (Generated from AccelDSP) in my
> Visual studio project, and a few compile time error made me add some
> extra header files from AccelDSP and Matlab directories. After adding
> all of the header files, the visual studio gives error messages within
> the code.
>
> Am I missing some thing, has any one successfully incorporated
> AccelDSP generated code in existing visual studio project ?
>
> Regards
> Moazzam

Hi all,

For the sake of completion of this thread, I am copying the answer
that I got from Xilinx forums:

"Currently importing the fixed point C-code generated from AccelDSP to
Microsoft Visual Studio is not supported. The generated fixed point C-
code can only be used in the AccelDSP".

Regards
/MH

Article: 139281
Subject: Re: Antti Processor
From: goouse@twinmail.de
Date: Wed, 25 Mar 2009 00:14:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 24 Mrz., 09:30, Antti <Antti.Luk...@googlemail.com> wrote:
> it is being developed :)
> well it is actually NPU version 2
> (where NPU stands for my node processor unit - a not finished design
> concept)
>
> some features
> * optimized for streaming media, that is clocked data streams (serial
> flash, SD card, etc..)
> * PC is optional
> * Stack is optional
> * minimum number of registers: 0
> * minimum size of internal RAM: 0
> * no reset pin needed (input stream can force reset)
> * operand widths: 1 to unlimited
> * address space: unlimited
> * minimal configuration : 0 LUT/0 FF (1 Block ROM + IOB F/F's)
>
> there are some compromises of course, say 32 bit ALU operation
> would take 40 clock cycles for the operation itself + some more
> clocks to select the operands and operation type. shorter operation
> will be less clock cycles, but still rather slow in terms of clock
> cycles
> otoh as the serialized nature allows operation at higher fabric speeds
> then the overall performance could be rather good.
> Quad SPI memories can stream data at 320MBit/s, in modern
> FPGA NPU2 could easily run at 320mhz, what would give some
>
> >5 MIPS for 32 bit operations what is not that bad at all
>
> the Processor is currently designed using EXCEL
>
> main problem would be the tool support, as the assembler/compiler
> would
> need to be generated based on the processor description, there is no
> fixed
> instruction set at all, and pretty much all features of the processor
> are
> configurable, also variables and constant can be of different widths,
> so the
> compiler should know how wide variables to use, not only 8/16/32 but
> they
> can really be any size with single bit granularity
>
> Antti

Hi Antti,
about the tool problem:
Do you know the TASM (Table Driven Assembler)? It's quite old, but the
concept could be useful in your case.
Extract a configuration file from the hardware description that tells
the assembler how to program the processor.
If your processor design can also be configured by a single file (e.g.
vhdl package) the assembler could either use this file too, or a table
generator could convert this file to the needed format.

Have a nice synthesis
  Eilert

Article: 139282
Subject: Re: Silicon Blue last datesheet correct URL
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Mar 2009 00:35:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 1:38=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 25, 6:39=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 24, 12:49 pm, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > On Mar 24, 6:36 pm, Prevailing over Technology <steve.kn...@prevailin=
g-
>
> > > technology.com> wrote:
> > > > On Mar 23, 9:01 am, rickman <gnu...@gmail.com> wrote:
>
> > > > > I was reading the data sheet the other day and I noticed that the=
se
> > > > > parts have 5 volt compatible I/Os on three of the four banks. =A0=
I'm
> > > > > pretty impressed with that... until I read that the fourth bank i=
s not
> > > > > even 3.3 volt tolerant!!! =A0What's up with that?
>
> > > > [snip]
>
> > > > I've talked to them about that also. =A0All I can say at this point=
 is
> > > > watch this space. =A0I think they plan on some sort of 3.3V support=
 in I/
> > > > O Bank 3.
>
> > > > [snip]
>
> > > > > One other thing I noticed, they seem to be changing the planned
> > > > > packaging, which is not surprising I suppose. =A0In the package l=
ist,
> > > > > they flag compatible pinouts using the same package. =A0But I don=
't see
> > > > > the 04 and 08 as being compatible in the 196 pin package. =A0This
> > > > > package was added since rev 1.1 of the data sheet, so it is surpr=
ising
> > > > > to me that these would not be compatible.
>
> > > > The 'L04 and 'L08 are _almost_ pin compatible in the 196-pin packag=
e.
> > > > There is a table on page 62 in the data sheet that shows the
> > > > differences. =A0The real differences are if you use differential I/=
O and
> > > > if you use the Global Buffer INput (GBIN) pins in banks 2 and 3. =
=A0If
> > > > you use single-ended I/O and direct clock inputs in those banks, th=
en
> > > > both devices are pin compatible in the 196-pin package.
>
> > > > > The CS132 package looks pretty interesting. =A0The main reason th=
at I
> > > > > avoid BGAs is the PCB requirements to provide routing from the in=
ner
> > > > > pins. =A0This package looks like it might be routable without run=
ning
> > > > > traces between the pads or even vias within the pads. =A0But the
> > > > > innermost 16 pads seem to mess this up. =A0Anyone have a good rou=
ting
> > > > > layout for this package? =A0What PCB design rules are required to=
 use
> > > > > this package?
>
> > > > There are some examples layouts from the iCEman65 development board=
.
> > > > The board uses the 284-ball chip-scale BGA package (CB284) which is=
 a
> > > > superset of the 132-ball package (CB132). =A0The inner balls are
> > > > identical.
>
> > > > A PDF version of the layout appears in the user guide beginning on
> > > > page 44.http://www.siliconbluetech.com/media/iCEmanBoardUserGuide.p=
df
>
> > > > The Gerber files are available as well. =A0Note that the link on th=
eir
> > > > website apparently points to an old version (Should be Rev. D).http=
://www.siliconbluetech.com/media/iCEman65GerbersRevB.zip
>
> > > > -- Steven K. Knapp
> > > > =A0 =A0Prevailing Technology, Inc.
> > > > =A0 =A0www.prevailing-technology.com
>
> > > Steven,
>
> > > iceMAN65 is multilayer PCB, Rick asked how i made it on 2 layers :)
>
> > > well i have to say that the SB easyBGA is not that easy, mostly
> > > because of the inner vcc/gnd pads, so most of the inner free space
> > > is wasted to route out vccint and vccio
> > > also some other pins are rather hard to route on 2 layers
>
> > > so bga 0.5 with 3 outer rows only could actually be easier
> > > as the easyBGA as it leaves large space in the middle
>
> > But with three rows, one row has to be routed between the pads of the
> > other two. =A0If you are going to do that you =A0might as well use four
> > rows. =A0Still, you need a lot of room in the middle for vias and they
> > still have to be pretty small. =A0I thought 10 mil holes were ok until
> > Sunstone "rounded up" my drill holes to 13 mils because they didn't
> > want to plate 10 mil holes. =A0Even at 13 mils they couldn't make it
> > work and some 30 % of the boards they produced did not pass electrical
> > test. =A0Then some 6% of the assembled boards had open vias after the
> > soldering process. =A0I hate to think how many of them will be failing
> > in the field. =A0Fortunately this batch was for internal testing for my
> > customer and will not be shipped to their customers. =A0Any failures
> > will be sent back to me without recriminations.
>
> > After experiences like this I am reluctant to work in very small
> > feature sizes on boards. =A0To route between pads on 0.5 mm (~20 mil)
> > centers would require what, maybe 3 or 4 mil trace/space? =A0I've never
> > pushed below 5 mil.
>
> > Rick
>
> Rick
>
> minimum hole size that is done without HDI is usually 0.3mm =3D 13mils
>
> so it was your fault if you designed with 10mils
>
> any halfway decent PCB fab should be able todo 0.3mm drilled holes
> and 6 mils track/space. you need of course immersion gold plating
> for the PCB's. my proto fab doesnt do that so for the 1 off proto
> boards
> i use chemical tinning. production boards are made in taiwan with
> immersion gold. The boards are 0.8mm thick and we have no problems
> with the yield so far.
>
> Antti

Hey, the Sunstone web site said they could do 10 mil and they took the
job.  Since then I have made over 300 of the boards with only two bad
PWBs.  There seemed to be a panel (4 boards) with a registration
problem on one of the power layers shorting V3.3 to gnd.  We saw it on
the X-ray machine and the assembly house is talking to the PWB maker
about it now.  No issues at all with the 10 mil vias.  I've never seen
anyone claim that 10 mil holes are not doable.  Some charge more for
that size, but most will do it.

I'm still using HASL lead-free finish.  With leaded parts this is a
good finish and cheap.  Of course with QFN packages leveling of the
finish is much more critical.  I like sticking with packaging with
leads, but they are getting harder to find in FPGAs, at least in the
smaller sizes.  QFP208 and TQFP144 are still easy to find, but HUGE!

Rick

Article: 139283
Subject: Transmit data with clock capable pins on Virtex5 ??
From: Heiner Litz <heinerlitz@googlemail.com>
Date: Wed, 25 Mar 2009 03:59:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
afaik it wasn't possible with Virtex4 devices to use clock capable
clock pins for differential output signaling. They could only be used
as an input or single ended output.

For Virtex5 devices I do not find this limitation in the user guide
and also the ISE does not complain.

However, I am seeing weird behavior on the receiver side which is
connected to an transmitter using such an cc pin for sending its data.

Are the CC or low capacitance pins still problematic when it comes to
transmitting data?

In my design, the CC pin (as an output) is driven by an ODDR buffer
running at 300 MHz (600Mbps).

thanks, Heiner

Article: 139284
Subject: SiliconBlue on Wikipedia
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 04:07:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I was entering FPGA in wikipedia, entered Silicon Blue, found nothing
added SiliconBlue page, as i did think it is worth of being covered,
but the censors of the wikipedia think otherwise :(

Any ideas how to convince them?
here is the page that is pending deletion (was one time deleted
already)

http://en.wikipedia.org/wiki/SiliconBlue_Technologies

maybe i am so stupid and do not understand why only the worlds 5 first
FPGA
can be included in wikipedia?

Antti

Article: 139285
Subject: Re: Fm digital baseband demodulation
From: mehta.nupur@gmail.com
Date: Wed, 25 Mar 2009 04:36:00 -0700 (PDT)
Links: << >>  << T >>  << A >>

Hi
I am final year engineering student. i am making FM receiver using
Xilinx Spartan-3 FPGA.
I have two samples I and Q.
I am facing problems in demodulating the wave.
1.The two samples are not synchronized in time then how to execute the
equation.
2.Does differenciation in digital domain mean difference between two
consecutive samples.

Thanks

Article: 139286
Subject: Re: Fm digital baseband demodulation
From: mehta.nupur@gmail.com
Date: Wed, 25 Mar 2009 05:32:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi
I am a final year engineering student. I am making a FM receiver using
XILINX Spartan-3 FPGA.
I am stuck with the demodulation block.
I have two samples I and Q.
I am facing following problems.

1.The two signals are not synchronized. Then do I need to synchronize
them for implementing the demodulation equation.Q*dI/dt - I*dQ/dt
2.Does the differentiation in digital domain means difference between
two consecutive samples?
Thanks

Article: 139287
Subject: Re: Which ISE Webpack version for S3A..?
From: gabor <gabor@alacron.com>
Date: Wed, 25 Mar 2009 05:54:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 1:53=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 25, 1:46=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
>
> > I'm about to start a project on an Spartan3A (200) in VHDL - having see=
n a few comments here about
> > ISE problems I was wondering if I'd be best using the Webpack v 9.2 tha=
t came with the devboard or
> > downloading the latest 10.1 ?
> > Is there anything in V10 that would be worth the doubtless colossal dow=
nload ?
> > Or anything sufficiently broken in either version to be a big deal?
>
> each ISE version has more bugs..
>
> one already sufficient reason to get 10.1 is that from 10.1 the
> installation folder is name properly
> ( same as Altera is doing Quartus\90\.. )
>
> now Xilinx also has
> Xilinx\10.1\ISE
> Xilinx\10.1\EDK
> ..
>
> i used to have many parallel xilinx installs and had to always rename
> the folders to reflect the version
> now this is done by the installer :)
>
> Antti

Actually for someone new to Xilinx that would be a pretty minor
reason to upgrade.  One real issue is using any demo applications
shipped with the board.  Often these have problems moving to a
newer version of ISE.  If you're starting fresh from scratch
you might want to go with the latest revision, though.

The colossal download is several gigabytes by the time you
download the service packs (they're cumulative so
you can go right to sp 3, but it's still big).  Also the
service packs come in pieces, one for ISE, one for CoreGen
(the "IP update") and another for modelsim ("MXE update)
if you use the Xilinx branded edition.

Good luck on your new project.

Gabor

Article: 139288
Subject: Re: Antti Processor
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 05:59:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 9:14=A0am, goo...@twinmail.de wrote:
> On 24 Mrz., 09:30, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > it is being developed :)
> > well it is actually NPU version 2
> > (where NPU stands for my node processor unit - a not finished design
> > concept)
>
> > some features
> > * optimized for streaming media, that is clocked data streams (serial
> > flash, SD card, etc..)
> > * PC is optional
> > * Stack is optional
> > * minimum number of registers: 0
> > * minimum size of internal RAM: 0
> > * no reset pin needed (input stream can force reset)
> > * operand widths: 1 to unlimited
> > * address space: unlimited
> > * minimal configuration : 0 LUT/0 FF (1 Block ROM + IOB F/F's)
>
> > there are some compromises of course, say 32 bit ALU operation
> > would take 40 clock cycles for the operation itself + some more
> > clocks to select the operands and operation type. shorter operation
> > will be less clock cycles, but still rather slow in terms of clock
> > cycles
> > otoh as the serialized nature allows operation at higher fabric speeds
> > then the overall performance could be rather good.
> > Quad SPI memories can stream data at 320MBit/s, in modern
> > FPGA NPU2 could easily run at 320mhz, what would give some
>
> > >5 MIPS for 32 bit operations what is not that bad at all
>
> > the Processor is currently designed using EXCEL
>
> > main problem would be the tool support, as the assembler/compiler
> > would
> > need to be generated based on the processor description, there is no
> > fixed
> > instruction set at all, and pretty much all features of the processor
> > are
> > configurable, also variables and constant can be of different widths,
> > so the
> > compiler should know how wide variables to use, not only 8/16/32 but
> > they
> > can really be any size with single bit granularity
>
> > Antti
>
> Hi Antti,
> about the tool problem:
> Do you know the TASM (Table Driven Assembler)? It's quite old, but the
> concept could be useful in your case.
> Extract a configuration file from the hardware description that tells
> the assembler how to program the processor.
> If your processor design can also be configured by a single file (e.g.
> vhdl package) the assembler could either use this file too, or a table
> generator could convert this file to the needed format.
>
> Have a nice synthesis
> =A0 Eilert

sure I know TASM (I even know things like TenDRA...),
i think i even tried to buy the source code (was offered for 30$?)
but TASM would really not do the job, the opcodes would be
of variable size and that TASM would not handle for sure

the tools just need little thinking, they doable for sure

Antti





Article: 139289
Subject: Re: FPGAs in automotive apps
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 25 Mar 2009 13:03:55 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> On Mar 24, 5:02 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>> rickman <gnu...@gmail.com> writes:
>> > That makes some sense I suppose.  But the automotive market is not
>> > one of the places I would expect to see many FPGAs.  Even if they
>> > are low power, why does an auto maker need the flexibility of
>> > reconfiguration?  Their volumes are high enough that they can spin
>> > low cost ASICs at large feature sizes which keeps the NRE down
>> > compared to FPGAs.
>>
>> You might be surprised :) (sorry if this is a bit blatant, but it's on
>> topic...http://www.conekt.net/fpgas-for-ldw.html)
>>
>> And being able to reconfigure is not a bad thing - we also use a lot
>> of flash micros, rather than ROMming everything.
>
> Yup, it makes sense when the cost of reconfigurability is just the
> cost of the memory.  

But the memory is a v. large proportion of the die area on most of the
micros (that I have contact with anyway).  

> But does it make sense when reconfigurability makes the logic cost
> 10 times as much?
>
> I looked at your web page and I expect this is a prototype, no?  Do
> you plan to go into production with a $10+ FPGA when you could use a
> $2 ASIC?  

This is in production.  We put a fair amount of clever engineering
(IMNSHO :) into fitting it into a small FPGA.

http://trw.mediaroom.com/index.php?s=43&item=367.  

> But then again, a "Lane Departure Warning System" wouldn't
> really be installed in many autos would it?  At least, not until the
> cost comes down by using ASICs instead of FPGAs...
>
> Am I wrong about this?
>

I'm not going to give you prices, but trust me, we know what we're
doing :)

>
>> > Autos are using a lot of DSP and higher end embedded processors.
>> > Otherwise, I don't see autos pushing semi technology.  Yeah, chips
>> > will be made to fit all those sockets, but the use of technology is
>> > mainly to cut the cost to the bone and FPGAs will never fit that
>> > socket.
>>
>> You can get an awful lot of FPGA for the price of a DSP these days.
>> And if you've been thinking highly parallel all the way through
>> development, you can do a lot more with them (IMHO :)
>
> Yes, but what can you do in an FPGA that you can't do in an ASIC, even
> just a gate array, that wouldn't be much cheaper in high quantities?
> Sure, the costs of FPGAs have come down over the years and there are
> clearly some reasons to use FPGA, even in some high volume products.
> But I don't see any of those reasons applying to auto usage other than
> perhaps "special" features that you only see in Cadillacs and high end
> Mercedes.
>
> I'm happy to be corrected.  I just don't see where autos are an
> application where FPGAs will have much of a market for the foreseeable
> future.  What feature of FPGAs make them a primary solution for a high
> volume automotive product?
>

It's the same as flash based micros - when they were first available
they were for prototype-only - no-one would seriously go to
production, they'd ROM the code!  Now look at them...  flash micros abound.

By the time these driver assistance features are on the *really*
high-volume vehicles FPGAs will be even cheaper than they are now.

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 139290
Subject: Re: Help Needed Regarding VPR
From: 'use_real_email'
Date: Wed, 25 Mar 2009 07:06:50 -0700
Links: << >>  << T >>  << A >>

HI

I need some help regarding the switch box architecture modification.
The architecture file allows me to configure for number of inputs,
clustering, selection of switch box type etc, but is it possible to
modify the switch box architecture and define another type of switch box
that I may use in the architecture file? I have one more question. Does
the tool help in identifying long paths and displaying back the same
information to the user with the corresponding pin numbers or any other
detail about the blocks connected by that long path? I have gone through
all the files and have searched for information in the internet but am
not able to find out answers to my questions. 

If anyone got information about this, It will be very helpful if you
kindly post a reply.

Thank you.


-- 
sush10
------------------------------------------------------------------------
sush10's Profile: http://www.fpgacentral.com/group/member.php?userid=45
View this thread: http://www.fpgacentral.com/group/showthread.php?t=56850


Article: 139291
Subject: Re: FPGAs in automotive apps
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Mar 2009 08:41:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 9:03=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Mar 24, 5:02=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote=
:
> >> rickman <gnu...@gmail.com> writes:
> >> > That makes some sense I suppose. =A0But the automotive market is not
> >> > one of the places I would expect to see many FPGAs. =A0Even if they
> >> > are low power, why does an auto maker need the flexibility of
> >> > reconfiguration? =A0Their volumes are high enough that they can spin
> >> > low cost ASICs at large feature sizes which keeps the NRE down
> >> > compared to FPGAs.
>
> >> You might be surprised :) (sorry if this is a bit blatant, but it's on
> >> topic...http://www.conekt.net/fpgas-for-ldw.html)
>
> >> And being able to reconfigure is not a bad thing - we also use a lot
> >> of flash micros, rather than ROMming everything.
>
> > Yup, it makes sense when the cost of reconfigurability is just the
> > cost of the memory. =A0
>
> But the memory is a v. large proportion of the die area on most of the
> micros (that I have contact with anyway). =A0
>
> > But does it make sense when reconfigurability makes the logic cost
> > 10 times as much?
>
> > I looked at your web page and I expect this is a prototype, no? =A0Do
> > you plan to go into production with a $10+ FPGA when you could use a
> > $2 ASIC? =A0
>
> This is in production. =A0We put a fair amount of clever engineering
> (IMNSHO :) into fitting it into a small FPGA.
>
> http://trw.mediaroom.com/index.php?s=3D43&item=3D367. =A0
>
> > But then again, a "Lane Departure Warning System" wouldn't
> > really be installed in many autos would it? =A0At least, not until the
> > cost comes down by using ASICs instead of FPGAs...
>
> > Am I wrong about this?
>
> I'm not going to give you prices, but trust me, we know what we're
> doing :)
>
>
>
>
>
> >> > Autos are using a lot of DSP and higher end embedded processors.
> >> > Otherwise, I don't see autos pushing semi technology. =A0Yeah, chips
> >> > will be made to fit all those sockets, but the use of technology is
> >> > mainly to cut the cost to the bone and FPGAs will never fit that
> >> > socket.
>
> >> You can get an awful lot of FPGA for the price of a DSP these days.
> >> And if you've been thinking highly parallel all the way through
> >> development, you can do a lot more with them (IMHO :)
>
> > Yes, but what can you do in an FPGA that you can't do in an ASIC, even
> > just a gate array, that wouldn't be much cheaper in high quantities?
> > Sure, the costs of FPGAs have come down over the years and there are
> > clearly some reasons to use FPGA, even in some high volume products.
> > But I don't see any of those reasons applying to auto usage other than
> > perhaps "special" features that you only see in Cadillacs and high end
> > Mercedes.
>
> > I'm happy to be corrected. =A0I just don't see where autos are an
> > application where FPGAs will have much of a market for the foreseeable
> > future. =A0What feature of FPGAs make them a primary solution for a hig=
h
> > volume automotive product?
>
> It's the same as flash based micros - when they were first available
> they were for prototype-only - no-one would seriously go to
> production, they'd ROM the code! =A0Now look at them... =A0flash micros a=
bound.

You miss the point.  Flash micros are in production products because
there is very little price differential with metal layer ROM devices.
Otherwise the ROM parts would "abound" in high volume products.


> By the time these driver assistance features are on the *really*
> high-volume vehicles FPGAs will be even cheaper than they are now.

Yes, and the bean counters at every company will be beating you
mercilessly to cut every penny from the cost.  When you are facing the
loss of a $10M contract because you need to cut the cost by another
$1, the decision will be made to go with an ASIC.  How else are you
going to cut the cost of this product otherwise?

You can say you "know what you are doing", but the economics are what
they are.  If your company sells a high volume product using an FPGA
instead of an ASIC, when you don't need reconfigurability, you are
leaving money on the table.  Not many CEOs like that idea.

Is there some rational for not designing an ASIC for a high volume
product that is out of development and meets all specs?  Don't tell me
you are doing it, tell me *why* you are doing it.  Companies make
mistakes all the time.  I would like to know the reason for this
decision or if it is just a temporary choice and will change as the
volumes increase.

Rick

Article: 139292
Subject: Re: Which ISE Webpack version for S3A..?
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Wed, 25 Mar 2009 09:15:43 -0700
Links: << >>  << T >>  << A >>
On Tue, 24 Mar 2009 22:53:41 -0700 (PDT)
"Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com> wrote:

> On Mar 25, 1:46=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> > I'm about to start a project on an Spartan3A (200) in VHDL - having
> > seen a few comments here about ISE problems I was wondering if I'd
> > be best using the Webpack v 9.2 that came with the devboard or
> > downloading the latest 10.1 ? Is there anything in V10 that would
> > be worth the doubtless colossal download ? Or anything sufficiently
> > broken in either version to be a big deal?
>=20
> each ISE version has more bugs..
> [snip]
>=20

See, my experience has been that the back-end tools (XST, MAP, PAR, etc)
really have been improving with each version.  Certainly they're
getting smarter: my designs synthesize more closely to how I expect
they will, and ultimately fit onto fewer slices with better timing
margins.  Then again, I haven yet to make heads or tails of the
"partition" interface, and so can't speak to whether that's worth
anything.

The front-end is the real kicker.  The GUI in my experience bogs down
your machine fantastically simply by having it open; and god forbid
you're actually trying to do anything with it.  That's where each rev.
comes with more features, less testing, and more problems.  But for
those of us with Makefile build processes (and probably those weirdos
with TCL builds), I'd say the best place to start your Xilinx
experience is with the latest and greatest.  1.5GB for Webpack 10, and
another 1.5GB for all the service packs.  Start 'em downloading
overnight, don't _dream_ of using the WebInstall.  And Mike, since
you're just starting out, do yourself a favor by learning to work with
a command line build process right from the get-go.  Google will
happily give you advice on "xilinx makefile" or "xilinx tcl".=20

--=20
Rob Gaddi, Highland Technology
Email address is currently out of order


Article: 139293
Subject: Re: Which ISE Webpack version for S3A..?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 09:26:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 6:15=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> On Tue, 24 Mar 2009 22:53:41 -0700 (PDT)
>
> "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote:
> > On Mar 25, 1:46=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> > > I'm about to start a project on an Spartan3A (200) in VHDL - having
> > > seen a few comments here about ISE problems I was wondering if I'd
> > > be best using the Webpack v 9.2 that came with the devboard or
> > > downloading the latest 10.1 ? Is there anything in V10 that would
> > > be worth the doubtless colossal download ? Or anything sufficiently
> > > broken in either version to be a big deal?
>
> > each ISE version has more bugs..
> > [snip]
>
> See, my experience has been that the back-end tools (XST, MAP, PAR, etc)
> really have been improving with each version. =A0Certainly they're
> getting smarter: my designs synthesize more closely to how I expect
> they will, and ultimately fit onto fewer slices with better timing
> margins. =A0Then again, I haven yet to make heads or tails of the
> "partition" interface, and so can't speak to whether that's worth
> anything.
>
> The front-end is the real kicker. =A0The GUI in my experience bogs down
> your machine fantastically simply by having it open; and god forbid
> you're actually trying to do anything with it. =A0That's where each rev.
> comes with more features, less testing, and more problems. =A0But for
> those of us with Makefile build processes (and probably those weirdos
> with TCL builds), I'd say the best place to start your Xilinx
> experience is with the latest and greatest. =A01.5GB for Webpack 10, and
> another 1.5GB for all the service packs. =A0Start 'em downloading
> overnight, don't _dream_ of using the WebInstall. =A0And Mike, since
> you're just starting out, do yourself a favor by learning to work with
> a command line build process right from the get-go. =A0Google will
> happily give you advice on "xilinx makefile" or "xilinx tcl".
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order

super!

yes i forgot to say NONO regarding the webinstall.
just get all the install files local, and install then...

as of makefile, can also look at the gui logs and copy paste
from there, its not that complicate.

but with decent computer and small projects its ok to work
from gui too

Antti

Article: 139294
Subject: USB PHY
From: bhavanireddy@gmail.com
Date: Wed, 25 Mar 2009 09:39:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

While searching for USB IP resources on the net I came across USB PHY
cores in verilog.


1) Why is it neessary to seperate USB controller and PHY in two
different cores? It may be necessary for 3.0 due to higher speeds but
what is the need for 1.1 and 2.0?
2) If USB PHY is a mixed (Analog & Digital) solution how can it be
offered only in verilog as developer claims?
How can a mixed core (GDSII and HDL) be implemented in FPGA?
3) If I have the USB and USB PHY cores seperately how do I implement
in FPGA and use/test it?


See the description of USB 1.1 PHY core from www.asics.ws. .


Thanks in advance.
br


***************************************************************************=
=AD
*****************************************************
"USB 1.1 PhyUSB 1.1 Physical Interface core. This core provides all
functions essential to interface to the USB 1.1 bus. This includes
serial/parallel conversion, bit stuffing and unstuffing, NRZI
encoding
and decoding and a DPLL. It comes with a industry standard UTMI
interface for easy portability


Sample Implementation Results
Technology Area Speed
Xilinx Spartan 2 xc2s50-6 111 LUTs (30%)  > 50 MHz


Currently this IP Core is available in Verilog only."
***************************************************************************=
=AD
*****************************************************

Article: 139295
Subject: Re: USB PHY
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 09:55:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 6:39=A0pm, bhavanire...@gmail.com wrote:
> Hi,
>
> While searching for USB IP resources on the net I came across USB PHY
> cores in verilog.
>
> 1) Why is it neessary to seperate USB controller and PHY in two
> different cores? It may be necessary for 3.0 due to higher speeds but
> what is the need for 1.1 and 2.0?
> 2) If USB PHY is a mixed (Analog & Digital) solution how can it be
> offered only in verilog as developer claims?
> How can a mixed core (GDSII and HDL) be implemented in FPGA?
> 3) If I have the USB and USB PHY cores seperately how do I implement
> in FPGA and use/test it?
>
> See the description of USB 1.1 PHY core fromwww.asics.ws. .
>
> Thanks in advance.
> br
>
> *************************************************************************=
**=AD
> *****************************************************
> "USB 1.1 PhyUSB 1.1 Physical Interface core. This core provides all
> functions essential to interface to the USB 1.1 bus. This includes
> serial/parallel conversion, bit stuffing and unstuffing, NRZI
> encoding
> and decoding and a DPLL. It comes with a industry standard UTMI
> interface for easy portability
>
> Sample Implementation Results
> Technology Area Speed
> Xilinx Spartan 2 xc2s50-6 111 LUTs (30%) =A0> 50 MHz
>
> Currently this IP Core is available in Verilog only."
> *************************************************************************=
**=AD
> *****************************************************

those FPGA USB IP cores "PHY" are not the actual PHY actually
the USB PHY can not be done with any FPGA reliable, only FPGA's
with USB PHY are the CSSP stuff from QuickLogic

what is referenced as USB PHY is the lower lever USB IP just before
the actual PHY, that in that case the PHY is really a dumb tranceiver
only

there are hobby projects also where the USB pins are connected
directly
to FPGA also, but this possible violates some of the operationg specs.
one such project used a special 1 bt soft core processor to perform
usb host task (keyboard only)

Antti














Article: 139296
Subject: Re: Which ISE Webpack version for S3A..?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 25 Mar 2009 17:41:41 +0000
Links: << >>  << T >>  << A >>
On Wed, 25 Mar 2009 09:26:20 -0700 (PDT), "Antti.Lukats@googlemail.com"
<Antti.Lukats@googlemail.com> wrote:

>On Mar 25, 6:15 pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
>> On Tue, 24 Mar 2009 22:53:41 -0700 (PDT)
>>
>> "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote:
>> > On Mar 25, 1:46 am, Mike Harrison <m...@whitewing.co.uk> wrote:
>> > > I'm about to start a project on an Spartan3A (200) in VHDL - having
>> > > seen a few comments here about ISE problems I was wondering if I'd
>> > > be best using the Webpack v 9.2 that came with the devboard or
>> > > downloading the latest 10.1 ? Is there anything in V10 that would
>> > > be worth the doubtless colossal download ? Or anything sufficiently
>> > > broken in either version to be a big deal?
>>
>> > each ISE version has more bugs..
>> > [snip]
>>
>> See, my experience has been that the back-end tools (XST, MAP, PAR, etc)
>> really have been improving with each version.  Certainly they're
>> getting smarter: my designs synthesize more closely to how I expect
>> they will, and ultimately fit onto fewer slices with better timing
>> margins.  Then again, I haven yet to make heads or tails of the
>> "partition" interface, and so can't speak to whether that's worth
>> anything.
>>
>> The front-end is the real kicker.  The GUI in my experience bogs down
>> your machine fantastically simply by having it open; and god forbid
>> you're actually trying to do anything with it.  That's where each rev.
>> comes with more features, less testing, and more problems.  But for
>> those of us with Makefile build processes (and probably those weirdos
>> with TCL builds), I'd say the best place to start your Xilinx
>> experience is with the latest and greatest.  1.5GB for Webpack 10, and
>> another 1.5GB for all the service packs.  Start 'em downloading
>> overnight, don't _dream_ of using the WebInstall.  And Mike, since
>> you're just starting out, do yourself a favor by learning to work with
>> a command line build process right from the get-go.  Google will
>> happily give you advice on "xilinx makefile" or "xilinx tcl".
>>
>> --
>> Rob Gaddi, Highland Technology
>> Email address is currently out of order
>
>super!
>
>yes i forgot to say NONO regarding the webinstall.
>just get all the install files local, and install then...
>
>as of makefile, can also look at the gui logs and copy paste
>from there, its not that complicate.
>
>but with decent computer and small projects its ok to work
>from gui too
>
>Antti

Thanks for the info - did a hobby project on S3 with ISE 6 a couple of years ago & compile cycle was
tolerable - I do like a fast change-compile-run cycle so I'll investigate command-line options.
Setting up via GUI and then creating a makefile from that looks like a good idea. 



Article: 139297
Subject: Re: Using SelectIO LVDS to drive 40 inch backplane trace
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 25 Mar 2009 11:08:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have worked on LVDS over similar distances, and bus wide backplane
structures, but only in 400-500Mbit/s zone. It worked fine in those
circumstances. Main consideration is to avoid skew in pair length and
between pairs if using multiple pairs. Matching will make data
recovery simple. Using a source synchronous clock roiuted with data
will also make life a lot easier.

Ultimately the trace capacitance will probably be the limiting thing
and a trade of speed versus maximum length will exist. Ensuring that
the the 2 traces of a pair run togther as much as possible will be
important. Minimising discontinuities like connectors is good
practise.

John Adair
Enterpoint Ltd.

On 24 Mar, 06:16, Goli <tog...@gmail.com> wrote:
> Hi,
>
> I am designing a system which needs multiple interfaces (about 16) to
> backplane running at about ~700Mhz. These are going to be source
> synchronous interfaces and clock will be available. =A0I did not wanted
> to use the build in transceivers because the 20 transceiver devices
> are very expensive. The logic and block Ram requirement of the design
> is relatively small.
>
> I was wondering if for Xilinx FPGA can I use the normal LVDS select IO
> pins to drive the backplane. Will it work? Are there any design
> consideration that I need to take to accomplish this. What is the
> maximum trace that the select LVDS IO can drive.
>
> Also wondering if there is any difference between Xilinx and Altera
> LVDS, if either or one of them is suited for backplane applications.
>
> Cheers.
>
> --
> Goli


Article: 139298
Subject: Re: USB PHY
From: bhavanireddy@gmail.com
Date: Wed, 25 Mar 2009 11:14:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
> what is referenced as USB PHY is the lower lever USB IP just before
> the actual PHY, that in that case the PHY is really a dumb tranceiver
> only

Thanks Antti. I will check QucikLogic stuff. In the aove case why
can't that be part of USB controller core rather than a seperate core
before PHY tranciever?

> there are hobby projects also where the USB pins are connected
> directly
> to FPGA also, but this possible violates some of the operationg specs.
> one such project used a special 1 bt soft core processor to perform
> usb host task (keyboard only)

OK.

> Antti- Hide quoted text -
>
> - Show quoted text -


Article: 139299
Subject: Re: USB PHY
From: Muzaffer Kal <kal@dspia.com>
Date: Wed, 25 Mar 2009 11:15:04 -0700
Links: << >>  << T >>  << A >>
On Wed, 25 Mar 2009 09:39:01 -0700 (PDT), bhavanireddy@gmail.com
wrote:

>Hi,
>
>While searching for USB IP resources on the net I came across USB PHY
>cores in verilog.
>
>
>1) Why is it neessary to seperate USB controller and PHY in two
>different cores? It may be necessary for 3.0 due to higher speeds but
>what is the need for 1.1 and 2.0?

The difference is the speed. USB 1.1 is 12 Mb/s and the "PHY" is
basically three CMOS receivers (two single ended and one differential)
and a tri-state CMOS drive so implementing the digital portion of the
PHY in RTL is feasible. The analog portion of the PHY can be
implemented by the standard IOs one can find on an FPGA in most cases
even though it may not be fully compliant.
USB 2.0 (at least  high speed portion thereof) is 480 Mb/s and need
special IO for both receiver and transmitter and this IO doesn't exist
on any FPGA I know of. Also there are quite challenging clock recovery
requirements which make even implementation of the "digital" portion
of the PHY challenging. 
Interestingly USB 3.0 is quite similar to PCI Express and we may see
full implementations in FPGAs.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.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