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 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! RickArticle: 139276
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. RickArticle: 139277
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. AnttiArticle: 139278
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 :) AnttiArticle: 139279
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 AnttiArticle: 139280
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 /MHArticle: 139281
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 EilertArticle: 139282
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! RickArticle: 139283
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, HeinerArticle: 139284
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? AnttiArticle: 139285
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. ThanksArticle: 139286
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? ThanksArticle: 139287
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: 139288On 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 AnttiArticle: 139289
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.htmlArticle: 139290
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=56850Article: 139291
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. RickArticle: 139292
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 orderArticle: 139293
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 AnttiArticle: 139294
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
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) AnttiArticle: 139296
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
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. > > -- > GoliArticle: 139298
> 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
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:
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