Not plausible 16L8 analysis

[toms001]

Hi,

i programmed the following test-equations to a GAL16V8:

 W = A * B * C
/X = D * E
 Y = F + G
 Z = H * I + J * K

Pinout:

Pin # | Name     | Pin Type
-----------------------------
   1   | B        | Input
   2   | C        | Input
   3   | D        | Input
   4   | E        | Input
   5   | F        | Input
   6   | G        | Input
   7   | H        | Input
   8   | I        | Input
   9   | J        | Input
  10   | GND      | GND
  11   | K        | Input
  12   | NC       | NC
  13   | NC       | NC
  14   | NC       | NC
  15   | Z        | Output
  16   | Y        | Output
  17   | X        | Output
  18   | W        | Output
  19   | A        | Input
  20   | VCC      | VCC

and tested it with peeper.

The analyzer (started as 16L8, only combinatorical) finds the output-mask 0x3F. When i specify the right output-mask 0F, i get this error: An IO pin marked as input is behaving as an output. New IO mask: 0F Only 3F goes further and the analysis is not right.

[hkzlab]

Please provide me the JED you used to program the GAL device, so I can test it on one of my boards

[toms001]

Gatter.jed.zip

[hkzlab]

There is an issue with the jed file you just uploaded. The following output is generated via jedutil -view Gatter.jed gal16v8:

Inputs:

1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 17, 18, 19

Outputs:

12 (Combinatorial, Output feedback output, Active low)
13 (Combinatorial, Output feedback output, Active low)
14 (Combinatorial, Output feedback output, Active low)
15 (Combinatorial, No output feedback, Active high)
16 (Combinatorial, No output feedback, Active high)
17 (Combinatorial, Output feedback output, Active low)
18 (Combinatorial, Output feedback output, Active high)

Equations:

/o12 =
o12.oe = vcc

/o13 =
o13.oe = vcc

/o14 =
o14.oe = vcc

o15 = i7 & i8 +
      i9 & i11
o15.oe = vcc

o16 = i5 +
      i6
o16.oe = vcc

/o17 = i3 & i4
o17.oe = vcc

o18 = i1 & i2 & i19
o18.oe = vcc

Note the following:

1. Outputs 12, 13 and 14, while not tied to any combinations of inputs, are actually always high with these equations. They DO act as outputs, if you tie them to GND you're going to get a short circuit, they're not hi-z. Hence, the IO mask of 3F is correct.
2. Now, the L in 16L8 means that the device is actually one with active-low outputs. If you check the equations for o15, o16 and o18 you'll see that you have a mix of active-low and active-high outputs (see that / missing in front of them? that switches them to active-low), which is not possible on a real 16L8.

The raw output you get from the analyzer might very well be correct, but once you input this in the table generator, it will ask espresso to optimize for active-low when you select a 16L8, and get you a mess of equations.

You'll have to retest with a JED compatible with a real 16L8 (and remember to check already-known issues here).

[hkzlab]

Please, reopen if you have an issue with a valid JED.

[toms001]

Thank you - i got it and dumped successfully a real PAL16L8 of a Commodore A1060-Sidecar :)

One last about another PAL (CPL16L8):

`# PAL16L8 o19 = (i2&!i4&!i5&i6&i7&i8&!io17) | (!i3&i4&i9) | (i3&i4&!i11) | (!i4&i9 &io17) | (!i4&i5&i9) | (i3&!i4&io17) | (!i4&i8&i9) | (i3&!i4&i5) | ( i3&!i4&i8) | (fio18&!fio15) | (fio16&!fio14) | (!fio18&!fio14) | ( !fio18&fio16) | (!i2);

o12 = (i2&!i4&!i5&i6&i7&i8&!io17) | (fio18&!fio15) | (fio16&!fio14) | ( !fio18&!fio14) | (!fio18&fio16);

io18 = (i2&!i4&!i5&!i8&!io17) | (fio18&!fio15) | (fio16&!fio14) | (!fio18 &!fio14) | (!fio18&fio16);

io16 = (i4&!io13) | (fio18&!fio15) | (i2) | (fio16&!fio14) | (!fio18 &!fio14) | (!fio18&fio16);

io15 = (i2&!i4&!i5&i7&!i8&!io17) | (fio18&!fio15) | (fio16&!fio14) | ( !fio18&!fio14) | (!fio18&fio16);

io14 = (i2&i3&i4&i11) | (fio18&!fio15) | (fio16&!fio14) | (!fio18&!fio14) | ( !fio18&fio16);

o19oe = (i2) | (!i2);

o12oe = (i2) | (!i2);

io18oe = (i2) | (!i2);

io16oe = (i2) | (!i2);

io15oe = (i2) | (!i2);

io14oe = (i2) | (!i2);`

