I sidste brainer så vi på et problem hvor Active-HDL ikke ville som vi ville. Lad os slå fast med det samme at Active-HDL har fuldstændig ret og fejlen er vores. Under opdatering af test-benchen skulle ansvaret for at generere clock-en flyttes; men ved en fejl blev den drevet fra to steder. Eftersom fasen og frekvensen var uændret kunne man ikke umiddelbart se noget i wave-vieweren.
Hvis man i stedet indsætter et break-point ud for første if-sætning vil man observere at processen schedules to gange for hver flanke og at clock-en er X anden gang processen eksekveres!
Årsagen er at selvom de to clock-kilder driver signalet højt på samme tidspunkt, sker det ikke i samme delta-cycle. Clock signalet får derved følgende forløb: 0 -> X -> 1 -> X -> 0. Værdien X har signalet kun i et antal delta-cycles og da en delta-cycle ikke har nogen tidsmæssig udbredelse kan X’et ikke ses i wave-vieweren.
Hvis vi vender tilbage til vores process, bruger vi funktionen rising_edge. Første gang den kaldes har vi et skift fra 0 til X hvilket ikke kan kaldes en for-flanke. Næste gang processen kører har vi et skift fra X til 1 hvilket heller ikke er en for-flanke. Derfor når vi aldrig ind og eksekvere den indre if-sætning.
Moralen er: Selv om noget ser rigtigt ud i wave-vieweren,
kan det godt være forkert.
Problemet blev fundet ved at sætte et break-point i koden – hvilket visse VHDL designere vægrer sig fra. Angiveligt minder det for meget om software design, men i vores tilfælde viste det sig at være særdeles nyttigt. Nødtvungent må vi opgøre stillingen til 1-0 i Active-HDL’s favør.
PS: Modelsim og Active-HDL har begge mulighed for at liste drivere for et signal. Dette ville også have afsløret årsagen. Kører man det samme eksempel i Modelsim, viser det sig at Modelsim har en fordel idet det dobbelte skift faktisk antydes i wave-vieweren.