As I need to use NiosII processor in my project and to run a program on it, so QSys is to be used and SDRAM is used for program code and data. And image captured from the D5M should be displayed through a VGA monitor, so a frame buffer is required to store the image data, and the best choice is to use SDRAM.
It’s a 16bit SRAM on DE2 115 and it requires 24bit to store a 8-8-8 bit RGB pixel data, so solutions:
1. change to use 5-6-5 16bit RGB data, and reduce the time to access SRAM
2. change the custom logic in SRAM controller (in fact, I need to write the SRAM controller all by myself in VHDL), to allow 32bit access (in two cycles).
There’s a problem is that both D5M controller and VGA controller will try to access SRAM, and probably at the same time, so logic needs to be added to resolve conflict. again solutions:
1. implement only one read/write slave port in SRAM controller, and share it between the D5M controller and VGA controller’s master interface. And let the arbitration provided by QSys to resolve the conflict. This is not a good idea as QSys use fairness-based, round-robin to resolve the conflict. However in this case, read request from VGA controller has a limited response time, while write request from D5M controller can wait for a couple of clock cycles.
2. implement two (one read and one write) slave interface in SRAM conflict, and use FIFO to make write request wait for read request. FIFO can use the Megafunction implementation.
Tomorrow I’ll try to implement the second solution.
On Friday, I’ll have an oral test for "Specification and Simulation of Digital Systems", hopefully it will go well this time.
Updates on this part of the project will be post in this post later on.
Today (or Yesterday) I rewrote the SRAM controller using separated Avalon MM read slave interface and write slave interface for D5M controller and VGA controller, However, now the thing is that the content written into the SRAM cell is not exactly what I intend to write, and it seems like a random error stuff.
I’ve already tried to use signal tap II to debug, but it’s not so suitable for this as some clock’s are involved and it requires to recompile the project every time (quiet slow). I’ll try another tool (Signal Probe) later.
Today I’ve got an oral test. Pray the professor not to be harsh. 😉
Oral test went very well. Though it’s just two simple questions, I didn’t know the answer of the very first question asked by the professor, I took a shot and guessed the right answer, 🙂
With another (this) course cleaned up, I’ve more time to do the DE2.115 project. But not today.
Damn It. The timing for Avalon Memory Mapped Read Salve of the SRAM controller was wrong, the content wrote to SRAM is right now, but the result read by VGA controller is not correct as I was using process to implement the logic and synchronized to the CLK signal. Need to re-wrote the SRAM controller again. 😦
Finally the system is finished. SRAM is used in the system as a frame buffer, use one single read/write cycle to read/write a 16bit RGB data from/to SRAM. The problem is that SRAM will not work @100MHz, and either @80MHz. 50MHz is working, and is enough for our project. And SRAM is directly accessed through the custom IP instead of the Avalon Memory Mapped interface, as in this way the read requests from the VGA controller and write requests from D5M camera can be correctly arranged by time.