Multisim and Ultiboard

cancel
Showing results for 
Search instead for 
Did you mean: 

quad package pin mapping

Can anyone explain how the pin mapping works for the LM3301 example? It looks to me like the map given would short together various pins due to duplicate definitions for the supply pins (eg Pin1 is 1IN+ and VS+). I would have expected the pcb (footprint) pins to only appear once in the list, but for multiple signals to connect to them, eg VS1, VS2, VS3, VS4....The mutiple supply pins are required because the EW symbols for the amplifier gates all include the power pins...so there are 20 symbol pins to be connected to the mechanical model (4 x 3 signals, 4 x +ve power, 4 x -ve power).
 
I've built and checked a net list and the connections seem correct but I can't see how the S/W digs itself out of the mapping mess. I'm sure I'm missing something obvious...so can someone help me out of this!
 
Also, on a similar point.....is there a way to set up and use alternate symbols in this type of situation so that 1 gate of the 4 carries the power pins and the other 3 do not replicate this pointless information. You can with Cadstar, Mentor Graphics, Protel etc, so I would be suprised if this package doesn't do it (and irritated)
 
Ta
 
Ian
 
0 Kudos
Message 1 of 7
(7,446 Views)
Ian,
 
In Quad-packages such as that for the LM3301N, what you may notice is that in the pin properties is that the Vs pins for each segment are classified as COM or common. Because of this Multisim/Ultiboard automatically assign the footprint mapping to what the first Vs pins are set to. Because of this regardless of what the other pins are set to with regards to the footprint, when we do transfer forward to Ultiboard the pin mappings will be correct (as you have noticed). Essentially what you will see is that the COMMON area will clean up any issues with mapping and make sure everything looks fine in Ultiboard.
 
One thing that you might notice is that if you do have multiple sections of your QUAD package placed (so for example the A, B and C section), once you connect the voltage rails on one of the OpAmps (for example the A section), the supply pins on the B and C section will have a small red x appear at the pin. This means that you do not have to connect any of those pins as the common sections have already been assigned their necessary voltage values. For this reason there is not really a need to have to change the symbol to a 3-pin model.
Message 2 of 7
(7,431 Views)

Thanks Bhavesh,

this explains how the net lister sorts itself out. The only remaining confusion I have is where footprint pins seem to be used twice for different functions, eg pin 1 is both defined as a signal and a power pin because it is defined twice. I'm not sure I appreciate how this is resolved. I'm interested because I want to make sure that any parts I create follow what ever rule it is that says that "even though pin1 is a power pin and I've also described it as a signal you {the netlister} should infer that I want it to be a signal, not a power pin (even though I've defined it as one) because I've done ...." It's the "..." bit that I don't get. Of course it might well be a much bigger lump that I don't understand and I'm confusing myself no end 🙂

 

0 Kudos
Message 3 of 7
(7,425 Views)
Ian,
 
Can you give me an example of where you have seen such a footprint mapping issue (different types of symbol pins being linked to the same footprint). I have not seen this before, so I need to see the context in which this situation has been arising.
 
Thanks
Bhavesh
0 Kudos
Message 4 of 7
(7,419 Views)

Hi,

 

The LM3301 and the LM324 both have this. I've attached a pdf that shows what is confusing me as a screen cap.

 

Thanks

 

0 Kudos
Message 5 of 7
(7,415 Views)

Hi Ian,

What you are pointing out is an error in the footprint-to-symbol mapping for the component LM3301. If you were creating a custom component such as the LM3301N what you would want to do is have each of the quad packages to be tied to footprint pins 7 and 14 (which is what I believe made logical sense to you in the first place).

The reason that everything works out with the netlist in Multisim/Ultiboard despite this error is due to those symbol-pin designation of COM (common) which I described earlier. In later stages of the model creation (such as footprint-to-symbol mapping), the COM designation by default changes the other common pins to have the same footprint mapping as the first one that is defined. So in the footprint mapping page, once the VS1+, VS1- were assigned to 7 and 14, VS2+, VS3+ and VS4+ are automatically assigned to the same thing by Multisim once components are placed onto a schematic (regardless of what is written in the footrpint-to-symbol map). So essentially the error is automatically overwritten.

When you are designing any components you will want to avoid this issue by just assigning the symbol pins to the footprint pins as they should be (i.e. all VS+ to 7 and VS- to 14). If you need any further assistance in creating components please check out the following tutorial: http://zone.ni.com/devzone/conceptd.nsf/webmain/897FBC1CA3296F088625712B0034BEE9.

I hope this clears any confusion.

 

Thanks

Bhavesh

 

 

0 Kudos
Message 6 of 7
(7,407 Views)

Hi Bhavesh,

Now that makes all kinds of sense to me! Thanks for your assistance 🙂

 

Regards

 

Ian

 

0 Kudos
Message 7 of 7
(7,362 Views)