OR gate not able to map to MIG about lsoracle

[yashton]

% lsoracle -f x.lso 
AIG network stored
[w] no mig in store
There is not an MIG network stored.

I suspect you had an XOR gate stored in the MIG store while the OR gate ended up in the AIG store - you'll note that you loaded the blif as an AIG with -a, but wrote out the MIG store with -m.

[ratul619]

I read the blif with -m option , but or gate doesnt seem to reflect

lsoracle> read_blif or.blif -m
MIG network stored
lsoracle> ps -m
nodes: 6
inputs: 2
latches: 0
outputs: 1
MAJ nodes: 3
MIG level: 3
lsoracle [mig]> write_verilog -m --filename or_oracle2.v

module top(c , d , q );
input c , d ;
output q ;
wire new_n3, new_n4, new_n5;
assign new_n3 = ~c & d ;
assign new_n4 = d & ~new_n3 ;
assign new_n5 = ( c & new_n3 ) | ( c & ~new_n4 ) | ( new_n3 & ~new_n4 );
assign q = new_n5 ;
endmodule

[yashton]

@ratul619 could you post the blif file so I can take a look?

[ratul619]

.model top
.inputs c d
.outputs q
.names $false
.names $true
1
.names $undef
.names c d q
1- 1
-1 1
.end

[srtemp]

Good catch. It's a bug in either the BLIF reader or the node resynthesis that goes from truth table -> MIG. I have an update in progress that should fix it, since it updates all of that code, but I need to test with this particular case now. We should push it in the next few days. In the interim I'd recommend using AIG input if possible; that resolved the problem for me.
Thanks for pointing this out!

[ratul619]

Hi , Should this be solved now ? Thanks

[NormandAlexandre]

Hey,
With the current version we have, it worked without any problem.