Adriand1281 wrote on 2024-12-24, 13:38:Thank you for your answer.
It clarified a lot for me. I compiled the shared code. I only added "declarations" of pins 11 14 15, […]
Show full quote
Thank you for your answer.
It clarified a lot for me. I compiled the shared code. I only added "declarations" of pins 11 14 15, the compiler required it.
Unfortunately, the truth table readings for the programmed system differ from the original. I am attaching the original and the read batch from the programmed system.
I also have a request for a link to the working "Espresso" program. I probably won't be able to move forward without it.
I also absolutely do not understand why during reading PIN 2
(p2) is recognized as "doesn't matter", and PIN 4(p4), which is not even declared in the program, is "OK".
I experienced false reading from time to time so usually I make numerous dumps, process them all and then just check if I have two identical dumps. I can't find a true reason for random readings but I assume it's just because of using breadboard: insufficient conductivity of Vcc/GND, parasite capacities, interference, who knows. Sometimes replacing the resistor array with slightly different value can help, or reinserting of the chip, adding capacitor between Vcc and GND.
In your case it's alerting that the programmed CPLD gives significantly different results, up to mixing up inputs in equations. Maybe you just have something wrong in your wiring (see my post above, I've just drawed mine). The PLD code is correct with exception of omitted declarations of pins, so the problem is either with the chip or with the dumping circuit.
As for "don't matter", it's complex.
Before launching a full test with serial output, the code first tests each of 16 (or 20) inputs in order to detect inputs which don't matter and minimize the output because although combination tests are fast, serial output slows down the process noticeably.
The test for significancy of an input goes like this: all 65K combinations are being tested via passing binary numbers from 0000000000000000 to 1111111111111111 to the input pins, with bit 0 and the tested bit swapped each with other, providing sequential test of all variants of 15 remaining inputs with tested input set to 0, then set to 1. SO, after getting a pair of results, they are compared. Once this routine discovers a difference in a successive pair, immediately returns true. If all test gone with no detected differences, it returns false.
So, if there is any analog problem, causing to slow slew at certain inputs/outputs and they have no enough time to change their state during test, there may be false negative test results which will distort the further analysis.
The final truth table is compiled in real time during the test, so switching rate is limited at least by the serial output functions.
Honestly I haven't looked at the code for several months and already forgot some of its principles. I know that it can detect an input as doesn't-matter and nevertheless include it into the table but I already don't remember, why. Usually when chips was doing so, I got senseless results, poked my breadboard and wires, wiggled the chip and did other shaman's stuff causing some contacts to get back in their place and finally got my two identical reads assuming them correct.
Also, all dumps I've made to JED files were tested on hardware and passed through the same dumping process to make sure that the truth tables are identical, so at lease I may assure that the database is correct.
All I can suggest is double-checking of all the wiring again and maybe passing additional Vcc/GND wires to make the board switch faster. You will be surprised how bad are dupont wires in passing fast currents. I'm thinking on assembling this stuff on a mega2560 shield prototype board and I bet the tests will be dramatically more stable.
P.S. Here's the espresso.exe:
