1-Bit ALU -- geht es besser?

[Läubi .. (laeubi)]

Ich lese gerade das Buch: "Structured Computer Organisation".
Im Abschnitt "The Digital Logic Level" ist eine 1-Bit ALU beschrieben, 
welche ich mal versucht habe in VHDL Nachzubilden (siehe Anhang).
Zur Zeit hat diese auf nem Spartan 3 folgende Werte:
4 Slices / 7 LUTs
Maximum combinational path delay: 12.030ns

Ich frage mich nur, ob man da noch das ganze geschickter beschreiben 
kann sodass die Synthese das FPGA besser ausnutzt, meine bisherigen 
Versuche das zu minimieren sind leider fehlgeschlagen, aber dass muß ja 
nichts heißen.

Da später die ALU kaskadiert wird um größere Bitbreiten zu berechnen 
erscheint mir das Delay schon etwas hoch.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Maximum combinational path delay: 12.030ns
Da streust du dir selber Sand in die Augen:
Wenn du mal einen Takt einführst, und die Eingangs- und Ausgangssignale 
taktest, dann siehst du, dass die meiste Zeit in den Eingangs- und 
Ausgangs-Pintreibern des FPGAs verplempert wird.

> Da später die ALU kaskadiert wird um größere Bitbreiten zu berechnen
> erscheint mir das Delay schon etwas hoch.
In deiner fertigen CPU wirst du mit diesen Signalen aber niemals an die 
Pins fahren, sondern diese synchron im FPGA weiterbearbeiten.

Mit dem Code im Anhang sieht das Ganze entspannter aus:

   Minimum period: 3.883ns (Maximum Frequency: 257.539MHz)
   Minimum input arrival time before clock: 1.572ns
   Maximum output required time after clock: 6.216ns
   Maximum combinational path delay: No path found

(mit Speedgrade -5)

Und auch an der Beschreibung selber würde ich etwas ändern.
Weg mit den Variablen und ein wenig Concurrent, damit man den MUX 
schöner sieht:

architecture Behavioral of OneBitAlu is
signal AV, BV: std_logic;
signal SUM : std_logic_vector(1 downto 0);
begin
    AV  <= '0'   when ENA='0' else
           not A when INVA='1' else
           A;
    BV  <= '0' when ENB='0' else
           B;
    MUXout: process (AV, BV, Cin, F)
    begin
        Cout <= '0';
        case F is
            -- AND
            when "00" => Y <= AV AND BV;
            -- OR
            when "01" => Y <= AV OR BV;
            -- NOT B
            when "10" => Y <= NOT BV;
            -- A + B
            when "11" => SUM := ("0"&AV) + ("0"&BV) +("0"&Cin);
                         Y    <=  SUM(0);
                         Cout <=  SUM(1);
            when others => Y <= '-';
        end case;
    end process;
end Behavioral;

Und zudem würde ich eher das NUMERIC_STD Package nehmen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Okokok.
Und ich sach' noch: Nimm Concurrent-Zuweisungen und Signale  :-o
So passts:

    :
    BV  <= '0' when ENB='0' else
           B;
    SUM <= ("0"&AV) + ("0"&BV) + ("0"&Cin);

    MUXout: process (AV, BV, Cin, F)
    :
            -- A + B
            when "11" => Y    <=  SUM(0);
                         Cout <=  SUM(1);
    :

[Läubi .. (laeubi)]

@Lothar Miller: Ich kann nur sagen, das hats gebracht! Da wäre ich nie 
drauf gekommen, das das die Ausgangstreiber sind, wieder was gelernt...
Bin jezt für meine 32bit Version aus 1-Bit ALUs von 75ns auf Period 13ns 
gekommen, das ist annehmbar, war schon etwas frustriert das dieser 
Ansatz so dermaßen fehlgeschlagen war.

Habe auch nochmal ne "native" Version mit std_logic_vector gemacht kom 
dort auf kom ich auf 9ns, da kann er wohl noch etwas mehr rausholen.

Hätte dazu aber gleich mal ne Frage:
Minimum period: 9.275ns (Maximum Frequency: 107.817MHz)
   Minimum input arrival time before clock: 1.941ns
   Maximum output required time after clock: 17.895ns
   Maximum combinational path delay: No path found

Was ist den jezt hier die "Laufzeit" meiner ALU/Logic?

