标签: parameter

我们知道在一些SI、PI等仿真软件中使用的电容的模型形式有分布RLC参数和S参数，这是两种很常用的model，当然你也可以使用子电路形式作为仿真的model，但是这种模型获得与赋予过程就较为复杂。那么RLC model和S参数model作为PDN decap model仿真存在什么区别呢？ 我们通过Simulation观察RLC模型和S参数模型运用于PDN的decap Z参数仿真的区别，使用murata的同一型号电容，采用S parameter和提供的元件库做一个Z参数分析的对比。

Is it true that men become curmudgeons as they get older? Anecdotal evidence suggests this is so. I see bits of it in myself, my friends, and the previous generation ( though I have observed that after 75 or 80 a lot of men mellow greatly ). For instance, for some time I've gotten increasingly impatient or worse with the behaviour of our elected officials. As one who writes it's hard not to express outrage in this or other forums about these issues. But this is not the place for political rants. It is, however, a reasonable place to express frustration with some approaches to engineering. A recent article I read about ultra-low power design contains this gem about CR2032 batteries: " A part of the coin cell's energy is exhausted through self-discharge; another part is not viable due to the increased source impedance near end-of-life. Both are assumed to take 20% of the capacity away. " Huh? Who assumes that? Why would an engineer base anything important on an assumption? If some critical parameter is an assumption, at the least cite chapter and verse so the thoughtful engineer can examine the evidence himself. The best engineers are pessimists. They assume one thing: everything will go wrong. That network of 5% resistors will all come in clustered at the worst possible end of the tolerance band. The transistor's beta will be just exactly at the datasheet's min value. The op amp's gain-bandwidth product will be lower than the rated min due to PCB parasitics. Datasheets in many cases are getting worse. Far too many list typical specs in lieu of min or max. If worst case is listed that's often just for extreme cases, like at some greatly elevated temperature. While that's important data, we need to understand how components will work over the range of conditions our systems will experience in the field. Firmware people should share the same curmudgeon-ness. The C language's sqrt() can't take a negative value, so it makes sense to check or guarantee the argument is legal. Weird stuff happens so we liberally salt the code with asserts(). We should use C's built-in macros to insure floating point numbers are, well, floating point numbers and not NaNs or some other uncomputable value. As for that assumption that "source impedance" and self-discharge account for 20% of the capacity, that's simply wrong. For almost a year I've been discharging CR2032s and have gobs of data points, which, are still being turned into meaningful information. In these ultra-low power applications coin cells don't behave like anything I have seen published. Everyone uses "internal resistance," rather than impedance, to describe their reduced ability to supply current as they discharge, but that's merely a proxy for some complex chemistry, since a load on the battery causes the voltage to continue to drop the longer the load is applied. The following chart in the figure shows experimental results on nine Panasonic CR2032s. All are from the same batch; all are from a very reputable, high-volume distributor (Digikey). The data—real, experimental results, not assumptions—are interesting and puzzling.   Figure: Experimental results on nine Panasonic CR2032s. What the heck is going on with battery five? It dies at half the rated capacity, mirroring the behaviour of a CR2025. But it is visually identical to the other eight, has the same markings, and is the same size. Is this just a dud or is it something we can expect? The batteries are being discharged at a 0.5 mAh rate so should die ( vendors rate "dead" at 2.0V ) at about 440 hours, though they do not specify what this means. Is it measured under any load? The charted data is the battery voltage about a millisecond after connecting a 10 mA load, which is probably a light load for an MCU which has woken up and is doing work. If there's any comm involved ( think the "Internet of things" ) expect much higher current levels, even if for just a very short period of time. Consider the internal resistances (IR). At the 300 hour point, well short of the 440 we expect, the average battery is at 2.5V with an IR of about 40Ω. Ultra-low current embedded systems can easily take tens of mA for a few ms when awake; if the system pulls just 25 mA ( 15 more than the 10 being pulled in the charted data ) the voltage will drop below 2.0 at 300 hours. The battery is effectively dead long before its rated capacity is used. Systems are getting extraordinarily complex. If we don't question our assumptions that gadget may be built on quicksand, sure to fail if our guesses prove to be incorrect. In this era of crowdsourcing it's easy to rely on hearsay—or Internet-say. But a question lobbed onto the net usually elicits a dozen conflicting answers, each of which is claimed to be authoritative. As Joe Friday didn't say : "Just the facts, ma'am."  

