Trouble with altsyncram on cyclone III

[Altera_Forum]

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 advance

[Altera_Forum]

Are there clock enable or byte enable inputs that you're not asserting during writes?

[Altera_Forum]

--- 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]

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]

--- 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]

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]

--- 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]

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]

--- 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]

--- 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]

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.

[Altera_Forum]

--- Quote Start ---  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?  --- Quote End ---    This stuff will drive you nuts sometimes. The only thing I can think here is that one or more signals are getting optimized out without SignalTap, but when they are instrumented in SignalTap they do not get optimized out. I assume that in SignalTap you selected nets "pre-synthesis"?  If anything is getting optimized out it should be mentioned in the reports, but it sounds like you're not seeing anything? If that's the case then it might be worth trying the netlist viewers (Tools -> Netlist Viewers) to make sure everything is hooked up properly. You can look at the rtl viewer or post-map or post-fit. Try compiling without SignalTap and then find your VRam in the post-map viewer and see if it's connected correctly.  If you simply can't figure this out then it's time for a service request. That can be a frustrating process, but if you're able to send them an archived project they should be able to figure it out for you.  Good luck. Please post back with whatever you find out (hopefully with the problem resolved).  Bob

[Altera_Forum]

I finally fixed it. Some people on freenode IRC helped me out, and as far as I can tell it was a problem with the way my reset logic was written. Maybe it was metastability, along with not having negedge nReset in my sensitivity list for synchronous processes, or a combination of things, I guess I'll never know for sure.

[Altera_Forum]

Interesting problem. Never seen that one before. Glad you got it fixed, and thanks for posting back! 

 Bob