Im writing a multiplexor of 4 bits as input and 1 as output. I have tray several ways, using cases, if, etc. but I keep getting this error:
WARNING:PhysDesignRules:367 - The signal <A<2>_IBUF> is incomplete. The signal
does not drive any load pins in the design.
WARNING:Par:288 - The signal A<2>_IBUF has no load. PAR will not attempt to route this signal.
WARNING:Par:283 - There are 1 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.
And when I program in my circuit design card (Basys), everything works fine, but the switch that is assign to A[2], doesnt work, here are my modules:
module Multi_4_1(
input [3:0] A,
input [1:0] S,
output Z
);
wire w1, w2;
Multi_2_1 a(.A(A[0]), .B(A[1]), .SEL(S[0]), .F(w1));
Multi_2_1 b(.A(A[2]), .B(A[3]), .SEL(S[1]), .F(w2));
Multi_2_1 c(.A(w1), .B(w2), .SEL(S[1]), .F(Z));
endmodule
module Multi_2_1(
input A,
input B,
input SEL,
output F
);
assign F = (~SEL&A)|(SEL&B);
endmodule
And this is where I assign the terminals to the card, but this I have tried it with another projects and it works fine
NET "A[3]" LOC ="B4"; # sw3
NET "A[2]" LOC ="K3";
NET "A[1]" LOC ="L3"; # sw1
NET "A[0]" LOC ="P11"; # sw0, el de la derecha
NET "S[0]" LOC ="G3"; # sw4
NET "S[1]" LOC ="F3"; # sw5
NET "Z" LOC ="M5"; # L0, el de la derecha
Your multiplexer has an incorrect design.
This is your truth table:
S=00 => Z=A[0]
S=01 => Z=A[1]
S=10 => Z=A[3]
S=11 => Z=A[3]
Thus A[2] can never be an output, so it is 'unloaded', and your synthesis tool is warning you of this. You probably intend for Mux b to use sel(S[0]).
Related
I need to find a pool of solutions with AMPL (I am relatively new to it) using the option "poolstub" but I get an error when I try to retrive them. I will try to explain everything step by step. This is my code:
option solver cplex;
model my_model.mod;
data my_data.dat;
option cplex_options 'poolstub=multmip poolcapacity=10 populate=1 poolintensity=4 poolreplace=1';
solve;
At this point AMPLE gives me this:
CPLEX 20.1.0.0: poolstub=multmip
poolcapacity=10
populate=1
poolintensity=4
poolreplace=1
CPLEX 20.1.0.0: optimal solution; objective 4.153846154
66 dual simplex iterations (0 in phase I)
It seems like AMPL has not stored the solutions in the pool.
And in fact, if I try to retrive them with this code
for {i in 1..Current.npool} {
solution ('multmip' & i & '.sol');
display _varname, _var;
}
I get this error:
Bad suffix .npool for Initial
context: for {i in >>> 1..Current.npool} <<< {
Possible suffix values for Initial.suffix:
astatus exitcode message relax
result sstatus stage
for{...} { ? ampl: for{...} { ? ampl:
I have no integer variables, only real ones and I read that CPLEX doesn't support the populate method for linear programs. Could this be the problem or is something else missing? Thank you in advance
You have identified your problem correctly. Entity Initial does not have the npool suffix, which means the solver (in your case CPLEX) did not return one.
Gurobi can return that information for linear programs, but it seems to be identical to the optimal solution, so it would not give you any extra information (more info on AMPL-Gurobi options).
Here is an example AMPL script:
model net1.mod;
data net1.dat;
option solver gurobi;
option gurobi_options 'ams_stub=allopt ams_mode=1';
solve;
for {n in 1..Total_Cost.npool} {
solution ("allopt" & n & ".sol");
display Ship;
}
Output (on my machine):
Gurobi 9.1.1: ams_stub=allopt
ams_mode=2
ams_epsabs=0.5
Gurobi 9.1.1: optimal solution; objective 1819
1 simplex iterations
Alternative MIP solution 1, objective = 1819
1 alternative MIP solutions written to "allopt1.sol"
... "allopt1.sol".
Alternative solutions do not include dual variable values.
Best solution is available in "allopt1.sol".
suffix npool OUT;
Alternative MIP solution 1, objective = 1819
Ship :=
NE BOS 90
NE BWI 60
NE EWR 100
PITT NE 250
PITT SE 200
SE ATL 70
SE BWI 60
SE EWR 20
SE MCO 50
;
The files net1.mod and net1.dat are from the AMPL book.
When solving a MIP the solver can store sub-optimal solutions that it found along the way as they might be interesting for some reason to the modeler.
In terms of your LP, are you interested in the vertices the simplex algorithm visits?
i am a complete beginner at Fortran and am working on a code that solves a kinetic mechanism by solving differential equations at different time steps using a differential equation solver.
Here is a link to download the zip file with the whole project:
http://www.filedropper.com/fortranmicropyrolyzersetup
The input variables for the differential solver are defined as follows in the code:
! Declaration of variables
implicit none
EXTERNAL :: FEXSB_AUTO, JEX_SB
integer :: neq,Mf,lrw,liw,iwork,itol,itask,istate,iopt !solver parameters
integer :: j,jjk,m !Counters
double precision :: ATOL,RTOL, RWORK !solver parameters
double precision :: T, TOUT !starting time (s), timestep time (s)
double precision :: Y, w !molar fraction of biomass (-), mass fraction of biomass (-)
double precision :: y_gas, w_gas, Conc !molar fraction in gas phase (-), concentration in gas phase (mol/m³), mass fraction in gas phase (-)
double precision :: n(speciescount) !number of moles (used temporarily to calculate initial molar fracions)
character*5 :: simulationNumber
!Setting the solver parameters
neq = SpeciesCount !number of equations
ITOL = 1 !RTOL and ATOL are integers
RTOL = 1.0D-8 !Relative tolerance
ATOL = 1.0D-15 !Absolute tolerance
ITASK = 1
ISTATE = 1
LRW = 22 + 9*SpeciesCount + 2*SpeciesCount**2 !Array sizing (see VODE)
LIW = 30+SpeciesCount !Array sizint (see VODE)
MF = 22 !Use BDF with finite difference Jacobian
IOPT = 1 !Optional input specified
Iwork(6) = 7000 !Increase maximum iteration steps from 500 to 2000 otherwise the solver does not converge
The differential solver is then called in a do loop for each time step as follows:
! Solve reactor equations (see FEXSB) and advance time, until stop criterium is met
TimeStep = 0 ! dimensionless time step
!DO while(wm(1).lt.0.9999) -> previously used stop criterium
DO while((y_gas(1).lt.0.99999).OR.(TimeStep.lt.10)) !stop criterium: molar fraction Helium = 0.9999 AND do at least 100 timesteps
TimeStep = TimeStep + 1
write(*,*)"Doing iteration for time step",TimeStep
call DVODE(FEXSB_AUTO,NEQ,Y,T,TOUT,ITOL,RTOL,ATOL,ITASK,ISTATE,IOPT,RWORK,LRW,IWORK,LIW,JEX_SB,MF) !solve reactor equations to Y
!CALL DVODE(FEXSB_AUTO,NEQ,Y,T,TOUT,ITOL,RTOL,ATOL,ITASK,ISTATE,IOPT,RWORK,LRW,IWORK,LIW,JEX_SB,MF,RPAR,IPAR)
! calculate w, y_gas, w_gas and Conc from Y
do j = 1, SpeciesCount
if (Y(j) .lt. 1.0D-10) then ! round to zero below 10e-10 to avoid negative numbers and numerical problems with small numbers
Y(j) = 0.0D0
endif
if (MolarFlowRate(j) .lt. 1.0D-10) then
MolarFlowRate(j) = 0.0D0
endif
w(j) = Y(j)*n0_tot*amms(j) / (mass_sample)
y_gas(j) = MolarFlowRate(j) / TotalMolarFlowRate
w_gas(j) = MolarFlowRate(j)*amms(j) / (1000*MassFlowRate) ! factor 1000 to put molar mass in kg/mol instead of g/mol
Conc(j) = MolarFlowRate(j) / VolumetricFlowRate
end do
The differential equation solver does not successfully complete the do loop of the line :
DO while((y_gas(1).lt.0.99999).OR.(TimeStep.lt.10))
The variables seem to be recognized for the first time step when the ODE Solver is called in the line:
call DVODE(FEXSB_AUTO,NEQ,Y,T,TOUT,ITOL,RTOL,ATOL,ITASK,ISTATE,IOPT,RWORK,LRW,IWORK,LIW,JEX_SB,MF)
And the solver successfully completes the first iteration. After the time step is increased one more time, the call function works again but this time the variables are not recognized somehow. When I stop the code to debug what is wrong after the first time step, I realized that the variables required for DVODE do not have set values anymore, somehow they get deleted after the first successful iteration.
What might be causing this problem?
*DECK DVODE
SUBROUTINE DVODE (F, NEQ, Y, T, TOUT, ITOL, RTOL, ATOL, ITASK,
1 ISTATE, IOPT, RWORK, LRW, IWORK, LIW, JAC, MF,
2 RPAR, IPAR)
EXTERNAL F, JAC
DOUBLE PRECISION Y, T, TOUT, RTOL, ATOL, RWORK, RPAR
INTEGER NEQ, ITOL, ITASK, ISTATE, IOPT, LRW, IWORK, LIW,
1 MF, IPAR
DIMENSION Y(*), RTOL(*), ATOL(*), RWORK(LRW), IWORK(LIW),
1 RPAR(*), IPAR(*)
!-----------------------------------------------------------------------
c dvode: Variable-coefficient Ordinary Differential Equation solver,
! with fixed-leading-coefficient implementation.
! This version is in double precision.
!
! DVODE solves the initial value problem for stiff or nonstiff
! systems of first order ODEs,
! dy/dt = f(t,y) , or, in component form,
! dy(i)/dt = f(i) = f(i,t,y(1),y(2),...,y(NEQ)) (i = 1,...,NEQ).
! DVODE is a package based on the EPISODE and EPISODEB packages, and
! on the ODEPACK user interface standard, with minor modifications.
!-----------------------------------------------------------------------
! Authors:
! Peter N. Brown and Alan !. Hindmarsh
! Center for Applied Scientific Computing, L-561
! Lawrence Livermore National Laboratory
! Livermore, CA 94551
! and
! George D. Byrne
! Illinois Institute of Technology
! Chicago, IL 60616
!-----------------------------------------------------------------------
Any help would be greatly appreciated. Please note that I am new to Fortran. If I should supply any additional information to help you answer my question, please don't hesitate to let me know. Thanks in advance!
The assumption that the parameters should be untouched after the first iteration is wrong.
In fortran function parameters are always passed by reference. Thus, a fortran function never guarantees that your original parameter set is the same after the call. It might be the intened (or poor) design of the function to DO change the parameters. Only documentation can help you, and what you provided in your question is not enough, which might very likely also mean: maybe there is not enough documentation for this case/function.
In contrast to C/C++ in fortran there is no "const" modifier for variables that would guarantee you what you have to assume right now.
To me it seem the only solution is to re-initialize all parameters right before every call to DVODE.
So, I am working on a program in ARM that takes a bunch of numbers from a file and tells if they are even or odd.
The problem is that I know how to multiply by 0.5, but I don't know how to do something like this high level statement in ARM
if (A / 2 == 0)
print even
else
print odd
Here's what I have in terms of code:
#open input file
ldr r0,=FileName # set Name for input file
mov r1,#0 # mode is input
swi SWI_Open # open file for input
bcs InFileError # if error?
ldr r1,=InFileHandle # load input file handle
str r0,[r1] # save the file handle
#read integers from input file
NUMBERS:
ldr r0,=InputFileHandle # load input file handle
ldr r0,[r0]
swi SWI_RdInt # read the integer into R0
bcs EofReached # Check Carry-Bit (C): if= 1 then EOF reached
#multiplication by 0.5 to test for odd or even
MUL R2 R0 0.5
#what is the test in ARM
#for ( R0 / 0.5 ) == a multiple of 1?
B NUMBERS
LOOP:
#end of program
Message1: .asciz"Hello World!"
EOL: .asciz "\n"
NewL: .ascii "\n"
Blank: .ascii " "
FileName: .asciz"input.txt"
.end
So I think the first two things inputting from the file and reading the integers works. I don't know how to test for the condition that it is divisible by 2. I think it's multiplied by 0.5 and then the next step is to say even if that number doesn't have a decimal place with anything after it at the end, but if it does then then number A that was divided into number B is odd. Otherwise it is even?
A brief answer: you don't need to multiply by 0.5 or anything like that. You need to check the value of LSB (least significant bit) of the value. It will be 0 for even numbers and 1 for odd numbers.
Upd.: your "C" code is also wrong. You want to use A % 2, not A / 2
I would like to ask how I can define / declare a variable in Scilab. In some PDFs that I read, it says that I can just type it in and Scilab will take care of the declaration. Not so. I want to set up a matrix equation of something like:
Ax + By + Cz = D
Mx + Ny + Pz = E
Rx + Sy + Tz = F
And then I want to get the general value of x, y, x in terms of A, B, C, D, E, F, M, N, P, R, S, T. I remember this is possible with Matlab. And later on, I want to plug in these values to get actual numbers. Please help.
Scilab is much more oriented at numerical computation than algebra solving, but you can still do it.
In your case you first should define the system in the form M1*x=M2, being M1 upper triangular.
I suggest you look at help for solve() and trianfml(), there are nice examples.
After that you can evaluate the expressions giving any value you want for A, B, C, ..., using evstr()
For symbolic algebra, I recommend Wolfram mathematica, Maple, or Maxima (this last one is open-source like Scilab)
OK, this is what I found. SciLab requires "symbolic math toolbox" in order to do symbolic math. the scimax/overload toolbox (by Calixte Denizet) can do that by integrating Maxima with SciLab. however, it is only available on Linux/Unix OS. another way to do it is the OVLD/SYM toolbox (by the deceased Jean-François Magni) which works with Windows (even Win 7). however, support for this toolbox has ceased due to its author's demise. the installation guide on spoken-tutorial.org no longer exists. thus, I am left with using Maxima by itself to solve symbolic equations and calculus problems.
I'm trying to make a mod-12 counter in Verilog using 4 D-FFs. I've actually come up with two implementations, one of which works as intended (but is really bad practice IRL), and the other does not work as intended. The following is the ideal(correct) output generated from my "bad" implementation.
And the following is what's generated from the module I'm having trouble with.
Here is the module that generated the top image:
module Mod12Counter(q, clk, rstIn0);
output [3:0] q;
input clk, rstIn0;
DF DF0(q[0], qBar0, qBar0, clk, rst),
DF1(q[1], qBar1, qBar1, qBar0, rst),
DF2(q[2], qBar2, qBar2, qBar1, rst),
DF3(q[3], qBar3, qBar3, qBar2, rst);
and and0(test, q[2], q[3]);
or or0 (rst, rstIn0, test);
endmodule
And here is the module that generated the bottom image:
module Mod12Counter(q, clk, rst);
output [3:0] q;
input clk, rst;
and and0(d1In0, q[1], qBar0),
and1(d1In1, qBar1, q[0]),
and2(d2In0, q[2], qBar1),
and3(d2In1, qBar3, qBar2, q[1], q[0]),
and4(d2In2, q[2], qBar0),
and5(d3In0, q[3], qBar1),
and6(d3In1, q[2], q[1], q[0]),
and7(d3In2, q[3], qBar0);
or or0(d1, d1In0, d1In1),
or1(d2, d2In0, d2In1, d2In2),
or2(d3, d3In0, d3In1, d3In2);
DF DF0(q[0], qBar0, qBar0, clk, rst),
DF1(q[1], qBar1, d1, qBar0, rst),
DF2(q[2], qBar2, d2, qBar1, rst),
DF3(q[3], qBar3, d3, qBar2, rst);
endmodule
What's really weird is these two modules should behave exactly the same way. The only difference is one is just made using my gut feelings and the other one is generated by deriving equations from state tables. From what I know, the bottom module is much more preferable to use IRL.
So far the problem I'm seeing is q[2] and q[3] don't get triggered at all in the bottom module. I've tried using BUS assignment as you see now and I've also tried not using BUS assignment.
I've spent MANY hours on this, and I would really appreciate it if you could help me debug the module, point at the right direction, or tell me a better place to go for things like this.
If q[2] is never going high, the first thing you should look at is to understand why the input to DF2 is not ever going high at the point when the clock rises.
Looking at the inputs to see what drives d2, I see these three lines:
and2(d2In0, q[2], qBar1),
and3(d2In1, qBar3, qBar2, q[1], q[0]),
and4(d2In2, q[2], qBar0),
Obviously and2 and and4 cannot help you here, because they require q[2] to be true in order to be true, so we can throw those out, leaving just these lines to look at:
and3(d2In1, qBar3, qBar2, q[1], q[0]),
or1(d2, d2In0, d2In1, d2In2),
DF2(q[2], qBar2, d2, qBar1, rst),
d2In1 should be high when q is equal to 0011, which then means that d2 will be high at the same time. However you are triggering the clock to DF2 on the rising edge of qBar1, which means that at whenever qBar1 goes high, q[1] is going low, thus causing d2In1 to go low as well. So you have a race condition where the input to the flip flop is falling at the same time the clock edge is rising, which is not good!
Instead of clocking your flip flops on outputs of flip flops (which can give you nasty race conditions), you should let all your flip flops be based on just a single clock, and generate your next state based on the previous value of the flip flops.
Alternatively, here is a very simple solution (you don't always have to design the gates yourself!):
reg [3:0] q;
always #(posedge clk) begin
q <= (q == 4'd11 || rst) ? 0 : q + 1;
end