Looking for guidance re large team designs

--- Quote Start ---

I am looking for guidance from folks with experience developing and/or managing code for large FPGAs.

Our project is moving from three Stratix FPGAs to one Stratix III FPGA.

In the original design, the code for each was compiled from independent files. Not surprisingly the implementer/s copied and changed files. The result being:

1. entities with EXACTLY the same names and ports yet different architectures,

2. a few cases where the names are the same yet ports are different, and

3. lastly the same generics are used with different values.

I choose to solve this problem by using bottom up design and importing a post synthesis net list for the guts of each of the original FPGAs.

While this project is about done, I can see the problem of “duplicated” but different entities in any large team based design preventing top down compiles.

Is there a better way to solve this problem? Managing names from top to bottom does not seem practical.

Thanks!

--- Quote End ---

Hi,

is your design a mixed language design ? I'm not sure, but many it is possible to flatten the sub-designs (I have to look at that), in order to get rid of the duplicated modules.

I had a similar problem with verilog netlists and I solved the problem by renaming the modules (e.g. and2_part1).

Kind regards

GPK

--- Quote Start ---

Hi,

is your design a mixed language design ? I'm not sure, but many it is possible to flatten the sub-designs (I have to look at that), in order to get rid of the duplicated modules.

I had a similar problem with verilog netlists and I solved the problem by renaming the modules (e.g. and2_part1).

Kind regards

GPK

--- Quote End ---

Hi again,

maybe I found a simple solution for your problem. It looks like that the vqm-files you can write out are flat by default. I prepared a smal testcase for you. To my surprise it was not necessary to re-map the stratix project to stratixIII. You can enable the vqm writing under : Setting -> Compilation Process Settings -> Save a node-level netlist ....

Look into the attached project.

Kind regards

GPK

You could:

a) Parameterize them, so the parameters passed in cause different behavior.

b) Use different architectures(VHDL) or just 'ifdef in Verilog the contents.

Both of those are ugly unless the parameterization makes sense for other reasons.

What I would strongly recommend is taking the time to clean up the files and give them new names that make sense based on their changes. Right now you've got multiple files with the same name, which is going to cause problems. If you even want to talk about them, how do you refer to them, i.e. it can't be "the ingress module" if there are three of them, but it would have to be "Charlie's ingress module, not Bill's", or something like that.

Anyway, the entity/module name is what makes them unique, and if you have unique files, then I would give them unique names. You're already jumping through a lot of hoops to get around this, and it's going to get worse, when fixing the names is not that difficult.

Thanks to pletz and Rysc for your suggestions.

For the most part the design is schematic and vhdl with a little verilog. Unfortunately VQM is not supported for Stratix III.

We do not plan to do any cleanup of the current project.

What I would like to know is how folks manage large team based designs so as avoid conflicts between internals of the various blocks.

Is there a better way than bottom up design?

Thanks!

will exporting QXPs work for you? take a look around page 30:

http://www.altera.com/literature/hb/qts/qts_qii51015.pdf

--- Quote Start ---

Thanks to pletz and Rysc for your suggestions.

For the most part the design is schematic and vhdl with a little verilog. Unfortunately VQM is not supported for Stratix III.

We do not plan to do any cleanup of the current project.

What I would like to know is how folks manage large team based designs so as avoid conflicts between internals of the various blocks.

Is there a better way than bottom up design?

Thanks!

--- Quote End ---

Hi,

VQM-files are not longer supported for StratixIII. I got this answer also from Altera. They recommend to use design partitions. I think the only way for you is a bottom up design.

What kind of problem do you have with that solution ?

Kind regards

GPK

While we are presently using bottom up design, the reasons I would prefer not:

1) QII can not optimize across partition boundaries

2) More work especially if SDC files are needed for partion boundaries

3) I don't know how to probe inside a partition with signal tap. I gather it can be done but am not sure.

Still hope someone has a better way than bottom up design or naming conventions.

A simple example of the problem both Entity1 and Entity2 have internal NCOs. The NCOs are not visible at the entity ports. Each designer creates an NCO using the megawizzard and using the same entity name "NCO". Now we compile our Top which has an instance of Entity1 and an instance of Entity2. How to make sure each Entity (1 and 2) are built using the correct definition of NCO.

That is the problem -- solutions Naming conventions, bottom up design, or ??? Someone must know a better way.

I left out another one -- while a partion can have bidirectional ports they MUST only connect to device pins. Bidirectional connections between partitions are not allowed and thus the top design must include an interconnect cloud which implements all the needed to/from interconnects. If every partition communicated in both directions to every other partion, this grows exponentially. In our case the number of interconnects is much smaller but still significant. The PCI Interface exchanges data with each of the other blocks. For the most part the remaining blocks form an input, process, output daisy chain.

In a design w/o partitions or, I believe, inside a partion QII will simulate bidirectional connections.