Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
21615 Discussions

Multicycle MIPS Compilation Problem

Altera_Forum
Honored Contributor II
1,444 Views

Hi I'm new here, I'm sorry if this might not be the appropriate place for this but this seemed like a Quartus issue so I decided to give it a shot. Yes, this is a college lab project but the issue seems so obscure that maybe someone has run into something like this. 

 

I have one input -- the clock. (not including the .MIF files used for my ROMs) 

 

I'm trying to implement a Multicycle MIPS CPU and I get two nasty errors right when it's about done compling (say maybe 92% complete).  

 

But get this, these errors ONLY come up when I try to add output pins!! It will compile successfully when there are no output pins. 

 

I tried having the output pins virtually connected as well as hard-wired but to no avail. 

 

Error: WYSIWYG primitive "memory_blocks[0][0]" has mismatched parameters for port Port A, Read Address 

Error: WYSIWYG primitive "memory_blocks[1][0]" has mismatched parameters for port Port A, Read Address 

 

Edit: When I double-clock the errors, Quartus takes me to some Quartus-"critical" definition file and here's the path: 

../../../../../altera/81/quartus/libraries/megafunctions/altqpram.tdf 

 

I've compiled all my sub-symbols used, i.e. Control, ALU Control, shift left logical, sign-extend, the ALU, regsiter file, etc. and they all compiled successfully, no errors. In fact, I made made separate project files for said lower level blocks, debugged all pieces independently from the top-level design and all I/O pins reported the right stuff after analyzing the Vector Wave form files form simulation. 

 

I even updated the symbols used in my top-level design. ... No go. 

 

Any suggestions would be great. 

If I need to post more info please by all means let me know. 

 

Thanks.
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
739 Views

The fact that the design compiles successfully when you remove the output pins might come from the fact that all your design gets "optimized away" by the synthesizer. 

From what you are describing, it looks like Quartus is not happy with the way you instantiated or connected to a megafunction. 

Do you have altqpram megafunctions in your design? If you only have this message when you compile the full design, it could come from a problem in the way you connect all the pieces together.
0 Kudos
Altera_Forum
Honored Contributor II
739 Views

I'm surprised that you are using altqpram. The on-line help page for this megafunction says this: 

 

 

--- Quote Start ---  

The altqpram megafunction is available for APEX II devices only. This megafunction is provided only for backward compatibility for Cyclone, Cyclone II, HardCopy Stratix, Stratix, and Stratix GX devices; instead, Altera recommends using the altsyncram megafunction. 

--- Quote End ---  

 

 

Did you manually select altqpram, or is synthesis inferring it?
0 Kudos
Altera_Forum
Honored Contributor II
739 Views

Thanks for the replies. I think Daixiwen was correct -- I'm a beginner and actually i don't really plan on using Quartus anymore after this class so I'm not too sure about the formal naming 

 

The main issue was that there was a bad virtual connection -- The source virtual connection of the issue was named "Address[31..0]" whereas while looking over the virtual connections and maybe zoomed out a little too far, the destination virtual name "Adress[31..0]" seemed just fine at the time. lol. 

 

It was quite frustrating thought that the error seemed much more "critical" since it was pointing to such an obscure file when I would double-click on it. 

 

My lab partners and I received a pretty good grade except what happened was that we had an error in our Dispatch ROMs and our main control unit -- we mistook LUI and ADDI for R-Type instructions.. oops! So we fixed it, turned it in a bit late but was fully functional. 

 

Thanks again.
0 Kudos
Reply