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
Ray Andraka <ray@andraka.com> wrote: >The problem is that if the reset is released right at the clock edge at >any one flip-flop, that flip-flop can go metastable, and can result in >it landing in the '1' state instead of the '0' state. I saw this exact >failure on an SDRAM controller provided as part of the infrastructure IP >on one of the high-end 3rd Party FPGA boards two years ago. The fix, >BTW, was to add a synchronizing flip-flop to make removal of the reset >to the whole counter synchronous with the counter's clock. Yes, this can happen, and it is OK. If the FF has an asynchronous clear, the D input is one, and the clear is released just before the clock edge, the FF can go metastable, and might resolve to one or zero. If the FF has an asynchronous clear and the D input is zero, there is no chance of a metastable result. So the only FF that can go metastable on the first clock edge after reset is the LSB. That may well mess up a SDRAM controller, but will not cause this circuit to do anything other than have the extra delay of the metastable resolution time if that slips past the next clock edge. Which is acceptable, as all we are hoping for is a clear release from reset for the rest of the design. >For the SRL16, yes, you are correct, the metastable performance sucks. >I should have been more exact by stating the SRL16 should be preceded by >a flip-flop. The SRL16 is essentially being used as a counter to delay >the reset. You want the FF before the SRL16, as that is where the clock >domain crossing is. You will also want a FF after the SRL16, but that >one is for timing closure, not metastability reasons. Good explanation. -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 92451
Hi, all. This is Tomoya greeting from Japan. I would like to hear about Altera Stratix-II ES(engineering sample)/MP(mass production) differences. Here is background of our isse (we're facing); We'd made three DDR evaluation boards using Altera Stratix-II EP2S180/130. It has DDR interface, DDR memories, and many IOs (GPIO: General purpose IO). At first, we used EP2S180/130ES (engineering sample, working sample) because of delivery. It worked well. DDR worked well and GPIO ran at 200 MHz (or more) data communication speed between one board to another board (board to board). After that, we'are now making same evaluation set. We use same PCB bare board, same devices/parts ... only differences are that we used EP2S180/130MS (mass production. Of course, same speed grade!). However, the new one does not work well. It works when we drop its speed (from 200 to 150 MHz). We're now guessing it has clock problem. Especially, FPGA internal PLL. Does anyone has had/faced same issue? Does anyone knows any differences between ES and MP of EP2S180/130? If you have any issue/information about these, let me know. It helps our work and of cource I would like to post it for your progresses. Best regards, --- Tomoya <http://www.accverinos.jp/english/english.html>Article: 92452
g.wall napisał(a): > im trying to reverse engineer a windows driver > for a PCI fpga development board so i can use it on a linux machine > (write my own driver) > all i need are the command and control signals > in order to configure, do dma, reset, etc... > i need to capture these things as they are being sent from > the windows kernel to the PCI bus, then to the pci bridge on the board. > > anyone have any ideas? If You have PCI board with FPGA, RAM and some inferface to second PC, it would be easier to do it in hardware. Best Regards Krzysztof PrzednowekArticle: 92453
"Frank" <Francis.invalid@hotmail.com> wrote in message news:438bd5a3$1@news.starhub.net.sg... > I am injecting the DAC output from TI DAC290x-EVM to ADC (Analog AD9218). > When I connect I channel from DAC to I & Q channel of ADC, I am seeing > vastly > different digital outputs on ADC (sampling three pins on oscilloscope). What > might > be the cause? > > > When using logic analyzer to sample ADC outputs, i am getting strange outputs. Right channel, bit 9,8,7,6 stick to 1, bit 0 stick to zero, while bits 5,4,3,2,1 varies during active, while sticking to 1 during idle mode. Left channel, bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle mode, bit 8,6,3,2 switches during active, stick to 0 during idle (I expect 9:2 of both channel to behave in this manner), bit 1:0 are switching during idle and active (noise during idle mode). I double checked my settings, but found nothing wrong. How can I proceed now?Article: 92454
"Frank" <Francis.invalid@hotmail.com> wrote in message news:438d4a78$1@news.starhub.net.sg... > When using logic analyzer to sample ADC outputs, i am getting strange > outputs. > > Right channel, > bit 9,8,7,6 stick to 1, bit 0 stick to zero, while bits 5,4,3,2,1 varies > during active, while sticking to > 1 during idle mode. > > Left channel, > bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle mode, > bit 8,6,3,2 switches during > active, stick to 0 during idle (I expect 9:2 of both channel to behave in > this manner), bit 1:0 are > switching during idle and active (noise during idle mode). Do you use any bus control signal (RD in combination with CE for the ADC for example) to trigger the logic analyser? If not, you are just measuring all bus activity, not just the output from the ADC. MeindertArticle: 92455
"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message news:11oqj75td1vni04@corp.supernews.com... > "Frank" <Francis.invalid@hotmail.com> wrote in message > news:438d4a78$1@news.starhub.net.sg... > > When using logic analyzer to sample ADC outputs, i am getting strange > > outputs. > > > > Right channel, > > bit 9,8,7,6 stick to 1, bit 0 stick to zero, while bits 5,4,3,2,1 varies > > during active, while sticking to > > 1 during idle mode. > > > > Left channel, > > bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle > mode, > > bit 8,6,3,2 switches during > > active, stick to 0 during idle (I expect 9:2 of both channel to behave in > > this manner), bit 1:0 are > > switching during idle and active (noise during idle mode). > > Do you use any bus control signal (RD in combination with CE for the ADC for > example) to trigger the logic analyser? If not, you are just measuring all > bus activity, not just the output from the ADC. > > Meindert > > In my digital side, I have a PHY_EN pin which is high when the digital circuit repetitively sends out same data, and the digital circuits work for 30us and idle for 10us. On logic analyzer, I set the LA to start filling in the internal memory (256K) once PHY_EN is high, thus I can capture 20 repetitions. I am sure the data capture is correct.Article: 92456
>I suppose I'll have to do my own bus handshake implementation from the >Q-bus docs (I think my processor or peripheral handbook that came with >the 11/03 has one in there somewhere). Does it have the specs for the bus transcievers? I remember using some special DEC chip. >I wonder how hard it would be to get a PCB fabbed with the bus edge >connector? Needs gold fingers. They are big relative to modern connectors. I don't know if thats good or bad - easier to make but takes more gold. Anybody know where to get boards with gold fingers at hobbyist prices? I keep scheming about making a few PCI cards. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 92457
>If I connect the writing system to this async falling edge signal >directly what would be the problem? An "again availabe fifo" possible >would be detected one clock earlier but this shouldn't be a problem, >because the effect (falling edge of FULL) is still behind the cause >(read pointer was increased). Where is my error? It's an asynchronous signal going into your state machine. All the classic things can go wrong. The complicated one is metastability. The simple one is that it meets setup for some parts of your FSM but not for others. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 92458
Hi Olaf,
shame on me.
I have synthesized, but not simulated my source.
A simple change of my code like this:
total_sum <= ('0' & a)-('0' & b);
would do the trick and give you a 17 bit result. Wether you call the MSB
carry out or not depends on you, but it's no longer ignored.
Of course the use of the resize function, like Andy Peters showed us, is
to prefer, for its a more general solution.
diff := resize(x, diff'length) - resize(lower_bound, diff'length);
So,
have a nice synthesis (after simulation) :-)
Eilert
Article: 92459"Hal Murray" <hmurray@suespammers.org> wrote in message news:vaadnSJVHo9ezBDeRVn-hQ@megapath.net... > >>I suppose I'll have to do my own bus handshake implementation from the >>Q-bus docs (I think my processor or peripheral handbook that came with >>the 11/03 has one in there somewhere). > > Does it have the specs for the bus transcievers? I remember using > some special DEC chip. DEC did make some interface IC's for Qbus ... but *IF* I remember right... these were easily replaced with standard TTL logic. > > >>I wonder how hard it would be to get a PCB fabbed with the bus edge >>connector? > > Needs gold fingers. They are big relative to modern connectors. > I don't know if thats good or bad - easier to make but takes more gold. > > Anybody know where to get boards with gold fingers at hobbyist prices? > I keep scheming about making a few PCI cards. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or > unsolicited > commercial e-mail to my suespammers.org address or any of my other > addresses. > These are my opinions, not necessarily my employer's. I hate spam. >Article: 92460
Depends what side of the coin you come from when you consider how "powerful" the tools are... Sure you can't use OP in Hardware... but software is getting to be bloatware... that's easy in software as the average PC has a ton of ram to play with.. in real hardware .. as in not RAMS (which are symmetrical and enjoy one transistor, one capacitor per element) there is a real cost per transistor.. and .. although its a stone axe... it hits very often, very fast and always on target :-) Simon <fjh-mailbox-38@galois.com> wrote in message news:1133267892.868934.258910@f14g2000cwb.googlegroups.com... > Bob Perlman wrote: > >Fergus Henderson wrote: > >>Mike Treseler writes: > >>> Problem 1. > >>> There are ten times as many software designers > >>> as digital hardware designers. > >>Solution 1: > >>Develop high-level languages for hardware design. Make these similar > >>enough to existing software development practices that developers only > >>need a general understanding of hardware optimization techniques (e.g. > >>pipelining, resource sharing, etc.), available hardware resources (e.g. > >>LUTs > >>and BlockRAMs), and how high-level language constructs map onto those > >>hardware resources. Then one hardware engineer can easily train up 10 > >>software engineers to the level of hardware knowledge that they need in > >>order > >>to be able to productively develop efficient hardware using a > >>high-level language. > > > >Would it be possible to do just the opposite, and create a high-level > >language that lets a digital designer write efficient, > >high-performance software the same way he'd design hardware? Because > >I'd like to become an expert programmer without expending much effort. > > I'm not suggesting that becoming an expert hardware designer isn't > going to take effort. But currently popular hardware design tools are > in the stone age in comparison to software design tools. The amount of > effort required to implement even very simple functionality in > synthesizable VHDL/Verilog is huge -- much higher than the effort > required to implement the same functionality in software. > > Becoming an expert warrior certainly takes effort, regardless of > whether your weapon of choice is a sharpened stone axe or an AK47. But > that's not a good reason to stick with stone axes. > > -- > Fergus J. Henderson "I have always known that the pursuit > Galois Connections, Inc. of excellence is a lethal habit" > Phone: +1 503 626 6616 -- the last words of T. S. Garp. >Article: 92461
"Frank" <Francis.invalid@hotmail.com> wrote in message news:438d4f5d$1@news.starhub.net.sg... > In my digital side, I have a PHY_EN pin which is high when the digital > circuit repetitively sends > out same data, and the digital circuits work for 30us and idle for 10us. On > logic analyzer, I set > the LA to start filling in the internal memory (256K) once PHY_EN is high, > thus I can capture > 20 repetitions. I am sure the data capture is correct. And I am not. this PHY_EN signal, what does it drive on the processor? I can imagine that it just signals the processor data is available and that consequently, the processor issues bus cycles (set an address or CE, activate RD, read data, deactivate Rd and CE) to read the data. This means that data on the bus during this 30us is not data from the ADC all the time. Only when the ADC is read during the bus read cycle, valid ADC data is readable on the bus. MeindertArticle: 92462
g.wall wrote: > has anyone used this board, what do you think of it? > does anyone have a linux driver for it? > a schematic? > > thanks According to the Nallatech site http://www.nallatech.com/?node_id=1.2.2&id=28&sub=1 This board has Linux drivers available. Cheers PeteSArticle: 92463
Watch out for "feature creep" also, i.e. requirements / specifications changing as you're going along. How you handle that will probably be make or break for your project. It's a very difficult tightrope between frustrating the people who are waiting on your chip (regardless of whether it's customer specific or mass market) by playing hardball with a formal change request procedure, or frustrating your team by agreeing to spec' changes without agreeing schedule impacts arising from those changes. Doing project management can be very challenging, keeping all those plates spinning in the air at the same time, but it's very rewarding when you hand over the development at the end. Don't take it personally if the development gets canned, it happens a lot in our industry. I've never seen a bad project manager be the root cause of a cancellation, it's usually external like missing a market opportunity or whatever. In which case you can pin it on your product marketing people (or your top-management, or your end customers) for being too far behind the crest of the wave. Last word, but in my personal experience I think women make better project managers, as they're naturally gifted multi-taskers, and usually have better sift skills than typical male engineers. Not always, but on average. AlanArticle: 92464
Hal Murray wrote: > >No matter what, if you track the actual schedule against your original > >estimate you can at least have an estimate of when you'll actually be > >done. Not only can you use this estimate to motivate the troops, but > >you can use it to warn your boss that things aren't going as fast as > >expected. > > How well does that work? > > I'd expect it would give horrible results in two common cases. > (Maybe just looking at the same thing two different ways.) > > One is the one-last-bug problem. All the module tests go great > but then it doesn't work when you put it together. This is a common issue to all of us, and due to poor specifications. Engineers (and management) hate the time to put down a thorough specification 'because we could be actually implementing something', but when modules don't work together because they did *not* do a thorough spec, it takes longer and is far more frustrating, to say nothing of being hazardous to your current employment position. One of my cardinal rules of project management is --Have a thorough specification of the task--. Thorough spec: Any three of your engineers can read it and **will all get the same result**. If three different engineers read that spec and do not agree on what it means, it is not a properly written spec. > > The other is that halfway through a project, the nature of the > work changes. You shift from writing code to integrating/checking. > Knowledge of how well things worked during the first mode doesn't > tell you anything about how good your estimates for the second mode > will be. > True enough. I usually allow a fair amount of time (depending on who, what etc) for 'mode changes' Product definition Spec writing module implementation Integration testing Each of those is a major section and should have some time between them for the team to 'change focus'. Your projects may have more stages for good reasons. I have found this is the minimum for my projects, so far. > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam. Cheers PeteSArticle: 92465
Peter Alfke wrote: > After some thinking: > 1. > You can divide the input load by using "zero-delay buffer chips" with > up to 8 outputs and very little skew betrween them. And you can even > compensate for the (assumed constant) skew between the outputs.(see > below) > 2. > You can drive all IDELAYs from the fabric, using internal fan-out. > Again, you an compensate away the routing delay differences. > > The compensation is done by setting all IDELAY values be to the same, > and then observing the parallel captured word. It should always be > either all zeros or all ones. If it's different, change the responsible > IDELAY accordingly. > > Obviously, this compensation deos not cover drift with temperature and > Vcc. > > Peter Alfke, Xilinx Applications Hi, Is this two different approaches or two steps of one process? For 2) above, I connected the input pin to 16 IDELAY blocks but got this error: FATAL_ERROR:Pack:pktv4iob.c:737:1.24.2.1 - Input buffer CH1_IBUF drives multiple DELAYCHAIN symbols. The implementation tools can not pack the design. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com How can I fan out the one input without getting this!! Thanks AlArticle: 92466
"al99999" <alastairlynch@gmail.com> schrieb im Newsbeitrag news:1133348095.999307.101310@o13g2000cwo.googlegroups.com... > > Peter Alfke wrote: >> After some thinking: >> 1. >> You can divide the input load by using "zero-delay buffer chips" with >> up to 8 outputs and very little skew betrween them. And you can even >> compensate for the (assumed constant) skew between the outputs.(see >> below) >> 2. >> You can drive all IDELAYs from the fabric, using internal fan-out. >> Again, you an compensate away the routing delay differences. >> >> The compensation is done by setting all IDELAY values be to the same, >> and then observing the parallel captured word. It should always be >> either all zeros or all ones. If it's different, change the responsible >> IDELAY accordingly. >> >> Obviously, this compensation deos not cover drift with temperature and >> Vcc. >> >> Peter Alfke, Xilinx Applications > > Hi, > > Is this two different approaches or two steps of one process? For 2) > above, I connected the input pin to 16 IDELAY blocks but got this > error: > > FATAL_ERROR:Pack:pktv4iob.c:737:1.24.2.1 - Input buffer CH1_IBUF drives > multiple > DELAYCHAIN symbols. The implementation tools can not pack the > design. > Process will terminate. To resolve this error, please consult the > Answers > Database and other online resources at http://support.xilinx.com. If > you need > further assistance, please open a Webcase by clicking on the > "WebCase" link > at http://support.xilinx.com > > How can I fan out the one input without getting this!! > > Thanks > > Al > Hi Al, I think Peter did suggest the impossible, there is no connections in the FPGA that would allow single signal to be routed to multiply IDELAY elements. The only possibility would be to use unbonded IOBs as route through, but I have not found an option that allows the use of unbonded IOBs in user design :( AnttiArticle: 92467
Hi, I just succesfully installed ISE BaseX on Linux. All is OK. BUT the ISE simulator is not present in the list of available simulators in project properties. Please help! Cheers Mehdi.Article: 92468
Simon Peacock wrote: > Depends what side of the coin you come from when you consider how "powerful" > the tools are... > Sure you can't use OP in Hardware... but software is getting to be > bloatware... that's easy in software as the average PC has a ton of ram to > play with.. in real hardware .. as in not RAMS (which are symmetrical and > enjoy one transistor, one capacitor per element) there is a real cost per > transistor.. and .. although its a stone axe... it hits very often, very > fast and always on target :-) > > Simon > Software as bloat [well, non-optimised] (which covers a lot of ground nowadays) has in fact been justified by people such as Eric Raymond with the rationale that processor cycles and memory is cheap and getting cheaper. The issue in hardware (well, reasonably fast hardware) is bloat, by definition, is a bad thing[tm]. Taking a fairly standard for instance, let's implement a simple memory interface, but with a wrinkle; the bus has a *minimum* speed (such as DDR). Now you can't just run it a little slower - the memory devices *won't work*. For such an application, a thorough knowledge of the interface (and the chips on the other side of the design) is a pre-requisite. It's no good saying do this, then that. Earlier in the thread, I noticed some compilers automatically register everything. The problem there is now we get resource utilisation problems and we *can't route* and meet our timing criteria. So, before we get to the 'advanced type of tools such as software has', we must first make them efficient and non-bloating. Just my $0.02 Cheers PetesArticle: 92469
"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:dki76s$cb1$1@online.de... > Why Spartan-3e is the best > ================== > Antti Lukats > 4.Nov 2005 > > [lot's of indispensable 3e advantages snipped] > > 6) There are possible some other nice new features > I have not discovered yet :) Yes, you forgot to mention the extra fun you may have with the DCM / DFS >90MHz && <220MHz. Raymund HofmannArticle: 92470
Hi every one, It seems that implementation of DSP algorithm In simulink is possible not only for TI DSPs but also XILINX FPGAs. I intend to implement a baseband 64 QAM modem with MATLAB/SIMULINK. It should be added that the bandwidth of afforementioned modem is 8 KHz and about 64 Kbps. It wuold be highly appreciated if some one informe me about the pros and cons of the two mentioned solutions. Best Regards. AlirezaArticle: 92471
damir escreveu: > "Ricardo" <spamgoeshere1978@yahoo.com> wrote in message > news:3v3qjgF137kthU1@individual.net... > >>damir escreveu: >> >>>We have developed data acquisition system which uses Cypress FX2 as the >>>USB 2.0 interface. State machine for control and conversion of data >>>between AD converters and FX2 is implemented using Xilinx Spartan 2 FPGA. >>>The problem is that with higher data rates (up to 25 Mbit/s) we >>>experience FX2 internal FIFO stalls and missing data on the receiving >>>side. Small FIFO implemented inside FPGA does not help to resolve the >>>problem. On the PC, data acquisition is implemented using CyAPI & CyUSB. >>>USB bulk mode is used for transfer. >>> >>>As mentioned data rate is only a fraction of USB 2.0 bandwidth, I don't >>>know if the mentioned problem is related to the implementation of the >>>receiver side (CyAPI) or lacking capability to sustain such bandwidth >>>within Cypress FX2. >>> >>>Did anyone have similar problems using FX2 and how you manage to solve >>>it? >>> >>>I will appreciate any help to resolve this problem, if possible in >>>software - hardware solution will require redesign of the PCB and >>>implementation/addition of large size FIFO to buffer FX2 stalls (which >>>may, according to our experience, extend up to 50 ms). >>> >>>Thanks, >>> >>>Damir >>> >>> >>> >> >>I use the SX2 and could get around 25Mbit/s of sustained transfer in bulk >>mode, but remember that bulk transfers have absolutely no time guaranty. >>Even interrupt and isochronous that should have timeliness have a >>disclaimer in the USB specification that real timeliness is dependant upon >>SO. Windows and Linux can take a very long time without giving the >>processor to any specific task. I did no test at all regarding latency in >>this case. Depending on how critical is the data, you may need over 1s of >>buffering. Using drivers in windows i've seen sub-ms response times, but >>there's no way to be sure it will allways be so. I think the Cypress >>driver is quite slow also. In the test I achieved 25mBit/s the FPGA >>driving the SX2 could deliver over 120Mbit/s to the SX2, which sould be >>capable of even more.... >> >>Ricardo > > Is there any alternative to Cypress driver available in the source, or I'll > have to go and write driver (WinXP) by myself :(((( I've done some windows > drivers several years ago and I don't like it at all. > > Damir > Talking to the software guy here, USB drivers are the most documented one in DDK's. But, as the Cypress drivers achieves what we need right now, we're no looking anywhere else now. RicardoArticle: 92472
"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message news:11oqpeup6ur1k50@corp.supernews.com... > "Frank" <Francis.invalid@hotmail.com> wrote in message > news:438d4f5d$1@news.starhub.net.sg... >> In my digital side, I have a PHY_EN pin which is high when the digital >> circuit repetitively sends >> out same data, and the digital circuits work for 30us and idle for 10us. > On >> logic analyzer, I set >> the LA to start filling in the internal memory (256K) once PHY_EN is >> high, >> thus I can capture >> 20 repetitions. I am sure the data capture is correct. > > And I am not. this PHY_EN signal, what does it drive on the processor? > I can imagine that it just signals the processor data is available and > that > consequently, the processor issues bus cycles (set an address or CE, > activate RD, read data, deactivate Rd and CE) to read the data. This means > that data on the bus during this 30us is not data from the ADC all the > time. > Only when the ADC is read during the bus read cycle, valid ADC data is > readable on the bus. > > Meindert > > Ah! I understand what you mean now. PHY_EN is a stable signal, while my clock period is 25ns, in each frame, digital side is sending some 1200 I/Q samples, one pair of samples each cycle and unchanged throughout the clock cycle. From the datasheet of ADC, I don't see there is any Rd or CD signal, it's as plain as ADC outputs are hold stable and change every 25ns. After all is done, I think I had better flag a "faulty ADC board" message to the up layer. since even when I disconnect ADC input, many of the pins mentioned below still to high level, sampled by a logic analyzer's 400MHz clock. Left channel, bit 7,5 stick to 0, bit 9,4 switches during active, stick to 1 in idle mode, bit 8,6,3,2 switches during active, stick to 0 during idle (I expect 9:2 of both channel to behave in this manner), bit 1:0 are switching during idle and active (noise during idle mode).Article: 92473
GaLaKtIkUs=99 wrote: > Hi, > I just succesfully installed ISE BaseX on Linux. All is OK. > BUT the ISE simulator is not present in the list of available > simulators in project properties. > Please help! > > Cheers > Mehdi. The ISE 7 Feature Guide document http://www.xilinx.com/ise/devsys_feature_guide.pdf says that Modelsim is "Sold as an Option." Contact your Xilinx distributor. Or you can buy a real copy from here: http://www.model.com/ Regards, AllanArticle: 92474
<allanherriman@hotmail.com> schrieb im Newsbeitrag news:1133357961.011069.169040@g44g2000cwa.googlegroups.com... GaLaKtIkUsT wrote: > Hi, > I just succesfully installed ISE BaseX on Linux. All is OK. > BUT the ISE simulator is not present in the list of available > simulators in project properties. > Please help! > > Cheers > Mehdi. The ISE 7 Feature Guide document http://www.xilinx.com/ise/devsys_feature_guide.pdf says that Modelsim is "Sold as an Option." Contact your Xilinx distributor. Or you can buy a real copy from here: http://www.model.com/ Regards, Allan -------------- The OP asked about the ISE built in simulator not about modelsim! ISE Simulator possible only supported on windows version (in 7.1). Antti
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z