User peripherals within a Nios system

Is it possible to have a connection between two seperate user peripherals inside 
a Nios 2 system? Or do I have to route the signals outside the Nios 2 system and 
connect them at toplevel (like below)?

nios_system : entity work.nios_system
port map (
     clk                                => sys_clk,
     reset_n                            => locked,
     out_port_from_the_usr_peripheral_1 => usr_peripheral_shared,
     in_port_from_the_usr_peripheral_2  => usr_peripheral_shared
);

BTW, is it possible to give ports from a user peripheral your own names in the 
generated nios_system.vhd file? (instead of out_port_from_the_... and 
in_port_from_the_...)

TIA,
Frank

"Frank van Eijkelenburg" <someone@work.com.invalid> wrote in message 
news:45333f2e$0$11183$bf4948fe@news.tele2.nl...
> Is it possible to have a connection between two seperate user peripherals 
> inside a Nios 2 system?
Yes...but more properly this would be called an SOPC Builder system....you 
don't need to have Nios in there at all.

> Or do I have to route the signals outside the Nios 2 system and connect 
> them at toplevel (like below)?
>
> nios_system : entity work.nios_system
> port map (
>     clk                                => sys_clk,
>     reset_n                            => locked,
>     out_port_from_the_usr_peripheral_1 => usr_peripheral_shared,
>     in_port_from_the_usr_peripheral_2  => usr_peripheral_shared
> );
The connections between the two user peripherals will need to be between two 
Avalon interfaces not just a signal.  In other words if you want to connect 
just the single 'usr_peripheral_shared' signal between the two peripherals 
you'll need to bring them out to the top level and connect them yourself as 
you've mentioned.

If you want to keep it within the SOPC Builder system, the two user 
peripherals then will each need an Avalon interface set of signals so the 
two would look something like....

entity Peripheral1 is port(
.... -- Here you would have the existing Avalon interface signals to talk to 
your Nios
    read:                out    std_logic;
    address:           out    std_logic_vector(1 downto 0);
    read_data:        in      std_logic_vector(7 downto 0);
    wait_request:    in    std_logic);
end Peripheral1;

entity Peripheral2 is port(
.... -- Here you would have the existing Avalon interface signals to talk to 
your Nios
    chip_select:      in    std_logic;
    read:                in    std_logic;
    read_data:        in    std_logic_vector(7 downto 0));
end Peripheral2;

Here I'm assuming that signal 'usr_peripheral_shared' is an output of 
Peripheral2 that needs to go to Peripheral1.  It would do so via one of the 
'read_data' signals.  I've also somewhat arbitrarily defined Peripheral1 to 
be the Avalon master, Peripheral2 to be the Avalon slave which implies that 
#1 needs to do a read from #2.  You could also just as easily make #2 be the 
master and #1 be the slave in which case change 'read' to 'write' and 
'read_data' to 'write_data'.  Within the two architectures you would then 
have....

architecture RTL of Peripheral1 is
begin
    read <= '1';
    address <= (others => '0');
end RTL;

architecture RTL of Peripheral2 is
begin
    read_data(7 downto 1) <= '-';
    read_dta(0) <= usr_peripheral_shared;
end RTL;

In addition to whatever interfaces already exist on these interfaces 
(presumably they each have at least one to talk to your Nios), each of these 
components would also have this new interface and the signals in the entity 
would then get mapped to the Avalon signal interface names (do this in 
Altera's Component Editor).

It seems like a bit of overkill just to send one signal from one block to 
another if you're really only talking about one signal but generally I find 
that two components need to share much more than just one signal in which 
case having a standardized way for them to talk is quite handy.

>
> BTW, is it possible to give ports from a user peripheral your own names in 
> the generated nios_system.vhd file? (instead of out_port_from_the_... and 
> in_port_from_the_...)

I think you're talking about the names as they exit the top level built by 
SOPC Builder.  If so, then I don't think so, but you can name them whatever 
you want above that and hook up your signals via the port map.  In other 
words, don't use the SOPC Builder generated VHDL file as your top level.  In 
fact, if you do bring out your 'usr_peripheral_shared' signal and wrap it 
back around you'll have to have such a wrapper anyway.

KJ 

Correction to earlier post.  The 'read_data' signal on entity
'Peripheral2' should be an 'out', not 'in'.  Corrected entity is shown
below.

entity Peripheral2 is port(
.... -- Here you would have the existing Avalon interface signals to
talk to your Nios
    chip_select:      in    std_logic;
    read:                in    std_logic;
    read_data:        out   std_logic_vector(7 downto 0));
end Peripheral2

KJ