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
Thank you :-)
I tried this
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity counter_test is
Port ( clk : in std_logic;
cnt : out std_logic_vector(7 downto 0);
extra : out std_logic);
end counter_test;
architecture Behavioral of counter_test is
signal counter_intern : std_logic_vector (23 downto 0) := (others =>
'0');
begin
process(clk, counter_intern)
begin
if rising_edge(clk) then
counter_intern <= counter_intern + 1;
end if;
end process;
cnt <= counter_intern(8 downto 1);
extra <= counter_intern(23);
end Behavioral;
I added one more output and copied counter_intern(23) to that output. And
now it works ok.
Now I know why the synthesizer complained.
"Jonathan Bromley" <jonathan.bromley@doulos.com> skrev i meddelandet
news:t3m4019i26nhaqcgj1hair69jquums5hpd@4ax.com...
> On Thu, 3 Feb 2005 17:30:40 +0100, "Mr M" <student@telia.se> wrote:
>
> >I'm wondering. I wrote the following VHDL-code (this is
> >only an example, not something usefull):
>
> [...]
>
> >use IEEE.STD_LOGIC_ARITH.ALL;
> >use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> Please consider migrating to NUMERIC_STD instead of these
> old and poorly-standardised packages.
>
> >entity counter_test is
> > Port ( clk : in std_logic;
> > cnt : out std_logic_vector(7 downto 0));
> >end counter_test;
>
> So you have an 8-bit output....
>
> >architecture Behavioral of counter_test is
> > signal counter_intern : std_logic_vector (23 downto 0)
> > := (others => '0');
>
> and a 24-bit internal counter...
>
> >begin
> [snip standard counter process]
> >
> > cnt <= counter_intern(7 downto 0);
>
> and you port out only the bottom 8 bits of the counter.
>
> >And when I synthesize it I get the following warnings:
> >WARNING:Xst:1291 - FF/Latch <counter_intern_22> is unconnected in block
>
> [etc, etc]
>
> >Why do I get that when I only want a part of the counter_intern vector?
>
> Because the synthesis tool has correctly detected that you make no use
> of its upper 16 bits, and has optimised them away. If you had instead
> picked the TOP eight bits of the counter...
>
> cnt <= counter_intern(23 downto 16);
>
> then the tool could not optimise away the lower 16 bits and you
> would not get the messages.
>
> Be grateful; the synthesis tool is trying to save you money
> by fitting your design in a smaller part :-)
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
Article: 78576Hi, I am trying to looking to look up LUT in the Xilinx software, but doesn't really help. Exactly what is LUT? And how does one use it? Thanks for helping, AnnArticle: 78577
Ann wrote: > Hi, > > I am trying to looking to look up LUT in the Xilinx software, but doesn't really help. Exactly what is LUT? And how does one use it? > > Thanks, Ann LUT stands for Look Up Table which is what is used to implement most of the logic in an FPGA. In this case the LUT can be used as a shift register (SRL, IIRC) which you *should* be able to find in the Xilinx docs. They certainly talk about it a lot in the marketing info. Or you can use the LUT as a 16x1 memory. I am sure that is also well documented and can be read back. -- Rick Collins rick.collins@XYarius.com Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave. 301-682-7772 Voice Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.comArticle: 78578
Ann wrote: > Hi, > > I am trying to looking to look up LUT in the Xilinx software, but doesn't really help. Exactly what is LUT? And how does one use it? > > Thanks for helping, Ann Look-Up Table - the basic combinatorial element of the FPGA. In this case you want to take this LUT, which is a small RAM and configure it as a shift-register (Xilinx-specific feature) using the "SRL16" primitive. Look it up in the Libraries guide. Good luck, GaborArticle: 78579
Kolja Sulimma wrote: > Symon wrote: > > p.s. > > Hey Kolja, did you look at those resistor packs? > Yes I did. I used them in previous projects. The problem with this one > are the vias. > I can run differential pairs nicely pitch matched from the 0.5mm pitch > pqfp to the 1mm bga. Now 0.5mm single in line resistor packs would be > graet (Pinout A1-A2-B1-B2-....). But dual in line resistor packs are > rather useless unless I can route a signal between the pins. > > I can't meet a 0.5mm via pitch, so the resistors can not sit at the back > . And I can not have the vias on the inside of the PQFP (at least not > all of them) because it is almost completely filled with a thermal pad. > Check out Bourns CAT16-PT4F4 or CAT16-PT2F2. These are 0.8mm, not 0.5 but they route through nicely on the surface (they're DIP but work like a SIP because opposite pads connect together). > But I am going to find a way to squeeze in the resistors.... > > KoljaArticle: 78580
Hm...I read something about the USER1 and USER2 registers and also found this code in the software manual Verilog Instantiation Template // BSCAN_SPARTAN3:Boundary Scan primitve for connecting internal logic // JTAG interface. Spartan-II // Xilinx HDL Libraries Guide version 7.1i BSCAN_SPARTAN3 BSCAN_SPARTAN3_inst ( .CAPTURE(CAPTURE), // CAPTURE output from TAP //controller .DRCK1(DRCK1), // Data register output - //USER1 functions .DRCK2(DRCK2), // Data register output - //USER2 functions .RESET(RESET), // Reset output from //TAP controller .SEL1(SEL1), // USER1 active output .SEL2(SEL2), // USER2 active output .SHIFT(SHIFT), // SHIFT output from //TAP controller .TDI(TDI), // TDI output from // TAP controller .UPDATE(UPDATE), // UPDATE output from //TAP controller .TDO1(TDO1), // Data input for USER1 //function .TDO2(TDO2) // Data input for USER2 //function ); Has anyone used this feature before? Does it work in reading out a user defined register? If you know anything about this feature, please let me know. Thanks, AnnArticle: 78581
Verilog Instantiation Template // BSCAN_SPARTAN3:Boundary Scan primitve for connecting internal logic // JTAG interface. Spartan-II // Xilinx HDL Libraries Guide version 7.1i BSCAN_SPARTAN3 BSCAN_SPARTAN3_inst ( .CAPTURE(CAPTURE), // CAPTURE output from TAP controller .DRCK1(DRCK1), // Data register output - USER1 functions .DRCK2(DRCK2), // Data register output - USER2 functions .RESET(RESET), // Reset output from TAP controller .SEL1(SEL1), // USER1 active output .SEL2(SEL2), // USER2 active output .SHIFT(SHIFT), // SHIFT output from TAP controller .TDI(TDI), // TDI output from TAP controller .UPDATE(UPDATE), // UPDATE output from TAP controller .TDO1(TDO1), // Data input for USER1 function .TDO2(TDO2) // Data input for USER2 function );Article: 78582
Verilog Instantiation Template // BSCAN_SPARTAN3:Boundary Scan primitve for connecting internal logic // JTAG interface. Spartan-II // Xilinx HDL Libraries Guide version 7.1i BSCAN_SPARTAN3 BSCAN_SPARTAN3_inst ( .CAPTURE(CAPTURE), .DRCK1(DRCK1), .DRCK2(DRCK2), .RESET(RESET), .SEL1(SEL1), .SEL2(SEL2), .SHIFT(SHIFT), .TDI(TDI), .UPDATE(UPDATE), .TDO1(TDO1), .TDO2(TDO2) );Article: 78583
Ulf Samuelsson wrote: >>>I leave it to the reader to draw conclusions. >>> >> >>Okay...finally received Atmel samples of AT25F1024A and AT25F4096. >>Both are not working as replacement for EPCS configuration for Cyclone > > FPGA. > >> >>rick > > > If you want o configure FPGAs, then you need to look at the AT17xxxA family. ...and again Atmel is misunderstanding (o; I was talking all the time about Cyclone FPGA... rickArticle: 78584
Hi g. giachella, > Dear all, > I've placed my design in an Altera Stratix and use a PLL for clock > generation. In a first stage PLL generated 22 MHz as output freq and > Quartus II (3.0 release) showed 36 MHz as fmax. Due to this result, I > have decided to increase PLL output to 33 MHz (without any change on > the design). > Now, after placement, Quartus Timing Analyzer shows 33.1 MHz as new > fmax. I've repeated both placements (with a 22MHz PLL and with a 33 > MHz PLL) multiple times and the results are similar. > > Has the PLL configuration any impacts on other parameters which affect > timings ? > > I've also tried a backannotation when going to 33 MHz, but the results > are the same. I can't use Chip Editor, since it crashes. First of all I suggest that you move to a newer version of Quartus. Version 3.0 is over a year and a half old (if not more) and the tool has improved considerably. The PLL setting indeed affects Quartus' results because the placer picks paths to optimize based on the amount of slack (the difference between the reached and the desired frequency), and basically any difference in a design results in a different initial placement. Quartus will attempt to meet timing, and will stop when it reaches timing or after a number of iterations hasn't found a workable solution (after which you will see errors in the timing report). I am pretty sure that if you set the PLL to output 36MHz, you will reach this performance. As to the chip editor crashing, this subsystem was new in 3.0, and is stable in the current 4.2 version. Best regards, Ben TwijnstraArticle: 78585
Gabor wrote: > Kolja Sulimma wrote: >>Now 0.5mm single in line resistor packs would be >>great (Pinout A1-A2-B1-B2-....). But dual in line resistor packs are >>rather useless unless I can route a signal between the pins. > > Check out Bourns CAT16-PT4F4 or CAT16-PT2F2. These are 0.8mm, not 0.5 > but they route through nicely on the surface (they're DIP but work like > a SIP because opposite pads connect together). You are aware that I need to do parallel termination, not series termination? I use these resistor arrays a lot, but as you can not route between the pins they are really inconvenient for LVDS parallel termination. But we are really OT for this group now. Is there a sci.pcb.layout newgroup or something? ;-) KoljaArticle: 78586
Kolja Sulimma <news@sulimma.de> wrote: > Gabor wrote: > > Kolja Sulimma wrote: > >>Now 0.5mm single in line resistor packs would be > >>great (Pinout A1-A2-B1-B2-....). But dual in line resistor packs are > >>rather useless unless I can route a signal between the pins. > > > > Check out Bourns CAT16-PT4F4 or CAT16-PT2F2. These are 0.8mm, not 0.5 > > but they route through nicely on the surface (they're DIP but work like > > a SIP because opposite pads connect together). > You are aware that I need to do parallel termination, not series > termination? I use these resistor arrays a lot, but as you can not route > between the pins they are really inconvenient for LVDS parallel > termination. > But we are really OT for this group now. Is there a sci.pcb.layout > newgroup or something? > ;-) Have a look at digikey. They have a lot of special footprints, e.g. RT1710B6P. Hope this helps -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 78587
Paul Leventis wrote: > Hi Che Fong, > > Core logic/routing performance is only one aspect of the overall > performance/design suitability question. Many customers *do* have > trouble meeting timing in the core of their design, and a faster chip > (e.g. Stratix II) can make it easier to do so, leaving you with more > time/energy to spend on other problems such as I/O interfaces and > debugging. A faster chip can also mean you can by a cheaper speed > grade and still meet core timing, provided that device meets your other > needs. > > If you don't need core performance at all, then that particular aspect > of Stratix II will not be of use to you. Everyone has different needs. > Many customers do need speed. > > Regards, > > Paul Leventis > Altera Corp. I think these benchmark perforamance comparisons for the fabric are biased. Altera says Stratix II is 39% better than Virtex-4 Xilinx says Virtex-4 is 10 % better than Stratix-II I bet both companies biased their results. Who is to tell otherwise. Where are these designs ? Are they available to the public ? How much effort was really put into making them optimized for the other guy's device. C'mon, give me a break ! ;-) Enough of this chest punding BS !!! CheArticle: 78588
Hi, I would like to develop software by means of RoseRT, and running it using the ThreadX OS and a Xilinx Microblaze softcore. There seems to be a Target Adaptation Layer for ThreadX available for RoseRT and there is a ThreadX version of Microblaze. Has someone good or bad experience with the RoseRT + ThreadX + Microblaze flow? Are there any pitfalls? What kind of debugging methods are available? Thanks, RoelArticle: 78589
Have you tried retired re-entrant routing with par, -k switch? Do this without guide, re-entrant routing simply takes an .ncd and tries to complete whatever portion of the design that isn't fully placed or routed. I'm not sure is supported in the latest architectures but it is an effective methodology. Jacob Bower wrote: > Hi, > > I'm working on a small research project, for which I'd really like to be able > to modify a post-PAR Xilinx design. Specifically, I'd like to remove routing > information for a single net, add have it rerouted with new timing constraints. > > So far I have come accross two possible ways of realistically doing this, but > they both have problems. > > 1. Use JBits > > The problem with using JBits is that it doesn't look like it has > a router advanced enough to (among other things) take into account > timing constraints. Also the bitfile format loses all symbolic naming > information, which is something it would be very helpful to use to guide > this process. > > 2. Modify the PAR'ed NCD directly a'la FPGA Editor but automated > > I came accross XDL which looked like it might do the trick. So I tried > a simple experiment: > > 1. PAR a simple design to NCD format > 2. convert the NCD to XDL > 3. remove the PIP information for a single net in the XDL file > 4. convert the XDL back to NCD (including compensating for the lost ISET > information as in Xilinx Answer record #17204) > 5. re-run PAR on the original (unplaced) NCD using the modified ncd->xdl->ncd > file as a guide in 'exact' guide mode. > > This sort of works, but the guide report suggests that there isn't a > 100% match between the guide file and the original NCD (see below), > and seems to think that 129 signals rather than 1 need re-routing. This > really isn't ideal for me, as I'd like to leave as much of the initially > PAR'ed design intact as possible. > > It'd be really good if I could get this technique to work, but I can't > understand why there are mismatches between the two NCD files and more > than one net that needs re-routing. I also found that even if I omitted > stages 2-4 from my expt. above and just used the fully PARed NCD as a > guide, there are still mis-matches between this and the unPARed NCD. > > Does anyone have any comments or suggestions on how I could refine this > process, or an alternate method I could use? > > Thanks, > - Jake > > Snippet of output from the guided PAR: > > Xilinx Place and Route Guide Results File > ========================================= > > Guide Summary Report: > > Design Totals: > Components: > Name matched: 1873 out of 1873 100% > > Total guided: 1873 out of 1873 100% > > Signals: > Rejected Implicit/Internal: 3046 out of 7238 > Name matched: 4192 out of 4192 100% > Total guided: 4191 out of 4192 99% > Total connections guided: 8582 > > Guide file: "modified_xdl.ncd" Guide mode: "exact" > > Components: > Name matched: 1873 out of 1873 100% > Total guided: 1873 out of 1873 100% > > Signals: > Name matched: 4192 out of 7238 57% > Total guided: 4191 out of 4192 99% > Total connections guided: 8582 > > ... > Phase 1: 129 unrouted; REAL time: 8 secs > > Phase 2: 0 unrouted; REAL time: 31 secs > ...Article: 78590
Hi Che Fong, I can't speak for Xilinx, but we did not bias our results. If you look at our Stratix vs. Virtex II data, you'll notice we do not try to claim a large performance advantage, even though we could have if we chose to bias our data. Those families had similar performance. Stratix II improved on Stratix (somewhere in the vicinity of 45% better core performance) through a combination of process and architecture improvements. Virtex-4 has not -- we have benchmarked Virtex-4 vs. Virtex II-pro and found very little difference in performance. So have customers and posters on this bulletin board. The lack of publicly available credible benchmark designs is unfortunate. It would help clear the waters in benchmarking, and it would also help academics who develop cad tools and new algorithms to apply them to real-world problems. We cannot release our benchmark circuits, since they were originally the IP of (real or potential) customers who provided us the design under NDA. We made no effort to optimize the designs for our chips. Some of our designs were originally targetted at Xilinx chips, and all we do to these designs is replace DCMs with PLLs and replace any RAMs with lpm_ram. I strongly encourage you to take your designs and try them out on Virtex-4 and Stratix II. You decide -- in the end benchmarks can only give you an indication of what to expect. Real performance depends on exactly what your design is and what resources it requires. Both Altera and Xilinx provide free place & route tools (see www.altera.com) so you can easily make your own head-to-head comparison. For more details on how we benchmark, see http://www.altera.com/products/devices/performance/high_performance/per-high_performance_fpga.html. Regards, Paul Leventis Altera Corp.Article: 78591
> > 2. Modify the PAR'ed NCD directly a'la FPGA Editor but automated Maybe you can try fpga_edline.exe, the command line version of FPGA editor. Jim HTH, jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chipsArticle: 78592
I seldom have serious issues with Paul (he is not part of their local marketing snakepit anyhow) and I will not have a dirty fight with him. Altera had skewed the benchmark results in their favor by comparing their fastest against our middle speed grade (I know that our fastest speedfiles were not yet public, but that is a poor excuse if you want to create benchmarks for the benefit of the public. Learn from tennis, where you don't surprise a temporarily not-yet-ready opponent !) Altera also did not use the Xilinx software the way a user interested in top performance would use it. And bingo: +39% ! No lies, just cheats. The stable of designs is naturally different in the two companies. And they are not public... My intent was not to battle the 39% (that would have been a different presentation, and a different presenter). My intent was to convince you that such benchmarks, based on legacy designs are irrelevant, since the real performance criteria are elsewhere, namely in novel and innovative functionalty and systems features. Maybe I succeeded. ;-) Thanks to all who had the stamina to listen to the bad audio track. The accent is mine, but the fade-in and fade-out happened elsewhere. The mike was a constant 2 inches from my mouth... On the 15th, same time, we will cover power consumption in Virtex-4. Peter Alfke, Xilinx ApplicationsArticle: 78593
Kolja Sulimma wrote:
> Gabor wrote:
> > Kolja Sulimma wrote:
> >>Now 0.5mm single in line resistor packs would be
> >>great (Pinout A1-A2-B1-B2-....). But dual in line resistor packs
are
> >>rather useless unless I can route a signal between the pins.
> >
> > Check out Bourns CAT16-PT4F4 or CAT16-PT2F2. These are 0.8mm, not
0.5
> > but they route through nicely on the surface (they're DIP but work
like
> > a SIP because opposite pads connect together).
>
> You are aware that I need to do parallel termination, not series
> termination? I use these resistor arrays a lot, but as you can not
route
> between the pins they are really inconvenient for LVDS parallel
> termination.
>
Look at the data sheet. The connection looks like:
1 --------------- 8
|
R
E
S
|
2 --------------- 7
and so on, where all RES are 100 ohms. It is really made for this type
of termination. The only thing you would like is finer pitch.
> But we are really OT for this group now. Is there a sci.pcb.layout
> newgroup or something?
> ;-)
>
> Kolja
Article: 78594Sunds like Altera BS is bigger than Xilinx ! ;-)Article: 78595
Ann wrote: > Hm...I read something about the USER1 and USER2 registers and also found this code in the software manual Verilog Instantiation Template > > // BSCAN_SPARTAN3:Boundary Scan primitve for connecting internal logic // JTAG interface. Spartan-II // Xilinx HDL Libraries Guide version 7.1i BSCAN_SPARTAN3 BSCAN_SPARTAN3_inst ( .CAPTURE(CAPTURE), // CAPTURE output from TAP //controller .DRCK1(DRCK1), // Data register output - //USER1 functions .DRCK2(DRCK2), // Data register output - //USER2 functions .RESET(RESET), // Reset output from //TAP controller .SEL1(SEL1), // USER1 active output .SEL2(SEL2), // USER2 active output .SHIFT(SHIFT), // SHIFT output from //TAP controller .TDI(TDI), // TDI output from // TAP controller .UPDATE(UPDATE), // UPDATE output from //TAP controller .TDO1(TDO1), // Data input for USER1 //function .TDO2(TDO2) // Data input for USER2 //function ); Has anyone used this feature before? Does it work in reading out a user defined register? If you know anything about this feature, please let me know. > > Thanks, Ann I used to use this in the original spartan parts (XC4000-like). But I thought it had disappeared from newer parts. If they still have a BSCAN primitive you should find it easier than reading out the whole config. However be aware that at least in the old parts, placing the BSCAN into the design made it hard to re-program the part if you needed to use JTAG for that, too (I was using slave serial mode).Article: 78596
Ken wrote: >Hi all, > >Been reading a lot from the archives about synch/asynch resets. Found lots >of good stuff and am now more enlightened. > >My conclusions so far: > >(1) >Use synchronous reset in general on the flip flops for FPGAs > >(2) >If system requires asynch reset on the flip-flops, synchronise the release >of the reset to the appropriate clock domain to avoid the release spanning a >clock edge due to fanout delay. > >Question 1: >I guess the main reason for using an asynch reset is for when the circuit >must be reset in the absence of a working clock? If so, how can the release >ever be synched to said clock if it is not working? Hence, why ever use >asynch reset on a clocked circuit? > > I can think of a couple of situations where this might make sense. One is where you need to respond to a short duration reset signal that might not last during a clock transition. In most cases, building a one-instance synchronizer to generate a synchronous reset for the rest of the FPGA would be the best solution for this case. Another is a safety-related reset, perhaps in a motion control system, where you need the reset to halt motion and cause an emergency stop, even if the clock were to fail. I have something like this in some of my designs. The external, analog-based one-shot watchdog timer will cause an e-stop even if the clock to the FPGA has gone static. I don't have any problem with an asynchronous release of this reset, in this case. it could cause a problem with a simulation, but it won't cause any problem in the actual application. The worst case is one more millisecond before the e-stop condition ends. JonArticle: 78597
Peter Alfke wrote: > I seldom have serious issues with Paul (he is not part of their local > marketing snakepit anyhow) and I will not have a dirty fight with him. > Altera had skewed the benchmark results in their favor by comparing > their fastest against our middle speed grade (I know that our fastest > speedfiles were not yet public, but that is a poor excuse if you want > to create benchmarks for the benefit of the public. Learn from tennis, > where you don't surprise a temporarily not-yet-ready opponent !) > Altera also did not use the Xilinx software the way a user interested > in top performance would use it. And bingo: +39% ! > No lies, just cheats. > The stable of designs is naturally different in the two companies. And > they are not public... <snip> Then you need another class of benchmarks, that ARE public ? If you look at the EEBC (sp?) Embedded controll benchmarks, they also extend the meaning of benchmarks by having TWO columns. a) = "out of the Box" = Std tools, Compilers, not hand level tuned in assembler, or using special HW fabric. b)"Optimised" = Experienced designer, hand optimised Assembler,and using all relevant special HW fabric. Not surprisingly, there can be 10:1 or 100:1 between a) and b) So, how about making some PUBLIC simple candidate benchmarks ? They need to be small enough to understand, but difficult enough to push the devices. How about : 1) DDS Synthesis - 24/32/40/48 bits wide, and using a) fabric only, Most Portable HDL b) HDL, but using special HW support features c) [if applicable] full optimise, including hand placement [least portable] 2) Frequency & Period Counter : BCD and Binary alternate designs, 8-12 digits, Reciprocal counting, results to spec Fmax, dT min, and Digits/Sec of gate time. 3) PWM/Pulse generation - word widths as for DDS: Simplest form is gated counter, but FPGAs have many time-domain HW supports, that have higher resolution so the optimised form of this benchmark, would use any time-domain feature you like. Self-Calibrate is ok. 4)SoftCPUs : SoftCPUs are advancing, and there are public cores out there. This gets more political, as these make very good benchmarks, but IC vendors would much rather lock customers into their own SoftCPU, so do not want to publicise any alternatives. etc -jgArticle: 78598
ptkwt@aracnet.com (Phil Tomson) wrote in news:cpsaav02be3@enews1.newsguy.com: > In article <aqUz8KBGOYwBFw$7@jmwa.demon.co.uk>, > John Woodgate <noone@yuk.yuk> wrote: >>I read in sci.electronics.design that Phil Tomson <ptkwt@aracnet.com> >>wrote (in <cprnfc02h25@enews3.newsguy.com>) about 'Exportability of >>EDA industry from North America?', on Thu, 16 Dec 2004: >> >>>It's not a pretty picture. The standard of living will likely have >>>to fall a good bit in the US before you see these kinds of jobs move >>>back. >> >>Or the standard of living elsewhere will have to rise. > > True. We'll have to meet in the middle somewhere. This is partly why > the dollar is falling (also because of the national debt, of course). > The fact remains that the US standard of living will have to fall in > this kind of a free-trade system. It's not going to be pretty for the > US standard of living to fall that way - it hasn't really happened > before. > > Phil Meeting in the middle will be very hard for Americans, especially when the middle will be population-weighted billions of Indians and Chinese 200 plus million of us in the USA. Already those high paid Malysians and others in Asia have been squeezed by the even lower cost Chinese. The middle probably represents a per capita income of $5,000. Once all the technology and industry that are the basis of the USA's strength are transported to Asia, we'll see how our position in the world changes. Once all the technical people are over there, they will be the onese in the drivers seat. And they will not need American CEOS for long. No it won't be pretty. Since China has its currency tied to the dollar, there has been no self correcting economic feeback loop to stem the trade deficit with them. Otherwise our currency would have fallen against theirs and the price of their products would have gone up. Instead we are in a death spiral with an elephant. Not that all is rosy for the Chinese or the CEOs sending all the work there. All the Chinese banks are insolvant, there is no financial transparency, corruption is rampant, contracts may not be enforcable, intellectual property is stolen outright, its difficult to take money out of the country, the political situation can change at any moment, a billion peasants are poor and restless and then there is Tiawan. With those negatives you have to wonder what these CEOs are thinking by placing their balls firmly in the grasp of the Chinese.Article: 78599
On Fri, 04 Feb 2005 00:46:08 GMT, the renowned Winston Smith <winston@1984.com> wrote: >With those negatives you have to wonder what these CEOs are thinking by >placing their balls firmly in the grasp of the Chinese. The motivation is green (at least the US version is) and there is lots and lots of it to be had. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z