Qsys

Hi, also when i encounter problems?? For example i have a design which has worked perfect before on the Strativ IV dev kit and also on the Cyclone IV transceiver kit, both using the shared SSRAM and Flash on a tristate external bus. I do know that there are migration guidelines for the tristate bus, but whatever i do, i cannot get the design work anymore in reality... very annoying...

update: solved... see another thread that i posted

[BO] Adding your link so others can find it: http://www.alteraforum.com/forum/showthread.php?p=119780#post119780

In general, I would agree with the concept of maintaining a Wiki page for workarounds however, I would like to ask a fundamental question to anyone that has tried the 11.0 tools and/or migrated a design to the new Qsys environment:

Do you believe this 11.0 tool release represents a reasonably well-engineered product?

And a follow up question: Will you continue to use the 11.0 tools or will you revert to a previous release and wait for the next one?

My impression is that Altera has committed themselves to two annual tool releases (one in spring and one in the fall) and the schedule has become the most important factor of consideration regradless of how well the tools work when the release date rolls around. I do not see a reasonable engineering explanation given of how the Qsys system differs from the SOPC implementation so that as an engineer I can understand why they did what they did and understand how to tailor those changes to my project.

The impression I get is that if the tools aren't quite ready to go, then Altera will let the users be the guinea pigs and provide the feedback to clean up the tools for the next release. And that's all well and good, but those of us that pay the yearly maintenance fee should not be doing the testing that Altera should be doing as part of the responsibility that comes along with selling a product.

I agree with BusDriver completely. I keep hoping that some day these changes that Altera keeps throwing at us will end up as a development system that is actually useful and does what it is supposed to do, but in the meantime it is nothing but constant aggravation.

Hopefully I will be able to glean enough from their Qsys training workshop next week to be able to continue with my design. As for now my project is dead in the water and I don't know where to turn.

I hope the rest of you are having better luck with QII, Qsys, and Nios II for Eclipse than I have been having.

Sincerly I think that QII 11.0 >>> QII 10.x !

Qsys is a very nice system and I'm doing my new design using it a lot.

Qsys at the moment has 2 big advantage respect SOPC builder:

1- all communications are "packetized" and so you can achieve faster speed (very difficult with SOPC when you start to have some fast peripheral on the same bus - I had in past quite a bit of problems in order to let a DDR2 work with a Stratix III)

2- A slave that is accessed by 2+ different master will be seen by each master with a different base address (that can be the same, but CAN BE DIFFERENT - sopc cannot do this).

Moreover a lot of problem of QII 10.1 has been fixed (graphical entry expecially).

Told that I still prefer the interface of QII 9.1sp2 that except for Qsys imo is the best release ever, but unfortunatly there is a bug with Stratix IV gx with the Hard IP of PCIe (do not check some thing such as that the links to be used are only of GXB0 and others) and so I'll stuck to QII 11.0.

The byteblaster issue is a bit annoying but at the moment I've resolve it as suggested on the websites.

About nios, I've never used it before this version so I cannot comment.

Sincerly I love qII 9.1 sp2, I hated qII 10.x, whereas I like the qII 11.0 atm also if it's not perfect.

With Qsys and SOPC_Builder on Linux platforms, when adding custom components, error messages about missing top level module or multiple modules can be caused by the first line of /etc/issue being written into the PLATFORM tag of the temporary xml file. (See discussion on quartus_map terminates unexpectedly). This results in a parse error whe reading the xml file to create the interface.

By default the first line of /etc/issue contains non-printing characters, actually command sequence to clear the screen on boot up.

Hi - I have been struggling to use Qsys for my project having difficulty setting up an address bus. In my system I have an ALTGX instance configured as a transmitter/serializer and using 16bit data FIFO. It generates a data clock output which is 1/16th of the serial bit rate. I am trying to stream the data input into the FIFO from an on chip ROM memory. I use a 3bit counter clocked by the data clock to generate the LSB part of the memory address. (This arrangement cycles repeatedly through 8 memory locations which is a data set) In Qsys I define these lines as a conduit. Now I need another 5 address lines - the MSB part of the memory address - tied to input pins to select one of 32 sets of data.

I have no idea how to combine the MSB lines and the LSB lines to form one address bus in Qsys.

Any suggestions

If I understood what you are trying to do I think you would be best off with a comonent that has an Avalon-MM master on one side and an Avalon-ST source on the other side so that you could do something like this:

RAM (slave) --> (master) <your custom component> (source) --> (sink) FIFO --> whatever this goes to

Doing so will allow you to re-use a bunch of pre-existing components and you also will not have to worry about building your own interconnect. By wiring everything using conduits you kinda defeat the purpose of using Qsys since you could do that in HDL yourself. In Qsys you use standard interfaces and let the tool build the rest for you.

Also by the sounds of that repeating pattern of reading back 8 words then cycling back to the start sounds a lot like the 'parked reads' feature of my modular SGDMA. You can find it in the alterawiki, there is also an example of using the parked reads feature in the video frame buffering design I posted in the wiki since that's how I perform frame buffer repeating in that design.

Thanks for your quick replay BadOmen,

Yes you are correct - I need to design a pure (no added bits) cyclic serializer which outputs a hardware selected set, from a pool of 32 pre-programmed sets, of 8 16bit words=128bits on a serial line at 2.5Gbps.

The hardware selection is time critical - the switch between sets must occur in one data clock cycle without resetting the FIFO or word counter. In fact that is all what I use the Cyclone IV GX for at this stage of the project.

The first part of your answer is related to the data path - that part is actually not what I had the difficulty with. I defined an on-chip 1port ROM MegaWizard instance which has separate data and address interfaces. I connected its data output using Avalon ST master signal type to the ALTGX transmitter data input which is an Avalon ST slave.

I have difficulty with the addressing of the ROM - in Qsys - I do not know how to form the address bus from two sets of lines coming from independent sources (3 LSB lines from the cyclic word counter and 5 MSB lines from FPGA input pins driven by an external controller in hardware)

I'n looking at the SGDMA component you suggested as a different approach for the cyclic data transfer - from first impression it looks much more complex then my (Naive?) system concept.

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.

Thanks BadOmen,

I appreciate your thoughts and recommendations - and most certainly know the value of standard interfaces IP reuse and scalability.

However the FIFO at the input to the ALTGX will further scramble the timing of the GX output when a "set" is changed. In my application (which is not a communication of data)

It is critical that that upon a switch of bit sets the current bit position of the serializer is maintained - it simply sends the bit value form the new sequence.

In theory, the correct implementation of the function that I need is with a MUX 128:1 and a free running 7 bit counter that cyclically addresses the MUX at the output clock rate. In this way a change in the data at the input of the MUX changes the output stream immediately - as in the next bit state.

Unfortunately I have to use the ALTGX mega-function to access the high speed data rate hardware and high speed PLL - it was designed with a data communication in mind. It already forces me to live with its internal 4 word deep FIFO logic and the associated latency (the time it takes for the ALTGX FIFO to fill up with the new data when bit sets are switched) this results in an unavoidable skew.