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
I do not understand your design, but take my word for it: Reading the Xilinx BlockRAM content absolutely requires a clock edge. Nothing happens in the address decoder without a clock edge. In many cases this is a desirable feature, in some cases it is not desirable, but it is a fact: You need a clock, not only for writing, but also for reading. Peter Alfke, Xilinx ApplicationsArticle: 100976
AnonymousFC4 wrote: As of today, could anyone tell me: 1) Are Linux Xilinx tools for FPGA design, especially microblaze, actually, solid, good, usable? 2)Does anyone has RTOS experience with microblaze? If yes, which one? Please comment the answer. Thanks. --Article: 100977
Austin Lesea wrote: > All, > > Here is the answer: > > "Hi, > > Yes this is a bug. This issue is being fixed for the next EDK release > (8.2i). Also, your patches seem correct." > > Austin > GReat, thanks for the followup. SylvainArticle: 100978
Yes, look in the user manual and command reference :-) Simple batch file: vlib work vlog design.v vsim -c work.design_testbench -do "run -all; quit" You can use Tcl in Modelsim PE, and TCL/TK in SE/Questa. You can still use TK in PE but you need to write a standalone TK GUI and use files/sockets to communicate. Hans. www.ht-lab.com "Davy" <zhushenli@gmail.com> wrote in message news:1145673250.397779.122720@i40g2000cwc.googlegroups.com... > Hi all, > > I am new to Modelsim and always use GUI to do all the work. > > I heard that we can use Tcl to control Modelsim to compile and run a > batch of work, is there any example available? > > BTW, I use Verilog. > > Any suggestions will be appreciated! > Davy >Article: 100979
1) yes 2)yes, I'm sure someone does. I don't.Article: 100980
AnonymousFC4 wrote: > AnonymousFC4 wrote: > > As of today, could anyone tell me: > > 1) Are Linux Xilinx tools for FPGA design, especially microblaze, actually, > solid, good, usable? > > 2)Does anyone has RTOS experience with microblaze? > If yes, which one? > Please comment the answer. > > Thanks. > -- > 2) Yes. http://www.xilinx.com/publications/xcellonline/xcell_48/xc_pdf/xc_micrium48.pdf Don't you even bother to visit the web site and do a simple search? AustinArticle: 100981
Ben Jones schrieb: > Hi Fred, You > can do it without any square-roots or even multiplies (except by 2). Not even that because 2(x+1) + 1 = (2x+1) + 2 You need a total of two adders and one comparator per ordinate. Kolja SulimmaArticle: 100982
radarman schrieb: > Where I work, we aren't allowed to directly connect FPGA or CPLD pins > directly to external connectors, save for on-board test points (like > Mictor connectors). Everything goes through external buffers or > registers. Yes, it does add latency, but it does protect > hard-to-replace BGA's from damage. > > Of course, I work on military hardware, and reliability is a major > factor. While most things are replaced at LRU (chassis) level, there > are some systems where the customer is allowed to replace individual > boards. Usually, this happens in a customer repair facility, and is > done by military technicians, but still - it pays to go the extra mile. I thought in military applications reliability is more important than cost. For standard buffers I would argue that you get a much higher failure rate with the buffers than without. You have three times the number of solder joints and much more parts after all. Also, many buffer chips are less robust then FPGA pins. Some don't even have protection diodes. Of course if you use special ESD protection buffers all this changes. But some passive protection to the FPGA pin might give you the same effect. > The other factor is that every board costs so much, that they are > almost never thrown away, and instead reworked. It is much simpler to > replace a buffer chip than a BGA. With the right tools it is not really more complicated to replace a bga or an SOIC. Local IR-heating, pulling the chip, cleaning the board, placing a new chip, local IR-heating again. Cleaning takes longer because there are more pads. But that's about it. I doubt that the cost of replacing the BGA is more than 5% of the cost of isolating the defect. Kolja SulimmaArticle: 100983
Austin:
I am aware of google search... so be reasonable.
If you post with a Xilinx email address, you may refrain from the "RTFM"
type of answers...
--
So if you have any experience, the fact you may to work for xilinx, does not
disqualify to post... with details (the good, the bad, the ugly) about your
experience, we will all benefit from... and Xilinx as a company will also!
Hope it will be more answers from individuals more willing to share their
experience on this topic.
---
Austin Lesea wrote:
> AnonymousFC4 wrote:
>
>> AnonymousFC4 wrote:
>>
>> As of today, could anyone tell me:
>>
>> 1) Are Linux Xilinx tools for FPGA design, especially microblaze,
>> actually, solid, good, usable?
>>
>> 2)Does anyone has RTOS experience with microblaze?
>> If yes, which one?
>> Please comment the answer.
>>
>> Thanks.
>> --
>>
>
>
> 2) Yes.
>
>
http://www.xilinx.com/publications/xcellonline/xcell_48/xc_pdf/xc_micrium48.pdf
>
> Don't you even bother to visit the web site and do a simple search?
>
> Austin
Article: 100984AnonymousFC4 wrote: > Austin: > I am aware of google search... so be reasonable. > If you post with a Xilinx email address, you may refrain from the "RTFM" > type of answers... > -- > So if you have any experience, the fact you may to work for xilinx, does not > disqualify to post... with details (the good, the bad, the ugly) about your > experience, we will all benefit from... and Xilinx as a company will also! > > Hope it will be more answers from individuals more willing to share their > experience on this topic. > --- > > Austin Lesea wrote: > > >>AnonymousFC4 wrote: >> >> >>>AnonymousFC4 wrote: >>> >>>As of today, could anyone tell me: >>> >>>1) Are Linux Xilinx tools for FPGA design, especially microblaze, >>>actually, solid, good, usable? >>> >>>2)Does anyone has RTOS experience with microblaze? >>> If yes, which one? >>> Please comment the answer. >>> >>> Thanks. >>>-- >>> >> >> >>2) Yes. >> >> > > http://www.xilinx.com/publications/xcellonline/xcell_48/xc_pdf/xc_micrium48.pdf > >>Don't you even bother to visit the web site and do a simple search? >> >>Austin > > AnonymousFC4, I actually know very little about FPGA design. I've done some simple ones and read a lot of VHDL code. I knew the answers to your questions, without doing any research, other than looking through recent posts. 1) Like any successful company, Xilinx has been able to produce some reasonably robust tools. There are, from my reading of posts, some bugs, but the Xilinx people really care, and try to get them fixed. It's my understanding that many people beleieve that Synplify has a better synthesis tool. 2) There have been a bunch of posts about Linux, including several about porting Linux and other RTOSes to MicroBlaze. If you had read them, you might have gotten your question. BTW, remember that this is a free and open forum. Flaming people who answer a relatively inarticulate and somewhat fuzzy question is not a good idea. Actually, it is a good way to get future questions ignored. I know that this could get me flamed, as well, but such is life... GSArticle: 100985
Anon, It would help if you would ask something more specific. It appears there are a number of competing RTOS for uBlaze. What is your intended application? Details like that might be useful too. Control? Measurement? Communications? As many will tell you, "real time" is real tough, and many (most) RTOS are more 'in the way' that real assets in solving real time issues. That is why many write their own kernals for serious real time systems work. Is your idea of real time 1 millisecond to switch context/service a process, or 1 microsecond? It makes a real difference in your choices of an RTOS. I know some people who think that a response time of seconds is "real time." It is like asking "I want to run some software on uBlaze? Anyone have any experience?" Ask an intelligent question, and you might get an intelligent answer. I am just amazed sometimes that many do not even visit a vendor's website before they post. If this is a hobby of yours, then OK, fine. But if this is a profession, then do some due diligence. Austin AnonymousFC4 wrote: > Austin: > I am aware of google search... so be reasonable. > If you post with a Xilinx email address, you may refrain from the "RTFM" > type of answers... > -- > So if you have any experience, the fact you may to work for xilinx, does not > disqualify to post... with details (the good, the bad, the ugly) about your > experience, we will all benefit from... and Xilinx as a company will also! > > Hope it will be more answers from individuals more willing to share their > experience on this topic. > --- > > Austin Lesea wrote: > > >>AnonymousFC4 wrote: >> >> >>>AnonymousFC4 wrote: >>> >>>As of today, could anyone tell me: >>> >>>1) Are Linux Xilinx tools for FPGA design, especially microblaze, >>>actually, solid, good, usable? >>> >>>2)Does anyone has RTOS experience with microblaze? >>> If yes, which one? >>> Please comment the answer. >>> >>> Thanks. >>>-- >>> >> >> >>2) Yes. >> >> > > http://www.xilinx.com/publications/xcellonline/xcell_48/xc_pdf/xc_micrium48.pdf > >>Don't you even bother to visit the web site and do a simple search? >> >>Austin > >Article: 100986
Gob Stopper: If asking poster to refrain to some basic respect is "flamming", the so be it... and let pigs fly. Before I posted, I of course, looked at existing posts... and did not find anything, even closely related.... May be you did? Then point to a given message, with date/time if you have some specific in mind. About synthesis, your answer is not exactly what I asked, but it may interest others... then you may want to develop it, and be specific about your experience. About the questions I asked, even a tiny bit of an answer, could interest me (indeed), and a lot of users, so there is still a value there... I still hope that some one has some experience there, and is willing to share it with us? -- Gob Stopper wrote: > I know that this could get me flamed, as well, but such is life...Article: 100987
It is probable that the buffer, although offering more pins to cause faults (Military boards will be x-rayed and each solder joint inspected don't forget) offer a level of protection that FPGA pins can't. A typical "Interface" buffer chip has a higher drive strength, better ESD Protection thru bigger geometry and the "real" outside connections have ESD diodes and the proper interface for the conditions, including current limit, voltage control, hot-pugging support etc. Simon "Kolja Sulimma" <news@sulimma.de> wrote in message news:444a64d2$0$11079$9b4e6d93@newsread4.arcor-online.net... > radarman schrieb: > > Where I work, we aren't allowed to directly connect FPGA or CPLD pins > > directly to external connectors, save for on-board test points (like > > Mictor connectors). Everything goes through external buffers or > > registers. Yes, it does add latency, but it does protect > > hard-to-replace BGA's from damage. > > > > Of course, I work on military hardware, and reliability is a major > > factor. While most things are replaced at LRU (chassis) level, there > > are some systems where the customer is allowed to replace individual > > boards. Usually, this happens in a customer repair facility, and is > > done by military technicians, but still - it pays to go the extra mile. > > I thought in military applications reliability is more important than > cost. For standard buffers I would argue that you get a much higher > failure rate with the buffers than without. You have three times the > number of solder joints and much more parts after all. > Also, many buffer chips are less robust then FPGA pins. Some don't > even have protection diodes. > Of course if you use special ESD protection buffers all this changes. > But some passive protection to the FPGA pin might give you the same effect. > > > The other factor is that every board costs so much, that they are > > almost never thrown away, and instead reworked. It is much simpler to > > replace a buffer chip than a BGA. > > With the right tools it is not really more complicated to replace a bga > or an SOIC. Local IR-heating, pulling the chip, cleaning the board, > placing a new chip, local IR-heating again. > Cleaning takes longer because there are more pads. But that's about it. > I doubt that the cost of replacing the BGA is more than 5% of the cost > of isolating the defect. > > Kolja SulimmaArticle: 100988
When I complied any project with ISE 8.1 webpack with SP3, I got warnings like below: WARNING:ProjectMgmt - "G:/test/watchver/stopwatch_map.ngm" line 0 duplicate design unit: 'Module|stopwatch' WARNING:ProjectMgmt - "G:/test/watchver/stopwatch.ngc" line 0 duplicate design unit: 'Module|stopwatch' Does anyone know what does it mean? or how can I avoid this? thanks a lot.Article: 100989
John, You will now spend most of your time creating "workarounds" for Xilinx 8.1. I finally gave up and went back to 6.3 yesterday. Various 8.1 problems I have seen: 1. The "humongous project file bug"--in this one, your ise project grows to perhaps gigabytes in size, takes forever (20-30 minutes) to load and then doesn't work. The "workaround" is to blow away the project file and start over. Hmm . . . why am I doing this again? This appears to be fixed by service pack 3. 2. Coregen doesn't run--crashes and wants to talk with Microsoft. This is better in service pack 3--at least I could run it from the gui, although it still crashed if I tried to run it separately. 3. The "multipass par fools you" bug. In this one, you run a multipass, find a seed that gives good results, copy the files back, then run par only to find that the timing is now awful. 4. The "can't really run these apps" bug. I normally use my own control app to run the tools from the command line, parse the error file and use timingan.exe if necessary. Now timingan.exe won't run--nothing happens. Still runs if I execute it from the ISE gui. The same is true--at times--of all the gui apps like fpga_editor.exe and such. They won't even run from Windows Explorer--brief hourglass, then nothing. No log files, nothing. They still run from the gui. 5. The "oops the bitfile is too big" bug. Run fpga_editor independently (when it works), define probes, generate bitfile from the probes dialog. The bitfile for a 2vp30 is now 35 bytes too long and won't load properly. Run fpga_editor from the gui, do the same thing and all is well. 6. The "can't do anything even in the gui" bug. In this one, you can't run any processes anywhere. The ISE gui runs, but if you try to run a process (map, par, whatever), all the wheels spin briefly, then show errors for the process, but no log files are created. Forcing run with "rerun" doesn't work--nothing works. The "workaround" is again to blow away the project file. Bottom line is that even after three (3!) service packs, the 8.1 tools are unusable for real work. It was taking me most of a day to discover the next "workaround" so I could build bits when it should take an hour. After struggling to get timing closure on Friday, I gave up, went back to 6.3, ran multipass and had perfect timing bits in an hour and a half. We are looking at upgrading our board to use a Virtex-4, but that may require using version 8 of the tools and I think we'll evaulate Altera seriously now--at least then maybe I could get some work done. Terry Brown On Fri, 21 Apr 2006 09:16:19 -0700, johnp wrote: > I found a work-around - I delete the bulk of the files from my > working directory including the .ise file and now ISE starts > up. I copied in an older 6.1 .npl file and told ISE to convert it > to the newer 8.1 project file. > > John ProvidenzaArticle: 100990
Hello, at the moment I own a Spartan 3 experimentation board (from digilent) (the so called "Spartan 3 starter kit") that I bought from Xilinx directly last year. Together with the board I got the ISE Webpack 6.3i and some additional software to try out for a limited time. Now I would like to use the newest (free) ISE 8.1i Webpack which can be downloaded from the Xilinx side. This leads me to some questions: 1) Will the version of ISE 8.1i for Linux have all the functionalities and features that the Windows (XP) version has ? (In the 6.3i version there seemed to be some features missing in the Linux version). 2) Will the ISE 8.1i software run under Novell/SuSE 10.0 64-bit Linux too ? 3) Is the Windows or the Unix/Linux version of the ISE software the preferred one among professional users ? 4) Can the 8.1i version of ISE be used with this (older) board ? Thanks in advance for any answers Jürgen Böhm ------------------------------------------------------------------------- Dipl.-Math. Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 100991
On Sun, 23 Apr 2006 22:04:46 +0200, Jürgen Böhm wrote: > Hello, Hi. > at the moment I own a Spartan 3 experimentation board (from digilent) > (the so called "Spartan 3 starter kit") that I bought from Xilinx > directly last year. Together with the board I got the ISE Webpack 6.3i > and some additional software to try out for a limited time. I got the same thing about 3 months ago. It's an excellent value. > Now I would like to use the newest (free) ISE 8.1i Webpack which can be > downloaded from the Xilinx side. > > This leads me to some questions: > > 1) Will the version of ISE 8.1i for Linux have all the functionalities > and features that the Windows (XP) version has ? (In the 6.3i version > there seemed to be some features missing in the Linux version). I've never tried the Windows version, but 8.1.03i is apparently full-featured. I used to have problems programming the flash when I used the 7.1(?) Webpack, but these days it works almost perfectly. Simulations aren't working for me; I suspect it's a $PATH issue and it'll probably work for you. > 2) Will the ISE 8.1i software run under Novell/SuSE 10.0 64-bit Linux too ? You will be able to do everything up to generating the programming file. The drivers, however, are 32-bit only - so you can't actually program it when running a 32-bit kernel. > 3) Is the Windows or the Unix/Linux version of the ISE software the > preferred one among professional users ? I'm not a professional user by any means, but I say if it works in the OS you're comfortable with, then there should be no problem. > 4) Can the 8.1i version of ISE be used with this (older) board ? It most certainly can! In the new project wizard: Family: Spartan 3 Package: FT256 Speed: -4 I never tried any of the evaluation software they sent with the board, but it should be an intuitive transition. As of 8.1.03i, they have the code editor/main interface, the constraints editor and iMPACT converted to QT (yay). the rest is WindU (ugh, needs DISPLAY=":0" workaround and portmap to be running). > Thanks in advance for any answers No problem. > Jürgen Böhm DanArticle: 100992
"Fred" <fred@nowhere.com> wrote in message news:4448b5a2$0$209$db0fefd9@news.zen.co.uk... >I would like to use a FPGA to create some simple test patterns. One of >which is a circle with a variable diameter. I'm not sure where to start. >Can this be realistically be done in an FPGA using minimal resources? > > I greatly appreciate the responses here. It's made life a great deal easier! Many thanks again.Article: 100993
Dan McDonald wrote: > I've never tried the Windows version, but 8.1.03i is apparently > full-featured. I used to have problems programming the flash when I used > the 7.1(?) Webpack, but these days it works almost perfectly. Simulations > aren't working for me; I suspect it's a $PATH issue and it'll probably > work for you. I believe the only thing missing is StateCAD. > You will be able to do everything up to generating the programming > file. The drivers, however, are 32-bit only - so you can't actually > program it when running a 32-bit kernel. I run the Linux ISE 8.1 in FreeBSD under ABI emulation and I have this problem. I *did* find a program which will program a Spartan 3 via the Xilinx III cable - http://www.rogerstech.force9.co.uk/xc3sprog/ I haven't used it very much but it does seem to work fine (it can also program a flash chip) I really wish Xilinx would open source the cableserver TCP protocol and a basic bit bang implementation.. It would make my life a lot simpler :) (Not to mention the current cableserver spins chewing CPU if the program that connected to it crashes [which iMpact is prone to do] ...) > As of 8.1.03i, they have the code editor/main interface, the constraints > editor and iMPACT converted to QT (yay). the rest is WindU (ugh, needs > DISPLAY=":0" workaround and portmap to be running). I think it's the other way around.. Everything *but* iMpact is Qt :) Also I've found in *BSD portmap/rpcbind needs to run in insecure mode (ie -i) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 100994
any suggestions in this regard?Article: 100995
Thank you for the comments guys, it would appear they confirm my intuition.Article: 100996
Hello John_H,
Thank you very much for your idea. It saved almost 20K LUTs.
Actually i want a circuit equivalent to 16 port RAM. But as you pointed
is not avilable in lx60. What i am thinking now is to time multiplex
the full operation. 8 port first then the next eight ports. This will
need only 64 RAMs. Thank you once again for your brilliant idea.
regards
Sumesh V S
Article: 100997bad news...... will use multiplied clock for extra edge requirement..... regards SumeshArticle: 100998
Why the PAR is showing unroutable design..... why it is not giving output with a large delay.....Article: 100999
I suggest you step back and re-implement your design in a more conventional fashion. Unless you do something very unconventional or extremely fast, there is no need for using latches. Try to build your design with fli-flops and one common clock, or perhaps with a few, but be aware of the difficulties and dangers of multiple clocks. Peter Alfke, Xilinx Applications
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