Clock Fequency or Bus Width ?

A theoretical question , which is better:

1-A 256-bit bus running @300 MHz Single Data Rate , or
2-A 192-bit bus running @400 MHz Double Data Rate

Both gives a bandwidth of 9600 Mbytes , is the first bus the better one ?
 
A theoretical question , which is better:

1-A 256-bit bus running @300 MHz Single Data Rate , or
2-A 192-bit bus running @400 MHz Double Data Rate

Both gives a bandwidth of 9600 Mbytes , is the first bus the better one ?
How do you define better?

Practical BW will be roughly be same.
400MHz is already very slow in this day and age, so 300MHz gives you no benefit.
DDR is a solved problem and not harder than SDR.
192 will be cheaper on a fronts: less DRAMs, less board space, easier PCB routing, less MC die space, less power(?).

I can't come up with benefits for the 256 bus, so be honest.
 
The numbers are just examples , for all I care they could be 3000 MHz and 4000 MHz respectively :)

The 192-bit bus is DDR , so while data is being transferred at 400 MHz , Address and clock signals are being transferred at half that speed (ie 200 MHz), so the 256-bus SDR already out matched it in frequency in that regard .. will that matter in the end ? or is it just a theoretical advantage ?
 
The numbers are just examples , for all I care they could be 3000 MHz and 4000 MHz respectively :)

The 192-bit bus is DDR , so while data is being transferred at 400 MHz , Address and clock signals are being transferred at half that speed (ie 200 MHz), so the 256-bus SDR already out matched it in frequency in that regard .. will that matter in the end ? or is it just a theoretical advantage ?
In theory, for very high frequencies, the fact that the SDR has higher rate address changes is a disadvantage for signal integrity.

In practice, it doesn't matter because very fast SDR doesn't exist AFAIK.

You have to assume that on-silicon problems are always solvable and that the solution won't be very costly in terms of gross margins. So the extra design effort is worth it (if your schedule allows.) It's PCB and component cost that can really eat into your margins. So, given a choice, go for the solution that optimizes board cost.
 
If you would allow me to ask, I have another question .. How engineers managed to force bus to transfer data two times per clock cycle .. did they use a sort of PLL dedicated for the bus (like a multiplier) ? or is it another thing entirely ?
 
Yeah , everybody knows that , the devil is in the details though .. current PCs are synchronous systems , they always need the clock signal to maintain operation , that is why a proposed PLL could be a valid assumption for DDR operation .
 
Yeah , everybody knows that , the devil is in the details though .. current PCs are synchronous systems , they always need the clock signal to maintain operation , that is why a proposed PLL could be a valid assumption for DDR operation .

No you don't need a PLL, synchronous logic can be rising edge or falling edge sensitive. I don't know what a DDR bus implementation looks like exactly but I'd guess it handles even and odd data in parallel with separate low and high edge sensitive logic.
 
Yeah , everybody knows that , the devil is in the details though .. current PCs are synchronous systems , they always need the clock signal to maintain operation , that is why a proposed PLL could be a valid assumption for DDR operation .
Contemporary memory controllers have PLLs and DLLs plus a bunch of pretty complicated digital logic that's built into the IO pads.
 
Are those directly related to their capability to transmit two data pulses per clock ?

If I wasn't making myself clear enough , let me rephrase the question , What makes DDR controllers so different from SDR controllers that they can operate two times per clock ?
 
Last edited by a moderator:
Are those directly related to their capability to transmit two data pulses per clock ?
Not necessarily. The PLL is there to decouple the system from the memory system. The DLL is used to move the incoming capture clock such that the incoming data can be clocked at a stable moment.

I'm rusty on this and may be making a fool of myself, but I believe it went like this:

For reads, the DQS/DQSn differential pair carries the clock, is driven by the RAM and changes at the same time as the data bits. Internally, you should clock the data when things are stable, in the middle of the data eye. For DDR, that means that the phase relation between clock and data needs to be shifted by 90 degrees. The DLL does that for you.

DDR does not require a DLL. If your clock has a decent duty cycle is a nicely tuned to change in the middle of the data eye, you can use a falling and rising edge FF or a double rate clock and that's it. The problem with DDR DRAM is that they are dealing with insanely high clock speeds and that the speeds are not constant.

For writes, the DQS/DQSn is driven by the MC instead of the RAM. So the data always has a source synchronous clock that runs with it. There is 1 DQS/DQSn pair per 8 or 9 bits. The routing delay between different byte lanes doesn't have to be as closely matched as the intra-byte routes.

There may be some things wrong in my explanation, but you get the general idea: the DLL is there to force a certain relationship between clock and data. ;)

Fundamentally, there is not a big difference between SDR and DDR: the only real difference is the transmit and receive logic inside the IO pads. Other than that, you can treat it internally as a double wide SDR.

E.g on the transmit side, DDR is not much more than 2 flip flops with a mux after it that's controlled by the clock.
 
Last edited by a moderator:
After tedious search , it seems there is indeed a PLL .. used in -at least- writing operations . For other things ,there is also something called a DLL , which is supposed to be similar to PLL .. I still cant put things together though .

PLL : Page 24
DLL : Page 20
http://www.latticesemi.com/lit/docs...essionid=f030a24eab0a49db57557c585373392b6274
It's uncommon to actually click on PDF links and even more so to then read the stuff in detail (I didn't yesterday), but this document really worth reading as it explains very well how things work.
 
Back
Top