Re: disallow distributed switch branches

From: Kevin Cameron <kevin_at_.....>
Date: Fri Apr 20 2007 - 10:27:48 PDT

Geoffrey.Coram wrote:

Kevin Cameron wrote:
  

The reason for having OOMR voltage contributions being in series is
consistency with the rest of the language. Why should the rules be
different for out-of-module-references than for in-module-references?

      

I think you are just avoiding my question on justifying the behavior
being different depending on how you wire things up. I'd ask the
question: why should in-module behavior be different from multi-module
behavior, and hence why should OOMR behavior be different from that.
    

In-module behavior is already different from multi-module behavior:

module A(a,b);
  inout a,b;
  electrical a,b;
  analog begin
    V(a,b) <+ 5.0;
    V(a,b) <+ 6.0;
  end
endmodule

module B(a,b);
  inout a,b;
  electrical a,b;
  vsine #(.dc(5)) v1 (a,b);
  vsine #(.dc(6)) v2 (a,b);
endmodule
  

Yes, but I'm discussing the case where A is:

module A(a,b);
  inout a,b;
  electrical a,b;
  analog V(a,b) <+ 5.0;
  analog V(a,b) <+ 6.0;
endmodule

This is an argument about the semantics when inlining submodules.

Whether module B can be simulated in a particular simulator is beside the point. (Ken and I will avoid simuluators that allow it, because we think it's a bad idea; you will use them, so you can model parallel switches.)  You get 11 for A and something else (an error, 5.5, ...?) for B.
  

The idea is to create a *standard* that works properly and everyone adheres to.

Bear with me a little on this example:

module base(a,b);
  inout a,b;
  electrical a,b;
  branch (a,b) Ibr;
  analog I(Ibr) <+ 5.0;
endmodule

module augmentor();
  analog I(top.mybase.Ibr) <+ 6.0;
endmodule

module iprobe();
  analog $strobe("I = ", I(top.mybase.Ibr));
endmodule

module top();
  electrical n1;
  ground gnd;
  resistor #(.r(1k)) R1(n1, gnd);
  base mybase(n1, gnd);
  augmentor aug1;
  iprobe probe1;
endmodule

The OOMR probe in iprobe really must be sensing the current in that branch "Ibr"; it would be non-sensical for the probe to somehow create a new branch in parallel and sense that (zero) current.  Hence, the OOMR contribution in augmentor *must* add 6.0 to the 5.0 already on branch "Ibr" in instance mybase module base, not create a new branch in parallel for the contribution.  Here we had no problems with v-sources in parallel.  

Now let's switch all the I's to V's (access functions and Ibr->Vbr).  Again, I would maintain, the augmentor adds 6.0 to the 5.0 already on Vbr, and the $strobe prints V = 11.0.
  

OK, you make a good argument for the current sensing OOMR to a branch being in series if all it is doing is measuring, and therefore if you contribute to it you would expect the current to add into that branch. However, in the case of flow the contribution would add in either semantic so it's a moot point.

If the OOMR is a Voltage probe then you would expect it to be measuring the voltage across the branch - i.e. it's in parallel. If you then say that a potential contribution to the branch is in series it looks a little in consistent to me. I'm not saying you can't define it that way, just that it doesn't make that much sense to me since the process doing the probing is a separate analog block it should obey the inter-module rules (same as connection by port).

My recommendation (as before) is that if you want the summing behavior for a specific branch between analog blocks I would make it explicit. In this case I would suggest modifying the operator to (say) "<++" i.e.:

     analog V(top.mybase.Ibr) <++ 6.0;

That would also work for multiple analog blocks in a module.

In an earlier message, you (Kev) wrote:

  

Contributions from analog blocks in different modules are in parallel 
for potential and flow - thats the way it has always been. I'm just 
asking for that behavior to apply consistently.
    

and I'm saying these contributions are *not* in parallel.
  

I presume you mean OOMRs specifically?

Kev.

-Geoffrey
  

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri Apr 20 10:28:06 2007