So search for DRAM on wikipedia. The concept comes directly from the core memory that preceeded it (look that up too). You had ferrite bead cores that were arranged with row and column wires, and a sense line. You could energize a single core using a specific row and column and using the right hand rule cause a magnetic charge in one direction or the other. Then later by stimulating it again you could cause that charge to dump onto the sense line.
DRAM they "simply" used the capacitance features of a FET (notice how a FET symbol kind of has a cap in the middle) and did somewhat the same thing. Think of the cap as tiny rechargable batteries. You can have them empty for one state and charged for the other (say zero and one), but you have to keep going back and charging up the ones that need to stay in that state before they drain. Thus dram needs to be refreshed.
SRAM is the classic feedback on a nand gate flip flop thing. two transistors per gate you need four transistors I think for an sram bit, where you only need one for DRAM. Sram doesnt need to be refreshed, just dont turn the power off (core memory you could turn the power off, but reading a bit lost the state of the bit so you had to write back after reading).
So that is where the rows and columns comes from, and you still need them on ddr.
DDR (dual data rate) simply means they are using both halves of a clock, this is why what one would call 800Mhz dram uses a 400Mhz clock. They can move data on each half clock. (QDR used in SRAM they can move data on each half clock and have a read and write bus so can do reads and writes at the same time on half clocks so quad data rate).
Yes you absolutely have a controller if using DDR, you can make it yourself or just buy one (the ip). So your intel computer definitely has one, no reason whatsoever that each generation (every year or two) of x86 uses anything remotely the same as the prior generation.
Look up serial presence detect on wikipedia. DDR needs to be trained/tuned and with removable modules (DIMMs) are used that means you cant tune a board and then just use those values forever. You have to wake up and not know what is there, so each dimm has a small i2c rom (flash) on there which is read and contains the parameters need to setup the controller. So there is a JEDEC standard that is used for this.
Even very seasoned programmers can struggle with DRAM, bringing up a new board design, can literally take months with all seasoned/experienced staff working together (chip, board, software). UNfortunately for your intel motherboard traditionally the BIOS is contracted out and very much closed source, so you might find the intel docs on the controller but may never figure out how to get DDR up and working. There are now some movements in the direction of opening that up, but I have not looked into that in a while. maybe it happened already, but if you are banging out a motherboard you just call one of the very very short list of vendors and have them make your bios and/or bmc code. If on a non-x86 then it is quite a bit easier and the chip supplier probably has a BSP with what you need in it.
Look at the main chip vendors (micron, samsung, etc), take the dimms you have and find the brands and type in some of the numbers (some are just lot codes, others will direct you to the datasheets). Early in a new generation the parts are often 8 bits wide, and you get 8 or 9 per dimm (with or without ecc 64 bit or 72). As mentioned they eventually or immediately offer 16 bit wide and 32 (although these dont make sense for ECC enabled sticks/solutions). And as mentioned they can internally be various configurations. The dram controller doesnt really know nor care, look at the SPD (serial presense detect) information, they care mostly about total number of bits, row address bits, column address bits, and banks and ranks. The terminology and timing parameter (names) are used across the industry, the controllers use some of these parameters directly and some math is required for others. Some controllers do much of the tuning in logic, others software has to drive the tuning. Because the industry is driven off of removable dimms the whole thing is driven by tuning every time you power up (just like pci), things that are normally soldered down but are high speed (network interfaces) are not designed from the beginning to be tuned every time, you tune each product if needed and just hardcode those into the init.
So you might find some just run this code and it works examples, but I hope you are not walking into this thinking you are going to poke some registers in a DDR controller and have memory working.
With the intel computer and basically any other computer, you have the cpu it has a bus, the other end of that bus has a bus controller that sorts out transaction types and sends them to the right places based on address or type or both. Then a layer or two or ten later memory transactions hit the dram controller, ideally you have a cache in front of that not just because dram is really slow, but you kinda want 100% of the transactions to be bus widths in size, otherwise you have to design that into the dram controller. If you have a cache then the cpu side of the cache can do byte addressable accesses all the way up to whatever that cpu can do, per transaction. The cache handles those, on the dram side the cache only talks in cache lines which are integer multiples of the memory width or at least the dram controllers data bus width. And then the dram only has to deal with bus width sized transactions. So even if you have 9 8 bit wide chips it is managed in 72 bit wide transactions on the DDR side.
Older intel designs had multiple chips required for all of this (cpu, i/o/memory chips, pcie controllers and bridges, etc) and with time they are pulling more and more of that into the processor package (can still be multiple dies on the package or one die but are all under one lid). Things that lean toward system on a chip from day one like ARM based designs, it has mostly been on die/package the whole time. But they all work the same if they use DDRx memories at a certain level.
Intel got beat up by the motorola fans in the early days due to their segmented architecture. Which wasnt a bad idea and still isnt, but have since really tried for the illusion of a flat memory space, it is of course not true on intel nor motorola nor arm, etc. PCIe is mapped "into" the flat memory space such that the pcie address space and the x86 address space use the same address, but they are two separate address spaces, and worse the pcie bars used to all have to fit in one gig (back in the 32 bit days) and for backwards compatibility some 64 bits still have that limit, others have a 2 gig window, so all of your cards have to fit in that window, so naturally your video memory is not in any way shape or form "flat" you have a window through the pcie bar to view a fraction of that space. The flatness between the intel cpu address space and the pcie bus address space is because they wanted to do it that way, the bios decides all of these things and sets it up. Other systems can do that or not depending on how they want to do it the pcie address space can be completely separate from the cpus, they dont have to match. this messes with the "memory" space on an x86, this is why some older computers you were limited to 3GB on a 32 bit machine, even though you had to buy 4gig because they forced you to buy pairs and you had to buy 2 2GB pairs (the pairing thing is not a DDR requirement just a side effect in part of lazy designers or programmers, force all of them to match rather than having to deal with various timings, multiple memory controllers, one for each slot), and that continues on sometimes you lose one or two GB because they used that window for the pcie bars.
There is no reason to try to connect rows and columns to address, they are but the dram controller worries about that, the dram address space (which can be separate from the cpu address space, can have an offset for example, no reason why they have to line up perfectly either) as far as the cpu is concerned is just this flat space of some size. the cpu doesnt even care about the speed, it puts out a transaction and the transaction completes whenever it completes, the cpu doesnt know nor need to if there is a cache or not in the middle, certainly doesnt care about rows and columns. some subset of the cpus address space determined by the system design, is the memory/dram address space. then the dram controller determines from the dram address, which rows and columns of the chip to use, and there is no reason to assume it is linear, it may be advantageous to stripe things across banks or ranks for performance rather than make it linear.
Caches and mmus further remove the knowledge from the cpu and/or programmer. caches change the size and shape of the transactions on either side as mentioned above. the mmu changes the address of either side, virtual vs physical, and make mallocs easier, you might think you malloced 1GB of memory for some hungry program, but there is no reason that that 1GB of virtual memory space is linear in physical space, they could in theory chip that up into 4K or 16K or whatever the smallest unit of the mmu is (so long as the tables are big enough). Makes heap management much easier you no longer have to move stuff around to create a hole the size of the malloc, you instead need to find enough pieces of memory that add up to the right size that fit within the rules of the mmu.
cpus are extremly stupid as far as their address spaces are concerned, the knowledge is known by the programs and programmers the cpu simply does what the programmer says, put this address request out on the bus, and it just does it it doesnt know on an address by address basis if that is ram, flash, a peripheral on the chip on the motherboard, pcie space, etc. If it doesnt even know ram from not ram there is no way it knows dram from srams in the system much less rows and columns on the dram.
