W dniu 03.05.2011 20:59, MiSter pisze:
>> Najprostszy przykład:
>> process(clk) begin
>> out<= in;
>> end process;
>> NIE działa tak jak się człowiek spodziewa - mimo, że w symulacji ładnie
>> kopiuje wejście na wyjście w takt zegara to w FPGA będzie zmieniać stan
>> wyjść gdy tylko zmienią się wejścia.
>>
>> Trzeba więc napisać:
>> process(clk) begin
>> if rising_edge(clk) then
>> out<= in;
>> end if;
>> end process;
>
>
> A co tu jest nie tak wg Ciebie?
> Wszystko działa zgodnie z zapisem.
> Na liście czułości w pierwszym przypadku masz clk więc symulator tylko
> wylicza nowy stan w chwili zmian sygnału "czułego" - clk.

> W rzeczywistości to masz współbieżne przypisanie - poprostu out jest
> połączony "kawałkiem przewodu" z in.
Właśnie. Czyli zsyntetyzowany core zachowuje się inaczej niż to wynika z
opisu. Tylko w takiej sytuacji należałoby zmienić standard języka i
dostosować symulatory a nie udawać, że wszystko jest ok.


> W drugim przypadku masz klasyczny zatrzask - czyli wyjście może zmienić się
> w takt zegara.
Mam klasyczny flip-flop (D, bez wyjścia /Q). Latch wyglądałby tak:
process(clk) begin
if clk='1' then
out<= in;
end if;
end process;

> Po prostu nie ma się co załamywać bo wszystko działa zgodnie z fizyką -
> trzeba się tej fizyki wpierw nauczyć i ją czuć.
Problemem nie jest fizyka tylko inne zachowanie symulacji i syntezy.

Takie a nie inne działanie wynika z prostego faktu - gdyby kompilator po
cichu generował sprzętowy odpowiednik if xxx'event z każdego xxx na
liście czułości (a tak by wygladała realizacja tego co opisuje standard)
to wszystko byłoby strasznie wolne i zasobożerne. Alternatywą jest
wprowadzenie do standardu, że niewymienienie na liście czułości czegoś z
prawej strony podstawienia skutkuje błędem, ale "taka zmiana w języku"
jest niedopuszczalna. Mamy więc sytuację w której symulacja sobie a
synteza sobie, mimo, że symulujemy przecież po to, żeby uzyskać
przewidywalne zachowanie po syntezie.

--
Pozdrawiam
Michoo