Forum Discussion
Trouble with altsyncram on cyclone III
Hello,
I'm working on a simple video buffer, using the altsyncram dual port megafunction. Reading the memory works fine, I can display video using a memory initialization file. Writing to memory seems to have no effect at all. In simulation, all of the signals are in the correct places (WE is high, address and data are set and unchanged). I even tried holding the WE signal high an extra cycle. Is there something I'm missing? Is it not okay to have both ports run off the same clock? Thanks in advance13 Replies
- Altera_Forum
Honored Contributor
Are there clock enable or byte enable inputs that you're not asserting during writes?
- Altera_Forum
Honored Contributor
--- Quote Start --- Are there clock enable or byte enable inputs that you're not asserting during writes? --- Quote End --- I don't have any extra ports enabled in the megafunction, so they should default to something useful. - Altera_Forum
Honored Contributor
If it doesn't work in simulation then you're clearly doing something wrong. If you drill down into the RAM in simulation what do you see during writes? Does everything look right at that level? There are only a few signals involved here so it's got to be a simple problem.
Any synthesis warnings that might explain it? - Altera_Forum
Honored Contributor
--- Quote Start --- If it doesn't work in simulation then you're clearly doing something wrong. If you drill down into the RAM in simulation what do you see during writes? Does everything look right at that level? There are only a few signals involved here so it's got to be a simple problem. Any synthesis warnings that might explain it? --- Quote End --- I've never been able to get the ram to show data in simulation, its outputs are always Z. The input signals appear correct in simulation though, and on hardware the read functions correctly. I can't launch modelsim from quartus since it says the path is wrong even though it's correct, so it's probably not simulating the ram correctly anyway. - Altera_Forum
Honored Contributor
This should be a no-brainer. At some point you should seriously consider figuring out what the simulation problems are. That's the easiest way to resolve issues like this.
Can you attach the .qip file for the RAM and the source file where you instantiate it? - Altera_Forum
Honored Contributor
--- Quote Start --- This should be a no-brainer. At some point you should seriously consider figuring out what the simulation problems are. That's the easiest way to resolve issues like this. Can you attach the .qip file for the RAM and the source file where you instantiate it? --- Quote End --- You're right, I should have done that from the start. I took the time to get it working correctly, and have verified that in simulation the data is written to memory and read out later on in RTL simulation. Timing simulation is not available on the device I'm using (Cyclone III). I've attached the .qip file (with an added .txt extension so I could upload) and the source file that instantiates it. - Altera_Forum
Honored Contributor
I should have asked for the VRam.v file instead of the .qip file but I can see from the port list how the RAM was configured.
Your code looks fine except that the data_a input port on the RAM is not connected. Since you're using port A as read-only you should tie data_a off as 16'h0. The fact that writes now work in simulation says that your logic is ok, so this must be a synthesis issue. Is there anything in the synthesis reports about this RAM? At a minimum you should get a warning about the unconnected data_a input. Maybe the synthesis tool is doing something stupid because of that dangling input? I would tie off data_a and try again. If it still doesn't work I would try SignalTap. Instrument the VRam inputs and outputs and see what's happening in hardware. The final step would be to open a service request with Altera. One side comment: Doing the read address math for address_a at instantiation is not very good form. It would be better to declare a signal (wire or reg) for that read address and assign it separately where you can add some comments about what you're doing. Good luck. Bob - Altera_Forum
Honored Contributor
--- Quote Start --- I should have asked for the ARam.v file instead of the .qip file but I can see from the port list how the RAM was configured. Your code looks fine except that the data_a input port on the RAM is not connected. Since you're using port A as read-only you should tie data_a off as 16'h0. The fact that writes now work in simulation says that your logic is ok, so this must be a synthesis issue. Is there anything in the synthesis reports about this RAM? At a minimum you should get a warning about the unconnected data_a input. Maybe the synthesis tool is doing something stupid because of that dangling input? I would tie off data_a and try again. If it still doesn't work I would try SignalTap. Instrument the VRam inputs and outputs and see what's happening in hardware. The final step would be to open a service request with Altera. One side comment: Doing the read address math for address_a at instantiation is not very good form. It would be better to declare a signal (wire or reg) for that read address and assign it separately where you can add some comments about what you're doing. Good luck. Bob --- Quote End --- Connecting the output port to zeros did get rid of a warning, unfortunately it didn't fix the problem. As far as I can tell, any warning I'm getting is unrelated to this part of the code. I'll work on getting signal tap up and running after work, or maybe the in system memory editor. Also, thanks for the coding tip, I wrote that file about four years ago when I was first learning, but I did correct the line anyway =D - Altera_Forum
Honored Contributor
--- Quote Start --- Connecting the output port to zeros did get rid of a warning, unfortunately it didn't fix the problem. As far as I can tell, any warning I'm getting is unrelated to this part of the code. I'll work on getting signal tap up and running after work, or maybe the in system memory editor. Also, thanks for the coding tip, I wrote that file about four years ago when I was first learning, but I did correct the line anyway =D --- Quote End --- It took me a lot of effort to get signal tap to actually pick something up, but when I finally did, I noticed all of the signals looked good. I then turned around and looked at the screen, and behold, the characters written to memory was displayed. Only problem is, I can't get it to work without signal tap, so I'm at a loss as to what's going on. Any ideas? - Altera_Forum
Honored Contributor
Another update, I don't think this warning was there before but now I have a connectivity check error where the critical write enable signal is said to be connected to dangling logic. The signal obviously goes to the VRAM, but Quartus apparently doesn't know this, and is removing it. Why would this happen?
Edit: Never mind, that signal actually isn't the one going to the VRAM, so it's fine if it gets removed.