EMIF Avalon-MM Burst never ending

[RLedu]

Hello,

I try to write data to "EMIF Intel Arria 10 FPGA" (for DDR4 SDRAM) component with avalon-mm burst. If this works for burstlenght of 1, it doesn't for 2 or more.

It means that if I try to write a burst of 2 or more, the slave will stay in locked position forever, and abritration will prevent other master to read EMIF (for instance I cant to read from HPS).

As you can see in the picture below, I want to write with a burstlength of 2 : 

We can properly see the "amm_write" twice, however there is a "amm_read" that occures right in the middle, I don't know why, and also, I don't know why I would have recurrent reads before I start writting, since my master only writes, I have no "read" output, maybe emif performs auto-check ?

Anyway, after these 2 writes, emif avalon interface hangs and I cannot send read from HPS anymore.

Also, there is no "chip_select" on the emif amm interface (see https://docplayer.net/88824953-External-memory-interfaces-intel-arria-10-fpga-ip-user-guide.html). However, if I don't assert chip_select during transaction from master to emif, it will not work ! Because of this, I'm not really sure how to exactly assert this chip_select signal since it is not visible anywhere on the EMIF, but it affects its behavior...

Moreover, I would like to add beginbursttransaction signal on my master , but in QSYS Component Editor -> Signals & Interfaces -> my "avalon_master" conduit end doesn't provide any signal of this kind. 

Any insight please ? It seems very unclear to perform transactions to emif using avalon-mm burst

Thanks

Roman

[sstrell]

So you're using a custom component instead of the hard memory controller along with the EMIF IP?

The Avalon agent on the EMIF IP only has the signals listed here: https://www.intel.com/content/www/us/en/docs/programmable/683106/21-1-19-2-0/ctrl-amm-for-ddr4.html so you're looking for beginbursttransfer, not beginbursttransaction under Avalon memory-mapped in the Component Editor.

As for seeing the read signal, it appears you are tapping the EMIF IP with Signal Tap, not your controller, so as noted in the link above, it does have a read signal.  As such, something else in your system must be accessing the EMIF IP and issuing read if it's not your controller.  You mention the HPS.  Is this EMIF a dedicated memory connected to the HPS or is it configured in the FPGA fabric and you are accessing the EMIF from the HPS over the H2F bridge?  I'm guessing the latter.

Finally, chip select is not an Avalon signal.  There's obviously chip select on the memory side of things (https://www.intel.com/content/www/us/en/docs/programmable/683106/21-1-19-2-0/mem-for-ddr4.html) so I'm not sure what "chip select" you are asserting from your controller that is required for this to work.

More details are needed here, especially a look at your system design and connections.

[RLedu]

Hi,

Thank you very much for your response.

So, I don't believe I am using another logic instead of hard memory controller. At least, the hmc provides an avalon-mm interface, and I use my logic to write to this interface, nothing more, so indeed I am using the HMC, isn't it ? My QSYS structure is the following and helps to get a clearer picture (there are other things, but I focus on this issue):

I have 2 avalon-mm masters accessing EMIF, for read/writing to an external DDR4 SDRAM based on FPGA side. One master is customized IP inside FPGA fabric and writes data to EMIF through amm interface, meaning through the hard memory controller of EMIF. As you guessed well, the other master is actually the HPS that accesses EMIF for reading, through H2F bridge and avalon-mm bridge adapter. 

The two masters are connected to the same slave EMIF amm base address 0x0, and as far as I know , avalon performs arbitration automatically.

So basically I have the following signals :

Pipeline bridge host (amm-master) :

-(out):m_address[32]
-(out):m_burscount[1]
-(out):m_bytenable[32]
-(out):m_read[1]
-(in):m_readdata[256]
-(in):m_readdatavalid[1]
-(in):m_waitrequest[1]
-(out):m_write[1]
-(out):m_writedata[256]

Master write logic (amm-master) :

-(out):m_address[32]
-(out):m_burscount[7]
-(out):m_bytenable[32]
-(out):m_chip_select_n[1]
-(in):m_waitrequest[1]
-(out):m_write[1]
-(out):m_writedata[256]

EMIF (amm-slave) :

-(in):s_address[32]
-(in):s_burscount[7]
-(in):s_bytenable[32]
-(in):s_write[1]
-(in):s_writedata[256]
-(out):s_waitrequest[1]
-(out):s_read[1]
-(out):s_readdata[256]
-(out):s_readdatavalid[1]

- I don't see any burstbegintransfer in the EMIF amm-slave interface, maybe this is automatically assigned by internal's EMIF logic when a burst begins ? Also, I don't see burstbegintransfer (not transaction) in the Component Editor for an "Avalon Memory Mapped Host" interface (don't pay attention to the "Name", just an example):

- For the read signal : I don't have any other IP connected to this slave. The amm bridge host never issues any "read" signal during operation before I ask, and never issues anything anyway (I checked in SignalTap).

- I suppose the chipselect_n signal might be confusing, I will try to remove it completely from interface (and not let it to 1 or 0) and see how it goes.

Also, about the clocks.  Pipeline bridge host has 50 MHz source clock, my custom master write IP has 50 MHz clock, but my EMIF can only be provided 1 clock source (pll_ref_clk), which is the DDR4_REF_CLK about ~266MHz. I'm not quite certain what is the EMIF avalon-mm source clock, and if it can cause any problem that my masters (50MHz) have different clock domain ? I don't know if tapping any amm signal in signaltap is also a problem ?

Here is again a picture of SignalTap during a write transaction from my master write of just 1 burst, which is called "Capture_Burst_ad9250", and the emif amm signals "a10s_hanpilot_emif_ddr4bh" , I hope is somehow readable :

Thank you very much

[AdzimZM_Intel · Accepted solution]

Hi,

I think the busrtbegintransfer signal no longer used in Arria 10 device.

The signal exist to support legacy memory controllers.

Most of the avalon interfaces got some details in the Avalon Interface Specifications: https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/memory-mapped-interface-signal-roles.html

About the clocks, the PLL_REF_CLK should be the clock source for EMIF IP.

The EMIF IP can provide the clock to user logic through the EMIF_USR_CLK.

You may feed your logic with this clock.

The chip select for EMIF interface is between FPGA and external memory.

https://www.intel.com/content/www/us/en/docs/programmable/683106/21-1-19-2-0/mem-for-ddr4.html

Regards,

Adzim

[RLedu]

Hi,

It works !

I removed the chipselect signal from my master and there is no parasitic "read" anymore.

It is very good to know that even though there is no chipselect input on a slave, it can affect its behavior. I'm curious to know how avalon automatically assigns a signal which is not supported by slave ! Anyway, that is a very good practice to be consistant between master/slaves.

Thank you very much,

Regards,

RLeduc