Dual port RAM shared between Nios and async interface

Hi,

if you can use the DSP AMI control signals directly as avalon master signals (even it is an asynchronous interface the signal are related to the a clock) you can use a simple tcl script to export the avalon master signals to the top level. The tcl script creates a component with a master interface where you can connect one slave interface of the dpram. Additionally the master signal are exported. You do not need a HDL file for exporting the signals. You need a small logic for connecting avalon read- and writedata to the dsp databus . If your DSP signals do not match you must create your own avalon master component where you have to convert the DSP signals to avalon master signals. An others solution is to build your own dpram component with one avalon slave interface and one export interface. AFAIK simply exporting one port of the sopc builder dpram is not possible.

HJS, thank you for your reply.

--- Quote Start ---

if you can use the DSP AMI control signals directly as avalon master signals (even it is an asynchronous interface the signal are related to the a clock) you can use a simple tcl script to export the avalon master signals to the top level.

--- Quote End ---

I think this is the solution. But I'm not very expert with tcl scripts. Can you suggest me a reference or give me an example.

--- Quote Start ---

An others solution is to build your own dpram component with one avalon slave interface and one export interface. AFAIK simply exporting one port of the sopc builder dpram is not possible.

--- Quote End ---

Infact I tried this before asking here.

At the moment I'm doing this: I created a lpm dual port ram block with Quartus megawizard; then I defined a new sopc component based on this dp ram, one port connected to Avalon signals and the other exported.

No problem about the exported signals, since the interface is exactly the same as the current project, with external lpm dp ram block.

But I'm concerned about the port connected to Avalon bus: I don't know if the direct connection between Avalon and lpm signals is correct.

I attach the resulting tcl file generated by sopc builder component editor.

Hi,

I attached a tcl script. BTW you can do this easily with the Component Editor (I did this tcl script with the component editor). Just add one master interface. Then on the signal tab just add the signals you want to export and assign them to the avalon master interface signals.

I do not see any problems in your approach with the direct connection between the avalon slave interface and the dual port ram.

Ok. I got it. It was easier than I expected.

Before your hints I missed it because I thought I had to explicitly expose signals I wanted to export, which I couldn't do with onchip ram sopc component. Adding the "fake" component with master interface does the trick.

I'll test both solutions and I'm confident at least one of them will do the job.

Bonus question:

Now my external master is supposed to access only one dpram port, while Nios master accesses the other side.

I wonder if I can use the same component to allow the dsp or any other host processor to access the main Avalon bus

(I don't need this now; just an idea for future projects)

Thank you again HJS

I think there are two points to consider if you do accesses to the main avalon bus from your host processor.

1. You have to synchronize the host processor accesses to your avalon clock domain.

2. Your host processor should have some kind of ready/wait/TA signal.

--- Quote Start ---

I think there are two points to consider if you do accesses to the main avalon bus from your host processor.

1. You have to synchronize the host processor accesses to your avalon clock domain.

2. Your host processor should have some kind of ready/wait/TA signal.

--- Quote End ---

Yes, this was implied in the question.

I'm aware of these requirements.

Thank you

Hi HJS,

I implemented your solution and it works perfectly! Thank you again.

Could you answer one last question? Just because I read Avalon specification but I'm not sure if I understood everything.

Following your hints, I now have a sopc system exporting address,be,cs,rd,wr,writedata input signals and readdata,waitrequest output signals. Connecting to these signals my external processor can now rd/wr data on the onchip dpram.

Suppose now the bus I connect to needs arbitration, for example because I connected to a multi master bus, or the main Avalon bus, as I asked in the question above.

Point 1 is ok: host processor is sync to Avalon clock domain

Regarding point 2, is the waitrequest signal enough to manage master accesses?

I mean, should host processor simply drive cs, rd or wr, be, addr signals and hold until waitrequest signal is asserted or a more complex handshake logic may be required?

I want I minimal implementation, then no arbiterlock, pipeline or burst functions

Regards

Cris

Hi Cris,

the avalon wait signal should be enough, but it can be a bit more complicated than just using this signal as wait signal for your host. Maybe you have to assert the wait signal for the host processor before you get the wait from the avalon and maybe you have to assert the wait for the host processor longer then the avalon wait is asserted (especially for reads from the host). This depends on the timing of your host processor.

Thank you for replying again

--- Quote Start ---

Maybe you have to assert the wait signal for the host processor before you get the wait from the avalon

--- Quote End ---

I think this is not a problem. My host processor can add a fixed number of wait cycles before it starts polling waitrequest signal.

--- Quote Start ---

and maybe you have to assert the wait for the host processor longer then the avalon wait is asserted (especially for reads from the host). This depends on the timing of your host processor.

--- Quote End ---

This would not be a problem, too. I can add minimal glue logic to generate the reuiqred delay

Regards