Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Looking for guidance re large team designs

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!

11 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    1) A general rule of thumb is to register the outputs of each partition(I know, it's not always possible). In general this isn't that big of a deal, but sometimes requires moving stuff around. Note that this is based off of what Incremental Compilations underlying principle is, that it saves compile time by not having to re-synthesize and possibly re-fit partitions that haven't changed. If one partition's results are dependent on another partition, then you just have to re-do everything.

    2) I've never seen anyone use .sdc files for partition boundaries.

    3) SignalTap comes in after the merge, which means it views the design as being flat. It works the same whether or not you have partitions.

    I don't get how you would have two different entities NCO with the exact same name in a single VHDL project to begin with(you can have architectures with different configuration bindings, but it doesn't sound like what you're doing.) Heck, a bottom-up flow with .qxps would actually work since you can build Entity1 and Entity2 separately, but it still seems like changing the name would be much simpler and much less confusing in the long run(having two very different behaviours for something that has the same name seems like it could cause problems.)