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
Hello, guys! Anyone has an experience debugging Virtex-4 PPC via Lauterbach TRACE32? I just can't connect them together! I have previous experience in ARM-7 and it was simply plug-and-play. Please, help.Article: 105276
Hi all, We are about to implement a PCIe x8 core but don't want to make it on Virtex-4 FX devices, so the PHY layer should be realized by external chips. So the question is: is it possible to use 8 external x1 PHY devices (for example Philips PX1011A or TI XIO1100) to form a x8 PHY?Article: 105277
Mark McDougall wrote: > No implementation/compatibility issues at all really. Nice if you have > wishbone peripherals you want to hook up on the back end - very easy to > get going. Had opencores DMA mastering over PCI too. > > Performance is another issue. If you're looking to push PCI burst > transfers to the limit, then it's not so straightforward. Not saying it > can't be done, but it will take some effort. That's another thing i meant to ask about in my original post. Is there noticible performance difference between the different available cores? This is my experience with anything PCI related, so I'm still not very clear on whether I can get away with a target, or if I'll need to mastering/DMA capabilities. I know that theoretically, the max tranfer rate of the bus is 133 MB/s w/ 33MHz systems. The intended customer of this thing is going for low cost, so I'm not going to assume that it will be used with a computer that supports 66Mhz or 64-bit transfers. Ideally, I would like to be able to guarantee 54 MB/s with pretty much equal I/O rates (27MB/s into and out of the device). Most of the time, rates should be lower than that, but just about the max I could ever need it to be. This card will probably be the only thing on the PCI bus of the PC it's plugged into, and the primary purpose of the PC will be to process the data to & from this device, so having moderately high CPU usage requirements is not much of a concern.Article: 105278
GaLaKtIkUs=99 schrieb: > Hi all, > We are about to implement a PCIe x8 core but don't want to make it on > Virtex-4 FX devices, so the PHY layer should be realized by external > chips. So the question is: is it possible to use 8 external x1 PHY > devices (for example Philips PX1011A or TI XIO1100) to form a x8 PHY? at least PLDA fully supports PCIe 8 lane by using 2 times quad PCIe PHYs Antti http://antti-brain.comArticle: 105279
I recommend that you first upgrade to 6.0 SP1. If that does not fix your problem, contact the help desk at mysupport.altera.com. We will need your design and vectors to debug this case. The other things that I would look at is to make sure this design has the right set of timing constraints so that the fitter can implment the desired timing relationships. Hope this helps, Subroto Datta Altera Corp. "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de> wrote in message news:1153303906.254358.157210@m79g2000cwm.googlegroups.com... >I am having several dual port block rams in a cyclone II device. The > access takes place as simple dual port option with only one clock for > the bram but sometimes a write, when a read is done simultaneously. I > expexted the old data to appear at the output as demanded, when I > defined the brams from within the altera megafunction wizzard. > > I know about the possible bugs, when using two different clocks, as > described in an altera technical announcement, therefore I use only one > system clock for the rams. > > I observe corrupted data though! :-( It obviously is caused when the > reading and writing processes access the same time. I am sure that I > contraint "old data" and varified this in the vhdl-definitions created > be the wizzard. > > Ideas? >Article: 105280
> read-modify-write - thats not sufficent - the external memory interface must > be able todo real byte writes as well, in the case that some stupid ip core > is connected with 8 bit registers and side-effects on register reads. there > are other reasons as well. Indeed. However, for my purposes the simple memory interface and the reduced BRAM requirement justified the internal byte steering. For the MicroBlaze, RAM must be added in groups of 4 BRAMs, so that an individual byte can be stored by selecting a specific memory. The read-modify-write of the OpenFire permits a single BRAM to be used. Regardless, the OpenFire code is (hopefully) fairly easy for others to customize to their needs.Article: 105281
My application needs 4KB (32768 bits) of buffer space for incoming data. We are wanting to use the Spartan-3E, but we have not entirely settled on a version of it. Obviously, we would like to use the cheapest package possible. My question is if this is too much buffer to synthesize in VHDL. If so, what would be my best option here? The data is written to the buffer 8 bits at a time, and it is used 64 bits at a time. Currently, I am creating this buffer like this: type ram_type is array (0 to 511) of STD_LOGIC_VECTOR(63 downto 0); signal data_buffer: ram_type; However, once I connect it to the logic that uses it, it reports that it's too large for the chip. Is there a better way to accomplish what I am trying to here? Thanks! Alex McHaleArticle: 105282
Hi Jonathan, "1. I would like to know why you get 543 compare/swap blocks? It has (lg N)*((lg N)+1)/2 stages based on formula of Knuth Vol 3, p.113. For N= 64, it has 21 stages. Yes, that's where I get my figure for 21 levels of logic. With n/2 comparators at each stage, it means it has 32 comparators at each stage. 32*21 = 672 /= 543? Not all levels have the maximum population of n/2 blocks. " I read Knuth's Volumn Batcher's algorhtm and didn't find the formula for the number of comparators. Do you have a ready formula for it? Thank you. WengArticle: 105283
Alex wrote: > My application needs 4KB (32768 bits) of buffer space for incoming > data. We are wanting to use the Spartan-3E, but we have not entirely > settled on a version of it. Obviously, we would like to use the > cheapest package possible. > > My question is if this is too much buffer to synthesize in VHDL. If > so, what would be my best option here? The data is written to the > buffer 8 bits at a time, and it is used 64 bits at a time. You can use block RAM, e.g. one instance of RAMB16_S9 for 16384 bits and some parity bits (the smallest Spartan 3E, XC3S100E, has 4 RAM blocks of this size). See the Xilinx libraries guide for details. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 105284
Hello, we have a Virtex4 FPGA and are looking for availlable hardware sorting algorithms. I couldnt find anything @opencores.org however I guess that it has been worked on this subject. The Virtex4 supports 2 PowerPCs and lots of Block RAMs so everything seems to be there. Are there any projects and what speeds could be estimated for sorting 64 bit integers? thx HeinerArticle: 105285
I'd suggest a binary tree based sorting algorithm with destination vectors in order to be able to sort them parallely with more than one architecture (e.g. one per block ram) or even one per cell in my case :-) once having found the final order. If you have no special demands concerning the speed, you should be able to use a software based algo on the power pc core using one of the algos around in the net.Article: 105286
Dan wrote: > I have tried already all the demos and they all work fine. Problem is with a new configuration ACE file that I create with ISE 8.1 and iMPACT - even the simplest design can not configure the board. Are you sure that you set up the JTAG chain properly in iMPACT when you generated the ACE file? The chain should be defined as XCF32P -> XC4VSX35 -> XC95144XL Ed McGettigan -- Xilinx Inc.Article: 105287
I have a problem while specifying the clock correction sequence for the Virtex-II ProX MGT. The problem is that I don't find a way to make the clock correction function of the MGT to distinguish between 64B66B control blocks and data blocks. Does anyone have any experience in this?Article: 105288
1) "Learn about semaphores" I know about semaphores, but according to my understanding it is a feature of a dp ram to be accessed the same time from both sides. If I'd implement a semaphore based access, there would be no need to use a dual ported ram, would it? The data that appears is totally wrong, having nothing to do with old data, as expected. Anyway, I''ll camoe back to this issue later. 2) "Upgrade to 6.0 SP1" Thanks, yes, I am with 6 SP1 now but the same experience. I also think, that it is a matter of physical timing. I will do a back annotation sim on order to find out.Article: 105289
Hello, There was a similar thread in this newsgroup. If you are looking to solve a specific problem and have performance targets, you should share those -- it will help people give you more focused answers. You do not need PowerPCs or BlockRAMs to sort integers. Sure, you can write a sequential sort algorithm and run it on a processor, but if you are interested in performance, I think that approach may be one of the last things you would want to do. If you are interested in two examlpes of a hardware sort, take a look at: http://www.engr.sjsu.edu/crabill/module05.pdf There is a bubble sort and an odd-even transposition sort. The examples sort a set of five, 16-bit values. They could certainly be extended to handle fewer/more and/or wider/narrower inputs. One example is pipelined, the pipeline depth can certainly be changed. In fact, you can turn it into a combinational sorter if you want. If anyone expands the examlpes to sort 1 million 64-bit integers, please let me know what your synthesis tool thinks about it. Certainly, I am not advertising the examples as "the best" and I am no "expert" in sorting. Or anything. But they might be a place for you to start. I only knew the bubble sort, but used Google to search for "parallel sorting algorithms" because I figured there would be one which I could implement in hardware. The odd-even transposition sort is indeed quite easy. Eric > we have a Virtex4 FPGA and are looking for availlable hardware sorting > algorithms. I couldnt find anything @opencores.org however I guess that > it has been worked on this subject. > > The Virtex4 supports 2 PowerPCs and lots of Block RAMs so everything > seems to be there. Are there any projects and what speeds could be > estimated for sorting 64 bit integers?Article: 105290
Faster speed grade parts will work in almost all scenarios. While min timing analysis should be conducted to ensure there are no timing problems, likelihood is extremely high that faster speed grade parts will work. To do min timing analysis from the UI use Processing->Start->Start Timing Analyzer (Fast Timing Model). Hope this helps - Subroto Datta Altera Corp. Jesper.Kristensen@tellabs.com wrote: > Hello Group. > > Quite simple question... but I cannot seem to be able to find the > answer: > > Given a Code Image initially targeted for a Stratix EP1S40F780C8 - i.e. > Speed Grade "-8" - would it then be without troubles to load and run > that Image on the corresponding "-6" device...? > > The need for the question arises in the crossfire of device > availability and the wish of having only one Coding Image to update. > > Thanks in advance & best regards, > > Jesper.Article: 105291
Ed McGettigan wrote:
Are you sure that you set up the >JTAG chain properly in iMPACT when you
generated the ACE file? The >chain should be defined as
XCF32P -> XC4VSX35 -> XC95144XL
How do I set up the JTAG chain in iMPACT? What I see on the iMPACT is:
xc4vsx35 myfile.bit -> XCCACE-TQ144I
Article: 105292Have you installed service pack 1 for version 6? If you haven't, tech support will prbably have you do this first. I haven't used 6 yet but, when I upgraded from 4 to 5, I had the optimizer reduce a state machine to nothing because the newer version identified an ambiguous state and poof. I'm not saying this is your problem but examine your project settings, see if it is doing anything differently. Put an emphasis on optimizing. And look at the warnings DerekArticle: 105293
Hi Brian, An important consideration regarding the PCI bus (say, in a desktop PC) is that you generally cannot make any guarantees about bandwidth. There are too many things outside of your control -- the O/S, other devices using the bus, the performance capabilities of the host bridge device... That "133 MBytes/sec for PCI32/33" is the physical bus bandwidth -- how much data could possibly fly over the bus. It is not an indicator of what your device may realize in a typical system. If you need performance, and your host is going to be x86 based with a commodity chipset (certainly not "perfect"), you absolutely must include some kind of bus mastering capability. For all practical purposes, it will be very difficult to get any kind of data burst initiated by the CPU to your device target. For that reason, a target will not suffice unless you are building something that only needs a dribble of data -- a standard serial port, or an LED flasher. :) Eric > This is my experience with anything PCI related, so I'm still not very > clear on whether I can get away with a target, or if I'll need to > mastering/DMA capabilities. I know that theoretically, the max tranfer > rate of the bus is 133 MB/s w/ 33MHz systems. The intended customer of > this thing is going for low cost, so I'm not going to assume that it > will be used with a computer that supports 66Mhz or 64-bit transfers. > Ideally, I would like to be able to guarantee 54 MB/s with pretty much > equal I/O rates (27MB/s into and out of the device). Most of the time, > rates should be lower than that, but just about the max I could ever > need it to be. This card will probably be the only thing on the PCI > bus of the PC it's plugged into, and the primary purpose of the PC will > be to process the data to & from this device, so having moderately high > CPU usage requirements is not much of a concern. >Article: 105294
I am no lawyer, but it my understanding that the Lattice reference design is intended for use on Lattice devices. The license agreement says something like: "for the sole purpose of programming Lattice programmable logic devices." If you use the Lattice PCI reference design, it sounds like you should use the LatticeECP2 device or another Lattice FPGA, a list of which you can find here: http://www.latticesemi.com/products/fpga/index.cfm Hope this helps. Bart Borosky, Lattice Antti wrote: > > but do you mean that at lattice they have a downloadable pci ip > > retargettable to any fpga? (i.e rtl code?) if yes could put here the link? > > > > Antti Lukats ha scritto: > > sure get it here http://www.latticesemi.com/products/intellectualproperty/referencedesigns/pcitarget32bit33mhz.cfm > > 100% verilog source included! > > Antti > http://antti-brain.comArticle: 105295
"bart" <bart.borosky@latticesemi.com> schrieb im Newsbeitrag news:1153331232.004936.238120@p79g2000cwp.googlegroups.com... >I am no lawyer, but it my understanding that the Lattice reference > design is intended for use on Lattice devices. The license agreement > says something like: "for the sole purpose of programming Lattice > programmable logic devices." > > If you use the Lattice PCI reference design, it sounds like you should > use the LatticeECP2 device or another Lattice FPGA, a list of which you > can find here: > http://www.latticesemi.com/products/fpga/index.cfm > > > Hope this helps. > Bart Borosky, Lattice > Hi Bart, well yes -- everyone should read the license of course. I would gladly use that lattice pci core on lattice boards, and hopefully one day I will - but as I dont have any lattice-pci fpga boards so I have evaluated the lattice-pci core on different PCI boards. [snip - self censoring, the deleted text goes to lattice in private] all the use of it I have ever done is fpga board initial testing - nothing more. I have never considered using it in any products based on non-Lattice silicon (because of the license) but - the fact that this core is available - it brings some attention to Lattice if someone mentions it. I should have mentioned the license clause of course - but the link I provided did land on the license agreement and not direct download. AnttiArticle: 105296
I also tried to edit svf file before converting it to ace with svf2ace117.exe and the red led 'err' was turned on again. But when I converted the edited svf file with -s option (skip TDO test) then finally the red led 'err' was not on, neither was the green led 'done'. It didn't work again.Article: 105297
homoalteraiensis wrote: > That is the point. Modelsim shows a well behavior. Nothing wrong. And the Quartus timing analysis shows no problems either I'm assuming. > The error only shows up in real and signal tap analysis. Then open a service request to Altera. > I already changed > the timing (slower). The only way to shun this problem is, to disallow > simultanous access, which in fact lowers performance. Or go to Altera to find out what the issue is, and if there are any work arounds. I haven't used Cyclone but I've used Stratix and Stratix II dual port memories extensively with a single clock without any issues. KJArticle: 105298
Hi all, I downloaded code for a vga generator from xess design examples. I just want to verify that my board is functioning properly. The vga generator should display a frame from the sdram which is preloaded using GXSLOAD. I loaded the image.xes file and the test_vga.bit onto the board. As soon as the ramintfc.bit file (sdram|fpga interface file) is loaded, i get the following error. Major Error : Error Downloading into the RAM!! An error occured while downloading to the RAM? I click 'Continue' and now the test_vga.bit is loaded into the fpga. The image displayed is not what is expected. Has anyone seen this error before? Any help is appreciated. Thanks, Subhasri.KArticle: 105299
I forgot to say that I edited the svf file according to: <http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23146> The issue is caused by the lack of a proper time delay after the JPROGRAM instruction is issued to the device. //NEW CODE SEGMENT: Loading device with a 'bypass' instruction SIR 14 TDI (3fff) SMASK (3fff) ; RUNTEST 434000 TCK ; here I changed TCK to 2434000 - made it longer because I am programming Virtex 4 SX35.
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