<promach3>
lambda: why 8 REF commands lead to 9 x tREFI ?
<vup>
promach3: Simple example: If you don't postpone any you have 1 × tREFI. Now you postpone one, so you have a additional 1 × tREFI, which makes a total of 2 × tREFI
<vup>
Continue to 8 postponed -> 9 × tREFI
<promach3>
lambda: however, in that picture, 8 REF commands are **SQUEEZED** in between just 1 single tREFI
<lambda>
promach3: yes, those are the refreshes that have been postponed
<promach3>
lambda: but why **SQUEEZE** ?
<lambda>
because that's the fastest way to catch up
<promach3>
<lambda "because that's the fastest way t"> catch up on which exact DDR timing parameter ?
<promach3>
> <@freenode_lambda:matrix.org> because that's the fastest way to catch up
<promach3>
* catch up on which exact DDR timing parameter specification ?
<lambda>
the amount of refreshes you need in a given time frame
<lambda>
sure you can also just sprinkle in an extra refresh every once in a while, but it'll be a lot longer until you can postpone another complete 8 refreshes
<promach3>
which is equivalent to tREFI
<promach3>
lambda: if those 8 REF commands are **SQUEEZED** , why are they still called/referred as **POSTPONED** ?
<hell__>
> to delay an event or arrange for it to take place at a later time
<promach3>
lambda: how SQUEEZED == POSTPONED in terms of DDR timing-wise ?
<hell__>
these 8 REF commands got delayed. in a regular scenario, refreshes happen every tREFI time, but in this case they happened later
<hell__>
one could continue to operate with 8 postponed refresh cycles, but it's not a good idea (you cannot delay refreshes at all)
<promach3>
hell__: you mean DDR memory controller at FPGA side will need to **remember** there are still eight outstanding REF commands at every execution clock cycles ?
<hell__>
yes, the memory controller needs to have a scheduler
<lambda>
a simple ddr controller can also just not delay any refreshes
<hell__>
it still needs to have a scheduler
<hell__>
one can't perform a read/write and a refresh command at the same time
<hell__>
the scheduler decides which one should take place first
<lambda>
alright, I guess "do a refresh whenever you have to, otherwise do transfers" would count as a simple scheduler then
<hell__>
a simple scheduler could favor refresh commands over anything else, but performance won't be optimal
<hell__>
once that works, one can try to postpone some refresh cycles. choose a "watermark" value: if the number of outstanding refresh cycles is below the watermark, favor regular operations over refresh cycles; otherwise, favor refresh cycles over anything else
<hell__>
when the scheduler queues are empty, execute any postponed refreshes, then idle
<hell__>
promach3: does that single file contain all of the memory controller logic?
<promach3>
<hell__ "promach: does that single file c"> hell__: yes
<hell__>
I'd highly recommend splitting it up in "blocks", then
<hell__>
I can't read HDL, but I see you have a state variable for each command, and also for the initialisation sequence
<promach3>
<hell__ "I can't read HDL, but I see you "> yes
<hell__>
I wouldn't put the initialisation sequence in the state machine
<hell__>
rather, have one block that handles sending commands to the DRAM, and another block that decides which commands to send
<promach3>
lambda hell__ one more question, do all 8 refresh commands **FINISH** execution inside that **squeezed(( tREFI inside Figure 4 ?
<promach3>
* lambda hell__ one more question, do all 8 refresh commands **FINISH** execution inside that **squeezed** tREFI inside Figure 4 ?
<promach3>
* lambda hell__ one more question, do all 8 refresh commands **FINISH execution** inside that **squeezed** tREFI inside Figure 4 ?
<hell__>
yes, I read you
<hell__>
yes, in the picture they happen inside one tREFI cycle
<promach3>
<hell__ "yes, I read you"> what did you exactly mean by this particular above reply ?
<lambda>
(hell__: that's just the matrix bridge's way of showing edits)
<hell__>
ah, to me it showed as three different messages (I use actual IRC)
<promach3>
hell__: try to use Element RIOT matrix client
<lambda>
same, but the sender has no idea they're being spammy :/
<hell__>
promach3: however, if tREFI < 8 * tRFC then it's impossible to do all 8 refresh commands inside one tREFI cycle
<lambda>
promach3: also, if I understand correctly, even the "squeezed" refreshes are all tRFC apart, which is the time it takes for a refresh to finish
<hell__>
the problem with these diagrams is that they show commands as points in time
<hell__>
a more accurate representation would be to draw the commands as rectangles, where the width is the time that a command takes
<hell__>
meh, now I want to get a FPGA and try to make my own DDR3 memory controller :S
<promach3>
<hell__ "promach: however, if tREFI < 8 *"> let me double check the datasheet
scientes has quit [Changing host]
scientes has joined ##openfpga
<promach3>
hell__lambda I just calculated: tREFI = 65*tRFC , so it is entirely possible to do all 8 refresh commands inside one tREFI cycle since each refresh command will take tRFC cycle to finish
<promach3>
please correct me if the calculation is wrong
<hell__>
tREFI is usually quite large, so it's reasonable
<promach3>
hell__: must all 8 refresh commands finish in a single tREFI cycle ?
<hell__>
not necessarily
<promach3>
<hell__ "not necessarily"> but it will violate the highlighted timing as shown below
<promach3>
there is no mention how long can refresh commands be postponed ? as in when is the first postponed refresh command to be executed after the first non-postponed refresh command + 9*tREFI ?
<promach3>
lambda: any idea ?
<hell__>
as long as there's less than 9 outstanding refresh commands, refreshes can be postponed indefinitely
<promach3>
<hell__ "as long as there's less than 9 o"> no, there is still a 7.8us timing spec to be met