Is there a place to store private C-Blocks to be shared with other sims across directories?

QSPICE
1

I’ve created a few C-blocks I’d like to share across multiple simulation projects and directories.

However, I’d prefer to NOT copy-n-paste these C-blocks manually within each project directory. I’d prefer to store them all in one directory and reference them into each project. The obvious reason is that if I have fix a C-block, I’d rather fix it in one location and have it automatically apply across all projects.

Any ideas? Or am I just missing the obvious?

Len

2

This method works for me.

image
image1612×420 119 KB

1 Like
3

@KSKelvin ,

Thank you for your reply nd suggestions.

Generally it worked as you specified. I performed some quick experiments to yield the following information below.

Good news:

  • You can use relative path names.
  • You can use spaces in the names as long as there are quotes surrounding the string.
  • If you desire, the 1st Attribute can be made invisible so it doesn’t take up too much room on the schematic. Of course it is still editable from the symbol properties editor.

There are some disadvantages to this method you recommend:

  • You need to recreate the hierarchical block with the same pins and, if you use them, the same attributes. You might have a special “look” to the original C-block. Work-around: copy-n-paste the C-hierarchical block from another schematic. This should fix the “look” issue.
  • The recreated pin order needs to re-established in the SAME order. Without the same order, the inputs and outputs will be out-of-sync with the dll declarations. Work-around: copy-n-paste the C-hierarchical block from another schematic. This should fix the pin order issue.
  • As you pointed out, the path name to the dll (without the .dll extension) needs to be the “1st Attribute”. This could be an issue if you are using attributes in the dll to pass configuration data. Work-around: Make the path the first attribute and all other configuration parameters as additional attributes. The C++ code may need to be updated to reflect where in the UData being passed into the function everything is assigned to.
  • Editing the C-block from the remote-referenced block appears to be not possible. I would have to go straight to the original .cpp in the remote directory to modify it. A hassle. However, this might be a blessing in disguise. If you share a C-block with other projects, caution and consideration should be used when modifying it since it might render it unworkable in the other projects.

IMHO I believe adding a new directive such as .incdir could be incorporated to instruct QSPice which additional include directories to use when searching for additional content. It has a .inc directive but this looks for and assumes a file. Maybe the .inc could be expanded to allow for a global directory path to the project.

I’ve tried to use the “Symbol & IP Browser” to add the directories to find the .dlls I’m trying to reference. This could be useful if this window could be used to allow the user to pull the shared .dll, .cpp and hierarchical block symbol into the current project. Then the directories in this browser can be used as include directories during the sim compile.

Either way, QSPice is still a great tool. I can do things in it that I couldn’t do with other sim programs.

Len

4

Hi, Len.

Don’t know whether this will help or not. Let’s say that the primary goal is to be able to have the “production” DLLs in a single library folder so that they don’t need to be copied to the project folder. As you noted, you can use relative paths. To make that more simple, you can map a drive to the folder:

From a command prompt: subst d: [drive:\folder path]. The path will show up in File Explorer. Example:

subst Z: C:\QSpice\MyLib (map drive)
subst Z: /d (delete mapping)

From there, you can use Z:\[dll name] in the symbol or hierarchical block.

However, QSpice uses the proper mapping in the netlist but it doesn’t properly parse the name to open the *,cpp code or *.qsch for a schematic block.

Anyway, the drive mapping might be convenient until Mike implements search paths, etc.

–robert

Edited to add “\” to “Z:\[dll name]”. It was in the text but treated as an escape character in the formatted post.

1 Like
5

Robert,

Thanks for the workaround. For now, I need to add my virtual drive (subst ) into my startup.

Also, thanks for all your contributions.

Len