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
daver2 wrote: > I am implementing an extremely old logic design (circa 1965!) on a > Xilinx Virtex 4 (XC4VLX25). > > For those interested - it is the logic for the computer that flew to > the moon and back! The design is based on approximately 5,000 3-input > NOR gates and not a flip flop in sight! For the circuit diagrams see > website 'http://klabs.org/history/ech/agc_schematics/index.htm'. > Does the design implement flops using NORs with feedback? If so, that could be an issue. The ISE tools don't like combinational feedback. -KEvinArticle: 111151
Hi, I hope someone would be able to help me with my issue. I have a Xilinx Virtex II Pro Eval board from Avnet. The board has a serial interface to program it. I bought a Serial to USB Converter cable from RadioShack to try to program the FPGA from Impact. I have had no luck in doing this so far. Impact doesn't recognize the cable and it always fails. Can someone point me on how would I be able to program the FPGA with the Serial-USB Converter cable?. Ram.Article: 111152
Hi, all: I want to incorporate moduleA and moduleB to XPS and connected them with microblaze. ModuleA and ModuleB have connection with microblaze through FSL and OPB separately, and also, moduleA and Moduleb have connection between themselves. My question is: how to describe the connection between moduleA/B in XPS. Thanks a lot, CathyArticle: 111153
aravind wrote: > Does anyone know how to simulate the picoblaze processor in > modelsimXE(xilinx specific version) > Is it possible? http://www.mediatronix.com/pBlazeIDE.htmArticle: 111154
Evan Lavelle wrote: > - What are MicroWriteBus() and MicroReadBus()? I can do macros and > pass parameters to the macros; you can call the macros from wherever > you want in the vector file. I can also do basic C-like control > structures - looping, branching based on tested values, and so on. Shorthand notation for "generic test-bench procedure/task call that performs a read or write on my microprocessor's external bus, from the micro's point-of-view." -aArticle: 111155
"Joseph Samson" <user@example.net> wrote in message news:wvK0h.24436$7I1.12748@newssvr27.news.prodigy.net... > > I run xmd and chipscope together all the time on the same JTAG port. In > fact, recently I was debugging 2 different systems simultaneously with > one JTAG cable. I'd plug into one system and do some xmd commands, > unplug the flying leads, plug into the other board and trigger > chipscope. Nither was confused. > > Did you have any timing errors after routing the chip with the chipscope > inserted? That might cause errors in the ChipScope display. > Joseph, I might have had a few timing errors, which could affect some of the channels but not all... What kind of cable (USB, parallel, etc.) are you using and what chip/CPU combination? Thanks, /MikhailArticle: 111156
Brian Davis wrote: > Peter Alfke wrote: > > we may have different definitions of the word "nasty" > <snip> > > I wish these problems could be ventilated in a less aggressive tone, > > but that may be a question of personal taste. > > Since you continue to refer to my original post as "nasty" > and now "agressive", I ask you once again to explain > exactly what part of that post you found offensive. > > I am hardly the first person on the newsgroup to express > exactly these same opinions about the usefulness of WebCases, > and your documentation system's handling of both customer > feedback and long-known, yet poorly documented, problems. > > My comments are based on 20 years of experience using > Xilinx parts; during that time I have attempted to have Xilinx > correct serious flaws in their documentation and/or software > on several occasions, with no success, as described in my > original post. You might not want to go down this road. The Xilinx reps in this group are a bit quick to assume that others are posting with an attitude all the while giving all the attitude in the world in their own posts. Peter is actually one of the nicer guys, but he has his moments as you have found. I am of the opinion that it may be a bit of a cultural thing at the company. They seem to have developed a corporate opinion over the years that they are the best and are better off being defensive about their faults. Of course this is not accurate as a blanket statement. There are many times when they are very helpful. This is a comment about the "tone" of the replies you may get from time to time. My point is that it is not likely to be worth the effort to try calling them out on the "tone" (or even substance) of their posts.Article: 111157
Kevin Neilson wrote: > daver2 wrote: > > I am implementing an extremely old logic design (circa 1965!) on a > > Xilinx Virtex 4 (XC4VLX25). > > > > For those interested - it is the logic for the computer that flew to > > the moon and back! The design is based on approximately 5,000 3-input > > NOR gates and not a flip flop in sight! For the circuit diagrams see > > website 'http://klabs.org/history/ech/agc_schematics/index.htm'. > > > > Does the design implement flops using NORs with feedback? If so, that > could be an issue. The ISE tools don't like combinational feedback. > -KEvin Kevin, Yes, the design does use NOR gates with feedback to create the flipflops - and yes I am getting warnings from XST about combinatorial loops. I am (as we speak) going through the network that the synthesiser has generated for the 4LUT's to see that what it has generated is what should have been generated! The original logic would have potentially suffered from unstable oscillation and glitches if it had not been designed properly in the first place so it is my belief that ISE is complaining about something that won't occur in reality. DaveArticle: 111158
Tim wrote: > daver2 wrote > > I don't really want to change the logic to suite the tool as I am > > trying to be as true to the original design as I can be. I have coded > > the logic up in a similar manner to the following: > ... > ... > > \37101\ <= not( \37105\ or \37102\ ); > > \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay; > > \37103\ <= not( \37102\ or CLOCK or \37104\ ); > > \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\; > > Can you write a Perl script to whizz through the code and extract the flops > and latches? Tim, Thanks for the idea Tim. Let me think about that one for a while... DaveArticle: 111159
MM wrote: > Joseph, > > I might have had a few timing errors, which could affect some of the > channels but not all... What kind of cable (USB, parallel, etc.) are you > using and what chip/CPU combination? Parallel Cable IV running under XP, connecting to Virtex2Pro, Virtex4 FX60 and Virtex 4 SX55. --- Joe Samson Pixel VelocityArticle: 111160
Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and I don't like to be called a "Troll of Implausible Deniability". Instead, I want to address the issues. I have funneled many comments from this newsgroup to our support management. And they have acknowledged them, and have admitted errors. And we are working on improvements. But as I wrote earlier, the parts are getting very complex and are being used in many different ways. Making every user happy is our goal, but I have been around long enough to relize that this is an elusive goal. Xilinx is listening and responding to this newsgroup, you have to give us credit for that. Whether our "bedside manners" are always perfect is another question. The "patients" don't always show perfect behavior either... Peter Alfke =============================== On Oct 30, 10:55 am, "rickman" <gnu...@gmail.com> wrote: > Brian Davis wrote: > > Peter Alfke wrote: > > > we may have different definitions of the word "nasty" > > <snip> > > > I wish these problems could be ventilated in a less aggressive tone, > > > but that may be a question of personal taste. > > > Since you continue to refer to my original post as "nasty" > > and now "agressive", I ask you once again to explain > > exactly what part of that post you found offensive. > > > I am hardly the first person on the newsgroup to express > > exactly these same opinions about the usefulness of WebCases, > > and your documentation system's handling of both customer > > feedback and long-known, yet poorly documented, problems. > > > My comments are based on 20 years of experience using > > Xilinx parts; during that time I have attempted to have Xilinx > > correct serious flaws in their documentation and/or software > > on several occasions, with no success, as described in my > > original post.You might not want to go down this road. The Xilinx reps in this group > are a bit quick to assume that others are posting with an attitude all > the while giving all the attitude in the world in their own posts. > Peter is actually one of the nicer guys, but he has his moments as you > have found. I am of the opinion that it may be a bit of a cultural > thing at the company. They seem to have developed a corporate opinion > over the years that they are the best and are better off being > defensive about their faults. Of course this is not accurate as a > blanket statement. There are many times when they are very helpful. > This is a comment about the "tone" of the replies you may get from time > to time. > > My point is that it is not likely to be worth the effort to try calling > them out on the "tone" (or even substance) of their posts.Article: 111161
If you're doing this because you don't have another two available pins on the FPGA, you need a bigger FPGA, or save pins somewhere else. I would not go into a board design using more than 90-95% of the pins on the FPGA. Now if I was updating a mature design or something like that, I might allow that margin to get a little tighter. The flexibility and reliability of doing this sort of thing, especially with clocks, inside the FPGA (where the STA tools can manage your timing) is far superior to trying to do it with an extra component on the board. Andy Elmo Fuchs wrote: > Hi, > > I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke > the Virtex-II series they now offer the possibility to route various clock > signals to several domains on the FPGA and select them locally by specific > clock multiplexer inputs. > Because of the restricted amount of available pins on the device I selected > (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input > on each side of the FPGA, thereby saving clock multiplexer inputs which I > can use as normal GPIOs, and use an external clock multiplexer instead for > my 3 clocks. > Has anyone made experience with such or similar solution? Has anyone used an > external clock multiplexer device for frequencies up to 500 MHz, yet? Is > there any recommendation which chip I could use for this application in > terms of jitter, etc.? And by the way... is my approach advisable, at all? > > Any comments are appreciated. > > Regards ElmoArticle: 111162
Evan Lavelle wrote: > Ok, is it worth any more than $0 now? :) In a word, no. Why go to the trouble of learning a new language to try to do things like macros, loops, random stimulus, etc. when you have the power of the VHDL language at your disposal in a VHDL testbench? Now, if you have vectors from an external model/simulation, those can be applied with text-io relatively easily from within a vhdl testbench that will run on any vhdl simulator. My "unit level tests" are usually at a high enough level that I need a lot more capability than is available in any vector based scripting language. Andy From janvi@t-online.de Mon Oct 30 12:17:56 2006 Path: newssvr11.news.prodigy.com!newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!newsfeed.freenet.de!news.albasani.net!news.warperbbs.de!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Message-Id: <45465df7$0$30329$9b4e6d93@newsspool1.arcor-online.net> From: janka vietzen <janvi@t-online.de> Subject: Profibus implementation? Newsgroups: comp.arch.fpga Date: Mon, 30 Oct 2006 21:17:56 +0100 User-Agent: KNode/0.10.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 5 Organization: Arcor NNTP-Posting-Date: 30 Oct 2006 21:17:59 CET NNTP-Posting-Host: 2426e695.newsspool1.arcor-online.net X-Trace: DXC=[8RHHgkj\kg<6cDJZfMd_cic==]BZ:afn4Fo<]lROoRa^YC2XCjHcbiDd]5FP7@cFhFdWcRPJWW\aDVg6_Sj8ZmeV]^[o?7LY4b X-Complaints-To: usenet-abuse@arcor.de Xref: prodigy.net comp.arch.fpga:122126 Is there any implementation of the profibus protocol for FPGA/CPLD known? DP V0 for cyclic traffic is sufficient. Preferably implementations for MachXO or general VHDL. The Siemens Profibus Chip bothers a lot and muxed address data bus only fits to old fashioned mikrokontrollers.Article: 111163
fl wrote:
> Hi,
> I am learning VHDL from Mike's example Uart.vhd in ISE 8.2. For
> behavioral simulation, I can run Modelsim smoothly.
> After I check the library work, I find the work.uart (for other than
> behavioral simulation) does not have char_len_g anymore (only the
> source, i.e. behavioral file has that generic definition). How to deal
> with this?
Choose one.
1. Skip the post-route sim because it is not normally
needed with a synchronous design.
2. Search and replace the _g identifiers with constants.
3. Open a case with Xilinx and ask them
to fix whatever software generates test_uart.ndo
4. Write your own do script using vsim -G as shown
in the reference testbench.
-- Mike Treseler
Article: 111164daver2 wrote: > Kevin Neilson wrote: > >>daver2 wrote: >> >>>I am implementing an extremely old logic design (circa 1965!) on a >>>Xilinx Virtex 4 (XC4VLX25). >>> >>>For those interested - it is the logic for the computer that flew to >>>the moon and back! The design is based on approximately 5,000 3-input >>>NOR gates and not a flip flop in sight! For the circuit diagrams see >>>website 'http://klabs.org/history/ech/agc_schematics/index.htm'. >>> >> >>Does the design implement flops using NORs with feedback? If so, that >>could be an issue. The ISE tools don't like combinational feedback. >>-KEvin > > > Kevin, > > Yes, the design does use NOR gates with feedback to create the > flipflops - and yes I am getting warnings from XST about combinatorial > loops. I am (as we speak) going through the network that the > synthesiser has generated for the 4LUT's to see that what it has > generated is what should have been generated! > > The original logic would have potentially suffered from unstable > oscillation and glitches if it had not been designed properly in the > first place so it is my belief that ISE is complaining about something > that won't occur in reality. > > Dave > Unfortunately, the original design depends on redundant cover terms and circuit delays to guarantee that proper operation. FPGAs are not intended for what amounts to asynchronous logic. Unlike the original design, the delays in the interconnect between the gates in the FPGA are significant and need to be considered when doing the design. Unless you intend to had route this, you can't guarantee the delays are properly balanced to avoid the hazards the original design avoids. Also, the FPGA tools generally do not leave the cover terms necessary to avoid glitch hazards in an async design without you explicitly forcing the tools to keep the terms. You would be more likely to achieve success by converting the flip-flops in the original design to FPGA flip-flops, something that kind of goes against your intent I suppose. The ISE complaints are quite valid, and unless you take the pains to make sure the design is not reduced by the tools and that the routing delays are properly balanced and considered, you will likely not wind up with a working design. In order to get the tools to keep from optimizing out stuff you need in there for hazard covers, you will at least need to put syn_keeps or the equivalent on each node in the original design, and may have to go as far as explicitly instantiating xilinx primitives with the proper init strings for each gate. Instantiation might in the long run be the easier way to go, as it gives you a bit more control when it comes to placement. Good luck.Article: 111165
> Parallel Cable IV running under XP, connecting to Virtex2Pro, Virtex4 > FX60 and Virtex 4 SX55. Hmm... The only difference I can see is that I am using a Platform Cable USB... The chip is V4FX60 and I am using its PPC core... /MikhailArticle: 111166
The original design was verified for the timing and behavior (specifically glitch-free behavior) of hard NOR gates within the gate array fabric that it was implemented on. Change the NORs to luts, and change the timing (radically), and you no longer have a reliable design, no matter how reliable the original was. Combinatorial feedback loops in FPGAs are bad medicine. If the original design had macros for every flop built out of NORs, you could replace those macros with rtl code for conventional flops, and then ISE would be happy, and so would you/your design. Otherwise your going to have to be able to recognize the pattern of feedback in NOR networks that makes a flop, then cut that out and replace it with a conventional flop. Andy daver2 wrote: > Kevin Neilson wrote: > > daver2 wrote: > > > I am implementing an extremely old logic design (circa 1965!) on a > > > Xilinx Virtex 4 (XC4VLX25). > > > > > > For those interested - it is the logic for the computer that flew to > > > the moon and back! The design is based on approximately 5,000 3-input > > > NOR gates and not a flip flop in sight! For the circuit diagrams see > > > website 'http://klabs.org/history/ech/agc_schematics/index.htm'. > > > > > > > Does the design implement flops using NORs with feedback? If so, that > > could be an issue. The ISE tools don't like combinational feedback. > > -KEvin > > Kevin, > > Yes, the design does use NOR gates with feedback to create the > flipflops - and yes I am getting warnings from XST about combinatorial > loops. I am (as we speak) going through the network that the > synthesiser has generated for the 4LUT's to see that what it has > generated is what should have been generated! > > The original logic would have potentially suffered from unstable > oscillation and glitches if it had not been designed properly in the > first place so it is my belief that ISE is complaining about something > that won't occur in reality. > > DaveArticle: 111167
>> I was unable, however, to use a double edge clock circuit >> on the output. The OSERDES does not have a 7x option and >> when you try 8x you get 8x data bits no matter how you >> drive the clkdiv input. > > Hi Brad, (You can now spend all evening wondering where I know you > from...) Mutual client, I suppose. > I can't shed any light on your Virtex problems, but I am interested as to > what leads you to bother with trying to do CameraLink with an FPGA, rather > than just using the appropriate NatSemi ChannelLink chip (I'm too lazy to > look up the number, but you know the one I mean.) Pin count and input/output flexibility. I have used the National Chips before. > When everything about CameraLink is designed around those interface chips, > it has always seemed to me like unnecessarily hard work to reimplement > their behaviour elsewhere. > > Is it cost, space or a sense of adventure which pushes you away from them > in this design? Yes. > Cheers, > > Will >Article: 111168
> You already need to use an entire IO tile for each output pair, as you > are using a differential IO standard. As such you have two OSERDES > available for each pair. While you could use them together to get DDR > mode (as you have done), I would suggest using them cascaded in SDR x7 > mode. The slowest speed grade of V4 will easily support 280MHz clock, > and IO, and no additional logic is required to determine pixel > boundary. This will sork up to the max clock rate of the DCM, which is > (IIRC) about 400MHz, or about a 57MHz pixel clock. I would be willing to give this a try again if you tell me you have had good success with SDR. I believe when I tried SDR, I needed two DCMs to generate the high frequency and was having data corruption on receiving. I might have been doing something wrong. Another vote for National Chips if the highest frequency at SDR is 57MHz. The Camera Link standard should go to 80MHz. > > > Regards, > Erik. > > --- > Erik Widding > President > Birger Engineering, Inc. > > (mail) 100 Boylston St #1070; Boston, MA 02116 > (voice) 617.695.9233 > (fax) 617.695.9234 > (web) http://www.birger.com >Article: 111169
Thanks, Peter. It seems the apparant name calling was the problem. Brian - you can fill us in on what you actually meant if it's different from Peter's interpretation. Personally, I saw other interpretations and saw the text as trying "to be cute, but [he] blew it." The original post is pertinent. I stopped trying to submit webcases a while back, instead calling straight to the Xilinx hotline to kickstart the issue rather than dealing with the typical email response of "we need more information" even when extreme care was taken to provide all needed information. I was even called by someone from Xilinx asking about my use of the hotline versus webcase; I fed back the information I felt pertinent. I like the idea of a "mystery shopper" approach where Xilinx can do an informal audit of their own procedures by submitting cases of their own. It may sound at first listen like it would be a waste of resources, having a CAE doing work that results in no actual help to the customer. But it could be a serious help to the customer if it exposes the limited effectivity (at times) of the WebCase process. It appears that we can't submit bugs for CRs unless we submit our design since software likes to have cases that can reproduce the bug to prove a bug fix. My company is hesitant about shipping out source code in spite of the bidirectional NDAs in place. Webcase isn't (or wasn't when I used it) a terribly effective way of communicating an issue no matter how well considered in the original submission. Even if 60% of webcases succeed in providing a timely accurate response, the experience from the other 40% swamps the engineers memory. - John_H "Peter Alfke" <peter@xilinx.com> wrote in message news:1162237816.355133.116950@e3g2000cwe.googlegroups.com... > Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and > I don't like to be called a "Troll of Implausible Deniability". > Instead, I want to address the issues. I have funneled many comments > from this newsgroup to our support management. And they have > acknowledged them, and have admitted errors. > And we are working on improvements. > But as I wrote earlier, the parts are getting very complex and are > being used in many different ways. Making every user happy is our goal, > but I have been around long enough to relize that this is an elusive > goal. > Xilinx is listening and responding to this newsgroup, you have to give > us credit for that. Whether our "bedside manners" are always perfect is > another question. The "patients" don't always show perfect behavior > either... > Peter Alfke > ===============================Article: 111170
My guess would be that you need a special driver/software to do the programming because it would take an application aware middle device to convert from USB to the boards programming interface. ---Matthew Hicks <ramakrishnan.vijayakumar@gmail.com> wrote in message news:1162230211.740121.266040@i42g2000cwa.googlegroups.com... > Hi, > I hope someone would be able to help me with my issue. I have a > Xilinx Virtex II Pro Eval board from Avnet. The board has a serial > interface to program it. I bought a Serial to USB Converter cable from > RadioShack to try to program the FPGA from Impact. I have had no luck > in doing this so far. Impact doesn't recognize the cable and it always > fails. Can someone point me on how would I be able to program the FPGA > with the Serial-USB Converter cable?. > > Ram. >Article: 111171
John, Peter and I are very serious about improving the customer experience. After all, that is really all that counts: happy customers all designing commercially successful products with Xilinx FPGAs. This dialog is providing for some real creative thinking, so please let it continue. Just one comment, for every case that is resolved in a un-satisfactory way, it takes more than ten cases with the same engineer to repair the 'damage'. The good news is that we are doing much much better than 9 in 10 cases successfully concluded, but all it takes is a few to cause a lot of anguish (and unhappy postings to a newsgroup). We don't even want a few cases to go unresolved, but realize realistically that some cases will be. Just have to make those as few as we possibly can, and be sure that we learn all the lessons we can from them. Austin John_H wrote: > Thanks, Peter. It seems the apparant name calling was the problem. Brian - > you can fill us in on what you actually meant if it's different from Peter's > interpretation. Personally, I saw other interpretations and saw the text as > trying "to be cute, but [he] blew it." > > The original post is pertinent. I stopped trying to submit webcases a while > back, instead calling straight to the Xilinx hotline to kickstart the issue > rather than dealing with the typical email response of "we need more > information" even when extreme care was taken to provide all needed > information. I was even called by someone from Xilinx asking about my use > of the hotline versus webcase; I fed back the information I felt pertinent. > > I like the idea of a "mystery shopper" approach where Xilinx can do an > informal audit of their own procedures by submitting cases of their own. It > may sound at first listen like it would be a waste of resources, having a > CAE doing work that results in no actual help to the customer. But it could > be a serious help to the customer if it exposes the limited effectivity (at > times) of the WebCase process. It appears that we can't submit bugs for CRs > unless we submit our design since software likes to have cases that can > reproduce the bug to prove a bug fix. My company is hesitant about shipping > out source code in spite of the bidirectional NDAs in place. > > Webcase isn't (or wasn't when I used it) a terribly effective way of > communicating an issue no matter how well considered in the original > submission. Even if 60% of webcases succeed in providing a timely accurate > response, the experience from the other 40% swamps the engineers memory. > > - John_H > > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:1162237816.355133.116950@e3g2000cwe.googlegroups.com... >> Rickman, I disagree. I may be (overly?) sensitive to a nasty tone, and >> I don't like to be called a "Troll of Implausible Deniability". >> Instead, I want to address the issues. I have funneled many comments >> from this newsgroup to our support management. And they have >> acknowledged them, and have admitted errors. >> And we are working on improvements. >> But as I wrote earlier, the parts are getting very complex and are >> being used in many different ways. Making every user happy is our goal, >> but I have been around long enough to relize that this is an elusive >> goal. >> Xilinx is listening and responding to this newsgroup, you have to give >> us credit for that. Whether our "bedside manners" are always perfect is >> another question. The "patients" don't always show perfect behavior >> either... >> Peter Alfke >> =============================== > >Article: 111172
John_H wrote: > > I like the idea of a "mystery shopper" approach where Xilinx can do an > informal audit of their own procedures by submitting cases of their own. It > may sound at first listen like it would be a waste of resources, having a > CAE doing work that results in no actual help to the customer. What about the _really_ radical idea, of getting the "mystery shopper" to actually try and use the tools, and submit a real web case, based on whatever issues they encountered ? :) [that way, they do actually help the user base !] -jgArticle: 111173
Jim, It may surprise you, but the FPGA Lab (which I manage) leads in the verification and characterization of new silicon. In order to do this, we use the same software tools the customers do (the surprising part, perhaps?). So, we typically file hundreds of change requests, and bugs per month when we first get the silicon back. Yes, we are the first users, and no, we don't do just "goofy" special stuff, but are required to help get things like the PCIe designs working for the plug-fests and testing off-site, the DSP filters to work, the FIFO/BRAM to pack properly, measure the SRL16 power, and so on. Next time you wonder "Hasn't anyone ever even tried this before!" the folks in my group probably have, and may have a bug fix request in for it. If not, we probably just got lucky, and missed that particular case. We try to keep lots of old cases around for regression testing (just common good practice). We are not alone, there is the systems engineering group, the applications group, product test group, the DSP group, the embedded systems folks, early access customers, design services group, all the FAE's that can't wait to see if the new part is a better fit for their customers, and a whole slew of other quality control systems in place. Admittedly, all it takes is just one bug that isn't caught to ruin your day. Austin Jim Granville wrote: > John_H wrote: >> >> I like the idea of a "mystery shopper" approach where Xilinx can do an >> informal audit of their own procedures by submitting cases of their >> own. It may sound at first listen like it would be a waste of >> resources, having a CAE doing work that results in no actual help to >> the customer. > > What about the _really_ radical idea, of getting the "mystery shopper" > to actually try and use the tools, and submit a real web case, > based on whatever issues they encountered ? :) > [that way, they do actually help the user base !] > > -jg >Article: 111174
Hello,
> I am using xup virtex2 pro with xc2vp30 fpga and I am trying to
send data
> between two boards.
> I do not want to use the example (xupv2p_aurora.zip), I want to
create it.
> using aurora software, I generated the aurora core and at the
command page I
> used xilperl to create the .ise file, then I used project
navigator to run the
> project.
> Using chipscope, I synthesized and inserted ila.cdc file into the
design.
> One of my problems is when I try to modify my connections in
chipscope
> inserter I don't know what I'm doing, I am a beginner in this.
Another problem
> is the data, I don't know how to deal with it, in other words I
don't know how
> and where to insert it into the design ( I am not very good in
vhdl or
> verilog). And the last problem is that I am using one board right
now to loop
> my data out and in the board, now when I use two boards how do I
deal with
> this and what file should I make changes to?
> I really appreciate your help
>
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