I have a sample combinatorial circult in Verilog where I can follow the instruction to do logic synthesis and generate blif file.
However, what I need is to generate the CNF formula out of the circuit. Tools such as ABC only allows to generate from combinatorial miter (i.e., with 1 output).
I tried the yosys instruction "sat -dump_cnf FILE", and indeed I am able to generate a CNF file. However, I am not sure how to map variables in the CNF with I/Os in the circuit.
Have anyone studied the feature "sat -dump_cnf" from Yosys and can give me a pointer?
Related
I'm running many linear regressions and probit models with a massive number of covariates. That means, every time Stata finished to compute and print the results, produce a huge list of coefficients. And, each time I have to move until the beginning of such a list, where the main coefficients are printed.
I would like to know if there is a way to avoid that. I was looking for an option to print only a certain number of lines. My sencond try was running the regression using -quietly- option and then trying to print a given number of lines. But I'm not really familiar with Stata. I usually work in R, but I have to use Stata this time, that's why I'm struggling with this commercial software.
For linear regressions the -areg- function offers a partial solution for my issue, but that function only allows me to "absorb" a single factor variable. But I need to absorb more variables and also run probit models. Hence, -areg- don't work to me.
Anyone has a trick to solve this? Only print a selection of covariates in Stata?
UPDATE:
A minimal example: I have the following linear regression with many places and time units as FEs.
regress depVar Var1 Var2-Var15 i.place i.time [pw = myweigth], cluster(ID)
I'm interested on see only the coefficients of Var*. But every time I run the regression I got thousands of coefficients for the FEs.
I posted the same question on reddit, and I got the following comments:
https://www.reddit.com/r/stata/comments/fwtds4/cutting_down_stata_results/
What is pretty much what I was looking for. Basically, is solved via estout package, and its -estout- and -esttab- functions:
estout myRegression: quietly ///
regress depVar Var1 Var2-Var15 i.place i.time [pw = myweigth], cluster(ID)
esttab myRegression, drop(place time)
Maybe someone can enrich this approach. Thanks!
I met an error during initialization when using ThermoSysPro library.
It seems like the Turbine5.Pe is larger than Turbine2.Pe, so the result is negative. but I checked my parameters, there shouldn't be such a problem.
Is this because the nonlinear solver couldn't solve the equation in the following picture?
There is not enough information and I would recommend to set Details and/or Nonlinear iterations in Simulation setup>Debug>Nonlinear solver diagnostics to get more information.
The full expression causing the problem is sqrt((Turbine2.Pe^2-Turbine5.Pe^2)/(Turbine2.Cst*Turbine2.proe.T))
Since the two Pe-values have fixed=true it seems unlikely that they are wrong, but it is impossible to see without the complete model.
However, it is also possible that either Cst or proe.T is negative, or computed to a negative value based on other values.
Without a complete model that is impossible to tell.
According to the comparison between ThermoSysPro(Open source library from EDF https://github.com/alex19941215/ThermoSysPro ) and ThermalPower(Commercial library from Modelon https://www.modelon.com/library/thermal-power-library ), there should be some inspiration for people faced with the same situation.
Here is the code form ThermoSysPro library:
Connectors.FluidInlet Ce
Connectors.FluidOutlet Cs
Here is a type code from Thermal Power library:
Interfaces.FlowPort feed(
h_outflow(start=hstartin))
Interfaces.FlowPort drain(
p(start=pstart),
h_outflow(start=hstartout))
From the code, we can see that in the Thermal Power library each connector's attribute is assigned values according to the parameters, but in the ThermoSysPro library, the connector is using default values, probably zero. So that's why the Thermal Power library has better performance in the term of initialization convergence
I've had to create the Simulink Diagram after this picture:
My answer is this one:
I've gave some values to a, b and c (like 3, 4 and 5), but when I try to run it, it gives me the following warning:
Warning: The model 'ex2_2' does not have continuous states, hence Simulink is using the
solver 'VariableStepDiscrete' instead of solver 'ode45'. You can disable this diagnostic by
explicitly specifying a discrete solver in the solver tab of the Configuration Parameters
dialog, or by setting the 'Automatic solver parameter selection' diagnostic to 'none' in the
Diagnostics tab of the Configuration Parameters dialog
Warning: 'ex2_2/Unit Delay' is discrete, yet is inheriting a continuous sample time; consider
replacing unit delay with a memory block. When a unit delay block inherits continuous sample
time, its behavior is the same as the memory block. Unit delay block's time delay will not be
fixed and could change with each time step. This might be unexpected behavior. Normally, a
unit delay block uses discrete sample time. You can disable this diagnostic by setting the
'Discrete used as continuous' diagnostic to 'none' in the Sample Time group on the
Diagnostics pane of the Configuration Parameters dialog box. "
and the output (scope) it's just a step signal...
I don't know where I'm wrong here.
You've built the model correctly, but did not configure it correctly.
When running the model as-is, what will happen is the following:
The Step block is a continuous-time source by default (it's Sample Time setting is 0).
Simulink sees that the Step is connected to the Unit delay block, which is guaranteed to have constant output during minor steps (unlike Memory blocks)
According to the documentation on sample times:
[...] Simulink sets [Fixed-in-Minor step] as either an inherited sample time or as an alteration to a user specification of 0 (continuous). This setting is equivalent to, and therefore converted to, the fastest discrete rate when you use a fixed-step solver.
Continuous sample time degrades to Fixed-in-Minor-Step rather than Discrete-time in the context of Variable-step solvers. Variable step size is used to speed up simulations (larger steps are taken when accuracy allows it), but requires trickery to compute, for example, the exact time at which the step triggers (the "Enable zero-crossing detection" tick box in the Step block's options). So, Simulink's best way forward in this particular situation is to convert the sample time of the Step block into Fixed-in-Minor-Step, which is propagated forward and inherited by all other blocks in the model.
This is usually an awkward type of sample time, which is effectively not continuous-time, but still seen by all blocks as such. Therefore, the inherently discrete-time Unit delay will complain about being driven by a continuous-time signal (your 2nd warning), and Simulink itself will complain about the complete lack of "real" continuous-time blocks anywhere, while being instructed to use a continuous-time solver, ode45 (your 1st warning).
As usual in software development: it's always best to be explicit, about everything. In this case, the simplest way out of this is to explicitly specify a discrete-time, fixed-step solver in the model configuration dialog. That way, the continuous-time from the step will be automatically converted into discrete-time for the Unit delay.
The block diagram you want to implement is a discrete-time system. Since there are no Ordinary Differential Equations (ODE) but only their discrete counterpart (Finite-differences equations), you do not need an ODE solver as the warning 1 points out.
In discrete-time systems you have to specify your sample time in order to approach to a continuous-time representation where every single instant t is built up by the discrete integer n and its progressions (n+1, n+2, and so on) as t = nT where T is your sample time; Simulink basically expects that you respect this kind of logic, then asks for a sample time. By default Simulink sets it variable which may lead the result "out of track". This is what the warning 2 points out.
Solution: In the 'Model Configuration Parameters' menu, at the Solver tab, set 'Fixed-Step' as Type. The pane will change with a field related to the sample-time (Fixed-step size); set then a Sample time in seconds different than "auto" (e.g. 0.01). This will solve the warning 2. Still in the Solver menu, set also 'Discrete (no continuous states)' instead of any other useless solver. This will solve the warning 1.
I wonder if there a way to "debug" a modelica code, I mean debugging the code line by line and you can see how variables change, things like that?
I know that the modelica code is translated into C, I just want to know if there's a possibility to do that somehow, if there is, I believe it's gonna be a great improvement for any of the simulation environments. Thanks.
HY
This is a good question and it comes up a lot. But first, let's step back for a second.
The idea of debugging "line by line" is something comes from imperative programming languages. By "imperative" I mean that a program is simply a sequence of instructions to be carried out in the specified order.
When someone debugs Java or Python, this "line by line" approach makes sense because the statements are the fundamental way behavior is represented. This "line by line" approach could also be extended to modeling formalisms like block diagrams (e.g. Simulink) because, while graphical, they are also imperative (i.e. they constitute steps to be carried out in a specified order).
But Modelica is not an imperative language. There is no notion of steps, statements or instructions. Instead, we have omnipresent equations. So thinking linearly about debugging doesn't work in Modelica. It is true that you could think about debugging the C code generated from Modelica, but that is typically not very useful because it bears only a partial resemblance to the equations.
So how do you debug Modelica code? Well, debugging Modelica code is really debugging Modelica equations. Normally, Modelica models are composed of components. The equations that are generated when components are connected are automatically generated so lets stipulate that the Modelica compiler generates those correctly. So what's left is the equations in the component models.
The simplest way to approach this is to test each component individually (or at least in the smallest possible models). I often say that trying to debug Modelica components by throwing them all together in a big model is like listening to an orchestra and trying to figure out the one instrument that is out of tune. The fact that these equations in Modelica tend to form simultaneous systems of equations means that errors, when they occur, can propagate immediately to a number of variables.
So your best bet is to go through and create tests for each individual component and verify the behavior of the component. My experience is that when you do this, you can track down and eliminate bugs pretty easily.
Update: You shouldn't need to add outputs to other people's component models to debug them. An output can be created at any level, e.g.
model SystemModel
SomeoneElsesComponent a;
SomeOtherGuysComponent b;
end SystemModel;
model SystemModel_Debug
extends SystemModel;
output Real someNestedSignalFromA = a.someSubsystem.someSubcomponent.someSignal;
output Real someOtherNestedSignalFromB = b.anotherSubsystem.anotherSignal;
end SystemModel_Debug;
Of course, this becomes impractical if you have multiple instantiations of a signal component. In those cases, I admit that it is easier to modify the underlying model. But if they make their models replaceable, you can use the same trick as above (extends their model, add a bunch of custom outputs and then redeclare your model in place of the original).
There is a transformation debugger in OpenModelica now. You can find here which variable is evaluated from which equation.
Matlab Coder is a recently released MathWorks product. My understanding is that it is a Matlab-to-C compiler with the biggest advantage over previous solutions being that the resulting program does not need to be linked against a Matlab shared library.
Can someone with access to this product confirm the above? What are the dependencies of the translated programs and what kind of performance are we talking about? Also I would really like to see some example outputs, to know if the resulting C programs can be understood and improved without access to the Matlab source.
If done right this could be very powerful, allowing rapid prototyping in Matlab and instantaneous conversion to C when things are getting serious. I kind of whish it doesn't work well so that Python+Numpy+Scipy.weave is still superior ^^.
MATLAB Coder can allocate memory using malloc, so you can generate C code from MATLAB functions that operate on dynamically sized data. You can also choose the option of static allocation with a maximum size for variables.
RE: using BLAS for matrix multiplication – while the generated C code doesn’t automatically include any processor/platform specific optimizations, there is a feature called Target Function Library, which that allows users to write their own implementation of primitive operations (such as matrix multiplication), and include them in the generated code. You can hook up BLAS libraries to MATLAB Coder via that method. There’s also an ability to include optimized processor specific calls for larger functions through custom code integration and conditional compilation that lets you specify one set of code to use for code generation, and another set for simulation (for example, an optimized FIR function for an Texas Instruments DSP and functionally equivalent code for simulation that can execute on your PC written in C or in MATLAB).
Hope this is helpful --
Arvind Ananthan; Product Manager for MATLAB Coder; MathWorks
I am using Matlab Coder with Real Time Workshop (RTW) in order to generate self standind standard C code.
First of all you are asked to use a Matlab subset called "Embedded Matlab" you can find the doc about it on the web
You also have to avoid any dynamic exploitation of variables and you can't obviously generate c code for plots or figures.
The code it generates could be a mess to understand but it works.
you should actually not try to understand it. In a certain way it is as you would try to understand the assembler your compiler generates from a C code you wrote, quite pointless.
another thing you should take care of is to declare persistent big data types (vectors, big arryes, etc.) otherwise they will be allocated into your stack...
good luck!