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
We have built the capability to drive the JTAG from the FPGA into Raggedstone1 in a similar fashion to what we did in MINI-CAN. You need the first build containing the PCI and JTAG interfaces to be loaded by the the ye olde JTAG cable. After that and providing you keep the PCI/JTAG interface in all subsequent builds the hardware features will be there so you can keep reprogramming the Platform Flash. The hard bit is driver/software support that may have to change as you add and remove different bits to the overall design. Longer term we may build the JTAG interface into our own PCI core so that is there any time our core is used but it certainly will not be in the first cut of that core. It is our intention to have some kind of GUI interface but the details and practicality of this are awaiting some man time to do it. Our PCI core will be available in a "lite" version to owners of Raggedstone1 free for use with their board. If you want to take the core onto a board design of your own, or have the more advance version, there will be a license fee based on a tier of usage. We will try to make this reasonable for the smaller guys out there so that the entry cost isn't a barrier to a small volume/value commercial project. John Adair Enterpoint Ltd. - Home of MINI-CAN. The Spartan-3 CAN Bus Development Board. http://www.enterpoint.co.uk "Phil Tomson" <ptkwt@aracnet.com> wrote in message news:dqnd2611rjo@enews1.newsguy.com... > In article <1137574950.42552.0@demeter.uk.clara.net>, > John Adair <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >>Phil >> >>What you need as a driver depends on your software. I'm not a softy so I >>am >>not best person to talk about this. If you simply want to use a PC slot to >>power the card or do what Antti has done with his design that turns a RS1 >>into a parallel port look-alike you can get away without supplying a >>driver. > > I don't need to be able to program the part on the board through PCI (I > could > program it through the parallel cable), but after the part is programmed I > want to be able to transfer data between the CPU and the FPGA over the PCI > bus. > > If I understand correctly, I only need the driver if I want to be able to > program the FPGA through the PCI - is that a correct assumption? > >> >>We are getting a drivers, XP and Linux, for our own PCI core but probably >>4-8 weeks away from releasing the first of these. We have a number of >>customers using Linux on various boards so if you ask in the Linux >>community >>newsgroups someone may offer a driver. > > Sounds good (if I could program the FPGA through the PCI bus, that would > be > great, but it's not absolutely needed I think). Is your PCI core freely > available with the board? > > PhilArticle: 94951
"John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag news:Pine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU... > Is your library for the CRC generation available to others. > > JOhn > hi John I just sent per email to you an updated version (tested with Virtex) of bit2frames application that is based on our bitsream library, if you can verify that the tool works and is able to process and properly calculate the CRC in your bitstreams then well we can give the source out too, ah one more adivce make sure not to use compression whrn working with data2mem, but I guess you are not using it anyway. the bit2frames I just sent is also not tested with compressed Virtex bitsreams yet AnttiArticle: 94952
with the core you're working on, how many space left to implement design ? x3s400 means 400k gates ? X.Article: 94953
As we have all known for some time, Xilinx has had a habit of padding the logic cell counts in their data sheets to account for "effectiveness". This factor is 1.125 or 9 LCs per CLB in the newest parts. I still find this very odd, but mainly annoying because when I want the true LC count, I have to calculate it myself. Anyone else find this to be a bit rediculous?Article: 94954
Of course it's ridiculous! Marketing loves to make engineers hate the company. They want to make the *managers* look past their feeble engineers for approving brand X versus brand A (forgetting, of course, that most engineers have the lattitude to push for one brand due to the *engineering* tradeoffs). There are times when you need to shoot the engineer to ship the product (just one more tweak is *not* okay!) but thankfully the engineers get to be pissed off at marketing until they skew the preference toward the "other" brand's mismarketing BS. Ah, what a wonderful world. What would it be like, after all, if we have to pull our hair out with our CAD tools (PC, synth, P&R, sim) but didn't have to get the least bit upset about choosing the part in the first place? - John_H "rickman" <spamgoeshere4@yahoo.com> wrote in message news:1137702911.352529.98730@g47g2000cwa.googlegroups.com... > As we have all known for some time, Xilinx has had a habit of padding > the logic cell counts in their data sheets to account for > "effectiveness". This factor is 1.125 or 9 LCs per CLB in the newest > parts. I still find this very odd, but mainly annoying because when I > want the true LC count, I have to calculate it myself. > > Anyone else find this to be a bit ridiculous? >Article: 94955
Rickman, why do you ask? Everybody in this newsgroup hates that method, but Xilinx Marketing thinks that it is a more meaningful metric when comparing different manufacturer's devices. And it is, like it or not. This reminds me of the way horsepower was measured for automobiles: Disconnect the gearbox, the generator, the waterpump, the airconditioner and everything else that might drain power. A red-blooded engineer would say: give me the horsepower where the tire meets the road.... PeterArticle: 94956
Rickman, why do you ask? Everybody in this newsgroup hates that method, but Xilinx Marketing thinks that it is a more meaningful metric when comparing different manufacturer's devices. And it is, like it or not. This reminds me of the way horsepower was measured for automobiles: Disconnect the gearbox, the generator, the waterpump, the airconditioner and everything else that might drain power. A red-blooded engineer would say: give me the horsepower where the tire meets the road.... PeterArticle: 94957
Great, thanks a lot for all your answers ! I'll try to downmix the analogue VCXO signal... Bye, BEN Ulrich Bangert wrote: > Ben, > > if you can afford to use a small amount of analogue circuitry around your > fpga, i suggest you use a second 1000010.0 Hz oscillator (this can be a > "detuned" 1 MHz oscillator) and mix the received signal with this this > oscillator down to the audio domain using a double balanced mixer. A lowpass > filter (or better a so called diplexer) must be used at the IF port of the > mixer. > > The frequency variation in the downmixed signal stays the same, so with this > arrangement you have shifted the scenario from 1 MHz, where a 5 Hz variation > is a difficult to detect 5*10E-6 effect to a 10 Hz audio signal where 5 Hz > variation is a easy to detect 50 % effect. This scheme is the usual one for > comparing ultra stable oscillators against each other, where variations > smaller by some orders of magnitude have to be measured. > > No matter what scheme you will use: Keep in mind that a "normal" x-tal > oscillator has a tempco of app. 1*10E-6/K. So a normal x-tal oscillator will > give you a 1 Hz variation per Kelvin @ 1MHz, well in the region of the > Doppler that you want to measure. This is a indication that a "better" > oscillator has to be used. Don't go for a TCXO, look out for a cheap OCXO. > > Rgegards > > Ulrich Bangert > > "Ben Marpe" <Ben.Marpe@gmx.de> schrieb im Newsbeitrag > news:1137597178.426492.225110@z14g2000cwz.googlegroups.com... > >>Dear experts in this newsgroup, >> >>in my diploma thesis i'm using a FPGA for baseband signal generation. >>I'm interested in generating and varying a clock of 1Mhz which is >>DOPPLER shifted +/- 5Hz due to movements between receiver and >>transmitter. >> >>The +/- 5Hz Doppler must be applied in a very "smooth" way, the step >>resolution should be as fine as possible. >> >>Any ideas how to do this on a (Xilinx) FPGA ? >>The sine output of Xilinx LogiCore DDS isn't necessary and the step >>resolution might be even a little bit finer for my application. >> >>Thanks a lot for every single hint you can give to me ! >> >>Greetings, BEN >> > > >Article: 94958
Leon wrote: > Incorrect footprints can also be very annoying, that has caught me out > once or twice. > > Leon > I remember once creating a part my self, then discover after I get the PCB that I didn't unzoom the PDF enough ... i missed the fine print at the bottom that said "bottom view" ... SylvainArticle: 94959
Peter Alfke wrote: > Rickman, why do you ask? > Everybody in this newsgroup hates that method, but Xilinx Marketing > thinks that it is a more meaningful metric when comparing different > manufacturer's devices. And it is, like it or not. How about you try and introduce the meaning of UNITS to them ? ie let them use LCeq for the marketing DOCS, and also have an absolute, physical count, of LC = X * Y on the die. As a radical idea, they could even publish the formula LCeq = LCactual * MarketingsIdeaOfLevelPlayingFieldFactor That way, everyone is happy :) The problems occur when one dept trys to use a std unit, but hijack it to mean something else. In the end no one knows where they are.... and everyone is annoyed. -jgArticle: 94960
Thank you for your suggestions.Article: 94961
Peter Alfke wrote: > Rickman, why do you ask?\ I asked because I wanted to hear the the opinion of others. I read a recent Spartan 3 data sheet and noticed that there is now a footnote explaining they they are padding the number. I just find this pretty absurd. You compared it to car makers measuring horsepower, but that is a measurement that has parameters. Countings LCs is counting and adding a 12.5% fudge factor is marketing, not measurement. It would be more like a car maker saying his engines are 9 equivalent cylinders! But mainly it is frustrating to always have to calculate the correct number myself. At least marketing has not gotten to my calculator yet. :) > Everybody in this newsgroup hates that method, but Xilinx Marketing > thinks that it is a more meaningful metric when comparing different > manufacturer's devices. And it is, like it or not. That is silly for you to state this as a fact when it is just your opinion. Have you ever had a customer ask you to adjust your LC counts so they can compare them to the competition? Who says it is "a more meaningful metric"? Your marketing, that's who! It is one thing to accept that your company lets marketing inflate the numbers, but please don't insult me by trying to justify it. Am I alone in regard to finding this annoying?Article: 94962
Peter Alfke wrote: > Rickman, why do you ask? > Everybody in this newsgroup hates that method, but Xilinx Marketing > thinks that it is a more meaningful metric when comparing different > manufacturer's devices. And it is, like it or not. Actually Pete I don't think it is. It's a very arbitrary number where apples, dead tires, horse shit, and tree stumps are all given numerical values which have absolutely no relation to particular customers needs, and declared equal in decsion tree wieghting in ways certain customers would never do the wieghting. If the company would then derate the part for being unable route a fully used device, or power a fully used device, or cool a fully used device there might, maybe, in a long shot be a justification for the bloat factor. The reality is that certain applications do not do arrithmentics, do not need much if any carry chain, or multipliers, or even very many F5/F6 muxes, but do need a lot of LUT's. Being clear up front that you are offering 2 cases of applies, 4 dead tires, no horse shit, and one stump to sit on while eating your apples is a whole lot clearing than tring to figure out just how much shit you get for 37. Old School math ... JohnArticle: 94963
Hello Group, I'm having difficulty convincing Xilinx ISE (8.1SP1 WebPack) PAR to pack some of my signals into the IOBs of an XC4LVX25-FF668. A simple demonstration case is the MIG 1.4 dimm72 VHDL design for the ML461 memory eval board. The FPGA editor shows that most of the DDR command bus outputs correctly push their registers into the IOBs; however the DDR_CS and DDR_ODT output get registered within the fabric. The resulting skew between DDR_CS and the rest of the command bus outputs becomes fatal when generating cores for DDR systems with multiple ranks (chip-selects). The skew of 2ns or so is clearly visible in timing simulations, and my DDR2 model throws a tantrum about invalid setup time on DDR_CS. I have tried seducing ISE into pushing the DDR_CS registers to the IOBs by setting XST "Pack I/O Registers into IOBs" to both "Auto" and "Yes". I have set XST register balancing to "No" and to "Yes" with Move First/Last Flip-Flop Stage disabled. I am also enabling the MAP option to Pack I/O Registers/Latches into IOBs. I am new to Xilinx FPGAs. With Altera I would enable Fast Inputs/Outputs in Quartus, and all the registered I/O would get pushed to the pads. Am I missing something obvious? One thing I did notice: DDR_CS (and ODT) is different from the rest of the command bus in that it is directly fed a combinatorial term, whereas the rest of the command outputs are just relatches of signals registered on previous clocks. Should this make a difference? It seems to me that a combinatorial term could be routed from a slice to an I/O register, just as easily as a registered signal could... Any thoughts or meditations are appreciated, -PeterArticle: 94964
I have a DCM that drives a 1X clock and 2X clock on BUFGs. In one case, the enable to a CLK2X register depends on a CLK1X based FF. Looking at the path delays, there is no problem with setup and hold, but the timing analyzer reports a hold violation that is essentially the actual path delay plus the CLK2X period. The required hold time is 0ns. Is there any way around this, or should I just ignore the error? I don't think that it should be showing a half cycle of skew between two non-phase-shifted clocks. For some reason, the 2X versus 1X seems to be confusing it. ChrisArticle: 94965
Marco wrote: > Leon, sorry, could you explain me more in detail what you've done? > Thanks 'Bit-banging' is slang for clocking out the data by manipulating pins with software, instead of using hardware, which is how it is done in the SPORTs. It's often used for asynchronous comms (a software UART), and for synchronous protocols like SPI, and FPGA configuration. It was a long time ago, and t've got the software somewhere. It was quite straightforward, using the Altera documentation. LeonArticle: 94966
Hi all, Hope everything is fine on your side.
Key Words: ML300 board, VHDL, XST, XPS, Xilinx
I have written a VHDL program(look post script)to count pulses from
quadrature encoder. Basically i read both the clocks(here QEP0 and
QEP1) and count on two different conditions based on if the motor is
going forward or backward. In the previous case count is increased and
the latter case the count is decreased. I store the count in a S/W
accessible slave register generated when i use "Create Peripheral
wizard" (EDK) (slv_reg0)
Usually everything works fine, however at times (roughly 1 out of
15-20) what happens is that when i keep reading from that register
continously(for (i=0;i<100;i++){read from the slave register and
display it} ), previous value to the current value difference is
tremendously huge (say 1234,1235,1236...1278,10378,10379...) something
like that. there is no much change in the hardware(i mean no sudden
surge in Motor rotation/ encoder). I read from the register slv_reg0
using a C program.
{
long temp;
long *my_pointer = (long*) XPAR_abcef_BASEADDR;
temp = *my_pointer;
return temp;
}
I would like to know if i read and write to the register(slv_reg0) at
the same time will there be any problems like this? or what is that
wrong i am doing in this program. I am trying to implement a encoder IP
which coul do this job for me. any help in this regard will be greatly
appreciated.
With Warm Regards,
Chakra.
PS: the VHDL program
--------------------------------------------------------------------------------
--------------new encoder counter algorithm dec
19------------------------------
--------------------------------------------------------------------------------
---Please note that QEP0 and QEP1 are input signals defined in the
ports and are connected
--to GPIO ports. the encoder output from the motor is connected to the
GPIO pins.
--thus everytime there is a pulse in the encoder the GPIO senses it and
thus this IP will be
---able to sense it and count how many pulses the mototr is gone
forward or backward.
process(QEP0, rst)
begin
if (QEP0'event and QEP0= '1') then
if(QEP1 = '0') then
D <= '0';
else
D <= '1';
end if;
end if;
end process;
process(QEP1, rst)
begin
if (QEP1'event and QEP1= '1') then
if(QEP0 = '0') then
E <= '0';
else
E <= '1';
end if;
end if;
end process;
process (QEP0, rst)
begin
if (QEP0'event and QEP0 ='1') then
if ((D='1' and E='0')) then
count1 <= count1 + 1; --motor going forward
elsif(D='0' and E='1') then
count1 <= count1 - 1; --motor going backward
else
count1 <= count1; --do nothing
end if;
end if;
end process;
slv_reg0 <= count1;
Article: 94967Paul, You are correct that is the proper use model through NGDbuild. If you are using Project Navigator then you can add the *.BMM and *.ELF file to the top level file in your project and it should feed it to NGDBUILD. BITGEN will automatically call Data2MEM to initialize the memory. BITGEN will also output a *_bd.bmm file that can be used with Data2MEM standalone to update the memory with the LOC constraints. Unfortunately, I have not seen any good way to find the hierarchy name for the Block RAM to be place in the BMM file. I normally run the project through one and try to find them in FPGA Editor. But the XDL flows also works. Cheers, Shalin- Paul Hartke wrote: > As far as I can tell, the model is that a bmm file without placement > info is fed to ngdbuild with the -bm option. Each BRAM is associated > with a hierarchical name and its location in the memory address space. > That info is passed through the design flow until bitgen. Bitgen > recognizes this info in the design database and creates a new *_bd.bmm > file which includes the hierarchical names and the physical location > information. data2mem uses the memory address space info and the > physical location information to insert the elf/mem into the fpga > bitstream. > > EDK generates the original bmm; currently coregen does not and its not > clear what the BRAM hierarchical names are in the internal database. > There is no need to manually look into floorplanner and/or ucf LOCs to > use data2mem if you can figure out what the BRAM hierarchical names > are. Since coregen doesn't automatically export a bmm with its internal > hierarchical names, the floorplanner *.fnf file can be used to determine > them. Doing it this way allows the placement to change and the backend > flow keeps working once you know exactly what coregen memories are > needed. > > Paul > > Antti Lukats wrote: > >>data2bram seems to work properly only when used by the EDK. >> >>the BMM file that it requires *must* have LOC info >> >>on possibility is to LOC the BRAMs in the UCF and then inject the >>same LOC info into BMM manually, doable but hassle >> >>the BMM issue has been a problem all the time, maybe its better >>in 8.1 havent checked but so far it really hasnt be any joy when >>attempting to use it >> >>Antti -- ------------------------------ Shalin Sheth Embedded Applications Engineer General Products Division Spartan-3 Generation FPGAs http://www.xilinx.com/spartan3 http://www.xilinx.com/spartan3e ------------------------------Article: 94968
Dear group,
I have a work around for this issue but it seems a
little strange that the Q1 from the Master ISERDES
is acting a little flaky. It appears that it copies Q2
from time to time. The rest of the bits seem fine.
Perhaps this is how I assigned the same signal to
both CLK and OCLK and perhaps one should
be delayed from the other?
Or perhaps this is an artifact of using 7x frequency
and I am the only one on this planet who is using 7x?
Or perhaps its an artifact of using the all the output
bits, including Q5 and Q6 from the slave,
and not just the 7 suggested by Xilinx ?
Brad Smallridge
Ai Vision
cam2_x0_ibufd_inst : IBUFDS
port map (
O => cam2_x0,
I => cam2_in(1),
IB => cam2_in(0) );
x0_iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 6, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "IFD", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "VARIABLE",-- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 15, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => cam2_x0_bit(0),
Q2 => cam2_x0_bit(1),
Q3 => cam2_x0_bit(2),
Q4 => cam2_x0_bit(3),
Q5 => cam2_x0_bit(4),
Q6 => cam2_x0_bit(5),
SHIFTOUT1 => cam2_x0_shift1,
SHIFTOUT2 => cam2_x0_shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam2_clk7x,
CLKDIV => cam2_xclk,
D => cam2_x0,
DLYCE => cam2_dlyce,
DLYINC => cam2_dlyinc,
DLYRST => cam2_dlyrst,
OCLK => cam2_clk7x,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => cam2_reset );
x0_iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- "DDR" "SDR"
DATA_WIDTH => 6, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "IFD", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "VARIABLE",-- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 15, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => cam2_x0_bit(6),
Q4 => cam2_x0_bit(7),
Q5 => cam2_x0_bit(8),
Q6 => cam2_x0_bit(9),
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam2_clk7x,
CLKDIV => cam2_xclk,
D => '0',
DLYCE => cam2_dlyce,
DLYINC => cam2_dlyinc,
DLYRST => cam2_dlyrst,
OCLK => cam2_clk7x,
REV => '0',
SHIFTIN1 => cam2_x0_shift1,
SHIFTIN2 => cam2_x0_shift2,
SR => cam2_reset );
Article: 94969Has anybody ported the Xilinx DDR SDRAM examples over to the ML40x boards?Article: 94970
Hi all, I am new to demodulation and FEC. How can I get each bit's soft-probability from the constellation? For example, the modulation method is 16QAM, How can I get P(bit1=0),P(bit2=0),P(bit3=0),P(bit4=0) from a symbol? Is it belong to the subject of detection and need viterbi algorithm? Or can you recommend some key words of this subject? Best regards, DavyArticle: 94971
Here is an observation - what do y'all think ? 1 - Indian / Chinese / East European /etc people are at least as smart and hardworking as Westerner's / Japanese 2 - However, they work for something like $10% of what we will (or could live on) 3 - Our major advantage (in terms of these newsgroups) is our experience with these subjects/technologies/methods/products 4 - On these newsgroups, many of the questions originate from people in India, China or Eastern Europe and are answered by Westerners 5 - Are we shooting ourselves in the foot ? I'm not suggesting this is a bad thing - after five years in the US I am actively looking for opportunities elsewhere - I just thought it was an interesting question. GArticle: 94972
> 4 - On these newsgroups, many of the questions originate from people in > India, China or Eastern Europe and are answered by Westerners > 5 - Are we shooting ourselves in the foot ? The good ones will improve themselves anyway. The bad ones will never be any good. Knowledge should never be hoarded. Experience cannot be given away, only /experiences/.Article: 94973
On Fri, 20 Jan 2006 03:43:58 GMT, "HoustonEngineer" <xxx@yyy.com> wrote: >Here is an observation - what do y'all think ? > >1 - Indian / Chinese / East European /etc people are at least as smart and >hardworking as Westerner's / Japanese >2 - However, they work for something like $10% of what we will (or could >live on) >3 - Our major advantage (in terms of these newsgroups) is our experience >with these subjects/technologies/methods/products >4 - On these newsgroups, many of the questions originate from people in >India, China or Eastern Europe and are answered by Westerners >5 - Are we shooting ourselves in the foot ? > >I'm not suggesting this is a bad thing - after five years in the US I am >actively looking for opportunities elsewhere - I just thought it was an >interesting question. > >G > Back in my high school days it was common for students to help each other out; if a classmate didn't understand something, I was happy to explain it, and I found that others were glad to return the favor. When I went to college, I realized that I was competing with people who were very, very smart, and it made me wonder whether I was doing myself harm by sharing knowledge with others. I gave this a lot of thought early in my freshman year, and finally came to the conclusion that if the only way I could successfully navigate college was to withold information from others, I'd rather sell shoes. It's been about 35 years since I made that decision, and I've never regretted it--in school, on the job, or on Usenet. Of course, I still draw the line at designing other people's traffic light controllers. Bob Perlman Cambrian Design WorksArticle: 94974
On Fri, 20 Jan 2006 03:43:58 GMT, "HoustonEngineer" <xxx@yyy.com> wrote: >Here is an observation - what do y'all think ? > >1 - Indian / Chinese / East European /etc people are at least as smart and >hardworking as Westerner's / Japanese >2 - However, they work for something like $10% of what we will (or could >live on) >3 - Our major advantage (in terms of these newsgroups) is our experience >with these subjects/technologies/methods/products >4 - On these newsgroups, many of the questions originate from people in >India, China or Eastern Europe and are answered by Westerners >5 - Are we shooting ourselves in the foot ? > >I'm not suggesting this is a bad thing - after five years in the US I am >actively looking for opportunities elsewhere - I just thought it was an >interesting question. Is it our destiny to be rich and well fed, while the rest of the world stays poor and hungry? Must we always be the elite? Is the world economy a zero-sum game, where we want 90% of the winnings? John
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