<Wanda[cis]>
<gatecat[m]> "literally corners? ;)" <- oh hey did you know there's dedicated routing from the SPI/I2C IP to particular pre-assigned IOs? the "ENABLE" bits icestorm mentions for them are actually the bits the disable the dedicated paths and switch to fabric routing
mupuf-soju has quit [Remote host closed the connection]
mupuf has joined #prjunnamed
h_ro has quit [Ping timeout: 272 seconds]
sajattack[m]1 has joined #prjunnamed
<sajattack[m]1>
Dumb question but when a parent module defines a verilog parameter for a child module and they're in different source files how do I tell yosys the child module's parameter isn't undefined
<whitequark[cis]>
wrong channel?
<sajattack[m]1>
I guess. Just looking for people with experience using yosys and didn't get an answer on 1b2 and afaik prjunnamed uses yosys' json format or something
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #prjunnamed
micko has joined #prjunnamed
jn has quit [Remote host closed the connection]
jn has joined #prjunnamed
jn has quit [Remote host closed the connection]
jn has joined #prjunnamed
jn has quit [Ping timeout: 252 seconds]
jn has joined #prjunnamed
jn has joined #prjunnamed
jn has quit [Ping timeout: 260 seconds]
micko has quit [Quit: Client closed]
micko has joined #prjunnamed
micko has quit [Ping timeout: 240 seconds]
leocassarani[m] has quit [Quit: Idle timeout reached: 172800s]
jn has joined #prjunnamed
jn has joined #prjunnamed
Guest86 has joined #prjunnamed
Guest86 has quit [Client Quit]
LeoC has joined #prjunnamed
LeoC is now known as leo_cassarani
leo_cassarani has quit [Client Quit]
<mei[m]>
in documentation, how do I concisely distinguish between the mode of synthesis with and without a target specified (context: "Name cells will be removed anyway if you specify a target")
<mei[m]>
I guess I could say just that, but having a proper name for this would probably elucidate why that is the case
<whitequark[cis]>
"target-independent" and "target-dependent"?
<mei[m]>
currently target-dependent also implies that out the other way comes a bitstream, right?
<whitequark[cis]>
i... don't think so?
<whitequark[cis]>
it just means that it depends on knowing the taret
<whitequark[cis]>
s/taret/target/
<whitequark[cis]>
like, on the face of it that's what the term says
<mei[m]>
ah, i see. i made an unfounded logical leap. so the fact that target-dependent synthesis kills Name cells is kind of... random? or, rather, it tries to approximate some other condition?
<whitequark[cis]>
it doesn't actually kill them any more
<whitequark[cis]>
well, it transforms them into Debug cells
<whitequark[cis]>
but yes, I should go into more detail on this
<Wanda[cis]>
(note that it's unclear there's any use for synthesis without a target other than testing; we may want to expose it only under a test subcommand in the future, sort of like LLVM's opt)
<whitequark[cis]>
we do not make an apriori assumption of what the netlist is going to be used for when reading the netlist. possible options include "synthesis for siliconblue", "synthesis for [redacted]", or "cxxrtl"
<Wanda[cis]>
(there is use for doing other things without a target, though, such as simulation or Verilog output)
<whitequark[cis]>
synthesis for an FPGA only requires computing the values of primary outputs (output cells). optimization for cxxrtl requires computing the values of all named nets
<whitequark[cis]>
* synthesis for an FPGA only requires computing the values of primary outputs (output cells). optimization for cxxrtl requires computing the values of all named nets (output but also name cells)
<whitequark[cis]>
synthesis also benefits from (nextpnr shows you slightly more legible timing reports) retaining the names of intermediate nets, but dropping them is preferred to computing them without need (since it conserves resources)
<whitequark[cis]>
so instead of adding a parameter to Design::from_str (or the frontend or Yosys JSON import or whatever) we use the unname pass
<whitequark[cis]>
in general i dislike having "contexts", "global settings", and the like when the same things could be achieved by a transformation in a single place
<whitequark[cis]>
"composition over configuration" if you will
<whitequark[cis]>
there's this cute choice of even having impl FromStr for Design which constraints it to "it is absolutely impossible to pass any configuration parameters to the primary entry point to the parser" (yes, we do have crate::parse also, but.)
<whitequark[cis]>
* there's this cute choice of even having impl FromStr for Design which constraints it to "it is absolutely impossible to pass any configuration parameters to the primary entry point to the parser" (yes, we do have crate::parse also, but. it's mostly for testing anyway)
<whitequark[cis]>
and i think this choice is actually useful in that it prevents a Context struct from existing
<whitequark[cis]>
<sajattack[m]1> "I guess. Just looking for people..." <- see #yosys:matrix.org
<whitequark[cis]>
so looking closer at this doc, i feel like there's two things that are in tension
<whitequark[cis]>
there is explaining what something is (reference documentation), which is what i think should go into the doc comments; it is the source of truth for the netlist semantics as it is encoded
<whitequark[cis]>
and then there is explaining what something is used for (guide documentation), which is what should go into our equivalent of LangRef.html
<whitequark[cis]>
basically, someone writing a frontend (plausibly in a different language) should not be expected to dig in the depths of rustdoc
<whitequark[cis]>
also the netlist crate is intentionally decoupled from the uses of the netlist, such as synthesis, so i guess rust not allowing links into a dependent crate is kind of just reflecting that reality here
<whitequark[cis]>
i do think it is worth thinking about starting a langref.md; i am currently making some updates that will bring the text netlist format closer to its final form
<whitequark[cis]>
i propose that once i finish that i create an mdbook under docs/ or book/ or something and we put the guide-level information there
<whitequark[cis]>
whereas the crate will only describe the validity invariants and other such technical info
<whitequark[cis]>
* the crate docs will only
<whitequark[cis]>
or to summarize in a few words: i think the netlist crate docs is not the right place for explaining how synthesis/simulation flows work in general
<mei[m]>
yeah, feel free to migrate the documentation to whereever, i merely started with rustdoc because that didn't involve making a tooling choice or setup friction