Custom Instruction writing to FIFO

If you have extra ports declared "export" then they should show up at the top level of your SOPC builder system and not directly in SOPC Builder. SOPC Builder will show you known interfaces like Avalon slave, master, tri-state.

By Altera FIFO I assume you mean "SCFIFO" or "DCFIFO"? If it doesn't have an Avalon slave interface it will not show up in SOPC Builder. But you can run the logic through Component Editor and give it an Avalon interface (so you just need to "bundle" it as a component)

Thanks for the fast response!

What is the "standard" way to integrate an Altera "SCFIFO" with a multiprocessor NIOS II system with Custom Instructions?

Would I do the following:

1. Use SOPC Builder to add CI with extra FIFO interface to some NIOS II processors

2. Hack generated Verilog to instantiate SCFIFO, connecting it to the "extra" CI ports that are exported to the top level

3. Compile the hacked verilog in Quantus

Or are there some Quantus functions/menu options that could help with this?

--- Quote Start ---

originally posted by badomen@Nov 17 2006, 10:03 AM

if you have extra ports declared "export" then they should show up at the top level of your sopc builder system and not directly in sopc builder. sopc builder will show you known interfaces like avalon slave, master, tri-state.

by altera fifo i assume you mean "scfifo" or "dcfifo"? if it doesn't have an avalon slave interface it will not show up in sopc builder. but you can run the logic through component editor and give it an avalon interface (so you just need to "bundle" it as a component)

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=19495)

--- quote end ---

--- Quote End ---

1. Use SOPC Builder to add CI with extra FIFO interface to some NIOS II processors

2. Hack generated Verilog to instantiate SCFIFO, connecting it to the "extra" CI ports that are exported to the top level

3. Compile the hacked verilog in Quantus

This worked for me. I also found the call formats for builtin custom functions on the web:

http://uclibc.org/cgi-bin/viewcvs.cgi/trun...patch?rev=13071 (http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gcc/3.4.3/900-nios2.patch?rev=13071)

+And the function names are:

+@example

+void __builtin_custom_n (void)

+void __builtin_custom_ni (int)

+void __builtin_custom_nf (float)

+void __builtin_custom_np (void *)

+void __builtin_custom_nii (int, int)

+void __builtin_custom_nif (int, float)

+void __builtin_custom_nip (int, void *)

+void __builtin_custom_nfi (float, int)

+void __builtin_custom_nff (float, float)

+void __builtin_custom_nfp (float, void *)

+void __builtin_custom_npi (void *, int)

+void __builtin_custom_npf (void *, float)

+void __builtin_custom_npp (void *, void *)

+int __builtin_custom_in (void)

+int __builtin_custom_ini (int)

+int __builtin_custom_inf (float)

+int __builtin_custom_inp (void *)

+int __builtin_custom_inii (int, int)

+int __builtin_custom_inif (int, float)

+int __builtin_custom_inip (int, void *)

+int __builtin_custom_infi (float, int)

+int __builtin_custom_inff (float, float)

+int __builtin_custom_infp (float, void *)

+int __builtin_custom_inpi (void *, int)

+int __builtin_custom_inpf (void *, float)

+int __builtin_custom_inpp (void *, void *)

+float __builtin_custom_fn (void)

+float __builtin_custom_fni (int)

+float __builtin_custom_fnf (float)

+float __builtin_custom_fnp (void *)

+float __builtin_custom_fnii (int, int)

+float __builtin_custom_fnif (int, float)

+float __builtin_custom_fnip (int, void *)

+float __builtin_custom_fnfi (float, int)

+float __builtin_custom_fnff (float, float)

+float __builtin_custom_fnfp (float, void *)

+float __builtin_custom_fnpi (void *, int)

+float __builtin_custom_fnpf (void *, float)

+float __builtin_custom_fnpp (void *, void *)

+void * __builtin_custom_pn (void)

+void * __builtin_custom_pni (int)

+void * __builtin_custom_pnf (float)

+void * __builtin_custom_pnp (void *)

+void * __builtin_custom_pnii (int, int)

+void * __builtin_custom_pnif (int, float)

+void * __builtin_custom_pnip (int, void *)

+void * __builtin_custom_pnfi (float, int)

+void * __builtin_custom_pnff (float, float)

+void * __builtin_custom_pnfp (float, void *)

+void * __builtin_custom_pnpi (void *, int)

+void * __builtin_custom_pnpf (void *, float)

+void * __builtin_custom_pnpp (void *, void *)

+@end example

+

+

I would recommend against "hacking" the generated Verilog or VHDL. If you do this, everytime you run SOPC Builder, you&#39;ll need to make your changes all over again. Instead, make a top-level design that instantiates the SOPC module & FIFO and connects the two. That way, as long as you don&#39;t make changes to the exported ports from SOPC Builder, you won&#39;t have to redo any code changes.

--- Quote Start ---

originally posted by cjike@Nov 17 2006, 02:13 PM

thanks for the fast response!

what is the "standard" way to integrate an altera "scfifo" with a multiprocessor nios ii system with custom instructions?

would i do the following:

1. use sopc builder to add ci with extra fifo interface to some nios ii processors

2. hack generated verilog to instantiate scfifo, connecting it to the "extra" ci ports that are exported to the top level

3. compile the hacked verilog in quantus

or are there some quantus functions/menu options that could help with this?

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=19498)

--- quote end ---

--- Quote End ---

You don&#39;t really need to "hack" anything. Just use Quartus II to parameterize the SCFIFO logic in whatever language you want, create a custom instruction wrapper that instantiates SCFIFO, map your ports any way you like and off you go (to component editor). I have never used custom instruction mapped FIFOs before but this is how I&#39;d do it (if I had to):

1) Instantiate SCFIFO in my custom instruction RTL

2) Connect each side of the FIFO to a custom instruction interface (remember you need multiple interfaces since you are connecting multiple Nios II cores)

3) Map a secondary set of signals like "empty" and "full" to do some handshaking between CPUs

The reason for# 3 is if Nios A and Nios B are talking to each other through FIFOs, and Nios B goes to read from an empty FIFO then you will have to take care of that. You would either need Nios B to read from a secondary instruction that states there is data in the FIFO or have that FIFO instruction hold Nios B in a wait state by not asserting the "done" bit (potential for deadlock if you are not careful). With all this control I don&#39;t think you are buying much using this FIFO and custom instruction method.

This begs the question of why you want to implement this sharing method using custom instruction mapped FIFOs? There is a mailbox component in SOPC Builder for the purpose of passing messages back and forth between processors. If you want to use low latency memory to store messages then I recommend using tightly coupled memories.