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
Antti wrote: > Xilinx webshop related again > > I am ready to immediatly order ML501, but unfortunatly Xilinx website > has only documentation and reference design, and no product code, > neither it is available in Xilinx online shop, and search at Avnet > yields at zero results also. > > surprisingly it is listed as orderable here > > http://hitechglobal.com/catalog/product_info.php? > products_id=136&osCsid=f67b9795ed80136c7aef4e96006bca95 > > at price 1195USD > > I wonder why isnt ML501 orderable from Xilinx or Avnet, or if it is how > to place an order e.g. I need at least a product code - I would really > really rather order from Xilinx online shop or Avnet then from > somewhere else. Antti, We had a too many items going through a release queue that overloaded the logistics team and the ML501 release was delayed slightly. It is now available for sale, but because it is a new product not everyone in the Xilinx Sales Rep and Distributor companies may know this off the top of their head. Tell them you want to order a HW-V5-ML501-UNI-G board and they should take your order, if they don't please let me know. The boards will ship from the US so it may take a couple of weeks to get through to you. We do have plenty of these in inventory right now with more in the production pipeline. The extra codes at the end indicate that the power supply is universal (-UNI) and the board is RoHS compliant (-G). Ed McGettigan -- Xilinx Inc.Article: 109526
I looked at your Stanford page, what project is this going to be used for? You said that the results will be open sourced, are there any parts of your past projects open? ---Matthew Hicks "Greg Watson" <gwatson@stanford.edu> wrote in message news:efecqi$1m8$1@news.Stanford.EDU... > Hi > > We are planning to use MIG to generate a DDR2 interface for a V2Pro30 > design, but I'd like to know if anyone has done this successfully already? > The MIG tool doesn't seem to have the quality level of other Xilinx tools > and that makes me a bit nervous for something as timing critical as a DDR2 > controller. > > We are using MIG 007 Rel 6 (as it's the recommended version for V2P). So > far the only irritations we have encountered is that it forces the use of > specific DCMs and requires the user to reselect every option each time it > is invoked (no saving of current design). > > We plan to run 1 32 bit controller at 200MHz (400 Mb/s/pin) with Micron > MT47H16M16. > > We would like to hear of any experiences with MIG and DDR2 and V2P, if > only to convince us that this is doable. Our final design should be open > sourced and available to all, if that encourages you to be open about your > experiences. > > If you would rather contact me directly I am at gwatson@stanford.edu > > Thanks > > Greg WatsonArticle: 109527
jjlindula@hotmail.com wrote: > Are these tools useful for > high-speed applications? If anyone can comment on these tools I'd > greatly appreciate it. High speed applications don't necessarily require a high-speed MCU. Granted, the NIOS isn't as fast as dedicated MCUs but there are other benefits when you don't require processor grunt: 1. Lower chip, pin count 2. Integration. As many or as few peripherals can be integrated into the MCU as required - all done in 'software'. 3. Customisation. Custom instructions can be added to the MCU for application-specific performance enhancement. 4. Integrated development tools. 5. Flexibility. Useful during proof-of-concept or R&D phases. Can also be used to support families of products with different feature sets. FWIW we have implemented the NIOS in 2 commercial products for a customer so far. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 109528
waishanl@gmail.com wrote: > Hi! i am having problem to communicate between virtex4 fx60 to 512 > SODIMM. I use the MIG1.6 to generate a controller. I add one module > into the design, change some names and run ModelSim. The simulation > looks fine. So, i use the ICE tools to get my bit file. When i check > all the report, I saw the map report have the follwoing message: > > WARNING:MapLib:851 - Your design is using FIFO16 primitives, Please > note that > there are additional requirements for the FIFO16 to guarantee full > functionality. For more information regarding requirements for the > FIFO16 > primitive, please see Answer Record 22462. > > is that going to cause me fail on the design? I didn't fine any .edn or > ngc file in the folder that MIG generate. > > I also run the time simulation, it didn't match with the funcational > simulation. Seems like signal start fail in 200ns. Am i missing > anything? > > In addition, I chipscope the signal. It seems like data did get in the > fifo. But the controller never request a read. Any ideas? There has been quite a bit written lately about DDR2 and MIG in this newsgroup. Search for ddr2 and MIG. I recommend replacing the FIFO16s with FIFOs generated by CoreGen that don't use the FIFO16 primitive. I had problems with the address/command FIFO. It would be empty, but still indicate that it had data, so the same memory cycle would run forever. --- Joe Samson Pixel VelocityArticle: 109529
Hi All, The EC/ECP EBR (or Block RAM) can be configured in the following modes (as supported in the hardware): - Single Port RAM (RAM_DQ) - Dual Port RAM (RAM_DP) - True Dual Port RAM (RAM_DP_TRUE) - Read Only Memory (ROM) The EBR block does not have a native hardware support for the FIFO. The way FIFO is created for the EC/ECP devices is by utilizing a Dual port RAM (RAM_DP) and then adding the address counters and the flag logic. The IP Express tool in ispLEVER is fully capable of creating both a single clock FIFO and a Dual Clock FIFO (FIFO_DC). It is emulated FIFO that utilizes RAM_DP underneath. Besides using the IP Express tool, another way to implement RAMs in the EC/ECP devices is by inferencing them i.e. you write a behavioral VHDL or Verilog code for the memory style and the synthesis tool automatically implements the RAM. By default, ispLEVER uses the following criteria: + If the inferenced memory is smaller than 2K bits, use the PFU's (or slices) and implement a Distributed RAM (Single, Dual or True Dual Port) or ROM. + If the inferenced memory is larger than 2K bits, use the Block RAM and implement an EBR based RAM (Single, Dual or True Dual Port RAM) or ROM. The attribute that is being discussed and questioned in this thread is the Synplify attribute "syn_ramstyle". This attribute comes in handy when you are inferencing a memory and you want to force the synthesis to implement it using either the EBR blocks or the Slices. Now, the FIFO in the Ben Cohen's book. It is a FIFO infrencing example. And since there is no FIFO support in the hardware, the software implements it as logic and not RAM, since it can not be mapped to the four RAM modes listed above. And thus uses the slices to implement the FIFO making the attribute "syn_ramstyle" ineffective. This would happen in both EC/ ECP/ XP families from Lattice as the FIFO is emulated in these devices. I hope this clarifies why the attribute is not working. Regards JP SinghArticle: 109530
Hi, I have two problems about the FPGA implementation after I finished my design with Xilinx block set in Matlab. 1. What is the relationship between the FPGA clock and the sampling rate which I set up in System Generator when I simulate the system in Matlab? 2. When I implement the system in simulink in Matlab, some blocks may have different sampling rate such as one third the input data rate. So how can I achieve this sampling rate ratio in FPGA? Or the FPGA can fullfill that ratio automatically? Hope someone could give me some ideas. Thank you very much!Article: 109531
So let me get this straight, Alexandre: If I understand you correctly, you want to take somebody else's idea and publish it as your own? Perhaps I misunderstood your intention, in which case you are putting the cart before the horse; the paper is the last thing to be done after you've put in the research or made the discovery to have something of merit to contribute to the community. The paper is just a vehicle to deliver the results of your work to the community at large so that others can build on your work. There are plenty of areas ripe for research in FPGA related topics, but simply having a goal of publishing a paper without having something of merit first is not helpful. In fact, speaking as a conference paper reviewer, the last thing we need is more papers with nothing new to offer. We have to review every paper that is submitted, and there are already plenty of papers submitted that amount to little more than a regurgitation of somebody else's work with no significant new contribution. While those papers seldom get published, they still have to be reviewed and are a waste of the conference committee's time as well as yours.Article: 109532
I need help on how to use the EDK DDR memory controller in ISE to write to/from ram and fpga directly. I have implemented the FFT provided by Xilinx Coregen but need a faster memory controller to streamline the FFT process rather than the EDK-PowerPC DDR controller in C that is provided. Any help is appreciated. Thanks AshwinArticle: 109533
Dear ray@andraka.com Let me clarify you one point: Well, i am conscious of the usefulness and characteristics of the paper and its publishing! If you are unable to offer some help, so please dont bother to reply! Ray Andraka wrote: > So let me get this straight, Alexandre: If I understand you correctly, > you want to take somebody else's idea and publish it as your own? > > Perhaps I misunderstood your intention, in which case you are putting > the cart before the horse; the paper is the last thing to be done after > you've put in the research or made the discovery to have something of > merit to contribute to the community. The paper is just a vehicle to > deliver the results of your work to the community at large so that > others can build on your work. > > There are plenty of areas ripe for research in FPGA related topics, but > simply having a goal of publishing a paper without having something of > merit first is not helpful. In fact, speaking as a conference paper > reviewer, the last thing we need is more papers with nothing new to > offer. We have to review every paper that is submitted, and there are > already plenty of papers submitted that amount to little more than a > regurgitation of somebody else's work with no significant new > contribution. While those papers seldom get published, they still have > to be reviewed and are a waste of the conference committee's time as > well as yours.Article: 109534
hi thanks. i did take a look into those pdf's and i initialized the raw api mode according to the example in this pdf. but it didn't work. can't i use raw api mode with xilkernel and use the function "sys_thread_new()" ?Article: 109535
Hello again expert, I am not clear about one thing and this is making me confused. I have read documents but could not find what is meant by term 'images' in open cores PCI core for example when he says that PCI bridge can have 6 wishbone images, 6 targets images etc etc. What is exactly meant by this. Please explaing this term to me. thanks in advance, regards, AdnanArticle: 109536
Ed McGettigan schrieb: > Antti wrote: > > Xilinx webshop related again > > > > I am ready to immediatly order ML501, but unfortunatly Xilinx website > > has only documentation and reference design, and no product code, > > neither it is available in Xilinx online shop, and search at Avnet > > yields at zero results also. > > > > surprisingly it is listed as orderable here > > > > http://hitechglobal.com/catalog/product_info.php? > > products_id=136&osCsid=f67b9795ed80136c7aef4e96006bca95 > > > > at price 1195USD > > > > I wonder why isnt ML501 orderable from Xilinx or Avnet, or if it is how > > to place an order e.g. I need at least a product code - I would really > > really rather order from Xilinx online shop or Avnet then from > > somewhere else. > > Antti, > > We had a too many items going through a release queue that overloaded > the logistics team and the ML501 release was delayed slightly. It is > now available for sale, but because it is a new product not everyone > in the Xilinx Sales Rep and Distributor companies may know this off the > top of their head. > > Tell them you want to order a HW-V5-ML501-UNI-G board and they should > take your order, if they don't please let me know. The boards will > ship from the US so it may take a couple of weeks to get through to > you. We do have plenty of these in inventory right now with more in > the production pipeline. > > The extra codes at the end indicate that the power supply is universal > (-UNI) and the board is RoHS compliant (-G). > > Ed McGettigan > -- > Xilinx Inc. Thank Ed, the order number is in purchasing dep. should Avnet refuse to take the order I will let you know. AnttiArticle: 109537
Thank you for the answer. I discussed with many people about this feature, and all of them confirmed to me that there isn't a straight way to do what I'd like to do. The only solution I've found is to use the Node Finder, typing the name of the module I want to find (remembering to always put aterisks before and after the module name, otherwise the search will fail), selecting "Design Entry (all names)" as filter and performing a search in the top-level module enabling the "Include subentities" option. A bit tricky, but it works... By the way, I hope that Altera will include a direct option like "List all instances of the selected module in the design", it could be really useful with large designs. Regards, Claudio alterauser wrote: > I think I know, what you mean. Qaurtus shows the instances in the > h-tab, but when clicking on it, Q jumps to the module. I do it that > way, that I use cut&paste to copy the name of the module, jump to the > former folder (upper level) and do a search for. > > Another possibilty is to click on the item and chooes "Locate in design"Article: 109538
hi thanks for the answer. i did look at those pdfs and initialised the raw mode according to the manual. still the sys_thread_new function dosen't work. can't i use raw mode with the xilkernel?Article: 109539
Hi All, we are having troubles in simulating our design with QuartusII. We found that the QuartusII simulator is dramatically slow since every time we must perform the whole compilation procedure before simulating, even if we'd like to perform a functional (not timing) simulation; so we are now trying to use Modelsim. We set the QuartusII to launch Modelsim (through the NativeLink feature); by the way, compilation seems to be necessary in any case, and the problem is that Quartus, while optimizing the design, eliminates some signals that instead could be useful to simulation. We tried to create a project from scratch with Modelsim and include all our source files, in order to simulate the whole design without starting the Quartus environment, but since we are using schematics and Altera MegaFunction blocks (LMP_RAM_DP, PLLs, etc.) it turned out to be a bit complicated to set up the Modelsim project and keep it up-to-date with the Quartus project. Have you encounted the same problems with Modelsim+Quartus? Can anyone suggest us a better way of proceeding? Referring to our experience, from the Xilinx ISE we were able to launch the Modelsim simulation very easily, and we could also simulate separately each single module of a design... Thank you in advance.Article: 109540
Hi everybody, I started to develop my fir filter with Quartus and Nios II dev board, with an Altera Stratix II EP2S60ES. The problems are starting now, when I'm loading the .soc file on the FPGA. I put the "other pin's tree-state" option (so MAX processor doesn't reload factory config), but the project doesn't work. I think there are some problems on pin assignments, but I followed the pin tables found on 'Nios II dev Reference Manual (May 2006)'. The board is old, about end of 2004... Is this the problem in your opinion? Can you tell me where I could find old specifications (here I haven't original documentation) on the internet (I haven't found in altera site...)? Or can I missing some important step? (like tree-state buffer for unused pins that isn't showed clearly in documentation). I don't use Nios processor, I need only FPGA for a fir filter using Quartus II. Any suggestions are welcome! :) Thank you very much DarioArticle: 109541
Hi,
maybe this is a stupid question, but is there any chance to absorb the
cpld logic into the FPGA?
this will move your interface inside and make your life easier.
Aurash
Dolphin wrote:
>Hello,
>
>In my future design I could win a lot of pins if I could drive a bus at
>160MHz. Because of bank restrictions and because this bus is connected
>to a CPLD, I will have to use LVTTL.
>Has anybody tried driving a bus in LVTTL at 160MHz?
>
>I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has
>LVDS CPLDs but only the large CPLDs support LVDS inputs.
>
>I am afraid that this bus will have a lot of EMI/EMC problems. What do
>you think of it, should series termination be adequate to limit the
>EMI/EMC problems?
>
>best regards,
>Dolphin
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 109542
<jjlindula@hotmail.com> wrote in message
news:1159383143.067882.307120@k70g2000cwa.googlegroups.com...
> Hello, I've been seeing more training at Altera concerning their SOPC
> Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
> these tools are gaining acceptance in the engineering world? A
> co-worker used the Nios processor a few years ago and said that it was
> slow so they didn't use it in their project. Are these tools useful for
> high-speed applications? If anyone can comment on these tools I'd
> greatly appreciate it.
On the SOPC Builder side of things I can flatly state that the tool itself
is very poor for anything other than the most minimal of 'programmable
systems on a chip'. That being said, it can be a good tool if your design
does fit into that 'minimal' definition. Specific area where it is not very
good are:
- GUI. Once you have 'too many' components, the GUI is nearly impossibly
slow to work with.
- Build time. Again once you have 'too many' components and even just by
making innocious changes to the .PTF file the build time can sky rocket out
to over a day and sometimes never complete ('never' meaning I waited more
than a day than gave up). 'Normal' build times should take minutes.
- Miserable error reporting. When SOPC Builder fails for whatever reason,
there is typically no message or log file with any information regarding
what it didn't like, just the command line that it invoked that caused the
error.
- Components that you design can't pass generics other than std_logic or
integers through the tool chain using the 'Component Editor'. I tend to
like to pass 'time' types for those cases where the underlying widget needs
to know how much time elapses per clock cycle because it needs to do
something every so much time, or wait a certain amount of time for something
etc.
- Quality of results. Where to begin?
- Multi-mastering logic to a shared resource performance drops rapidly
(like after ~3-4 masters). SOPC Builder has no controls for improving it so
you'll have to do it yourself.
- Multi-slave read side logic back to a master drops (but not nearly as
quickly as with the multiple masters). SOPC Builder has no controls for
improving it so you'll have to do it yourself.
- Even after making the above two design changes and implementing them
into the SOPC Builder flow I was only able to get the design from ~45 MHz up
to ~75 MHz. That's a big improvement but I needed to get to over ~110 MHz.
So I gutted the last remaining code that SOPC Builder generates and wrote it
myself and was able to get up to 133 MHz without any trouble.
I should note also that my completely gutting and not using any of the SOPC
Builder generated code I did not take advantage of any 'specific knowledge
of my particular design' when I rewrote that code. I simply coded it per
the Avalon specification itself. The end result was virtually identical
logic resource usage and ~3x speed improvement.....and code now that was in
no way limited to only being usable with Altera.
All of these were submitted to Altera support and I worked with the FAE on
this and as of Quartus 6.0 SP1 all of the above problems appear to still
exist. For a while Altera seemed to be willing to help but I submitted so
many bug reports that they ended up dropping my problems as not being
'important enough for them to work on' because most other users don't have
these types of problems. When pressed on what made my design 'out there'
the response was the size of the design. My design has a lot of interfaces
but darn near all of them were simple point to point connections connecting
components that implemented portions of a processing pipeline....not at all
a 'difficult' thing to do, but apparently it was too taxing for SOPC
Builder. The targetted part was a Stratix II EP2S60 so while I was in the
'big' family I was only using the mid-range part in that family. Prior to
using SOPC Builder (and even after on other bugs I discover) support
response from Altera has been good so it's not just 'me'....well, I hope
not.
Having said all THAT though, I can also say that the Avalon bus
specification itself is excellent and can recommend using it. Designing to
that specification does not in any way lock you into an Altera
implementation. It's only when using SOPC Builder to tie it together that
you've locked into Altera. Mainly for the above mentioned reasons though I
don't use SOPC Builder.
Another option is OpenCore's Wishbone but that specification is actually not
as good as Avalon in many ways. OpenCores seems to have a SOPC Builder like
tool to tie together the components but it too is limited in the number of
components that it can tie together. I haven't used it so I can't comment
on the quality of that tool.
As for NIOS, without some application in mind you can't really say whether
any processor is 'good' or 'bad'. There are several companies out there
developing NIOS related stuff (do some Googling) so somebody must be using
it. NIOS has all of the tool support and can run uCLinux so it would seem
to be OK for many apps. The custom instructions should allow you to speed
up the code sections that need it with real hardware which is pretty much
out of the question with most other processors. Bottom line is you have to
benchmark it yourself using code somewhat representative of what your major
areas of concern are.
KJ
Article: 109543Adnan wrote: > I am not clear about one thing and this is making me confused. I have > read documents but could not find what is meant by term 'images' in > open cores PCI core for example when he says that PCI bridge can have 6 > wishbone images, 6 targets images etc etc. What is exactly meant by > this. Please explaing this term to me. An 'image' is a memory or I/O space map. From the host perspective, they correspond to the PCI Base Address Registers (BARs) implemented in configuration space. There's plenty of information on these in the PCI literature. Conversely, you have the same concept from the wishbone perspective, although you've only got memory images, no I/O images. In this case the images only come into play when bus-mastering from the wishbone side. You've also got address translation for each of the images in either direction. This allows you to add a constant offset to each address generated on the master side as it appears on the target bus. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 109544
KJ wrote:
> - Build time. Again once you have 'too many' components and even just by
> making innocious changes to the .PTF file the build time can sky rocket out
> to over a day and sometimes never complete ('never' meaning I waited more
> than a day than gave up). 'Normal' build times should take minutes.
Heh, interesting. I had a design with a modest amount of components that
was generating in about 4-5 minutes. I used this design for several
weeks until the project was complete.
Not longer after, I inherited an existing design from a customer which I
was to extend. It had quite a few more components, but most of them were
empty shells or instantiations of the same component.
I hit generate and the system would 'hang'. I spent over a day trying to
find the problem - upgrading Quartus, upgrading NIOS, cloning the
customer's development environment, etc. Then I started a 'generate' and
got distracted doing something else. A few hours later I switched back
to SOPC Builder and to my complete surprise - the build had finished!
(I should add that the developer responsible for the project was by this
time on his honeymoon in Europe, so I couldn't ask anyone how long it
should take.)
Not knowing how long it took, I tried to generate again and it hung. But
I let it go and finally saw the process spit out more messages as it
continued the build. I was stunned with the seemingly exponential time
increase.
> - Miserable error reporting. When SOPC Builder fails for whatever reason,
> there is typically no message or log file with any information regarding
> what it didn't like, just the command line that it invoked that caused the
> error.
Yes, I've traced through perl and other scripts to find build problems...
> - Components that you design can't pass generics other than std_logic or
> integers through the tool chain using the 'Component Editor'.
I found that out the hard way too!
> For a while Altera seemed to be willing to help but I submitted so
> many bug reports that they ended up dropping my problems as not being
> 'important enough for them to work on' because most other users don't have
> these types of problems.
You found yourself in the 'too hard basket'! ;)
> Having said all THAT though, I can also say that the Avalon bus
> specification itself is excellent and can recommend using it.
Yes, and wishbone components wrap nicely in the component builder too.
One slightly tricky thing we did was implement a SHA1 hasher around the
opencores DMA engine, so that simply using DMA to read a block from,
say, Compact Flash, calculated the SHA1 hash value. That required some
gymnastics in SOPC builder - we had to write an Avalon 'pass-thru'
component whose memory space overlapped everything else so DMA addresses
required no translation from PIO addresses and also (by educated
guesswork) had to get the component ordering in the SOPC GUI just right
for it to work properly!
Regards,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Article: 109545
Hi Annti,
I would call PCIexpress everything but "small little thing"
Aurash
Antti wrote:
>Xilinx isnt advertizing 'small things' that are also coming as bonus
>with Virtex-5, I found one by accident while browsing the ML501
>reference designs and docu, namly
>
>* Virtex-5 has fully dedicated pins for the parallel flash so any NOR
>flash connected properly as configuration memory is also accessible by
>the dedicated pins for both read and writes. Those it is possible to
>use indirect nor flash programming for V5-connected nor flash, and
>surprise it is already offered by Xilinx! its hidden in the "LAB
>resources" for ML501 but the indirect programming software and
>bitstreams are available for all v5lx devices.
>
>* anothes small thing is the access to configuration clock oscillator
>after configuration from FPGA fabric (but that has already been told
>here)
>
>* not to mention that the SYSMON what is there in V4 (but disabled by
>the tools) is now finally user accessible
>
>* CRC32 and CRC64 as primitives
>
>* EFUSE primitive whats that !?
>
>* KEYCLEAR primitive !! Thanks you, Xilinx! this is for clearing the
>encryption key from the FPGA fabric - I was missing this feature badly,
>now its there !!
>
>* PCIE primitive ? I am not believing what I am seeing ?!
>
>* PMV is still there too
>
>* USR_ACCESS is enhanced as well
>
>I guess there are some more nice small things hidden - anyone found
>something?
>or was I just dreaming? too late maybe I'd better rest or who knows
>what else
>I would be seeing!
>
>Antti
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 109546I'm trying to understand what help you are seeking. So far, it appears that you are asking for a paper topic, which is not the way to go about it. Find a research topic that interests you, do the work and then if something noteworthy falls out of it, then and only then consider writing a paper. Going into it with the primary goal being a published paper will generally not yield a paper worth reading. There are topics in nearly every facet of FPGA design, tools and application that have room remaining for useful research. Asking a broad "help me pick a topic so I can write a paper" isn't likely to get you much advice: no one knows what your talents or interests are, and the subject 'something to do with FPGAs' is extremely broad.Article: 109547
Claudio, Thank you for your imput. It will be passed on to the correct folks so that it may be included in a future release. Subroto Datta Altera Corp. "Claudio" <Totti10@hotmail.com> wrote in message news:1159437484.530576.47250@h48g2000cwc.googlegroups.com... > Thank you for the answer. > I discussed with many people about this feature, and all of them > confirmed to me that there isn't a straight way to do what I'd like to > do. > The only solution I've found is to use the Node Finder, typing the name > of the module I want to find (remembering to always put aterisks before > and after the module name, otherwise the search will fail), selecting > "Design Entry (all names)" as filter and performing a search in the > top-level module enabling the "Include subentities" option. > A bit tricky, but it works... > By the way, I hope that Altera will include a direct option like "List > all instances of the selected module in the design", it could be really > useful with large designs. > > Regards, > Claudio > > > alterauser wrote: >> I think I know, what you mean. Qaurtus shows the instances in the >> h-tab, but when clicking on it, Q jumps to the module. I do it that >> way, that I use cut&paste to copy the name of the module, jump to the >> former folder (upper level) and do a search for. >> >> Another possibilty is to click on the item and chooes "Locate in design" >Article: 109548
what chip are you using, consider using MIG tool from xilinx to generate DDR controller which can communication with fpga directly. akcooper8@gmail.com wrote: > I need help on how to use the EDK DDR memory controller in ISE to write > to/from ram and fpga directly. I have implemented the FFT provided by > Xilinx Coregen but need a faster memory controller to streamline the > FFT process rather than the EDK-PowerPC DDR controller in C that is > provided. Any help is appreciated. > > Thanks > > AshwinArticle: 109549
Aurelian Lazarut wrote: > Hi Annti, > I would call PCIexpress everything but "small little thing" > Aurash Looks like it's only the physical layer from the port name "PIPE..." Sylvain > Antti wrote: > >> Xilinx isnt advertizing 'small things' that are also coming as bonus >> with Virtex-5, I found one by accident while browsing the ML501 >> reference designs and docu, namly >> >> * Virtex-5 has fully dedicated pins for the parallel flash so any NOR >> flash connected properly as configuration memory is also accessible by >> the dedicated pins for both read and writes. Those it is possible to >> use indirect nor flash programming for V5-connected nor flash, and >> surprise it is already offered by Xilinx! its hidden in the "LAB >> resources" for ML501 but the indirect programming software and >> bitstreams are available for all v5lx devices. >> >> * anothes small thing is the access to configuration clock oscillator >> after configuration from FPGA fabric (but that has already been told >> here) >> >> * not to mention that the SYSMON what is there in V4 (but disabled by >> the tools) is now finally user accessible >> >> * CRC32 and CRC64 as primitives >> >> * EFUSE primitive whats that !? >> >> * KEYCLEAR primitive !! Thanks you, Xilinx! this is for clearing the >> encryption key from the FPGA fabric - I was missing this feature badly, >> now its there !! >> >> * PCIE primitive ? I am not believing what I am seeing ?! >> >> * PMV is still there too >> >> * USR_ACCESS is enhanced as well >> >> I guess there are some more nice small things hidden - anyone found >> something? >> or was I just dreaming? too late maybe I'd better rest or who knows >> what else >> I would be seeing! >> >> 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