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
> When I say painful I'm mostly speaking of the turnaround time > from source change to test. 30 minutes to try something else > on actual hardware -- from a software development point of view > that's a lot of time. From a VHDL developer depending on the > project that can actually be considered *fast*...I just wish the > build process wasn't so slow. It's like batch processing again. That's also where simulation can be such a powerful tool. You can check out and verify a whole heck of a lot and (if you have a testbench coded) automate the regression testing. I'll agree with the 30 minute turn around, but those are also for what I would call the relatively simple changes (i.e. the DOH...bonehead! ones that everyone makes at times) since most of that 30 minutes is chewed up by the build time and not the actual debug/analysis/fix effort. > Anyway to get back onto the subject, what would be really > cool is if you could just code your program in 'c' or whatever > language, and some magical development tool would break > it up into stuff to go onto an fpga and even if that takes hours > to build, you only have to do it *once*, and it is guaranteed to > work the first time. Then the masses would be able to use > this technology for day to day stuff. Synthesis tools (and software compilers) do that today and always have....well, almost. You go through the build process and the FPGA (or software program) is guaranteed to work exactly as you stated that you wanted it to do....an alternative definition of a 'bug' is when what you wanted (i.e. the specification) is not what you said you wanted (i.e. the source code that you fed into the compiler/synthesis engine). 'Works as designed' is a given (except for the occasional bugs that pop up in the compiler/synthesis tool itself). 'Works as intended' is another thing entirely where the right language (whatever that may be) and a skilled user/designer are probably the biggest aids in minimizing the gap between 'as designed' and 'as intended'. I know, I'm just stating the obvious here ;) KJArticle: 107326
fpga_toys@yahoo.com wrote: > you are right ... and at the same time, my tollerance for Austin and > Peter is near zero, when they assert things on reputation and their > employers name, that are direct personal attacks. I'll be nice and mind > my language better. > > My respect level for Xilinx is at a near all time low. I know what you mean. There have been times when I could not take the "attitude" that shows in some of the posts by company representatives here. It is a waste of time to get into a protracted arguement with anyone at any time on the Internet and comp.arch.fpga is no exception. Those people are not likely to change and it can make you look bad. But that does not mean you are wrong in your discussion, just that it's not really worth the effort. I will say that my attitude towards Xilinx has shifted as well. I used to use Xilinx exclusively unless there was a specific reason to use another brand. Now I consider them all to be about the same unless there is a specific reason to do otherwise. In particular I find that the Xilinx parts allways have something that makes them a PITA to use. The early Virtex parts and Spartan II had the huge power on surge problem which was presented an unavoidable for "modern" chips. This was fixed in later generations. Then the early Spartan III parts had an unusual sensitivity to voltage excursions which were presented as unavoidable for "modern" chips. This was fixed in later versions of the same chips. The last few generations have used 2.5 volt interfaces for configuration while the next version I have heard will go back to 3.3 volt interfaces. I have not looked at the more recent parts to see what is up with them, but I am sure whatever it is, it is "unavoidable". As to the issues of discussing this sort of problem here, "It's just Chinatown", or in this case "It's just the Internet!"Article: 107327
Peter, Thanks for offering your help. I'll send you my design by e-mail shortly. I'm targetting our own board but for the time being, I'm just trying to make something work on the "Avnet Virtex-II Pro Evaluation Board". I tried the instructions you provided for xmd, and everyting works except for the "run" part. I get something like that: XMD% run PC reset to 0xffff3ffc, Clearing MSR Register Processor started. Type "stop" to stop processor RUNNING> XMD% Processor stopped at PC: 0xffff0000 The processor stopped instantly. I then tried to reset and start again: XMD% rst Target reset successfully XMD% run PC reset to 0xffff3ffc, Clearing MSR Register Processor started. Type "stop" to stop processor RUNNING> Now this 2nd time the processor seems to run, but I don't get the normal "running" behavior that I get in GDB. The program is quite simple, it mirrors the state of the 8 dip switches to the 8 leds on the board (infinite loop). The leds all stay off with the above steps (which indicates that the code is not running properly). I get the same behavior when I try to load everything through SystemAce. Is there a special step to do when compiling "release" code? I'll get in touch with you by e-mail shortly. Thanks Peter. PatrickArticle: 107328
Hello, I am newbie learning Xilinx system generator. I have made a simple down sampler program which will just downsample the incoming signal and presents it as downsampled version. The simulink simulation runs well, but when I try to create a HDL netlist, the process just hangs in "Running Netlister". Can someone help with this issuse and can provide a solution. Sivakanth.Article: 107329
"rickman" <gnuarm@gmail.com> schrieb im Newsbeitrag news:1156619847.879877.247170@b28g2000cwb.googlegroups.com... > Martin E. wrote: >> We are designing with a V2P30 right now for migration to an equivalent V5 >> Q1'07. The SATA solution won't be needed until early next year. Would >> V5 >> work then? >> >> Also, is SATA IP commercially available? >> >> I guess an alternative might be to go PCI X/e and then use an off-the >> shelf >> SATA controller that talks to PCI. The problem is that I need lots of >> drives in parallel (I do mean LOTS) for this application. It'd be easier >> to >> hang them right off an FPGA with a PHY (which seem to be impossible to >> get). > > Ignoring all the paranoid nonsense that is being posted about this, I > was able to Google search and find at least one potential PHY from > Atmel, the AT78C5091. They have a summary data sheet although I don't > see a full sheet. They provide a contact which I assume means they > will only sell it if you are interested in high volumes. > > It may well be that external PHY chips are not used because of the high > power or the high data rate. It would be a lot cheaper and lower power > to integrate the PHY into your controller chip. > oh there are "product briefs" for SATA PHY's available from many different vendors. but have you ever tried to purchase a SATA PHY IC? try! and let us know if you succeed! AnttiArticle: 107330
KJ wrote: > 'Works as designed' is a given (except for the occasional bugs that pop up > in the compiler/synthesis tool itself). 'Works as intended' is another > thing entirely where the right language (whatever that may be) and a skilled > user/designer are probably the biggest aids in minimizing the gap between > 'as designed' and 'as intended'. > > I know, I'm just stating the obvious here ;) yes, and it can not be said enough times. The turning point is a complexity * (probability of mistake) product which predicts the likely hood of making errors. When you build circits a bit at a time, then a 2M bit device will have a development error rate of 2M times the probablity of a bit programmer error. If those 2M bits are better described as 50 lines of HLL, the error rate is a different product based on 50 times the probablility of an HLL coding error. This second probablility can be relatively low, or in some cases very high too (such as a C programmer writing their first complex Lisp). In addition, debug time is directly proportional to expression size ... looking for a needle in a haystack problem, vs sorting thru 50 pins. HLL's tend to leverage smaller well defined complexity, to produce lower over all system probablility of error.Article: 107331
On a sunny day (26 Aug 2006 13:48:18 -0700) it happened fpga_toys@yahoo.com wrote in <1156625298.673980.153570@i42g2000cwa.googlegroups.com>: >When you build circits a bit at a time, then a 2M bit device will have >a development error rate of 2M times the probablity of a bit programmer >error. When you build circuits a bit at the time (like electronic circuits), then you also test these. That leaves you with a good library of circuits. Combining these is merely interconnecting. At such a point already 'what language' becomes highly irrelevant. This works in electronics designs, this works in software coding, and this works in HDL coding. For example I have a good UART, LCD driver, and quite a few other modules (or 'bits' if you will), and can just wire these together. You cannot just multiply errors, as especially in these smaller modules there are either no errors, or extremely few. Overview of these smaller pieces is simpler, allowing you to optimise and debug in a better way. Over the years you end up with a good library that is tested and bug free, _reducing_ the probability of errors. When I code in C (in Linux mainly) I _always_ use pieces of software I wrote, cut and paste is easy. Why re-invent the wheel every time? Or why let a program re-invent the wheel, with all uncertainties it brings?Article: 107332
Antti Lukats wrote: > "rickman" <gnuarm@gmail.com> schrieb im Newsbeitrag > news:1156619847.879877.247170@b28g2000cwb.googlegroups.com... > > Martin E. wrote: > >> We are designing with a V2P30 right now for migration to an equivalent V5 > >> Q1'07. The SATA solution won't be needed until early next year. Would > >> V5 > >> work then? > >> > >> Also, is SATA IP commercially available? > >> > >> I guess an alternative might be to go PCI X/e and then use an off-the > >> shelf > >> SATA controller that talks to PCI. The problem is that I need lots of > >> drives in parallel (I do mean LOTS) for this application. It'd be easier > >> to > >> hang them right off an FPGA with a PHY (which seem to be impossible to > >> get). > > > > Ignoring all the paranoid nonsense that is being posted about this, I > > was able to Google search and find at least one potential PHY from > > Atmel, the AT78C5091. They have a summary data sheet although I don't > > see a full sheet. They provide a contact which I assume means they > > will only sell it if you are interested in high volumes. > > > > It may well be that external PHY chips are not used because of the high > > power or the high data rate. It would be a lot cheaper and lower power > > to integrate the PHY into your controller chip. > > > oh there are "product briefs" for SATA PHY's available from many different > vendors. > but have you ever tried to purchase a SATA PHY IC? try! and let us know if > you succeed! Atmel has three devices on their HDD page and I am confident that they offer them for sale. I expect that if I wanted to buy a million they would be readily available. The OP did not say how many he expects to use so I am just providing a potential source. What they cost will depend on how many he wants.Article: 107333
Jan Panteltje wrote: > That leaves you with a good library of circuits. > Combining these is merely interconnecting. > At such a point already 'what language' becomes highly irrelevant. True to some extent, but the argument doesn't scale, otherwise it woudl be true also for programming without software tools at all, in 1's and 0's. So language, it's functional abstract complexity, do make a difference - and a large one. Mostly because of the complexity/cost to build new library parts.Article: 107334
Junction, Since we have no clue what the FPGA will do, we must specify junction temp. This is different from most other devices where the dissipation is completely known, and case temperature is specified (because that is obviously easier to measure). AustinArticle: 107335
Peter Alfke wrote: > V5LX50 have been available for several months. > I don't want to get into a fight with your distributor, but he is > feeding you nonsense data. > Unless you want a peculiar combination of package-speed-temp range > there should be no problem getting many samples now. > If you have trouble, send me an e-mail. But I will be gone through > labor day, Sept 4. > Peter Alfke, peter@xilinx.com > ========================== Usually in these cases, the date (May 2007) has come from _somewhere_ ? Supposing he _does_ want "a peculiar combination of package-speed-temp range" - could/would that push the date to May 2007 ? Or, perhaps that date is the release date for non-ES silicon, slightly garbled in transit ? -jgArticle: 107336
John_H wrote: > rickman wrote: > >> Peter Alfke wrote: >> >>> Rickman, the SRL16 (or SRL32 in Virtex-5) really is a "physical" shift >>> register that transfers all data bits to their respective neighbors. So >>> it will probably consume more power than a pointer-addressed RAM. >>> But you don't need the pointer, and it's also a neat way to load a LUT >>> with its 16 bits. >> >> >> I wasn't aware of that. Is this only true for the V5 parts, or has >> this always been true for SRLs in Xilinx parts that have them? > > > SRLs have been actual shift registers for quite some time. A recent > discussion pointed out that the Pre-V5 SRLs shifted charge from one > memory cell to the next (I'm assuming like a CCD) but this "trick" > didn't scale well beyond 90 nm so the V5 parts use master/slave latches > to halve the number of available elements in the SRLs. Could this "trick" have been part of the observed problem ? -jgArticle: 107337
Jim Granville wrote: > John_H wrote: > >> SRLs have been actual shift registers for quite some time. A recent >> discussion pointed out that the Pre-V5 SRLs shifted charge from one >> memory cell to the next (I'm assuming like a CCD) but this "trick" >> didn't scale well beyond 90 nm so the V5 parts use master/slave >> latches to halve the number of available elements in the SRLs. > > Could this "trick" have been part of the observed problem ? > > -jg Why would you suspect it might? The SRLs have been a joy to work with over the years. They've worked flawlessly.Article: 107338
rickman wrote: > Atmel has three devices on their HDD page and I am confident that they > offer them for sale. I expect that if I wanted to buy a million they > would be readily available. The OP did not say how many he expects to > use so I am just providing a potential source. What they cost will > depend on how many he wants. Guess I'll have to go look into that as well. I was going to bid an SATA controller design based on the mistaken assumption that since the XUP Virtex-II Pro board had SATA interfaces, that it would be relatively easy to include in the design. Even picked up one of these expensive XUP development systems to prototype it with. Let's just say that this insight was timely, and after the whining by Austin/Antti about the SATA-IO NDA's it's about time to cut my losses with Xilinx and pickup some Altera software and development boards. I'm getting real tired of wasting money on Xilinx products which do not work. Maybe Altera will listen to this, join SATA-IO and license the IP for it's next product turn.Article: 107339
John_H wrote: > Jim Granville wrote: > >> John_H wrote: >> >>> SRLs have been actual shift registers for quite some time. A recent >>> discussion pointed out that the Pre-V5 SRLs shifted charge from one >>> memory cell to the next (I'm assuming like a CCD) but this "trick" >>> didn't scale well beyond 90 nm so the V5 parts use master/slave >>> latches to halve the number of available elements in the SRLs. >> >> >> Could this "trick" have been part of the observed problem ? >> >> -jg > > > Why would you suspect it might? > The SRLs have been a joy to work with over the years. They've worked > flawlessly. In this discussion about FPGA failues, when pushed past the edge, a couple of things have made me ponder. The dominant Icc spike source in a FPGA is the clock tree, and data spikes will of course add, but I was a little surprised that data patterns seemed able to 'break' a design. So I was wondering if the Icc spikes on the SRL-shift is more extreme, and/or, if the nature of the chaining trick, made it more susceptable to the inductive kick effects. Given that newer devices _are_ claimed to be better able to cope, it is apparent some engineering changes have been made ? -jgArticle: 107340
Jim Granville wrote: > Peter Alfke wrote: > > V5LX50 have been available for several months. > > I don't want to get into a fight with your distributor, but he is > > feeding you nonsense data. > > Unless you want a peculiar combination of package-speed-temp range > > there should be no problem getting many samples now. > > If you have trouble, send me an e-mail. But I will be gone through > > labor day, Sept 4. > > Peter Alfke, peter@xilinx.com > > ========================== > > Usually in these cases, the date (May 2007) has come from _somewhere_ ? > > Supposing he _does_ want "a peculiar combination of package-speed-temp > range" - could/would that push the date to May 2007 ? > > Or, perhaps that date is the release date for non-ES silicon, slightly > garbled in transit ? > > -jg My request was for -ES parts LX50 Commercial temp FF676 package. I tried to get the part that would be the most readily available. That was why I was shocked by the delivery date of the distributor.Article: 107341
Antti Lukats wrote: > The ASSP vendors are very likely not directly scared, but for some reason > almost every document regarding SATA IC's is only available under NDA and > SATA PHY silicon is virtually impossible to obtain. Ok asshole (sorry folks, I did count to ten, a bunch of times). Since you are so free with your caustic insults and "free advice", including the go fly a kite BS ... let's put this in perspective. You and Austin have the gaul to whine about NDA's ... consider that Xilinx will not even relax any software interface IP for obsolete products that they refuse to provide full support for, so that Open Source and pickup the mess. Even on new products, they complain openly that they can not provide support for certain market segments because it's not profitable, and would be unfair to the stock holders. The are in over their heads turning new products at a breakneck speed, and drop the previous generations support before they even stop shipping the last of it. Xilinx doesn't give away much for free, as most forprofits are expected. And at the same time is completely hostile to open source support for XC4K parts, XC3K parts, Spartan parts, etc which they refuse to provide full support for. The offer to Xilinx was to provide open source support to it's customers for these old products, in fact, any product older than two generations back. They are so tight fisted about this, they prefer their customers and their end users have NO support at all, so they will migrate up and trash the old product. I can not think of a less customer friendly policy, a less deserving company to whine about free SATA IP access. So what is the whining about SATA-IO NDA crap really mean? Now, we have an open industry wide standards organization, with open membership, and Xilinx refuses to participate complaining the product of that organization doesn't provide free documentation and IP access. I can think of a lot of terms to describe this self serving bull shit that you two are bitching about. Hypocrites is at the top of the list. You want to insult me as being Mr Brass? .... just where do you two get off with such crap? You want to insult me as not having the right to make comments about the vendors not really caring about Xilinx and SATA ... and you two bitch about a non-existant exclusion conspiracy like you are Gods and can read all their minds .... and you can not even follow your own sick BS. Both of you sound like two spoiled little brats bitching having to pay your fair share like everyone else. As a Xilinx customer burned by the drop of VHDL/Verilog access to XC4085/XC4062 parts a few years back, I think their support policy for old products is a total travesty. I bought tens of thousands of dollars worth of new and old XV4K parts just as this happened, and got burned bad. But I stuck with the company. For the last 6 months Austin and Peter have been a shining example of why purchasing the next $30K of Virtex, Virtex-E, Virtex-II and Virtex-Pro parts was a horrible mistake. Xilinx just plain sucks as an arrogant customer insensitive corporation gone awry. That you lackeys just compound that to gain good graces, and to hopefully pickup some crumbs of support, is just a crying shame. Xilinx simply doesn't have problems ... it is the problem.Article: 107342
Antti wrote: > ML300 and digilent XUP V2Pro both have SATA connectors on > them but can not actually be used for SATA as of compliance issues. > (OOB and CDR lock range mainly) As a new owner of XUP V2Pro board, my comment is that Xilinx screwed up royally by not joining the standards process BEFORE shipping a SATA based product or design. I purchased the board simply BECAUSE it had these interfaces. There are certain expectations that systems vendors actively take part in industry standards if they are going to ship and support products based on those standards. I've spent years of my life supporting standards processes ... they are the most valuable customer asset a systems company can invest in to protect both their products, their customers products, and a safe product migration path over time.Article: 107343
jeff, I guess I'd be shocked, too. We have just finished early access, and are in the process of changing to general ES. To define a few terms, early access is defined as a program where we decide exactly how many customers we are going to support, and directly support them. To be part of early access, you need to get you FAE to request a part on your behalf, and it has to be accepted. That part of the program generally favors the "big guys", although, we do have smaller businesses that we enagage with. The general ES program is just that, order entry is opened, and all orders are scheduled through the "normal channels", which means that you are no longer dealing directly with Xilinx, but are working through a distributor. Peter, and my, view of the world is a world with parts, reports of shipments, crawl charts showing dollars shipped of Virtex 5, and scehdules and plans. That may be far different from your view, as you are just one request, among who knows how many, for general ES parts. I apologize in advance, as I have no way to know, and no way to change what happens with the general ES Virtex 5 shipments. Yes, we have LX50, 30, 85, and 110 die, and yes, they are yielding, now. But that may have no bearing on your individual order. We have been criticized, and properly so, for our sins and omissions of the past. If anything, Xilinx does listen, and does place procedures which are intended to prevent the kinds of problems we may have had in the past. You may at least take some pride for your calling things to our attention, as we do listen, and we do recognize that anything that we can do better at, we should do better at. I would encourage you to email Peter, and let him know what you are requesting, and through whom. Whatever pull he has, he will be an advocate for you. The truth is that we are rolling out V5, with a great deal more process and procedure in place to prevent the kinds of issues we have been accused of in the past. Some things will always remain outside of our control, but anything over which we do have control, we will do even better to fufill our promises. AustinArticle: 107344
On Sat, 26 Aug 2006 12:39:12 -0700, Austin Lesea wrote: > Peter, > > It is the substate to s,d pn junction, but it does not resemble the > 1N914 that is the "standard" for measuring temperature. > > I have no idea if it would work, or not. > > Before we had temp diode, people would calibrate the frequency shift on > a ring oscillator, with nothing else in the part, forcing the > temperature. > > Then, with the design running, all you had to do was measure the > frequency of the ring oscillator to get a reading. > > Since the temp diode, the ring oscillator method has been abandoned. > > Austin I'll have to do a little temperature chamber test then. For my (room temperature) measurements looks like a standard ~.7V @ 1 ma forward junction to me. Peter WallaceArticle: 107345
I appreciate the feedback from Peter and Austin and feel somewhat better knowing that there is not some big yield problem with the part. Part of this problem may be with our distributor. When I initially contacted our local rep he said I should order P/N XC5VLX50-1FF676CES through Nu Horizons in order to get sample parts which we did back in July. I was out of town Friday but was told by our purchaser today that we got a FAX from Nu Horizons late Friday with a delivery date of May 2007. I have gotten the FAX tonight and the part quoted on the FAX is for XC5VLX50-1FF676C and a delivery of May 2, 2007. This looks like the delivery date for commercial parts and not engineering samples. I will try and straighten this out with the distibutor on Monday and hope that ES versions of this part are available. We are not a huge company but we have been loyal Xilinx users since 1990 and hope that counts for something when it comes to determining who gets ES parts. Austin Lesea wrote: > jeff, > > I guess I'd be shocked, too. > > We have just finished early access, and are in the process of changing > to general ES. > > To define a few terms, early access is defined as a program where we > decide exactly how many customers we are going to support, and directly > support them. > > To be part of early access, you need to get you FAE to request a part on > your behalf, and it has to be accepted. > > That part of the program generally favors the "big guys", although, we > do have smaller businesses that we enagage with. > > The general ES program is just that, order entry is opened, and all > orders are scheduled through the "normal channels", which means that you > are no longer dealing directly with Xilinx, but are working through a > distributor. > > Peter, and my, view of the world is a world with parts, reports of > shipments, crawl charts showing dollars shipped of Virtex 5, and > scehdules and plans. > > That may be far different from your view, as you are just one request, > among who knows how many, for general ES parts. > > I apologize in advance, as I have no way to know, and no way to change > what happens with the general ES Virtex 5 shipments. Yes, we have LX50, > 30, 85, and 110 die, and yes, they are yielding, now. But that may have > no bearing on your individual order. > > We have been criticized, and properly so, for our sins and omissions of > the past. If anything, Xilinx does listen, and does place procedures > which are intended to prevent the kinds of problems we may have had in > the past. You may at least take some pride for your calling things to > our attention, as we do listen, and we do recognize that anything that > we can do better at, we should do better at. > > I would encourage you to email Peter, and let him know what you are > requesting, and through whom. Whatever pull he has, he will be an > advocate for you. > > The truth is that we are rolling out V5, with a great deal more process > and procedure in place to prevent the kinds of issues we have been > accused of in the past. Some things will always remain outside of our > control, but anything over which we do have control, we will do even > better to fufill our promises. > > AustinArticle: 107346
fpga_toys@yahoo.com wrote: > Ok asshole (sorry folks, I did count to ten, a bunch of times). Since > you are so free with your caustic insults and "free advice", including > the go fly a kite BS ... let's put this in perspective. Maybe you should have counted to eleven? ;^) > Xilinx doesn't give away much for free, as most forprofits are > expected. And at the same time is completely hostile to open source > support for XC4K parts, XC3K parts, Spartan parts, etc which they > refuse to provide full support for. The offer to Xilinx was to provide > open source support to it's customers for these old products, in fact, > any product older than two generations back. They are so tight fisted > about this, they prefer their customers and their end users have NO > support at all, so they will migrate up and trash the old product. > > I can not think of a less customer friendly policy, a less deserving > company to whine about free SATA IP access. So what is the whining > about SATA-IO NDA crap really mean? > > Now, we have an open industry wide standards organization, with open > membership, and Xilinx refuses to participate complaining the product > of that organization doesn't provide free documentation and IP access. I can't say anything about their support of mature products. They will continue to sell parts, but yes, they don't provide much support. But the issue of open documentation on SATA, is that about the cost to Xilinx or the cost to their customers? I can see where they would not want to work with a standard that makes it difficult for their customers to get documentation. I can't say I have ever seen IP offered for free other than at opencores.org. Did Xilinx really complain that the SATA IP is not free?Article: 107347
rickman wrote: > But > the issue of open documentation on SATA, is that about the cost to > Xilinx or the cost to their customers? We all license IP .... certainly Xilinx customers should be used to that by now given core costs and marketing. > I can see where they would not > want to work with a standard that makes it difficult for their > customers to get documentation. And those that purchase Xilinx cores are free to republish the works on the net? > Did Xilinx really > complain that the SATA IP is not free? Well ... take a look at Austin's rant ... and the rant that triggered this flame fest.Article: 107348
Patrick, wrt the XMD commands I was a little bit sloppy. Please have a look at the xmd.ini that ships as part of XAPP575 to see what the correct commands are. If you have the xmd.ini in the directory where you start xmd it will automatically pick it up and connect to the UC2. The correct short form of what is in xmd.ini is: $ xmd XMD% connect ppc hw -debugdevice icachestartadr 0xffff0000 dcachestartadr 0xffff8000 XMD% xwreg 0 msr 0x40000 XMD% xwreg 0 msr 0 XMD% con The xwreg lines toggle the WE bit on the processor to deassert DEBUGHALT. I believe that's what was missing in your commands below, i.e. DEBUGHALT is still asserted and the processor stops right on the next instruction. I had a quick look at the design files. The custom board file you use does not map the caches to the correct addresses (it does not map them at all). It might be easier if you add your board to genace.tcl and use one of the existing boards in there as an example. Unfortunately, I do not have one of the Avnet boards at hand at the moment and will hunt for one on Monday if your problems persist. - Peter Patrick Dubois wrote: > Peter, > > Thanks for offering your help. I'll send you my design by e-mail > shortly. > > I'm targetting our own board but for the time being, I'm just trying to > make something work on the "Avnet Virtex-II Pro Evaluation Board". > > I tried the instructions you provided for xmd, and everyting works > except for the "run" part. I get something like that: > > XMD% run > PC reset to 0xffff3ffc, Clearing MSR Register > Processor started. Type "stop" to stop processor > RUNNING> > XMD% > Processor stopped at PC: 0xffff0000 > > The processor stopped instantly. I then tried to reset and start again: > > XMD% rst > Target reset successfully > XMD% run > PC reset to 0xffff3ffc, Clearing MSR Register > Processor started. Type "stop" to stop processor > RUNNING> > > Now this 2nd time the processor seems to run, but I don't get the > normal "running" behavior that I get in GDB. The program is quite > simple, it mirrors the state of the 8 dip switches to the 8 leds on the > board (infinite loop). The leds all stay off with the above steps > (which indicates that the code is not running properly). I get the same > behavior when I try to load everything through SystemAce. > > Is there a special step to do when compiling "release" code? > > I'll get in touch with you by e-mail shortly. Thanks Peter. > > Patrick >Article: 107349
sivakanth.telasula@gmail.com ha scritto: > Hello, > > I am newbie learning Xilinx system generator. > > I have made a simple down sampler program which will just downsample > the incoming signal and presents it as downsampled version. > > The simulink simulation runs well, but when I try to create a HDL > netlist, the process just hangs in "Running Netlister". > > Can someone help with this issuse and can provide a solution. > > Sivakanth. Hi, Try to restart Matlab and delete the '.\netlist' directory. My design (with sysgen 8.1) work correctly.
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