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
Hi, I have the following problem: I want to configure my virtex II pro with powerpc but when I try to download with JTAG the application doesn't run. So I have tried to use XMD, but when I init this debug I find this message. I have asked to Xilinx, and they have some solutions for this, but this doesn't work. Did anyone take this problem? PD: I use ISE/EDK 8.1 RegardsArticle: 120326
> > I guess, 13 answers later you still didn't get the .xbd file, right ? > > Indeed it's proving very hard to track down, i even asked someone on > the inside at xilinx and digilent if they had one and still came up > blank. ask again the support at digilent. They sent me the files yesterday.Article: 120327
On Jun 5, 6:23 pm, Antti <Antti.Luk...@googlemail.com> wrote: > On 5 Jun., 18:16, Sandro <sdro...@netscape.net> wrote: > > > > > On Jun 5, 5:33 pm, austin <aus...@xilinx.com> wrote: > > > >... > > >... > > > There has even been thoughts of hardening the MicroBlaze(tm) core, but > > > most feel that the last thing the world needs is 'yam' (yet another > > > microprocessor). > > > > Austin > > > PPC, ARM, Microblaze.... I hope MIPS could be an option too! There are > > a lot of device using it and maybe using FPGA as glue for a hard MIPS > > inside the FPGA could lower such devices price... > > > Sandro > > P.S. I don't know MIPS Licesing cost... > > some dont care about licensing: > > there are > > * godson > * godson-2 > * some_similar_name > > all MIPS derivates > I know wikipedia sometimes is not the truth... but from http://en.wikipedia.org/wiki/Loongson it seems STM bought a licence from MIPS (?to build godson?) SandroArticle: 120328
On 5 juin, 10:53, rpons...@gmail.com wrote: > Hi groups, > > this is for neewbees and mig user... > > if you want to save your time, remember to modify ISE options (XST and > Implements properties) for your design (the default choices causes PAR > fails with something bad in ucf...) : see .bat files in reference > design... > > hopes it helps, > raph Thanks for the tip. PatrickArticle: 120329
Antti wrote: > did Steve work at Triscend? My memory is that Steve was one of the main movers at Triscend. Possibly one of the founders. If Phil Freidin is reading, he may be able to fill in the details.Article: 120330
Andrew wrote: > Hi, > > I'm looking for thoughts, impressions, pros, cons, etc, on System > Generator, Synplify DSP, and Simulink HDL Coder. We develop image > processing algorithms and we are trying to shorten the design cycle > and eliminate the errors caused by a hand conversion of C or Matlab > code to VHDL. > > It appears that System Generator and Synplify DSP are heavy on comms > type functions. How useful are these tools if you need custom > functions? > > Are the tools easy to use? > > Can System Generator be used with a Synplify Pro synthesis flow? > > It looks like AccelDSP + System Generator may be a good solution for > developing custom algorithms. Any IP not found in System Generator > could be done with AccelDSP and exported to System Generator. > > How well do these tools work/how mature are they? Is anyone using any > of these tools for _real_ projects. > > Thanks for any insights, > > Andrew > SysGen can be used with Synplify. The HDL it creates is highly structural so the choice of the synthesizer is not as important as it might be when writing more behavioral HDL. I think the most problematic part of image processing designs is the memory interface. Designing a convolver, for instance, is much easier than figuring out how to keep the convolver fed with data from the image RAM. I'd keep this foremost in mind when selecting a design flow. -KevinArticle: 120331
austin wrote: > In the Spartan family, the PPC is not the clear winner, with ARM being > used primarily in low cost/low power apps. However, licensing ARM cores > doesn't fit the Spartan business model, as it would increase the cost to > the customer beyond what the benefit might be. Interesting. From http://tinyurl.com/32h6ou : "The average royalty rate fell to 6.7 cents in 2007, down from 7.9 cents in 2005" Must be too high because X has some products on the horizon priced at $1 with embedded PPC ;-)Article: 120332
On 5 Jun., 19:15, "Tim (one of many)" <t...@nooospam.roockyloogic.com> wrote: > austin wrote: > > In the Spartan family, the PPC is not the clear winner, with ARM being > > used primarily in low cost/low power apps. However, licensing ARM cores > > doesn't fit the Spartan business model, as it would increase the cost to > > the customer beyond what the benefit might be. > > Interesting. Fromhttp://tinyurl.com/32h6ou: "The average royalty rate > fell to 6.7 cents in 2007, down from 7.9 cents in 2005" > > Must be too high because X has some products on the horizon priced at $1 > with embedded PPC ;-) must be large difference in royalty, as Actel is charging over 100 USD per ARM enabled FPGA (in small qty) AnttiArticle: 120333
In article <an29i.92548$vE1.9245@newsfe24.lga>, Ray Andraka <ray@andraka.com> wrote: >Totally_Lost wrote: >> I've been looking at the various core/macro generators and they all >> seem horribly large and slow, almost like student designs. Has anyone >> seriously taken a good look at hand fitting multipliers and squarers >> into Altera/Xilinx FPGA's? >> > >If you haven't already, you might look at the multiplication in FPGAs >page on my website at http://www.andraka.com/multipli.htm. The partial >product LUT multipliers are about as efficient as you are going to get >with the FPGA LUT structure. I agree that partial-product LUT multipliers are pretty much optimal for multiplying three-bit quantities. For wide multipliers, I think the relevant literature is the multi-precision arithmetic stuff by people like Knuth; you can multiply two 64-bit numbers by using three 32x32 multipliers in parallel. Relevant search terms are Karatsuba and Toom-Cook. (trying to multiply 2^32A+B by 2^32C+D: compute AC, BD, and (A+B)*(C+D), then do 2^64*AC + BD + 2^32*((A+B)*(C+D)-AC-BD). This takes one 32-bit add delay in which you get A+B and C+D one 33x33->66 multiply delay for (A+B)(C+D), parallelly AC and BD one 64-bit add delay to get AC+BD one 66-bit subtract delay to get ((A+B)*(C+D)-AC-BD) one 64-bit add delay to add the top 34 bits of that product to AC and you can decompose the 33x33->66 multiply in the same kind of way, and if you're clever you can probably pipeline the wide additions) Toom-Cook lets you multiply two (A*B)-bit numbers by using (2A-1) multipliers a bit wider than B, and a lot of rather strange additional tidying-up circuitry. The idea is that multiplying numbers is a lot like multiplying polynomials, and you can reconstruct the coefficients of a polynomial of degree 2d from its values at 2d+1 places by multiplying by a constant matrix; pick the places to evaluate to make the coefficients in the matrix nice. TomArticle: 120334
> SysGen can be used with Synplify. The HDL it creates is highly > structural so the choice of the synthesizer is not as important as it > might be when writing more behavioral HDL. I think the most problematic > part of image processing designs is the memory interface. Designing a > convolver, for instance, is much easier than figuring out how to keep > the convolver fed with data from the image RAM. I'd keep this foremost > in mind when selecting a design flow. -Kevin Thanks for the response. I agree, the image processing bits are usually fairly simple. Do you think System Generator is high-level enough for an algorithm guy to use competently or does it still require a fair amount of FPGA knowledge. (I'm an FPGA/VHDL guy btw) The algorithm guys would love to be able to come up with their algorithm and just run it on the hardware without us FPGA guys at all. AndrewArticle: 120335
Austin, Thanks for suggestion; I have some question about it to fully understand you idea 1. I have think that all of the C based design flow ends to an HDL description in low level of design and C isn't a suitable language for designing a hardware because it's naturally sequential and limited in many cases like X or Z data representation. May be your intent is systemC ? 2. If assume you suggest compare C with HDLs, are there any contribution in this work? Did you know someone or community working on this topic? I appreciate for your attention. On Jun 5, 6:04 pm, austin <aus...@xilinx.com> wrote: > haghdoost, > > Of interest might be to compare a c language flow, vs a HDL language > flow, for a suite of designs. > > In other words, if you had: > > a video application, > a dsp signal processing application > a networking application > > each codes in both c, and VHDL, with the c being converted to HDL by a tool. > > How do these compare? Why is (is not) one better than the other? What > elements of coding style do not work (well)? > > You may be able to find existing examples of HDL code for all of the > above. All that is needed is the core element of the application, and > it actually doesn't have to work (unlike a real product), but it has to > be good enough for the compare. Specifications need to exist so you can > code the equivalent function in c. > > This might be more of a Master's project, but it could also be a good > senior year project. Discuss it with your advisor. > > The XUP (Xilinx University Program), has the tools, the boards, and > might be able to provide you with what is required. Have your advisor > contact the XUP with the requirements. > > AustinArticle: 120336
> >Ever tried to enter BIOS on bootup and set the appropriate mode? (Sorry that this is moving further from FPGAs.) So I did go into the BIOS and configure the parallel port for ECP. But when I rebooted the modes changed, but I still didn't have an ECP option: (dmesg) parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected After that I retried loading the parport_pc as follows: modprobe parport_pc io=0x378,0xc400 irq=auto,auto Now I in fact have a parport1: parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] parport1: PC-style at 0xc400 [PCSPP,TRISTATE,EPP] and I can download but only in the slower PC3 mode. How do I change the mode of a PCI parallel port to ECP so I can use PC4? Try the BIOS again? Thanks for the help.Article: 120337
Just a little update, I tried on a colleague computer and the bug doesn't show up. So it really seems like there is a hidden environment variable or something on my computer only, that guides xst to the Coregen_V4 directory. Even more strange, I deleted the file s_fifo_w8_d16.vhd completely, emptied the recycle bin, and yet xst still manages to find the file and compile it!! I'm using a truecrypt partition for my source files, I wonder if it is related. Yet another Xilinx tool issue (maybe), <sigh>. PatrickArticle: 120338
<cs_posting@hotmail.com> wrote in message news:1181060211.371062.97100@p47g2000hsd.googlegroups.com... > On Jun 5, 11:10 am, Amal <akhailt...@gmail.com> wrote: >> Anyone has a good pointer to a portable (Windows, *nix) TCP/IP socket >> library that can be used with VHDL FLI, Verilog PLI/VPI, SystemC, or >> SystemVerilog DPI? > > Have you tried just using the common (BSD-derived I suppose) socket > calls and found them not to work on both platforms, or somehow > incompatible with the simulation interfaces you mention? > > I would think that if you just avoid vendor/os -specific extensions > you should be fine. > I believe that you should pay attention to OS specific examples, thus if you use sockets on Modelsim's FLI running under windows then follow the winsock examples, if you are running SystemC under Cygwin then follow the libc/bsd coding style. In general they are very close and pragmas can make your code portable. These example might help you out: http://www.ht-lab.com/howto/fli_demo/uart2fli/uart2fli.htm http://www.ht-lab.com/howto/fli_demo/ferndemo/socket.html Hans. www.ht-lab.comArticle: 120339
Problem solved. The mystery lied in the xst temporary directory, which had been set automatically by Active-HDL to a strange location. I had not noticed its existence because it was not in the same file hierarchy as the rest of the design. Clearing the temporary directory solved the problem. Yet, I find it troubling that xst relied on old data in its temporary directory. It should always give the same result (given a certain set of input files), no matter what lies in its temp directory. If it can find precompiled stuff in there, fine, as long as it doesn't use OLD outdated stuff! If the temp directory in unreliable, xst should clear it completely before starting a compilation then. It shouldn't be the user's problem. PatrickArticle: 120340
I guess this is really one for Austin, but I wonder if anyone else has any input. My company supplys a design which is used in a V4LX25. The design uses external QDR SRAM @ 200MHz (400MBit). The design has a built in memory test which exercises the memories under worst case conditions (flat out) with pseudo random address/data, and all works well. However, the jitter on the Kclock to the memories gets a lot higher (>600pS) when this test is running. When the system is idle the jitter is <100pS. These "jitter" measurements are simply read off the scope eye pattern which is captured over several minutes. The jitter analyses software shows the same sort of numbers but I don't have them to hand. All IOs are HSTL I 1.5V. Due to constraints on the ASIC this thing is attached to, the FPGA currently takes in a 100MHz clock, and a single DCM creates a static phase shifted clkX2 output which is used to generate the K clock using DDR flops. There is a jitter paper on the SI bit of the Xilinx web site I use to convince myself (and others) that we can meet the 200pS cycle to cycle jitter requirement to the SRAM by the fact the DCM will only add jitter when it switches taps, and this will be worst case 80 odd pS or something per cycle ..etc etc. If I run the memory test but disable the IO drivers of the FPGA (apart from the K clock) then the jitter on the clock returns to normal, so the jitter is related to the activity on the IO pins, not the core. The traces are very short, and I am measuring the K clock at the end terminator. I also understand the x2 DCM output is more sensitive to VCCAUX noise then the x1 output. I thought at first it must be the PCB layout coupling noise into VCCAUX but I have played with a number of different boards with excellent layout and all behave similarly. Is it possible the coupling to the DCM is happening inside the Xilinx package? I am about to do a board update and am considering adding a linear 2V5 regulator to feed just the VCCAUX pins ??? Question : if it is possible to change the design to using the x0 phase shifted output (tricky, lots of work), does anybody know if it is Significantly more resilient to disturbance. Anybody else had a similar problem? The jitter when idle I can live with, its with lots of things waggling I get into trouble, so I have a feeling the x0 output may behave the same ?? I have found the Xilinx FAEs not terribly helpful on this, although there is a bit of info on the Xilinx support web (which is quite good, have you seen how Mentor have ruined theirs)??? Best regards, MikeArticle: 120341
I am using spartan3 XC3S400FG456C-4 device. For the past two years or so I have been creating the svf file and I am suddenly having some problem with the svf file. Basaically the software gives SDR compare error when I try to download the svf file. Could this be due to wrong configuration of the project file? I tried using Project navigator version 8.2 and 9.1 and they both are giving same results. Have you all seen this issue?Article: 120342
ARH wrote:
> 1. I have think that all of the C based design flow ends to an HDL
> description in low level of design and C isn't a suitable language for
> designing a hardware because it's naturally sequential and limited in
> many cases like X or Z data representation.
It's quite possible to write sequential HDL code
that describes parallel hardware.
While it is common to see HDL used as a netlist,
synthesis tools can do much more
with a synchronous process/block if I want to.
The C-like HDL's cover the same ground
but punt most of the bit level port details
to vhdl or verilog.
I agree with Austin that a side by side
benchmark for several HDL's would be
a useful and interesting project.
The C-like languages claim that a
C programmer can more quickly port
algorithms to hardware with yet another HDL.
It would be of interest to know if this is true.
-- Mike Treseler
Article: 120343On 5 juin, 12:31, Pablo <pbantu...@gmail.com> wrote: > Hi, I have the following problem: > > I want to configure my virtex II pro with powerpc but when I try to > download with JTAG the application doesn't run. So I have tried to use > XMD, but when I init this debug I find this message. I have asked to > Xilinx, and they have some solutions for this, but this doesn't work. > > Did anyone take this problem? > > PD: I use ISE/EDK 8.1 > > Regards Not sure if this will help (since you contacted Xilinx already), but the following answer record is pretty comprehensive about this issue: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=18265 One way to debug this is to add a Chiscope with all the relevant PPC signals (RSTC405RESETCORE, etc.. see answer record). You also might look around and tweak the files xmd.ini and /etc/ xmd_ppc405_0.opt. They are the ones that get executed when you "Launch XMD". Avoid connect-disconnect-connect sequences, it fails with the error message above (in my case anyway). PatrickArticle: 120344
Biancu wrote:
> Hi, I´m new to card using Xilinx chips. I´m developping a new vhd
> prgogram, and on one Mesa example, at the very beginning of the code,
> the following statements appear:
>
> entity main is
> port
> (
> -- bus interface signals --
> LW_R: in std_logic;
> DEN: in std_logic;
> ADS: in std_logic;
An entity only tells me how many
port pins the module has.
What it does is described in the architecture.
-- Mike Treseler
Article: 120345Patrick Dubois wrote: ... > If the temp directory in unreliable, xst should clear it completely > before starting a compilation then. It shouldn't be the user's > problem. Unfortunately, it is. There are lots of synthesis settings, and any one of them can be wrong. I could write a script or makefile to control simulation and synthesis and use source control tools to keep track of versions. -- Mike TreselerArticle: 120346
Andrew wrote: >> SysGen can be used with Synplify. The HDL it creates is highly >> structural so the choice of the synthesizer is not as important as it >> might be when writing more behavioral HDL. I think the most problematic >> part of image processing designs is the memory interface. Designing a >> convolver, for instance, is much easier than figuring out how to keep >> the convolver fed with data from the image RAM. I'd keep this foremost >> in mind when selecting a design flow. -Kevin > > Thanks for the response. I agree, the image processing bits are > usually fairly simple. Do you think System Generator is high-level > enough for an algorithm guy to use competently or does it still > require a fair amount of FPGA knowledge. (I'm an FPGA/VHDL guy btw) > The algorithm guys would love to be able to come up with their > algorithm and just run it on the hardware without us FPGA guys at > all. > > Andrew > I'm not necessarily saying the image processing is simple; it's just not going to be where you spend most of your design time, especially if external memory is involved. You can use SysGen and, probably to a greater extent, AccelDSP, without hardware knowledge. But, as with most high-level design tools, having hardware knowledge is necessary to achieve the optimally fastest/smallest implementation.Article: 120347
Austin, that is one tough project :-) "ARH" <haghdoost@gmail.com> wrote in message news:1181066596.543625.105400@m36g2000hse.googlegroups.com... > Austin, > > Thanks for suggestion; I have some question about it to fully > understand you idea > > 1. I have think that all of the C based design flow ends to an HDL > description in low level of design Not necessarily there are some tools that go straight to edif like Handle-C and some go via an intermediate HDL language like Catapult and ImpulseC. > C isn't a suitable language for > designing a hardware because it's naturally sequential I would argue the opposite, people don't think parallel, they think sequentially and hence engineers tend to write many more line in a high-level sequential language than in a parallel one. Thinking of all the synchronisation issues between the concurrent blocks is a real pain. Some tools can reduce this pain for you (e.g. Catapult) but you still need to think like a hardware engineer when you use them (so I have been told, I have never used Catapult). > and limited in > many cases like X or Z data representation. May be your intent is > systemC ? Using SystemC for your project is a great suggestion since the simulator and IDE's are free (e.g. OSCI with Visual C++ on windows or KDeveloper/Anjuta on Linux) and you can really put your teeth into issue like delta cycles, concurrency and high-level programming all from one language, the only disadvantage IMHO is that you have to know C++. You can even use SystemC at a low hardware level, that is connecting blocks of logic between FF although some might argue this is abusing the language :-) > 2. If assume you suggest compare C with HDLs, are there any > contribution in this work? Did you know someone or community working > on this topic? There are lots of papers and lots of tools that operate in the C/C++/SystemC/Handel-C domain but getting any sense where they are currently (or would be) most effective is a difficult job and most marketing departments would pay an arm and a leg for that answer :-) Hans www.ht-lab.com > > I appreciate for your attention. > >Article: 120348
If you used wizard to build the design or if it is one of the reference designs, then the most likely problem is DCM not being locked for whatever reason (bad/wrong external clock, DCM frequency range is wrong for the frequency, etc.) Also, if this happens during debugging with a design that usually works, try reloading your bit file. /MikhailArticle: 120349
MikeJ, Let me study this, and get back to you. Austin
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