--- Quote Start ---
For SDRAM, that is a minimum guaranteed operating frequency, i.e., its really the maximum frequency at which they guarantee it meets timing spec (yes, its confusing!).
--- Quote End ---
If 133.33Mhz is the maximum frequency at which they guarantee it meets timing spec then what are the other operating frequencies of 143MHz, 166MHz, and 200MHz for? I interpreted to mean that the SDRAM chip can operate at either 133MHz, 143MHz, 166MHz, or 200MHz. I don't doubt that you're right, I just want to understand why because the information is conflicting. Here is the spec sheet:
http://www.issi.com/ww/pdf/42-45s16400j.pdf I have noticed that in every QSYS example that uses SDRAM, both from Altera, and from 3rd parties, the clock used for the SDRAM controller and the SDRAM_CLK output is only 50Mhz. There is also always a -3ns phase shift applied but it isn't clear whether this phase-shifted clock signal should go to (A) the SDRAM controller
and the SDRAM_CLK output, ( B ) just the SDRAM controller while a regular 50MHz clock goes to the SDRAM_CLK output, or (C) just the SDRAM_CLK output while a regular 50MHz clock goes to the SDRAM controller. Is it A, B or C in your opinion?
--- Quote Start ---
You can create a Qsys system with two Avalon-MM master interfaces connected to the SDRAM controller, and the Qsys fabric that connects the two masters to the SDRAM slave will include arbitration logic.
--- Quote End ---
When you say create two Avalon-MM master interfaces, are you implying that (A) the camera entity and vga entity be modified to conform to Avalon-MM master standards like you were saying earlier, or ( B ) to use some sort of generic Avalon-MM master interface component and export the signals for use in the original top_level file? If it is A, it will take a while to find some sort of documentation or example. If it is B, what is the specific IP component name?
--- Quote Start ---
You can set the arbitration shares to determine whether one master gets higher priority over another, you can add pipelining-bridges and other bells-and-whistles if you want data to be pre-fetched or buffered.
--- Quote End ---
I'm hoping the details on this, especially priority settings, become more obvious when I get to that step because I doubt I'll just accidentally see that info somewhere.
--- Quote Start ---
All of this requires you read and understand the Avalon Specification, the Verification IP Guide (for BFMs), and the users guides associated with the IP you add to your system.
--- Quote End ---
I've looked into that before but it wasn't much help.
For example, the Altera ALTPLL has dynamic phase adjust options. I enabled that and all of the new ports such as phasecounterselect[], phasestep, and phaseupdown made sense except for scanclk. So I looked at the ip user guide (
https://www.altera.com/en_us/pdfs/literature/ug/ug_altpll.pdf) for that and it just says that it's the input clock for the serial scan chain. That doesn't tell me whether I should set it to '1', '0', or feed a clock into it. I mapped phasecounterselect[] to switches, phasestep and phaseupdown to buttons, and hooked up an oscilloscope to try to see the phase shift in real-time but I couldn't gt the phase to change no matter what I did with scanclk port.
I also wanted to know why the ALTPLL has seemingly unnecessary avalon slave ports such as altpll_0_pll_slave_read, altpll_0_pll_slave_write, altpll_0_pll_slave_address, altpll_0_pll_slave_readdata, and altpll_0_pll_slave_writedata. My best guess as to what to do with these is just to set them all to '0' and open. The Altera ALTPLL user guide didn't really answer that question either..
Experiences like that are why I prefer person-to-person help, tutorials, and examples over raw documentation.
Honored Contributor
