for muxen. during combinatorial optimization. in berkeley-abc. I am using the binary aig format for importing. It knows only about `and' and `inverter' gates. During optimization the safety terms get dropped (the AB in: Ax + B~x + AB) Should I use a different import format? Which one? I'd like to end up with a .pla file or similar in the end.
If you think this is offtopic feel free to suggest another ng...
It's not about a signal, but a (redundant) term getting lost during the simplification (in abc here: ) That is, the term is redundant w.r.t logic, but not in terms of timing(glitches). Searching for `hazard' in the repository (.c files) does not give a match. There are methods in there to find muxen, so maybe sthg can be cobbled together from that. But before doing that I'd rather ask here if I've missed something, or maybe there's something similar wot can do this already.
I may be way off base here, but I think this is something that is not applicable to FPGAs. FPGAs use a LUT for logic. This is exactly equivalent to the Karnaugh map table that is filled in with 1s and 0s. Notice I didn't say anything about grouping terms for simplification. That is because none of that is needed when you have such a table. Since there is no grouping of terms, preserving term groups is meaningless.
Are you intending for the logic to generate multiple LUTs with these terms separate and another LUT to OR them together?
I can't say for sure about every FPGA family, but Xilinx has indicated they design the muxes in their LUTs to be hazard proof for the problem you are trying to prevent. They do this by the use of transmission gates rather than logic. As the transmission gates turn off and on, the capacitance of the output line keeps the present value until the next transmission gate turns on driving the output to the new value. If the old and new values are the same, no glitch guaranteed.
It's a tool specific attribute that will need to be attached to the signals in order to preserve the logic as you've written.
Why do you think you need to prevent a glitch in the first place? If it's because the signal is going to the input of an edge sensitive device, then you've got a bigger problem, you should not be using internally generated c lock signals or, even worse, internally generated by logic (as opposed to t he output of a flip flop). Unless this is a homework assignment, I strongl y suspect you're trying to solve the wrong problem by searching for the met hod to prevent optimization that removes logic cover terms.
Yes, if you are using simple PLDs then they work directly with product terms and you do need the covering terms for transitions between other terms.
I can't help you with your tool. Is berkeley-abc the tool you are using? What is the source of support? If you have source code you might be able to figure out the input formats. I expect the front end is not so complex. Still, there *should* be some sort of documentation from the same source as the tool.