How to keep all top level signals for mapping to pins (feasibility study)

[Altera_Forum]

Hello, 

 For a feasibility study, I have to see if we can use a certain FPGA. Mainly seeing if we can fit all the needed signals on the pins.  For that I took another project on which the new project will be based. Removed all the code and left the toplevel signals which need to be mapped on the pins. I also kept all needed pin assignments.  It does it synthesis and elaboration well but when it comes to the fitter, I get following error (for multiple pins): Error (177035): The input pin tmds0_rx_dp[0] assigned to HSSI Pin_V34 has no fanout. Error (177035): The input pin tmds0_rx_dn[0] assigned to HSSI Pin_V33 has no fanout.  How can I overcome this error? I tried adding the preserve_fanout_free_node attribute on these pins. I tried adding an iobuf_diff for these differential signals and noprune on their output. But nothing helps.  Does somebody know how to overcome this? Or help me in the right direction for such a feasibility study?  Thanks a lot in advance!

[Altera_Forum]

A brute solution which doesn't need any attribute is feeding the N unused input signals into a N input AND or OR port and drive a spare fpga pin with the port output

[Altera_Forum]

Altera has made the creation of a "basic" top-level design, i.e., one which includes all pin assignments, but minimal logic (eg., "blinky LED") very difficult. 

 For example, transceiver interface pin assignments cannot appear in a top-level design *unless* they connect to a transceiver IP block. This "rule" also applied to transceiver reference clocks. The workaround is to instantiate a transceiver IP block, and hold it in reset.  I was playing with the BeMicro CV (Cyclone V) kit last month and it appears there is a new "rule"; you cannot include pin assignments for the hard memory interface unless they are connected to a hard memory IP instance. I tried using ALTIOBUF components, but Quartus 13.0sp1 would "freeze" and never complete compilation. I haven't had a chance to try 13.1 ... I'll re-run the script now.  Bottom-line is that Altera make using a common top-level entity difficult, but (probably) not impossible depending on your device.  What part are you using, and what pin assignments to interfaces do you need to preserve?  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   I haven't had a chance to try 13.1 ... I'll re-run the script now.   --- Quote End ---   Quartus gets to "Fitter router operations beginning", has a message that interconnect usage is 0%, and then goes off into la-la-land; its been 30minutes and its still running (using a CPU core according to the Windows task manager).  So even if you can describe a legitimate design with appropriate "null" IP blocks inserted to preserve pin assignments, there's no guarantee Quartus will actually synthesize it!!!  Cheers, Dave

[Altera_Forum]

Thanks for your replies, sorry that mine is late! 

 I'm using an Arria V and need to interface (a lot of) memories, transcievers and general I/O on 1.5, 2.5 and 3.3V. So it seems that what I want to achieve is quite hard to do? In theory, all the required pins should fit on the device but I want to be sure. How are people doing this feasability study then?

[Altera_Forum]

--- Quote Start ---   I'm using an Arria V and need to interface (a lot of) memories, transcievers and general I/O on 1.5, 2.5 and 3.3V. So it seems that what I want to achieve is quite hard to do? In theory, all the required pins should fit on the device but I want to be sure. How are people doing this feasability study then?  --- Quote End ---    Start with a development kit; you don't have to actually buy it, just go through and configure the memory interfaces from scratch, or using their example designs, "reverse engineer" the IP core settings.  For example, the Arria V GT Development Kit appears to be shipping with the non-ES (engineering sample) devices. I have some ideas for a design in an Arria V, and started a couple of example projects using the device on that kit (there's two identical devices).  Create a design for each IP core you want to use, synthesize it, add timing constraints, and get each core to meet timing. Then start combining IP into a single system. For example, each IP could be part of a Qsys system, with an Avalon-MM master that is either a JTAG-to-Avalon-MM bridge or a NIOS II processor, or if you want to simulate, an Avalon-MM BFM master.  The key to FPGA development is to have the top-level design synthesized *before* you actually design a board. Then as you design your board, you can move pins around to ease routing, and re-synthesize the design to make sure you have not made an illegal change to the pin assignments.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Thanks for your extended explanation, I'm quite new to this and this is really helpful.  For this new project we want to go further from another project. But now with interface Y instead of interface X, more memories... In theory we have enough pins but it's close. Therefore, I wanted to check this with the pin planner. I removed all code from this old project and changed the top level interface. Adding more and more pins with some basic code or a megawizard design behind it. Some things got synthesized away and to prevent this, I created this thread. In the meanwhile I got to know virtual pins which also helped preventing things from getting synthesized away.  I also ran into trouble with VCCIO and VCCPD. I didn't knew the concept of pre-driver voltage and that they are shared among multiple I/O banks preventing for example the use of 3.3V I/O and 1.5V I/O in the same group.  Once again, thank you for your help!

[Altera_Forum]

--- Quote Start ---   Thanks for your extended explanation, I'm quite new to this and this is really helpful.   --- Quote End ---   You're welcome.    --- Quote Start ---   For this new project we want to go further from another project. But now with interface Y instead of interface X, more memories... In theory we have enough pins but it's close. Therefore, I wanted to check this with the pin planner. I removed all code from this old project and changed the top level interface. Adding more and more pins with some basic code or a megawizard design behind it. Some things got synthesized away and to prevent this, I created this thread. In the meanwhile I got to know virtual pins which also helped preventing things from getting synthesized away.   --- Quote End ---   Another way to stop the synthesis tool from removing components is to use synthesis constraints (keep and no prune). Though eventually its better to create a design that works, eg., a Qsys system, add stuff to that system, simulate it, and then synthesize it. At least then you can be 100% sure your resource estimates are legitimate ... unfortunately it requires more effort.  Cheers, Dave