How to set up shared on-chip memory

[Altera_Forum]

Hi, using Cyclone V with HPS. 

 I have a custom Verilog module which needs to have its own registers, as well as read/write access to 1kByte of on-chip memory. The Linux side also needs to have access to both the module's registers and the on-chip memory.  I'm able to get the module's registers memory mapped in Linux and can read/write them, using the Avalon interface. I assume I can get on-chip memory to be memory-mapped in Linux too, at a different base address. However I'm not sure where to begin with getting my module to read/write on-chip memory.  I'd like to just use the Verilog array syntax, like read_data <= my_memory[addr] or my_memory[addr] <= write_data, where my_memory is the shared on-chip 1kB memory. I'd prefer not to have to write Avalon master logic, eg controlling chip selects, read/write signals, etc., from my module to access the shared memory, just the Verilog array syntax. Is this possible?  Can someone please provide an overview or point to an example of how to have a custom module access on-chip memory which is shared with the Linux side?  thanks

[Altera_Forum]

Hi sonicsmooth, 

 The Cyclone V HPS Golden Hardware Reference Design (GHRD) has on-chip memory implemented in the FPGA fabric and accessible to both the HPS and a JTAG master. The HPS can access the on-chip memory through the HPS to FPGA bridge memory range while you can also access the on-chip memory using System Console when the board is connected through USB Blaster. Perhaps you can use this as a starting point to implement your design?  GHRD overview: https://rocketboards.org/foswiki/documentation/gsrdghrd   Using System Console to access GHRD peripherals: https://rocketboards.org/foswiki/documentation/gsrd160systemconsole  Regards, ccthum (This message was posted on behalf of Intel Corporation)

[Altera_Forum]

Thanks for the response. 

 From within Quartus, I was able to find the verilog template for instantiating "real" dual-port on-chip memory (as opposed to registers). I had gotten the thing to simulate properly using registers, but there were a gazillion timing errors. Once I switched to using on-chip ram, the timing errors went away and things seemed to work better. The cost for this was some complexity in accessing the memory with the read/write strobes, etc., dealing with clocks, etc., so I didn't get the array[i] syntax I wanted. Oh well. I was able to access this ram from within system console.