Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Altera DDR3 "avl_burstbegin"

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello,
In the following document:
https://www.altera.com/content/dam/...US/pdfs/literature/hb/external-memory/emi.pdf

Page #797 - description of "avl_burstbegin":
The Avalon burst begin strobe, which indicates the beginning of an
Avalon burst. Unlike all other Avalon-MM signals, the burst begin
signal is not dependant on avl_ready (1).
For write transactions, assert this signal at the beginning of each
burst transfer and keep this signal high for one cycle per burst
transfer, even if the slave deasserts avl_ready. The IP core samples
this signal at the rising edge of phy_clk when avl_write_req is
asserted (2). After the slave deasserts the avl_ready signal, the master
keeps all the write request signals asserted until avl_ready signal
becomes high again.
Click to expand...


The combination of #1 and #2 confuses me.
If we assert "avl_burstbegin" independently of "avl_ready" (1), yet the core samples this signal only when "avl_write_req" is asserted (2) - then there might be a case when the core fails to capture "avl_burstbegin".
This is because Avalon specifications dictate that "avl_write_req" must be low when "avl_ready" is low...

In other words if we assert "avl_burstbegin" (for a single cycle) when "avl_ready" is low, yet we don't assert "avl_write_req".
According to the spec in that case "avl_burstbegin" won't be captured !

Am I wrong?
 

The way I read it is that you are prevented from *first* asserting avl_write until avl_ready is true (i.e. avl_ready is true, avl_write and avl_burstbegin are false on the clock cycle right before you will be starting the burst). Then you assert avl_write and avl_burstbegin. On the next clock cycle you de-assert avl_burstbegin even if avl_ready is false. It is kind of funky.

Kevin Jennings
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
The way I read it is that you are prevented from *first* asserting avl_write until avl_ready is true
Click to expand...
That's what I also thought. Hope we're both wrong.
Because if that's the case - the controlling logic will have to de-assert avl_write asynchronously...

Consider the following scenario (assume synchronous logic) :
At T = 0 we sample avl_ready and see it high so we initiate a transaction by driving avl_write high.
At T = 0+ (after hold time) avl_ready drops low (maybe a refresh is taking place or the controller is just not in the mood).
At T = 1 we see that avl_ready is high. But it's too late - we already caused a "avl_write high while avl_ready low violation".

Conclusion - avl_write must be controlled by a zero cycle latency circuit.
 

Re: Altera DDR3 "avl_burstbegin"

I don't think what you've described is correct. Quoting from the documentation you referenced in your first post..."After the slave deasserts the avl_ready signal, the master keeps all the write request signals asserted until avl_ready signal becomes high again." From that same document, the definition of avl_ready is "The avl_ready signal indicates that the controller is ready to accept request signals. If controller asserts the avl_ready signal in the clock cycle that it asserts a read or write request (KJ note: Should be "that it receives a read or write request), the controller accepts that request. The controller deasserts the avl_ready signal to indicate that it cannot accept any more requests." What that means is that avl_write must be held constant whenever avl_ready is not true.

The short answer is that if avl_ready is not true then you are not allowed to change avl_write on the next clock cycle. Once avl_write is set active, you cannot deassert it until there is a clock cycle that ends with avl_write and avl_ready both true. avl_write will not deassert on the same clock cycle that avl_ready deasserts.

I think the following untested code is roughly what you're trying to accomplish.

Code: 
process(clock)
   variable WantToWriteSomething:  std_ulogic;
   variable BurstStarted:  std_ulogic;
begin
   if rising_edge(clock)
      WantToWriteSomething := -- Whatever logic that you have that decides you want to write something
      if (avl_ready= '1') then
         avl_write <= WantToWriteSomething; -- avl_write will only change state when avl_ready is also true
         BurstStarted <= WantToWriteSomething;  -- Set a flag to indicate that we've started a burst
      end if;
      avl_burstbegin <= avl_ready and WantToWriteSomething and not(BurstStarted);
   end if;
end process;
Kevin Jennings

- - - Updated - - -

shaiko said:
But it's too late - we already caused a "avl_write high while avl_ready low violation".
Conclusion - avl_write must be controlled by a zero cycle latency circuit.
Click to expand...
No, because "The IP core samples this signal at the rising edge of phy_clk when avl_write_req is asserted"

Kevin
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
If controller asserts the avl_ready signal in the clock cycle that it asserts a read or write request (KJ note: Should be "that it receives a read or write request), the controller accepts that request. The controller deasserts the avl_ready signal to indicate that it cannot accept any more requests."
Click to expand...
Your note makes sense. But there's something else I don't understand.
Does the sentence I painted in green comes in context to the sentence before it?
If it does, why would the controller deassert the avl_ready signal if it just accepted the request ?
Or perhaps this sentence doesn't come in context to the one before it - and it's just a note about the purpose of this signal...what do you think?
 

shaiko said:
Your note makes sense. But there's something else I don't understand.
Does the sentence I painted in green comes in context to the sentence before it?
If it does, why would the controller deassert the avl_ready signal if it just accepted the request ?
Or perhaps this sentence doesn't come in context to the one before it - and it's just a note about the purpose of this signal...what do you think?
Click to expand...

I believe it is just a note about the purpose of avl_ready. Note the use of 'any more requests...' would imply to me that it accepted the last request, but cannot accept any more. That's kind of pointless since the last accepted request would have to have been one from the previous (or earlier) clock cycle. Each clock cycle is independent so it is not really relevant to say 'more'.

Kevin Jennings
 
  • Like
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top