Jak droga jest konwersja typu danych w porównaniu z manipulacją bitową w VHDL?

Question

W VHDL, jeśli chcesz zwiększyć wartość std_logic_vector, która reprezentuje liczbę rzeczywistą o jeden, natknąłem się na kilka opcji.

1) Użyj funkcji konwersji typów danych typecasting, aby zmienić wektor std_logic na wartość podpisaną lub niepodpisaną, a następnie przekonwertować ją na liczbę całkowitą, dodać do tej liczby całkowitej i przekonwertować z powrotem na std_logic_vector w odwrotny sposób niż poprzednio. Poniższy wykres jest przydatny przy próbie wykonania tej czynności.

2) Sprawdzić wartość LSB. Jeśli jest to "0", ustaw "1". Jeśli jest to "1", zrób "przesunięcie w lewo" i połącz "0" z LSB. Przykład: wektor (dla wektora 16-bitowego) (15 początków 1) & '0';

W FPGA, w porównaniu do mikroprocesora, fizyczne zasoby sprzętowe wydają się czynnikiem ograniczającym zamiast rzeczywistego czasu przetwarzania. Zawsze istnieje ryzyko, że zabraknie fizycznych bram.

Moje prawdziwe pytanie brzmi: która z tych implementacji jest "droższa" w FPGA i dlaczego? Czy kompilatory są wystarczająco wydajne, aby zaimplementować tę samą reprezentację fizyczną?

Answer 1

Żadna z konwersji typu nie kosztuje.

Różne typy to czysto wyrażanie projektu tak wyraźnie, jak to możliwe - nie tylko dla innych czytelników (lub dla siebie, w przyszłym roku :-), ale także dla kompilatora, pozwalając mu złapać jak najwięcej błędów (np. ta liczba całkowita jest poza zakresem)

Konwersja typu to twój sposób mówienia kompilatorowi "tak, chciałem to zrobić".

Należy użyć typu, który najlepiej wyraża zamiar projektu.

Jeśli używasz zbyt wielu konwersji typów, zwykle oznacza to, że coś zostało uznane za niewłaściwy typ; Zatrzymaj się i pomyśl trochę o projekcie, a to często ułatwi ładnie. Jeśli chcesz zwiększyć wartość std_logic_vector, prawdopodobnie powinna to być wartość unsigned, a nawet naturalna.

Następnie konwertuj, gdy trzeba: często na najwyższych poziomach portów lub IP innych osób.

Konwersje mogą nieskończenie spowalniać symulacje, ale to już inna sprawa.

Co do twojej opcji 2: szczegółowe opisy na niskim poziomie są nie tylko trudniejsze do zrozumienia niż a <= a + 1;, ale nie są łatwiejsze do tłumaczenia przez narzędzia syntetyczne i częściej zawierają błędy.

Answer 2

Daję kolejną odpowiedź, aby lepiej odpowiedzieć, dlaczego pod względem bramek i zasobów FPGA, to naprawdę nie ma znaczenia, z której metody korzystasz. Na końcu logika zostanie zaimplementowana w tablicach przeglądowych i klapkach. Zwykle (lub zawsze?) Nie ma natywnych liczników w tkaninie FPGA. Synteza zamieni twój kod na LUTs, kropka. Zawsze staram się wyrażać kod tak prostym, jak to tylko możliwe. Im więcej spróbujesz napisać swój kod w RTL (vs. behawioralny) tym bardziej będzie on podatny na błędy. KISS to właściwy sposób działania za każdym razem, Narzędzie do syntezy, jeśli jakieś dobre, uprości twoje intencje tak bardzo, jak to tylko możliwe.

Answer 3

Jedynym powodem do wdrożenia arytmetyka ręką jest, jeśli:

• że można to zrobić lepiej niż narzędzie syntezy (gdzie lepiej mogłoby być mniejsze, szybsze, mniej mocy konsumentami, etc)
• i uważasz, że ograniczona przenośność i łatwość konserwacji kodu nie ma większego znaczenia w dłuższej perspektywie
• i ma to znaczenie, jeśli wykonujesz lepszą pracę niż narzędzie syntezy (np. Możesz osiągnąć żądaną częstotliwość operacyjną robiąc to ręcznie, a nie pozwalając t narzędzie syntezy zrobi to za ciebie).

W wielu przypadkach można również przepisać nieco kod RTL lub zastosować atrybuty syntezy, takie jak KEEP, aby przekonać narzędzie syntezy do bardziej optymalnych wyborów implementacyjnych, a nie ręcznych implementacji komponentów arytmetycznych.

Nawiasem mówiąc, dość standardową sztuczką do obniżenia kosztów liczników sprzętu jest uniknięcie zwykłej arytmetyki binarnej, a zamiast tego użycie na przykład liczników LFSR. Zobacz Xilinx XAPP 052, aby uzyskać inspirację w tej dziedzinie, jeśli jesteś zainteresowany FPGA (jest dość stary, ale ogólne zasady są takie same w obecnych FPGA).