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
rk wrote: > > rk: > : > > : > unix versions of software have traditionally cost far more than the > dos/win > : > versions. yes, same code and all (in principle). but it is a > different > : > market. and, i believe, it will continue to be a different market. > > rk: > one little paragraph generated a large response! ok, let's move ahead. Actually, there were a whole bunch of others, but I thought this was a good summary. I also admit to artificial pricing barriers being a hot-button of mine. > rick kwan: > : The embedding of posts were getting kinda long, so I'll > : apologize up front. > : > : Pricing. This is an interesting artificial, obsolete separator > : between UNIX and PC platforms. I am arguing here for equivalent > : application pricing for UNIX and NT systems. > > rk: > me argues for lowest pricing period, regulated by the laws of supply and > demand and competition. and what helps this is avoiding proprietary > formats and tools to avoid getting locked in. a nice example is edif. now > i can generate an edif netlist from any number of different tools from a > number of different manufacturers, and, as an example, move it into > viewlogic, run my low level logic simulations, cut another composite > netlist, pop into my p&r tool, and i'm off and running. typically, i take > 3 different types of input and put it into my designs (schematic, macro > generators, and vhdl). and edif is the glue that makes it happen. if a > tool is too expensive, then i have the choice to possibly go with some > other manufacturer. like the mentor $35,000 station vs. the orcad $500 pc > package for card-level design and netlisting from a while back. and there > are a number of companies in between. > > obviously, sales volumes will make prices drop, since the design and > maitenance cost of a tool are fixed per version but the manufacturing costs > are really quite low. support costs should be linear w.r.t. the # of > users. if the tools are well designed and has good doc the support costs > should be low and the users happy. and we're all happy, > right?!?!?!?!?!?!?!?!?! Ummm... yeah... we assume somewhere that they can easily fit into an automated design flow. > rick kwan: > : With PCs, this model has broken down. PC manufacturers > : want us to believe that their machines perform as well as > : traditional worktations. Furthermore, today you might have > : a 150 MHz machine; tomorrow, it might be 333 MHz. You can no > : longer base a software license fee on machine power. > > rk: > well, i run on both unix and pc but don't think the two are equivalent. > they're not. but if the pc is good enough for an app, and some studies > have shown better performance / $, then it makes sense. it won't make > sense for the million gate asics. but it probably will for 100,000 gates > and less. and for < $1k, you can go down to the store, pick up a new > motherboard and cpu and memory, and have something that really flies. lots > of m-board competition, and with the amd k6 and others, there's getting to > be some real competition for cpu slots. and the cpu market is now > unbelievable w.r.t. performance and it's accellerating, with prices > dropping. intel can no longer decide when to put out a new cpu and control > pricing. somebody else will come along and beat them. I agree that in hardware, they are not equivalent. (Some are going to argue with that.) It use to be that in OS, they were not equivalent either. However, with current robust implementations of POSIX, that machine for < $1K can now run a workstation OS; and if you put it on an Ethernet, it might as well be a full-fledged workstation. > an interesting aside. you can go down to the local hole in the wall shop > and pick up a m-board+cpu that runs at 333 MHz. that's a 3 nanosecond > cycle time. here's a quote from one of my architecture books, (c) 1980. > > ... we cannot fail to mention that the clock cycle of 12.5 nS could only > be achieved through some amazing technological advances in LSI ... and the > cooling system. ... > > this is a description of the cray-1 supercomputer. But the 333 MHz machine doesn't come with a love seat! (Forget the love seat; I'll take the one with the sofa. ;-) > <snipped lots of good stuff> > > i don't think unix or linux or domain or win '95 or win nt or dos (yes, > people still do good engineering in dos) or exec 8 or rt-ll or vms or mvs > or whatever is really what's important. > > it's staying away from proprietary models that lock you in. a good healthy > market with competition will lower prices while improving efficiency and > performance. some comapnies will want to stay on top. and startups will > want to take the market and money away from them. gotta beat the standard > and convince people to change. Basically, I think I agree. But there is perhaps a difference of perspective here. I have been assuming a team of multiple designers, or perhaps even multiple teams. In that case, automating design flows and having strong underlying network infrastructure is important. If your team is very small and you are CPU-bound, then lots of things are equalized. However, even in small networks, if you are or have a systems wiz around, automation on a UNIX/Linux network comes very cheaply.Article: 9326
>No revision control ? No batch mode ? I don't use revision control. I have used PVCS and it is OK, but frankly I don't trust some *program* to be diving into my source files and inserting various bits of text in them. When I finish a particular version, I back up the *whole* project to optical, and/or CD, and tape. >Most of the cpu and time consuming jobs here are done by batch >(shell scripts, etc) overnight, e.g. Synthesis, ATPG, Simulations, >Analysis, etc. Under DOS, one uses .bat files. I still use DOS a lot. In Viewlogic 4 (DOS) one can run simulations using .cmd scripts - this is probably the same on the unix versions. I have often run overnight simulations, although this is less common with P200+ machines. Under windoze, batch processing is much more difficult if the app does not have some sort of script language built-in, and this is partly why I like the old DOS (or DOS box) tools. There are "automation" tools for NT but I have not used them. If you mean what I think you mean, you certainly have a point, but not an NT-specific one. What has happened too often is that when EDA apps moved to windoze, they lost nice features like command line entry, and being able to run in batch mode. This is stupidity on the part of the developers, because once one knows what one is doing, a keyboard is much faster to use than doing click click click click click click click with the mouse. The other related problem is that if there is no scripting facility, it becomes much more difficult to maintain a project over several years. Take today's trendy Integrated Development Environments. All the compiler & linker options are set via the GUI. One can no longer open an old project and just type MAKE to rebuild it. But again this is nothing to do with NT. >Don't tell me that you turn your PC off overnight (perhaps to get >your NT free off memory leaks ;)) and thus waste a lot of time ... :) >> VI is for masochists :) >Or for those who need a small and fast editor and don't want to >lose time by moving their hands to the mouse and back during >touch typing, e.g. to copy just one line :). Brief? I know several people who went from unix to DOS/etc and all now use Brief - years after its development was abandoned. I have used VI - it is OK but not a patch on Brief. Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 9327
On 6 Mar 1998 11:51:14 GMT, rk <rich.katz@gsfc.nasa.gov.NOSPAM> wrote: > >if Linux *is* a UNIX, can i just go down to the local synopsys store, >order me up a copy of UNIX synopsys, drop in the cd onto my linux/x86 >portable machine, and start running? You are obfuscating the issue here. Just because you run UNIX doesn't mean the underlying hardware is the same. Can I take an NT application compiled on the Alpha and run it on the PC? >hmmm ... just a little old engineer here, but i seem to remember, let me >know if it's not true, that s/w needs to be written or tweaked for >different versions of unix. can i take code from an hp box and run it on >a sun box, or a dec box, or a ibm box, or an cray box, or a silicon >graphics box (haven't followed these two too close since merger) or a >xenix box? anyways, that's s/w portability. Software is very portable when it is written to adhere to standards that all vendors support and requires very little/no "tweaking" as you say. For example, software written in ANSI C is highly portable. XFree86 is available on FreeBSD, Linux, LynxOS, NetBSD, OpenBSD, OS/2, SCO, Solaris x86, and SVR4 which are all quite different OS breeds. The newsreader SLRN and the Mutt mailer compile on just about any UNIX imaginable regardless of the underlying hardware architecture. Now as to why Synopsys doesn't cut a release Design Compiler on Linux is another story. That has a lot of baggage in it, and chances are they didn't care a lot about portability when it was first written. We'd have to see their software development process in a little more detail to ascertain the cause. -ClintArticle: 9328
Allan Redenbaugh <allan@ti.com> wrote in article <6dpdnk$n8o@sf18.dseg.ti.com>... > Given the following code for a control register where a single bit has to > have > a seperate async reset : > (target device = Xilinx 4ke) > > process ( strobe, reset, clear_bit0) > > begin > if reset = '0' then > cntl_reg <= DEFAULT_REG; > elsif clear_bit0 = '1' then > cntl_reg(0) <= DEFAULT_REG(0); > elsif strobe'event and strobe = '1' then > cntl_reg <= data; > end if; > end process; > > I assign reset to GSR so I expect clear_bit0 to drive the reset line of a > dff > on bit 0 and the reset of the register bit to only have the GSR reset. > > My synthesis tool (Leonardo) says that since I have nothing defined for the > upper bits under the clear_bit0 condition it defaults to a preset which is > not what I inteded. > > I have pulled out bit 0 into its own process and everythings happy, I just > don't > understand why this method doesn't work. Because the code doesn't specify what should happen to cntl_reg(1 to n) when reset = '1' and clear_bit0 = '1'; The value of each output of the process must be defined for all combinations of the sensitivity list. Since all the bits of cntl_reg are outputs, then they must all be defined for each elsif. I think it would have worked like this: begin if reset = '0' then cntl_reg <= DEFAULT_REG; elsif clear_bit0 = '1' then cntl_reg(0) <= DEFAULT_REG(0); cntl_reg(1 to n) <= cntl_reg(1 to n); -- replace n with actual number. elsif strobe'event and strobe = '1' then cntl_reg <= data; end if; end process; -- Rich Iachetta IBM Corporation iachetta@us.ibm.comArticle: 9329
Phil Ptkwt Kristin wrote: > > In article <01bd4897$2b62d1c0$2985accf@homepc>, > rk <stellare@erols.com.NOSPAM> wrote: > >peter: > >: :There are lots of stupid things in NT but none of them make it in any > >: ;way unsuitable for EDA. > > > >wen: > >: Oh yes. For one, it prevents me from using the tools if I am not sitting > >: in front of of the machine. > > > >rk: > >solution: sit in front of the machine. > > Not always possible. For example if you can't make it into work because > of an ice storm, you can (if you're running Linux at home) establish a ppp > connection with a system at work and set your display to your home system > (assuming you're running some kind of Unix at work) and do a reasonable > amount of work. We gave up on that. Telnet works, but X is pretty much unacceptable, even over a good (28.8) connection. Let me state _clearly_ that a simple X terminal works fine, but when I have to run the tools I use in my job, whether it is a VHDL simulator or a schematic editor, we find that we need LOTS of bandwidth. The schematic software we run is completely unacceptable using X. Even with ISDN, it's marginal. Editing a simple schematic is at least an order of magnitude slower over ISDN than running locally (and we complain about the speed when we run locally). == Note: Don't argue yet - read the next paragraph == But, we do have an acceptable solution - use NT. We run an X emulator on an NT server, then dial up to that remotely. The NT server runs Citrix' WinFrame Server, and that converts the (apparently remarkably inefficient) X into a reasonably efficient system. Over a 28.8 line, the performance is marginal, but over ISDN, it's quite acceptable, even for our schematic editor. Note that even though I said the solution is to use NT, it's because that's what the solution, Citrix WinFrame, runs on. It's not that NT is so much better - it's that WinFrame is. There doesn't appear to be anything limiting X from performing as well as WinFrame - but so far it doesn't. So, I run Win95, start up the WinFrame client, dial into an NT server, start up an X emulator, connect to my Unix workstation, and run my application. Sounds complicated, but it sure beats any other solution we've ever seen. > Sure, not being tied to the network might make it easier to take you > laptop on the plane and work on a design, but the need for this is only > 2-3 times a year for most of us. > The disadvantages of not being tied to a network greatly outweigh the so > called advantages (especially if you have multiple people on a project). > Well, the tools for running remotely with Linux are free. You get > XWindows which allows you to do this sort of thing. Now there is > something called VNC (Virtual Network Computer) which allows PCs running > NT, Suns running Solaris, and Linux boxen to display a desktop remotely - > and VNC is free (GPLed). > > phil As long as we're talking about running off the network, we really need to divide the world into licensed tasks and unlicensed tasks. Virtually all of the Unix software I use in my job is licensed, and requires access to a license server. When that server goes away, so does the application. So, as long as we're talking about EDA stuff, the issue of whether I can run my system on a plane is pretty moot - regardless of the OS. -- Mike -- -- Mike Palmer -------------------------------- Principal Engineer -- -- -- -- In a sad attempt to limit spam, my standard return addresses -- -- are all invalid. Mail "mike dot palmer at tus dot ssi1 dot com" -- -- replacing 'dot's and 'at's as appropriate. -- -- -- -- Silicon Systems, Inc. - A Subsidiary of Texas Instruments, Inc. -- -- The views expressed here are mine, and do not reflect the views -- -- of Silicon Systems, Inc. or Texas Instruments, Inc. --Article: 9330
misha: : There is a significant advantage of Linux over Windows concerning portables. : I was very surprised when I touched the processor inside my desktop when : it was running Linux. It was COLD. So was the power regulator. Under : Windows95 the processor is always hot, even when OSR2 System Monitor shows 1% : CPU utilisation for an hour. Same about NT. : : Of course, when CPU-intensive application runs under Linux, the processor : warms up. But for typing text on the portable Linux should give much longer : battery life. interesting. i haven't seen any of the rags that report on portables and battery life consider this. it would make a good benchmark since a lot of people do x-country traveling. now, the portables do have a lot of power savings features and do a bunch of stuff to extend battery life so the difference on the desktop pc may not equal difference on a lapdog. but it would be interesting to see, for a portable, a comparison for running a simple text editor between: a. win '95 b. win nt c. linux d. unix/pc e. unix/risc (pick hp, sun, ibm, etc.) f. mac may the best win! -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9331
peter: : > VI is for masochists :) stephan: : Or for those who need a small and fast editor and don't want to : lose time by moving their hands to the mouse and back during : touch typing, e.g. to copy just one line :). rk: i use win '95 and nt (amongst other os'es) and don't have that problem at all. i'm not that much of a mouse fan, too, although for certain apps, it is the way to go.Article: 9332
peter: : :: :There are lots of stupid things in NT but none of them make it in any : ;: ;way unsuitable for EDA. wen: : :: Oh yes. For one, it prevents me from using the tools if I am not sitting : ;: in front of of the machine. rk: : :solution: sit in front of the machine. wen: : Sorry, I can't do that. The machine I sometimes need to use would have : so many processors, disks, and memory and powersupply that it would take : a forklift to carry. I also routinely use manage jobs that runs on a : farm of workstations and I need to do it remotely and service them at : odd hours of the day. rk: for an application like that, at the high end, you need the high end horsepower. that's not a good spot for NT. but that has nothing to do with suitability of nt for eda, as peter pointed out. it only has to do with the suitability of nt for a particular class of job. don't think there's any disagreement there. and i've bought some big machines for big jobs (and spent big $). wen: : The problem is not with NT, the problem is with how Microsoft is having : an effect on how EDA programs were written. There is absolutely no reason : why EDA vendors couldn't compile their program on NT but link them with : X-window libraries so that the NT machine would be useful as a remote : compute engine within a network of unix workstations. NT still has a : long way to go to match Unix for networking and user interface. rk: yup, microsoft monopoly, which is not good [see my earlier post on competition and open standards]. and, i believe, microsoft does care about you; well about your $, anyways. for some networking features, the microsoft stuff is pretty good (and win 3.11 was horrible); on others it's a pain and not up to unix or another of other os'es. their user interface is not bad, very mac-like, and it's easy to write your own programs with nice, easy to use and understand humanoid interfaces. having programmed both, i'd go with the win '95/nt interface. wen: : By making : it so that engineers either has to choose between inexpensive EDA software : and versatile and mature networked user environment, Microsoft is causing : us a lot of pain. rk: not sure m-soft has anything to do with it, but the pc and it's software has made available inexpensive that is readily affordable, easy to use and learn, and is capable of performing good engineering. does it solve all problems. no way. but it's capable of good engineering as is dos and a number of other systems. of course, as one unix or linux fanatic put it, the pc's are only good for secretary's. i would, er, disagree there. wen: : <snip stuff on eda s/w structure> : But Microsoft won't do that because they : don't care about you. They care about market share. They are a monopoly. rk: obvious to the most casual observer. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9333
peter: : >: :There are lots of stupid things in NT but none of them make it in any : >: ;way unsuitable for EDA. wen: : >: Oh yes. For one, it prevents me from using the tools if I am not sitting : >: in front of of the machine. rk: : >solution: sit in front of the machine. phil: : Not always possible. For example if you can't make it into work because : of an ice storm, you can (if you're running Linux at home) establish a ppp : connection with a system at work and set your display to your home system : (assuming you're running some kind of Unix at work) and do a reasonable : amount of work. rk: hmmm ... work from home all the time. and can do *more* than a reasonable amount of work running '95 both home and at the office. sometimes (ok, a lot of times) it seems that i get a lot more done at home than at the office. but anyways, for any graphics intensive application, running over the 28.8 bps line interactively just won't work. now, you might say, as my neighbor across the street say, you can get a cable modem. well, her company pays for that that and it's expen$ive. but then again, her company just lost their company and were bought out (dec). rk: : >i think nt (and probably linux) is winner here over unix since with nt, you : >can simply fold up the machine, put it in your backpack, hop on the plane, : >wait for the announcement that you can pull out your 'puter, and get back : >to work. i travel a modest amount on business, 6-8 times per year, and i : >do some personal travelling. i see a lot of pc's with windows and mac's : >being used everywhere. never saw anybody doing unix on the plane. and i : >frequently pack up a pc, stick it in a box, get to where i'm going, take it : >out, turn it on, don't miss a beat. NOT being tied to the network makes it : >the portable computer and i don't lose any of the environment i'm used to. : >can you do this with unix box? can't with the way ours are setup but not a : >unix guru, just a key tapper. phil: : Sure, not being tied to the network might make it easier to take you : laptop on the plane and work on a design, but the need for this is only : 2-3 times a year for most of us. rk: for a lot of people it's a lot more. but i was just addressing wen's complaint that he wants to work w/out sitting in front of the machine. not a restriction for pc (win, linux). phil: : The disadvantages of not being tied to a network greatly outweigh the so : called advantages (especially if you have multiple people on a project). rk: i do a lot of multiple person design work. not being tied down hard to a network hasn't been a problem. at work, we're really well networked. and from home, i can just email myself or other team mates files at the end of the night and weekend and we're ready to go. no muss, no fuss. this includes joint projects for chip, board, and s/w design. now, one of the complaints that i have about the networked environment, for a large system, is that you lose control. admins do s/w updates, database updates, etc. surprise! and you're working late at night, weekend, etc. gotta get the job done. that's why you're there late at night or a weekend or a holiday. something goes wrong with network, server, etc. it's not in your lab. you don't have the key. don't even know where the stuff is. your stuck. this is NOT hypothetical and is a big complaint. with pc, easy to fix anything with the hardware (always keep some spare parts laying around) and can usually recover from any disaster in just a few hours. and don't have the surprise s/w updates. being able to control your destiny *IS A REALLY BIG ADVANTAGE!!!!!!!!!!!!!!!!!!!!!* rk: : >then again, tools for pc are cheap. got a set for home pc. don't gotta go : >to work. and can upload/download files no prob over the internet. hooking : >up drag and drop from home pc to work : >pc now, it'll be even easier to communicate. phil: : Well, the tools for running remotely with Linux are free. You get : XWindows which allows you to do this sort of thing. Now there is : something called VNC (Virtual Network Computer) which allows PCs running : NT, Suns running Solaris, and Linux boxen to display a desktop remotely - : and VNC is free (GPLed). rk: how well does xwindows run over 28.8? and you gotta tie up phone line, that's a pain. and can't get the software for linux. perhaps that'll change. but back to one of my original questions: why did synopsys announce all tools going to NT and not linux, with no customer demand for linux? dunno, perhaps you do. -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9334
Maybe its time to take this personal discussion between the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA etc groups its being SPAMMED to... This has little to do with the subject of the groups and the cross-posting is nothing more than SPAM. Anyone agree? -- BillArticle: 9335
rick kwan: : > : > unix versions of software have traditionally cost far more than the dos/win : > : > versions. yes, same code and all (in principle). but it is a different : > : > market. and, i believe, it will continue to be a different market. rk: : > one little paragraph generated a large response! ok, let's move ahead. rick kwan: : Actually, there were a whole bunch of others, but I thought : this was a good summary. I also admit to artificial pricing : barriers being a hot-button of mine. rk: didn't notice ;) rick kwan: : > : With PCs, this model has broken down. PC manufacturers : > : want us to believe that their machines perform as well as : > : traditional worktations. Furthermore, today you might have : > : a 150 MHz machine; tomorrow, it might be 333 MHz. You can no : > : longer base a software license fee on machine power. rk: : > well, i run on both unix and pc but don't think the two are equivalent. : > they're not. but if the pc is good enough for an app, and some studies : > have shown better performance / $, then it makes sense. it won't make : > sense for the million gate asics. but it probably will for 100,000 gates : > and less. and for < $1k, you can go down to the store, pick up a new : > motherboard and cpu and memory, and have something that really flies. lots : > of m-board competition, and with the amd k6 and others, there's getting to : > be some real competition for cpu slots. and the cpu market is now : > unbelievable w.r.t. performance and it's accellerating, with prices : > dropping. intel can no longer decide when to put out a new cpu and control : > pricing. somebody else will come along and beat them. r. kwan: : I agree that in hardware, they are not equivalent. (Some are : going to argue with that.) It use to be that in OS, they : were not equivalent either. However, with current robust : implementations of POSIX, that machine for < $1K can now run : a workstation OS; and if you put it on an Ethernet, it might : as well be a full-fledged workstation. rk: you can do fine engineering with unix. you can do fine engineering with nt. you can do fine engineering with 95. you can do fine engineering with dos. 3.11 was a pain in the ass, when on a network <poke in peter's ribs>. ran fine standalone, but on the network, everytime they'd mess with the net, doing something, every machine would lock up. and for critical runs, like programming parts, had to do the reboot to dos or the windows run with networking disabled. of course, different systems are capable of solving different problems and with different efficiencies when they leave their domains. don't know why people think you can't do good work with non unix/linux systems and delegate "lesser" systems to secretaries. if they're that dependent on a particular os they must be poor engineers. ;) me, basically agree with you. but it's the app s/w that's the big difference now for a majority of jobs. of course there are exceptions, like the guy earlier who requires a whole pile of machines for his runs. rk shows his age with his history books (ok, college text book): : > an interesting aside. you can go down to the local hole in the wall shop : > and pick up a m-board+cpu that runs at 333 MHz. that's a 3 nanosecond : > cycle time. here's a quote from one of my architecture books, (c) 1980. : > : > ... we cannot fail to mention that the clock cycle of 12.5 nS could only : > be achieved through some amazing technological advances in LSI .. and the : > cooling system. ... : > : > this is a description of the cray-1 supercomputer. rick kwan: : But the 333 MHz machine doesn't come with a love seat! : (Forget the love seat; I'll take the one with the sofa. ;-) rk: ;) rk: : > <snipped lots of good stuff> : > : > i don't think unix or linux or domain or win '95 or win nt or dos (yes, : > people still do good engineering in dos) or exec 8 or rt-ll or vms or mvs : > or whatever is really what's important. : > : > it's staying away from proprietary models that lock you in. a good healthy : > market with competition will lower prices while improving efficiency and : > performance. some comapnies will want to stay on top. and startups will : > want to take the market and money away from them. gotta beat the standard : > and convince people to change. rick kwan: : Basically, I think I agree. But there is perhaps a difference : of perspective here. I have been assuming a team of multiple : designers, or perhaps even multiple teams. In that case, : automating design flows and having strong underlying network : infrastructure is important. If your team is very small and : you are CPU-bound, then lots of things are equalized. rk: wow, possible agreement. must be a conspiracy of the rk's. ;) i generally work in small teams (generally 3 engineers at a time - and do work with a number of others, but more of a boundary there - can keep a real fluid flow with 3 people. after that, communications is a real problem. size of ideal group, gotta be another thread there). there are a lot of engineers who work in small teams, i have found. small is defined as from 1 to 3. after that, integrate at the card or box level. of course, for the state-of-the-art-stuffed=to-the-gills asic, it's another story. and a different model. and you need a different story. we do put a lot of emphasis on having a good network. all of our machines are linked together with drag and drop. we share common libraries. we all have identical setups, s/w revisions, tool sets. we can all sit down at one or the other machines, drag a directory over and work. we can finish a section of a design and pass it over. no muss, no fuss. '95/nt is good for that, we don't need more power. rick kwan: : However, even in small networks, if you are or have a systems : wiz around, automation on a UNIX/Linux network comes very : cheaply. rk: ah, the wiz, gotta have one for unix, that i know (and i hear the same about linux). me, not a unix wiz, key tapper, know how to yell for help! but for pc/win, any idiot can setup and maintain a decent, functional networked environment. don't even need a network, can just string the 'puters together with some cable, t's and 50 ohm resistors. that's what i like. see earlier note (prob. in previous post) about controlling one's destiny. important when it's you *ss on the line. and i just don't have the time to become unix wiz. friends i know says it takes 1 year of pain to get there. -- -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9336
someone said: : >No revision control ? No batch mode ? peter: : I don't use revision control. I have used PVCS and it is OK, but : frankly I don't trust some *program* to be diving into my source files : and inserting various bits of text in them. When I finish a : particular version, I back up the *whole* project to optical, and/or : CD, and tape. rk: i never use revision control. set up a back up machine out of spare parts - and it doubles as a www server to boot. we save on each other's disks. backup to backup of choice at time. storage is cheap, fortunately, as this is the '90s. and this eliminates any possible confusion about what version is what. someone: : >Most of the cpu and time consuming jobs here are done by batch : >(shell scripts, etc) overnight, e.g. Synthesis, ATPG, Simulations, : >Analysis, etc. peter: : Under DOS, one uses .bat files. I still use DOS a lot. In Viewlogic 4 : (DOS) one can run simulations using .cmd scripts - this is probably : the same on the unix versions. I have often run overnight simulations, : although this is less common with P200+ machines. rk: still the same for viewlogic. most sims are done < 10 minutes. rarely more than a half hour anymore. haven't run an overnight one in years, although chip designs are getting bigger. peter: : Under windoze, batch processing is much more difficult if the app does : not have some sort of script language built-in, and this is partly why : I like the old DOS (or DOS box) tools. There are "automation" tools : for NT but I have not used them. rk: the scripting tools are starting to come in. for designer, for example, they give you a simple c-like programming language. generally, things happen fast enough don't really need them. and with viewlogic .cmd files, just load them and go. peter: : The other related problem is that if there is no scripting facility, : it becomes much more difficult to maintain a project over several : years. Take today's trendy Integrated Development Environments. All : the compiler & linker options are set via the GUI. One can no longer : open an old project and just type MAKE to rebuild it. But again this : is nothing to do with NT. rk: ah, depends on the s/w. for viewlogic, as we discussed, i do all of my final simulations via file commands. and they are compatible with current versions. for my actel work, they do a good job of remembering your settings. for their vhdl compiler, for example, you can save your configuration which controls clickable options so as optimization and effort settings, chip or block mode, etc. not sure about the other manufacturers s/w. their macro generator stores the entire state of the macro in a file, and you can easily call it up and look at it or mod it.Article: 9337
z80@ds2.com (Peter) writes:
> >No revision control ? No batch mode ?
>
> I don't use revision control. I have used PVCS and it is OK, but
> frankly I don't trust some *program* to be diving into my source files
> and inserting various bits of text in them. When I finish a
> particular version, I back up the *whole* project to optical, and/or
> CD, and tape.
I guess if you don't interact with other people it might be OK to do
without some source of revision/source control system. If you're in a
group of several people working on a design it's a different story. I
personally use revision control for designs that I do by myself too. I
store the RCS tags into each source file and output them into the SST
(or VCD/VPD) files (simulation dump files) using the following snippet
in each of my source files:
// synopsys translate_off
reg [639:0]RCS_ID;
initial begin
RCS_ID = "$Id: compu.v,v 2.4 1998/01/06 22:29:23 pegu Exp $";
end
// synopsys translate_on
You could also throw a $display in there to write the RCS_ID to the
log file. I use a script which will iterate over all the source files
and do a what/ident to dynamically build a Verilog module which writes
out the source files and version numbers in a cleaner format.
So when you find a SST or simulation log file on your hard disk after
a week of vacation (or a month of simulation) you can track the
version numbers back to the source. This is also useful when you have
other people responsible for the functional testing, e.g. "please run
the CAM test on the 2.278 release". Or something suddenly stopped
working, and you realize that it's been broken for the last two
months, but it worked before Christmas. Then it's great to have a way
to track back and see what changed. I'm addicted, I use it in all my
programs, scripts, documentation or whatever. It gives me a feel of
control which is greater than the fear of RCS/CVS/SCCS screwing up the
substitution of a couple strings in my source files. It integrates
beautifully with emacs too. And of course, I still do backups.
I'm sorry for getting little off topic. This is really not an argument
in the UNIX/Linux/NT debate since RCS/CVS are available under W95/NT.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://home.sol.no/~pegu
Remove the obvious from my reply address to send mail -- sed s/nospam//g
Article: 9338On 6 Mar 1998 04:36:07 GMT, janovetz@ews.uiuc.edu (Jacob W Janovetz) wrote: > I read in the Xilinx documentation that the 4000XL series allows >mapping an internal signal to an available BUFGLS. >(page 4-43 9/96 databook). I have not been able to do this, however. >In Leonardo, I have tried assigning a BUFGLS to the signal and >even tried mapping a component in. However, when it comes time for >the Xilinx tools to place and route, I get the following error: Buffer_sig BUFGLS clk pad IBUF clk should do it. By forcing the IBUF, you'll gain access to the BUFGLS via internal resources, rather than being forced to the fixed pins. What happens to your clk2q when you do this? StuartArticle: 9339
Check out SourceSafe...by Microsoft. SourceSafe understands files and directories. It works under a varity of OS's. It does not embed stuff in your files, unless you ask it to. I'm just a satisfied customer. David Decker wrote in message <34fc3a8b.3807785@news.jps.net>... >I would like to use a version control system to support multiple >FPGA designers doing ViewLogic schematic capture to >Xilinx in under Win95. PVCS and similar programs are designed >to support software developers. As I am discovering, the main >deficiency of these systems when trying to use them for schematics, is >their inability to check directories in and out of version control. >They want to work with file lists. > > > > snip description of lots of need features Jeff Stout Sorry,Article: 9340
rk:
: >if Linux *is* a UNIX, can i just go down to the local synopsys store,
: >order me up a copy of UNIX synopsys, drop in the cd onto my linux/x86
: >portable machine, and start running?
clint:
: You are obfuscating the issue here. Just because you run UNIX doesn't
mean
: the underlying hardware is the same.
rk:
well, after consulting my dictionary, i don't think so. going back up the
thread we see that the discussion started about linux and eda and etc.,
etc., etc. well, we have discussed that, advantages and disadvantages of
different configurations, requirements of different applications, etc. and
there's a nice thought here about the advantages of unix software and pc
hardware. it's a nice model. however, for the model to useful, there has
to be application software. my requirement is that i need to run synopsys.
because that's what the foundries that i need to go to take. i have no
choice. that's why i purchased (day job) synopsys and big unix machine and
got boss to sign big pr to go along with that.
ok, here's the previous quote:
mark:
The key point of the message: PC != Windows. Linux/*BSD = UNIX.
UNIX !=
workstation. UNIX runs on a PC, too. Only faster/better. :)
Mark "Not a fanatic, really! ;-)" Willey
perhaps i misunderstood the quote but it says that linux and *bsd both
equal unix. so, we can assume mark meant linux = *bsd (mark correct me if
i'm wrong). unix != workstation implies that unix doesn't equate with
having to be on a workstation (can't argue that one). then, with unix
running on a pc (this means linux and *bsd) it says linux or *bsd can run
on a pc too. did i miss something here?
now, this is a nice model. pc hardware is cheap and portable and
reasonably powerful for a nice class of jobs. now, for programming, there
are two things that have to happen. 1, as you point out, the generated
binary code must run on the 'puter of choice. 2, the software must make
calls to the OS for services and humanoid-interface. 1 is done by the back
end of the compiler. 2 is done by the humanoids for a lot of programs
although with delphi, for example, we're getting shielded from that
although that's another story.
so, can linux (unix) + pc hardware do the job? we've seen lots of comments
about lots of the pieces. but if there's no software it can't, no matter
how much people like the model. so we have to look at the model a bit
closer and we might be able to say that linux ~ *bsd. and various people
have pointed out that sys admin retraining, for example, will not be too
bad going from unix to linux. and this may be a factor in where the
industry is going over the next several years.
also note the intel + hp alliance for the cpu. and the intel + rambus deal
for memory. speed, speed, and speed. rambus is fast and high density,
basically same as regular dram. and hp has a lot of unix experience. and
they're going to 64-bits. clearly, they are going after workstations. but
there is one more piece of the puzzle that hasn't received that much
attention, and may address what another poster talked about, needing a big
pile of machines. that is, hp is working on chip set for large numbers of
cpus to work together, targeting the high end. and with almost every major
workstation vendor (believe there is one holdout, sun) hedging their bits
on cpus, it'll be interesting to see what will happen on the high end of
processing.
so, i obfuscate nothing.
i need to run synopsis. that means, from what i hear, unix. not linux.
seems pretty clear.
: Can I take an NT
application compiled
: on the Alpha and run it on the PC?
dunno, didn't ask, and it doesn't really matter in this discussion.
but, i shall ask you this:
will it be easier to port an NT/alpha program to NT/pentium II?
or
will it be easier to port a unix/sun program to linux/pentium II?
rk:
: >hmmm ... just a little old engineer here, but i seem to remember, let me
: >know if it's not true, that s/w needs to be written or tweaked for
: >different versions of unix. can i take code from an hp box and run it
on
: >a sun box, or a dec box, or a ibm box, or an cray box, or a silicon
: >graphics box (haven't followed these two too close since merger) or a
: >xenix box? anyways, that's s/w portability.
clint:
: Software is very portable when it is written to adhere to standards that
: all vendors support and requires very little/no "tweaking" as you say.
For
: example, software written in ANSI C is highly portable. XFree86 is
: available on FreeBSD, Linux, LynxOS, NetBSD, OpenBSD, OS/2, SCO, Solaris
: x86, and SVR4 which are all quite different OS breeds. The newsreader
SLRN
: and the Mutt mailer compile on just about any UNIX imaginable regardless
of
: the underlying hardware architecture.
rk:
well, for eda i need synopsys. no choice. but, as i asked earlier, why is
synopsys porting to nt and not to linux? let's find out, below.
clint:
: Now as to why Synopsys doesn't cut a release Design Compiler on Linux is
: another story. That has a lot of baggage in it, and chances are they
: didn't care a lot about portability when it was first written. We'd have
: to see their software development process in a little more detail to
: ascertain the cause.
rk:
it seems to me that if the code isn't written that portably, then moving to
nt instead of linux will increase their work load. gotta make sure no
oopses in the coding style. gotta change os calls. gotta change tools.
gotta make sure the humanoid interface works ok. gotta retrain support
staff. gotta write more app notes. gotta those slashes pointing the wrong
way all over the place. linux would make a lot more sense technically, if
they want to get on cheap hardware with minimal investment in s/w
development and support costs, if linux and unix are that close. also,
it's curious to note, synopsys just bought viewlogic. and their tools, to
a large extent, run on both unix and '95/nt.
==> perhaps nt just isn't so bad, is usable for eda, not just for
secretaries.
--------------------------------------------------------------
rk
"there's nothing like real data to screw up a great theory"
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 9341William D. Billowitch <wdb@vhdl.com> wrote in article <6dpo45$c5o$1@news1.fast.net>... : Maybe its time to take this personal discussion between : the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA : etc groups its being SPAMMED to... : : This has little to do with the subject of the groups and the cross-posting : is nothing more than SPAM. : : Anyone agree? : : -- : Bill OH, SH*T, IT'S THE NET POLICE. RUN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Article: 9342
William D. Billowitch <wdb@vhdl.com> wrote in article
<6dpo45$c5o$1@news1.fast.net>...
: Maybe its time to take this personal discussion between
: the 3 folks off-line and out of the VERILOG, VHDL, Synthesis, FPGA
: etc groups its being SPAMMED to...
:
: This has little to do with the subject of the groups and the
cross-posting
: is nothing more than SPAM.
:
: Anyone agree?
:
: --
: Bill
TOP TEN THINGS THAT MAKE THIS THREAD RELEVANT
=============================================
1. IT'S MORE THAN THREE FOLKS. IT'S NOT PERSONAL. IT'S A NICE DIVERSE
GROUP RANGING
FROM DOS USERS ALL THE WAY UP TO GUYS RUNNING REALLY POWERFUL MACHINES
THAT YOU
NEED A FORKLIFT TO MOVE.
2. ER, WHAT'S SPAM? DOESN'T SOUND GOOD. I THOUGHT IT WAS ANNOYING
COMMERCIAL E-MAIL.
THIS IS A TECHNICAL DISCUSSION COVERING A LOT OF RELEVANT TOPICS. AND
WE'RE
NOT DOWNLOADING E-MAIL INTO YOUR E-MAIL BOX, FORCING YOU TO WATCH THE
LITTLE
LIGHTS BLINK ON THE MODEM.
3. WE ARE, HOWEVER, FORCING YOU TO WAIT UNTIL THE 50 OR SO CHARACTERS FOR
THE HEADER
TO DOWNLOAD AND GET PUT UP ON YOUR SCREEN. SOMEHOW THAT DOESN'T SEEM TOO
BAD.
AND, TO AVOID WASTING MORE OF YOUR TIME, JUST DON'T CLICK ON THESE HEADERS
ANY MORE.
4. WHO STARTED THE CROSS-POSTING ANYWAYS? PROBABLY SOMEONE WHO THOUGHT
THAT IT WAS
RELEVANT AND IN THESE GROUPS THIS HAS BEEN ONE OF THE BETTER DISCUSSIONS
I'VE
SEEN RECENTLY. LEARNING STUFF.
5. FPGA: YUP, THIS HAS SOMETHING TO DO WITH FPGA. AS THEY GET BIGGER AND
THEIR
CAPACITY INCREASES, THESE ISSUES WILL BE *MORE* RELEVANT. AND WITH XILINX
AND
ALTERA BEATING THEMSELVES OVER THE HEAD FOR MAKING BIGGER FPGAS, AND TALK
OF
MILLION GATE FPGAS (OR LETS SAY EVEN SEVERAL HUNDRED THOUSAND GATES FOR
THE
NON-MARKETEERS) IT'S IMPORTANT TO SEE WHERE WE'RE GOING IN THE NEXT FEW
YEARS.
6. SYNTHESIS: YUP, WHAT H/W-S/W ENVIRONMENTS ARE WE GOING TO USE FOR
SYNTHESIS. WHAT
IMPLICATIONS DOES THIS HAVE FOR PERFORMANCE, USABILITY, TOOLS, FLOW,
REMOTE
OPERATIONS, ETC. SOUNDS RELEVANT.
7. VHDL: YUP, THIS IS ABOUT HDL'S, NOT STRICTLY SCHEMATIC CAPTURE. THE
VHDL FOLKS
KEEP TELLING US DEVICES TOO BIG FOR SCHEMATICS. BUT THAT MEANS WE NEED
SOFTWARE.
AND OSES TO RUN THEM ON AND HARDWARE FOR THEM TO RUN THEM ON. AND THIS IS
A
VERY RELEVANT TOPIC. OR, PERHAPS IT'S ALL B.S. AND WE SHOULD GO BACK TO
THE
DRAFTING TABLE <DAMN, THEY WOULDN'T LET ME KEEP MINE ANYMORE, NO ROOM>.
ANYWAYS,
IT'S RELEVANT.
8. VERILOG? DIDN'T NOTICE IT UP THERE. DON'T DO VERILOG. BUT LIKE 7,
ABOVE, IT PROBABLY
IS RELEVANT. I GUESS A LOT OF PEOPLE NEED TO RUN VERILOG FOR THEIR
SIMULATIONS.
I HEAR IT'S A LANGUAGE OF CHOICE AND IMPORTANT. SIGNOFF OF CHIPS AND
STUFF.
9. IT'S INTERESTING, GETTING THE DIFFERENT DISCUSSION GROUPS TO INTERMIX,
AS WE'LL BE
GETTING CLOSER IN THE FUTURE, AS SEMICONDUCTOR TECHNOLOGIES MATURE.
ALTHOUGH
I DO MOSTLY FPGAS, I USE VHDL AND SYNTHESIS IN ALMOST EVERYONE OF MY
DESIGNS.
AND FOR THE ASICS, WELL, THAT SPEAKS FOR ITSELF.
10. IF YOU'RE STILL READING THIS, YOU REALLY MUST SECRETLY ENJOY IT. OR AT
LEAST ENJOY
THE NET COP ROLE, GLORIOUS PROTECTOR OF INTERNET BANDWITH.
RK
P.S. LIGHTEN UP, RELAX, THIS IS SUPPOSED TO BE FUN! PERHAPS YOU WISH TO
CHIME IN ON SOME OF YOUR OPINIONS AND EXPERIENCES.
P.S.S. I GUESS THIS MEANS THAT I DON'T AGREE WITH YOU.
Article: 9343On 6 Mar 1998 23:45:04 GMT, rk <stellare@erols.com.NOSPAM> wrote: > >dunno, didn't ask, and it doesn't really matter in this discussion. I'm just trying to distinguish the OS from the hardware underneath. I think I made that pretty clear. >will it be easier to port an NT/alpha program to NT/pentium II? > > or > >will it be easier to port a unix/sun program to linux/pentium II? I'm only speculating that the NT port from hardware->hardware would be slightly easier, but I've never performed software development on NT. But, I don't think it would be very time consuming at all to migrate a portable piece of code from sun->linux/pII. >it seems to me that if the code isn't written that portably, then moving >to nt instead of linux will increase their work load. Synopsys is in the business to make money just like everyone else. This is purely a marketing maneuver. They clearly see that they can sell more bundles on NT than they ever could for Linux. This is probably true given the lemming syndrome of most people. When is the last time you saw a Linux commercial on TV? But, I would advise EDA companies not to underestimate the power of "word-of-mouth". At times this can be more powerful than any marketing tool. Hell, it's done wonders for Linux so far :) The Linux/FreeBSD model is very similar. Someone says they want to run UNIX in the home. The first thing that pops into their mind is: Linux (surprise!). Technical issues/merits aside, Linux has it's inertia in the free OS marketplace as NT does commercially. -ClintArticle: 9344
Rick Collins wrote: > > Hi, > > In addition, a Correlation typically is used with a variable sequence in place > of the fixed FIR coefficients. The FPGA design utilizes a lookup table to > impliment the multiplier by a fixed coefficient. This would not be easily > programable for a variable Correlation pattern. > > To impliment a multiplier of two variables requires a very large amount of > resources in an FPGA. If on the other hand, you only have a small number of > Correlation patterns you need to use, then you can use a separate download for > each pattern. > I don't remember what the application here is. The coefficients in a distributed arithmetic FIR or COrrelator can be changed on the fly, but it is a little painful and takes some time. If the rate is high, but the number of sets is limited (for instance, in radar we might use a correlator with ten sets of coefficients corresponding to evenly spaced fractions of a range cell - the reference waveshape is constant but with different subsample arrival times) you can get away with switching which table is used. THis does grow the filter by quite a bit as the number of coefficient sets increases however. This may be one of those cases where you need to look at the overall problem to see if another approach might yield a better answer. For instance, if this is a case where the arrival time is predictable for future samples once it has been found for one, you can introduce a subsample delay in the input signal to align the correlator sample clock to the incoming data. -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: 9345
Stuart Clubb wrote: > > On Tue, 03 Mar 1998 12:28:12 -0800, Peter Alfke > <peter.alfke@xilinx.com> wrote: > > >Don't believe what Marketing says about its competitor. You can be sure > >that the facts have been massaged. There are hundreds of ways of > >manipulating the truth without necessary creating outright lies, > >although even that happens. ( Would you be so naive to believe what > >Ford says about Chevrolet, or Toyota about Honda, or McDonald about > >Burger King or vice versa ? ) > > Amen to that, but a sticky wicket approaches... > > >Be careful when you evaluate "equivalent" devices. One observer's > >equivalence is another one's big difference. > > You could always just cut to the chase and count the number of 4ip > LUTs. Or maybe the number of registers? Imperfect, but better than the > marketing "specmanship" that has been going on recently. > > Let's try it shall we?.... > > Xilinx XC4062 - 4608 4ip LUTs, and a total of 5376 registers, of which > 768 are internal. I/O is 384 maximum. > > Altera FLEX10K100A - 4992 4ip LUTs, and a total of 5398 registers, of > which 406 are in the I/O blocks. I/O is 406 maximum. > > Similar devices yes? > Well not for arithmetic. See to use the carry chain the altera 4 lut is broken into a pair of 3 luts, one for the carry function, one for the bit function. One input to each of those 3 luts is the carry in, so you are left with a maximum of 2 inputs for arithmetic functions if you want to stay in one level of logic. Xilinx, on the otherhand has dedicated carry logic, so you get a 4 lut for your bit function whether you use the carry or not (one input is used for the carry in). Thus for arithmatic functions, the xilinx 4 lut and the altera 4 lut are not the same! What is worse with the Altera, is that if you are using the carry, the second layer of logic can't be in the same LAB (in the 10K) because the carry chain snakes thru all the LE's in the LAB (you could put a buffer in as one of the carry LUTs to do this, but then you double the carry chain delay). The result is the signal from the first level of logic has to go on the global row routing to get to the second level of logic with the attendant delay and routing resource penalty. This is significant, because in DSP there are many times when you need more than two inputs. Examples are adder-subtractors, multiplexed inputs on adders, and and gates followed by adders such as those used in multiplication. I do however agree about not using marketing gates to evaluate devices. My point is that you really have to look at the architecture an evaluate it for your application. -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: 9346
rk: : >dunno, didn't ask, and it doesn't really matter in this discussion. clint: : I'm just trying to distinguish the OS from the hardware underneath. I : think I made that pretty clear. rk: yes, that was clear before. however, a requirement (mine) is run synopsys. and in this case, linux <> unix. it would be nicer if it did, but that's not the case. rk: : >will it be easier to port an NT/alpha program to NT/pentium II? : > : > or : > : >will it be easier to port a unix/sun program to linux/pentium II? clint: : I'm only speculating that the NT port from hardware->hardware would be : slightly easier, but I've never performed software development on NT. But, : I don't think it would be very time consuming at all to migrate a portable : piece of code from sun->linux/pII. rk: question is, how portable is code? when i was writing c, we looked at what we had to do to make it truly portable. well, there'e books written on the subject. i wouldn't be surprised it most code is not that portable, but i've been out of c for a number of years. if one company wrote a 'nt' compiler for both intel and dec hardware, i would imagine that the port would be easy, as they would switch out the back end of the compiler. the os calls would be the same. that's a biggie. the commands for compilation would be the same. that's a biggie. and the back end would be handled once, by the manufacturer, transparent to the user if done well and the code isn't too bad. perhaps someone current in c and nt could comment on some real specifics. rk: : >it seems to me that if the code isn't written that portably, then moving : >to nt instead of linux will increase their work load. clint: : Synopsys is in the business to make money just like everyone else. This is : purely a marketing maneuver. They clearly see that they can sell more : bundles on NT than they ever could for Linux. This is probably true given : the lemming syndrome of most people. When is the last time you saw a Linux : commercial on TV? But, I would advise EDA companies not to underestimate : the power of "word-of-mouth". At times this can be more powerful than any : marketing tool. Hell, it's done wonders for Linux so far :) rk: totally agree here. and with the news release for synopsis saying that they will charge the same, small and medium users will be tempted to go with cheaper alternatives (independent of linux or 95 or nt). their stuff is expensive. they will get some more wins from people who want the same tools on nt and unix even if it costs a bit more. and they will get probably a few more wins from people who have to have synopsys and the cost of the unix hardware and admin was blocking their entry. i would expect this number to be small as this business is really expensive, and even the expensive unix h/w is not the big-ticket item. word of mouth is important and getting users to know the tool. leaves the door open for someone selling a $5k tool and a lot of copies. once there's a lot of people using it, then it can get critical mass. like bell labs giving away unix+c+source to universities in the '70s to run on dec machines. we all know what happenned. also, it's interesting to see how agressively ambit is advertising. and synplicity in the pc world, amongst others. clint: : The Linux/FreeBSD model is very similar. Someone says they want to run : UNIX in the home. The first thing that pops into their mind is: Linux : (surprise!). Technical issues/merits aside, Linux has it's inertia in the : free OS marketplace as NT does commercially. rk: yeah, but there are a lot of people who want to run lots of programs at home, and their are a lot of them. and eda people are drop in the bucket. like now-adays can't communicate w/ anyone unless you have ms office. and systems need to be trivial to set up and use. and most people (like me) who can afford multiple machines at day job when necessary, will not be able to do that at home. perhaps a dual-boot system will be somewhat popular. but that's a bit messy. -- -------------------------------------------------------------- rk "there's nothing like real data to screw up a great theory" - me (modified from original, slightly more colorful version) --------------------------------------------------------------Article: 9347
Stuart Clubb <s_clubb@die.spammer.netcomuk.co.uk> wrote in article <34fddb0c.1321474@nntp.netcruiser>... > It gives me great pleasure to announce that I now have no ties to any > programmable logic vendor. As some of you will recall, I have been > working for a Lucent distributor, Eurodis Bytech, but following my HDL > 'convictions', I have (this week) changed jobs to work for the HDL > solutions company, Saros Technology. > > Hopefully my views on programmable logic can now be treated with a > slightly less sceptical view than they may have been in the past. ;-) > > Naturally, I look forward to working with all vendors, and their UK > distributors in the provision of HDL solutions for ASIC and PLD to > their customers, both present, and future. > > www.saros.co.uk > > Modelsim, Exemplar Leonardo/Galileo, Turbowriter, IP cores, TransEDA, > etc. > > Stuart > For those who don't give a stuff, sorry for the time-waste. Best of luck, you could not have made a better choice for the UK market. DavidArticle: 9348
In article <01bd4944$4106a440$1e83accf@homepc>, rk <stellare@erols.comNOSPAM> wrote: >don't know why people think you can't do good work with non unix/linux >systems A mere problem of interface. With Linux you can get the interface you want (it can look like NT if you really want). With NT you have to be happy with what Bill Gates has made for you. If you dislike the NT interface, you are out of luck. The "keyboard guys" who do not use the mouse, neither the arrow keys (they are too far on the right), have real difficulties to use efficiently mouse-driven interfaces. About the same difficulties as what a Mac user feels when he sits in front of a DOS prompt. >and i just don't have the time to become unix wiz. friends i know says >it takes 1 year of pain to get there. It has been true. It still is with some unixes. But not with modern Linux distributions. Actually, they seem to be simpler to install than Windows. The reason why the average PC user has Windows and not Linux is that he got it on his harddisk when he bought his computer, and does not want to (re)install any OS. --Thomas PorninArticle: 9349
In article <35005160.69CE@nospam.nospam.com>, Mike Palmer <mike.palmer@nospam.nospam.com> wrote: [things about X11 too slow on a 28.8 connection] You may try dxpc: it's a free X11 protocol compressor. It works really well and costs nothing. It should be easily found in many ftp sites. --Thomas Pornin
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