I'm working with a NIOS II cpu on an Altera Stratix chip. I'm finding it easy enough to make simple Avalon slave devices, using the "interface to user logic" wizard to connect my components to the bus. But I can't find any way to deal with memory devices that would logically connect to tristate buses. I have a couple of synchronous ram devices which should be simple enough to use (I can access them using a test module I made outside the NIOS). Is there any simple way of connecting new devices to a tristate bus, or any application notes that show how?
Thanks,
-- David
"I love deadlines. I love the whooshing noise they make as they go past." Douglas Adams
On this: The trick is in the IO signal type (Input,Output,Inout) in the interface to user logic. If you specify your data bus as bi-directional, your peripheral will sprout a tri-state bus, and require an Avalon Tri-State bridge to master it.
The next thing is "what about multiple devices on the tri-state bus" - the interface to user logic handles this as well. The trick is to specify which signals are "shared". Anything not "shared" will have a unique pin in the collection of pins on the tri-state bus (this is useful for sharing an IO for read/write/byte enables).
The Avalon Bus Spec reference manual should discuss this a bit as well.
I've figured it out now, and got my devices working perfectly. The process was not too hard - all I needed was to write a class.ptf file for each type of device, and get the signals and timing parameters specified correctly. All in all, I needed to write about 100 lines of text class.ptf file. However, to get that I had to read hundreds of pages of documentation in the Avalon Bus Spec and the SOPC references, as the information is pretty scattered. For the sake of others who face the same situation, could you suggest to the powers that be that they
a) update these manuals to refer to the Nios II (I know not much has changed in the bus, but it'd be nice to be told that in the manual),
b) put links to these manuals in the Nios II literature section as well as the Nios section,
c) write a 10-page application note covering connection of external memory to tristate buses, to save lots of reading and collection of information,
d) write a nice wizard, like the "interface to user logic" and "flash" wizards, making it easy to see the timing.
Having figured out all the required signals and timing settings, the system worked great - I added the memory components, re-generated the design, and it worked first time. But a bit more directed information would have made the process much easier.
Thanks I will pass this on to the relevant people on the engr & doc team for SOPC Builder. Work is already being done for a future release on enhancing this functionality for more complex systems, but I am surprised to hear that you had to write a PTF file for an off-chip memory interface (the wizard in its current state should handle such a thing) - you're right that better docs are in order for this.
The memory involved was pipelined synchronous static ram, so it needed things like latency settings. It's quite possible that I could have got something to work using the flash memory wizard (or is there a ram memory wizard that I missed?), but I don't think that would cover the latency. Incidently, are the Nios II masters latency-aware? And how about the DMA controller? I have a vague feeling the first answer is no, but I don't know about the second. It's just that if they are latency aware, they could read my ram chips at 3-1-1-1... timing rather than 3-3-3... I must say, though, that I like the way the master and slave are independant and don't need to know how the other side works - burst will work for masters that support it, and not for other masters.
My apologies, I forgot you mentioned this was SSRAM (for some reason I was thinking it was async). You're right about latency; this currently requires a PTF entry to speciy max pending read transfers.
About your question: The Nios (and Nios II) instruction master is latency aware; after getting the first 'n' reads through the pipe, you get a word per clock (assuming that the memory can handle it). The data master is not latency aware. DMA controller is on both of its masters.
However, this should not affect your slave peripheral design! (You shouldn't need wait states unless your SSRAM can't handle the desired clock speed). A master is "latency aware" if it has the "readdatavalid" pin (Avalon spec has more detail on this). Masters which aren't latency aware are just told to "wait" until the data comes back (and can therefore only issue one access at a time). This is the beauty of the whole system - masters designed with performance in mind can get it from slaves despite pipelining between the two; masters designed for low logic usage need not impose wait states on the otherwise high-speed memory.
This is not, as far as I can see, documented anywhere. Latency-awareness can make a big difference (it will tripple the continuous read speed from my ssram) in some applications - indeed, a particular use of the DMA is to get that sort of full burst speed.
That is definitely one of the nice things about the bus. I made my ssram peripheral latency-aware, and I am currently making a latency-aware master, knowing that both would seemlessly integrate with non-latency-aware masters and slaves.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.