Und zu dem Concurrent:
 Was für einen Vorteil habe ich dadurch? In meinem Fall hat das 
umstellen auf Concurrent nix gebracht was die Laufzeit betrifft, habe 
mich aber schon gefragt ob ein Process ohne CLK oder eine Concurrent 
Anweisung "besser" ist oder ob ich überhaupt die ganze ALU lieber als 
eine Zuweisung versuche zu schreiben...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Und zu dem Concurrent:
> Was für einen Vorteil habe ich dadurch?
1. Es liest sich schöner  ;-)
2. Du sparst dir diese (blödsinnigen) Variablen.
3. Wenn du Kombinatorik concurrent schreibst,
   mußt du nicht auf irgendwelche Sensitivity-Listen achten.

> Was ist den jezt hier die "Laufzeit" meiner ALU/Logic?
9.275ns - tsu - tcko --> also etwa 8ns, das ist die Zeit, die die 
ALU-Kombinatorik braucht.

[Läubi .. (laeubi)]

Alles klar, super dann kann es ja weitergehen :)
Habe jezt meine "große" ALU auch auf Concurrent umgeschrieben, eine 
Variable brauch ich aber trozdem für die Flags, wenn ich die auch 
COncurrent mache ist das komischerweise langsamer. (Die große ALU hat 
ein Negativ und ein Zero Flag).

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> ist das komischerweise langsamer.
Sieh dir mal die statische Timinganalyse (Post Place/Route Static 
Timing) an, da steht detailliert, welcher Pfad der Flaschenhals im 
Design ist.

[Läubi .. (laeubi)]

Hab den Report mal angehängt, sehr erhellend ist der nicht, außer das er 
mir Sagt das das ZeroFlag irgenwie ärger macht.

------------+------------+------------------+--------+
            | clk (edge) |                  |  Clock |
Destination | to PAD     |Internal Clock(s) |  Phase |
------------+------------+------------------+--------+
xFLAG_N     |    9.788(R)|clk_BUFGP         |   0.000|
xFLAG_Z     |   23.030(R)|clk_BUFGP         |   0.000|
xY<0>       |    7.360(R)|clk_BUFGP         |   0.000|
....

Habe das Flag direkt an den Ausgang gelegt:

ALUInst:     n32bitALU PORT MAP(A,B,Y,INC,INVA,ENA,ENB,F, xFLAG_Z, FLAG_N);

Weil ich festgestellt habe das wenn ich das über ein Zwischensignal 
mache das ganze langsamer wird...

Erzeugen tue ich die Flags folgendermaßen:

-- Ausgangs Mux
MUXout: process (E_OR, E_AND, E_NOT, E_SUM, F)
variable ERG   : std_logic_vector(n-1 downto 0);
variable ZERO  : std_logic_vector(n-1 downto 0) := (others => '0');
begin
    case F is
        -- AND
        when "00" =>   ERG := E_AND; --CA AND CB;
        -- OR
        when "01" =>   ERG := E_OR; --CA OR CB;
        -- NOT B
        when "10" =>   ERG := E_NOT; --NOT CB;
        -- A + B + INC
        when "11" =>   ERG := E_SUM;
        when others => ERG := (others => '-');
    end case;
    -- Flags
    FLAG_N <= ERG(n-1);
    if ERG = ZERO then
        FLAG_Z <= '1';
    else
        FLAG_Z <= '0';
    end if;
    Y      <= ERG;
end process;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> INFO:Timing:2698 - No timing constraints found, doing default enumeration.
Wenn du der Toolchain keine Vorgaben machst, dann gibt die sich auch 
keine Mühe.

> ... das das ZeroFlag irgenwie ärger macht.
> ... clk to PAD  23.030(R)...
Das Ganze ist derzeit eher eine akademische Spielerei. In der realen CPU 
wird das Z-Flag sowieso nicht auf ein Pad geführt. Mach dir um die 
Laufzeit hier mal keine Gedanken.

[Läubi .. (laeubi)]

Okay, alles klar, dann werd ich mich mal weiter vorarbeitenim CPU Model 
und dann sehen wie sich das mit dem Delay entwickelt.
Ich wollte nur von Anfang an bei den "Basics" schon versuchen möglichst 
effizient zu arbeiten, man muß ja nicht unütz da Zeit verschenken. :)

Bedanke mich auf jeden fall schonmal.