• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Allegro X PCB Editor
  3. Recommended project directories structure

Stats

  • State Verified Answer
  • Replies 8
  • Answers 2
  • Subscribers 162
  • Views 1543
  • Members are here 0
More Content

Recommended project directories structure

bdc66a938f164d
bdc66a938f164d 20 days ago

I am new to Cadence software. Before starting working on a large project, I would like to know if there is a recommended or most common structure for the directories and files.

One option is to a single directory and all the files in there, but it does not look very convenient for large project. Another option is to have global directories for footprints, symbols, etc. This works fine for a single project, but with multiple projects then everything gets mixed.

In other EDA software tools I usually set up things like this:

```
.
├── libs
│   ├── lib_1
│   │   ├── 3D
│   │   │   └── a.step
│   │   ├── a.footprint
│   │   ├── a.symbol
│   │   ├── b.footprint
│   │   └── b.symbol
│   └── lib_2
│       ├── 3D
│       │   └── a.step
│       ├── a.footprint
│       ├── a.symbol
│       ├── b.footprint
│       └── b.symbol
└── main.project
```

which is very convenient because 

  1. It remain local to the project,
  2. if I reuse say `lib_1` in another project, I can simply symlink to it and use it without duplicating information or having to update any path, and
  3. the working directories stay clean.

