Presently, the device connectivity portion of the input file is added as a "cat" function where every single line of the device connectivity shows up as a line in the input file. Is there any hidden switch to change the behavior so that the device connectivity shows up as a single .include statement?
Not sure I understand what you're asking here, or even why it is important.
Please clarify your request, maybe with an example.
In reply to Andrew Beckett:
It's just a large duplication of information that already exists elsewhere.
For example, a simple testbench for a simple circuit produces an input.scs of over 400 lines (see truncated example below). Just imagine if this were a larger circuit and I was using extracted views. Jeesh!
--------------------------- First Example - Existing input.scs---------------
// Generated for: spectre// Generated on: Aug 13 15:02:09 2010// Design library name: test// Design cell name: tb_test_ckt// Design view name: schematicsimulator lang=spectreglobal 0parameters start_vdc=0.6 supply_r=1.2 start_delay=1n enable_delay=1n \ fin_time=1.5uinclude "/import/foundry/foundry_geom/pdk/datecode/../models/spectre/toplevel.scs" section=top_tt// Library name: test// Cell name: test_ckt// View name: schematicsubckt test_ckt enable_bar ibandgap vddr vref vssa MN0 (start1 n1 vssa vssa) nch_mac l=1.5e-07 w=9u multi=1 nf=9 \ sd=120.0n ad=4.75e-13 as=4.75e-13 pd=10.950u ps=10.950u \ nrd=0.031475 nrs=0.031475 sa=545.4200n sb=545.4200n sca=6.69814 \ scb=0.00508037 scc=0.000303349 sa1=170.94300n sa2=442.04300n \ sa3=735.1600n sa4=410.01400n sb1=170.94300n sb2=442.04300n \ sb3=735.1600n spa=117.68700n spa1=117.6400n spa2=117.04600n \ spa3=117.43400n sap=168.48100n sapb=194.36500n spba=163.57500n \ spba1=170.96400n enx=1.68175u enx1=1.58702u eny=558.400n \ eny1=390.97300n eny2=507.38900n rex=1.2283u rey=702.34300n \ sa5=589.32800n sa6=710.87200n sodx=80n sodx1=339.84200n \ sodx2=1.10182u sody=327.95200n dfm_flag=0 dw1=-1.33332e-20.. Many lines of netlist are truncated from here.. Just imagine what an extracted netlist might look like!. M16 (start2 start1 vssa vssa) nch_18ud15_mac l=300n w=1u multi=1 nf=1 \ sd=180.0n ad=7.5e-14 as=7.5e-14 pd=2.15u ps=2.15u nrd=0.09 \ nrs=0.09 sa=75.0n sb=75.0n sca=9.21917 scb=0.00603396 \ scc=0.000304546 sa1=75.0n sa2=75.0n sa3=75.0n sa4=75.0n sb1=75.0n \ sb2=75.0n sb3=75.0n spa=100n spa1=100n spa2=100n spa3=100n \ sap=91.97760n sapb=114.44400n spba=130.0n spba1=144.22200n \ sa5=75.0n sa6=75.0n enx=800n enx1=800n eny=596.43500n \ eny1=392.79900n eny2=507.38900n rex=938.73400n rey=754.77100n \ sodx=80n sodx1=140.45700n sodx2=763.6600n sody=327.95200nends test_ckt// End of subcircuit definition.// Library name: test// Cell name: tb_test_ckt// View name: schematicV0 (net2 0) vsource dc=supply_r type=dcV1 (enable_bar 0) vsource dc=0 type=pulse val0=supply_r val1=0 period=1 \ delay=enable_delay rise=100p fall=100p width=800.0mV3 (start 0) vsource dc=start_vdc type=pwl wave=[ \ (enable_delay+start_delay) 0 fin_time start_vdc ]x0 (enable_bar start net2 out 0) test_cktsimulatorOptions options reltol=1e-3 vabstol=1e-6 iabstol=1e-12 temp=27 \ tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 maxnotes=5 maxwarns=5 \ digits=5 cols=80 pivrel=1e-3 sensfile="../psf/sens.output" \ checklimitdest=psf modelParameter info what=models where=rawfileelement info what=inst where=rawfileoutputParameter info what=output where=rawfiledesignParamVals info what=parameters where=rawfileprimitives info what=primitives where=rawfilesubckts info what=subckts where=rawfilesaveOptions options save=allpub
Now if the connectivity were just included since it already exists in the netlist file (yes, it's just named netlist, no extension)
------------------------- Second Example - Desired input.scs---------------
// Generated for: spectre// Generated on: Aug 13 15:02:09 2010// Design library name: test// Design cell name: tb_test_ckt// Design view name: schematicsimulator lang=spectreglobal 0parameters start_vdc=0.6 supply_r=1.2 start_delay=1n enable_delay=1n \ fin_time=1.5uinclude "/import/foundry/foundry_geom/pdk/datecode/../models/spectre/toplevel.scs" section=top_tt////// Just do an include of the netlist file to get all the connectivity//include "$HOME/path/blah/blah/simulation/tb_test_ckt/spectre/netlist"//simulatorOptions options reltol=1e-3 vabstol=1e-6 iabstol=1e-12 temp=27 \ tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 maxnotes=5 maxwarns=5 \ digits=5 cols=80 pivrel=1e-3 sensfile="../psf/sens.output" \ checklimitdest=psf modelParameter info what=models where=rawfileelement info what=inst where=rawfileoutputParameter info what=output where=rawfiledesignParamVals info what=parameters where=rawfileprimitives info what=primitives where=rawfilesubckts info what=subckts where=rawfilesaveOptions options save=allpub
That's less than 30 lines! Easy to read and understand without all the nitty gritty details of the devices.
Now do you understand? Is this possible through any existing settings?
In reply to SharksFan:
OK, I understand. No, I don't believe this is possible right now. In fact the "netlist" file could also be includes of the appropriate cellView level files from the ihnl directory.
Please contact customer support, and then an enhancement request can be filed.
I was just looking for the very same feature - an enhancement would be very appreciated! I'd even go one step further and ask for an option to create one file per subcircuit. The netlist files are, especially for designs with a lot of ports (like sig<1> sig<2> ... sig<128>), pretty much messed up and hardly readable.
Off topic: or is there maybe a way to tell the netlister not to chop up busses in the schematic and use something like sig<1:128> in the netlist directly?
Thank you for the reply, Andrew. When you say "contact customer support", do you mean I should open a service request? Or is there another manner in which enhancement requests are handled? Since you understand the desired enhancement, any chance you could file the enhancement request since you work at Cadence? No harm in asking is there? :-)
The best way to get an enhancement request entered is through customer support as Andrew has recommended - this way the request is for a specific customer and is treated more favourably than a request that appears to only come internally from a Cadence employee without any specific customer details. Sometimes customers working with on-site field engineers have enhancements entered on their behalf without directly going through customer support, but in these cases a service request is created so that the customer can still have visibility of the issue and progress in COS (Cadence Online Support).
Indeed, there is no harm in asking, but I think that filing a Service Request would be in your best interests, and perhaps reference this conversation in case the engineer was not aware of it.
Phil, if you have the same request, even better - if you also file an SR and ask for the same enhancement, that's elevated the visibility of the issue due to customer demand. Also, for your bus related question, I'm afraid I don't know; perhaps starting a new thread would be a good way to get others to look at and respond to the question?
In reply to skillUser:
What Lawrence says is true. Also, this forum is not an alternative to customer support - whilst I work for Cadence, my role is to deal with customers in my region and work as one member of a larger team - having to take on enhancement requests coming in from worldwide users via the forum would take more than the limited bandwidth I have (I'd have to prepare testcases, and outline in detail the benefit, and so on, and then follow it through with R&D). I do this Forum work as a spare-time activity (it's not part of my job).
This is precisely what customer support is for. It allows us to get true information about customer demand to resolve specific bugs and to implement specific features - whereas I have no idea who you are or how much impact such an enhancement would have in your company.
As for Phil's request - I don't think it makes any sense unless the simulator itself was capable of understanding bus syntax. If the simulator (and most SPICE-like simulators fall into this category) do not have the concept of a bus (all nets are scalar) then that would need addressing first - then we could add the capability of netlisting buses as buses.
Thanks to both of you for your comments on my issue. Andrew, you are right, the simulator I am using (eldo) does indeed not support this way of referring to enumerated nets (sig<1:128> instead of sig<1>, ... <sig128>). Instead it considers sig<1:128> a name for one single net, so forget about my proposal :-(