You can certanly use MEMS techniques to make a better electrical circuit. (Though I am not familiar with applications in digital devices)
MEMS techniques can for instance help in creating excellent on-chip inductors, important for RF applications.
However, it is not given that the Next Big Thing in digital devices will be electronic at all. Maybe we'll find ways to make micromechanics perform better than electronics.
What simulator are you referring to? If you're referring to a Synopsys or Cadence simulator then you're off by an order of magnitude.
Modelsim PE can be had at around these costs (if you can negotiate well). Deepending on the market situation there may be emerging products that can be obtained cheaply. (A common tactic is to buy a cheap and crappy tool, then negotiate a deal with a vendor of a decent tool to switch in return for just paying maintenance)
2K is propably a too low estimate though
Again what tools are you referring to here? This seems off by at least a factor of two.
I was referring to the costs for paying somone else to do synthesis, P&R and tape out procedure. Not tools.
What's wrong with VHDL? What is it you want to express that you are unable to do clearly in VHDL?
And sure, you can design without explicitly making a state machine, but as long as you are making a synchronous circuit that is what it is going to end up as anyway.
While explicit state machines aren't right for everything, I have yet to see any sensible design methodology which can do away with them completely.
These prices are however just for the fabrication, no?
If so you will still need to do synthesis and P&R.
Of cource your point about just dropping in a processor as beeing uninteresting is well taken. Indeed a CPU is a very inefficient piece of logic. Dropping CPUs in FPGAs seem to me as a particularly stupid thing to do.
The whole reason many want a CPU in a SoC product is that they want the flexibility to reconfigure the chip and update it's algorithms without having to fabricate a new device. On a FPGA you allready have the flexibility to update at any time at practically no cost, so on those you will want to forgo the CPU entirely and implement the algorithm completely in hardware.
Also since FPGAs generally are unable to reach high clockspeeds, the designer really need to paralellize his algorithm to achieve any kind of performance.
(We recently have done a SoC project which was to be prototyped in a FPGA which included a 16 bit single issue unpipelined RISC core. On a virtex II 3000-4 this achieved a speed of 18MHz max)
Right. You do _not_ want to deped on the supplied xilinx software for synthesis. It's pretty much crap. Use Synplicity or Leonardo Spectrum (to be replaced with Precicion synthesis this summer) instead.
Also, you do most definetly not want to design your circuit graphically. The time you are going to use to draw a single state machine graphically, I will have designed the whole circuit. Graphical design tools are OK for the structural design phase (this is however a miniscule part of the whole process), otherwise they ar pretty much toys. The best digital hardware design tool availible is Emacs.
Once you have learnt hardware design, and understood the difference between a programming language and a hardware description language, VHDL is quite easy to deal with (I don't know much verilog, and from what I have see I don't want to deal with it. It's a verification hell)
Sure you can outsource. Practically all design houses outsorce fabbing (current estimates indicate that you need a turnaround of approx $7 billion to justify your own fab)
As a small time operator no fab is going to talk to you however. You are going to go through a middleman (just as well since these often supply design services like P&R(Place and route) and synthesis, withouth these services you'll be looking at a investment at approx $200 000 in tools)
For a pure digital diesign you can then get away with a tool investment of $2-5000 for simulation.
For fabbing you should expect $20-50000 in expenses to ready your design for tape-out. The cost of the manufacture will depend of wether you are going for an engineering run of MPW (Multi Project Wafer). An MPW will cost you $10-100 000 depending on process sophistication and size and yield 10-200 chips. An engineering run requires a dedicated mask set which will cost $100-500 000. The engineering run itself is consisderably cheaper and the masks may be reused for manufacture.
If you are going to do any leading edge design you will however need to do your own synthesis and P&R. If you target 0.18um of better you propably are going to need som degree of physical synthesis capability ($100000 and up). Fo manufacture you will also need to prepare a test procedure (ATPG tools (Automatic Test Pattern Generator) check in at approx $100000)
Also remeber that all tools will usually require a maintenance fee of 10-20% annually of purchase price (pays for upgrades and support)
At last don't forget computer hardware to run your tools on. Linux suffices for most tools, but some will only run on Sun/HP workstations.
You are basically right about exponetial drop in yield as area goes up. Some of your calculations do miss the mark however as you assume uniform distribution of defects instead of the more realistic random distribution.
What intel (and any sane manufacturer who drop a significant amount of memory on die) will do is to add redundancy to regular structures. The l3 cache _will_ have redundancy, l2 most likely. l1 is more of a toss-up.
Redundancy is currently a standard engineering practice (Actually, most designs use IP modules bought from specialiced memory vendors who can integrate this kind of functionality for you).
While VHDL might seem cumbersome syntactically, you will soon realize that it brings a significant readability advantage over the c-like syntax usedinverilog and to some extent java.
As for structure. All HDL's will have some method for describing structure. VHDL uses the entity as the most common hierarchial component. A entity has a well defined interface, and may use generic parameters. In addition you can use blocs for describing smaller subcomponents and configurations for describing the overall system. (One very useful propery of VHDL is that you can have multiple implementations (architectures) of an entity. A configuration is used for selecting the apropriate one)
Genericity along with generate statements make it very easy to describe very general structures. Good for reuse.
From what I gather of JHDL is that it tries to be a behavioral description language rather than an HDL. This poses a problem at synthesis as behavioral synthesis is a lot tougher and more error prone process than rtl synthesis (though improvements are beeing made)
I don't really see at first glance what this particular language might offer (though it might find a slot in dynamically reconfigurable circuits, (which is rather margial IMO)).
Why on earth do you think anyone would be interested in what a geolocation server says about a users origin when the dealers can just look at the shipping information.
If the industry associations with interest in region division had the power to stop on-line dealers this way, they would allready have done it.
Having a synthesizable core does NOT mean that you can just drop it into any modern design. The deliverables for a commercially usable core are significant. Typically you need the following:
* Verilog code.
I'd rather have VHDL, but i can always synthesize a gate level VHDL description at a cost to simulation speed.
* TWO sets of timing constraints in Synopsys SDC format - one for synthesis, the other for static timing analysis and back-end physical design (i.e. defined clocks, high fanout nets like resets/selects, false/multicycle paths, case analysis statements for setting fastest propagation mode through the design).
While false path and multicycle path information must be provided if such exist, other timing constraints will be determined by the surrounding design, and must be selected by the system designer anyway.
Given the RTL description, constraints are a small matter.
* Synthesis scripts, which have specific mappings to the standard-cell libraries of the particular process (except if implemented in an FPGA).
Erm... if you can't even do that, what on earth are you doing with that expensive synopsys licence. gimme...;-)
Seriously, you can't excpet the supplier of a MCU core to set up your synthesis tool for you.
* SRAM macro definitions and how they plug into the Verilog code (again, highly library/process specific and not relevant for an FPGA, assuming you can find enough on-board FPGA SRAM to equal the caches necessary for the ARM7)
Memory are usually provided by separate suppliers anyway. Given adequate information on the core's memory interface a small piece of glue logic would be quick to assemble. (Some do cores come with a MMU, which makes the job somewhat easier though)
* All JTAG-related files, including BSDL and tap controller specs.
Not really neccecary, and not really associated with MCU core.
* Scan and functional test vectors for Verilog VCS or NC-Verilog to show the core works.
Some of the point of an ip module is that you should have a reasonable excpectation that it is already verified. Functional testing of the core should therefore not be neccecary (though in this case I would propably do some verification myself)
Production testvectors are generated during synthesis, and are dependent of the synthesis environment and libraries, and thus not associated with the MCU core.
Using FPGA for prototyping is definetly a good thing, and is one of the areas where you can get hardware with FPGA to go in a PC.
You can get pci cards with FPGAs that interface to a digital simulator (like modelsim or quicksim). These are rather nice since they shorten simulation times hundredfold.
As for a reconfigurable device in a houshold device, they will certanly not be used as microprocessors, that would be a criminal waste!
Rather you would implement the time critical part of your algorithm in synthsizable code (rtl code) an dump that to the FPGA. There would not really be any need to send programmable circuits to such devices, you allready got one of those, your CPU.
A DSP is just a very specialized CPU, primarily focusing on math intesive stuff, but less on branching and conditionals.
As any CPU they are sequential devices. The load a instruction, decode it and execute it and repeat. Though modern DSP can paralellize many intructions it's resources are still statically allocated at the time of design. A DSP with two multipliers may at most perform two multiplications at any one time.
Using a fpga on the other hand allows you to design the circuit from the ground up. now if your algorithm needs to do 20 multiplications at a time, you can do so simply by building them on the device.
Using a fpga is fundamentally different from using a DSP or microcontroller/processor. The latter is a finished circuit with an assorment of operators selectable by an instruction opcode. The former can be configured into any circuit.
Risc or cisc architecture primarily affect the complexity of the fetch and decode stages of the CPU.
The famous Intel-pipeline is in the execute stage (ALU).
Pipelining is a strategy which is equally valid for both risc as in cisc architectures, and a risc architecture do not offer any complexity advantage in the execute stage. After all a multiplier is a multiplier regardless of overlaying architecture.
Nowdays we don't really see much diffrence in performance between risc and cisc architecures for upscale processors. This is because the savings in fetch and decode logic are dwarfed by other costs like prefetch, reordering and brach prediction (which are used for both architectures).
I've seen nice systems in a few m/b's for a 4 screw mount system, which i imagine would work well, but it needs to be standardised.
They are standardized. I believe the standard (hole geometry and keep-out zone) was set by intel with the launch of the P4. However most new socketA mainboards also support them. (One caveat may be that there are two different hole dimensions used. This can be compensated for though.
Both the 8045 heatsink mentioned in the article and some swiftech models use these holes, there propably are some others as well.
The quality of your connectors is more important than that of your sound card. Bring the audio to your receiver over SPDIF or TOSLINK, not over analog RCA cables! Sound cards --- ALL of them --- have really awful RCA connectors.
While digital interfaces bring a theoretical possibility for a quality change over analog links, this is _not_ due to the properties of the cables or jacks.
Short of a connector totally covered in corrosion, no jack or reasonable cable will ever influence signals in the audio band.
Even SPDIF and TOSLINK aren't lossless
Yes they are, these are straight digital interfaces. Short of malfunction no data will be lost through them.
I can't tell the difference between 256 and anything above. VBR improves sound quality when you set a floor of 256 and a ceiling of infinity; otherwise, it's just a silly hack to save disk space at the expense of your MP3 files. It may not noticeably damage audio quality, but it sure as hell makes your MP3 files more complex, harder to analyze and play with/sort/etc. MP3 is just a poor file format for what VBR asks it to do.
VBR is part of the mp3 stadard, so it's not a hack by any stretch of the imagination.
VBR is IMO the Right Way(TM)to do audio coding as it essentially let you select a target quality instead of a target bitrate.
Current implementations of VBR are good enough to not degrade the sound noticeably so there is no real reason not to encode with VBR.
can't tell the difference between 256 and anything above. VBR improves sound quality when you set a floor of 256 and a ceiling of infinity; otherwise, it's just a silly hack to save disk space at the expense of your MP3 files. It may not noticeably damage audio quality, but it sure as hell makes your MP3 files more complex, harder to analyze and play with/sort/etc. MP3 is just a poor file format for what VBR asks it to do.
If joint stereo is a hack, then what do you call all the other techniques that make up mp3/ogg/whatever encoding.
JS simply utilizes the fact that significant signal is common for both channels and encodes this only once. Storing this information twice makes little sense.
JS is a efficient way to reduce space, which can be used to increase overall sound quality by using less aggressive compression on areas which actually matter.
Got any sources for this?
If you try to insert square waves into a cd-da bitsream it it will be represented in the audio band (components over 22KHz will of cource be lost).
How will a cd-player recognice a 'square' wave that is to be filtered from genuine music in the same band? After all a funtoning cd-player should pass 5-20KHz (and inserting a square wave at above 20KHz can hardly be called a square wave as you only get room for the fundamental and thus got a sine)
As for intentionally creating dropouts, I am pretty confident that this is in violation of the red book standard.
Re:WAP could have been cool
on
WAP Bashing
·
· Score: 2
You don't need wap for that. Allready there are several vending machines that accept payment via cellphone.
You just send a SMS message to a number listed on the vending machine with content describing what you want and the machine dipenses this. You are charged on the phone bill.
If you use the machine for actual work which is CPU bound (simulations, rendering) just calculate what your time is worth and how much you will save with the faster model. if number of hours saved over the lifetime of the machine multiplied by the cost of those hours is greater than the price difference the go for the faster one.
You will find that it will take a very high price difference, not to justify a faster processor in such cases.
However most people do not run anything CPU bound so they should find a cheaper model.
Where I work we generally buy the fastest (dual) CPU workstations we can get simply because it makes finacial sense. We constantly run simulations or calculation heavy software. It only takes a saving of 1 designer day over the lifetime of a machine to justify a $100 price increase.
Are you opposed to traditional firewalls as well? While a personal firewall can't compete with a dedicated firewall it will still provide far better protection than a bare connection.
While you can likely keep a machine free from trojans by beeing cautious of who you source your software from, there is still loads of spyware out there, some contained in quite useful apps.
While you can say (/shout) "SHOULD NOT RUN PROGRAMS THEY DO NOT KNOW". In practice noone can know all the software they run, as this entails reading and understanding all source, as well as building from the ground up all software you use. Some trust must be applied, and when you trust you may be mistaken.
A firewall app provedes an extra layer of security against your own erronous judgements (after all noone is perfect) as well an enable you to use and identify some spyware without sacrificing privacy (By blocking the spyware's channel to home)
You can build an on chip oscillator (this is done for virtually any modern RF circuit), however in order to make it slow enough to drive digital circuits you would need large valued passive components on board, these are expensive to implement as they will consume a large die area.
Concievably you could build a prescaler to handle the fast oscillator and scale it down to a managable speed but since a free running oscillator will have a rather imprecise speed, this prescaler must be designed very carefully.
The lack of a predictable clock will also be a detrimental for the end user as performance will vary rather wildly.
The use of an external timing source will enable you to stabilize and normalize the clock speed, which is exactly why you want a crystal.
Use of higher level timing sources like a heartbeat over ethernet is not apropriate as proper reception of such data really requires an accurate timing in the first place.
Generally reception of data without sunchronization is possible as long as the data is recieved much slower than the local clock. This way we can sample the data signal fast enough to make sense of it. I doubt such a scheme is appropriate for ethernet. (since the ethernet driver is on board you need to sample the ethernet signal directly which means you need a timing insensisitive way to transform the ethernet symbols to simple logic level signalling. I doubt this is a trivial task)
Clearly, the architecture of P4 was thus designed to break up long instructions into many shorter instructions (over-simplification) which which can each be completed in a shorter single clock cycle.
This is not how a pipeline works. Each instruction (or micro instruction) is executed in stages through a pipeline so that each stage only performs a small part of the overall operation. No modern high performance uP performs an entire op in a single cycle.
There is a very good reason to try to maximize pipelining whic rarely get mentioned here: The less logic depth between each pipeline stage the more calculations pr. transistor can be performed. The latter is actually a significant metric as die area and transistor dimentions are the most significant limitations for modern uP.
Shallower pipelines need to do more pr. pipeline stage which means each transistor will waste more time waiting for the signal to propagate through the deeper logic. (it will also waste more glitch power as the signal through a combinatorial logic unit will glitch for a while before stabilizing)
This is of cource a tradeof against the cost of a pipeline stall which the/. crowd has pointed out so well (as long as intel has the deepest pipeline)
A nuclear power plant, with all that tech, simply heats water to steam and moves a turbine. The nuclear part is just a better heater. This strikes me as silly.
Why do you think it silly? Heating water to drive a turbine happens to be an efficient way of converting energy of low refinement (heat) into energy of high refinement (electricity).
If all you are going to do with the electricity is to heat up some electric heat eement, then yes it's sliiy, otherwise: Do you have better suggestions?
Just because it doesn't sound high-tech doesn't mean it isnt (and iven if it weren't that isn't relevant anyway, only efficiency is)
Slashdot Mirror
You can certanly use MEMS techniques to make a better electrical circuit. (Though I am not familiar with applications in digital devices)
MEMS techniques can for instance help in creating excellent on-chip inductors, important for RF applications.
However, it is not given that the Next Big Thing in digital devices will be electronic at all. Maybe we'll find ways to make micromechanics perform better than electronics.
What simulator are you referring to? If you're referring to a Synopsys or Cadence simulator then you're off by an order of magnitude.
Modelsim PE can be had at around these costs (if you can negotiate well). Deepending on the market situation there may be emerging products that can be obtained cheaply. (A common tactic is to buy a cheap and crappy tool, then negotiate a deal with a vendor of a decent tool to switch in return for just paying maintenance)
2K is propably a too low estimate though
Again what tools are you referring to here? This seems off by at least a factor of two.
I was referring to the costs for paying somone else to do synthesis, P&R and tape out procedure. Not tools.
What's wrong with VHDL? What is it you want to express that you are unable to do clearly in VHDL?
And sure, you can design without explicitly making a state machine, but as long as you are making a synchronous circuit that is what it is going to end up as anyway.
While explicit state machines aren't right for everything, I have yet to see any sensible design methodology which can do away with them completely.
I was assuming at least 0.35um.
These prices are however just for the fabrication, no?
If so you will still need to do synthesis and P&R.
Of cource your point about just dropping in a processor as beeing uninteresting is well taken. Indeed a CPU is a very inefficient piece of logic. Dropping CPUs in FPGAs seem to me as a particularly stupid thing to do.
The whole reason many want a CPU in a SoC product is that they want the flexibility to reconfigure the chip and update it's algorithms without having to fabricate a new device. On a FPGA you allready have the flexibility to update at any time at practically no cost, so on those you will want to forgo the CPU entirely and implement the algorithm completely in hardware.
Also since FPGAs generally are unable to reach high clockspeeds, the designer really need to paralellize his algorithm to achieve any kind of performance.
(We recently have done a SoC project which was to be prototyped in a FPGA which included a 16 bit single issue unpipelined RISC core. On a virtex II 3000-4 this achieved a speed of 18MHz max)
Right. You do _not_ want to deped on the supplied xilinx software for synthesis. It's pretty much crap. Use Synplicity or Leonardo Spectrum (to be replaced with Precicion synthesis this summer) instead.
Also, you do most definetly not want to design your circuit graphically. The time you are going to use to draw a single state machine graphically, I will have designed the whole circuit. Graphical design tools are OK for the structural design phase (this is however a miniscule part of the whole process), otherwise they ar pretty much toys. The best digital hardware design tool availible is Emacs.
Once you have learnt hardware design, and understood the difference between a programming language and a hardware description language, VHDL is quite easy to deal with (I don't know much verilog, and from what I have see I don't want to deal with it. It's a verification hell)
Sure you can outsource. Practically all design houses outsorce fabbing (current estimates indicate that you need a turnaround of approx $7 billion to justify your own fab)
As a small time operator no fab is going to talk to you however. You are going to go through a middleman (just as well since these often supply design services like P&R(Place and route) and synthesis, withouth these services you'll be looking at a investment at approx $200 000 in tools)
For a pure digital diesign you can then get away with a tool investment of $2-5000 for simulation.
For fabbing you should expect $20-50000 in expenses to ready your design for tape-out. The cost of the manufacture will depend of wether you are going for an engineering run of MPW (Multi Project Wafer). An MPW will cost you $10-100 000 depending on process sophistication and size and yield 10-200 chips. An engineering run requires a dedicated mask set which will cost $100-500 000. The engineering run itself is consisderably cheaper and the masks may be reused for manufacture.
If you are going to do any leading edge design you will however need to do your own synthesis and P&R. If you target 0.18um of better you propably are going to need som degree of physical synthesis capability ($100000 and up). Fo manufacture you will also need to prepare a test procedure (ATPG tools (Automatic Test Pattern Generator) check in at approx $100000)
Also remeber that all tools will usually require a maintenance fee of 10-20% annually of purchase price (pays for upgrades and support)
At last don't forget computer hardware to run your tools on. Linux suffices for most tools, but some will only run on Sun/HP workstations.
We tried it on a sun at work. When we found that it was incompatible with Cadence Silicon Ensemble we threw it out and set up a NFS server instead.
Basically what happened was that for some reason SE wanted to enumerate all files mounted with sharity. Thus taking forever to start.
You are basically right about exponetial drop in yield as area goes up. Some of your calculations do miss the mark however as you assume uniform distribution of defects instead of the more realistic random distribution.
What intel (and any sane manufacturer who drop a significant amount of memory on die) will do is to add redundancy to regular structures. The l3 cache _will_ have redundancy, l2 most likely. l1 is more of a toss-up.
Redundancy is currently a standard engineering practice (Actually, most designs use IP modules bought from specialiced memory vendors who can integrate this kind of functionality for you).
While VHDL might seem cumbersome syntactically, you will soon realize that it brings a significant readability advantage over the c-like syntax usedinverilog and to some extent java.
As for structure. All HDL's will have some method for describing structure. VHDL uses the entity as the most common hierarchial component. A entity has a well defined interface, and may use generic parameters. In addition you can use blocs for describing smaller subcomponents and configurations for describing the overall system. (One very useful propery of VHDL is that you can have multiple implementations (architectures) of an entity. A configuration is used for selecting the apropriate one)
Genericity along with generate statements make it very easy to describe very general structures. Good for reuse.
From what I gather of JHDL is that it tries to be a behavioral description language rather than an HDL. This poses a problem at synthesis as behavioral synthesis is a lot tougher and more error prone process than rtl synthesis (though improvements are beeing made)
I don't really see at first glance what this particular language might offer (though it might find a slot in dynamically reconfigurable circuits, (which is rather margial IMO)).
Why on earth do you think anyone would be interested in what a geolocation server says about a users origin when the dealers can just look at the shipping information.
If the industry associations with interest in region division had the power to stop on-line dealers this way, they would allready have done it.
ATA 133 isn't just about the speed of the interface. It also overcomes capacity limits.
For instance maxtors D540X 160 GB drive could not exist on ATA 100 and below as they can't address so much space.
Having a synthesizable core does NOT mean that you can just drop it into any modern design. The deliverables for a commercially usable core are significant. Typically you need the following:
;-)
* Verilog code.
I'd rather have VHDL, but i can always synthesize a gate level VHDL description at a cost to simulation speed.
* TWO sets of timing constraints in Synopsys SDC format - one for synthesis, the other for static timing analysis and back-end physical design (i.e. defined clocks, high fanout nets like resets/selects, false/multicycle paths, case analysis statements for setting fastest propagation mode through the design).
While false path and multicycle path information must be provided if such exist, other timing constraints will be determined by the surrounding design, and must be selected by the system designer anyway.
Given the RTL description, constraints are a small matter.
* Synthesis scripts, which have specific mappings to the standard-cell libraries of the particular process (except if implemented in an FPGA).
Erm... if you can't even do that, what on earth are you doing with that expensive synopsys licence. gimme...
Seriously, you can't excpet the supplier of a MCU core to set up your synthesis tool for you.
* SRAM macro definitions and how they plug into the Verilog code (again, highly library/process specific and not relevant for an FPGA, assuming you can find enough on-board FPGA SRAM to equal the caches necessary for the ARM7)
Memory are usually provided by separate suppliers anyway. Given adequate information on the core's memory interface a small piece of glue logic would be quick to assemble. (Some do cores come with a MMU, which makes the job somewhat easier though)
* All JTAG-related files, including BSDL and tap controller specs.
Not really neccecary, and not really associated with MCU core.
* Scan and functional test vectors for Verilog VCS or NC-Verilog to show the core works.
Some of the point of an ip module is that you should have a reasonable excpectation that it is already verified. Functional testing of the core should therefore not be neccecary (though in this case I would propably do some verification myself)
Production testvectors are generated during synthesis, and are dependent of the synthesis environment and libraries, and thus not associated with the MCU core.
Using FPGA for prototyping is definetly a good thing, and is one of the areas where you can get hardware with FPGA to go in a PC.
You can get pci cards with FPGAs that interface to a digital simulator (like modelsim or quicksim). These are rather nice since they shorten simulation times hundredfold.
As for a reconfigurable device in a houshold device, they will certanly not be used as microprocessors, that would be a criminal waste!
Rather you would implement the time critical part of your algorithm in synthsizable code (rtl code) an dump that to the FPGA. There would not really be any need to send programmable circuits to such devices, you allready got one of those, your CPU.
A DSP is just a very specialized CPU, primarily focusing on math intesive stuff, but less on branching and conditionals.
As any CPU they are sequential devices. The load a instruction, decode it and execute it and repeat. Though modern DSP can paralellize many intructions it's resources are still statically allocated at the time of design. A DSP with two multipliers may at most perform two multiplications at any one time.
Using a fpga on the other hand allows you to design the circuit from the ground up. now if your algorithm needs to do 20 multiplications at a time, you can do so simply by building them on the device.
Using a fpga is fundamentally different from using a DSP or microcontroller/processor. The latter is a finished circuit with an assorment of operators selectable by an instruction opcode. The former can be configured into any circuit.
Risc or cisc architecture primarily affect the complexity of the fetch and decode stages of the CPU.
The famous Intel-pipeline is in the execute stage (ALU).
Pipelining is a strategy which is equally valid for both risc as in cisc architectures, and a risc architecture do not offer any complexity advantage in the execute stage. After all a multiplier is a multiplier regardless of overlaying architecture.
Nowdays we don't really see much diffrence in performance between risc and cisc architecures for upscale processors. This is because the savings in fetch and decode logic are dwarfed by other costs like prefetch, reordering and brach prediction (which are used for both architectures).
I've seen nice systems in a few m/b's for a 4 screw mount system, which i imagine would work well, but it needs to be standardised.
They are standardized. I believe the standard (hole geometry and keep-out zone) was set by intel with the launch of the P4. However most new socketA mainboards also support them. (One caveat may be that there are two different hole dimensions used. This can be compensated for though.
Both the 8045 heatsink mentioned in the article and some swiftech models use these holes, there propably are some others as well.
The quality of your connectors is more important than that of your sound card. Bring the audio to your receiver over SPDIF or TOSLINK, not over analog RCA cables! Sound cards --- ALL of them --- have really awful RCA connectors.
While digital interfaces bring a theoretical possibility for a quality change over analog links, this is _not_ due to the properties of the cables or jacks.
Short of a connector totally covered in corrosion, no jack or reasonable cable will ever influence signals in the audio band.
Even SPDIF and TOSLINK aren't lossless
Yes they are, these are straight digital interfaces. Short of malfunction no data will be lost through them.
I can't tell the difference between 256 and anything above. VBR improves sound quality when you set a floor of 256 and a ceiling of infinity; otherwise, it's just a silly hack to save disk space at the expense of your MP3 files. It may not noticeably damage audio quality, but it sure as hell makes your MP3 files more complex, harder to analyze and play with/sort/etc. MP3 is just a poor file format for what VBR asks it to do.
VBR is part of the mp3 stadard, so it's not a hack by any stretch of the imagination.
VBR is IMO the Right Way(TM)to do audio coding as it essentially let you select a target quality instead of a target bitrate.
Current implementations of VBR are good enough to not degrade the sound noticeably so there is no real reason not to encode with VBR.
can't tell the difference between 256 and anything above. VBR improves sound quality when you set a floor of 256 and a ceiling of infinity; otherwise, it's just a silly hack to save disk space at the expense of your MP3 files. It may not noticeably damage audio quality, but it sure as hell makes your MP3 files more complex, harder to analyze and play with/sort/etc. MP3 is just a poor file format for what VBR asks it to do.
If joint stereo is a hack, then what do you call all the other techniques that make up mp3/ogg/whatever encoding.
JS simply utilizes the fact that significant signal is common for both channels and encodes this only once. Storing this information twice makes little sense.
JS is a efficient way to reduce space, which can be used to increase overall sound quality by using less aggressive compression on areas which actually matter.
HP is a big name in instrumentation and lab electronics. Need a 50GHz scope? HP will propably be on your short list.
Got any sources for this?
If you try to insert square waves into a cd-da bitsream it it will be represented in the audio band (components over 22KHz will of cource be lost).
How will a cd-player recognice a 'square' wave that is to be filtered from genuine music in the same band? After all a funtoning cd-player should pass 5-20KHz (and inserting a square wave at above 20KHz can hardly be called a square wave as you only get room for the fundamental and thus got a sine)
As for intentionally creating dropouts, I am pretty confident that this is in violation of the red book standard.
You don't need wap for that. Allready there are several vending machines that accept payment via cellphone.
You just send a SMS message to a number listed on the vending machine with content describing what you want and the machine dipenses this. You are charged on the phone bill.
If you use the machine for actual work which is CPU bound (simulations, rendering) just calculate what your time is worth and how much you will save with the faster model. if number of hours saved over the lifetime of the machine multiplied by the cost of those hours is greater than the price difference the go for the faster one.
You will find that it will take a very high price difference, not to justify a faster processor in such cases.
However most people do not run anything CPU bound so they should find a cheaper model.
Where I work we generally buy the fastest (dual) CPU workstations we can get simply because it makes finacial sense. We constantly run simulations or calculation heavy software. It only takes a saving of 1 designer day over the lifetime of a machine to justify a $100 price increase.
Are you opposed to traditional firewalls as well? While a personal firewall can't compete with a dedicated firewall it will still provide far better protection than a bare connection.
While you can likely keep a machine free from trojans by beeing cautious of who you source your software from, there is still loads of spyware out there, some contained in quite useful apps.
While you can say (/shout) "SHOULD NOT RUN PROGRAMS THEY DO NOT KNOW". In practice noone can know all the software they run, as this entails reading and understanding all source, as well as building from the ground up all software you use. Some trust must be applied, and when you trust you may be mistaken.
A firewall app provedes an extra layer of security against your own erronous judgements (after all noone is perfect) as well an enable you to use and identify some spyware without sacrificing privacy (By blocking the spyware's channel to home)
You can build an on chip oscillator (this is done for virtually any modern RF circuit), however in order to make it slow enough to drive digital circuits you would need large valued passive components on board, these are expensive to implement as they will consume a large die area.
Concievably you could build a prescaler to handle the fast oscillator and scale it down to a managable speed but since a free running oscillator will have a rather imprecise speed, this prescaler must be designed very carefully.
The lack of a predictable clock will also be a detrimental for the end user as performance will vary rather wildly.
The use of an external timing source will enable you to stabilize and normalize the clock speed, which is exactly why you want a crystal.
Use of higher level timing sources like a heartbeat over ethernet is not apropriate as proper reception of such data really requires an accurate timing in the first place.
Generally reception of data without sunchronization is possible as long as the data is recieved much slower than the local clock. This way we can sample the data signal fast enough to make sense of it. I doubt such a scheme is appropriate for ethernet. (since the ethernet driver is on board you need to sample the ethernet signal directly which means you need a timing insensisitive way to transform the ethernet symbols to simple logic level signalling. I doubt this is a trivial task)
Clearly, the architecture of P4 was thus designed to break up long instructions into many shorter instructions (over-simplification) which which can each be completed in a shorter single clock cycle.
/. crowd has pointed out so well (as long as intel has the deepest pipeline)
This is not how a pipeline works. Each instruction (or micro instruction) is executed in stages through a pipeline so that each stage only performs a small part of the overall operation. No modern high performance uP performs an entire op in a single cycle.
There is a very good reason to try to maximize pipelining whic rarely get mentioned here: The less logic depth between each pipeline stage the more calculations pr. transistor can be performed. The latter is actually a significant metric as die area and transistor dimentions are the most significant limitations for modern uP.
Shallower pipelines need to do more pr. pipeline stage which means each transistor will waste more time waiting for the signal to propagate through the deeper logic. (it will also waste more glitch power as the signal through a combinatorial logic unit will glitch for a while before stabilizing)
This is of cource a tradeof against the cost of a pipeline stall which the
A nuclear power plant, with all that tech, simply heats water to steam and moves a turbine. The nuclear part is just a better heater. This strikes me as silly.
Why do you think it silly? Heating water to drive a turbine happens to be an efficient way of converting energy of low refinement (heat) into energy of high refinement (electricity).
If all you are going to do with the electricity is to heat up some electric heat eement, then yes it's sliiy, otherwise: Do you have better suggestions?
Just because it doesn't sound high-tech doesn't mean it isnt (and iven if it weren't that isn't relevant anyway, only efficiency is)