Qsys

[Altera_Forum]

As you find workarounds to Qsys issues please add them to the list found here: http://www.alterawiki.com/wiki/new_qsys_issues 

 You'll save others some time and your input will be monitored by Altera as well.  If you require assistance from Altera tech support please file a service request at this link: http://www.altera.com/mysupport

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

Does the set change occur anywhere in the middle of the 128 entry pattern or just when the counter rolls over? If it can happen at any time do you reset the counter or just continue where you left off? 

 I'm picturing a memory that contains two or more sets of data and a master that knows how to jump between sets. If at the time of a set change you have to flush out any data already preloaded from the old set then that would introduce gaps in your output. So if you clocked the master and memory higher than the rate that ALTGX consumes this data then I could see this being achieved using a clock crossing FIFO (at the expense of even more latency). If you are allowed to let an element or two through from the old set on a set change then this switchover should be fairly trivial. Also using a dual port memory might allow you to be reading two sets in parallel so that you can switch over easier.

[Altera_Forum]

In my application (which is not a communication of data) it is critical that that upon a switch of data bit sets the current bit position of the serializer is maintained - it simply sends out the same position bit value form the new data bit set. The set switch is synchronous with the clock but not with the serializer.  

 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.   I am forced to use the ALTGX IP which includes a FIFO to get access to the GX serial output and that messes up my output stream....  Moreover there are some 10 - 32 sets of bits and the selection of sets is done in hardware by controlling the set address through I/O pins.   but for now - proof of concept - I can live with the FIFO provided nothing is reset when a set is switched. The result would be a delay in the duration that it would take bits from the new set to show up in the output but the bit position in the set would be kept. since neither the data word counter or the FIFO sequence are disturbed.

[Altera_Forum]

--- Quote Start ---    The byteblaster issue is a bit annoying but at the moment I've resolve it as suggested on the websites.    --- Quote End ---     which problem is this? I've been having issues with my computer bluescreening upon connecting to byteblaster and have had no luck finding any solutions to this.

[Altera_Forum]

Ok, I'm reverting back to QII v9.0 and SOPC Builder and Nios2-studio because they all worked. The SDI Audio extract and embed are not worth it, Qsys is extremely slow to generate, and randomly works or doesn't, and Nios2 Eclipse build tools can't remember your Flash programming settings from one minute to the next (though apparently, if you create an empty flash settings file, and save to that, then it will work, but not the handy list of projects you got with nios2-studio). 

 Also the VHDL editor in QII 11.0sp1 is a retro-grade step from QII 9.0. The gripes I've got so far may not sound much but make some things much more laborious: 1) Column block editing is broken. You can select, and cut and delete column blocks, but pasting fails completely - it doesn't think you want your pasted block inserted as a column on the lines that are already there, and instead pastes them into new lines. Ha ha ha 2) You can't get a split screen in the editor anymore, so comparing your component declaration to the instantiation is a pain in the a**e.  Qsys: 1) The tristate bus problems seem to be well documented here: http://www.alteraforum.com/forum/showthread.php?p=119780#post119780 (http://www.alteraforum.com/forum/showthread.php?p=119780#post119780) but since then I've compiled my design, which after that thread had programmed flash beautifully, and not having changed ANYTHING in Qsys, only to find that the flash programmer can erase my flash, and program the first 120 bytes or so, but then gives up. This is on a board that I've compiled and recompiled multiple (at least 20 different) designs for in QII v9.0 and SOPC Builder and NEVER EVER had that happen. 2) Qsys seems to take an AGE to generate. I assume it's all the inserting Merlin stuff between all the avalon components, etc. But I suspect they introduce timing problems with my flash programming as well, so are not worth it. 3) All the memories I had generated for v9.0 don't seem to work, and there doesn't seem to be any way of adding a "this is a memory" tag to a custom component. Fortunately the memory generator in Qsys seems to let you generate internal memory relatively quickly, though you get many more signals than you used to in v9.0  All in all, not a happy chap.:(

[Altera_Forum]

Hi. 

 Did anyone try to use AXI interface in Qsys 11.1? It's supposed to be supported there.  I was expecting to see AXI interface on NIOS processor, but Only Avalon interfaces exist. How can an IP with AXI slave interface be connected to NIOS?  Should the protocol conversion from Avalon to AXI be performed by means of some Altera IPs?  In addition, In Components library of Qsys under Qsys Interconnect there's "AXI Interface" section with 2 components : AXI Master Network Interface and AXI Slave Network Interface. AXI Slave Network Interface accepts command packets on avalon_streaming interface and issues the resulting transactions to the AXI interface.  1) Does it mean that for connecting AXI IP to NIOS we should first translate Avalon-MM interface of NIOS to Avalon-ST interface, and after that use AXI Slave Network Interface?  2) There's no any documentation on AXI Master and Slave blocks. There're a lot of parameters inside and it's unclear how to set them. Does anyone have a clue how to deal with it?

[Altera_Forum]

Since I already answered you in the other thread you created I won't repeat myself. Others inquiring about AXI support should read this: http://www.alterawiki.com/wiki/axi_support Note that AXI support is beta in 11.1 so expect some pointy edges.

[Altera_Forum]

--- Quote Start ---  Others inquiring about AXI support should read this: http://www.alterawiki.com/wiki/axi_support Note that AXI support is beta in 11.1 so expect some pointy edges.   --- Quote End ---    I'm not afraid to bleed ... :)  There's an inconsistency in the release notes though:  http://www.altera.com/products/software/quartus-ii/whats-new/swf-qts-whats-new.html  Which states there is an "AXI® bus functional model (BFM) beta".  whereas the Wiki states "There are no AXI bus functional models (BFMs) provided in this version".  I'll download v11.1 and see which comment is true ... unless of course you know the answer off-hand ...  Cheers, Dave

[Altera_Forum]

It is somewhere in the middle. The HPS (hard processor system) has BFMs for the AXI ports on it but there are no standalone AXI BFMs yet. The HPS BFMs are not publicly documented yet so I don't think you will get very far trying to use them.

[Altera_Forum]

--- Quote Start ---  It is somewhere in the middle. The HPS (hard processor system) has BFMs for the AXI ports on it but there are no standalone AXI BFMs yet. The HPS BFMs are not publicly documented yet so I don't think you will get very far trying to use them.  --- Quote End ---    Ok, I'll just take a cursory glance at them then.  Cheers, Dave

[Altera_Forum]

You'll want to look at the AXI bridge interfaces, the multi-port SDRAM controller AXI/Avalon interfaces do not have BFMs hooked up yet. The AXI bridge interfaces are the ones that support 32/64/128 bit data widths into the FPGA fabric.