I tried to setup something similar for Allegro X but ended up having a lot of issues with the paths. Right now I have everything in a single directory, but I see an inconvenience when the project starts to grow.

  • Cancel
  • Sign in to reply
  • excellon1
    0 excellon1 18 days ago

    Hi

    In Allegro you can basically create any structure that you like, no real limitations. I have found a Global structure for the libs to work best. If your doing a number of projects just keep them in their own folder, You don't need to include the libs etc in that folder only things like the Schematic .Dsn, .brd pcb, Netlist  . By way of an example, I kind of like the plain English approach,  for example.

    Allegro Padstacks TH
    Allegro Padstacks SMD
    Allegro Vias
    Allegro Step Models
    Allegro Libs
    Allegro Modules
    Allegro Clip Files
    Allegro Templates
    Allegro Stackup

    Under Allegro Libs one could have additional folders that describe the contents such as.
    IC
    Capacitors
    Resistors
    Diodes

    These are basically the foofprint containers that reside on disk. Its an easy read if browsing the disk or if you need to schedule backups etc in a corporate situation.
    When you create PCB footprints or ,dra's be aware that the footprint will be made up of a number of items. Typically these are. .pad = Padstack, .psm = Package symbol,
    .dra = Footprint. Depending on how you name your footprint and padstack etc over time it can be difficult to find the complete footprint on disk. One way around this is to take the approach of having the same name for each item. For example assume you are creating a soic8 footprint then the naming would be like this.

    SOIC8.DRA
    SOIC8.PSM
    SOIC8.PAD

    On disk it would be fairly easy to identify a complete footprint done that way. The 3 parts would get put in the folder IC on disk. Usually I create the folders first using windows explorer then point to them when configuring Allegro paths from within Allegro.


    Best Regards

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • bdc66a938f164d
    0 bdc66a938f164d 17 days ago in reply to excellon1

    "... over time it can be difficult to find the complete footprint on disk..."

    This is exactly what I am trying to avoid from time 0.

    If I follow a structure like the one I put in the first post, do I have to add `./libs/lib_1`, ..., `.libs/lib_n` to the paths `padpath`, `psmpath` and `steppath` and that's it? What about name collisions like In my example where I have `lib_1/a` and `lib_2/a`? How are symlinks handled? For example:

    ```
    .
    ├── libs
    │   ├── lib_1
    │   │   ├── a.dra
    │   │   ├── a_pad_1.pad
    │   │   ├── a_pad_2.pad
    │   │   └── a.psm
    │   ├── lib_2
    │   │   ├── a_pad_1.pad -> ../lib_1/a_pad_1.pad
    │   │   ├── b.dra
    │   │   ├── b_pad_1.pad
    │   │   └── b.psm
    │   └── lib_3 -> /path/to/wherever/lib_3/is
    └── main.project
    ```

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • excellon1
    0 excellon1 17 days ago in reply to bdc66a938f164d

    I follow what your trying to do by splitting the items into their own folder. I have seen structures similar, like some people use a global step and padstack folder that is part of the basis for building up a library. It's really down to what one thinks works best.

    Whatever you end up going with, Just update the paths to the folders and sub folders so Allegro will know where to find the objects. One thing to be aware of is make sure you don't have duplicate symbol names in seperate folders. This can cause netlisting issues.

    There is a problem with your idea. You split the DRA & PSM into seperate folders. The issue with that is when you create a footprint and save it
    to disk it will save the psm, dra into the same folder. This means your going to have to do a manual move to put the files where they need to be so as to split them out. Allegro does not know how to save out objects to seperate folders that make up a footprint. The paths are read only unless you decide to create a footprint under one of those folders. If you do that you will find all the objects PSM, DRA etc in that folder.

    I think it is better to have your project folder totally seperate from any library folders. In some corporate environments the actual libs are on a networked shared folder so users can access them. Typically a designer will work locally on the physical PCB.

    One other thing. When you have your PCB created the actual pcb contains all the footprints and padstacks. These can be exported if there is a need to supply them with the design. To do an export go to File > Export Libraries.

    Best regards.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • bdc66a938f164d
    +1 bdc66a938f164d 15 days ago

    For future reference, this is how I achieved what I wanted:

    1. Within Allegro, go to "Setup/User preferences/Paths/Library" and add `$PROJECT_LIBS` to `padpath`, `psmpath` and `steppath`.
    2. Create a folder next to your project called `libs`.
    3. Create local project libraries with folders inside `libs`, e.g. `libs/connectors`, `libs/vias`, etc.
    4. Create `open_project.bat` and paste the contents below into it, save it and close it.
    4. Run `open_project.bat` (double click it) to open your project from now on. It will automatically and temporarily add all your libraries paths and start Allegro.

    Important: The changes made by the script are temporary, meaning that it will not interfere with any other existing configuration and also next time you open your project, you have to do it through the script.

    Script `open_project.bat`:

    ```
    REM Manual configuration below:
    set PATH_TO_ALLEGRO_EXE=C:\Cadence\SPB_24.1\tools\bin\allegro.exe
    set NAME_OF_PROJECT_FILE=main.mcm

    ::::::::::::::::::::::::::::::::::::::

    REM Get the directory of this batch file, we assume the `NAME_OF_PROJECT_FILE` sits right next to this script:
    set PROJECT_DIR=%~dp0
    REM Initialize PROJECT_LIBS variable:
    set PROJECT_LIBS=
    REM Enable delayed variable expansion so the `for` loop does not fail:
    setlocal enabledelayedexpansion


    REM Recursively loop through all subdirectories in ./libs:
    for /R "%PROJECT_DIR%libs" %%L in (.) do (
        if exist "%%L\" (
            set PROJECT_LIBS=!PROJECT_LIBS! %%L;
        )
    )
    ::echo %PROJECT_LIBS%
    ::pause

    REM Launch Allegro with the project file:
    set PATH_TO_PROJECT_FILE=%PROJECT_DIR%%NAME_OF_PROJECT_FILE%
    start "" "%PATH_TO_ALLEGRO_EXE%" "%PATH_TO_PROJECT_FILE%"

    ```

    Note that the script works recursively, so you can have an arbitrary directory structure within `libs`, e.g.:

    .
    ├── libs
    │   ├── lib_1
    │   │   ├── component_a
    │   │   │   ├── 3D_model.step
    │   │   │   ├── a.dra
    │   │   │   ├── a.psm
    │   │   │   ├── pad_1.pad
    │   │   │   └── pad_2.pad
    │   │   └── component_b
    │   │       ├── 1.pad
    │   │       ├── 2.pad
    │   │       ├── 3D_model.step
    │   │       ├── 3.pad
    │   │       ├── 4.pad
    │   │       ├── b.dra
    │   │       └── b.psm
    │   └── lib_2
    │       └── component_c
    │           ├── 3D_model.step
    │           ├── c.dra
    │           └── c.psm
    ├── main.mcm
    └── open_project.bat

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Reject Answer
    • Cancel
  • avant
    0 avant 15 days ago in reply to bdc66a938f164d

    We have multiple users and have one folder for footprints (.dra and .psm), one for padstacks, and one for clip files.

    We ensure users are only pointing to these folders. (delete the pointers to supplied libraries that came from Cadence).

    This simple structure is easy to maintain and ensures there are no duplicates.

    If a footprint or padstack is revised, all users have access to the new version.

    Note that an Allegro board file contains all footprints and padstacks used in the design and can be exported if need be.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
>
Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information