ChipNews - Chipworks Inside Technology Newsletter - Issue 1, 2003

2003-05-27 Thread Chipworks
Title: ChipNews - Issue 1, 2003










  
 
  
 
  

 
  Assertive 
Program Licensing | Interconnects 
and Dielectrics | New Reports | Conferences 
| Silicon Art | Contact Us 
  

 
   
  By Chuck Neuenschwander, 
  Principal, Patent Solutions
  
  If your company deals with cutting edge technology chances are that 
  you will be confronted at some time or another with a patent licensing 
  dispute. These disputes arise out of two different kinds of situations: 
  

defensive 
licensing
 proactive or assertive licensing campaigns

Usually the 
  first encounter with a licensing negotiation arises out of a defensive 
  situation, that is, a company is being charged with infringing a 
  competitors patents. The company is then faced with either paying 
  a significant royalty on its product and/or a costly lawsuit. This 
  is usually the wake-up call to management that they should be asserting 
  their intellectual property rights against others in their industry 
  rather than constantly being on the defensive. 

   
 Assertive 
patent licensing (charging someone with infringement) is usually 
an outgrowth of management strategy. It can however entail 
significant financial costs. A company must allocate human 
resources to various tasks such as reviewing patents, examining 
potential prior art problems, and developing settlement strategies. 
In addition there will be significant external costs for reverse 
engineering, legal consultations, travel expenses, and, finally, 
potential litigation expenditures. For these reasons, more 
and more corporations are outsourcing their licensing programs 
to external companies that specialize in this area. Ideally, 
these external companies should also have access to their 
own legal and reverse engineering resources. con't
 
  


 
  
By Dick James, Senior Technical Advisor  
In the Spring of 2002, Chipworks published an article 
  entitled Interconnect  Dielectric Technologies: Whats 
  really going on?. It was based on our then experience in this technology 
  arena. We received a lot of feedback on this article and decided 
  to provide our readers with a follow up. Feedback is an important 
  part of articles like this, and we appreciate your comments. 
We have had an ongoing discussion on what constitutes 
  low-k. The consensus seems to be that true low-k 
  processing uses dielectrics with k-values of 3 or less, and FSG 
  (fluorinated glass with k ~3.6) is merely lower-k.
 130 
  nm processes are now much more prevalent, but despite much media 
  hype last year, they have not had an easy introduction. Many suppliers 
  have had difficulties in ramping production with decent yield, and 
  there have been embarrassing slowdowns in deliveries of high-end 
  products. These delays have one main cause - trouble with integrating 
  low-k dielectrics into processes newly developed with copper metallization. 
  IBM seems to be capitalizing on these problems and is picking up 
  business from some of TSMCs and UMCs customers. 
  con't 
  


 
  
  
  Please contact 
Rick Patricio by e-mail at [EMAIL PROTECTED], 
phone +1.613.829.0414 or fax +1.613.829.0515 for more details 
on Standard Reports release dates and prices, or visit our website 
at www.chipworks.com 
for a list of all available reports.



   

   


  In todays 
highly competitive market, it is important to maximize your 
knowledge of the latest electronic devices available. Our 
timely reports will provide you with a convenient and effective 
way to keep informed of innovations in semiconductor technology. 

 
  
   
 
  
   

Re: linking ghc object files with mingw-g++

2003-05-27 Thread johago
Hello again!

This is gvc -v  output:

Hsc static
flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -f
do-lambda-eta-expansion -flet-no-escape
*** Linker
c:\ghc\ghc-5.04.3\gcc -Bc:\ghc\ghc-5.04.3\gcc-lib/ -v -o a.out
-DDONT_W
ANT_WIN32_DLL_SUPPORT main.o Test.o Test_stub.o -Lc:/ghc/ghc-5.04.3
-L
c:/ghc/ghc-5.04.3/gcc-lib -lHShaskell98 -lHSbase -lHSbase_cbits
-lwsock3
2 -lmsvcrt -lkernel32 -luser32 -lHSrts -lm -lgmp -lwinmm
-lwsock
32 -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info -u
_G
HCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u
_GHCziPtr_Pt
r_static_info -u _GHCziWord_Wzh_static_info -u
_GHCziInt_I8zh_static_inf
o -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info
-u _
GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u
_GHCziWord_
W16zh_static_info -u _GHCziWord_W32zh_static_info -u
_GHCziWord_W64zh_st
atic_info -u _GHCziStable_StablePtr_static_info -u
_GHCziBase_Izh_con_in
fo -u _GHCziBase_Czh_con_info -u _GHCziFloat_Fzh_con_info -u
_GHCziF
loat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u
_GHCziPtr_FunPtr_con_info
 -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure
-u _
GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u
_GHCziIOBa
se_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u
_GHCziI
OBase_NonTermination_closure -u _GHCziIOBase_BlockedOnDeadMVar_closure
-u
 _GHCziIOBase_Deadlock_closure -u
_GHCziWeak_runFinalizzerBatch_closure -
u ___stginit_Prelude
Reading specs from c:/ghc/ghc-5.04.3/gcc-lib/specs
gcc version 2.95.3-6 (mingw special)
$ c:/ghc/ghc-5.04.3/gcc-lib/ld.exe -Bdynamic -o a.out -u
_GHCziBase_Izh_static_
info -u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u
_GHCziFloa
t_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u
_GHCziWord_Wzh_static_info -u
 _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u
_GHCziInt_I32zh_s
tatic_info -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u
_GH
CziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u
_GHCziWord_W64zh_s
tatic_info -u _GHCziStable_StablePtr_static_info -u
_GHCziBase_Izh_con_info -u
_GHCziBase_Czh_con_info -u _GHCziFloat_Fzh_con_info -u
_GHCziFloat_Dzh_con_info
 -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u
_GHCziStable_StableP
tr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u
_GHCziPac
k_unpackCString_closure -u _GHCziIOBase_stackOverflow_closure -u
_GHCziIOBase_h
eapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u
_GHCziIOBase_Bloc
kedOnDeadMVar_closure -u _GHCziIOBase_Deadlock_closure -u
_GHCziWeak_runFinaliz
zerBatch_closure -u ___stginit_Prelude
c:/ghc/ghc-5.04.3/gcc-lib/crt2.o -Lc:/gh
c/ghc-5.04.3 -Lc:/ghc/ghc-5.04.3/gcc-lib -Lc:/ghc/ghc-5.04.3/gcc-lib -L/ming
w/l
ib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -L/mingw/lib/gcc-lib/min
gw3
2/2.95.3-6/../../.. main.o Test.o
Test_stub.o -lHShaskell98 -lHSbase -lHSbase_c
bits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lHSrts -lm -lgmp -lwinmm -lwsoc
k32
 -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell3
2 -
lmingw32 -lgcc -lmoldname -lmsvcrt
main.o(.eh_frame+0x11):main.cpp: undefined reference to
`__gxx_personality_v0'

Any hint what this __gxx_personality_v0 means?


Johannes
[EMAIL PROTECTED]



___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users