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
Hi I developed a medium project size that using Modular Design flow to create a dynamic reconfigurable system. Specifically, I create a memory controller that using a reconfigurable client circuit (fixed and reconfig. modules). I fixed all the bus macros on the FPGA in UCF file to communicate both modules. However, when the Active Modular Phase of Modular Design is performed, the MAP tool issues the following error: ERROR:MapLib:492- Create a dummy tbuf in the context connected to signal data_m_dup0 with a location constraint to a single site. This signal is created after logic synthesis by Leonardo Spectrum tool. "data_m_dup0" is connected on the data_m signal. data_m <= dataout when (pr_st_memctl=write_capture) else (others=>'Z'); "write_capture" is a state. I inserted the code above because I thougth it was necessary to help for understanding the problem. I appreciate any kind of help. Best regards Eduardo Wenzel Brião Catholic University of Rio Grande do Sul state - PUCRS Porto Alegre city BrazilArticle: 55826
> I know that one, actually it is very far from being detailed enough. Depends how close you want to get - If 'very' then you will have to emulate the nasty analogue bits which is going to be almost impossible (?) try here for some more info and the interview - I have to admit it was the interview I remember reading, not the patent document. http://stud4.tuwien.ac.at/~e9426444/sidtech.html > Additional and important information on the digital part of the SID > is available in the interview with Bob Yannes somewhere one the web. > However, there are still open questions about the more analog parts > of the SID. > >Article: 55827
Hi Ray, > I agree with your sentiments regarding Linux. It is also worth noting > that you can run just about anything under the windoze with a fairly > simple install. Many apps need a considerable amount of set up to get to > run under Lixux. Installing Quartus II 2.2 for Linux from CD at this point is no more than mounting the CD, running the install.sh script, answering one question (the installation path), and sitting back while a lot of stuff gets written to disk. I have done several installations myself and it truly is that simple, if you don't count setting a few environment variables like LM_LICENSE_FILE and suchlike, but that's a one-minute job as well. The UNIX installs of the older versions (prior to Quartus II 1.0 sometime in 2001) were a true pain in the rear, I'll grant you that. While still working for Altera I spent many days installing Quartus in some form or another, reconfiguring kernel parameters of compute servers that were supposedly not to be rebooted, setting obscure environment variables etc etc. Very educational but not much fun. Luckily these days seem to be over. Ever since Altera dropped the ObjectStore database manager things have gone uphill very quickly. I've also found that Quartus for Linux is pretty distribution-independant (it even contains its own fonts, just to be sure), even though it's only officially supported under RedHat 7.1. I've successfully run it on RedHat 7.1, 7.3 and 8.0 (using it on RedHat 9 crashes instantly at this point - but then again the ReadHat 9 kernel is so heavily modified that even Linux Torvalds would have trouble recognizing it), a version of Mandrake I don't recall, Suse 8.1 and Gentoo Linux 1.4rc4 (my current favourite) in bleeding-edge mode. My experience with Modelsim under Linux is likewise, and so is my experience with FPGA Connector (a really cool tool to settle pinout discussions between me and my PCB layout guy once and for all), so I guess that Linux installation and maintenance trouble is pretty much a myth - as long as you have had some basic Linux or Unix training. Best regards, BenArticle: 55828
Check out: www.fpga.nl & Jester Karl. "Daniel Fichtner" <daniel2323de@yahoo.de> wrote in message news:cd8e70cd.0305180532.1801e4b0@posting.google.com... > hi, > > do you know if there is a vhdl description or any other (synthesizable) > describtion of the SID chip (6581/6582) ?? > > thanks and byeArticle: 55829
On a sunny day (20 May 2003 10:36:55 -0700) it happened bretwade@earthlink.net (Bret Wade) wrote in <2d91c07d.0305200936.305782c7@posting.google.com>: >Jan Panteltje wrote: > >> ERROR:Place:1993 - Components udc0_uf10_N324 and udc0_N1466 are using the >> F5/F6MUX resources. The component udc0_uf10_N324 is part of a carry chain >> macro. Please RLOC components udc0_uf10_N324 and udc0_N1466 together. > >I haven't seen this particular error before but I believe I can >explain it. The component "udc0_uf10_N324" contains a portion of two >different multi-slice shapes, a carry chain structure and an F5/F6MUX >structure. Apparently the placer is having problems reconciling the >placement requirements of both shapes and is asking for help via the >use of RLOC constraints that would guide the relative placement of the >logic involved. > >There are other possible solutions depending on the root cause of the >problem. If the two shapes ended up sharing the same slice due to an >unrelated pack then anything that blocked that unrelated pack would >avoid the problem. Using a larger device would work (and would also be >a good test of the unrelated pack theory) but another way would be to >assign one of the shapes to an area group and then set a "compression" >attribute of zero which will block unrelated packs for that logic. >There is no need to actually define a range to the area group. > >Example UCF syntax: >INST "some/hierarchy" AREA_GROUP = AG1 ; >AREA_GROUP "AG1" COMPRESSION = 0 ; > >This trick can also be used to guard critical logic from unrelated >packs which can lead to conflicting placement needs WRT timing. > >Bret > Thank you Jan PS yes, reducing the size (by omitting stuff) makes some of these errors disappear. So I think you are right about a larger FPGA.Article: 55830
Ben,
I wasn't referring to the CAE tools as much as to all the other stuff you need
on the computer to do business. These include the CAE stuff of course, but also
a word processor (shouldn't be too much a problem, but might be compatability
issues with cusotmers), Matlab (needed for DSP apps), something to write PDF
files (Adobe Acrobat), a spreadsheet (Excel)(used for various things in the
course of a design), and in the case of a consulting business like mine, it also
includes quickbooks... The point is there is an awful lot of 'standard' stuff
out there that is much more hassle to get working under Linux than on an windoze
machine. The CAE software probably has more support for running under Linux
than does much of the other stuff that still needs a home in order to have a
complete suite. Regarding the CAE stuff, Windows does have a much larger user
base, so the chances of a bug being reported and dealt with are greater than
under Linux. I do enough debug of the FPGA software already.
Ben Twijnstra wrote:
> Hi Ray,
>
> > I agree with your sentiments regarding Linux. It is also worth noting
> > that you can run just about anything under the windoze with a fairly
> > simple install. Many apps need a considerable amount of set up to get to
> > run under Lixux.
>
> Installing Quartus II 2.2 for Linux from CD at this point is no more than
> mounting the CD, running the install.sh script, answering one question (the
> installation path), and sitting back while a lot of stuff gets written to
> disk. I have done several installations myself and it truly is that simple,
> if you don't count setting a few environment variables like LM_LICENSE_FILE
> and suchlike, but that's a one-minute job as well.
>
> The UNIX installs of the older versions (prior to Quartus II 1.0 sometime in
> 2001) were a true pain in the rear, I'll grant you that. While still
> working for Altera I spent many days installing Quartus in some form or
> another, reconfiguring kernel parameters of compute servers that were
> supposedly not to be rebooted, setting obscure environment variables etc
> etc. Very educational but not much fun. Luckily these days seem to be over.
> Ever since Altera dropped the ObjectStore database manager things have gone
> uphill very quickly.
>
> I've also found that Quartus for Linux is pretty distribution-independant
> (it even contains its own fonts, just to be sure), even though it's only
> officially supported under RedHat 7.1. I've successfully run it on RedHat
> 7.1, 7.3 and 8.0 (using it on RedHat 9 crashes instantly at this point -
> but then again the ReadHat 9 kernel is so heavily modified that even Linux
> Torvalds would have trouble recognizing it), a version of Mandrake I don't
> recall, Suse 8.1 and Gentoo Linux 1.4rc4 (my current favourite) in
> bleeding-edge mode.
>
> My experience with Modelsim under Linux is likewise, and so is my experience
> with FPGA Connector (a really cool tool to settle pinout discussions
> between me and my PCB layout guy once and for all), so I guess that Linux
> installation and maintenance trouble is pretty much a myth - as long as you
> have had some basic Linux or Unix training.
>
> Best regards,
>
> Ben
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55831On Tue, 20 May 2003 12:12:18 -0400, Bob Perlman wrote: > On 19 May 2003 02:01:50 -0700, tsvika.hirst@minicom.com (Tsvika Hirst) > wrote: > >>I need to specify a workstation that will use for FPGA development >>(around 300K gates) i.e. simulate, synth, place and route flow (e.g. >>Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was told >>it improves stability and 30% performance relative to Windows2000. > > I use a dual-processor setup myself, with Windows 2000 O/S. Nothing > against Linux, but using an O/S that a lot of other users run makes it > (slightly) more likely that any problems I encounter have already been > tripped over by someone else. > > For those of you with dual-processor systems, a question: which > motherboard are you using? I'm running an old Asus CUV4X-D with two > 1GHz Pentium IIIs and 1.5GB of memory--kind of ancient, but it works > very well. What are today's best choices for dual-processor boards? > > Bob Perlman > Cambrian Design Works I'm using a dual 2.6Ghz Xeon running Redhat 7.3. The most important thing is RAM, get at least 1G but 2G is better. Don't worry about disk speed if you have enough RAM there won't be any paging, get a big IDE disk with an 8M buffer.Article: 55832
tsvika.hirst@minicom.com (Tsvika Hirst) wrote in message news:<a688cfa9.0305190101.79cfedaa@posting.google.com>... > I need to specify a workstation that will use for FPGA development > (around 300K gates) i.e. simulate, synth, place and route flow (e.g. > Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was > told it improves stability and 30% performance relative to > Windows2000. > > I'm trying to set priorities to and find the tradeoffs between: > Processor: Single or Dual (e.g. Pentium IV 2.4GHz) > HDD type and speed: SCSI or ATA/EIDE (e.g. 18GB SCSI 10,000rpm or > 15,000 rpm vs. 80GB ATA 7200rpm) > RAM size: 512MB/1GB > > I will very much appreciate your feedback. If you're going to be doing a lot of work, I'd optimize my work environment first. That means a dual-head LCD setup. You'd be amazed at how much comfortable an LCD is to work with. Likewise, dual-head will save you gobs of time shuffling things around your desktop. Now, Linux will buy you a speed gain but only if the software supports it. ISE doesn't right now. I've seen big performance jumps using Linux (over Windows) on the same machine but only in software available native to Linux. Dual processor will avoid bogging down your machine when it is crunching on a P&R or something, but for that I just use VNC. I'll bring up VNC to a Linux box or another Windows machine in one of my heads, leave the other one on the Xilinx job and it's pretty smooth. I don't sponsor the dual-processor approach for most things. It is nice for multi-user UNIX setups so that folks don't affect each other, but for a single-user setup with little software support for multiprocessor, put your money elsewhere. SCSI is great for multi-threaded file access such as file serving, but won't buy you much in a single-user environment. It will get you a little, but for Xilling work, the processes aren't I/O limited, they're CPU limited. Bottom line-- get the fasted single-CPU setup you can afford with quality components and speedy memory (and lots of it) to keep the Xilinx environment efficient. Run a dual-head LCD setup to keep your WORK environment efficient. If you want to do other things while the jobs are running, get another PC (no monitor) and use VNC. JakeArticle: 55833
Newsgroup wrote: > Has anyone experience of BGA balls separating from the PCB pads when > cycling the boards at thermal extremes e.g. -40degC to +85degC. > I understand that there are cases where outer balls/pads have been seen to > separate on physically large BGA devices but need to understand what > physical size this is i.e. 35mm, 40mm?? This should be reduced by going > for well matched Tce of BGA substrate to PCB material but are there other > issues worth considering. Did you visually check the PCB behavior during operation at these extremes (especially the lower end)? When PCBs get warmed up differently on both sides they tend to bend and look like a slice of dry bread. Also check that the PCB layer stack is built up symmetrically. Especially in view of ground an power planes. When a majority of planes is located on one side of the PCB, it will be deformed as well depending on temperature (even if the board has the same temperature on both sides). Regards, MarioArticle: 55834
Hi Yevgeny, Usally I put the Germs monitor into my bootrom (M4k or ESB depending if I am using APEX or Cyclone/Stratix) block in the FPGA. This is done by adding a on-chip memory (RAM/ROM. Then select size to 2kByte and add content GERMS monitor. When you then do a build the germs monitor will be compiled and put into this memory content. Germs do not need FLASH to function and I can help with storing sw into exteral flash but can also be used to start your own SREC files. Cheers Fredrik syevgen1@hotmail.com (Yevgeny K.) wrote in message news:<6c3628cf.0305201149.15e36883@posting.google.com>... > Hello all. > > We are using Altera NIOS CPU with non-Altera PCI card with Altera FPGA > (Gidel PROC20K board without flash memory). > We are trying to use GERMS monitor, but it doesn't work - the "nios-run" > script doesn't find a target (no responce from the GERMS). > All the "hardware" was checked over and over - it's OK for sure. > We looked at the GERMS source code, and it looks like it requires flash > memory to exist and the program that GERMS receives is uploaded to flash, > so this maybe the explanation why in our case (no flash on board) it > doesn't work. > The question is, can the GERMS monitor be somehow "reconfigured"? > In other words, can we make it work somehow without flash, by uploading the > program to the RAM on the FPGA itself? > Has anybody tried something like this? > > Thanks in advanceArticle: 55835
"B. Joshua Rosen" <bjrosen@polybus.com> writes: > I'm using a dual 2.6Ghz Xeon running Redhat 7.3. The most important > thing is RAM, get at least 1G but 2G is better. Don't worry about > disk speed if you have enough RAM there won't be any paging, get a > big IDE disk with an 8M buffer. You're getting very close to the 2/3.xGB limit here. As design/tool complexity increases you might need to migrate to a 64-bit CPU. Does anybody know which tools will be available in 64-bit version for the AMD Opteron? The only one I know of is Synopsys VCS: http://www.synopsys.com/news/announce/press2003/vcs_amd_pr.html Most of the other Synopsys tools are available in 64-bit versions under Solaris/SPARC so I would expect most of these to migrate to X86-64/Linux. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 55836
Here is an update on the 5th Workshop on Cryptographic Hardware
and Embedded Systems (CHES 2003):
1) The List of Accepted Papers is available on the CHES web site:
www.chesworkshop.org
2) We have three invited speakers:
Hans Dobbertin, Ruhr-University Bochum, Germany
Adi Shamir, Weitzman Institute, Israel
Frank Stajano, Cambridge University, UK
3) Registration information is also on the CHES web site. You will find
information about accommodation and traveling too.
We will be happy to assist if you have other questions regarding CHES
2003.
Regards, Christof Paar
============================================
CHES 2003 CHES 2003 CHES 2003 CHES 2003 CHES
www.chesworkshop.org
============================================
Prof. Christof Paar
Chair for Communication Security
Dept. of Electr. Eng. & Information Sciences
Ruhr-Universitaet Bochum
44780 Bochum, Germany
URL: www.crypto.rub.de
Article: 55837Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:3EBF8D29.C2D5FBA5@andraka.com... > You can often simplfy readback of control registers that are written only by the > microcontroller by putting a shadow 'register' in RAM in addition to the > physical register. The physical register provides the individual bits to the > circuit while a RAM which is simultaneously written provides a copy of the data > in a convenient form for easy readback. If you have a small number of status > registers whose contents are updated by the FPGA logic, you can sometimes use a > dual port memory for the shadow register with the second port hardwired for > write at a specific address so that the status info winds up in the proper > location in the shadow RAM. > Thanx for your information. I have tried to understand your specification but I think I need more information. The basic principle what I need is a Dual-Port-Ram. The microcontroller selects via address bus, WR, CS, RD the register in the FPGA, respectively in (DUAL)-RAM. But the other side of DUAL-RAM should be direct useable without addressing the register. A control register are written by the µC and read by the FPGA - the status register are written by the FPGA and read by µC. I think a little example would be very useful. Until now I have created a 8 Bit wide register block by programming a discrete register (with CS, WR, RE, data_io (µC), data_io(FPGA), rm (register mode [status/config]. Then i have combined several 8 Bit registers to a block of e.g. 16 or more. To select the register I have developed a simple address decoder. In principle it runs, but I need more than 16 registers, e.g. 48 or more, and then this method becomes to complex. The other way would be to use a DUAL-RAM by addressing every time I need a config information and store it in the actual process. Is it clever?? Maybe, my idea to solve this problem could be the wrong way. I am open for other methods of resolutions. Best regardsArticle: 55839
In article <8679149d.0305190557.2eb2cd3c@posting.google.com>, Henning.Bahr@ncl.ac.uk says... > Hello there! > .. snip .. > Is it a problem for the FPGA to drive 9 memories in parallel? If it's > feasible to use an FPGA, which products would be most suitable? > Many thanks in advance for your help. > Kindest Regards, > Henning > If your question was if you can connect the 9 chips directly to the FPGA then the answer is : It depends on the input capacitance of the memory chip. A typical SDRAM chip has max. 5 pF per pin. This gives a worst case of 45 pF load and can slow down your signal. Best regards -- Klaus Falser Durst Phototechnik AG kfalser@IHATESPAMdurst.itArticle: 55840
Jens Nowack wrote: > Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag > news:3EBF8D29.C2D5FBA5@andraka.com... >> You can often simplfy readback of control registers that are written only > by the >> microcontroller by putting a shadow 'register' in RAM in addition to the >> physical register. The physical register provides the individual bits to > the >> circuit while a RAM which is simultaneously written provides a copy of >> the > data >> in a convenient form for easy readback. If you have a small number of > status >> registers whose contents are updated by the FPGA logic, you can sometimes > use a >> dual port memory for the shadow register with the second port hardwired > for >> write at a specific address so that the status info winds up in the >> proper location in the shadow RAM. >> > > Thanx for your information. I have tried to understand your specification > but I think I need more information. > > The basic principle what I need is a Dual-Port-Ram. The microcontroller > selects via address bus, WR, CS, RD the register in the FPGA, respectively > in (DUAL)-RAM. But the other side of DUAL-RAM should be direct useable > without addressing the register. > A control register are written by the µC and read by the FPGA - the status > register are written by the FPGA and read by µC. > > I think a little example would be very useful. Such a dual-ported RAM you need is usually not available, unfortunately. The scenario proposed by Ray is only useful, when you have a couple of control registers (I'm refering to your terminology) that need to be read/writable by the controller. In this case you implement both your actual control registers and the RAM (that does not need to be dual-ported). When the controller is writing something, it is written into the actual control registers AND into the RAM as well. When the controller is reading something, you would just return the data from the RAM. This safes you to implement this nasty multiplexer stuff. The actual problem are the status registers, however. When you want to read them by the controller, you have to select the right one by a mux. This can also be comined with the described shadow-RAM method (i.e. when you are reading, you sometimes return the RAM contents and sometimes status register contents). > Until now I have created a 8 Bit wide register block by programming a > discrete register (with CS, WR, RE, data_io (µC), data_io(FPGA), rm > (register mode [status/config]. Then i have combined several 8 Bit > registers to a block of e.g. 16 or more. To select the register I have > developed a simple address decoder. > In principle it runs, but I need more than 16 registers, e.g. 48 or more, > and then this method becomes to complex. > > The other way would be to use a DUAL-RAM by addressing every time I need a > config information and store it in the actual process. Is it clever?? It depends on your application. But generally there's the same problem with the status registers. Of course, you could send some kind of command to some back-end logic that writes the value of a certain status register into the dual-ported RAM. But here you are just moving the mux problem deeper into the FPGA (farther away from the controller interface). > Maybe, my idea to solve this problem could be the wrong way. I am open for > other methods of resolutions. Perhaps some useful hints: - avoid read/write registers; implement just read-only and write-only registers - try to make use of tristatable busses (if your FPGA does support this feature) in order to create multiplexers; this saves a lot of logic resources Regards, MarioArticle: 55841
Ray Andraka wrote: > Ben, > > I wasn't referring to the CAE tools as much as to all the other stuff you need > on the computer to do business. These include the CAE stuff of course, but also > a word processor (shouldn't be too much a problem, but might be compatability > issues with cusotmers), Matlab (needed for DSP apps), something to write PDF > files (Adobe Acrobat), a spreadsheet (Excel)(used for various things in the > course of a design), and in the case of a consulting business like mine, it also > includes quickbooks... The point is there is an awful lot of 'standard' stuff > out there that is much more hassle to get working under Linux than on an windoze > machine... My experience over quite a few years is that the CAE software itself is the biggest hassle, regardless of the platform. Trying to get it running, hitting and figuring out workarounds for bugs, etc. And that is only compounded when organizations like Xilinx change the software completely every few years. I think anyone who can figure out CAE software can handle Linux with no problem. And all those tools, though not the brands, you mentioned are already available for Linux. I do all phases of my business exclusively on Linux. I only have Windows around for customers who want something that runs only on Windows, and for Wine development testing when I have some spare time. -- My real email is akamail.com@dclark (or something like that).Article: 55842
Make sure your environment variables are correct. It believe it has to point to your license file or license server or both. I had problems with Synplify because of an environment variable setting. Also, something may have changed when you upgraded. Try going back to your older version. Try running them under Win2000 if it is available, I run modelsim and synplify under win2000 without any problems. Dennis Maasbommel wrote: > From: "Dennis Maasbommel" <aabbccdd00@hotmail.com> > Subject: Modelsim generating (Sigsegv BadPointer Access)-error on winXP > Date: zondag 18 mei 2003 22:59 > > Hello again, you all ! > > The advice on my previous post (see below) was to upgrade to Modelsim > version 5.7. > So I did, but unfortunately, the program running on my winXP system, still > collapses when > I try to add signals to the wave window. And here I have no solution or > workaround yet. > > It occured to me, that perhaps the system collapses if I'd try to add > signals to the wavetable, > if they haven't been forced a particular value at all. So I forces the > signals a value and simulated > the model for some time, and THEN added the signals to the wave table. > Unfortunately, still no success. > > Is somebody able to help this student out here? > Thanks in advance. > > Best regards, > Dennis Maasbommel > > > > > ----- Original Message ----- > From: "Dennis Maasbommel" <aabbccdd00@hotmail.com> > Newsgroups: comp.arch.fpga > Sent: Thursday, May 08, 2003 3:01 AM > Subject: Modelsim generating (Sigsegv BadPointer Access)-error on winXP > > > >>Hi Folks, >> >>Using FPGA Advantage V5.4 on my WinXP SP1 system, >>I am having some problems with the integrated modelsim (v5.6d) >>component. >> >>After a succesful compilation, I try to simulate the model, >>But with many models I get this error >> >> ** Fatal: (SIGSEGV) Bad pointer access. >> >> >>I searched using Google and it took me to the GNU C Library, >>where this error was explained; From this point my guess is >>that maybe Modelsim is not suitable for WinXP yet. >> >>I have tried all the compatibilty modes >>(i.e. win95, win98/winME, winNT4 SP5, win2k) >>but neither of these modes prevented modelsim from >>generating this error. >> >>I have also tested a very simple model, which COULD be simulated, >>but unfortunately Modelsim collapsed (program exits without further > > notice) > >>when I wanted to add signals to the wave-table. I guess maybe this has >>someway the same cause as the 'Bad Pointer Access'-error. >> >>Beside this behavior, I have no other clue that my installation >>version is corrupted >> >>Does any of you have experienced likewise problems with this tool, >>and/or know how to solve these problems? I would be glad to hear it! >> >>Best Regards, >>Dennis Maasbommel >> >> > > > > > >Article: 55843
I use Cocentric SystemC Behavioral Compiler to synthesise a SystemC specification implementing a N stages pipelined datapath , with loops (for statement) and pipeline_loop command. Target technology is APEX20KE FPGA. This works fine with N<=4, but fails with N>4. -- -- schedule -io cycle_fixed -effort low -- -- Information: Mapping components to FPGA........................................... ................................................................................................................. -- Error: Unable to communicate with FPGA Compiler II, launched from /soft/synopsys_hd/2001.08/fpga_compiler2/bin/fc -- 2_shell (HLS-608) Anybody has an idea why ? Thanks, CharlesArticle: 55844
How does one program the Altera configuration devices EPC1 and 1441? Can you use the standard parallel byteblaster cable, or do you need a special programmer? if so, where cao I find some information? Can't seem to find any information on the Altera CD. Any ideas?? thanks allArticle: 55845
VNC is fine for text stuff. It leaves quite a bit to be desired for looking at simulation traces though.
Jake Janovetz wrote:
> tsvika.hirst@minicom.com (Tsvika Hirst) wrote in message news:<a688cfa9.0305190101.79cfedaa@posting.google.com>...
> > I need to specify a workstation that will use for FPGA development
> > (around 300K gates) i.e. simulate, synth, place and route flow (e.g.
> > Foundation ISE + ModelSim XE). I plan to use RedHat Linux, as I was
> > told it improves stability and 30% performance relative to
> > Windows2000.
> >
> > I'm trying to set priorities to and find the tradeoffs between:
> > Processor: Single or Dual (e.g. Pentium IV 2.4GHz)
> > HDD type and speed: SCSI or ATA/EIDE (e.g. 18GB SCSI 10,000rpm or
> > 15,000 rpm vs. 80GB ATA 7200rpm)
> > RAM size: 512MB/1GB
> >
> > I will very much appreciate your feedback.
>
> If you're going to be doing a lot of work, I'd optimize my work
> environment first. That means a dual-head LCD setup. You'd be amazed
> at how much comfortable an LCD is to work with. Likewise, dual-head
> will save you gobs of time shuffling things around your desktop.
>
> Now, Linux will buy you a speed gain but only if the software supports
> it. ISE doesn't right now. I've seen big performance jumps using
> Linux (over Windows) on the same machine but only in software
> available native to Linux.
>
> Dual processor will avoid bogging down your machine when it is
> crunching on a P&R or something, but for that I just use VNC. I'll
> bring up VNC to a Linux box or another Windows machine in one of my
> heads, leave the other one on the Xilinx job and it's pretty smooth.
> I don't sponsor the dual-processor approach for most things. It is
> nice for multi-user UNIX setups so that folks don't affect each other,
> but for a single-user setup with little software support for
> multiprocessor, put your money elsewhere.
>
> SCSI is great for multi-threaded file access such as file serving, but
> won't buy you much in a single-user environment. It will get you a
> little, but for Xilling work, the processes aren't I/O limited,
> they're CPU limited.
>
> Bottom line-- get the fasted single-CPU setup you can afford with
> quality components and speedy memory (and lots of it) to keep the
> Xilinx environment efficient. Run a dual-head LCD setup to keep your
> WORK environment efficient. If you want to do other things while the
> jobs are running, get another PC (no monitor) and use VNC.
>
> Jake
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 55846Jake Janovetz wrote: > ... > Now, Linux will buy you a speed gain but only if the software supports > it. ISE doesn't right now. I've seen big performance jumps using > Linux (over Windows) on the same machine but only in software > available native to Linux. > My completely unscientific observation is that the Xilinx software runs just as fast under Linux as Windows. And after all, it is X86 software running on an X86, so unless there are a lot of API calls (which are a minor part of CAE processing) this would be expected. -- My real email is akamail.com@dclark (or something like that).Article: 55847
Evolvable Hardware for Autonomous Systems UCLA Extension, Los Angeles, CA August 18-20 Lecturer: Dr. Adrian Stoica, Jet Propulsion Lab http://www.uclaextension.org/unexVirtual.cfm?d=/shortcourses/summer2003/03SuP5502.cfm ----------------- Evolvable Hardware (EHW) is a new field at the confluence of Reconfigurable Hardware, Automatic Design, Artificial Intelligence and Autonomous Systems. Its main objective is the development of a new generation of hardware, self-configurable and evolvable, environment-aware, which can adaptively reconfigure to achieve optimal signal processing, survive and recover from faults and degradation, improve its performance over lifetime of operation. EHW techniques have already proven successful in design automation, automated calibration and tuning, and on-line adaptation of hardware systems. This course presents the fundamentals of EHW technology, overviews existing and previews future reconfigurable devices, explains algorithms and techniques for guiding self-configuration, illustrates operation with evolvable hardware experiments, provides application examples, covers specific difficulties in doing evolution with hardware in the loop and ways of addressing them. The course is intended for engineers, managers, and other professionals who are involved in development and utilization of intelligent and adaptive hardware (flexible and survivable). It also targets those involved in the development and utilization of autonomous systems, automated design tools and platforms, automatic calibration and tuning. At the end of the course the attendants will be able to design evolvable hardware systems for their particular area of application. No special pre-requisite. -------------------- Lecture notes are distributed in the first day of the course. ------------------ Adrian Stoica, PhD, Principal Member of the Technical Staff, and Manager for Computing Devices in the Space Information Systems Technology Office at the Jet Propulsion Laboratory (JPL), California Institute of Technology. Dr. Stoica has over 17 years of R&D and technology development in adaptive and learning techniques for autonomous intelligent systems. The last seven years he was has been with the Advanced Computing Technologies Group at JPL, where he has lead multi-million dollar technology R&D projects for NASA and DOD, in the areas of adaptive hardware for space autonomous systems (including evolvable/reconfigurable hardware, adaptive/learning hardware and sensor fusion hardware), and next-generation robots (focusing on rover intelligence and robot sensory-motor control). He and his team have designed and demonstrated three generations of evolution-oriented chips. Dr. Stoica has authored over 70 papers, was keynote speaker at several conferences, is member of editorial board of several journals, taught conference tutorials and short courses, and has chaired four conferences on evolvable hardware, the latest being the 2002 NASA/DOD Conference on Evolvable Hardware. He is a recipient of the 1999 Lew Allen Award, JPL's highest distinction for excellence in research. --------------- Course Program Introduction to EHW - EHW as Adaptive hardware - Components of a EHW system - EHW for flexibility and survivability of autonomous systems - Automated design and adaptation by search/optimization techniques, - Extrinsic and Intrinsic EHW Reconfigurable and Morphable Hardware - Reconfigurable hardware (switch-based). Devices, SW Tools, Potential for EHW - Field Programmable Gate Arrays (FPGA) - Xilinx examples - Field Programmable Analog Arrays (FPAA) - Anadigm Examples - Field Programmable Transistor Arrays (FPTA) - JPL examples - Reconfigurable antennas - Other reconfigurable structures - Context-switching, speed of change, latency issues - Morphable hardware (no switches). Fine changes and tuning. - Morphable Materials and devices - Polymorphic circuits Algorithms for self-configuration and evolution - General perspective on search, optimization and adaptation algorithms - Essence of evolutionary algorithms - Flavors: Genetic Algorithms, Genetic Programming - Multi-criteria optimization, trade-offs, Pareto optimality Demonstrations of Evolvable Systems - Evolution on JPL EHW Testbed (platform for mixtrinsic evolution) - Details of EHW Pack (SW tools), and NICE (Visualization tool) - Evolution on JPL SABLES (Stand-Alone Board-Level Evolvable System) o Half-wave rectifier, Filters, Digital circuits Application Examples - Programmable compensation for analog circuits (Optimal tuning) - Programmable delays in high-speed digital circuits (Clock skew compensation) - Automated discovery - Invention by Genetic Programming (Creative Design) - EDA Tools, analog circuit design - Adaptation to extreme temperature electronics (Survivability by EHW) - Fault-tolerance and fault-recovery - Evolvable antennas (In-field adaptation to changing environment) - Adaptive filters (Function change as result of mission change) System Aspects - Integration - Need for upfront complete specifications - Behavioral vs structural specification - Languages for evolvable hardware - Verification and validation - On-line vs off-line evolution - Techniques to reduce evaluation time - Challenges, and open problems Resources for EHW Engineers - A guide to published literature and on-line resources - Software tools - EventsArticle: 55848
Hi I have a 50 MHz clock that I would like to run in 5 MHz. Thus making it neccessary to use two clkdlls in serial. If I set the generic CLKDV_DIVIDE to 2 or use the default value, 2, the lock signal appears. But if I use any other valid number than 2 the lock signal does not appear even though the division of the clock seams ok in the wavetrace. The same problem occurs both in ncsim and modelsim. My code and testbench can be found at http://bart.sm.luth.se/~johmat-8/ Regards JohanArticle: 55849
I've got a question of terminology for the group: is FPGA design generally classified as hardware, firmware, or neither? Most of the designs I've worked on have served to interface firmware with hardware. It seems that firmware engineers like to think of FPGA designs as more firmware, and that hardware engineers like to think of FPGA designs as more hardware. As an FPGA developer, though, I'm of the mind that the unique design considerations of the technology justify a new and separate category . . . A coworker suggested the term "coreware," but apparently that's a registered trademark of LSI Logic. Is there another term with the -ware suffix commonly used to refer to code (VHDL, Verilog, or otherwise) intended to be implemented in an FPGA? Joe
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