--- Quote Start ---
Qsys has an option to set the simulation language to VHDL. Did you try it?
--- Quote End ---
Yes, it only generates the top level in VHDL. The lower level components have always been in verilog in my experience.
--- Quote Start ---
That does not sound like its "working" at all.
--- Quote End ---
It is somewhat working. Not working at all means you see nothing but static and there is no indication that the SDRAM is responding. It is definitely responding, being written to, and being read from, just not correctly. After A while I see an "image" of what is in front of the camera, just very noisy and with messed up colors. That is a lot better than if it were not responding at all.
--- Quote Start ---
The phase-shift is board-specific. I think I wrote some notes in the DE0-nano SDRAM tutorial. I performed a TimeQuest timing and adjusted the clock phase until it provided suitable timing margin.
--- Quote End ---
A TimeQuest analysis is automatically run with each compile. This project has always had TimeQuest failures from the beginning though. I have no experience in fixing those types of errors. Is there a video or tutorial on it, or a particular report page that I could paste in which would show you just how messed up timing currently is?
--- Quote Start ---
100MHz should be fine. Start with that, and then once it works, you should have a better understanding of what it takes to get it to operate at a different frequency.
--- Quote End ---
If the SDRAM chip operates at a minimum of 133MHz as the spec sheet seems to suggest, then how would 100MHz be fine? In QSYS, if you only have the clock component that a new project starts out with and a SDRAM controller, does QSYS automatically create a PLL if the input clock frequency isn't what the SDRAM controller needs? If not, then it seems to make sense that an ALTPLL needs to be created to generate one of the frequencies specified on the ISSI spec sheet, which would then to be fed into the QSYS entity instantiated in top_level. Am I missing something here?
UPDATE:
I was hoping you looked at the code I pasted in earlier. One glaring mistake was sdram_controller_s1_byteenable_n => "11" instead of sdram_controller_s1_byteenable_n => "00" :-p
It now acts like a camera instead of a slowly-materializing still image. It's still very noisy though...
It's working far better but still has good bit of noise. What I think is happening is there are instances where the ram needs to be read at the same time that pixel data needs to be written. Regardless of the fact that the ram clock is 4x faster than the pixel and vga clocks, there are still going to be instances where they request ram usage at the same time. What is the standard way of handling this type of conflict?
Honored Contributor
