Chances are, you're correct, they're not doing anything special.
On the other hand, its not that difficult of a thing to do. Now, I've never worked with DDR SDRAM (I mostly work with various SRAMs), but AFAIK there is nothing about the physical memory preventing dual-port page-locked access. The physical memory would remain the same, but the memory controller would consist of three arbitrators: one for each port and another to make sure that both ports weren't accessing the same page (of an arbitrary size, 1MB sounds about right here) at the same time.
Its not a difficult thing to do (all of my companies chips do this with SRAM). I'd venture to say that the gate count would be quite low, in the neighborhood of maybe 50K gates (way top end). A chip to do so wouldn't be expensive, and a high-end FPGA may be able to achieve what is needed if fabrication overhead was too high.
However, having not worked the specific tech, I can't say with definite certainty (YMMV). And there also remains the (significant) possibility that Microsoft overlooked this or decided not to bother. In general, my point was that I doubt they picked the UMA becasue it sucked or it was cheapest, I'm assuming there was an advantage and taking a SWAG at what that advantage might be.
A) I agree, 700k is freakin' enormous for an embedded OS. On the other hand...
B) You really have no basis for bashing their unified memory system. Without full system knowledge, things are not always how they seem. The chips and board designs I work with are full of things that make you gasp "what a stupid idea!" until you see that the particular offending architecture is indeed an advantage in this case.
For the XBOX, the unified memory should prove to be a massive advantage. By sacrficing upgradability and compatibility, and running it at some obscene bus rate, they could make it dual-port memory so that only the physcial memory has to be arbitrated and the graphics chip and processor can access different regions of memory simiualtaneously (ie, dual port, page-locked memory).
Licensing issues aside (I'm ignoring them only because you are), how is this different from using Windows as an X-terminal?
At work, I do all my programming via Xterm and Emacs from a Win2K box. I get the power of emacs and 'ok' version control (I do have some issues with SCCS) on our Sun Servers. At the same time, I can run Visio (which is very useful for diagramming clock routings) and a whole host of other Windows programs on my own PC. Its the best of both worlds.
Now imagine it from the other side, having Visio, etc. on a central.net server and a Linux environment local. For a select group of people, I imagine this would be very advantageous.
That sounds like a second law violation, if I follow you. By expending energy constrianing the dipoles, entropy should be increasing in your system. Unless of course, you define the system as the dipoles only and not including whatever is constraining them, in which case you're not properly defining your system.
Tim
Re:Unions doing the bashing....
on
Dial U for Union
·
· Score: 1
Ummm, no. F--- that.
Why should a union worker be unable to feed his family because the sheeple that he works with decided a strike would be a good idea? Does he deserve to have his car-windshield broken and his house vandalized because he wants to feed his kids?
If he wants to work, let him. And if a company wants to fire every single one of the ungrateful assholes who strike, they should be allowed to do that too. If the employees were really that important, the company wouldn't be able to replace them. If they can replace them, that just means that the union was ignoring economic reality in a quest to soak the company.
Yes, but for all the glories of FORTRAN, it is being replaced by Matlab.
Matlab is the RAD tool of the scientist and engineer. While the *very* heavy number crunching (stuff that takes days) may still be done in FORTRAN, if, for example, an Analog Hardware designer needs to plot the frequency response of a low-order(complexity wise, once a filter gets too complex, analog hw deign is akin to voodoo) low-pass filter, he can bang out the code in Matlab in half the time and get it to plot the results about thirty different ways.
I completely agree with you... as I stated, i know better than to think DSP assembly is a good learning language (though it would make a heck of a weed-out course:). A fundamental understanding of programming in a generic sense is important to develop good programming skills in any specific language or platform.
On the other hand, Lisp or Scheme may not be the best choices for a beginner language, for similar reasons. I never really groked lisp in college, I did horrible in my Lisp / Scheme AI course, and probably would have dropped out of CompSci had the first course been taught with a functional language rather than C++.
Maybe I'm one of those weird few, but I have an affinity to the metal. And I really dig DSP coding (I tend more to the bit-pushing, encoding/decoding side of things, as opposed to the fourier side though). And I get the feeling that the attrition rate for metal-lovers would be too high if a functional language was the focus.
So in general, I think that C or C++ provide a better middle ground, with less attrition as a beginner course. But to be really radical, I think that CS curriculums should be split into Systems Engineering (embedded stuff, Operating Systems), Theoretical CS (big focus on algortihms, AI, etc), and Software Engineering (more-or-less, what most CS curriculums are now).
And as for code-is-art... I wanted to make a huge sarcastic post describing a Reed-Solomon Encoder or data scrambler as art, but I elected to preserve my precious mojo:) (I'm an engineer dammit, not an artist)
I'm an assembly programmer, and there's more of us than you think. In fact, I'd say that its an increasingly useful skill.
All the world is not a PC. Look around you, there are embedded devices everywhere - cars, TVs, microwave ovens, cell phones, PC peripherals, etc. When you plan to sell 30 million low-cost devices, adding an extra $2 of SDRAM or a faster processor is not cost effective. Its better to use the smallest, cheapest processor you can get away with and write all the code in assembly. After all, you can hire 10 extra programmers for (much) less than adding $1 to the cost of a device that will sell 10 million units.
I program DSPs in assembly lanugage professionally, but I know better than to push *that* as beginner lanuage:)
Anyway, how the hell do you live without a preprocessor? When I tooled around a bit with Java in college, that was probably the thing that bothered me the most. Macros are just so damned useful that every language support a preprocessor. I use gnu m4 all the time just to get that effect.
In small devices that are expected to sell in volume, like a USB device controller, a $3 8051 with 8K on-die memory will likely do the job just fine. Putting a $10 ARM chip and $2 of external SDRAM (not to mention the cost increase due to a larger footprint) on the board just so you can (maybe) save some development time is not a cost effective option, so its not done.
With custom devices and DSPs, smaller and faster are even more important. Asking our LSI team for an extra bit of addressing (and the associated memory) tends to draw comments about our group's bloat-ware that takes up an entire 1K code / 1K data:)
Nope. ADSL, at least any chipset I'm familiar with, does not operate within audible range.
Our chips start at bin 32, Alcatel at 38, and TI god-knows-where, but above 30. Bins are 4.325 KHz wide, so bin 30 is 30*4.325Khz, or about 130 KHz. Not audible.
The reason you need to have the filters is to keep the DSL signal from jacking-up your phone. Side effects from the gain imparted on the signal by the DSL transceiver can cause audible artifacts in your phone signal and may even cause damage if your phone doesn't employ decent filtering.
Its been pretty-much assumed for the last year or so that any VDSL solution is going to be DMT based, except with the number of bins expanded to 1024 (and therefor going to 4 MHz).
The biggest problem with it is that it simply isn't economical (currently) to make a DSP that can FFT 1024 frequency bins in 250us (as per the DMT spec). Not to mention the fact that you will be cramming many more bits into each frequency bin, further wrecking the signal-to-noise margin.
In the end, say about 3-5 years, I expect to see VDSL in a lot of places, but it will require major infrastructure overhaul. Because the SNR margin will be reduced so dramatically, the range of VDSL will be *maybe* 10 kilofeet at the most. So either you'll have to live close to your CO, or the CO will have to move a DSLAM closer to you.
And if you don't trust me, ask yourself this question : why, if Iraq lost the war and NATO invaded it, did we let Saddam in place and start an ambargo while we could have just put him in prison ? When Nazi germany lost WWII, we didn't let the Nazis in place and ambargo Germany... why do this with Saddam then ?
I'll answer this: Because Colin Powell, is a true pacifist (not to mention, entirely correct on this point). At the time of the Gulf War, Iraq had an unimaginably large standing army, fourth largest in the world (manpower wise). When the ground campaign ceased, the iraqis were in full retreat, having lost 100,000 men. At that point the stated and unstated objectives of the campaign had been accomplished... Kuwait had been freed, and their oil fields were again back in the hands of their former owners (though slightly burnt).
At that time, there was seen to be little to gain from mowing down an additional 900,000 iraqi soldiers and god-knows-how-many civillians. Now, you could claim that the sanctions have killed more (though I doubt you'd be correct, but you can claim it), but Iraq could have ended those sanctions at any time simply by allowing UN weapon-inspectors free access to the facilities that they wished to see.
Iraq's problems are entirely of their own doing. Anytime they wish to allow UN weapon inspectors, the sanctions are gone.
Tim
USB, while designed for low-speed devices, actually has 12 Mbit/s of bandwidth available, 8 Mbit/s of which is doled out on the Isochronous channel on a first-come-first-serve basis. This can lead to some nasty conflicts, which is the reason that practically nobody uses the isochronous channel (not to mention its a pain in the ass to work with). But, I did manage to write code that allows 8-Mbit ADSL over USB (with an 8051 controller, no less:), presuming no bandwidth hogging devices like cameras are attached.
Firewire, in the abstract, is pretty similar but with much (much much) higher bandwidth. Unfortunately, it'll never be as cheap for a few reasons. Namely:
1) Having a 400 Mbit/s serial connection means that you need a 400 MHz clock at the line.
2) Every device on the bus is aware of every other device on the bus, meaning that the protocol is much more difficult to deal with.
3) The above two problems mean that you're going to need a fairly fast processor on board (a $3 8051 won't cut it). Having a faster processor means increased cost there, plus the fact that power consumption will go up. Increased power consumption means that you're less likely to be able to bus-power your device, meaning you also have to add an AC rectifier/power-supply increasing the cost of the design further.
Firewire is just a bit ahead of its time. The processing power needed isn't yet economical in consumer embedded devices, but should be soon.
The clever idea for building inductors into ICs has already come along. I forget what its called (Analog LSI is not really my area of expertise), but you can effectively simulate inductance using a bunch of resistors, op-amps, and capactitors. If you want better frequency response, use more components. I don't know how well this would for a receiver, but it works pretty well for filters, and eliminates the need to populate noisy, interference causing coils all over the PCB.
I may be going to Taiwan at some point in the future to support some test software I wrote, and I gotta ask:
How's the food there?
I'm asking because many of the people I've talked to mentioned that its mostly seafood. While I enjoy the occasional sushi (but not tuna, salmon, or eel; and even then I do kinda feel sick afterwords), most fish and I don't agree. Judging by the large amounts of finish eaten by my Taiwanese colleagues, I'm kind of dreading the trip. Any chance you can make me feel better about it?:)
At work, we use Intel 80188 processors on our development boards as host processors to our DSP *because* it is so godawful slow and has a very limited pin-count. In effect, by making things work with a 80188, no matter what cheap processor our customers decide to use, the worst they'll have to is insert some delay cycles:)
Linux driver is on the way, I believe. We may even have an engineering release done for it, but not a production one at this point. If you weren't an AC, I'd see if I could hook you up as a tester:)
Incorrect about ADSL, see my above post. There are significant differences in line modulation between an ADSL CO and CP.
As far as symmetric goes, maybe, but one side has to provide a timing reference, and the box will probably have to be reconfigured somewhat.
The VCI (or any other ATM layer stuff) has absolutely nothing to do with whether the modems will train with each other. That's dependent on the line modulation and how its implemented on the particular transceiver. I highly suggest reading a book on Signal Processing before spouting off any more about DSL.
Nope, not gonna happen.
Standard DMT ADSL splits the frequency domain into 255 bins of ~4.325 kHz each. The upstream (CP to CO) is done in bins 15-35 (or thereabouts) and the downstream (CO to CP) is transfered in bins 45 - 255 (or we hope so, anyway).
Not only will your frequencies be misaligned when connecting two CPE modems (each trying to transmit in the same range), the analog filters will be way out of whack, and there are major differences in what each side has to do during the train sequence (most notably, the CO will put a pilot tone in bin 16 to indicate to the CPE end that it is, in fact, there and to start training).
So no, unless you want to reprogram your units and replace the filters.
Tim
hey. Reed-solomon. Working on DSL firmware I live and breathe RS coding/decoding. now, completely offtopic, I'm intetrested in where you found information regarding it. Don't bother replying here, just shoot me an email at thetimdog@hotmail.com.
Thnaks,
Tim
Re:Speaking of small reactors...
on
Fission in a Box
·
· Score: 1
Yes it does, from what I remember from my physics education (serving me well as useless information as a programmer:). However, uranium and plutonium aren't exactly compressible, so we're stuck with needing a good bit of the stuff.
Slashdot Mirror
Chances are, you're correct, they're not doing anything special.
On the other hand, its not that difficult of a thing to do. Now, I've never worked with DDR SDRAM (I mostly work with various SRAMs), but AFAIK there is nothing about the physical memory preventing dual-port page-locked access. The physical memory would remain the same, but the memory controller would consist of three arbitrators: one for each port and another to make sure that both ports weren't accessing the same page (of an arbitrary size, 1MB sounds about right here) at the same time.
Its not a difficult thing to do (all of my companies chips do this with SRAM). I'd venture to say that the gate count would be quite low, in the neighborhood of maybe 50K gates (way top end). A chip to do so wouldn't be expensive, and a high-end FPGA may be able to achieve what is needed if fabrication overhead was too high.
However, having not worked the specific tech, I can't say with definite certainty (YMMV). And there also remains the (significant) possibility that Microsoft overlooked this or decided not to bother. In general, my point was that I doubt they picked the UMA becasue it sucked or it was cheapest, I'm assuming there was an advantage and taking a SWAG at what that advantage might be.
Tim
Ok.
A) I agree, 700k is freakin' enormous for an embedded OS. On the other hand...
B) You really have no basis for bashing their unified memory system. Without full system knowledge, things are not always how they seem. The chips and board designs I work with are full of things that make you gasp "what a stupid idea!" until you see that the particular offending architecture is indeed an advantage in this case.
For the XBOX, the unified memory should prove to be a massive advantage. By sacrficing upgradability and compatibility, and running it at some obscene bus rate, they could make it dual-port memory so that only the physcial memory has to be arbitrated and the graphics chip and processor can access different regions of memory simiualtaneously (ie, dual port, page-locked memory).
Tim
Licensing issues aside (I'm ignoring them only because you are), how is this different from using Windows as an X-terminal?
.net server and a Linux environment local. For a select group of people, I imagine this would be very advantageous.
At work, I do all my programming via Xterm and Emacs from a Win2K box. I get the power of emacs and 'ok' version control (I do have some issues with SCCS) on our Sun Servers. At the same time, I can run Visio (which is very useful for diagramming clock routings) and a whole host of other Windows programs on my own PC. Its the best of both worlds.
Now imagine it from the other side, having Visio, etc. on a central
Tim
1 L^3?!
:)
What are dimensions 4, 5, and 6 that your brain occupies?
Tim
Could you elaborate?
That sounds like a second law violation, if I follow you. By expending energy constrianing the dipoles, entropy should be increasing in your system. Unless of course, you define the system as the dipoles only and not including whatever is constraining them, in which case you're not properly defining your system.
Tim
Ummm, no. F--- that.
Why should a union worker be unable to feed his family because the sheeple that he works with decided a strike would be a good idea? Does he deserve to have his car-windshield broken and his house vandalized because he wants to feed his kids?
If he wants to work, let him. And if a company wants to fire every single one of the ungrateful assholes who strike, they should be allowed to do that too. If the employees were really that important, the company wouldn't be able to replace them. If they can replace them, that just means that the union was ignoring economic reality in a quest to soak the company.
Tim
Yes, but for all the glories of FORTRAN, it is being replaced by Matlab.
Matlab is the RAD tool of the scientist and engineer. While the *very* heavy number crunching (stuff that takes days) may still be done in FORTRAN, if, for example, an Analog Hardware designer needs to plot the frequency response of a low-order(complexity wise, once a filter gets too complex, analog hw deign is akin to voodoo) low-pass filter, he can bang out the code in Matlab in half the time and get it to plot the results about thirty different ways.
Tim
I completely agree with you... as I stated, i know better than to think DSP assembly is a good learning language (though it would make a heck of a weed-out course :). A fundamental understanding of programming in a generic sense is important to develop good programming skills in any specific language or platform.
:) (I'm an engineer dammit, not an artist)
On the other hand, Lisp or Scheme may not be the best choices for a beginner language, for similar reasons. I never really groked lisp in college, I did horrible in my Lisp / Scheme AI course, and probably would have dropped out of CompSci had the first course been taught with a functional language rather than C++.
Maybe I'm one of those weird few, but I have an affinity to the metal. And I really dig DSP coding (I tend more to the bit-pushing, encoding/decoding side of things, as opposed to the fourier side though). And I get the feeling that the attrition rate for metal-lovers would be too high if a functional language was the focus.
So in general, I think that C or C++ provide a better middle ground, with less attrition as a beginner course. But to be really radical, I think that CS curriculums should be split into Systems Engineering (embedded stuff, Operating Systems), Theoretical CS (big focus on algortihms, AI, etc), and Software Engineering (more-or-less, what most CS curriculums are now).
And as for code-is-art... I wanted to make a huge sarcastic post describing a Reed-Solomon Encoder or data scrambler as art, but I elected to preserve my precious mojo
Tim
Hey now!
I'm an assembly programmer, and there's more of us than you think. In fact, I'd say that its an increasingly useful skill.
All the world is not a PC. Look around you, there are embedded devices everywhere - cars, TVs, microwave ovens, cell phones, PC peripherals, etc. When you plan to sell 30 million low-cost devices, adding an extra $2 of SDRAM or a faster processor is not cost effective. Its better to use the smallest, cheapest processor you can get away with and write all the code in assembly. After all, you can hire 10 extra programmers for (much) less than adding $1 to the cost of a device that will sell 10 million units.
Tim
I program DSPs in assembly lanugage professionally, but I know better than to push *that* as beginner lanuage :)
Anyway, how the hell do you live without a preprocessor? When I tooled around a bit with Java in college, that was probably the thing that bothered me the most. Macros are just so damned useful that every language support a preprocessor. I use gnu m4 all the time just to get that effect.
Tim
Correct.
:)
In small devices that are expected to sell in volume, like a USB device controller, a $3 8051 with 8K on-die memory will likely do the job just fine. Putting a $10 ARM chip and $2 of external SDRAM (not to mention the cost increase due to a larger footprint) on the board just so you can (maybe) save some development time is not a cost effective option, so its not done.
With custom devices and DSPs, smaller and faster are even more important. Asking our LSI team for an extra bit of addressing (and the associated memory) tends to draw comments about our group's bloat-ware that takes up an entire 1K code / 1K data
Tim
Huh?
V1 rockets were ramjets. A very simple design, and stable enough to fly from france to london.
Tim
GPL'ed code is owned by the author who released it under the GPL.
GPL says "You can do as you wish with this code, except..."
If you (as the public) truly owned the code, you could do as you wish with it, no exceptions.
Tim
Nope. ADSL, at least any chipset I'm familiar with, does not operate within audible range.
Our chips start at bin 32, Alcatel at 38, and TI god-knows-where, but above 30. Bins are 4.325 KHz wide, so bin 30 is 30*4.325Khz, or about 130 KHz. Not audible.
The reason you need to have the filters is to keep the DSL signal from jacking-up your phone. Side effects from the gain imparted on the signal by the DSL transceiver can cause audible artifacts in your phone signal and may even cause damage if your phone doesn't employ decent filtering.
Tim
Ok, the link is kinda good, but out of date.
Its been pretty-much assumed for the last year or so that any VDSL solution is going to be DMT based, except with the number of bins expanded to 1024 (and therefor going to 4 MHz).
The biggest problem with it is that it simply isn't economical (currently) to make a DSP that can FFT 1024 frequency bins in 250us (as per the DMT spec). Not to mention the fact that you will be cramming many more bits into each frequency bin, further wrecking the signal-to-noise margin.
In the end, say about 3-5 years, I expect to see VDSL in a lot of places, but it will require major infrastructure overhaul. Because the SNR margin will be reduced so dramatically, the range of VDSL will be *maybe* 10 kilofeet at the most. So either you'll have to live close to your CO, or the CO will have to move a DSLAM closer to you.
Tim
I'll answer this: Because Colin Powell, is a true pacifist (not to mention, entirely correct on this point). At the time of the Gulf War, Iraq had an unimaginably large standing army, fourth largest in the world (manpower wise). When the ground campaign ceased, the iraqis were in full retreat, having lost 100,000 men. At that point the stated and unstated objectives of the campaign had been accomplished... Kuwait had been freed, and their oil fields were again back in the hands of their former owners (though slightly burnt). At that time, there was seen to be little to gain from mowing down an additional 900,000 iraqi soldiers and god-knows-how-many civillians. Now, you could claim that the sanctions have killed more (though I doubt you'd be correct, but you can claim it), but Iraq could have ended those sanctions at any time simply by allowing UN weapon-inspectors free access to the facilities that they wished to see. Iraq's problems are entirely of their own doing. Anytime they wish to allow UN weapon inspectors, the sanctions are gone. Tim
USB, while designed for low-speed devices, actually has 12 Mbit/s of bandwidth available, 8 Mbit/s of which is doled out on the Isochronous channel on a first-come-first-serve basis. This can lead to some nasty conflicts, which is the reason that practically nobody uses the isochronous channel (not to mention its a pain in the ass to work with). But, I did manage to write code that allows 8-Mbit ADSL over USB (with an 8051 controller, no less :), presuming no bandwidth hogging devices like cameras are attached.
Firewire, in the abstract, is pretty similar but with much (much much) higher bandwidth. Unfortunately, it'll never be as cheap for a few reasons. Namely:
1) Having a 400 Mbit/s serial connection means that you need a 400 MHz clock at the line.
2) Every device on the bus is aware of every other device on the bus, meaning that the protocol is much more difficult to deal with.
3) The above two problems mean that you're going to need a fairly fast processor on board (a $3 8051 won't cut it). Having a faster processor means increased cost there, plus the fact that power consumption will go up. Increased power consumption means that you're less likely to be able to bus-power your device, meaning you also have to add an AC rectifier/power-supply increasing the cost of the design further.
Firewire is just a bit ahead of its time. The processing power needed isn't yet economical in consumer embedded devices, but should be soon.
Tim
The clever idea for building inductors into ICs has already come along. I forget what its called (Analog LSI is not really my area of expertise), but you can effectively simulate inductance using a bunch of resistors, op-amps, and capactitors. If you want better frequency response, use more components. I don't know how well this would for a receiver, but it works pretty well for filters, and eliminates the need to populate noisy, interference causing coils all over the PCB.
Tim
I may be going to Taiwan at some point in the future to support some test software I wrote, and I gotta ask:
:)
How's the food there?
I'm asking because many of the people I've talked to mentioned that its mostly seafood. While I enjoy the occasional sushi (but not tuna, salmon, or eel; and even then I do kinda feel sick afterwords), most fish and I don't agree. Judging by the large amounts of finish eaten by my Taiwanese colleagues, I'm kind of dreading the trip. Any chance you can make me feel better about it?
Hehe, yup.
:)
At work, we use Intel 80188 processors on our development boards as host processors to our DSP *because* it is so godawful slow and has a very limited pin-count. In effect, by making things work with a 80188, no matter what cheap processor our customers decide to use, the worst they'll have to is insert some delay cycles
Tim
Woohoo! That's our reference design! :)
:)
Linux driver is on the way, I believe. We may even have an engineering release done for it, but not a production one at this point. If you weren't an AC, I'd see if I could hook you up as a tester
Tim
Incorrect about ADSL, see my above post. There are significant differences in line modulation between an ADSL CO and CP.
As far as symmetric goes, maybe, but one side has to provide a timing reference, and the box will probably have to be reconfigured somewhat.
The VCI (or any other ATM layer stuff) has absolutely nothing to do with whether the modems will train with each other. That's dependent on the line modulation and how its implemented on the particular transceiver. I highly suggest reading a book on Signal Processing before spouting off any more about DSL.
Tim
Nope, not gonna happen. Standard DMT ADSL splits the frequency domain into 255 bins of ~4.325 kHz each. The upstream (CP to CO) is done in bins 15-35 (or thereabouts) and the downstream (CO to CP) is transfered in bins 45 - 255 (or we hope so, anyway). Not only will your frequencies be misaligned when connecting two CPE modems (each trying to transmit in the same range), the analog filters will be way out of whack, and there are major differences in what each side has to do during the train sequence (most notably, the CO will put a pilot tone in bin 16 to indicate to the CPE end that it is, in fact, there and to start training). So no, unless you want to reprogram your units and replace the filters. Tim
hey. Reed-solomon. Working on DSL firmware I live and breathe RS coding/decoding. now, completely offtopic, I'm intetrested in where you found information regarding it. Don't bother replying here, just shoot me an email at thetimdog@hotmail.com.
Thnaks,
Tim
Yes it does, from what I remember from my physics education (serving me well as useless information as a programmer :). However, uranium and plutonium aren't exactly compressible, so we're stuck with needing a good bit of the stuff.
Tim