NIOS II memory devices on tristate bridges

[David Brown]

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

 

[Jesse Kempa]

"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cfptk6$n4e$1@news.netpower.no>...

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,

Hi David,

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.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

 

[David Brown]

"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0408181657.4384520b@posting.google.com...

"David Brown" <david@no.westcontrol.spam.com> wrote in message
news:<cfptk6$n4e$1@news.netpower.no>...
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,

Hi David,

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.

David

Jesse Kempa
Altera Corp.
jkempa at altera dot com

 

[Jesse Kempa]

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.

David

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.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

 

[David Brown]

"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0408190852.4c900dcd@posting.google.com...

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.

David


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.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

 

[Jesse Kempa]

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.

Aha,

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.

Jesse

 

[David Brown]

"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0408200856.67f3f2fb@posting.google.com...

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.


Aha,

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.

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.

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.

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.

> Jesse