For some time now, I've been explaining how to implement and use virtual functions in C. 1, 2 I showed how to emulate a polymorphic C++ class (a class with at least one virtual function) as a C structure that has an additional member commonly called a vptr (VEE-pointer). The vptr points to a table of function pointers called a vtbl (VEE-table). Last November, I showed a way to initialise derived polymorphic objects. 3 My colleague, Miro Samek, posted a comment suggesting a slightly different approach. Last February, I explained the difference between the two approaches in detail. 4 I had originally planned to explain why I prefer my approach to Miro's. After some very helpful exchanges with Miro, I realised that my implementation doesn't have the interface that I'd like it to have. So this month I'm going back up a bit and present yet another variation on how to implement inheritance and virtual functions in C. Once again, my sample classes represent an assortment of two-dimensional geometric shapes such as circle, rectangle, and triangle, all derived from a common base class called shape. I recently suggested that the shape class should be an abstract class—one for which you can't, or at least shouldn't, create objects. 5 To simplify this discussion, I'll assume the shape class is not abstract. In C++, the shape implementation requires just a single class. In C, it requires two structures: one for the shape data members and one for the corresponding shape_vtbl. The C declarations for the shape "class" look like: // shape.h—a C base class for shapes ~~~ typedef struct shape shape; typedef struct shape_vtbl shape_vtbl; struct shape_vtbl { double (*area)(shape const *me); double (*perimeter)(shape const *me); }; struct shape { shape_vtbl *vptr; color outline, fill; }; void shape_construct(shape *me, color o, color f); double shape_area(shape const *me); double shape_perimeter(shape const *me); Each shape_vtbl member corresponds to a virtual function in the shape class. In this case, the shape class has two virtual functions: area and perimeter. It also has one non-virtual function: shape_construct, a constructor. The function declarations at the end of the header declare all of the shape member functions, even the virtual ones, as non-virtual functions. Each virtual function needs a non-virtual implementation so that the corresponding function pointer in the shape_vtbl has something to which it can point. In C++, every (non-static) member function in a class such as shape has an implicitly declared parameter named this whose type is "pointer to shape" or "pointer to const shape". A call such as ps-area() passes ps as the value of the area function's this parameter. C doesn't declare this parameters implicitly. In C, every shape "member" function needs an explicitly-declared parameter of type "pointer to shape". (In some cases, it's "pointer to const shape", but I won't belabor that anymore.) In the shape.h header, I declared that pointer as the first parameter of each member function. In my previous articles, I named those parameters s (for shape). I could have called them this, but then my code would not compile as C++. In his examples, Miro Samek called the pointers me. For this article, I've adopted his convention. Otherwise, this shape class is pretty much as I presented in previous articles. In C, each derived class, such as circle, requires two more structures: one for the circle data members and one for the corresponding circle_vtbl. The circle structure "inherits" the data members of the shape structure. That is, the initial portion of the circle structure should have all the data members in the same order as they appear in the shape structure. The simplest way to ensure this is to use "inheritance by composition"—to define a base class object as the first member of the derived class, as in: typedef struct circle circle; struct circle { shape base; // the base class subobject double radius; }; That is what I did in previous articles. The derived class vtbl (that is, the vtbl of the derived class) inherits all the members of its base class vtbl, and each inherited member must have the same offset in the derived class vtbl as it does in the base class vtbl. Miro suggested this is another opportunity to use inheritance by composition, as in: typedef struct circle_vtbl circle_vtbl; struct circle_vtbl { shape_vtbl base; // base class vtbl // virtual functions introduced in circle }; I didn't use inheritance by composition because it gives the me pointers in the derived class vtbl the wrong type. Rather, I defined each member of the derived class vtbl individually to correspond to the members in base class, as in: typedef struct circle_vtbl circle_vtbl; struct circle_vtbl { double (*area)(circle const *me); double (*perimeter)(circle const *me); }; In general, the me pointer for each member of a class C should have type "pointer to C". For example, the me pointer in each shape class member should have type "pointer to shape", and the me pointer in each circle class member should have type "pointer to circle", as in circle_vtbl above. C++ and other statically-typed object-oriented languages follow this rule for declaring this pointers or their equivalent. Declaring each me pointer to match its class type requires more effort than using inheritance by composition. You have to use what I call "inheritance by copying and editing". That is, you have to copy all the members from the base class vtbl to the derived class vtbl, and then change the me pointers from "pointer to base" into "pointer to derived". In the course of writing this article, I realised that I had defined the derived class structures circle, rectangle, and triangle using inheritance by composition. Consequently, the vptr member in each derived class had the wrong type. I should have used inheritance by copying and editing to give each "inherited" vptr its correct type. Rather than define the circle structure as: typedef struct circle_vtbl circle_vtbl; struct circle_vtbl { shape_vtbl base; // base class vtbl // virtual functions introduced in circle }; I now recommend copying the shape data members to circle, as in: typedef struct circle circle; struct circle { circle_vtbl *vptr; // copied and edited from shape color outline, fill; // copied from shape double radius; }; The vptr member copied from shape is declared as: shape_vtbl *vptr which isn't quite the right type for the derived type. I changed the declaration in circle to: circle_vtbl *vptr; which is exactly the right type. Such copying and editing arguably violates the DRY Principle (Don't Repeat Yourself). Should the base class change, keeping the derived classes in sync with the base class could be a maintenance headache. Nonetheless, I prefer using inheritance by copying and editing because it leads to type hierarchies with interfaces that look and act more like what C++ offers. Once you get past the initial hierarchy setup, such hierarchies are simpler and safer to use than what you get using inheritance by composition. I'll show you why in an upcoming column. I'll also show how you can use some simple macros that eliminate most of the code duplication. Thanks to Miro Samek, Steve Dewhurst, Ben Saks, and Joel Saks for their help with this article. Endnotes 1. Saks, Dan, "Implementing virtual functions in C++," Eetindia.com, April 2012. http://forum.eetindia.co.in/BLOG_ARTICLE_11885.HTM. 2. Saks, Dan, "Implementing virtual functions in C," Eetindia.com, August 2012. http://forum.eetindia.co.in/BLOG_ARTICLE_13544.HTM. 3. Saks, Dan, "Learn to initialise derived polymorphic objects," Eetindia.com, November 2012. http://forum.eetindia.co.in/BLOG_ARTICLE_14949.HTM. 4. Saks, Dan, "Ways to implement a derived class vtbl in C," Eetindia.com, February 2013. http://forum.eetindia.co.in/BLOG_ARTICLE_16330.HTM. 5. Saks, Dan, "The concept of pure virtual functions," Eetindia.com , December 2012. http://forum.eetindia.co.in/BLOG_ARTICLE_15551.HTM. 6. Hunt, Andrew and Thomas, David, The Pragmatic Programmer . Reading, MA: Addison Wesley Longman, 2000.