Ich versuche mit Quartus 16.1 ein case mit alle 256 Fälle zu synthetisieren. Ja alle 256 sind da von 0 bis 255. Ein when others gibt es auch, mach aber kein unterschied. Die Signal ist es ein std_logic_vector(7 downto 0). Mit einem integer range 0 to 255 kommt die Meldung auch. Die Fehlermeldung lautet: Case Statement choices must cover all possible values. Alle Werte sind da, ich kann auch der letzte Wert mit eine when other ersetzen, die Meldung kommt trotzdem. Hat jemand eine Idee ? GHDL 0.36 beschwert es aber nicht.
std_logic hat nicht nur 0 und 1 als moegliche Werte, daher ist die Meldung schon sinnvoll. Kannst du mal den betreffenden Code, bzw. ein Minimalbeispiel zeigen bei dem der Fehler auftritt? Edit: Hab leider ein paar Infos ueberlesen. Wenn die Meldung auch mit Integer kommt und alle Zahlen abgedeckt werden, ist wirklich etwas faul.
:
Bearbeitet durch User
Da musst du wohl mal den betreffenden Code hochladen. Ich mache was ähnliches mit Quartus und einem 8 Bit slv, das baut problemlos. Ich decke nichtmal alle Fälle ab...
1 | case read_data is |
2 | when x"06" | x"0E" | x"16" | x"1E" | x"26" | x"2E" => -- X = Mem[PC] |
3 | ...
|
4 | ...
|
5 | ...
|
6 | when others => |
7 | state <= IDLE; |
Ale schrieb: > ein case mit alle 256 Fälle zu synthetisieren Eine Copy-Paste Orgie. Kann man das nicht schlauer machen? Was passiert in den Zuständen > Die Fehlermeldung lautet: > Case Statement choices must cover all possible values. Lass mal den zugehörigen Code sehen. Am Besten als VHDL-Datei anhängen...
Quartus hat irgend ein Problem. Mit Diamond (synplify pro) wird synthetisiert mit nur einen Warnung. Egal, ich hab es umgeschrieben, jetzt gibt es eine Menge arrays.
1 | process (opcode_in) |
2 | begin
|
3 | case (opcode_in) is |
4 | when X"00" => op_name_o <= X"41525020"; -- ARP |
5 | op_name_str_o <= "ARP "; |
6 | op_next_decode_o <= ST_EXE; |
7 | op_bytes_to_fetch_o<= 0; |
8 | op_bytes_to_stack_o<= 0; |
9 | op_curr_drp_o <= DRP_DRP; |
10 | op_curr_arp_o <= ARP_ARP; |
11 | op_addr_src_o <= SRC_PC; |
12 | op_write_reg_o <= false; |
13 | op_multibyte_o <= false; |
14 | op_dec_dest_o <= false; |
15 | op_alu_op_o <= ALU_LD_ARP; |
16 | op_addr_mode_o <= OP_MODE_6LIT; |
17 | when X"01" => op_name_o <= X"41525020"; -- ARP |
18 | op_name_str_o <= "ARP "; |
19 | ...
|
20 | when X"FF" => op_name_o <= X"4a524e20"; -- JRN |
21 | op_name_str_o <= "JRN "; |
22 | op_next_decode_o <= ST_FETCH; |
23 | op_bytes_to_fetch_o<= 0; |
24 | op_bytes_to_stack_o<= 0; |
25 | op_curr_drp_o <= DRP_DRP; |
26 | op_curr_arp_o <= ARP_ARP; |
27 | op_addr_src_o <= SRC_PC; |
28 | op_write_reg_o <= false; |
29 | op_multibyte_o <= false; |
30 | op_dec_dest_o <= false; |
31 | op_alu_op_o <= JREL; |
32 | op_addr_mode_o <= OP_MODE_REL; |
33 | when others => null; |
34 | end case; |
Hat trotzdem gesgt daß ein "others" fehlt...
Werden da tatsächlich nur Konstanten zugewiesen oder ist die Sensitivliste unvollständig?
Ich tippe mal auf das null-statement, die fehlenden zuweisungen für alle anderen neben op_name_str_o und op_name_o, und in gewisser weise fehlenden Takt. Das case ist ein ROM-feld keine sequentielle Logik. Also muss für jeden Ausgang in jeden when eine Zuweisung gegeben werden. das Null-statement im Zusammenhang mit dem Rest der Bschreibung führt hier wahrscheinlich zu latches. https://www.ics.uci.edu/~jmoorkan/vhdlref/nulls.html Das handling von Latches kann sich von FPGA zu FPGA-Familie unterscheiden. Lattice hat womöglich congigurierbares Silizum vorgessen das als (internes) Latch arbeitet und intel für die Quartus-Zielarchitektur eben nicht. > Quartus hat irgend ein Problem. Mit Diamond (synplify pro) wird Nein, nicht das tool hat ein Problem, sondern womöglich die Zielarchitektur. VHDL ist hinsichtlich des FPGA-Targets so architekturunabhängig, wie es einem blutigen Anfänger erscheint. Wenn etwas unter Lattice synthetisiert, aber nicht unter intel/Altera dan bedeudet das nicht , das das VHDL parsen vom Quartus fehlerhaft ist.
C. A. Rotwang schrieb: > die fehlenden zuweisungen für alle anderen neben op_name_str_o und > op_name_o Ich hatte jetzt vermutet, dass die im "..." versteckten ca. 253,8 Fälle genau gleich aussehen wie X"00" und X"FF". Und das da deshalb keine Latches drin sind. Ale schrieb: > ich hab es umgeschrieben, jetzt gibt es eine Menge arrays. Ich hätte das das zwar auch von Anfang an in eines oder ein paar Arrays gepackt, aber prinzipiell sollte das mit den 256 Case-Abfragen schon funktionieren. Und der Synthesizer braucht das "when others" sowieso nicht, weil alle für ihn relevanten Zustände auscodiert sind. Er kennt ja nur '0' und '1' und keine 'X' oder 'U' oder 'H' oder 'L'...
:
Bearbeitet durch Moderator
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.