DuPAL_Analyzer

DuPAL_Analyzer copied to clipboard

Been working on a PAL20L8 and running into this error. Really not sure how this is possible un an unregistered array.

[main] ERROR info.hkzlab.dupal.analyzer.palanalisys.explorers.OSExplorer - exploreOutStates() -> Mismatch in expected pins (E:A9|00 - A:E9|00) after walking path to state OS[O:A9|Z:00] Exception in thread "main" info.hkzlab.dupal.analyzer.exceptions.DuPALAnalyzerException: exploreOutStates() -> Mismatch in expected pins after walking to state OS[O:A9|Z:00] at info.hkzlab.dupal.analyzer.palanalisys.explorers.OSExplorer.exploreOutStates(OSExplorer.java:58) at info.hkzlab.dupal.analyzer.board.boardio.DuPALAnalyzer.startAnalisys(DuPALAnalyzer.java:116) at info.hkzlab.dupal.analyzer.App.main(App.java:74)

It shouldn't be possible (barring bugs, of course, didn't have 20L8 at hand to test), usually happens if a state was misrecorded.

Now, this is more or less impossible for me to diagnose remotely, but when I had it in the past, in one case I had a flaky PAL which threw this randomly, and in the other I was able to get it working in the following way:

First, execute the run of the analyzer to extract the IO mask and find which pins are inputs. Then, power down the board, power it back on, and pass the mask as a parameter, so it doesn't do the detection step.

Yep. Actually was just in the middle of working in peeper instead and I have one pin that will go to a stuck state once activated. I'll just have to ignore that pin for now.

Ah, another time it happened (but doesn't look to be the case here) is I had one that several hours into the analysis started doing strange things. "Solved" placing a heatsink on it...

Another thing that came to my mind: i wonder if this could be another case of pin being a feedback into itself, something like out = out + in1 * in2 It's been a while since I dabbled with this, and can't really remember if this is a legal equation, but if it is, it's certainly capable of breaking the analysis, especially since it introduces a state out of which we cannot get out from without a power cycle.

Maybe I should document this possibility....

I am thinking it might be possible. There is a single databus and IOW input on this PAL. Might be using it as a set once register.

Solution for now is to just leave the pin lifted. Crude but effective.

Figured it out after more poking. Turns out it's a SR latch. https://www.paul.de/tips/sr-ff-in-gal.htm

Ah good job finding that out. I think it's worth tracking this. I don't have time right now to work on this, but who knows in the future (or maybe someone else).

The issue here is that the algorithm is taking the inputs as enough to define a state change and move through the graph to another node, but in this case taking in account the output values would also be required.

Example from the website above: MYOUT = /MYOUT * MYIN_A + MYOUT * /MYIN_B

@raymondh2 Should you happen to be able to reverse the PAL or generate equations that give you the same issue, I'd appreciate if you could upload them here.

Hmm, I had some time today to look back at my code. Actually, I took into considerations the possibility of latches back then, and in fact, at least for simple ones, they do work. See an attached example for a GAL16V8, including equations, JED, and the resulting JSON from the analysis latch.zip

The important equation is the following: o18 = i1 * /o18 + /i2 * o18 So there must be something else at play here...

Tested this as well and had it work. There might be a more complex equation going on here.

So it does seem to be a SR latch in this case. What is tripping it up is there being more than one state that resets and sets it. Example of case below

/* *************** INPUT PINS ********************/ PIN [1..10] = [A9..A0] ; / / PIN 11 = AEN ; / / PIN 13 = EDB4 ; / / PIN 14 = IOW ; / Seems to be IOW / PIN 16 = DSK ; / I */

/* *************** OUTPUT PINS ********************/ PIN 20 = IDECS0 ; / Connects to U10 Pin I11 O / PIN 21 = 21U20to7U10 ; / Connects to U10 Pin I7 SR Flip */

A10 = 'b'x; A11 = 'b'x; FIELD ADDRESS = [A0..A11]; IDEPRI = ADDRESS:'h'[1F0..1F7]; ALTIDEPRI = ADDRESS:'h'[170..177];

!IDECS0 = (IDEPRI & !AEN & DSK) # (ALTIDEPRI & !AEN & !DSK); 21U20to7U10 = !21U20to7U10 & (!IDECS0 & !A0 & A1 & A2 & EDB4 & !IOW) # 21U20to7U10 & !(!IDECS0 & !A0 & A1 & A2 & !EDB4 & !IOW);

Thanks for looking into it. For now I can't do much more than nothing the limitation in the README, until I have more time to get into it again. Until then, this issue will remain open!