https://open-source-silicon.dev logo
Join Slack
Powered by
<@U01732WNM60>: The `code_shown.sym` box needs to...
# xschem
t
@User: The 
code_shown.sym
box needs to be updated to reflect the fact that xschem can use variable names for the PDK path. It should be 
.lib \\$::SKYWATER_MODELS\\/sky130.lib.spice tt
and the include line for the standard cell library should be similar.
c
Thanks!! I've been trying things in this direction already, but I'm still having difficulties. With several reinstallations of OpenLane and sky130, I have several 
sky130.lib.spice
and 
sky130_fd_sc_hvl.spice
versions to choose from. What's the intended path, after OpenLane 
make native-full-pdk
? Can you make your implicit assumptions where (i.e. at what level in the file hierarchy) 
SKYWATER_MODELS
and 
SKYWATER_STDCELLS
are supposed to point explicit? Are the escape character and variable substitution rules identical in 
code_shown.sym
and 
code.sym
? I stil have "File not found" problems where there shouldn't be any.
@Tim Edwards, you made the undocumented implicit assumption that the 
code_shown.sym
includes the line (which isnt' shown in the schematic): 
format="tcleval( @value )"
, without which the substitutions won't work, no matter how the backslash character needs to be escaped (which is also an undocumented implicit assumption). It seems that I'm getting there, but this interplay of undocumented implicit assumptions at different levels of abstraction from the actual silicon that matters leads to the question: What does it take to implement an analog design on mpw3 that avoids these abstraction layers altogether, i.e., that treats anything in the caravan frame except the dedicated analog I/O pads, which is susceptible to undocumented mutual side effects of a deep stack of abstraction layers, as dead silicon?
t
SKYWATER_MODELS
and 
SKYWATER_STDCELLS
are defined in 
xschemrc
which after an open_pdks installation can be found in 
libs.tech/xschem/
. The problem is what to do with the 
xschemrc
file; a symbolic link to it would be hard-coded to the open_pdks install path, and copying it to the local directory would just mean that the definitions in it are hard-coded to the open_pdks install path. The best solution, which is being used by some tools like 
magic
and 
openlane
is to assume an environment variable 
PDKROOT
or 
PDKPATH
(
PDKROOT
is defined as the directory level above 
PDKPATH
), but not to assume that it is defined; to set those environment variables by default to the local installation of the PDK, but to always allow them to be overridden by the OS environment. So that to work with anybody else's project imported into your own local environment, all you need to do is to 
export PDKPATH=
. Given that SPICE netlists are not design-level files, ngspice shouldn't have to follow this methodology, but xschem should. Since 
xschemrc
is just Tcl, I guess it just needs a more sophisticated way of setting 
SKYWATER_MODELS
and 
SKYWATER_STDCELLS
that is like the one used in 
sky130A.magicrc
, which would be
Copy code
if {[catch {set PDKPATH $env(PDKPATH)}]} {
   set PDKPATH "/usr/share/pdk/sky130A"
}
set SKYWATER_MODELS $PDKPATH/libs.tech/ngspice
set SKYWATER_STDCELLS $PDKPATH/libs.ref/sky130_fd_sc_hd/spice
where the hard-coded 
/usr/share/pdk/sky130A
in the above is generated by open_pdks at install time. That way, no matter how a project is set up, it should work if you do 
export PDKPATH=
to point to your local install of the PDK. I need to make this change both in open_pdks and in caravel_user_project_analog.
Okay, I just pushed a change to the caravel_user_project_analog repository that should make the xschem schematics in that project friendlier to local variations in the open_pdks install. You just need to have 
PDKPATH
defined in the environment if sky130A is installed somewhere other than 
/usr/share/pdk/sky130A
. I still need to correct the open_pdks repository, but since the caravel user project has its own copy of 
xschemrc
, it wouldn't be affected by that.
y
@Christoph Maier I would suggest that if you are unhappy with the documentation that you take everything you've learnt and formalise so others can use it in the future. People like stefan do this with no renumeration for their hard work - if you see areas for improvement then please help him
c
@yrrapt, one big problem when adding documentation is that even if my documented solutions are workable, they are not necessarily compatible with the tools in the entire stack of the design kit, and it would only add to the overabundance of existing incomplete, slightly incompatible, recipes how to get things working. There's a huge difference between a patch that fixes one problem (with a rat's tail of unforeseeable side effects), and a consistent solution. Ah well. As a former postdoc of Gert Cauwenberghs, maybe I should collaborate closely with his first PhD on this.
s
@Tim Edwards since xschemrc is just a tcl file any tcl expression can be used. The same check for an environment variable (if existing) can be done there as done in magic ($env(...) ) Should we add a similar expression in xschem_sky30's xschemrc?
@Christoph Maier I understand the frustration, since i several times got into similar sinkholes. In some cases there are too many levels of indirection (variables, expansions and so on). Moreover each tool has its own substitution mechanism. The bash shell has variables, tcl has variables, xschem itself has a mechanism for variable substitution, to enable parametric symbols. In some cases this leads to the "escape nightmare", where escaping or quoting is needed to protect some special characters (notably $, ", space and other). To reduce the size of the black hole try removing some variables and hardcode paths, see if that solves. Of course i am open to change the way schematics locate model files. Currently the idea is to place a 
code.sym
block (or 
code_shown.sym
, they are equivalent, latter one shows the 
value
string in schematic), this has a value attribute that is dumped verbatim to the netlist. Xschem components can have any number of 
attribute=value
assignments, for example a code block has a 
name
attribute (just a unique ID in the design) and a 
value
attribute. You can edit the whole attribute string, however note that some special characters must be escaped , like in: 
name=s1 value=".control
.tran 1n 100n
plot v(\"data[4]\")
.endc"
the quotes in the plot line must be escaped to avoid interpreting them as a close quote of the value attribute. However you can set the 
Edit Attr
selector to '`value`' in the edit attributes dialog and you will be editing the part inside the quotes of the value attribute. if you write quotes xschem will do the escaping automatically. In the picture you see an example. Why is the $ character escaped? because $ is used internally by xshem to do parameter substitution. If a component has a 
foo=bar
attribute and the symbol has 
$foo
in the 
format
attribute (format specifies what goes in the netlist) the 
$foo
becomes 
bar
. However if 
format
string contains 
\$foo
then netlist will contain 
$foo
. Moreover in the picture the component redefines `format`: the symbol default is 
format=@value
, meaning the 
value
attribute goes directly in the netlist. The redefinition specifies 
tcleval(@value )
so before putting 
value
in the netlist the whole string is evaluated by the tcl interpreter. So if 
$foo
is encountered it is replaced with the value of the 
foo
tcl global variable. you have seen xschem has 2 substitution characters, $ and @. 
$foo
expands to 
bar
if instance has a 
foo=bar
attribute or just 
foo
if no such attribute assignment is found. 
@foo
expands to 
bar
if instance assigns it to 
bar
or the empty string if no such assignment exists. When a 
code.sym
block has the right attributes set and the final netlist has the right .lib /.include statements for ngspice to find spice models, you should just copy/paste this instance in all designs you work with. This is a bit of xschem internals to understand how the assignments in the dialog shown in picture work. In this case the 
SKYWATER_MODELS
global tcl variable is expanded by tcl. This variable is set in the xschemrc init file, typically. As a result of all this mechanisms if user A creates a schematic and sends this schematic to user B (together with all custom symbols and sub-schematics if any) User B should be able to simulate the design without any changes, provided he sets the correct paths in his 
xschemrc
file.
c
@Stefan Schippers, @Tim Edwards (and probably @Tim 'mithro' Ansell), interfacing problems and side effects of a deep tool chain are to be expected and probably inevitable. However, the recommended remedy "look at a slack discussion that only shows the latest 10000 messages for a solution to your problem" aggravates the problem, because the SNDR of useful information [where distortion = suggested workaround of a competence boundary problem between any two tools without due consideration of crosstalk and side effects between all of the other tools involved] deteriorates pretty much with the factorial of people of all sorts of skill and experience levels in the discussion. I'm about as fiercely anti-authoritarian as anyone can be and not get completely excommunicated from the analog/mixed signal IC design community (ask Gert), but I think you principal authors should set up a separate, authoritative discussion more permanent than slack and more free software (in the full Stallman sense) than Google docs, wherein • you discuss compatibility issues, • only you have full write/merge/push access, • and welcome but curate contributions from anyone who are not a core developer. This will add some latency to the signal (workable solutions with minimal unforeseen side effects) but hugely reduce noise and distortion (workarounds by contributors lacking sufficient knowledge to avoid unnecessary side effects). Just some unsolicited advice from a Fly On The Wall at the Ivy League in the most Nobel house of all Tübingen...
For starters, a concise list of all path variables you're using would be extremely helpful: While @Tim Edwards is introducing path variables to make local installation issues more manageable, @Stefan Schippers just suggested that I should use absolute paths instead of variables as local fix to my problems.
s
@Christoph Maier using absolute paths is not a solution, but may help when debugging a problem, by removing some indirection.
c
All discussions aside, tonight I'll try to open 
user_analog_proj_example.mag
and 
example_por.mag
in 
caravel_user_proj_analog/mag
. On schematic level (no corner or Monte Carlo analyses yet), 
xschem
and 
ngspice
already play nicely with each other, so @Stefan Schippers, you're already a part of the solution, not the problem 😉
s
@Christoph Maier @Tim Edwards I agree there can be a more unified approach across the various tools. We can for example all rely on shell env variables, instead of tcl/python/whatever other environment each tool uses. I think xschem can easily be adapted to do this. Please let me know, It's better to make these changes sooner than later . @Tim Edwards If you need i can update/change the xschem_sky130 symbol libraries (and xschem itself if needed) once we define a unified approach for pdk file lookup.
c
The fewer people have a say in the matter of a unified approach, the better. Which is why I was suggesting that you core developers have a discussion among yourselves, with everyone else being read-only.
9 Views
Open in Slack
PreviousNext
Powered by