How to design a component which has N number of Avalon ST Sink ports in SOPC Builder

[Altera_Forum]

Hi, 

 I need to design a component which has N number of Avalon ST Sink interfaces. The number of Avalon ST interfaces required is user programmable. It should be generic.    For Example, how we configued number of input ports (Avalon ST Sink ports) parameter in Avalon ST Multiplexer core for generating that number of Avalon ST Sink ports in a component.   So can you please help me how can I achieve this for custom component using SOPC builder?   Thanks in advance.

[Altera_Forum]

It's probably easiest to do this by coding up the maximum number of ST interfaces your component will support, feed it through component editor, then modify the .tcl file to add an elaboration callback which will stub out interfaces based on the parametrization. In the SOPC Builder handbook there is a chapter on the .tcl API you use to do this.

[Altera_Forum]

Could be an academic question perhaps, what do yo do if you would want to allow up to (let's say) 512 Sinks in a single component? 

The suggested (and used by Altera) method to just enumerate a number of ST interfaces, and them 'stubbing' them out at instantiation time can be 'at best' called clumsy. It also will probably generate another zilllion warnings during Analysis, just cluttering up the Message-Window?  I devised my own Source-Sink protocol before Avalon-ST came into play. It can be easily mapped into a subset of the ST-signals, and I'm going to migrate this into QSys/SoPC but the missing generics make me wonder. I just checked the .sv and .tcl of the ST-splitter. I wonder if it will be easier in VHDL?

[Altera_Forum]

For up 512 sinks in a single component I would probably build that up as a composed .tcl component made up of smaller components internally (hierarchical component). Now a component with 512 interfaces I think will be pretty hard to manage in a graphical sense so using hierarchy I would make sure only the interfaces that need to talk to the outside world are exposed while the others are wired up internally. 

 If you stub out interfaces you can set the inputs to a known value so the only messages you should see are optimization messages. So when I say stub I don't mean leaving it disconnected which I agree would be problematic.

[Altera_Forum]

You're quite right that handling 512 connections graphically would be a chore, but then it was an academic question ... 

But I have a few building blocks with either multiple sinks or multiple source and I have one with multiple sinks and sources. This means if I want to keep things tidy I have to write variations on a as needed basis, or try the .tcl way. I'm not fond of having to write a .tcl script because somebody else flawed the design (aside from the time spent to learn the quirks). And I have already seen too many .tcl scripts calling another .tcl script calling ... , you get the idea. I didn't see how this setting the inputs (what about unused outputs?) to a default value is done in the example I studied, but again I'm not an a .Tcl expert nor do I read much Verilog. I'm pretty sure that a lot of 'unnecessary' info and warning messages will be generated. I can live with the Info messages (I generate some myself), but I always get worried about Warning messages, as an old saying goes: "a warning is an error waiting to happen" (this goes back to the early days of C-programming). Can you explain why generics don't work, or what the rationale is behind leaving them out is?

[Altera_Forum]

Stubbed outputs will remain stubbed in the hardware so the usual synthesis optimizations will apply to those and you'll get the appropriate messages from Quartus II about it. Typically I tag my HDL with attributes to prevent those Quartus messages from occurring. In cases like these I typically use generate statements in my verilog so that I can control what gets synthesized.... not sure if VHDL has a similar feature though. The only way I can think of preventing those messages without using the attributes is to have your HDL generated on the fly using a generation callback. 

 I'm not a .tcl expert but I have found tweaking .tcl files after they are generated by component editor to be fairly trivial. I also don't think there is a cleaner solution to this problem since this is the price you pay for implementing/using highly parameterizable IP. The tools can't magically implement the interfaces for you since at the end of the day those interfaces connect to your own logic so I don't really see what you are getting at....  As for a lack of generics, I'm not sure about that one since I was under the impression they were supported so this is news to me. I know historically generics have been problematic but I don't think they were completely omitted from the product support.

[Altera_Forum]

--- Quote Start ---  In cases like these I typically use generate statements in my verilog so that I can control what gets synthesized.... not sure if VHDL has a similar feature though  --- Quote End ---   Annie get your gun?   --- Quote Start ---  The only way I can think of preventing those messages without using the attributes is to have your HDL generated on the fly using a generation callback.  --- Quote End ---   I found an example of this 'generation call-back' in a thread by dwh@ovro.caltech.edu(http://www.alteraforum.com/forum/showthread.php?t=26957 (http://www.alteraforum.com/forum/showthread.php?t=26957)). This looks feasible to me. As I have to write a wrapper around my 'subset' to get the proper ST-names anyway, I might as well generate the port list and connect it up.   --- Quote Start ---  As for a lack of generics, I'm not sure about that one since I was under the impression they were supported so this is news to me  --- Quote End ---   If you take a look at e.g. the ST-splitter code you will see that all the 16 (which is the maximum supported according to the user guide) ports are defined (the code is in SystemVerilog) and the 'elaborate' call-back does some work on the unused. There is no 'generation' call-back.  The approach taken can be called 'using generics' if you do the extra work of either writing the fully expanded ports list and 'elaborate' what is actually used or 'generate' a new file. True generics would result in using std_logic_2D for the data and std_logic_vectors for the signals, like:  NUMBER_OF_SINKS : positive := 32 ; ... asi_data : out std_logic_2D(NUMBER_OF_SINKS -1 downto 0, WIDTH_D - 1 downto 0) ; asi_ready : out std_logic_vector( NUMBER_OF_SINKS -1 downto 0) ; .... Excuse me for the VHDL, I don't know enough of Verilog to type it out just on top of my head :) The std_logic_2D is defined in the LPM library and matches the AHDL double array: a[][] construct.