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

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

--- 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

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?

--- 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

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!

--- 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