AHB Testbench - Signal wird nicht geschrieben

[Elvin S. (elvinsp)]

Hallo,

ich arbeite momentan an einer Peripherie für einen Leon3 Softcore (AHB 
Bus) von Gaisler. Um die Peripherie zu testen benutze ich den 
mitgelieferten ambatest framework von 
GRLIB(http://www.gaisler.com/index.php/downloads/leongrlib). Nun habe 
ich ein Signal ctrl das einen Master der auf den AHB Bus zugreift 
steuert. Leider werden meine, an eine PROCEDURE(ahbwrite) übergebenen 
Werte, nicht auf ctrl geschrieben.

ENTITY tb_noc IS
END tb_noc;
 
ARCHITECTURE behavior OF tb_noc IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
    

   --Inputs
   signal rstn : std_logic := '0';
   signal clkm : std_logic := '0';
   signal ahbsi : ahb_slv_in_type;
   signal ahbso : ahb_slv_out_vector := (others => ahbs_none);
   signal ahbmi : ahb_mst_in_type;
   signal ahbmo : ahb_mst_out_vector := (others => ahbm_none);
  signal ctrl  : ahbtb_ctrl_type;

   -- Clock period definitions
   constant clk_period : time := 20 ns;
 
BEGIN
 
  -- Instantiate the Unit Under Test (UUT)
   uut: top_noc
  generic map (
    hindex => 0,
    haddr => 16#400#,
    hmask => 16#fff#)
    port map (rstn, clkm, ahbsi, ahbso(0));
      
  ahb0 : ahbctrl       -- AHB arbiter/multiplexer
        generic map (defmast => 0, split => 0, 
                  rrobin => 1, ioaddr => 16#800#,
                  ioen => 1, nahbm => 1, nahbs => 16, acdm => 1)
        port map (rstn, clkm, ahbmi, ahbmo, ahbsi, ahbso);   

  ahbtbm0 : ahbtbm
    generic map(hindex => 0) -- AMBA master index 0
    port map(rstn, clkm, ctrl.i, ctrl.o, ahbmi, ahbmo(0));

   -- Clock process definitions
   clk_process :process
   begin
    clkm <= '0';
    wait for clk_period/2;
    clkm <= '1';
    wait for clk_period/2;
   end process;
 
   -- Stimulus process
   stim_proc: process
   begin  
    rstn <= '0';
    wait for 100 ns;
    rstn <= '1';
    --ctrl.o.rst <= '1';
    wait;
  end process;
  
  ahb_proc: process
  begin
    wait for 40 ns;
    -- Initialize the control signals
    ahbtbminit(ctrl);
    -- rstn <= '0';
      wait for 100 ns;  
    -- rstn <= '1';
      -- wait for 100 ns;
     -- Write 0x12345678 to address 0x40000000. Print access.
    ahbwrite(x"40000000", x"12345679", "10", 2, true , ctrl);
    wait for 100 ns;
    -- Read address 0x40000000 and compare with 0x12345678. Print access.
    --ahbread (x"40000000", x"12345678", "10", "11", '1', 2, true , ctrl);
    wait for 100 ns;
    -- Burst write with start address 0x40000000. Data is 0xdead0000 - 0xdead0020
    -- No output in printed.
    --ahbwrite(x"40000000", x"dead0000", "10", 32, 0, ctrl);
    wait for 100 ns;
    -- Burst read with start address 0x40000000. Compare data is 
    -- 0xdead0000 - 0xdead0020. Print result if not equal.
    --ahbread (x"40000000", x"dead0000", "10", 32, 1, ctrl);
    wait for 100 ns;
    -- Stop simulation
    ahbtbmdone(1, ctrl); 
      wait;
   end process;

END;

Im Anhang sieht man am Console Output dass der Process bis ahbtbmdone 
durchläuft.

Gesetzt wird ctrl durch die folgende PROCEDURE:

procedure ahbwrite(
  constant address  : in  std_logic_vector(31 downto 0);
  constant data     : in  std_logic_vector(31 downto 0);
  constant size     : in  std_logic_vector(1 downto 0);
  constant debug    : in  integer;
  constant appidle  : in  boolean;
  signal   ctrl     : inout ahbtb_ctrl_type) is
begin
  --ctrl.o <= ctrlo_nodrive;
  wait until ctrl.o.update = '1' and rising_edge(ctrl.o.clk);
  ctrl.i.ac.ctrl.use128 <= 0;
  ctrl.i.ac.ctrl.dbgl <= debug;
  ctrl.i.ac.hburst <= "000"; ctrl.i.ac.hsize <= '0' & size;
  ctrl.i.ac.haddr <= address; ctrl.i.ac.hdata <= data;
  ctrl.i.ac.htrans <= "10"; ctrl.i.ac.hwrite <= '1'; ctrl.i.ac.hburst <= "000";
  ctrl.i.ac.hprot <= "1110";
  if appidle = true then
    wait until ctrl.o.update = '1' and rising_edge(ctrl.o.clk);
    ctrl.i <= ctrli_idle;
  end if;
end procedure ahbwrite;

Man sieht dass meine übergebenen Werte nicht geschrieben werden anhand 
der Simulation im Anhang. Im Bild sieht man ein Signalwechsel bei 210ns, 
aber die Werte ändern sich nicht.

Hier noch der Testbench AHB Master:

component ahbtbm is
  generic (
    hindex  : integer := 0;
    hirq    : integer := 0;
    venid   : integer := 0;
    devid   : integer := 0;
    version : integer := 0;
    chprot  : integer := 3;
    incaddr : integer := 0); 
  port (
    rst  : in  std_ulogic;
    clk  : in  std_ulogic;
    ctrli : in  ahbtbm_ctrl_in_type;
    ctrlo : out ahbtbm_ctrl_out_type;
    ahbmi : in  ahb_mst_in_type;
    ahbmo : out ahb_mst_out_type 
    );
end component;

Ich sitze seit Tagen an dem Problem und verstehe nicht warum nicht auf 
das Signal geschrieben wird.

MfG

[Klakx (Gast)]

Initialisiere mal Ctrl.O.update mit 0

[Klakx (Gast)]

Ok da hat ich mich verschaut. Versuch mal mit Text Ausgaben dich an die 
Stelle zu tasten wo es hängt.

Etwas skeptisch sehe ich die Verwendung von inout in der Prozedur

[Elvin S. (elvinsp)]

Leider kommt 'X' raus, weil ctrl.o.update vom ahbtbm getrieben wird :(
Der Wert wird anscheinend durch ahbtbm immer auf '1' gehalten.

[Elvin S. (elvinsp)]

Ja mein Gedanke war auch das es mit dem INOUT zu tun haben muss. Ich 
habe nie mit INOUT gearbeitet bis jetzt. Ich habe versucht das INOUT zu 
entfernen aber es ist zum Chaos geworden mit der Übersicht in der 
Package, und habe es sein lassen.
Ich wollte mal schauen was man hier dazu sagen würde.
Ich habe mal eine Textausgabe eingebaut gehabt und die Prozedure läuft 
durch. Die Testbench wird ja bis ahbtbmdone ausgeführt (Sieht man in der 
Abschluss Textausgabe "AHBTBM Testbench Done").

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

Elvin S. schrieb:
> Ich habe nie mit INOUT gearbeitet bis jetzt.
Es ist innerhalb eines FPGAs auch sehr unschön, weil es weit weg von der 
tatsächlichen Hardware ist. Wenn schon records dann wenigstens getrennt 
nach Ein- und Ausgängen. Sonst versteigt man sich in aller 
Bidirektionalität und bekommt einen Buskonflikt.

Ich kann mich mit der Gaisler-Schreib- und Denkweise überhaupt nicht 
anfreunden...

[Elvin S. (elvinsp)]

Ich habe jetzt die PROCEDURE umgeschrieben.

procedure ahbwrite(
  constant address  : in  std_logic_vector(31 downto 0);
  constant data     : in  std_logic_vector(31 downto 0);
  constant size     : in  std_logic_vector(1 downto 0);
  constant debug    : in  integer;
  constant appidle  : in  boolean;
  signal   ctrlo     : in  ahbtbm_ctrl_out_type;
  signal   ctrli     : out ahbtbm_ctrl_in_type) is
begin
  --ctrlo <= ctrlo_nodrive;
  wait until ctrlo.update = '1' and rising_edge(ctrlo.clk);
  ctrli.ac.ctrl.use128 <= 0;
  ctrli.ac.ctrl.dbgl <= debug;
  ctrli.ac.hburst <= "100"; ctrli.ac.hsize <= '0' & size;
  ctrli.ac.haddr <= address; ctrli.ac.hdata <= data;
  ctrli.ac.htrans <= "10"; ctrli.ac.hwrite <= '1'; ctrli.ac.hburst <= "000";
  ctrli.ac.hprot <= "1110";
  if appidle = true then
    wait until ctrlo.update = '1' and rising_edge(ctrlo.clk);
    ctrli <= ctrli_idle;
  end if;
end procedure ahbwrite;

Die Simulation sieht genauso aus wie mein erster Anhang.
???
Ich frage anscheinend wird was geschrieben bei 210ns aber es ist nach 
wie vor nicht was ich übergebe zB "010" für ctrl.i.ac.hsize.

ahbwrite(x"40000000", x"12345679", "10", 2, true , ctrl.o, ctrl.i);

[Lattice User (Gast)]

Ich habe einen Verdacht:
Füge mal ein kleines delay nach den beiden waits in der ahbwrite 
procedure hinzu:
SO etwa:

  wait until ctrlo.update = '1' and rising_edge(ctrlo.clk);
  wait for 1 ns;

[Klakx (Gast)]

Elvin S. schrieb:
> ahbwrite(x"40000000", x"12345679", "10", 2, true , ctrl.o, ctrl.i);

vielleicht geht's wenn der record ganz getrennt ist. Ich mische auch nie 
Inputs und Outputs.

ahbwrite(x"40000000", x"12345679", "10", 2, true , tb2master, master2tb);

nebenbei füge noch Textausgaben ein, um zu sehen wo die Prozedur hängt.

[Elvin S. (elvinsp)]

Lattice User schrieb:
> Ich habe einen Verdacht:
> Füge mal ein kleines delay nach den beiden waits in der ahbwrite
> procedure hinzu:

Das wars! Jetzt wo ichs sehe ^^ Oh mann
Anscheinend wird alles in einem gemacht und nicht mehr auf die nächste 
rising_edge(ctrlo.clk) gewartet so dass das idle signal wieder angelegt 
wird (Was für ein S******). Warum wartet er nicht auf die nächste 
positive Taktflanke?

begin
  --ctrlo <= ctrlo_nodrive;
  wait until ctrlo.update = '1' and rising_edge(ctrlo.clk);
  wait for 1 ns;
  ctrli.ac.ctrl.use128 <= 0;
  ctrli.ac.ctrl.dbgl <= debug;
  ctrli.ac.hburst <= "100"; ctrli.ac.hsize <= '0' & size;
  ctrli.ac.haddr <= address; ctrli.ac.hdata <= data;
  ctrli.ac.htrans <= "10"; ctrli.ac.hwrite <= '1'; ctrli.ac.hburst <= "000";
  ctrli.ac.hprot <= "1110";
  if appidle = true then
    wait until ctrlo.update = '1' and rising_edge(ctrlo.clk);
   wait for 1 ns;
    ctrli <= ctrli_idle;
  end if;
end procedure ahbwrite;

[Elvin S. (elvinsp)]

Oh mann,

jetzt sehe ich auch ich muss nur appidle auf false setzen. Danke 
Lattice, Klakx, Lothar für eure Unterstützung!
Kann mir jemand noch ne Erklärung geben warum rising_edge auf die 
vergangene Taktflanke reagiert, obwohl diese 2ns her ist?

MfG

[Elvin S. (elvinsp)]

Kleiner Nachtrag:

Ich habe jetzt rausgefunden, dass das Problem am ISim vom Xilinx liegt. 
Ich habe das selbe auf Modelsim probiert und es läuft wie geschmiert.

lg