Qsys

By the sounds of it, the on-chip memory component in Qsys/SOPC Builder could be set to ROM mode and all you need is a master that will read from it in a cycling fashion. This will use Avalon-MM to perform the read accesses but to make a master that simply cycles through ROM reads is not difficult to implement so you may find making an Avalon-MM mastering component that reads from a memory mapped ROM and outputs streaming data to be the easiest way to do this. Here are the major pieces to make this work:

Avalon MM read master that is clocked on say "clock A" that simply posts reads to various addresses in the ROM and sends the valid read data into a dual clock FIFO. The output of the FIFO can be connected to a streaming source port one say "clock B" which matches your output clock frequency. This approach will be much more scalable if you decide to switch the ROM to a RAM in order to change the pattern on-the-fly since you won't have to change this fetching hardware at all. This is what I mean about using standard interfaces, if you stick to the Avalon interface standard..... you don't have to worry about the glue logic in between IP cores when using SOPC Builder/Qsys.

The mSGDMA I pointed you at can do this for you but if you want a smaller and faster (fmax) way to do this the hardware implementation is fairly trivial to implement as a custom frontend. If you do all this using conduits in SOPC Builder/Qsys then I don't see the point in using those tools since conduit connections are point to point and the tools don't add anything to your design that you couldn't do in HDL. The purpose of SOPC Builder and Qsys is to make you stick to standards so that you can re-use IP and not have to worry about how IP block "A" communicates to "B".

I highly recommend you read the Avalon specifications for MM and ST. Hopefully they'll do a better job explaining why it's trivial to re-invent the wheel hooking up IP blocks using conduits.