Welcome, Guest. Please login or register.

Author Topic: Of FPGAs and the way forward  (Read 6739 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show all replies
    • http://www.applemonthly.com
Re: Of FPGAs and the way forward
« on: August 08, 2008, 12:37:57 AM »
Quote

bloodline wrote:
@SamuraiCrow,

I'm not sure if I follow your thinking here. The FPGA issues aside, since they have been covered by AlexH... I don't uderstand your left brain/right brain metaphore...

Lets look at my aged Althon64 PC (and contrast it with my one of my A1200s with 4meg FastRam)...
correcting a lot of mistakes here
Quote


The Athlon: It has a CPU on a bus with some memory, local and for the CPU only.
The A1200: It has a CPU on a bus with some memory, local and for the CPU only.
The Athlon has the memory controller built-into the CPU, requiring all system access to utilize the Athlon whenever they need memory.  Is limited to an 8-bit DMA system.  
By comparison, the Amiga has memory used exclusively for the CPU, and used for the rest of the system.
Quote


The Athlon: It has a separate main System bus for all support systems (GFX, Audio, I/O).
The A1200: It has a separate main System bus for all support systems (GFX, Audio, I/O).

No, the Athlon has all support systems running through the CPU bus, opposite of the Amiga which keeps them seperately
Quote


The Athlon: It has a GFX CoProcessor (a Nvidia 8600) with it'a own RAM (512Megs) that performs all gfx functions, and capible of massively parallel GP processing.
The 1200: It has a GFX CoProcessor (The Blitter, Copper and barrel shifter) with its own RAM (well shared with the Audio and I/O).
Here is the real difference.  The Athlon has this the opposite of the Amiga, sharing the CPU memory while the Amiga shares the video memory.  The advantage to this is in the fact that the CPU gets undivided memory access in the Amiga, unlike the Athlon[/quote]
The Athlon: It has a dedicated Audio DSP and its own RAM.
The A1200: It has a DMA fed DAC, and RAM shared with the GFX and I/O
[/quote]I don't see many Athlons with audio DSP's. In addition, you remain stuck with the 8-bit DMA system of the Athlon vs the 16-bit DMA of the Amigas.
Quote

I could go on... but my point is made, the Athlon is structurally rather similar to the A1200, but massively improved on the idea. Each of the various subsystems are powerful independant devices in their own right. I don't really see how this relates at all to your mataphore?

No, your example fails due to not understanding the underlying design.
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.
 

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show all replies
    • http://www.applemonthly.com
Re: Of FPGAs and the way forward
« Reply #1 on: August 08, 2008, 11:51:16 PM »
Quote

bloodline wrote:
Quote

SyrTran wrote:
Quote

bloodline wrote:
I can only think he is referring to the old southbridge DMA... I guess he doesn't know that it's not used any more, since DMA is an old concept... with USB, FIrewire and PCI-E

Wow.  just Wow.

I hope you didn't mean that the way you typed it.


Ok, I will have to go into detail then... (Can't anyone on this board use Google?)

Quote

I should probably let Nate answer this himself, as I'll probably get it as wrong as you did.  Yes, DMA is old.  It's as old as the IBM System 360, and it's as old as the Nvidia GTX 280.

DMA stands for Direct Memory Access.  It's not (just) a theoretical concept, or an antique type of data bus, it's a data transfer method, regardless of bus.  It's the method a peripheral device uses to put/get its data into/from memory without getting permission from the CPU.  It's written into the PCI/AGP/PCI-e specs.

An nVidia SLI setup uses DMA.  It doesn't wait for the CPU to fill its (3-way) 3 Gigabytes of texture/data RAM, the CPU tells the GPU where in main memory the data is, and the GPU goes and gets it, itself.  If you have a network connector, it will also DMA its data, as will any SCSI, and most SATA and PATA controllers (hint: UDMA mode).

BTW, Firewire, aka IEEE-1394, aka Sony iLink, also uses DMA.

DMA is also the reason there's a patch for A1-XEs.  If the OS isn't critically careful, the peripheral DMA data can get overwritten by the CPU - while the DMA transfer is still in progress.


When you refer to DMA on the IBM-PC compatible architecture you are refering to the old 16bit ISA system, the DMA in this part of the system can only access the lower 16megs of the adderss space. Almost nothing uses this any more... but it is all still included in the southbridge... this is where things like Serial ports, Parallel port, the Floppy drive, Real time clock, Legacy IDE, PS/2 ports and god knows what else antiquated hardware sits.

All modern parts of the system, GFX cards, Sound cards, I/O (USB, Firewire, ATA/S-ATA, Ethernet, etc...) sit on the PCI/PCI-E bus. Which is then connected via the northbridge to the CPU. The CPU has a second local bus where the main system RAM is located... I hope Downx wasn;t suggesting that the System RAM was located on the PCI/PCI-E bus because that would be a pretty horrific architecture. The Athlon64 is slightly different at the top as it use HyperTransport, and my particular Athlon64 actually has three Hyper transport links and its own RAM controler... but that just confuses this issue.

Yes a horrific design if it was done.  Thankfully it is not.  But you are still tied to the CPU / Northbridge (there is no HT to Northbridge connection in Athlons, the Northbridge is embedded INTO the Athlon, the HT is the connection to the southbridge) for system memory access.  That means whenever this memory is polled for such minor things as, say, keyboard or mouse access, you will find that the memory is, ta da, blocked from CPU access during this time.  The whole use of CPU cache, pre-fetching, all those fun things is to prevent CPU idle during this period.  But as the CPU keeps going faster and faster but a keyboard is still, really, the same thing that was powered by the 4092 way back when, that lag time will get worse and worse.  By putting the CPU's memory front-and-center makes sense for a low cost minicomputer.  But the Amiga instead did a "hey, we have a dedicated RAM for our peripherals" which means that the peripherals ran without bothering the main CPU.  The PC's video and DSP cards are a step in the right direction, but not a complete one.  Intel's new maneuvers for a TurboFlash on board is, really, the best step to this I've seen in ages.  But nothing is handling the peripherals but... the CPU.  Your big huge math engine is resorting to doing the same meanial tasks as an 8088 controller chip.  Some high-end systems such as my Xeon here have an i940 processor for controlling these peripherals, but they are the exception, rather than the rule, and using a general purpose CPU for such a specialized task is crude.  The best route would be to do the "GPU/DSP" route, with dedicated controlling systems for the various peripherals.
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.
 

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show all replies
    • http://www.applemonthly.com
Re: Of FPGAs and the way forward
« Reply #2 on: August 09, 2008, 08:59:42 PM »
Quote

bloodline wrote:
@Downx

Are you smoking crack? My mouse and Keyboard are on USB, which itself is on the PCI-E bus, which is connected to the CPU via HyperTransport... the RAM is connected directly to the CPU, not via an HT link.

Your idea of a computer system seems 15 years old!!!! The only thing on the south bridge is pretty much just the BIOS now (since I don't use any of the legacy ports or floppy disk)...

Start here to refresh your memory:

http://en.wikipedia.org/wiki/Hyper_transport
http://en.wikipedia.org/wiki/Socket_939


And here is a nice picture of the standard PC architecture (Note the different Busses):



Um, dude, that is what I just said.  The "Northbridge" which includes the RAM controller is integrated onto the die with the CPU in the Athlon, with a HT bus connecting the CPU to the southbridge.

So you agree, for anything to utilize system RAM, it must go through the northbridge, now handily contained within the silicon of the Athlon CPU?  Or what are you saying?

That picture you have is several years old, only Intel still uses that architecture, and Intel is abandoning that next year with their next-generation interconnect technology.  Death to the Front Side Bus!
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.
 

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show all replies
    • http://www.applemonthly.com
Re: Of FPGAs and the way forward
« Reply #3 on: August 10, 2008, 05:31:48 PM »
Um, dude, you just destroyed your own arguement.

No, the CPU ram is closer to the CHIP ram, that is, "a shared pool of RAM, used by all peripherals.  There is no PC equal to the Fast RAM, that is RAM used soly by the CPU, without interruption by those pesky peripherals.  Video cards use their own RAM, which is closer to the Amiga's Fast RAM, but is now only for the GPU.

as I said, inverse design.

And, as pointed out, Intel itself is abandoning that design.  FSB are for antiques.
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.