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
On Mon, 02 Mar 98 19:06:27 +0300, svoiski@mcr.spb.ru wrote: >Some NT "features" are ridiculous compare to Linux: memory >allocation and multitasking are inferior to "antiquated" Linux, and in >Windows95 they are non-existent. I would install Linux tomorrow if I could get Xilinx's M1 on it. But, just to put the record straight on Win95, it has the same process and thread model as NT, and also has pre-emptive multitasking. I'm not aware that there are any memory allocation problems; the 'malloc' you get with your compiler does exactly the same job for you as malloc on a unix-based compiler. Win95 does have a lot of problems, of course. Existing 16-bit Windows apps, and any device drivers, new or old, must co-operatively multitask. In other words, multitasking only works properly for 32-bit (Win32) apps. The other major problem is memory space protection. Win32 apps have their own private virtual memory spaces, and are protected from each other. But - everything has full access to 'system' memory space. There's no user/supervisor distinction. By the way, I can't remember the first time I heard someone say "Unix will disappear over the next two years". But it was at least 12 years ago. And I've lost count of the number of times I've heard it since. Evan (ems@nospam.riverside-machines.com)Article: 9226
I think I should say it a bit more precisely (referring to my last mail): using vertical longlines: Constrain all critical components (CLBs) in one column and lock the critical net to a fixed pin of these CLBs with either the 'P' attribute or the 'MAP=PLO' resp. 'MAP=PLC' attribute combined with the use of CLBMAP mapping symbol. The disadvantage is the effort to map and constrain your design (or parts of it). But for best results you should always constrain 3K designs. If you fix critical nets to B or C inputs of CLBMAP you have the biggest chance to persuade PPR/APR to use a lonline (more resources are available in 3KA ICs). If PPR/APR doesn't it's now easy to correct the result in XDE. using horizontal longline: Use a 'dummy'-TBUF (WAND) or feed your critical net through a TBUF (need the 'X' attribute) and PPR has to use a longline. If the extra delay is a problem you can remove the TBUF in XDE. you see XDE is a nice tool. good luck reno:)Article: 9227
Hello Jake Make sure your fpga is properly decoupled. A 0.1uF cap for every VCC pin is what I would recommend. It maybe the case the ca[acitance of your probe is actually making your device work. In article <6dg38g$cla$1@vixen.cso.uiuc.edu>, Jacob W Janovetz <janovetz@ews.uiuc.edu> wrote: >Hello... > > I'm quite perplexed with a certain design I'm working on. The >state machine is extremely simple and the speed is not pushing >the device. I'm using Leonardo for VHDL synthesis into a Xilinx 4000XL >FPGA. Trouble comes in the normal execution of my state machine. >Certain items are not initialized as the code dictates they should >be. The simulations come out perfectly. > The perplexing part is that when I bring an internal signal out >to the package in order to observe it on a scope or logic analyzer, >the problem disappears so I can no longer observe it! This happens >very consistently. If a signal is brought out -- no trouble. > > It seems similar to problems I've had with discrete logic where >a signal is left floating or has weird capacitive effects so that >placing a scope probe on the signal causes the trouble to disappear. > > Does anyone have any advice? I'd appreciate it! Something >that may be common with 4000XL devices that I don't know about? > > > Cheers, > Jake > >-- > janovetz@uiuc.edu | Once you have flown, you will walk the earth with > University of Illinois | your eyes turned skyward, for there you have been, > | there you long to return. -- da Vinci > PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.htmlArticle: 9228
We are a mid-sized computer company located in Hayward, CA. We are seeking A technical lead/FPGA designer to join our company. Please contact me for more information regarding the position and company. thank you for your time debra ray -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreadingArticle: 9229
Kayvon Irani wrote: > An article published in the Feb. 98 issue of Altera's > "News&Views" > claims that a Xilinx XC4062XL > has twice the die size of an "equivalent" Altera device. For such > a > large device such a great difference > could mean a lot in terms of cost, yield, power consumption , > etc.. > Can any one confirm this apparent > mismatch on the die size? > Here is some general advice: 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 ? ) Be careful when you evaluate "equivalent" devices. One observer's equivalence is another one's big difference. Don't equate chip size with cost. There are many other factors affecting cost, some of them technology-oriented, some not. Cost is what matters, not square microns. Don't compare devices on the basis of today's single-quantity price, but don't blindly accept high-volume futures either. The old rule still holds: "If it sounds too good to be true, it probably is". These are general rules, and apply to all situations, not just Altera vs Xilinx. Peter Alfke, Xilinx ApplicationsArticle: 9230
On Mon, 02 Mar 1998 01:55:20 GMT, k.rozniak@XXX.ien.gda.pl (Krzysztof Rozniak) wrote: >I am using rather old version of VL as a front end for XACT6. >Does anybody know how to make VL 4.1.3 running under DOS7 (from W95)? >Works fine with DOS5.0 and QEMM6.0 as memory manager. >I spent a lot of time testing different configurations but I failed. >There is no (or I can't find) info about it on ViewLogic home page. >Any help will be appreciated. It doesn't work -- I seem to remember that the problem was something related to opening files not working under the 32 bit OS. Xilinx have a note on their tech support database about this. The only upgrade path I found was to Aldec (Xilinx Foundation) tools -- very painful, but possible. -- Gavin Melville gavin@cypher.co.nzArticle: 9231
I have seen this before with a Xilinx 4005H, 4013 and 4025. The internal logic has a problem so you bring it out for visibility. In doing that the problem goes away. My guess is there is some race condition or some very marginal timing in your design. Xilinx tools are notorious for timing problems. I have seen it in my designs before. Sure I expect that in asynchronous sections, but not in a synchronous design. Check the timing of the critical section(s) with the Xilinx tools. You mentioned it simulated correctly, is that post place and route? I have some designs that would simulate fine, but not work due to the poor nature of Xilinx place and route tools. I have heard they are better now - but, honestly, it wouldn't take much to be an improvement. I wish you luck. Keep posting your progress here. Cheers, Glen AtkinsArticle: 9232
Sorry to bother you. This is to test if they finally got our news server fixed. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 9233
"Glen Atkins" <glen_atkins@hp.com> writes:
>I have seen this before with a Xilinx 4005H, 4013 and 4025. The internal
>logic has a problem so you bring it out for visibility. In doing that the
>problem goes away. My guess is there is some race condition or some very
>marginal timing in your design.
Glen,
I'm still not sure what went on, but I reorganized a few things and
Leonardo (VHDL synthesis tool) reported that a few signals were
not initialized and therefore "loops were inserted to preserve values"
or something to that effect. In any case, I did not reset these
signals because I didn't care what they came up to. In other words,
they were being set later in a state machine before being needed.
By providing an asynchronous reset on the signals Leonardo complained
about, the design worked with and without external problems.
Thanks for your suggestions...
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9234> 1) What file name should I use to contain the listing given above? Should > it be my_pkg.vhd, comp1.vhd, comp2.vhd or something else? Your file-name must the same as the one of entity-name or package-name. if not, you'll meet error. Above is OK. > 2) In my main program (in a separate file), how does it know where to > find the component definitions defined in the above listing? Let's assume your package files, components and main exist the same directory. first, you must compile each entity one by one. then compile package. then you can get *.dls files. write following 'use' clause in your main program, then you can use your component. use work.my_pkg.all; To locate your library some where else, you may set "option-user libraries" menu. from Jong-Heon LeeArticle: 9235
In article <6dg38g$cla$1@vixen.cso.uiuc.edu>, janovetz@ews.uiuc.edu (Jacob W Janovetz) says: > > I'm quite perplexed with a certain design I'm working on. The >state machine is extremely simple and the speed is not pushing >the device. I'm using Leonardo for VHDL synthesis into a Xilinx 4000XL >FPGA. Trouble comes in the normal execution of my state machine. >Certain items are not initialized as the code dictates they should >be. The simulations come out perfectly. > > Cheers, > Jake Hi Jake.... When the going get weird, check for asynchronous inputs. Are ALL inputs to the state machine driven from registers clocked by the state machine clock? If not, try re-ordering the states so that any state changes that depend upon the aync input only cause a single bit in the state word to change, or else add some ff's on those inputs. EricArticle: 9236
alain arnaud wrote: > > My company will shortly be respinning the prototype board for Xilinx FPGAs. > We are requesting your help in choosing the appropriate feature set. > Email your responses to arnaud@ecla.com > > 1. Board Form Factor > Do you prefer > (A) standalone board or > (B) a board that plugs into a PC slot? A > > 2. Bus Interface > If PC size board, do you prefer > (A) an ISA interface or > (B) a PCI interface or > (C) No interface, just power and ground. A > > 3. Bus Interface Controller > Do you require the board to incude: > (A) Separate PCI bus controller > (B) Separate ISA bus controller > (C) the device should be able to drive the bus > (D) No bus controller B > > 4. Xilinx FPGA > Should the device be > (A) directly soldered to the board or > (B) to a small module that's plugged into a connector on > the board ? B > > 5. If the device is on the board, which device would you prefer? up to 4020 (e,ex,xl) or xcs40 > > 6. What package and pincount? HQFP 240 > > 7. Should the board include a microcontroller? > (A) Yes > (B) No B > > 8. What kind of connector should be used to bring out the IO? HE10 > > 9. How large should the wire-wrap area be? 60 x 60 mm > > 10. The device will be able to be programmed through a serial prom. > (A) Include a parallel Flash device? > (B) Include a jtag (boundary scan) connector > (C) Include a xchecker download/readback connector > (D) If a micro is on the board, should the micro be able > to program the device? Yes B and C > > 11. Other featgures or comments Price and availability for french users > > Thanks for you help. > > Alain Arnaud > arnaud@ecla.com Thierry GARREL (tga@hol.fr) +----------------------------------------------+ | MATRA Défense Equipements et Systèmes (MDES) | | 6 avenue des tropiques - BP 80 | | 91943 COURTABOEUF CEDEX / FRANCE | | Tel : (33) 1 69 86 84 84 | | Fax : (33) 1 68 07 03 70 | | Mail : cs-defense-ceo@calva.net | +----------------------------------------------+Article: 9237
alain arnaud wrote: > > My company will shortly be respinning the prototype board for Xilinx FPGAs. > We are requesting your help in choosing the appropriate feature set. > Email your responses to arnaud@ecla.com > > 1. Board Form Factor > Do you prefer > (A) standalone board or > (B) a board that plugs into a PC slot? A > > 2. Bus Interface > If PC size board, do you prefer > (A) an ISA interface or > (B) a PCI interface or > (C) No interface, just power and ground. C and then B > > 3. Bus Interface Controller > Do you require the board to incude: > (A) Separate PCI bus controller > (B) Separate ISA bus controller > (C) the device should be able to drive the bus > (D) No bus controller A > > 4. Xilinx FPGA > Should the device be > (A) directly soldered to the board or > (B) to a small module that's plugged into a connector on > the board ? either one > > 5. If the device is on the board, which device would you prefer? NA > > 6. What package and pincount? NA > > 7. Should the board include a microcontroller? > (A) Yes > (B) No B > > 8. What kind of connector should be used to bring out the IO? DIC connector > > 9. How large should the wire-wrap area be? 4" X 4" > > 10. The device will be able to be programmed through a serial prom. > (A) Include a parallel Flash device? > (B) Include a jtag (boundary scan) connector > (C) Include a xchecker download/readback connector > (D) If a micro is on the board, should the micro be able > to program the device? C and then D > > 11. Other featgures or comments > > Thanks for you help. > > Alain Arnaud > arnaud@ecla.comArticle: 9238
Hi.
The probability that the problem you are experiencing is some type of
common problem with the Xilinx XC4000XL devices is close to zero.
My guess is that the problem is almost certainly with either Leonardo, or
your VHDL design, and this is reinforced by your observation that the
problem always goes away when you add probes (I assume you do this by
changes in the VHDL), and recompile your design. Since you have said that
there are things that should be initialized, but aren't, that is probably
a good place to start looking. Also, since this is a state machine, you
should probably check that you have covered all possible (and impossible)
transitions in you design. Synthesis tools may do un-expected things when
given ambiguous specifications, such as infering latches, when none was
expected.
Although the problem looks like stuff you have seen with 'discrete'
logic, signal integrity problems tend not to occur within these chips,
although they can happen on the I/O. For instance, if you had a clock
signal arriving at the FPGA, and due to poor termination, the falling
edge of the clock signal looked like
(Mr ASCII head meets signal integrity):
-------------\
\
\
\ /\
\/ \
\
\
\________________
Your state machine might be transitioning on both the rising edge, as
expected, and on the falling edge because of the glitch. Placing a scope
probe on this clock signal at the chip may suppress the glitch
sufficiently that the problem stops. Plus, it is not uncommon that you
are so focussed on state transitions, that you have the scope zoomed in
on the rising edge, because you KNOW that that is when the transitions
occur, and you don't even see that the problem is actually the falling
edge of the clock. From you problem description, I don't think you are
facing this problem, but since I have been bitten by this I thought it
might be worth mentioning.
Other things worth checking:
Check that VCC is at the correct voltage
Have you got decoupling capacitors next to each power pin
(I use multilayer, monolithic, ceramic chip capacitors, 0.1uF)
Good luck, and please let us know of your progress.
Philip Freidin.
In article <6dg38g$cla$1@vixen.cso.uiuc.edu> janovetz@ews.uiuc.edu (Jacob W Janovetz) writes:
>Hello...
>
> I'm quite perplexed with a certain design I'm working on. The
>state machine is extremely simple and the speed is not pushing
>the device. I'm using Leonardo for VHDL synthesis into a Xilinx 4000XL
>FPGA. Trouble comes in the normal execution of my state machine.
>Certain items are not initialized as the code dictates they should
>be. The simulations come out perfectly.
> The perplexing part is that when I bring an internal signal out
>to the package in order to observe it on a scope or logic analyzer,
>the problem disappears so I can no longer observe it! This happens
>very consistently. If a signal is brought out -- no trouble.
>
> It seems similar to problems I've had with discrete logic where
>a signal is left floating or has weird capacitive effects so that
>placing a scope probe on the signal causes the trouble to disappear.
>
> Does anyone have any advice? I'd appreciate it! Something
>that may be common with 4000XL devices that I don't know about?
>
>
> Cheers,
> Jake
>
>--
> janovetz@uiuc.edu | Once you have flown, you will walk the earth with
> University of Illinois | your eyes turned skyward, for there you have been,
> | there you long to return. -- da Vinci
> PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 9239Since I have done little VHDL I wasn't going to post my answer, but noting the other posts being nothing to do with VHDL... IF you had been using schematic entry - I have seen this before. Let's say you have a D-type, and the wire to its Q output is not properly attached. It looks attached, but isn't really. Most schematic entry progs can produce this sort of thing, esp. after copying/pasting blocks of circuitry. The P&R software will see that D-type is not ever going to affect anything, so it minimises it away (removes it). It then works backwards, removing more circuitry, until it reaches a point where some net goes to an output pin, or such, and stops there. I once had a hilarious case where I deleted the main oscillator symbol (one had to, if simulating the whole device - I never found a way to "force" the oscillator output, in Viewlogic) and every single gate got minimised away, because the oscillator was ultimately clocking all D-types. That "design" routed very fast indeed... I don't know if an equivalent scenario is possible with VHDL but it would not suprise me. > I'm quite perplexed with a certain design I'm working on. The >state machine is extremely simple and the speed is not pushing >the device. I'm using Leonardo for VHDL synthesis into a Xilinx 4000XL >FPGA. Trouble comes in the normal execution of my state machine. >Certain items are not initialized as the code dictates they should >be. The simulations come out perfectly. > The perplexing part is that when I bring an internal signal out >to the package in order to observe it on a scope or logic analyzer, >the problem disappears so I can no longer observe it! This happens >very consistently. If a signal is brought out -- no trouble. > > It seems similar to problems I've had with discrete logic where >a signal is left floating or has weird capacitive effects so that >placing a scope probe on the signal causes the trouble to disappear. > > Does anyone have any advice? I'd appreciate it! Something >that may be common with 4000XL devices that I don't know about? 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: 9240
I thought PVCS would work on *binary* files too, no? 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: 9241
R. Mark Gogolewski wrote:
>
> The issue below of "how long will it take the suits to
> figure this out?" is compounded on both sides of the
> equation:
These are very good questions. I agree that the chicken-&-egg
problem persists until you dig really hard, which I will try
to do...
> How many vendors are going to shell out porting/support
> costs for a new OS without a customer promising the $$
> to buy it?
Actually, the costs of porting from another UNIX platform are
quite low. It's like porting from Sun Solaris to SGI IRIX.
The biggest cost is how to release for Linux packaging
conventions as opposed to SVR4 package conventions.
By constrast, going from UNIX APIs to WIN32 (NT or Win95)
is *quite* high. (I have made the mistake of seriously
underestimating such a port, even when there were NT experts
available to help.)
True, customers need to express some intent. But, this proposition
is not nearly as scary as going to a completely unrelated OS.
And the first EDA vendors in at the right price points are
going to give everyone else a very steep uphill battle.
Customers need to get a grip on what costs are important.
If your monetary software cost far outweighs your OS and hardware
cost, then a customer probably ought to stick to Solaris, simply for
the peace of mind. But as you drop software cost to below the
cost of hardware, things like memory requirement, stability and
support are more important factors.
Concerning memory: Linux typically takes less than NT. (Yes,
memory is cheap, but the more machines you have, the more
important this becomes.)
Concerning stability: Linux seems typically better than NT.
Concerning support: Have you ever tried to call Microsoft with
a non-trivial tech support question? Seriously, I think we
have to get real here. In either case, you are going to be
left to your own devices, or the advice and concern from
newsgroups like this one.
Managers *really* need to get a grip on this last one.
Is support really going to be different between Linux and NT?
> How many customers are going to put up $$ for a tool
> (and the machines, and the sys-admins) on a new OS
> without a guarantee of other software being there
> as well?
For a UNIX shop, Linux is not really a new OS, any more
than IRIX is new to a Solaris shop. It is perfectly reasonable
to run a mixed platform UNIX shop. The sys-admins will learn
quickly; they will know most of it already. If you are
conservative, you can do capture or layout on a Linux machine
and do heavy-duty simulation on Solaris. When your confidence
is up about up-time, you can plunge into simulators on Linux.
If you really want a Linux telephone support contract, and
are willing to pay what you pay for your Solaris contract,
we can probably find you one. (Linux distributor Red Hat
has been signing up commercial support partners.)
Conversely, introducing Linux to an NT shop is a mistake.
There is no sys-admin skill transfer except that the physical
hardware is the same.
The cost of Linux machines will be equal to (or probably)
less than the cost of NT machines. And if NT 5.0 beta is
any indication, you'd better buy more memory again.
Now, if the issue is that you're a single designer... and you've
got to pick a single machine to do all work your on... and
this includes long running simulation times..., then you've
really got problems. And it ain't just which OS to choose.
> Linux as an EDA OS is caught in a _classic_ chicken-&-egg
> problem.
Now that I've written this and think about it more, it may
be easier to get Linux adopted in EDA than in traditional
office applications, where Microsoft is historically strong.
We just have to come to our collective senses, and get the
"suits" to understand this.
> Mark
--Rick Kwan
Article: 9242
I received the following response from Xilinx' tech. support group on this
question.
"Don't connect means don't have anything connected to that
pin. In this case, a jumper would be correct, allowing for
pin isolation when using the Spartan part."
In the future, you may also want to post Xilinx-related technical questions
to hotline@xilinx.com. They're usually fairly prompt.
-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail: sknapp@optimagic.com
Web: http://www.optimagic.com
-----------------------------------------------------------
Laurent Gauch wrote in message <34FBDC06.444B@eiv.vsnet.ch>...
Spartan users,
I will use a XCS10 spartan in TQ144 package.
This spartan is almost pins compatible with XC4010E in TQ144 package.
-------------------------------------------------
pad number XCS10 XC4010E
in TQ144 in TQ144
pad name pad name
-------------------------------------------------
P34 Don't Connect O(M1)
P36 MODE I(M0)
P38 Don't Connect I(M2)
P117 N.C. pin I/O
-------------------------------------------------
I will design a compatible PCB (XCS10 and XC4010E in TQ144).
FPGAs are used in Master Serial Mode (MODE=0 or M0,M1,M2=0).
My question:
How understand the 'Don't Connect' term? To design a pin compatible PCB,
I must use a jumper to disconnect P34 and P38 (XCS10)or not.
Thank you, Laurent
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
Laurent Gauch
Ecole d'Ingénieurs du Valais (EIV / ISW)
Route du Rawyl 47
1950 Sion, Switzerland
Tel: ++41 (0)27 32 43 363
Fax: ++41 (0)27 32 43 315
E-mail: laurent.gauch@eiv.vsnet.ch
http://www.eiv.ch/universel/gc/electro/micro/index.htm
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
Article: 9243
Is there such a thing as a programmable analog switch matrix/crossbar?
I find digital ones (Lattice, Aptix FPIC), analog muxes and complete
switch boxes for measurement equipment, some for analog mixers, but
both extremely expensive. I'd like to use these with a Zetex TRAC
device for lab exercises, so fmax=4MHz, crosstalk -60dB, Ron
uncritical if tightly distributed. Before I forget, programmable
resitors/capacitors would be a boon, too although I could use analog
muxes for these.
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone: +49 351 463 - 8325
Article: 9244
Rick,
Great points.
You are very correct on the following two things:
[] A port from any other Unix OS to Linux is essentially cake.
[] Unix houses can very easily switch to Linux while NT houses
would have more difficulty.
BTW, I _love_ the idea of Linux. However, if I ran a pure
Solaris group, the only $$ I would really save would be on hardware.
The EDA software won't get cheaper on Linux. The admin support
won't get cheaper, etc. , etc. In fact, I'll have to support
both for awhile when switching, so my admin costs go up.
I think this is one reason that we do not see large groups in
many companies strongly pushing global adoption of Linux. Small
groups and individuals are pushing it because you can buy a sweet
Linux machine for less than $5K, and a Solaris machine is going
to be quite a bit more.
Anyway, my folowup point is simply that most software companies
have a ton of OSs to support. More than they would certainly
want. Once you are supporting 5-8 Unix OS's and NT, it becomes
a more painful proposition to support another one.
Chicken & egg.
$$ from customers is what will make the difference. In EDA land,
this will mean a large group or company pushing a full switch to
Linux.
Mark
In article <34FD3C88.FFBE8CE@ix.netcom.com>, Rick Kwan
<rkwan@ix.netcom.com> wrote:
>> How many vendors are going to shell out porting/support
>> costs for a new OS without a customer promising the $$
>> to buy it?
>
>Actually, the costs of porting from another UNIX platform are
>quite low. It's like porting from Sun Solaris to SGI IRIX.
>The biggest cost is how to release for Linux packaging
>conventions as opposed to SVR4 package conventions.
>By constrast, going from UNIX APIs to WIN32 (NT or Win95)
>is *quite* high. (I have made the mistake of seriously
>underestimating such a port, even when there were NT experts
>available to help.)
>
>True, customers need to express some intent. But, this proposition
>is not nearly as scary as going to a completely unrelated OS.
>And the first EDA vendors in at the right price points are
>going to give everyone else a very steep uphill battle.
>
>Customers need to get a grip on what costs are important.
>If your monetary software cost far outweighs your OS and hardware
>cost, then a customer probably ought to stick to Solaris, simply for
>the peace of mind. But as you drop software cost to below the
>cost of hardware, things like memory requirement, stability and
>support are more important factors.
>
>Concerning memory: Linux typically takes less than NT. (Yes,
> memory is cheap, but the more machines you have, the more
> important this becomes.)
>Concerning stability: Linux seems typically better than NT.
>Concerning support: Have you ever tried to call Microsoft with
> a non-trivial tech support question? Seriously, I think we
> have to get real here. In either case, you are going to be
> left to your own devices, or the advice and concern from
> newsgroups like this one.
>Managers *really* need to get a grip on this last one.
>Is support really going to be different between Linux and NT?
>
>> How many customers are going to put up $$ for a tool
>> (and the machines, and the sys-admins) on a new OS
>> without a guarantee of other software being there
>> as well?
>
>For a UNIX shop, Linux is not really a new OS, any more
>than IRIX is new to a Solaris shop. It is perfectly reasonable
>to run a mixed platform UNIX shop. The sys-admins will learn
>quickly; they will know most of it already. If you are
>conservative, you can do capture or layout on a Linux machine
>and do heavy-duty simulation on Solaris. When your confidence
>is up about up-time, you can plunge into simulators on Linux.
>
>If you really want a Linux telephone support contract, and
>are willing to pay what you pay for your Solaris contract,
>we can probably find you one. (Linux distributor Red Hat
>has been signing up commercial support partners.)
>
>Conversely, introducing Linux to an NT shop is a mistake.
>There is no sys-admin skill transfer except that the physical
>hardware is the same.
>
>The cost of Linux machines will be equal to (or probably)
>less than the cost of NT machines. And if NT 5.0 beta is
>any indication, you'd better buy more memory again.
>
>Now, if the issue is that you're a single designer... and you've
>got to pick a single machine to do all work your on... and
>this includes long running simulation times..., then you've
>really got problems. And it ain't just which OS to choose.
>
>> Linux as an EDA OS is caught in a _classic_ chicken-&-egg
>> problem.
>
>Now that I've written this and think about it more, it may
>be easier to get Linux adopted in EDA than in traditional
>office applications, where Microsoft is historically strong.
>We just have to come to our collective senses, and get the
>"suits" to understand this.
>
>> Mark
>
>--Rick Kwan
Article: 9245I am delighted about all the good things I read about Linux. I use it as a development platform. I would also like to tell you about a thing that doesn't seem to be well known for some reason : our company offers a full fledged Verilog Simulator Super-FinSim on Linux. If you'd like to try it out please let me know. -Alex Seibulescu Sr, Software Engineer R. Mark Gogolewski wrote: > Rick, > > Great points. > > You are very correct on the following two things: > > [] A port from any other Unix OS to Linux is essentially cake. > > [] Unix houses can very easily switch to Linux while NT houses > would have more difficulty. > > BTW, I _love_ the idea of Linux. However, if I ran a pure > Solaris group, the only $$ I would really save would be on hardware. > The EDA software won't get cheaper on Linux. The admin support > won't get cheaper, etc. , etc. In fact, I'll have to support > both for awhile when switching, so my admin costs go up. > > I think this is one reason that we do not see large groups in > many companies strongly pushing global adoption of Linux. Small > groups and individuals are pushing it because you can buy a sweet > Linux machine for less than $5K, and a Solaris machine is going > to be quite a bit more. > > Anyway, my folowup point is simply that most software companies > have a ton of OSs to support. More than they would certainly > want. Once you are supporting 5-8 Unix OS's and NT, it becomes > a more painful proposition to support another one. > > Chicken & egg. > > $$ from customers is what will make the difference. In EDA land, > this will mean a large group or company pushing a full switch to > Linux. > > Mark > > In article <34FD3C88.FFBE8CE@ix.netcom.com>, Rick Kwan > <rkwan@ix.netcom.com> wrote: > > >> How many vendors are going to shell out porting/support > >> costs for a new OS without a customer promising the $$ > >> to buy it? > > > >Actually, the costs of porting from another UNIX platform are > >quite low. It's like porting from Sun Solaris to SGI IRIX. > >The biggest cost is how to release for Linux packaging > >conventions as opposed to SVR4 package conventions. > >By constrast, going from UNIX APIs to WIN32 (NT or Win95) > >is *quite* high. (I have made the mistake of seriously > >underestimating such a port, even when there were NT experts > >available to help.) > > > >True, customers need to express some intent. But, this proposition > >is not nearly as scary as going to a completely unrelated OS. > >And the first EDA vendors in at the right price points are > >going to give everyone else a very steep uphill battle. > > > >Customers need to get a grip on what costs are important. > >If your monetary software cost far outweighs your OS and hardware > >cost, then a customer probably ought to stick to Solaris, simply for > >the peace of mind. But as you drop software cost to below the > >cost of hardware, things like memory requirement, stability and > >support are more important factors. > > > >Concerning memory: Linux typically takes less than NT. (Yes, > > memory is cheap, but the more machines you have, the more > > important this becomes.) > >Concerning stability: Linux seems typically better than NT. > >Concerning support: Have you ever tried to call Microsoft with > > a non-trivial tech support question? Seriously, I think we > > have to get real here. In either case, you are going to be > > left to your own devices, or the advice and concern from > > newsgroups like this one. > >Managers *really* need to get a grip on this last one. > >Is support really going to be different between Linux and NT? > > > >> How many customers are going to put up $$ for a tool > >> (and the machines, and the sys-admins) on a new OS > >> without a guarantee of other software being there > >> as well? > > > >For a UNIX shop, Linux is not really a new OS, any more > >than IRIX is new to a Solaris shop. It is perfectly reasonable > >to run a mixed platform UNIX shop. The sys-admins will learn > >quickly; they will know most of it already. If you are > >conservative, you can do capture or layout on a Linux machine > >and do heavy-duty simulation on Solaris. When your confidence > >is up about up-time, you can plunge into simulators on Linux. > > > >If you really want a Linux telephone support contract, and > >are willing to pay what you pay for your Solaris contract, > >we can probably find you one. (Linux distributor Red Hat > >has been signing up commercial support partners.) > > > >Conversely, introducing Linux to an NT shop is a mistake. > >There is no sys-admin skill transfer except that the physical > >hardware is the same. > > > >The cost of Linux machines will be equal to (or probably) > >less than the cost of NT machines. And if NT 5.0 beta is > >any indication, you'd better buy more memory again. > > > >Now, if the issue is that you're a single designer... and you've > >got to pick a single machine to do all work your on... and > >this includes long running simulation times..., then you've > >really got problems. And it ain't just which OS to choose. > > > >> Linux as an EDA OS is caught in a _classic_ chicken-&-egg > >> problem. > > > >Now that I've written this and think about it more, it may > >be easier to get Linux adopted in EDA than in traditional > >office applications, where Microsoft is historically strong. > >We just have to come to our collective senses, and get the > >"suits" to understand this. > > > >> Mark > > > >--Rick KwanArticle: 9246
I know this is a bit off-topic for this group, but I know there are many of you who use Viewlogic Viewdraw for schematic-based FPGA designs. I'd like to find the file format for the symbols created in Viewdraw. These are ASCII files, and I've already done some reverse-engineering and found some of the info. However, as long as this format has been around, I'd be surprised if the information isn't already available. I've put in a request to Viewlogic, but haven't gotten a response yet. Also, does anyone know of any newsgroups such as this which are focused on schematic capture, or EE-directed EDA tools in general. I've done some searching using AltaVista, but no cigar so far. Paul Urbanus urb@ti.com ****************************************************************** * * Never wrestle with a hog - you get dirty and the hog likes it * ******************************************************************Article: 9247
peter: : IF you had been using schematic entry - I have seen this before. Let's : say you have a D-type, and the wire to its Q output is not properly : attached. It looks attached, but isn't really. Most schematic entry : progs can produce this sort of thing, esp. after copying/pasting : blocks of circuitry. rk: new right here you were a viewlogic user. gotta zoom in and make sure you don't have some of these little squares instead of the little dots. hate when that happens.Article: 9248
Maybe of interest: > The AD8116 is a high speed 16 × 16 video crosspoint switch matrix. It offers a -3 dB signal bandwidth greater than 200 > MHz and channel switch times of 60 ns with 0.1% settling. With -70 dB of crosstalk and -105 dB of isolation (@ 5 MHz), > the AD8116 is useful in many high speed applications. The differential gain and differential phase errors of better than > 0.01% and 0.01°, respectively, along with 0.1 dB flatness out to 60 MHz make the AD8116 ideal for video signal > switching. see: http://products.analog.com/products/info.asp?product=AD8116 regards, tom Achim Gratz wrote: > > Is there such a thing as a programmable analog switch matrix/crossbar? > I find digital ones (Lattice, Aptix FPIC), analog muxes and complete > switch boxes for measurement equipment, some for analog mixers, but > both extremely expensive. I'd like to use these with a Zetex TRAC > device for lab exercises, so fmax=4MHz, crosstalk -60dB, Ron > uncritical if tightly distributed. Before I forget, programmable > resistors/capacitors would be a boon, too although I could use analog > muxes for these. > ----------- Tom Burgess National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 9249
INTERNATIONAL SYMPOSIUM ON PHYSICAL DESIGN 1998
Embassy Suites, Monterey, CA
April 6-8, 1998
http://www.ee.iastate.edu/~ispd98
****************************************************
***HOTEL RESERVATION DEADLINE NEXT WEEK (March 9)***
***EARLY REGISTRATION DEADLINE ON March 10***
****************************************************
ADVANCE PROGRAM
The International Symposium on Physical Design provides a high-quality forum
for the exchange of ideas and results in critical areas related to the physical
design of VLSI systems. This meeting evolved from the ACM/SIGDA Physical
Design Workshops held during the years 1987-1996. The first Symposium in 1997
was highly successful and drew such a large number of attendees that
registration had to be closed a month early. The scope of this symposium
includes all aspects of physical design, from interactions with behavior- and
logic-level synthesis, to back-end performance analysis and verification.
MONDAY, April 6
0915-0930 Welcome
M. Sarrafzadeh, General Chair (Northwestern)
D. F. Wong, Program Chair (UT-Austin)
0930-1030 Keynote Address
"Perspectives on Systems at 1 GHz and beyond"
Dave LaPotin (IBM Austin Research Laboratory)
1030-1100 BREAK
1100-1230 Session 1: Floorplanning and Placement
Chairs: C.K. Cheng (UCSD) and Jochen Jess (Eindhoven)
"On Wirelength Estimations for Row-Based Placement"
A.B. Kahng, S. Mantik, I.L. Markov, A. Zelikovsky (UCLA)
"Performance-Driven Soft-Macro Clustering and Placement by
Preserving HDL Design Hierarchy"
H.-P. Su, A.C.-.H. Wu, Y.-L. Lin (Tsing Hua)
"Nostradamus: A Floorplanner of Uncertain Design"
K. Bazargan, S. Kim, M. Sarrafzadeh (Northwestern)
1230-1430 Lunch (Pinot Noir Room)
Special Address: "Impact of Web Technologies on EDA System
Architectures"
A. R. Newton (UCB)
1430-1600 Tutorial: "Timing Metrics for Physical Design of Deep
Submicron Technologies "
Presenter: L. Pillegi (CMU)
Panelists: J. Cong (UCLA)
S. Otto (Intel)
A. Yang (Washington)
1600-1630 BREAK
1630-1730 Special Address: "Moore's Law and Physical Design of ICs"
W. Maly (CMU)
1730-1830 Session 2: Interconnect Optimization
Chairs: M. Alexander (Washington State) and
Y.-L. Lin (Tsing Hua)
"Greedy Wire-Sizing is Linear Time"
C.C.N. Chu, D.F. Wong (UT-Austin)
"An Efficient Technique for Device and Interconnect
Optimization in Deep Submicron Designs"
J. Cong, L. He (UCLA)
1900-2100 Dinner (Pinot Noir Room)
Special Address:
"Consorting with the Consortia: Cooperative Research
For Fun and Profit"
W. H. Joyner (SRC)
TUESDAY, April 7
0830-0930 Session 3: Layout Methodologies for RF Circuits
Chairs: M. Pedram (USC) and W. Dai (UCSC)
"Device-Level Early Floorplanning Algorithms for RF Circuits"
M. Aktuna, R.A. Rutenbar, L. R. Carley (CMU)
"A Layout Approach to Monolithic Microwave IC"
A. Nagao, T. Kambe (SHARP); I. Shirakawa (Osaka)
0930-1030 Session 4: Framework and Benchmarks
Chairs: D. Hill (Synopsys) and L. Jones (Motorola)
"CHDStd--Application Support for Reusable Hierarchical
Interconnect Timing Views"
S. Grout, G. Ledenbach, R. G. Bushroe, P. Fisher,
A. Chokhavtia (Sematech); D. Cottrell, D. Mallis
(Silicon Integration Initiative); S. DasGupta,
J. Morrell (IBM)
"The ISPD Circuit Benchmark Suite"
C.J. Alpert (IBM)
1030-1100 BREAK
1100-1230 Panel: "Given that SEMATECH is levelling the semiconductor
technology playing field, will corporate CAD (in
particular, PD) tools continue to serve as enablers/
differentiators of technology in the future?"
Organizer: S. DasGupta (IBM)
Panelists:
B. Beers, IBM
M. Khaira, Intel
R. Abrishami, Fujitsu Microelectronics
J. Hutt, Synopsys
L. Scheffer, Cadence
D. Guiou, Mentor Graphics
V. Kulkarni, Avant!
1230-1330 Lunch (Atrium Court)
1330-1430 Session 5: "PD for Manufacturability"
Chairs: M. Wiesel (Intel), R. Rutenbar (CMU)
"Critical Area Computation--A New Approach"
E. Papadopoulou (IBM), D.T. Lee (Northwestern)
"Filling and Slotting: Analysis and Algorithms"
G. Robins, A. Singh (Virginia); H. Wang (UCLA);
A. Zelikovsky (Virginia)
1430-1530 Special Address: "Global Wires: Harmful?"
R. Otten (Delft)
1530-1600 BREAK
1600-1645 Session 6: Poster Presentations
Chairs: E. Yoffa (IBM) and G. Robins (Virginia)
"Partioning Using Second-Order Information and Stochastic-Gain
Functions"
S. Dutt (UI-Chicago), H. Theny (Intel)
"A Parallel Algorithm for Zero Skew Clock Tree Routing"
Z. Xing, P. Banerjee (Northwestern)
"On Convex Formulation of the Floorplan Area Minimization
Problem"
T. Chen, M. Fan (Georgia Tech)
"A Pattern Matching Algorithm for Verification and Analysis
of Very Large IC Layouts"
M. Niewczas, W. Maly, A. Strojwas (CMU)
"LIBRA--A Library-Independent Framework for Post-Layout
Performance Optimization"
R. Huang (UCSB), Y. Wang (Avant!), K.-T. Cheng (UCSB)
"Estimation of Maximum Current Envelope for Power Bus
Analysis and Design"
S. Bobba, I.N. Hajj (Illinois)
"New Efficient Algorithms for Computing Effective Capacitance"
S. Muddu (SGI)
"Calculation of Ramp Response of Lossy Transmission Lines Using
Two-Port Network Functions"
P. Heydari, M. Pedram (USC)
"Switch-Matrix Architecture and Routing for FPDs"
G.-M. Wu, Y.-W. Chang (Chiao-Tung)
1645-1745 Poster Session
1900-2200 Banquet (Rancho Can~ada Golf Club)
WEDNESDAY, April 8
0830-1000 Session 7: Efficient Representation in Placement
Chairs: R. Otten (Delft) and C. Sechen (Washington)
"Sequence-Pair Based Placement Method for Hard/Soft/Pre-placed
Modules"
H. Murata, E.S. Kuh (UCB)
"Rectilinear Block Placement using Permutation-Pair"
J. Xu, C.K. Cheng (UCSD)
"Topology Constrained Rectilinear Block Packing for Layout
Reuse"
M. Kang, W. Dai (UCSC)
1000-1030 BREAK
1030-1200 Panel: "Process development and its impact on Physical Design"
Moderator: N. Sherwani (Intel)
Panel members: J. Cong (UCLA)
D. Lapotin (IBM)
J. Rey (Cadence)
1230-1400 Lunch (Pinot Noir Room)
1400-1530 Tutorial: "Why Clustering Is the Key to Partitioning"
Presenter: A. Kahng (UCLA)
Panelists: C. Alpert (IBM)
G. Janac (Cadence)
J. Lillis (UI - Chicago)
1530-1700 Session 8: Routing Algorithms
Chairs: J. Cong (UCLA) and J. Fishburn (Lucent)
"Chip-Level Area Routing"
L.-C. Liu, H.-P. Tseng, C. Sechen (Washington)
"Routing Tree Topology Construction to Meet Interconnect
Timing Constraints"
H. Hou (Iowa State), S. Sapatnekar (Minnesota)
"Analysis, Reduction and Avoidance of Crosstalk on VLSI Chips"
T. Stoehr, M. Alt (IBM); A. Hetzel (Bonn), J. Koehl (IBM)
1700 Symposium Closes
%%==========================================================================%%
%% Symposium Organization %%
%%==========================================================================%%
General Chair
M. Sarrafzadeh (Northwestern)
Past Chair
A. B. Kahng (UCLA)
Steering Committee
J. P. Cohoon (Virginia)
S. DasGupta (IBM)
M. Marek-Sadowska (UC Santa Barbara)
B. Preas (Xerox PARC)
E. Yoffa (IBM)
Technical Program Chair
D. F. Wong (UT-Austin)
Technical Program Committee
M. J. Alexander (Washington State) C. K. Cheng (UC San Diego)
J. Cong (UCLA) W. W.-M Dai (UC Santa Cruz)
J. Fishburn (Lucent) D. Hill (Synopsys)
J. A. G. Jess (Eindhoven) L. Jones (Motorola)
S. M. Kang (Illinois) Y.-L. Lin (Tsing Hua)
M. Pedram (USC) R. Rutenbar (CMU)
C. Sechen (Washington) M. Wiesel (Intel)
T. Yoshimura (NEC)
Publication Chair
D. Hill (Synopsys)
Panel Chair
N. Sherwani (Intel)
Local Arrangements Chair
R.-S. Tsay (Axis Systems)
Publicity Chair
S. Sapatnekar (Minnesota)
Treasurer
S. Souvannavong
Sponsors
ACM Special Interest Group on Design Automation
in cooperation with
IEEE Circuits and Systems Society and IEEE Computer Society
Additional Support From:
Avant! Corporation
Ambit Design Systems
%%==========================================================================%%
%% Hotel Accommodations and Travel %%
%%==========================================================================%%
ISPD-98 is being held at the Embassy Suites Monterey Bay in Monterey,
California, located on the beautiful Monterey Peninsula, two blocks from
the beach, at the intersection of Canyon Del Rey and Del Monte Boulevard.
The address is
Embassy Suites Monterey Bay Hotel & Conference Center
1441 Canyon Del Rey
Seaside, California 93955
Tel: (408) 393 1115
Fax: (408) 393 1113
For hotel reservations, call (408) 393 1115 or (800)362 2779.
A block of rooms is being held for the nights of Sunday through Wednesday
(April 5 through April 8). Room rates are $125 per night for a single room
and $145 per night for a double room. Any individual cancellations within 72
hours from the date of arrival will be billed for (1) night's stay, plus tax.
+---------------------------------------------------------+
| Please make room reservations directly with the hotel |
| at either 1-408-393-1115 or 1-800-362-2779, mentioning |
| ``ISPD'' to get the special rate. |
+---------------------------------------------------------+
The number of rooms available at this rate is limited, and are only being
held through March 9. Early room reservation is highly recommended.
%%==========================================================================%%
%% ISPD-98 Advance Registration Form %%
%%==========================================================================%%
Name: _______________________________________________________
Company/University: _________________________________________
Responsibility/Title: _______________________________________
Address: ____________________________________________________
City: _______________________________ State: ________________
Country: ______________________ Postal Code: ________________
Phone: ________________________ Fax: ________________________
Email: ______________________________________________________
Food Choices:
[ ] Vegetarian meals
[ ] Non-vegetarian meals
[ ] Either one is fine
Advance Late
(Through March 10) (After March 10)
ACM/IEEE Members [ ] $350 [ ] $425
Non-Members [ ] $425 [ ] $500
Full-Time Students [ ] $175 [ ] $225
Student ID is required if registering as a student.
ACM or IEEE Member No. _____________________________
Registration fee includes meals and Banquet. The Banquet will be held at
the Rancho Can~ada Golf Club and ISPD will provide a bus service to the site.
Payment may be submitted via personal or company check in US funds only and
drawn on a US bank, made payable to ``ACM/International Symposium on
Physical Design''. Payment may also be made with credit card (circle):
Mastercard Visa American Express
Credit Card # _______________________________________________
Expiration Date: ______________ Total Payment: ______________
Name as it appears on credit card: __________________________
Signature: ___________________________ Date: ________________
Please mail or FAX (credit card only) your completed registration form to:
ISPD-98 Symposium Registration
Sally Souvannavong, Treasurer
P.O. Box 395
Pullman, WA 99163-0395
FAX: 1-509-332-6118
Email registration will not be accepted. Cancellations must be in writing
and must be received by March 24, 1998. Questions concerning symposium
registration should be directed to Sally Souvannavong at 1-509-334-3162,
Email: ispd98@eecs.wsu.edu.
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