How do i have to interpret the last OE-rows? I2 | !I2 is everytime true, why i2?

Thank you, very cool project!

[hkzlab]

Glad to know!

What you see in the second post is a side effect caused by espresso not having the full truth table available. This happens because for a PAL with feedbacks or latches (like the 16L8) part of the outputs are fed back into it as inputs, and while we can try every combination for direct inputs, we can't for those feedbacks, so we end up with a partial table.

There is a way to mitigate (not solve) this issue, and it is by setting all the remaining possible combinations to a "don't care" state in espresso. I have a small tool developed for this, but I've yet to release it (need to clean it up a bit before). That should make those absurd (i2 | !i2) disappear, anyway you can safely consider them as always true. I hope this dump will work, 16L8 using feedbacks are very problematic to simplify with espresso. Maybe have a run with peeper by testing both the original PAL and the dump you made, comparing a few combinations side-to-side.

[toms001]

ok thank you. Do you think another solver using e.g. the quine mccluskey-algorithm will give better results?

[hkzlab]

That I can't say because I admit I don't know what algorithms espresso is attempting to use: I'm more than glad to know the results if someone wishes to test it though!

[toms001]

Is it possible that you have a last look at a DuPAL-Analyzer-File attached? The Peeper does the same with the real PAL and this dump (as i see). I think that the espresso-equations above are not working, can you copy that?

• sorry i'm new at this business - dupal_analyzer_out.zip

[hkzlab]

If I run it through the "filler" that adds the "don't care" fields, I get

o19 = (i2&!i4&!i5&i6&i7&i8&!io17) | (!i3&i4&i9) | (i3&i4&!i11) | (!i4&i9
    &io17) | (!i4&i5&i9) | (i3&!i4&io17) | (!i4&i8&i9) | (i3&!i4&i5) | (
    i3&!i4&i8) | (!i2);

o12 = (i2&!i4&!i5&i6&i7&i8&!io17);

io18 = (i2&!i4&!i5&!i8&!io17);

io16 = (i4&!io13) | (i2);

io15 = (i2&!i4&!i5&i7&!i8&!io17);

io14 = (i2&i3&i4&i11);

If I don't, I get the same equations as you posted.

It might be worth for you to try running the espresso converter by specifying a single output at a time (third parameter, start at 0 and increment by one each time), as in that case it will try to use the feedbacks of the PAL in a different way to generate the truth table (a bit too long to explain here, but it will take the values of feedbacks from the destination states except for the current output, where it will take it from the source).

No guarantee though, as I said, I did not yet find a way to properly map feedbacks on the truth table to feed espresso. It's mostly an issue in formalization of the problem here.

BTW, might be worth to actually open a ticket on this in the DuPAL_EspressoConverter repo, as I think the issue is actually in performing the truth table conversion and not in the analysis of the device that generates the JSON. Remember to also attach the JSON you added here. I can't assure you anything on the resolution, but I'd like to keep track of it in case I come up with new ideas.

[toms001]

ok, i will open a new ticket tomorrow - but these equations are not right, i tested them in Peeper with the original PAL and with the JSON-file. if you want, please test o19 or i16 - some inputs have to be reversed

[hkzlab]

Yes, as I mentioned earlier, the data fed into espresso for devices using feedbacks does not always produce good results. It's why I created the peeper. But let me get this straight, I want to make sure I understood: the equations are not correct and do not match the behaviour, but if you test the real device and the JSON output with peeper, leaving the equations generated by espresso aside, they DO behave the same. Is that right?

[toms001]

yes, i think so.

[hkzlab]

ok then, I suspect the issue is what I mentioned above then. Will play around with it with the peeper and see what I discover. I fear it won't be sooner than next week though, as I need to go away tomorrow and will be out for the weekend.

[toms001]

no problem, this is a great project - its done when its done :)