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
Rickman wrote: <snip good stuff re PnP arbitration> > I am not sure, but I believe PCI also works this way. thanks for the indicators - one of these days I must swallow my pride and find out how PnP and PCI work.... > Sounds like a good way to go if you can afford the time to shift out the > ID number. But then if you are on a serial bus, it is a moot point. Depends what you are doing. Remember N bits can arbitrate among 2^N devices (the serial arbitration scheme is, after all, just a bit- serial magnitude comparison). 16 bits gets you a fair number of devices, 30 bits gets you more than you could dream of. 8 bits would do for a lot of industrial applications. Doesn't sound like too dreadful an overhead to me. CANbus exploits the arbitration number by making it carry some useful identity information too - OK, it limits your flexibility; but once again the application comes to the rescue - CAN is clearly intended to be a low-latency, lowish-throughput bus which is expected to be quite lightly loaded. So arbitration contests are rare, and it doesn't much matter that the arbitration priority is fixed by other considerations that aren't related to arbitration. I can easily imagine situations where that would be grotesquely untrue. Thanks again for the info. Jonathan BromleyArticle: 13376
iccra ¼g¹D¡G
> i have a problem of taget size of my VHDL project.
> i try to minimize a number of Altera Device's and Delay.
> but my synthesized VHDL Source is larger than Altera's compiled AHDL
> source and Top gdf.
>
> i wanna know Altera FloorPlan Editor and using method.
> thank you in advance.
If you want to reduce your resource, I suggest that your have to
considerate about your design architecture first. if you don't want to
change your architecture and your target system is focus on Altera
devices, I think, everybody knows,your coding adopt AHDL is better than
Altera's VHDL. If you want to change your coding let it after synthesis
output small than before, Notice some signal type, I suggest using
"subtype" to restract your signal range,you can get a better output.
Checking your bus width, 2^n is better. Try to change your design into
structured coding, I think that let your after synthesis output size is
very close AHDL coding . To see your synthesis constraint and try some
different synthesis method, If your target devices is FLEX series,
Synthesis style to choose the "FAST" option. generally, it let you get a
better output than " Normal" and " WYSIWYG". If MAX series devices, try
" multi. level synthesys" options, it can reduce your cell count, --but
you have to simulation your output more detail.Shared expander let you
can reduce your cell count and speed, Parallel expander let it grow up.
Floorplan editor can't reduce your cell count any more, but If you
have to fit your design cells or pins on specify locations ,please
reference your " Getting Start " first, and to learn how to assign your
pins on specify location on device view. To assign the cells on specify
cell location is very similar to pin assign,it defferent from pin assign
only work on LAB view, and assign object is cells not pins. of course,
you have to think about your routing resource first.
Good Lock!
Calvin.
Article: 13377>I cannot see how the continued push towards ever larger FPGAs matches >with what people actually design. I can see why the vendors do this: >they have absolutely nowhere else to go, except keep reducing prices >on existing parts until they all go bust. >But very few designs are 100k+ gates. Sure, the newsletters are full >of such examples, but those are invariably very high cost low volume >products where the device cost was almost immaterial. I know quite a >few people who design FPGAs for a living, and several firms who use X. >devices in very large numbers, and most of the designs are under 10k >gates. Anything in the 100k-1M gate region would represent a massive >project (in man-years), unless the device is stuffed with RAM or some >other regular structure. Our market research is showing four trends: 1) FPGAs will continue to follow Moore's law, much in the same way that DRAM have done. That means very large densities at extreamely attractive prices in the future. 2) The system-on-a-chip market (which is in it's infancy now, at least for FPGAs) will grow at a faster pace than the market at large. These parts require very large densities. 3) The FPGA market will continue to erode the classic ASIC market, and make continued inroads into those design wins. Interestingly enough, the opposite seems to be true as well, with ASICs making inroads into FPGAs in many cases. The division between ASIC and FPGA will continue to blur. 4) FPGA and ASIC vendors will, at some point, become commodity producers of gates. These companies will complete on delivery, price and (to a smaller extent) performance, but not so much on tools (which will become the realm of third party EDA vendors). Wade Peterson Silicore CorporationArticle: 13378
I just got off the phone with Xilinx support re a problem with FPGA Express creating an xnf which generated errors in the Xilinx tools. They said that editing the xnf to fix the error was the best solution. Is this normal? There's got to be a better way. BTW, I was going to try edif output as recommended in answer 2866 but neither I (nor support) know how to select edif output from Express! This is getting a little frustrating. SteveArticle: 13379
> I have to admit I haven't run > into a major problems with the M1 tools yet and all in all I like > them much better than XACT. I'm glad to hear that, but for me, the tools are sorely lacking in both features that previously existed, and performing their function as well as the previous tool set. AND that is very frustrating. >... The conversion > was something Xilinx had to do because, despite your (and my) > affinity for ppr, the old tools could never have supported the new > larger devices. Why not? AustinArticle: 13380
> ... Moore's law, ... Sorry, but I can't resist... It's not a law, it was an assertion. AustinArticle: 13381
Austin Franklin wrote: > > >... The conversion > > was something Xilinx had to do because, despite your (and my) > > affinity for ppr, the old tools could never have supported the new > > larger devices. > > Why not? > O.k., this is what Xilinx told me. Not an unbiased source I realize. But this came from two FAEs I've worked with a lot and I believe them. I think some of it was algorithmic. But I also got the impression the code for the old tools was a nightmare. I heard Xilinx never really ever had their own internal software team, at least not one with any continuity. I think they just brought in contractors as needed and the code become a big patchwork. NeoCAD, OTOH, was in the business of writing software and probably did a much better job of it. You already noted that the new tools are much faster and that may be a good clue as to how things would have gone if Xilinx had stuck with XACT. Anyone with factual knowledge about why Xilinx made this decision out there? Bob S. -- --------------------------- real addr: rsefton_@_home.com (remove the underscores) ---------------------------Article: 13382
"Austin Franklin" <dark4room@ix.netcom.com> wrote: > ... Moore's law, ... >Sorry, but I can't resist... >It's not a law, it was an assertion. >Austin Okay, okay...you're right. DRAMs (and other functions) have followed Moore's 'assertion' pretty closely, though. We think FPGAs will continue to follow the same trend, and eventually end up as commodities. By the way...'Murphy's law' is probably an assertion too, but I find that it works pretty consistantly. Wade Peterson Silicore CorporationArticle: 13383
I have projects for XC95xx that require more than 1.5Mb of disk space when I use Foundation archiving facility and my project is not that big to demand for such a space. Does somebody have suggestion on how to archive only the essencial files (btw which files?) Thanks in advanceArticle: 13384
"Austin Franklin" <dark4room@ix.netcom.com> wrote: > I disagree that NeoCAD was a problem. They (again) created a perception of > making a better router. Well, it really was only better under certain > circumstances....but when used with a design that was floorplanned, it was > NO better, in fact, sometimes worse. They designed it to handle regular > structures, and the Xilinx router did not handle them at all. The NeoCad router beat the pants off Xilinx on the chips I tried (even floorplanned). Also, the NeoCad router was better designed for large chips. The Xilinx software would have required huge amounts of memory and time for large chips. I'm still running NeoCad on 32 Meg. > All the rest of the NeoCAD tools were not really very good (say, the EPIC > editor.....). The NeoCAD 'vision' was to make a universal set of tools for > all programmable logic, NOT just 'another' tool for the Xilinx parts. I > don't believe their 'vision' was ever going to materialize, and the > acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD. It looked like a good vision to me. I bought the NeoCad Xilinx/Orca package because it cost the same as a second Xilinx seat and gave me a safe way to try Orca chips. I tried a couple of designs on both chips and haven't used Xilinx since. Xilinx had a lock on customers because of expensive development software. NeoCad was a leak on that, providing a path to other chips. Xilinx made an excellent move to buy NeoCad and plug that leak. If I could buy a universal development package today for the cost of another Lucent seat, I would. I might even try the new chips from Altera and Xilinx.Article: 13385
Bob Sefton <nobody@home.com> wrote: > O.k., this is what Xilinx told me. Not an unbiased source I > realize. But this came from two FAEs I've worked with a lot and I > believe them. I think some of it was algorithmic. But I also got > the impression the code for the old tools was a nightmare. I heard > Xilinx never really ever had their own internal software team, at > least not one with any continuity. I've heard the same thing. I think another issue was that since the NeoCad software was designed to support multiple device families and was written for NT and Unix, then it was much easier to adapt to new chips. Some of the Xilinx software was device-specific, and so took huge effort to port to new chips or new platforms.Article: 13386
nobody@replay.com "Anonymous" writes: <snipped a long rant, pitched to lighten a dull Monday morning> > ... heart-breaking stories with 8000, 6200, 5200 series! Does anyone in the know have a brief summary of the fate of the 5200? I guess that it was a good idea at the time, but the combination of the extra costs of another line of software and the sinking costs of 4000E silicon finished it off. Is it formally dead?Article: 13387
Bob Sefton <nobody@home.com> wrote: : What an absolute crock of shit. Save this crap for : misc.invest.stocks where somebody might buy into it. Unlikely - it's easy to ignore anonymous posters trying to diss companies - they could equally well be from the backers of the competition. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com It's not hard to meet expenses - they're everywhere.Article: 13388
> The Xilinx software would have required huge amounts > of memory and time for large chips. I'm still running NeoCad on 32 Meg. I have seen that too. I never really cared about memory use, so it wasn't as important to me as it would be to some... > > All the rest of the NeoCAD tools were not really very good (say, the EPIC > > editor.....). The NeoCAD 'vision' was to make a universal set of tools for > > all programmable logic, NOT just 'another' tool for the Xilinx parts. I > > don't believe their 'vision' was ever going to materialize, and the > > acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD. > > It looked like a good vision to me. I completely agree. > I bought the NeoCad Xilinx/Orca package > because it cost the same as a second Xilinx seat and gave me a safe way to > try Orca chips. I tried a couple of designs on both chips and haven't used > Xilinx since. Xilinx had a lock on customers because of expensive development > software. NeoCad was a leak on that, providing a path to other chips. Xilinx > made an excellent move to buy NeoCad and plug that leak. Valid point, but, er, cough, cough, isn't VHDL supposed to give you that ability today? I believe you still needed to buy the vendors tool set for each architecture.... > If I could buy a universal development package today for the cost of another > Lucent seat, I would. I might even try the new chips from Altera and Xilinx. Completely agree. I have a different way of doing 'universal' development. I create my designs using hierarchical symbols from my own library (er, Viewlogic). It contains all variants of registers, muxes etc, and all I need to create for a new technology is a new lowest order element (say, for a 32 bit register, I need to create a 1 bit register). Now I understand there are some items that are quite architecture dependant....so that takes a bit to do for each technology. This has worked fine for me for the past 8 years... AustinArticle: 13389
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1CAC.98EBEFB7 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Elder, =A0 I am using Microsoft SourceSafe to store Foundation Projects=20 (as well as Viewlogic projects). Most of Foundation files are binary, some are - text. But SourceSafe successfully handles all of them. =A0 At the end of this message please see the list of the files,=20 which should be kept in SourceSafe for the sample=20 project: "exdXPa". =A0 There are several useful tricks: =A0* Synopsys EXP-files should be explicitly declared =A0=A0 as binary files for MS SourceSafe. =A0=A0 For the rest of XILINX-related files SourceSafe's=20 =A0=A0 automatic binary/text distinguishing works well. =A0* use NTFS system (WinNT) with compression=20 =A0=A0 enabled for SourceSafe DATA directory =A0=A0 Win95 compressed volume can also do the job =A0* use PKZIP to save the whole SourceSafe database =A0=A0 on removable media =A0* use SSARC utility (part of SourceSafe) to=20 =A0=A0 reduce database size and to save very old versions=20 =A0=A0 of your design =A0* if needed, delete your local copy of the project =A0=A0 as soon as you are sure, it was checked into SourceSafe =A0=A0=20 =A0 Regards, =A0=A0 Alex Sherstuk =A0=A0=A0=A0=A0 sherstuk@amsd.com <mailto:sherstuk@amsd.com>=20 =A0=A0=A0=20 =A0-------- =A0 Here is the list of files for the sample Foundation project:=20 =A0 $/EXD/XIL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Root directory for XILINX = chips,=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 related to EXD = card=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exdXLc.pdf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Project definition file for = "exdXLc" chip exdXPa.pdf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Project definition file for = "exdXPa" chip $/EXD/XIL/exdXPa=A0=A0=A0 Project directory ARCV.xnf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Results of VHDL synthesis for = the ARCV macro ARCV.xsf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Input and output signal names = for the ARCV macro AXMT.xnf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Results of VHDL synthesis for = the AXMT macro AXMT.xsf=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Input and output signal names = for the AXMT macro exdXPa.ncd=A0=A0=A0=A0=A0=A0=A0=A0=A0 Result of XILINX chip routing exdXPa.ucf=A0=A0=A0=A0=A0=A0=A0=A0=A0 Design constraints exdXPa1.SCH=A0=A0=A0=A0=A0=A0=A0=A0 Schematics, sheet 1 exdXPa2.SCH=A0=A0=A0=A0=A0=A0=A0=A0 Schematics, sheet 2 LOGIBLOX.INI=A0=A0=A0=A0=A0=A0=A0 Saved settings for the LogiBLOX tool $/EXD/XIL/exdXPa/EXPRESS=A0 Root directory for VHDL subproj for exdXPa $/EXD/XIL/exdXPa/EXPRESS/ARCV=A0=A0=A0 VHDL subproject for ARCV macro ARCV.EXP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 VHDL (Synopsys) project description ARCV.VHD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 VHDL source text for the ARCV macro $/EXD/XIL/exdXPa/EXPRESS/ARCV/FILES=A0=A0=A0=A0=A0=A0=A0=A0 empty = directory structures $/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS=A0=A0=A0=A0=A0 empty directory = structures $/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS/WORK empty directory structures $/EXD/XIL/exdXPa/LIB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 "ad hoc" symbols (Library) EXDXPA.BLK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 all library files EXDXPA.DIR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 must be stored EXDXPA.FIG=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in SourceSafe EXDXPA.FLG=20 EXDXPA.GNR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.HDR=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.ID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.INI=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.MAP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.MOD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.NET=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.PIN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.SYM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.SYN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 EXDXPA.VIS=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 =A0 =A0 -----Original Message----- From: Elder V Costa [ mailto:elder@dixtal.com.br <mailto:elder@dixtal.com.br> ] Posted At: Monday, November 30, 1998 10:43 PM Posted To: comp.arch.fpga Conversation: Archiving Xilinx Foundation Projects Subject: Archiving Xilinx Foundation Projects I have projects for XC95xx that require more than 1.5Mb of disk space when I use Foundation archiving facility and my project is not that big to demand for such a space. Does somebody have suggestion on how to archive only the essencial files (btw which files?) Thanks in advance ------_=_NextPart_001_01BE1CAC.98EBEFB7 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dwindows-1251"> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY> <DIV><BR><FONT color=3D#0000ff size=3D2>Hi Elder,</FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2>I am using Microsoft SourceSafe to = store=20 Foundation Projects <BR>(as well as Viewlogic projects). Most of = Foundation=20 files<BR>are binary, some are - text. But SourceSafe = successfully<BR>handles all=20 of them.</FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2>At the end of this message please = see the list=20 of the files, <BR>which should be kept in SourceSafe for the sample = <BR>project:=20 "exdXPa".</FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2>There are several useful = tricks:<BR> *=20 Synopsys EXP-files should be explicitly declared<BR> as = binary files=20 for MS SourceSafe.<BR> For the rest of XILINX-related files = SourceSafe's <BR> automatic binary/text distinguishing = works=20 well.<BR> * use NTFS system (WinNT) with compression = <BR> =20 enabled for SourceSafe DATA directory<BR> Win95 compressed = volume=20 can also do the job<BR> * use PKZIP to save the whole SourceSafe=20 database<BR> on removable media<BR> * use SSARC = utility (part=20 of SourceSafe) to <BR> reduce database size and to save = very old=20 versions <BR> of your design<BR> * if needed, delete = your local=20 copy of the project<BR> as soon as you are sure, it was = checked into=20 SourceSafe<BR> </FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2>Regards,<BR> Alex=20 Sherstuk<BR> <A=20 href=3D"mailto:sherstuk@amsd.com">sherstuk@amsd.com</A><BR> &= nbsp;=20 <BR> --------</FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT><FONT=20 face=3D"Courier New"></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier New">Here is = the list of=20 files for the sample Foundation project: </FONT></FONT><FONT=20 face=3D"Courier New"></FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier = New"></FONT></FONT><FONT=20 face=3D"Courier New"></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2><FONT=20 face=3D"Courier = New">$/EXD/XIL &nbs= p;=20 Root directory for XILINX chips,=20 <BR> &n= bsp; &n= bsp; =20 related to EXD=20 card &n= bsp; =20 <BR>exdXLc.pdf = Project=20 definition file for "exdXLc"=20 chip<BR>exdXPa.pdf = Project=20 definition file for "exdXPa"=20 chip<BR>$/EXD/XIL/exdXPa Project=20 directory<BR>ARCV.xnf &nb= sp; =20 Results of VHDL synthesis for the ARCV=20 macro<BR>ARCV.xsf &= nbsp; =20 Input and output signal names for the ARCV=20 macro<BR>AXMT.xnf &= nbsp; =20 Results of VHDL synthesis for the AXMT=20 macro<BR>AXMT.xsf &= nbsp; =20 Input and output signal names for the AXMT=20 macro<BR>exdXPa.ncd  = ; Result=20 of XILINX chip=20 routing<BR>exdXPa.ucf &nb= sp;=20 Design=20 constraints<BR>exdXPa1.SCH &nbs= p;=20 Schematics, sheet=20 1<BR>exdXPa2.SCH = Schematics,=20 sheet 2<BR>LOGIBLOX.INI Saved = settings=20 for the LogiBLOX tool<BR>$/EXD/XIL/exdXPa/EXPRESS Root directory = for VHDL=20 subproj for exdXPa<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV = VHDL=20 subproject for ARCV=20 macro<BR>ARCV.EXP &= nbsp; &= nbsp; =20 VHDL (Synopsys) project=20 description<BR>ARCV.VHD &= nbsp; &= nbsp; =20 VHDL source text for the ARCV=20 macro<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/FILES &nbs= p; =20 empty directory=20 structures<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS &n= bsp; =20 empty directory = structures<BR>$/EXD/XIL/exdXPa/EXPRESS/ARCV/WORKDIRS/WORK empty=20 directory=20 structures<BR>$/EXD/XIL/exdXPa/LIB &n= bsp; &n= bsp; =20 "ad hoc" symbols=20 (Library)<BR>EXDXPA.BLK &= nbsp; &= nbsp; &= nbsp;=20 all library=20 files<BR>EXDXPA.DIR  = ;  = ;  = ;=20 must be=20 stored<BR>EXDXPA.FIG &nbs= p; &nbs= p; &nbs= p;=20 in SourceSafe<BR>EXDXPA.FLG=20 <BR>EXDXPA.GNR &nbs= p; &nbs= p; =20 <BR>EXDXPA.HDR &nbs= p; &nbs= p; =20 <BR>EXDXPA.ID  = ;  = ; =20 <BR>EXDXPA.INI &nbs= p; &nbs= p; =20 <BR>EXDXPA.MAP &nbs= p; &nbs= p; =20 <BR>EXDXPA.MOD &nbs= p; &nbs= p; =20 <BR>EXDXPA.NET &nbs= p; &nbs= p; =20 <BR>EXDXPA.PIN &nbs= p; &nbs= p; =20 <BR>EXDXPA.SYM &nbs= p; &nbs= p; =20 <BR>EXDXPA.SYN &nbs= p; &nbs= p; =20 <BR>EXDXPA.VIS &nbs= p; &nbs= p; =20 </FONT></FONT><FONT face=3D"Courier New"></FONT></DIV> <DIV><FONT color=3D#0000ff size=3D2><FONT face=3D"Courier = New"></FONT></FONT><FONT=20 face=3D"Courier New"></FONT> </DIV> <DIV><FONT color=3D#0000ff size=3D2></FONT><BR> </DIV> <P><FONT size=3D2>-----Original Message-----<BR>From: Elder V Costa [<A = href=3D"mailto:elder@dixtal.com.br"=20 target=3D_blank>mailto:elder@dixtal.com.br</A>]<BR>Posted At: Monday, = November 30,=20 1998 10:43 PM<BR>Posted To: comp.arch.fpga<BR>Conversation: Archiving = Xilinx=20 Foundation Projects<BR>Subject: Archiving Xilinx Foundation=20 Projects<BR><BR><BR>I have projects for XC95xx that require more than = 1.5Mb of=20 disk space<BR>when I use Foundation archiving facility and my project = is not=20 that big<BR>to demand for such a space. Does somebody have suggestion = on how=20 to<BR>archive only the essencial files (btw which files?)<BR><BR>Thanks = in=20 advance<BR></FONT></P></BODY></HTML> ------_=_NextPart_001_01BE1CAC.98EBEFB7--Article: 13390
Peter <z80@ds2.com> wrote: [Re: moving to ever larger FPGAs will not provide future growth...?] : I cannot see how the continued push towards ever larger FPGAs matches : with what people actually design. I can see why the vendors do this: : they have absolutely nowhere else to go, except keep reducing prices : on existing parts until they all go bust. Power consumption, size and speed are also factors in need of attention. FPGA manufacturers will need to design their chips using reversible logic in the long term to cope with the former. They may well be better positioned to do this than traditional processor manufacturers. I'd rather have computing machinery that went twice as fast than twice as much of it. : But very few designs are 100k+ gates. [...] Prototyping designs by hand is one thing, evolving populations of designs is quite another. People involved in evolutionary strategies on FPGAs may not currently constitute a large segment of the market, but they are one that will never be at a loss for what to do with more speed, or more gates. : I don't think Xilinx will go bust. [...] Indeed - I suspect only trolls would suggest otherwise. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Terminal error. You're dead.Article: 13391
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1CAD.53477E7B Content-Type: text/plain; charset="koi8-r" By the way, editing an XNF file appears also to be a simple method for keeping different timing constraints for several Express macros belonging to one project. ------_=_NextPart_001_01BE1CAD.53477E7B Content-Type: text/html; charset="koi8-r" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>Editing XNF file</TITLE> </HEAD> <BODY> <P><FONT SIZE=2>By the way, editing an XNF file appears also to be a </FONT> <BR><FONT SIZE=2>simple method for keeping different timing constraints for</FONT> <BR><FONT SIZE=2>several Express macros belonging to one project.</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01BE1CAD.53477E7B--Article: 13392
Yes. That's the simple answer to your question. Xilinx has good silicon products and I don't blame them that I have to buy an HDL compiler from Exemplar or Synplicity and a simulator from ModelTech in order to get a good development environment. A more self-serving company would try to kill third-party software vendors, but as far as I can tell, Xilinx has a good relationship with these vendors. This assures their continued success as an IC manufacturer. Don't worry, Altera will be fine too. A more interesting (sad though it may be) question is whether the other manufacturers will survive on their own, like Vantis, Lattice, Actel, Quicklogic, Atmel, et al. Too bad you don't have the cojones to sign your message, we would have enjoyed looking up your number in the Altera telephone listing. Anonymous wrote in message <199811290840.JAA25405@replay.com>... >This thought should be worrying not only XILINX shareholders, >but also, - XILINX users, who have invested a lot of efforts >and money into mastering XILINX tools. > >Why should we expect XILINX shutdown in the foreseeable future? > >1) XILINX has started as successful innovative company and won >essential part of the market. But that's in the past ... >Recent history of XILINX is a sequence of disastrous failures >to deliver satisfactory quality at reasonable price. >Remind heart-breaking stories with 8000, 6200, 5200 series! >Lacking new ideas, XILINX is trying to sell their old 4000 >series wrapped into Spartan envelope. And now Virtex becomes >too late answer on Altera designs. > >2) XILINX applies tremendous efforts to reduce the price and ... >the quality of its development tools. >It was reported by many customers in this particular newsgroup >that XILINX Foundation is worse than XACT, and each subsequent >version of Foundation is worse than previous. >Currently the quality of development tools is so bad that XILINX >almost gave up any attempts to fix endless stream of bugs. >The bugs are just stored until next version of Foundation : > >3) XILINX support service became some sort of psychoanalyst to >keep users calm and to avoid bodily damage (and chip damage) >caused by desperate customers. XILINX is afraid to reveal >an obvious thing: there is no support for ALDEC software >that constitutes the principal part of Foundation (design flow, >schematics and simulation). > >4) And now the last news: >MARSHALL does not sell XILINX chips any more. >Obviously, they are feeling where the things go. > >Good bye XILINX ... > >************* > > >Article: 13393
comp.arch.fpga: 30-Nov-98 Re: Will XILINX survive? by Wade D. Peterson@maroon. > Our market research is showing four trends: > > 1) FPGAs will continue to follow Moore's law, much in the same way > that DRAM have done. That means very large densities at extreamely > attractive prices in the future. > > 2) The system-on-a-chip market (which is in it's infancy now, at least > for FPGAs) will grow at a faster pace than the market at large. These > parts require very large densities. > > 3) The FPGA market will continue to erode the classic ASIC market, and > make continued inroads into those design wins. Interestingly enough, > the opposite seems to be true as well, with ASICs making inroads into > FPGAs in many cases. The division between ASIC and FPGA will continue > to blur. > > 4) FPGA and ASIC vendors will, at some point, become commodity > producers of gates. These companies will complete on delivery, price > and (to a smaller extent) performance, but not so much on tools (which > will become the realm of third party EDA vendors). What about reconfigurable computing and systems-on-a-chip with programmable logic on the same die? Something like a processor core and an FPGA on the same chip with some an interface for the two to communicate with each other. That way if you need basic general processing abilities along with some custom logic, this might allow you to build a smaller, cheaper, faster implementation than current processor/FPGA combinations. I'm no expert but these are two possibilities I've heard. - FroilanArticle: 13394
The FPGA Design Center provides the followings services:
(I) FPGA to ASIC conversion:
(1) Fastest time to market: 4-8 weeks for production and prototype
(2) Low NRE charges
(3) Highest quality and world-class manufacturing
(4) Fast production
(5) Technologies: 20K gates/mm2 in 0.35 micron
(II) FPGA Design Services:
(1) HDL Synthesis (VHDL and Verilog)
(2) FPGA Implementation
(3) IP Cores libraries, such as FFT engine, decimate-by-N FIR
engine, FEC engine, Turbo Codes engine, Multipliers, etc..
(4) Quick-Turn and friendly services
--
===========================================================
Michelle Tran IComm
Technologies, Inc.
icommtek@fpga-design.com http://www.fpga-design.com/
===========================================================
Article: 13395Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds like a good FAE Challenge. http://www.actel.com/products/devices/SX/chall.html Steve wrote: > I'm interfacing to a Motorola MPC 860 @50Mhz. I need to provide an > acknowledge signal in <10ns after the Clock. To do this my PLD/FPGA > needs to have a (Clk-Q + comb delay + tristate enable) < 10ns. > > So far I haven't found a CPLD to do it. What small FPGA's have the best > crack at it??? ... or prove me wrong on the CPLD issue? > > So far my only practical solution is an XCS05XL-4. > > Comments? > > SteveArticle: 13396
got a few minutes, ran a quick design (schematics), sim (viewsim)
here's what i got:
1. used a54sx16/pl84 - released r2-1998 s/w doesn't have entry for a54sx08,
unless there's a patch that i missed
2. temp = 70C
3. voltage = 3.0V
4. fully automagic place and route
5. regular layout [not timing driven]
6. pin to pin delays: clkpin -> clock buffer -> flip-flop -> tri-state enable
-> outpin
i don't know what the comb delay in original post was
7. i used hclk, the faster clk
8. trivially makes 100 MHz, path through output enable:
std die = 7.7 ns
-1 die = 6.6 ns
-2 die = 5.8 ns
9. have the actelians donate watch to charity, i don't wear 'em
10. lots of fast fpga's out there, i have these tools at home, so i ran them:
which is "world's fastest fpga?"
rk
========================================================
Daniel K. Elftmann wrote:
> Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds
> like a good FAE Challenge.
>
> http://www.actel.com/products/devices/SX/chall.html
>
> Steve wrote:
>
> > I'm interfacing to a Motorola MPC 860 @50Mhz. I need to provide an
> > acknowledge signal in <10ns after the Clock. To do this my PLD/FPGA
> > needs to have a (Clk-Q + comb delay + tristate enable) < 10ns.
> >
> > So far I haven't found a CPLD to do it. What small FPGA's have the best
> > crack at it??? ... or prove me wrong on the CPLD issue?
> >
> > So far my only practical solution is an XCS05XL-4.
> >
> > Comments?
> >
> > Steve
Article: 13397I agree with Wade's statement: >>I cannot see how the continued push towards ever larger FPGAs matches >>with what people actually design. What is the difference between a 500k/1M gate FPGA design and an ASIC in terms of design time and time to market? Not much that I can see. An FPGA will always be slower and consume more power than the ASIC. Why re-invent the wheel for 75% of a 1M gate FPGA design that uses common cores/interfaces/functions in support of, on average 25% of the design for actual custom IP requiring re-programmable logic? Devices of that size do not show me any enhanced value from a designer's perspective. >2) The system-on-a-chip market (which is in it's infancy now, at least >for FPGAs) will grow at a faster pace than the market at large. These >parts require very large densities. I agree. The densities will need to be very large to implement standard cores in FPGA logic and still have programmable logic left over to do something custom with. That is why I believe that the only vendor who, to date, has actually displayed the ability to merge ASIC cores (dedicated silicon) with surrounding FPGA logic is Lucent Technologies (ORCA). That is what I would define as true "systems on a chip"; not just a bigger array block. They seem to have the designers in mind. >3) The FPGA market will continue to erode the classic ASIC market, and >make continued inroads into those design wins. Interestingly enough, >the opposite seems to be true as well, with ASICs making inroads into >FPGAs in many cases. The division between ASIC and FPGA will continue >to blur. > Absolutely. >4) FPGA and ASIC vendors will, at some point, become commodity >producers of gates. These companies will complete on delivery, price >and (to a smaller extent) performance, but not so much on tools (which >will become the realm of third party EDA vendors). If just producing larger arrays of the same ( although renamed) architecture is the direction X and A are going to take, then FPGAs will become as you put it "... become commodity producers of gates." However, I do not believe it will be reduced to quite that simplistic a level (e.g.. DRAMS). Just because a lot of gates fill a device does not qualify it as ASICish (forgive my new word). I feel it would be a mistake for the marketing departments of the FPGA vendors to promote their larger devices as ASIC like. To do so would insult the intelligence of most designers (I hope). FPGAs are used to implement specific system capabilities as do ASICs. I believe we are in store for the usual ASIC bidding wars with an FPGA twist. The vendors that can successfully merge the technologies will offer true value and will set themselves apart from the traditional FPGA/ASIC vendors. Mike.Article: 13398
Here is my oppinion (in response to your bullets). 1. Virtex looks pretty hot to me. According to our local (biased) rep the Xilinx tools will support Virtex long before Altera gets their software up with their new parts and I believe him. 2. I have experienced numerous bugs with Xilinx tools but always seem to get my work done on time. 3. Xilinx support is the best I've experienced in the last ten years from an EDA vendor. Their support people have always worked hard to find me an answer to my question. They seem to be the only company that can pass you from one technical person to the next without losing continuity and the original support person has always followed up to see that I was properly helped. And yes, like all vendors, they have told me, "wait until the next release". 4. Who cares about Marshall? 5. Goodbye Anonymous. IMHO: Xilinx Epic (even when buggy) makes it possible to make design tweaks without total recompilation. That is a GIANT plus when working on big parts. A compatriot was completely stymied by the Altera tools working on a 4062 size design when he couldn't make a few quick bug fixes with an Epic like editor. If you are trying to do a reasonable size FPGA design (> 50k gates) then Epic can cut hours and hours off your design cycle by letting you experiment with a possible problem solution. -- Tim Davis Timothy Davis Consulting TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023 +-------------------------------------------------------------------+ : Engineering is like having an 8 a.m. class and a late afternoon : : lab every day for the rest of your life. : +-------------------------------------------------------------------+Article: 13399
Tim Tyler (tim@BITS.bris.ac.uk) wrote:
: Bob Sefton <nobody@home.com> wrote:
: : What an absolute crock of shit. Save this crap for
: : misc.invest.stocks where somebody might buy into it.
: Unlikely - it's easy to ignore anonymous posters trying to diss companies
: - they could equally well be from the backers of the competition.
Or from a disenchanted employee wanting to get the "truth" out and fearing
reprisals.
Me, I'm looking for any frank discussion (anonymous or not; scattershot or
not), as I'm on the verge of selecting Xilinx for a new design.
--
jonathan@canuck.com
Canada Connect Corporation | Jonathan | Survival Research Laboratories
Calgary, AB | Levine | San Francisco, CA
403-705-2025, fax 2026 vox/fax 415-641-8065
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