How do I preserve Hazard safety terms?

J

Johann Klammer

Guest
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...
 
On Wednesday, October 5, 2016 at 9:26:45 PM UTC-4, Johann Klammer wrote:
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...
Click to expand...

I have no idea what tool you are using, but you'll need to look into the tool specific way to preserve signals.

Kevin Jennings
 
On 10/06/2016 05:55 AM, BobH wrote:
Assuming that the safety terms are getting removed at synthesis time,
look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in similar situations with Verilog, and it worked.

BobH
Click to expand...
You can preserve them with abc? (That's where they disappear here.) what commands do you use?
Here's what I used (on a popen()ed abc instance.. C code):

extern void
dump_pla15 (syn_ctx * ctx)
{
FILE *fp = ctx->abcfp;
char *buf = NULL;
asprintf (&buf, "%s/%s", ctx->tmpdir, "atf15.pla");
fprintf (fp, "read_aiger %s/nopt.aig\n", ctx->tmpdir);
fprintf (fp, "drw\n");
fprintf (fp, "refactor\n");
fprintf (fp, "collapse\n");
fprintf (fp, "write_pla %s\n", buf);
fflush (fp);
free (buf);
buf = NULL;

}
 
On 10/06/2016 03:41 AM, KJ wrote:
I have no idea what tool you are using, but you'll need to look into
the tool specific way to preserve signals.

Kevin Jennings
Click to expand...
It's not about a signal, but a (redundant) term getting lost during the
simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
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.
 
On 10/05/2016 08:17 PM, Johann Klammer wrote:
On 10/06/2016 03:41 AM, KJ wrote:

I have no idea what tool you are using, but you'll need to look into
the tool specific way to preserve signals.

Kevin Jennings

It's not about a signal, but a (redundant) term getting lost during the
simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
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.
Click to expand...

Assuming that the safety terms are getting removed at synthesis time,
look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in
similar situations with Verilog, and it worked.

BobH
 
On Wednesday, October 5, 2016 at 11:17:22 PM UTC-4, Johann Klammer wrote:
On 10/06/2016 03:41 AM, KJ wrote:

I have no idea what tool you are using, but you'll need to look into
the tool specific way to preserve signals.

Kevin Jennings

It's not about a signal, but a (redundant) term getting lost during the
simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
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.
Click to expand...

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 clock signals or, even worse, internally generated by logic (as opposed to the output of a flip flop). Unless this is a homework assignment, I strongly suspect you're trying to solve the wrong problem by searching for the method to prevent optimization that removes logic cover terms.

Kevin Jennings
 
On 10/5/2016 11:17 PM, Johann Klammer wrote:
On 10/06/2016 03:41 AM, KJ wrote:

I have no idea what tool you are using, but you'll need to look into
the tool specific way to preserve signals.

Kevin Jennings

It's not about a signal, but a (redundant) term getting lost during the
simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
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.
Click to expand...

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.

Does this address your concerns?

--

Rick C
 
On 10/06/2016 10:53 AM, rickman wrote:
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.

Does this address your concerns?
Click to expand...
1) I'm targeting a PLD.
2) cda has hazard.c which does that.
3) It targets PLDs too.
4) So it's probably useful here.
5) There is no pld group.
 
On 10/6/2016 9:29 AM, Johann Klammer wrote:
On 10/06/2016 10:53 AM, rickman wrote:

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.

Does this address your concerns?

1) I'm targeting a PLD.
2) cda has hazard.c which does that.
3) It targets PLDs too.
4) So it's probably useful here.
5) There is no pld group.
Click to expand...

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.

--

Rick C
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top