Csúszás hosszabb várakozás során.

Question

A feladatom egy sakkóra tervezése. A teszt során ha 10 másodpercet várok az óra jó értékeket mutat, viszont 74 másodperc eltelte után 1 másodperc csúszás keletkezik és nem tudom, hogy ez hogy lehetséges.

Előre is köszönöm a segítséget!

Answer 1

Valószínűleg hiba van a modellben. Érdemes megnézni, hogy biztos minden átmeneten csökken-e az óra ahol kell. Különös figyelemmel az esetleges várakozó állapotokra, ha nálad vannak.

Egy másik lehetséges magyarázat az, hogy a modell csak egész másodpercekkel dolgozik. Az after 1s átmenethez tartozó időzítő akkor indul el, amikor belép a vezérlés az állapotba. Amennyiben bármilyen gomb lenyomódik, aminek a hatására akár egy hurok élen is, de el lesz hagyva az állapot (viszont nem csinál semmit az átmenet), az időzítő újra kezdi az 1s számolását. Ez okozhat egy csúszást. A másik ami okozhat, hogy ha eltelt 0.8s és akkor vált a másik játékosra, vagy csak 0.2s és akkor vált a másik játékosra, ezek a töredék másodpercek elvesznek a számolásban, mert a másik játékos állapotába belépéskor újrakezdődik az after 1s számítása.

Ez utóbbi kettő jelenség nem számít hibának, a modell feladat jellegzetessége. Ha a kiadott tesztesetek nem jeleznek hibát, akkor helyesen működik az óra.

Comments

Köszönöm a választ.

Az időzítésre az every 1s-t használom, de az nem pontos és ezt még mindig nem sikerült kijavítanom.

Az új kérdésem az lenne, hogy az every 1s működését, hogy lehet pontosítani, mert a pontatlanság miatt az utolsó teszt esetben van 1s csúszás, miközben a többi teszt eset során jól fut le.

Ezenkívül azt szeretném még kérdezni, hogy az always-t lehet-e az every 1s helyett használni vagy az minden esetben tiltott elem, mert azzal tökéletesen működik.

Előre is köszönöm a segítséget!

---

Közben sikerült megoldanom a problémát always használata nélkül.

Köszönöm a segítséget!

---

Pro :)
A honlapon már le is lehet adni a megoldásokat :)

Egyébként általánosan igaz, hogy a tiltott elemek azért tiltottak, mert nem lehet őket használni. A gond velük az, hogy ezek hatására az automata nemdeterminisztikus lesz. Akár az always, az oncycle, vagy az átmenet nélküli éllel a probléma az, hogy nincs garancia arra, hogy mikor hajtódnak végre.
Míg egy egyszerű átmenetről tudod, hogy akkor, amikor a kiváltó eseménye tüzel, addig ezekről nem tudsz semmit. Ennek a mélyén a DIGIT-ből tanult sorrendi hálózatok vannak. Ott, mint a verilog kódokból látszódott is, egy órajelütésre (ami itt legyen egy esemény) legfeljebb egy átmenet történhetett. Itt is, ha leírod az always-t egy A állapotból kiinduló nyílra, akkor az nem annak az átmenetnek a hatására tüzel, ami miatt beleléptél A-ba, hanem azt követően, egy külön órajelciklusban. A hangsúly azon van, hogy el KELL telnie időnek, még ha az infizitemálisan kicsi is.
Ez általában ilyen egyszerű esetekben, mint ez a sakkóra nem okoz problémát. De ha 5-6 párhuzamos régiód van, és akkor szerepel egy always valahol, akkor az nagyon csúnyán fel tudja rúgni a régiók esetleges szinkronitását.

Mindenesetre ezért született az a döntés, hogy ezeket a nemdeterminisztikus elemeket nem fogadjuk el, és tiltott elemnek minősítjük. Valós rendszerek esetén ugyanis többször implementálhatatlanok, és veszélyesek is :)

---

Köszönöm a választ, így már értem, hogy miért tiltott az always.