Some newbe questions.

Hello all!
I'm new here and I don't know if it's good place for asking questions. May I count on your help?

I have some experience with fpga but totaly zero with high speed memory. I would like to design arbitrary wave generator and my project requires to use DDR3 memory. I have picked Cyclone 5 fpga 5CEFA2F23C7N which can handle DDR3 memory up to 400MHz and I'm considering to use this chip AS4C64M16D3 (link http://www.digikey.com/product-detail/en/AS4C64M16D3-12BCNTR/AS4C64M16D3-12BCNTR-ND/4965298 ) as LUT in my AWG but in datasheet there is said that this is memory for 800MHz speed. My question is if it maches? Will this specific chip (and any other maybe) work with slower clock, and provide slower data rate?

Regards
PB

 

[Piotr Błachnio]

I have found something... May anyone tell me if I interpret it correctly?
There is filed in table 17 "Minimum Clock Cycle Time (DLL off mode)" equal 8 ns it gives 125MHz frequency so I'm able to take longer Clocl Cycle Time - 10ns and have 100MHz clock what gives 400MHz data rate in DDR3, doesn't it?

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

On 9/23/2014 11:36 AM, Piotr B??achnio wrote:
I have found something... May anyone tell me if I interpret it correctly?
There is filed in table 17 "Minimum Clock Cycle Time
(DLL off mode)" equal 8 ns it gives 125MHz frequency so I'm
able to take longer Clocl Cycle Time - 10ns and have 100MHz clock
what gives 400MHz data rate in DDR3, doesn't it?

I don't know for sure, but I have not seen a digital part that wouldn't
work with a slower clock since I used the 8008 CPU chip. Even those had
a minimum clock speed that was some 100 times slower than the max.

I haven't actually done DDR, but it is synchronous, and I believe
that you do need to get the timing pretty close.

Minimum clock speeds lasted longer than the 8008. At least to
the 8080 (one advantage of the Z80 was that it didn't do that),
and the 8086/8088. I believe the minimum for the original 8086
was about 2MHz or so.

Newer processors might not have dynamic logic, but they have
internal PLLs on the clock that won't lock much lower than the
specified frequency.

DDRs might have a PLL, too.

If the part had a minimum frequency (maximum period) they
would list that.

Dynamic RAMs do have a max timing value for the refresh cycle.
So even if you run the part slower, you have to maintain the
refresh interval.

That, too.

-- glen

 

[rickman]

On 9/23/2014 11:36 AM, Piotr Błachnio wrote:

I have found something... May anyone tell me if I interpret it correctly?
There is filed in table 17 "Minimum Clock Cycle Time (DLL off mode)" equal 8 ns it gives 125MHz frequency so I'm able to take longer Clocl Cycle Time - 10ns and have 100MHz clock what gives 400MHz data rate in DDR3, doesn't it?

I don't know for sure, but I have not seen a digital part that wouldn't
work with a slower clock since I used the 8008 CPU chip. Even those had
a minimum clock speed that was some 100 times slower than the max.

If the part had a minimum frequency (maximum period) they would list that.

Dynamic RAMs do have a max timing value for the refresh cycle. So even
if you run the part slower, you have to maintain the refresh interval.

--

Rick

 

[Les Cargill]

glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:
On 9/23/2014 11:36 AM, Piotr B??achnio wrote:
I have found something... May anyone tell me if I interpret it correctly?
There is filed in table 17 "Minimum Clock Cycle Time
(DLL off mode)" equal 8 ns it gives 125MHz frequency so I'm
able to take longer Clocl Cycle Time - 10ns and have 100MHz clock
what gives 400MHz data rate in DDR3, doesn't it?

I don't know for sure, but I have not seen a digital part that wouldn't
work with a slower clock since I used the 8008 CPU chip. Even those had
a minimum clock speed that was some 100 times slower than the max.

I haven't actually done DDR, but it is synchronous, and I believe
that you do need to get the timing pretty close.

Yes.

Minimum clock speeds lasted longer than the 8008. At least to
the 8080 (one advantage of the Z80 was that it didn't do that),

Very much so.

and the 8086/8088. I believe the minimum for the original 8086
was about 2MHz or so.

I expect they'd actually go lower than that. Never tried, it,
tho.

Newer processors might not have dynamic logic, but they have
internal PLLs on the clock that won't lock much lower than the
specified frequency.

DDRs might have a PLL, too.

Generally more than one.

If the part had a minimum frequency (maximum period) they
would list that.

Dynamic RAMs do have a max timing value for the refresh cycle.
So even if you run the part slower, you have to maintain the
refresh interval.

That, too.

-- glen

--
Les Cargill

 

[Sean Durkin]

glen herrmannsfeldt wrote:

DDRs might have a PLL, too.
They do. They use it to maintain the phase relationship between input clock, output data strobes and data outputs.

For DDR2, the internal DLL is usually specified to a minimum frequency of 125Mhz. So, it might work below that, but it's not guaranteed to, meaning that could just stop working when a new die revision comes out or might not work at all when you use another manufacturer's drop-in replacement part; so it's not a good idea to rely on that.

DDR2 SDRAM memory (I assume it's similar for DDR3) has a config option enabling you to turn that DLL off. Then you won't have any problems with the DLL not working properly at lower frequencies, but you have no known, fixed phase relationship between input clock, data strobe and data, so that makes the interface into your FPGA more complicated (you'd have to constantly re-calibrate somehow). Plus, some manufacturers say turning off the DLL is not a normal use case, so there's no guarantee it will work at all, and if it doesn't, you won't get any help from them.

A few years back I did a design where memory bandwidth was not critical, so I thought I'd lower the memory interface clock rate to make meeting timing easier, save on power dissipation and such. I did some tests back then, and running the DRAM chips at < 125Mhz worked for some Micron parts, but not for some from Samsung. Later, it stopped working for some Micron parts as well after a new die revision came out. So, if the spec for the DLL in the DRAM chip states 125Mhz as a minimum frequency, don't expect enything else to work.

As it turns out, lowering the frequency doesn't help a lot with regards to power dissipation, either. You still have the same data to write, meaning the number and rate of IOs toggling stays the same (you just have longer idle phases when you use a faster clock); refreshes and such are identical, so in average the power dissipation doesn't change significatnly when you lower the frequency. Power dissipation is depending mostly on the number of read/write accesses and the data patterns that occur. If you're not doing a lot of reads/writes, the clock frequency alone doesn't make much of a difference.

Eventually, I ended up running the chips at 200Mhz, since back then the Xilinx DDR2 SDRAM controller wouldn't work with anything less (their calibration didn't work; they were doing phase shifts, and for 125Mhz one clock period was more than they could shift, so calibration aways failed).

Since modern FPGAs shouldn't have any problems with running DDR SDRAM at 125MHz (timing-wise), I'd recommend not going below that.

HTH,
Sean

 

[mnentwig]

Hi,

what I'd do is pick an eval board with a working reference design an
double-check that all required licenses are available (design tools, memor
controller). Depending on the situation, this can be a non-issue or a tota
showstopper (i.e. not able to modify after 365 days without a new budget).

I've got an example project for Numato Saturn and LPDRAM here:
http://www.fpgarelated.com/comp.arch.fpga/thread/119590/zpu-based-soc-for-numato-saturn-board-with-dram.php

This is not exactly what you asked for, but I'd use this myself if / whe
I'll run into a similar task.
The data rate quoted in the post comes from the very slow CPU, not th
RAM.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[Piotr Błachnio]

Thanks all for response.
PB