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
Magnus Homann wrote: > > Rickman <spamgoeshere4@yahoo.com> writes: > > [Deleted Homann's tired rantings about negative hold time, when he > really meant positive hold time] > > > I think the setup and hold times that Peter is talking about are for > > internal paths from one FF to another or input or output FFs in the > > IOBs. For the internal FFs, if I understand things correctly, Xilinx > > simply guarantees that the hold time will be met under all conditions > > (provided the clock distribution is used). You then specify the clock > > rate and the timing tools tell if the routing tools met the setup times. > > > > The clock pin to IOB pin setup and hold are specified in the databooks. > > Again, the assumption is that the proper clock distribution is used. But > > I believe you can get 0 ns (or negative) hold if you allow the input > > delay to be used. This gives you a larger setup time. If you want a > > smaller setup time, you take out the delay and you get a positive hold > > time. > > It is used, and I still get positive hold time, about 0.7 ns. I also > get negative setup time, so the window isn't very big. I just want to > constrain the P&R, and the timing analyzer so that it would check it > for me. > > Note: I'm trying to use the secodnary clock routing resource, as I'm > using the global resource for Other Stuff (four truly global clocks). > > > The Xilinx datasheet that I have lists only the pin to pin timing for > > LVTTL signals with delay. If you use the DLL, you can meet your > > requirements no problem. If you don't use the DLL, then it depends on > > the speed grade, the part size and I can't tell about turning off the > > delay option. > > Not really. I need 8 of these clocks, and there are only four DLLs > (and global clock dist.) in the Virtex family. > > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se Ok, now that I have read your other posts more carefully, I think I understand your problem. You have a design which is using more than the 4 clocks which can be supported on the 4 primary clock nets. The more local clocks are being routed on secondary clock lines to the IOBs which you have located as close as possible to the secondary clock input pins. You are using the input delays on the data going to the input FFs in the IOBs. Basically, you are doing everything you are supposed to do and you are still getting a negative setup time and a positive hold time.... I would say you are screwed! No actually, you might be able to deal with this by using an internal FF rather than one in the IOB. The problem is that you have too much delay in the clock net and too little delay in the data path. But I don't know that the tools will give you a good analysis if you don't use the IOB FFs. I have never seen the tools analyze hold time for the internal FFs. In fact I have never seen the tools analyze hold time at all (maybe I am just getting old and don't remember). But if you can force the signal to go through a LUT or two, and you can afford the extra setup time, then it will most likely work. Funny, I used to have to fight the tools to get them to NOT route the signals through an IOB as a wire! -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21201
"Don McCarley" <mccarley@fast.net> wrote in message news:scfj4j9abi7135@corp.supernews.com... > Has anyone been able to actually obtain the larger packages for Virtex and > Virtex E devices? Like the FG456, FG676, and FG680 for the 2.5V Virtex or > the FG456, FG676, FG680, FG860, FG900, and FG1156 for the 1.8V Virtex-E. We didn't have any difficulties getting a small handful of XCV400's in the FG-676 last month. ---Joel KolstadArticle: 21202
Peter Alfke wrote: > But the newer families, XC4000XV, XC4000XLA and SpartanXL DO have this feature. It > IS supported in epic/fpga_editor. Is it supported by stone knives and bear skins as well? Sorry. The support of this feature only by the gacky process of creating a macro was, is and will always be a joke. The only excuse for it was that the older 4K parts didn't have this feature, and the 4000XLA parts were enough faster, and about the time that the lack of reasonable software support would have been a problem, Virtex came out. > As we all know, it is also in Virtex and Spartan2 With reasonable software support, with pricing and speed that looks very attractive. -- Phil Hays "Are you willing to vote for funding the completion of the third report of the IPCC"? Ask the question!Article: 21203
What Peter's saying is yes it is there, but its not in the software so nah nah nah, use a virtex/spartanII Peter Alfke wrote: > Allan Herriman wrote: > > > > > Am I missing something here? My '99 databook shows that the > > 4000/Spartan parts do not have a register on the tristate control in > > the IOB. Only the Virtex/Spartan2 parts have the register. > > Allan, you are not missing anything. > Since the software doesn't support it in XC4000XL and SpartanXL, it effectively > doesn't exist (sigh!), and is not documented. > Use Virtex and Spartan2 for registered control of Output Enable. > > Peter Alfke -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21204
There are a number of commercially available PCI FPGA cards out there. See www.optimagic.com for a fairly comprehensive list. For smaller stuff (up to around a virtex 400 I think now) look at VCC. If you need multiple FPGAs, you might look at something like the annapolis wildstar board with 3 XCV1000's on it. As far as programming, you can't load VHDL directly into the FPGA. It has to be synthesized by one of the synthesis engines such as Exemplar, Synplicity or FPGA express, then placed and routed using the xilinx tools...But, I'm sure you knew that. Yvon Hache wrote: > Hi, > We are working on an intensive calculation application. We want to use the > parallel capability of FPGAs to accelerate the calculation. Does anyone > know where we can find a PCI compatible board with large FPGAs that we can > download our VHDL code to do the calculation? Or, is there such thing as > huge logic array available through the internet that we can download our > compiled VHDL, execute and get back the answer in no time? > > Yvon H. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21205
Because the software dweebs didn't want go through all the pain to add it to the tools, documentation, and support. Rickman wrote: > Ray Andraka wrote: > > > > Its not in the data book because it's not supported by the software. XC4000XL > > and XLA parts have the tristate register, but it is unknown to the software and > > therefore essentially unusable. I don't know if it is in the Spartan part or > > not. The earlier 4K parts do not have it. > > Now this really doesn't make sense to me. They put a feature in the > chips that they never supported in software??? Why would they do that? I > am sure that the cost in real estate was not large, but I can't believe > they would fail to support such a simple feature. If you told me that it > was not supported in VHDL or some other means, then that would make > sense. But if they didn't even make an effort to support it in the > schematic form, then why put it in the chip? > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21206
The question was not why did they not support it in the software. But why did they bother to put it in the hardware if they weren't going to support it in the software? Did somebody change their mind after the silicon was drawn? Besides, they had to do the work for the Virtex chips anyway. If they had put it in for the 4K parts, then it would already be there for the Virtex parts. They didn't start from scratch for Virtex tools did they? Ray Andraka wrote: > > Because the software dweebs didn't want go through all the pain to add it to the > tools, documentation, and support. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21207
On Wed, 8 Mar 2000 09:40:24 -0700, "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote: >Ray Andraka wrote in message <38C64FE0.13682CCB@ids.net>... > >>AFAIK, the xilinx software still doesn't support the tristate register for >4K >>parts. > >And it won't be. One of the Xilinx apps guys sent me a private note about >that. He said a Change Request was reported in September of last year, and >it was "closed as Never Fix." isn't there an app note that says that you can use the tristate reg in the XLA by using the map -pr option? doesn't this work? it seems strange that someone wrote the note without testing it. the map option works on virtex, but unfortunately, last time i looked, using an 'IOB=TRUE' attribute didn't work. this makes it impossible to write a completely generic IOB component; i don't know if this has been fixed yet. evanArticle: 21208
steve wenner wrote: > > Could anyone tell me how to successfully compile a pal design using > Protels package? I use the CUPL wizard within the package and create a > schematic however when I go to compile I get a lot of errors. Most seem > to be generated by the fact that not all the internal logic outputs are > being used (i.e. using only 9 bits of a 16 bit counter). I have tried > placing no connects on these pins but to no avail. I want the compiled > jedec output file to fit into a GAL22V10. > > thanks > > Steve Give the schematic input the heave-ho, and just use HDL equation entry. Look for details of CUPL's REGISTER_SELECT, which allows .T equations to be coded ( makes counters a snip ) but the compiler can turn them into .D for the base SPLD's that do not have Toggle registers. If you use Atmel ATF750CL, it has separate clocks, and T/D register options, and 130uA typ static current. - jg -- ======= 80x51 Tools & IP Specialists ========= = Want to work smarter than C ? = http://www.DesignTools.co.nz/modbench.htm = http://www.DesignTools.co.nzArticle: 21209
I didn't quite understand what you were doing before your last post - my post wasn't actually a suggestion for you, but simply an attempt to prod Xilinx into giving an official line on the use of secondary clock nets in general. The big problem here is CLB->CLB clocking, rather than IOB clocking. I think, as Rick says, you're on your own. I've never noticed any hold time reporting either, and the constraints are all for constraining setups. Good luck! EvanArticle: 21210
I've just been on the website: >isn't there an app note that says that you can use the tristate reg in >the XLA by using the map -pr option? doesn't this work? it seems >strange that someone wrote the note without testing it. The app note (XAPP123) didn't actually say this at all - it's just a description of how to create the hard macro. I must be getting old. >the map option works on virtex, but unfortunately, last time i looked, >using an 'IOB=TRUE' attribute didn't work. this makes it impossible to >write a completely generic IOB component; i don't know if this has >been fixed yet. This is scheduled for fixing in 2.1i+, apparently due in May. BTW, any newbies reading this thread will probably come to the conclusion that the software is bug-ridden and that reported bugs aren't fixed. The IOB=TRUE is something I reported last year, and the projected fix will be over 8 months later. On the other hand, next to nobody will want to use this feature, and at least it will get fixed, eventually. Just to add some balance, here are my experiences with 3 other FPGA tool vendors and their technical support: Vendor #1: I can't get through to the real vendor; I have to talk to the disti. This is the kiss of death. There's nothing useful on the web site, and I know more than the disti anyway. The in-detail documentation is plain wrong. Two recent problems: the documented comment character in a constraints file can't be used to start a comment. This is pretty fundamental; nobody knows the reason. I'm eventually told to use a Tcl script instead of a constraints file. Second: there are two documented methods to carry out an important procedure. Neither works, nobody knows why, I'm still waiting for an answer (I suspect there isn't one) after some months. Vendor #2: Vendor doesn't even have a website. Support from disti; see scenario (1) above. I recently ask a question on a newsgroup (which is answered by another user), vendor sees the question, instructs disti to mail me with half-baked procedure; I don't even bother replying to him. Vendor #3: Nothing useful on website. Disti wants to channel technical support. However, I've reported several problems direct to the vendor, and I always get someone who knows what they're talking about, and is grateful for a bug report. However, there's no way to see anyone else's bug reports, so you have to find them all for yourself. Go figure... EvanArticle: 21211
Rickman <spamgoeshere4@yahoo.com> writes: > No actually, you might be able to deal with this by using an internal FF > rather than one in the IOB. The problem is that you have too much delay > in the clock net and too little delay in the data path. Well, on the road to placing the right FFs in the right IOB, it actullay happened that the internatl FFs were used for thsi local clock. The result was even more hold and even less setup... Apparently, the clock delay were larger than the route delay. Or I didn't understand what the tool was telling me. > But I don't know > that the tools will give you a good analysis if you don't use the IOB > FFs. I have never seen the tools analyze hold time for the internal FFs. > In fact I have never seen the tools analyze hold time at all (maybe I am > just getting old and don't remember). But if you can force the signal to > go through a LUT or two, and you can afford the extra setup time, then > it will most likely work. > > Funny, I used to have to fight the tools to get them to NOT route the > signals through an IOB as a wire! You have to find the right switch... :-) Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 21212
TROJAN <psfeib@btinternet.com> wrote in message news:sW2y4.107252$O5.328631@stones... > OK! you HAVE to try this out....just got it the other day..GREAT FUN! > Watch the disc for between 40-60sec....then look at your hand or anything really...just like tripping, but without the drugs. (Dont know if thats a good or bad thing<G>) > We appoligise for the broken link the other day..but our server went down due to demand:( But THIS LINK WORKS!! > http://www.pachydermstudio.com/about/mindbender.exe > wnisltxzneehrvessbpgqskoqditkxwptmovmhixjwitlssdvlcsimrznufdfwwxxxkisorfiliy lgqwhdxlmbvydoeobz >Article: 21213
A case of the left hand not caring what the right hand is doing. As for the software, best I can tell it is pretty much new from scratch. Rickman wrote: > The question was not why did they not support it in the software. But > why did they bother to put it in the hardware if they weren't going to > support it in the software? Did somebody change their mind after the > silicon was drawn? > > Besides, they had to do the work for the Virtex chips anyway. If they > had put it in for the 4K parts, then it would already be there for the > Virtex parts. They didn't start from scratch for Virtex tools did they? > > Ray Andraka wrote: > > > > Because the software dweebs didn't want go through all the pain to add it to the > > tools, documentation, and support. > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21214
I'm with you on this Evan. As much as I whine about the bugs in the tools, Xilinx's tools are really pretty stable and reasonably bug free compared to the competition. IMHO, Xilinx really sets themselves apart with the level of technical support. The extensive on-line answers database should be a model for the others to emulate, including you folks with the synthesis tools. Additionally, the Xilinx hotline is very responsive. I always get a call back within a few hours of submitting a bug, and they do bend over backwards attempting to find a fix/work-around. If only the others had support that was even half what xilinx has... eml@riverside-machines.com.NOSPAM wrote: > BTW, any newbies reading this thread will probably come to the > conclusion that the software is bug-ridden and that reported bugs > aren't fixed. The IOB=TRUE is something I reported last year, and the > projected fix will be over 8 months later. On the other hand, next to > nobody will want to use this feature, and at least it will get fixed, > eventually. Just to add some balance, here are my experiences with 3 > other FPGA tool vendors and their technical support: > > Vendor #1: > I can't get through to the real vendor; I have to talk to the disti. > This is the kiss of death. There's nothing useful on the web site, and > I know more than the disti anyway. The in-detail documentation is > plain wrong. Two recent problems: the documented comment character in > a constraints file can't be used to start a comment. This is pretty > fundamental; nobody knows the reason. I'm eventually told to use a Tcl > script instead of a constraints file. > Second: there are two documented methods to carry out an important > procedure. Neither works, nobody knows why, I'm still waiting for an > answer (I suspect there isn't one) after some months. > > Vendor #2: > Vendor doesn't even have a website. Support from disti; see scenario > (1) above. I recently ask a question on a newsgroup (which is answered > by another user), vendor sees the question, instructs disti to mail me > with half-baked procedure; I don't even bother replying to him. > > Vendor #3: > Nothing useful on website. Disti wants to channel technical support. > However, I've reported several problems direct to the vendor, and I > always get someone who knows what they're talking about, and is > grateful for a bug report. However, there's no way to see anyone > else's bug reports, so you have to find them all for yourself. > > Go figure... > > Evan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21215
Hi, The current Spartan 2 datasheet (0.9) doesn't indicate that any parts are available in industrial temperature range versions. Does anyone know which parts are planned to be made available in this temperature range? The XC2S150 in the FG456 package is just perfect for my application, but I can't use a commercial temp range part. Thanks, Allan.Article: 21216
Actually, I went and checked. I did find one of them on there in answer 8229, which is pretty much a verbatim copy of my hotline inquiry...including the work-around. Unfortunately, the work around in that case didn't help me much because of the large number of RLOCs in the design. Ray Andraka wrote: > Not that I've seen. Probably because they don't have a workaround either. > > Rick Filipkiewicz wrote: > > > Ray Andraka wrote: > > > > > Bzzzzt. Nope, it's March, the Service Pack of the month this month is.... You > > > guessed it, Number 5. And they still don't have my show-stopper bugs from SP2 > > > fixed. > > > > > > -- > > > - > > > > Have they even put them on the answers database yet ? > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21217
Use the XCV150 if you need industrial range. Part of how they intend to keep spartan cheap is by limiting testing and packaging options. AFIAK, the XCV and XC2S are functionally identical. Allan Herriman wrote: > Hi, > > The current Spartan 2 datasheet (0.9) doesn't indicate that any parts > are available in industrial temperature range versions. > > Does anyone know which parts are planned to be made available in this > temperature range? > > The XC2S150 in the FG456 package is just perfect for my application, > but I can't use a commercial temp range part. > > Thanks, > Allan. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21218
Hi All, I encountered some problems when programming XC95216-CPLD's from Xilinx ; the elements themselves are part of a complete Boundary Scan chain. The complete environment is already tested over Boundary Scan, so I know the chain itself is ok, and there aren't very big errors around the CPLD. I don't dare to say it's completelly ok, I just don't have a clue anymore. (For the programming I use the Foundation Series JTAG Programmer) The programming and verifying is ok (are at least I don't get an error). The problem is when I want to get the checksum I get a different value every single time (only on 3 CPLD's out of 63). Does anybody know what can be wrong ? I already changed all three of them by new once, but still no difference (and I guess it can't be considered bad luck that the 3 new ones can be bad as well). How does the Checksum get verified by the way ? Is it a download of the info inside the CPLD, so that the JTAG-Programmer counts it itself, or is it a CPLD-internal process, after which the result comes out of TDO (I already checked with a Logic Analyser, and I guess there is too much traffic on TDO to be internal, but I'm not sure) Please answer - like it should be - on the newsgroup greetings, Alain Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21219
The TRI-FF _can_ be used with the SpartanXL and 4KX architectures. The reason that it is not automatic is due to the fact that the compiler for 4K architectures is different than for Virtex and you can see that when you run it. The s/w did not know about the feature, although you can see it in FPGA Editor, and generate a macro that you can then use in the source..... Please take a look at XAPP123. I have used this on many designs and it works fine.... Cheers, Dave Hawke. Xilinx UK. eml@riverside-machines.com.NOSPAM wrote in message <38c8ada4.462229@news.dial.pipex.com>... >On Wed, 8 Mar 2000 09:40:24 -0700, "Andy Peters" ><apeters.Nospam@nospam.noao.edu.nospam> wrote: > >>Ray Andraka wrote in message <38C64FE0.13682CCB@ids.net>... >> >>>AFAIK, the xilinx software still doesn't support the tristate register for >>4K >>>parts. >> >>And it won't be. One of the Xilinx apps guys sent me a private note about >>that. He said a Change Request was reported in September of last year, and >>it was "closed as Never Fix." > >isn't there an app note that says that you can use the tristate reg in >the XLA by using the map -pr option? doesn't this work? it seems >strange that someone wrote the note without testing it. > >the map option works on virtex, but unfortunately, last time i looked, >using an 'IOB=TRUE' attribute didn't work. this makes it impossible to >write a completely generic IOB component; i don't know if this has >been fixed yet. > >evan >Article: 21220
Incidentally, there's a solution record, app note, and a perl script regarding the utilization of the registered tri-state enable in the XL, XLA, and SpartanXLs. It can all be found here: http://support.xilinx.com/techdocs/5140.htm Carl Rohrer Allan Herriman wrote: > On Wed, 8 Mar 2000 09:40:24 -0700, "Andy Peters" > <apeters.Nospam@nospam.noao.edu.nospam> wrote: > > >Ray Andraka wrote in message <38C64FE0.13682CCB@ids.net>... > > > >>AFAIK, the xilinx software still doesn't support the tristate register for > >4K > >>parts. > > > >And it won't be. One of the Xilinx apps guys sent me a private note about > >that. He said a Change Request was reported in September of last year, and > >it was "closed as Never Fix." > > > >'tis a shame, because (IMHO) it's a damn useful feature. > > Am I missing something here? My '99 databook shows that the > 4000/Spartan parts do not have a register on the tristate control in > the IOB. Only the Virtex/Spartan2 parts have the register. > > Ta, > Allan.Article: 21221
Maybe
von Neumann, J. (1963).
Probabilistic logics and the synthesis of reliable organisms from unreliable components.
In Collected works, (Taub, A. H., ed.), vol. 5, pp. 341-342, The MacMillan Company, New York.
Mark Thorson wrote:
>
> I vaguely recall a paper with a title something like
> "On Building A Reliable System From Unreliable Nodes"
> by von Neumann. Does anyone remember that more clearly?
regards,
Tom Burgess
--
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
tom.burgess@hia.nrc.ca
Article: 21222Uma thread interessante de seguir... Holger Kleinert wrote: > > Hello All ! > > It's what the subject says... > > I am learning VHDL.... > I need expample VHDL files for Xilinx Foundation 2.1i , some which are > working .... > The Synopsys VHDL synthesis tool often produces very strange error > messages... > All 'generic' samples I used were not able to be systhesized. > I was not able to create a simple 8 bit counter.... > > I take every good link to a website who you can give me !!!! > Here I have postet the source code with a remark on the line which seems not > to be ok. > I do not understand why.... It is taken out of some sample code and articles > in a electronic magazine... > > Thank you for any help ot information. > > ************* > library IEEE; > use IEEE.std_logic_1164.all; > use IEEE.STD_LOGIC_UNSIGNED.all; > use IEEE.STD_LOGIC_ARITH.all; > > ENTITY count1 is > PORT > ( > clock : IN STD_LOGIC; > enable : IN STD_LOGIC; > qa : OUT STD_LOGIC_VECTOR (0 to 7) > ); > END count1; > > ARCHITECTURE Count1Arch of count1 is > BEGIN > VAR: PROCESS (clock) > VARIABLE count : INTEGER RANGE 0 TO 255; > > BEGIN > IF (clock'EVENT AND clock = '1') THEN > IF enable = '1' THEN > count := count + 1; > END IF; > END IF; > qa <= CONV_STD_LOGIC_VECTOR(count,8); -- This line produces an error > message on synthesis > END PROCESS; > END Count1Arch; > > ************* > > -- > Holger Kleinert > Development / Support > > IBP Instruments GmbH > Sutelstrasse 7a > D-30659 Hannover, Germany > > http://www.ibpmt.com > Fon : +49-511-652286 > Fax : +49-511-652283 -- ****************************************************************** Lino Marques Institute of Systems and Robotics Department of Electrical Engineering Phone: +(351) 239 796 277 University of Coimbra Fax: +(351) 239 406 672 3030 Coimbra E-Mail: lino@isr.uc.pt Portugal http://www.isr.uc.pt/~lino ******************************************************************Article: 21223
Looking for a Digital Design Engineer position or know of someone. Please email me your resume to resumes@m2recruiting.com Location: Palo Alto, CA Salary $100k+ Job Summary: A leading supplier of control network products and services that address the needs of the building, industrial, transportation, home, and other markets is looking for a Senior Digital Design Engineer. This Engineer will design the next generation of intelligent control and connectivity products, as well as sustain existing products. Hands-on board level design work. Responsible for all phases of the design cycle including specifications, scheduling, design, prototyping, test, debugging, documentation, and transfer to Manufacturing. Education/Experience: · Minimum 10 years engineering design experience · MSEE is desirable; BSEE is required · Required experience includes: embedded system architecture design, board level design, communications hardware, high-speed digital design, 32-bit microprocessors, CPU board design, memory, FPGA and CPLD design, simulation, environmental and EMC qualification. Skills: · Must be a self-starter, organized, and a team player. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21224
That people think Xilinx support is the best is pretty scary. I have used Xilinx tech support and although it has improved over the years, I think it is still in need of improvement. For people to say that it is the best available of all the FPGA vendors, I find disturbing. My current method for dealing with tech support is to not call. I try very hard to not push the capabilities of the tools or the parts and just plug ahead to find solutions myself. I only call support when there just does not seem to be an answer. I am often right. I guess my frustration with support centers around the way that they seem to use it as a training ground for new employees. I have spoken with people that don't know some very basic facts about the parts and also the software. So to get a complex question answered by having them relay questions and answers from the experienced engineers turns into a game of "telephone". Each iteration distorts the results a little more. I have had to ask the same question as many as 5 times before the person with the knowledge to answer it actually understood what was being asked. Too bad you can't get past the first level of support and speak directly with the engineers when your question requires it. Evan, is there a reason why you don't want to post names of companies with your experiences? I try to be honest with my experiences with vendors. A while back I had a very bad experience with Orcad and was not shy talking about it. This lead to an Orcad representative sending me an email asking me to try the newer version of the software. But they did not respond to any of my direct queries. I would like to know who the companies were that you had those problems with. I might want to use there products someday. Ray Andraka wrote: > > I'm with you on this Evan. As much as I whine about the bugs in the tools, > Xilinx's tools are really pretty stable and reasonably bug free compared to > the competition. IMHO, Xilinx really sets themselves apart with the level > of technical support. The extensive on-line answers database should be a > model for the others to emulate, including you folks with the synthesis > tools. Additionally, the Xilinx hotline is very responsive. I always get > a call back within a few hours of submitting a bug, and they do bend over > backwards attempting to find a fix/work-around. If only the others had > support that was even half what xilinx has... > > eml@riverside-machines.com.NOSPAM wrote: > > > BTW, any newbies reading this thread will probably come to the > > conclusion that the software is bug-ridden and that reported bugs > > aren't fixed. The IOB=TRUE is something I reported last year, and the > > projected fix will be over 8 months later. On the other hand, next to > > nobody will want to use this feature, and at least it will get fixed, > > eventually. Just to add some balance, here are my experiences with 3 > > other FPGA tool vendors and their technical support: > > > > Vendor #1: > > I can't get through to the real vendor; I have to talk to the disti. > > This is the kiss of death. There's nothing useful on the web site, and > > I know more than the disti anyway. The in-detail documentation is > > plain wrong. Two recent problems: the documented comment character in > > a constraints file can't be used to start a comment. This is pretty > > fundamental; nobody knows the reason. I'm eventually told to use a Tcl > > script instead of a constraints file. > > Second: there are two documented methods to carry out an important > > procedure. Neither works, nobody knows why, I'm still waiting for an > > answer (I suspect there isn't one) after some months. > > > > Vendor #2: > > Vendor doesn't even have a website. Support from disti; see scenario > > (1) above. I recently ask a question on a newsgroup (which is answered > > by another user), vendor sees the question, instructs disti to mail me > > with half-baked procedure; I don't even bother replying to him. > > > > Vendor #3: > > Nothing useful on website. Disti wants to channel technical support. > > However, I've reported several problems direct to the vendor, and I > > always get someone who knows what they're talking about, and is > > grateful for a bug report. However, there's no way to see anyone > > else's bug reports, so you have to find them all for yourself. > > > > Go figure... > > > > Evan > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com
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