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
I'v APA1000 device and FlashPro3..... After Layout using Libero designer, i check the SMART POWER for power consumption... Only 50mW But On the board which is designed for another application, The APA1000 heating!!!! :( The power consumption is about 0.4A at 3.3V.... --> 1.32W... Core voltage is 1.5V. IO voltage is 3.3V. But the programming of device on that board is successfull!!! also, APA100 heated....Can't touch... And function didn't operate..... what's the matter? Verified after programming... How's your thinking? Plz, Let me know your experience......Help me.. T___TArticle: 111801
"Anonymous" <someone@microsoft.com> wrote in message
news:Px%4h.33906$39.30129@southeast.rr.com...
> Can anyone tell me why the default width for the PLB in EDK is 64-bits
> when
> the PPC is a 32-bit processor? I have nothing in my design that is 64 bits
> wide.
One simple reason off the top of my head: the PowerPC might only have 32-bit
regsiters internally, but its instruction and data caches fetch data in
blocks of 128 bits at a time. So a 64-bit bus allows them twice the
bandwidth to/from memory compared with a 32-bit bus.
Cheers,
-Ben-
Article: 111802"Ben Jones" <ben.jones@xilinx.com> wrote in message news:ej22e2$qq01@cnn.xsj.xilinx.com... > > "Anonymous" <someone@microsoft.com> wrote in message > news:Px%4h.33906$39.30129@southeast.rr.com... > > Can anyone tell me why the default width for the PLB in EDK is 64-bits > > when > > the PPC is a 32-bit processor? I have nothing in my design that is 64 bits > > wide. > > One simple reason off the top of my head: the PowerPC might only have 32-bit > regsiters internally, but its instruction and data caches fetch data in > blocks of 128 bits at a time. So a 64-bit bus allows them twice the > bandwidth to/from memory compared with a 32-bit bus. > > Cheers, > > -Ben- > > In my case, though, I have a 16-wide DDR as my main memory running at 100 MHz (same speed as the cpu). So my bandiwdth is limited to 400 MByte/s regardless of the PLB right? Seems like the 64-bit plb is only helpful if you have a 64-bit memory source. Even the block rams can't be configured for 64 wide? Thanks, ClarkArticle: 111803
Hi all, I have problems with runnig a DDR test on Spartan3E SK. I rebuild one of the reference designs in EDK 8.2: http://www.xilinx.com/products/boards/s3estarter/files/Xil3S500E_Serial_Flash_v81.zip I have three boards and 2 do not pass the test. I have about the same problems with a Virtex4 MiniModule and the design with opb_ddr. Did anyone else experienced the same problems? Cheers, GuruArticle: 111804
shaz.pecobian@gmail.com wrote: > > hi > im going to develop adders,multipliers,dividers as they r somewht tough > but added advantage of high precision etc.and thenplanning to make an > fir filter based on them......i have got the idea from a no. of > research papers who have implemented thm...i am new to this field and i > have generated some code for this also(for swapping and alignment > before actual addition) but getting constraints of i/p o/p pins etc.so > due to being new ,i cant generate some code that is efficient enough > requiring less pins or memory.. > It doesn't really make sense to use floating point for a FIR filter. The only reason to do so is if the scale of the input is unknown, which in most cases means you haven't done your homework. Here's the reason for my assertion: A FIR filter is a sum of products, each product being the product of a constant and the input (delayed). Addition requires the addends to all be scaled so that the radix point is in the same position for every addend. Floating point arithmetic accomplishes this by right shifting the smaller addend, discarding (and usually rounding) the lsb's shifted off the right end of the addend. Therefore the precision of the sum is the same as the precision of the larger addend. If you extend this to a sum of many addends, the total sum again has no better precision than the largest addend (and in fact will usually have less due to right shifts needed to prevent overflow). If you implement the adder structure found in an FIR filter as floating point, you are needlessly denormalizing and renormalizing between each adder, which greatly increases the complexity of the circuit with no real advantage: your precision is limited to the width of the mantissa. The floating point multiplier is only slightly more complicated than a fixed point multiplier. The FIR filter coefficients are generally constants (adaptive filters are the exception), so the floating point multiplier for the FIR filter taps is essentially a fixed point multiplication of the mantissa and a fixed add to the exponent. You can reduce the precision of the multipliers in a fixed point filter if you normalize the coefficients, multiplying the delayed inputs by the mantissa of the coefficient and then hardwiring a shift at the multiplier output to account for the coefficient's exponent. The only fly in the ointment is if the input varies over a very wide range, which is not the case for most DSP applications.Article: 111805
kanglc@gmail.com wrote: > Hi, > > Is there a way to use partition for top-level edif flow? (Synthesis: > Synplify_premier) > > Since there is only one edif design file, how do we set partition for > lower level module? > > Thanks! > You can synthesize in parts leaving your lower module(s) as black boxes in the top level. Just leave the source for the lower module that you want a separate edif for out of the file list in the top level project, and then create another project with that module as the top level. Make sure you disable i/o insertion and clock buffer insertion for your lower level module, otherwise xilinx will throw an error when it tries to stitch the edifs together.Article: 111806
Al wrote:
> How these muxes look like? Is there any scheme they are arranged? I can
> imagine it, but I need to understand how many resources that will
> require. Do you suggest to try to implement it and then look at the rtl
> view? Can I foresee some structure?
Sure. Try it and see.
It's all LUTs and flops now.
But also look at my netlist .pdfs.
You will see lots of muxes, but
all of them are inferred from ordinary
conditional statements. No Zs required.
-- Mike Treseler
Article: 111807Anonymous wrote: > "Ben Jones" <ben.jones@xilinx.com> wrote in message > news:ej22e2$qq01@cnn.xsj.xilinx.com... > > > > "Anonymous" <someone@microsoft.com> wrote in message > > news:Px%4h.33906$39.30129@southeast.rr.com... > > > Can anyone tell me why the default width for the PLB in EDK is 64-bits > > > when > > > the PPC is a 32-bit processor? I have nothing in my design that is 64 > bits > > > wide. > > > > One simple reason off the top of my head: the PowerPC might only have > 32-bit > > regsiters internally, but its instruction and data caches fetch data in > > blocks of 128 bits at a time. So a 64-bit bus allows them twice the > > bandwidth to/from memory compared with a 32-bit bus. > > > > Cheers, > > > > -Ben- > > > > > > In my case, though, I have a 16-wide DDR as my main memory running at 100 > MHz (same speed as the cpu). So my bandiwdth is limited to 400 MByte/s > regardless of the PLB right? Seems like the 64-bit plb is only helpful if > you have a 64-bit memory source. Even the block rams can't be configured for > 64 wide? > > Thanks, > Clark And here's where the beauty of FPGA's comes in. You can just try it an see if it is faster! You're right, you could probably use a 32 bit bus. But perhaps 64 bit data ties up the plb bus less. Or two cycles of 32 bit data causes some sort of funny stall in the ppc. Or maybe there isn't much difference in size between 64 bits and 32 bits. (And 64 bit brams can be made with two 32 bit brams). Alan NishiokaArticle: 111808
S-III L == V5LX S-III E == V5SX S-III GX == V5xxT 1000-unit pricing starts at $549 for the EP3SL150 Quartus WebPack support for S-III to be available on 4 DEC 2006 AnttiArticle: 111809
Hello I have got a problem in SERDES chip selection that I would be grateful if someone helps me in this regard. First, I explain the system that we have. We want to design an STM-4 SDH system which has 5 tributary cards and 1 optical STM-4 line card.The tributary cards are of two types : E1 card and data card. The E1 tributary card which contains an SDH E1 mapper, has a 12-pin telecombus in 19.44 MHz rate in each of its transmit and receive directions (each card has 24 pins in backplane). but the Data tributary card which contains an EoS device on itself, has a 12-pin telecombus in 77.76MHz rate in each of the transmit and receive directions.The pslot of the optical line card is fixed but each of the tributary cards can sit in any position of the 5 tributary slots. to reduce the number of the pins on the backplane we want to serialize the telecombuses between the optical line card and the tributary cards. Since we do not know which of the tributary cards is inserted in in each slot we should select a SERDES which can serialize the data from both of the rates of 19.44 and 77.76 MHz (But during my searches in different vendors I haven't been able to find such a chip). I have got 2 questions. 1- As I have seen in different vendors pages, most of the SERDES devices are placed after a protocol device. for transmitting SDHArticle: 111810
> > > > In my case, though, I have a 16-wide DDR as my main memory running at 100 > > MHz (same speed as the cpu). So my bandiwdth is limited to 400 MByte/s > > regardless of the PLB right? Seems like the 64-bit plb is only helpful if > > you have a 64-bit memory source. Even the block rams can't be configured for > > 64 wide? > > > > Thanks, > > Clark > > > And here's where the beauty of FPGA's comes in. You can just try it an > see if it is faster! > Actually, turns out you can't. I just realized that it is hard coded to 64 bits. I'm going to try putting everything on the opb side so that the only thing on the plb is the plb2opb bridge to see if I save resources and power. Since PLB, OPB, CPU, and my DDR SDRAM are all running at 100 MHz I still don't see how a wide PLB would help? The only way it would seem to be helpful is if the external memories ran faster than the PLB. For example, if my 32-bit memory ran at 200 MHz, the PLB would only have to run at 100 MHz to retain the bandwidth. Of course, the opposite scenario is more likely (slow external, fast internal). If I ran my CPU at twice the plb frequency the plb bandwidth would match the cpu bandwidth but this only works if me external memory bandiwdth also matches otherwise the only speed up is when running from the on-chip cache which doesan't use the plb anyway? There has to be a reason xilinx forces 64-bit. Is it getting data AND instructions in parallel? Thanks, ClarkArticle: 111811
I also sometimes have the impression, that Q seems to produce strange results: I observed, that a design was not fitable anymore after having changed some minimal paramters, which only should have affected the number machine cycles. Doing re resynthesis suddenly met the time reqs again. (?) What I also sometimes recognize: The time for producing a design differs allthough done at the same machine (no other tasks running than Q). A recent (small) design used to be ready after typically 30-40min, but sometimes it took more than 60mins (no incremental compilation used).Article: 111812
Anonymous schrieb: > > > > > > In my case, though, I have a 16-wide DDR as my main memory running at > 100 > > > MHz (same speed as the cpu). So my bandiwdth is limited to 400 MByte/s > > > regardless of the PLB right? Seems like the 64-bit plb is only helpful > if > > > you have a 64-bit memory source. Even the block rams can't be configured > for > > > 64 wide? > > > > > > Thanks, > > > Clark > > > > > > And here's where the beauty of FPGA's comes in. You can just try it an > > see if it is faster! > > > > Actually, turns out you can't. I just realized that it is hard coded to 64 > bits. I'm going to try putting everything on the opb side so that the only > thing on the plb is the plb2opb bridge to see if I save resources and power. > Since PLB, OPB, CPU, and my DDR SDRAM are all running at 100 MHz I still > don't see how a wide PLB would help? > > The only way it would seem to be helpful is if the external memories ran > faster than the PLB. For example, if my 32-bit memory ran at 200 MHz, the > PLB would only have to run at 100 MHz to retain the bandwidth. Of course, > the opposite scenario is more likely (slow external, fast internal). > > If I ran my CPU at twice the plb frequency the plb bandwidth would match the > cpu bandwidth but this only works if me external memory bandiwdth also > matches otherwise the only speed up is when running from the on-chip cache > which doesan't use the plb anyway? > > There has to be a reason xilinx forces 64-bit. Is it getting data AND > instructions in parallel? > > Thanks, > Clark there is exactly one and very simple reason: IBM CoreConnect defines PLB as 64 bit bus. Xilinx is bound to CoreConnect standard. Simple as that. PPC405 hard macro PLB DBUS *IS* 64 bits If it makes sense to have 64 bit bus when max external memory width is only 16 is another thing. AnttiArticle: 111813
Anonymous wrote: > > > > > > In my case, though, I have a 16-wide DDR as my main memory running at > 100 > > > MHz (same speed as the cpu). So my bandiwdth is limited to 400 MByte/s > > > regardless of the PLB right? Seems like the 64-bit plb is only helpful > if > > > you have a 64-bit memory source. Even the block rams can't be configured > for > > > 64 wide? > > > > > > Thanks, > > > Clark > > > > > > And here's where the beauty of FPGA's comes in. You can just try it an > > see if it is faster! > > > > Actually, turns out you can't. I just realized that it is hard coded to 64 > bits. I'm going to try putting everything on the opb side so that the only > thing on the plb is the plb2opb bridge to see if I save resources and power. > Since PLB, OPB, CPU, and my DDR SDRAM are all running at 100 MHz I still > don't see how a wide PLB would help? > > There has to be a reason xilinx forces 64-bit. Is it getting data AND > instructions in parallel? Thinking about it some more, the reason it is 64 bits is the ppc405 core from ibm is 64 bits. http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/3D7489A3704570C0872571DD0065934E/$file/PPC405_Product_Overview_20060902.pdf The ppc has two plb interfaces so it can get data and instructions at the same time, but you probably have them both hooked up to the same bus. But this is probably not making much of a difference in size or speed anyway. Alan NishiokaArticle: 111814
hikmetkoca schrieb: > Hello, > > Is there anyone who interface the C3188A - 1/3" Digital Output Colour > Camera Module with an fpga. > I am waiting for your answers. > > Thanks there is one tool you need, it is called "soldering iron". AnttiArticle: 111815
Since STM4 is only 622 Mb/s and you're posting on the FPGA board, you can apply a SerDes from just about any FPGA to get to your rate Many families will also support 622 Mb/s in the standard I/Os. The STM-4 rate is a target for most FPGA vendors so they'll shoot at this as an achievable maximum on standard I/O and a minimum on the SerDes as well. The SerDes are often used after the protocol layer but isn't needed in an application with protocol. The FPGAs have this functionality as a more generic function than you might perceive. Two cautions for your application: First, the clocks must be supplies separately for your links; the FPGA logic doesn't deal well with plesiochronous signals alone though some SerDes blocks might support some form of clock recovery. If you have the local clock available and can communicate that clock with the 622 Mb/s data, you should be in good shape. Second, these signals can *not* be used for timing. The jitter requirements for the SDH signals are sincerely more strict that what you should expect from the FPGAs. As with most SDH designs, you should only introduce signals onto the line that are within the ITU-T jitter limits. As long as all your data shuffling is internal to your system and you're retimed for all your transmitters with the appropriate low-jitter circuitry, today's FPGAs can really carry you well. Oh - and did you have two questions? - John_H "Arash" <arash.majd@gmail.com> wrote in message news:1163175421.380944.121850@h48g2000cwc.googlegroups.com... > Hello > I have got a problem in SERDES chip selection that I would be grateful > if someone helps me in this regard. First, I explain the system that we > have. We want to design an STM-4 SDH system which has 5 tributary > cards and 1 optical STM-4 line card.The tributary cards are of two > types : E1 card and data card. The E1 tributary card which contains an > SDH E1 mapper, has a 12-pin telecombus in 19.44 MHz rate in each of > its transmit and receive directions (each card has 24 pins in > backplane). but the Data tributary card which contains an EoS device on > itself, has a 12-pin telecombus in 77.76MHz rate in each of the > transmit and receive directions.The pslot of the optical line card is > fixed but each of the tributary cards can sit in any position of the 5 > tributary slots. to reduce the number of the pins on the backplane we > want to serialize the telecombuses between the optical line card and > the tributary cards. Since we do not know which of the tributary cards > is inserted in in each slot we should select a SERDES which can > serialize the data from both of the rates of 19.44 and 77.76 MHz (But > during my searches in different vendors I haven't been able to find > such a chip). I have got 2 questions. > 1- As I have seen in different vendors pages, most of the SERDES > devices are placed after a protocol device. for transmitting SDH >Article: 111816
Hi, I've been working on an FPGA project for a month or so now and I have finally finished the code. Before I began I calculated the amount of BRAM and Distributed Ram that I had available and designed the code accordingly. However after compilation I get the following results: Number of Slices: 43734 out of 1200 3644% (*) Number of Slice Flip Flops: 19047 out of 2400 793% (*) Number of 4 input LUTs: 27654 out of 2400 1152% (*) Number of IOs: 58 Number of bonded IOBs: 53 out of 96 55% Number of BRAMs: 528 out of 10 5280% (*) Number of GCLKs: 2 out of 4 50% I don't really see how any of this is possible. I instantiated 5 BRAM's. Where does it come up with 528? Additionally where do the flipflops, slices, and LUT's come from? My code is only ~500 lines, I don't even know how I coded for this much logic?!!! PLEASE HELP!!Article: 111817
ian.peikon@gmail.com schrieb: > Hi, > > I've been working on an FPGA project for a month or so now and I have > finally finished the code. Before I began I calculated the amount of > BRAM and Distributed Ram that I had available and designed the code > accordingly. However after compilation I get the following results: > Number of Slices: 43734 out of 1200 3644% (*) > Number of Slice Flip Flops: 19047 out of 2400 793% (*) > Number of 4 input LUTs: 27654 out of 2400 1152% (*) > Number of IOs: 58 > Number of bonded IOBs: 53 out of 96 55% > Number of BRAMs: 528 out of 10 5280% (*) > Number of GCLKs: 2 out of 4 50% > > I don't really see how any of this is possible. I instantiated 5 > BRAM's. Where does it come up with 528? Additionally where do the > flipflops, slices, and LUT's come from? My code is only ~500 lines, I > don't even know how I coded for this much logic?!!! > > PLEASE HELP!! gosh, you are heavy coder! well for the future there is one good advice: LOOP: wrote 2 lines of code, hit "View Technology Schematic" and verify that the synthesis does something useful. Goto LOOP this will make sure you arent facing this kind of surprises. now you have to start from the bottom and look at lower modules what they produce and work up to the toplevel unit to see where the logic and rams really are consumed. AnttiArticle: 111818
Personally, I am waiting for Cyclone III.... However, the homepage mention that Quartus 6.1 which comes along with S-III will have multi-processer-support (finally...). If this really delivers what it promises that would be REALLY great! (Time to buy a quad-core :-) Thomas "Antti" <Antti.Lukats@xilant.com> schrieb im Newsbeitrag news:1163173725.751772.29560@k70g2000cwa.googlegroups.com... > S-III L == V5LX > S-III E == V5SX > S-III GX == V5xxT > > 1000-unit pricing starts at $549 for the EP3SL150 > Quartus WebPack support for S-III to be available on 4 DEC 2006 > > Antti >Article: 111819
Thomas Entner schrieb: > Personally, I am waiting for Cyclone III.... > > However, the homepage mention that Quartus 6.1 which comes along with S-III > will have multi-processer-support (finally...). If this really delivers what > it promises that would be REALLY great! (Time to buy a quad-core :-) > > Thomas > hm, I think I looking more for XP2 ;) but C-3 might be nice thing also AnttiArticle: 111820
On Nov 9, 10:44 am, "Paul Leventis" <paul.leven...@gmail.com> wrote: >This is not the expected behaviour of Quartus. Imagine how difficult > our job would be if we could not reproduce outputs for a given set of > inputs... This is why I stopped using Xilinx. I had a design that if I loaded a design file, saved it with no changes, then recompiled, I would get different timing. Sometimes failing, sometimes working. MarcArticle: 111821
> > Actually, turns out you can't. I just realized that it is hard coded to 64 > bits. I'm going to try putting everything on the opb side so that the only > thing on the plb is the plb2opb bridge to see if I save resources and power. > Since PLB, OPB, CPU, and my DDR SDRAM are all running at 100 MHz I still > don't see how a wide PLB would help? > > The only way it would seem to be helpful is if the external memories ran > faster than the PLB. For example, if my 32-bit memory ran at 200 MHz, the > PLB would only have to run at 100 MHz to retain the bandwidth. Of course, > the opposite scenario is more likely (slow external, fast internal). > > If I ran my CPU at twice the plb frequency the plb bandwidth would match the > cpu bandwidth but this only works if me external memory bandiwdth also > matches otherwise the only speed up is when running from the on-chip cache > which doesan't use the plb anyway? > > There has to be a reason xilinx forces 64-bit. Is it getting data AND > instructions in parallel? > Some other reasons not mentioned in this thread: - these days DDR2 memories with 64 bit interfaces are not uncommon, e.g. ML410 board. The bandwidth in this case is 1600 MBps which is twice the PLB bandwidth. - the bus is used not just for transfers to/fro the CPU, but also for DMA from a peripheral (Ethernet) to memory. /SivaArticle: 111822
> I observed, that a design was not fitable anymore after having changed > some minimal paramters, which only should have affected the number > machine cycles. Doing re resynthesis suddenly met the time reqs again. > (?) Which specific "minimal parameters" did you change? The algorithms that run under-the-hood in Quarus II (and any other CAD tool) are heuristic in nature. If you make any small change to the input or settings of the tool, you can end up with a radically different fitting result (synthesis, placement or routing). The result? Different wirelength, timing slacks, and even run-times. If you have a small part of your design that you will be changing, and you want to keep the rest of the design unchanged, you can try out the Incremental Compile features of Quartus. These allow you to preserve the synthesis, placement or even routing of untouched portions of the design. The result is more stable performance and reduced CPU time, with some possibility of reduced performance since the tool no longer can optimize across your partition boundaries. If you want to see more, go to http://www.altera.com/products/software/products/quartus2/design/qts-incremental.html. Note: Incremental Compile *does not* require floorplanning of your design, which is very nice, since you (and I) will have a hard time beating a placer at that task! Regards, Paul Leventis Altera Corp.Article: 111823
Fire up the Floorplanner after translate and it will give you a breakdown of where resources are used if you have maintained hierarchy. Synthesis report can also give some clues too. John Adair Enterpoint Ltd. - Home of Raggedstone1. The low cost PCI FPGA Development Board. Antti wrote: > ian.peikon@gmail.com schrieb: > > > Hi, > > > > I've been working on an FPGA project for a month or so now and I have > > finally finished the code. Before I began I calculated the amount of > > BRAM and Distributed Ram that I had available and designed the code > > accordingly. However after compilation I get the following results: > > Number of Slices: 43734 out of 1200 3644% (*) > > Number of Slice Flip Flops: 19047 out of 2400 793% (*) > > Number of 4 input LUTs: 27654 out of 2400 1152% (*) > > Number of IOs: 58 > > Number of bonded IOBs: 53 out of 96 55% > > Number of BRAMs: 528 out of 10 5280% (*) > > Number of GCLKs: 2 out of 4 50% > > > > I don't really see how any of this is possible. I instantiated 5 > > BRAM's. Where does it come up with 528? Additionally where do the > > flipflops, slices, and LUT's come from? My code is only ~500 lines, I > > don't even know how I coded for this much logic?!!! > > > > PLEASE HELP!! > > gosh, you are heavy coder! > well for the future there is one good advice: > > LOOP: > wrote 2 lines of code, > hit "View Technology Schematic" and verify that the synthesis does > something useful. > Goto LOOP > > this will make sure you arent facing this kind of surprises. > > now you have to start from the bottom and look at lower modules what > they produce and work up to the toplevel unit to see where the logic > and rams really are consumed. > > AnttiArticle: 111824
thank for your answer, did you write a code for configuring the cam and taking image data from the it?. Antti yazdi: > hikmetkoca schrieb: > > > Hello, > > > > Is there anyone who interface the C3188A - 1/3" Digital Output Colour > > Camera Module with an fpga. > > I am waiting for your answers. > > > > Thanks > > there is one tool you need, it is called "soldering iron". > > Antti
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