1 reply to this topic

[Tony]

Hi,
I generated two co_memory interfaces, one is for read, and another one is for write, what I did is to use the data read from one interface do some change of the data, and write to another co_memory interface. When simulating, I met a problem. I set the config stream and saw the base address has been written into "base", however, I didn't see the "req" signal start.That is to say, the read cycle doesn't start. I don't know why, could anyone help me one this. May I know how the "req" signal works?
Thanks

Tony

[etrexel]

Hi,
I generated two co_memory interfaces, one is for read, and another one is for write, what I did is to use the data read from one interface do some change of the data, and write to another co_memory interface. When simulating, I met a problem. I set the config stream and saw the base address has been written into "base", however, I didn't see the "req" signal start.That is to say, the read cycle doesn't start. I don't know why, could anyone help me one this. May I know how the "req" signal works?
Thanks

Tony

Hi,
Are you writing only one base address to the config stream? You will need to write a base address for EXACTLY the number of co_memory interfaces you have created. Until all the base addresses are written, the processes are held in reset via a local signal in the top module in the '_top.vhd/v file. Watching it and/or the state of the state machine of the processes will tell you if/when the base addresses have been written correctly.
Also note that the co_memory is shared via a priority scheme according to the order co_memory's are created in you hardware configuration routine. Because of this, it is possible for one process to starve another process keeping it from accessing the co_memory.

Ed