Logic Analyzer Core (Logic Analyzer)

[ope (Gast)]

Hi,

wie versprochen kommt forengerecht der VHDL Teil des Logik Analyser
Threads aus
http://www.mikrocontroller.net/forum/read-1-204570.html#new, der auch
der Haupt- und Initialthread ist. Wem es zu lang ist, eine halbwegs
aktuelle Zusammenfassung gibt's im Wiki
http://www.mikrocontroller.net/articles/Logic_Analyzer.

Daneben exisitiert noch:
- Pegelkomparator für High-Speed-Digital (Logic Analyzer)
http://www.mikrocontroller.net/forum/read-1-208137.html#new
- CPLD und AVR Kombo (Logic Analyzer)
http://www.mikrocontroller.net/forum/read-9-207389.html#new

Derzeit arbeitet Dirk am SRAM Interface und ich am Trigger; so nun zu
meinem Problem - irgendwie ist mein Gehirn während des Urlaubs
eingerostet (oder ich habe ein grundlegendes Problem):

entity counter_g is
  generic(
    BIT_WIDTH : positive  := 8;
    CLOCK_ENABLE: boolean := true;
    DOWN_COUNTER: boolean := false;
    LOADABLE    : boolean := false;
    RESET_ACTIVE: std_logic := '1'
  );
  port(
    clk   : in  std_logic;        -- rising edge trigger count
    reset   : in  std_logic;        -- asynchronous reset
    en      : in  std_logic := '0';   -- clock enable, high active
    ld      : in  std_logic := '0';   -- data load with rising edge 
    data    : in  std_logic_vector(BIT_WIDTH-1 downto 0) := (others =>
'0');-- preload data
    count   : out std_logic_vector(BIT_WIDTH-1 downto 0)  -- counter
output
  );
end counter_g;


architecture behavioral of counter_g is
  signal m_count : std_logic_vector(BIT_WIDTH-1 downto 0);
begin
  process(clk, reset)
  begin
    if(reset = RESET_ACTIVE) then
      m_count <= (others => '0');
    elsif(rising_edge(clk)) then
      if(LOADABLE) then
        if(ld = '1') then
          m_count <= data;
        end if;
      end if;
      if(CLOCK_ENABLE) then
        if(en = '1') then
          if(not DOWN_COUNTER) then
            m_count <= m_count + 1;
          else
            m_count <= m_count - 1;
          end if;
        end if;
      else
        if(not DOWN_COUNTER) then
          m_count <= m_count + 1;
        else
          m_count <= m_count - 1;
        end if;
      end if;
    end if;
  end process;

  count <= m_count;

end behavioral;

möchte ich gerne überall einsetzten. Konkret hier für einen Trigger hit
counter, d.h. in einer entity setze ich trig_hit auf '1', wenn das
bit/edge pattern gefunden wurde. Es soll nun n-mal auftauchen um den
Capture auszulösen (hier noch nicht implementiert). Die Variante, die
den Counter benutzt "cntrl_proc", klappt nicht so, wie ich es
eigentlich wie in "proc" haben möchte:

entity hitlength_trigger is
  generic(
    COUNT_BITS    : positive := 5;
    RESET_ACTIVE  : std_logic := '1'
  );
  port(
    clk         : in  std_logic;
    reset       : in  std_logic;
    trig_hit    : in  std_logic;    
    n_hits      : in  std_logic_vector(COUNT_BITS-1 downto 0);
    match       : out std_logic
  );
end hitlength_trigger;


architecture behavioral of hitlength_trigger is

  signal m_reset    : std_logic := not RESET_ACTIVE;
  signal m_clear    : std_logic := not RESET_ACTIVE;  
  signal m_hitcount : std_logic_vector(COUNT_BITS-1 downto 0);
  signal m_hitcount2: std_logic_vector(COUNT_BITS-1 downto 0);

begin

  cnt_i: entity work.counter_g
  generic map(
    BIT_WIDTH     => COUNT_BITS,    -- max N clock cycles
    RESET_ACTIVE  => RESET_ACTIVE,
    CLOCK_ENABLE  => true,
    LOADABLE      => false
  )
  port map(
    clk       => clk,
    reset     => m_reset,
    count     => m_hitcount,
    en        => trig_hit,
    ld        => open,      -- warning on input never used
    data      => open     -- warning on input never used
    );

   m_reset <= reset or m_clear;

  ctrl_proc: process(reset, clk, trig_hit)
  begin

    if(reset = RESET_ACTIVE) then
      match   <= '0';
    elsif rising_edge(clk) then
      if(trig_hit = '0') then
        m_clear <= RESET_ACTIVE;
      else
        m_clear <= not RESET_ACTIVE;
      end if;
    end if;

  end process;


  proc: process(clk, reset)
  begin
    if(reset = RESET_ACTIVE) then
      m_hitcount2 <= (others => '0');
    elsif rising_edge(clk) then
      if(trig_hit = '0') then 
        m_hitcount2 <= (others => '0');
      else
        m_hitcount2 <= m_hitcount2 + 1;
      end if;
    end if;
  end process;

Die Entities sind noch im Design Stadium, also noch nicht komplett. Das
unterschiedliche Verhalten ist im TB zu sehen:

entity tb_hitlength_trigger is
end tb_hitlength_trigger;

architecture behavior of tb_hitlength_trigger is 

   constant COUNT_BITS: positive  := 5;
   constant PERIOD  : time      := 10 ns;   
   
   signal clk     : std_logic     := '0';
   signal reset     : std_logic     := '0';
   
  --inputs
  signal n_hits   : std_logic_vector(COUNT_BITS-1 downto 0) := (others
=> '0');
  signal hit      : std_logic := '0';

  --outputs
  signal match    : std_logic := '0';
   
begin

  -- instantiate the unit under test (uut)
  uut: entity work.hitlength_trigger
  generic map(
    COUNT_BITS  => COUNT_BITS
  )
  port map(
    clk     => clk,
    reset     => reset,
    n_hits    => n_hits,
    trig_hit    => hit,
    match     => match
  );

   -- sample clock
   clock_proc: process(clk)
   begin
      clk <= not clk after PERIOD/2;
   end process;
   

  tb : process
  begin
   
      reset <= '1';

    -- wait for global reset to finish
    wait for PERIOD;
    reset <= '0';
    
    -- simulate trigger hit
    wait for PERIOD;
    hit <= '1';

    wait for 2*PERIOD;
      hit <= '0';

      -- finish      
      write(output, string'("TB done."));
      
    wait; -- will wait forever
  end process;

end;

Konkret zählt ctrl_proc einen hit zu wenig und geht nicht wieder auf
Null, wenn trig_hit != 0 ist.

Tja, wie bekomme ich das Verhalten von proc in ctrl_proc realisiert,
ich grübbele schon den ganzen Tag 'dran.

Viele Grüße
Olaf

PS: Da es keine Vorschau gibt - ist es für das nächste mal besser die
sourcen als Anhang zu machen?

[high_speed (Gast)]

Hallo Olaf

Beim ersten Überschauen über deinen Code ist mir aufgefallen, dass du
viel mit verschachtelten IF- Strukturen arbeitest.

Für die Übersichtlichkeit finde ich das nicht gerade optimal.
Der Code wird so nur länger und schwerer durchschaubar.

-- deine Version
if(LOADABLE) then 
   if(ld = '1') then 
      m_count <= data; 
   end if; 
end if; 

-- meine Version
if LOADABLE and ld = '1' then 
   m_count <= data; 
end if;

> Konkret zählt ctrl_proc einen hit zu wenig und geht
> nicht wieder auf Null, wenn trig_hit != 0 ist.

> m_reset <= reset or m_clear;

...

> elsif rising_edge(clk) then
>   if(trig_hit = '0') then
>      m_clear <= RESET_ACTIVE;
>   else
>      m_clear <= not RESET_ACTIVE;
>   end if;
> end if;

m_clear wird im schlimmsten Fall um eine Taktperiode verzögert.
Der Reset wird doch bei trig_hit = '0' gemacht?
Deine OR- Verknüpfung solltest du noch mal überdenken.
Dein Quelltext machst du sehr flexibel, aber dieses OR macht alles
wieder zugrunde.

Warum willst du mit aller Gewalt ein Zählerdesign nutzen?

> Tja, wie bekomme ich das Verhalten von proc
> in ctrl_proc realisiert, ich grübbele schon
> den ganzen Tag 'dran.

Weist du was der Vorteil von proc gegenüber ctrl_proc ist?
Mann kann es einfach lesen und versteht es sofort.

Wenn man ein Projekt in Teilefunktionen zerlegt, muss das eine Sinn
machen. Nur für deinen Zähler sehe ich da einfach keinen Sinn.
Du musst dir nur mal überlegen, wo welches Signal herkommt und um wie
viele Takte es gegenüber einem anderen verschoben ist.

Im Anhang ist dein Zähler ein bisschen aufgeräumt.

MfG
Holger

[high_speed (Gast)]

Noch einmal vereinfacht. :-)

MfG
Holger

[ope (Gast)]

>Beim ersten Überschauen über deinen Code ist mir aufgefallen, dass du
>viel mit verschachtelten IF- Strukturen arbeitest.
>
>Für die Übersichtlichkeit finde ich das nicht gerade optimal.
>Der Code wird so nur länger und schwerer durchschaubar.

das kommt vom "Kästchen"-Denken - da muss ich meiner Brainware mehr
Flexibilität antrainieren ;-)

>m_clear wird im schlimmsten Fall um eine Taktperiode verzögert.

das würde auch das "Eins-zu-wenig-gezählt" erklären.

>Der Reset wird doch bei trig_hit = '0' gemacht?

yep, es kommt kein trigger hit und der counter wird zurück gesetzt. Vom
Prinzip her ist es ein Monoflop.

>Deine OR- Verknüpfung solltest du noch mal überdenken.
>Dein Quelltext machst du sehr flexibel, aber dieses OR macht alles
>wieder zugrunde.

wie soll ich es anders lösen? Am reset "Knopf" des Zählers zerrt zum
einem der reset der ganzen entity und zum anderen der interne reset
m_clear aus ctrl_proc.

>Warum willst du mit aller Gewalt ein Zählerdesign nutzen?

Evtl. versuche ich die reuseablity etwas auf die Spitze zu treiben, das
mag sein ;-) und wenn ich sehe, wieviel Zeit ich darin bereits
reingesteckt habe ... Aber rein hypothetisch/interessenhalber, wie kann
man es machen?

Auch muss ich noch einen Vergleich einführen auf eine vorgegebene
Anzahl von hit events, zB. 3 clock periods continuous trig_hit. Was
wird besser synthetisiert, ein Vergleich (cnt = cnt_soll) oder einen
Zähler mit cnt_soll laden und runterzählen und bei cnt=0 den match
ausgeben? Daher auch die Idee mit der Zähler entity.

Viele Grüße
Olaf

[ope (Gast)]

inzwischen habe ich die einzelnen trigger condition entities (zum
Großteil) zusammen und wollte sie in einen gemeinsamen "trigger"
verpacken.

In diesem Testbench ist mir nun aufgefallen, dass der match m_hitlength
2 Takte später kommt als ich ich erwartet hätte (1 Takt). Im Testbench
für hithlength_trigger kommt er wie erwartet mit der nächsten
steigenden Flanke.

Woran liegt diese unerwartete Verzögerung eines Clocks und wie kann ich
sie umgehen, da ich ja alles nur zusammen geknippert habe.

Letzlich werden die Ereignisse auseinandergezogen, wodurch imo die
Kausalität verloren geht, wenn dann alles x Takte später kommt.

Viele Grüße
Olaf

[ope (Gast)]

hier mal ein Bild vom TB.

[ope (Gast)]

Neuer Tag, neues Problem:

entity latch_g is
  generic(
    BIT_WIDTH : positive  := 8;
    RESET_ACTIVE: std_logic := '1'
  );
  port(
    clk     : in  std_logic;
    reset     : in  std_logic;
    en        : in  std_logic;
    D       : in  std_logic_vector(BIT_WIDTH-1 downto 0);
    Q       : out std_logic_vector(BIT_WIDTH-1 downto 0)
  );
end latch_g;


architecture behavioral of latch_g is

  constant ZERO : std_logic_vector(BIT_WIDTH-1 downto 0) := (others =>
'0');

begin

  process(clk, reset, en, D)
  begin
    if(reset = RESET_ACTIVE) then
      Q <= ZERO;
    elsif rising_edge(clk) then
      if(en = '1') then
        Q <= D;
      end if;
    end if;
  end process;

end behavioral;

Der Entity name ist nicht ganz korrekt, besser währe wohl register,
aber was soll's.

entity la is
  generic(
    BIT_WIDTH   : positive  := 16;  -- probe bit width
    RESET_ACTIVE  : std_logic := '1'
  );
  port(
    clk     : in  std_logic;    -- Master clock
    reset     : in  std_logic;    -- asynchr. reset
    probe     : in  std_logic_vector(BIT_WIDTH-1 downto 0);
  );
end la;


architecture behavioral of la is

  signal sample_en  : std_logic;
  signal sample_t0  : std_logic_vector(BIT_WIDTH-1 downto 0);
  signal sample_t1  : std_logic_vector(BIT_WIDTH-1 downto 0);
  signal sample_trans: std_logic;
  
begin

  -- TEST ONLY
  sample_en <= '1';

  probe_latch_i: entity work.latch_g
  generic map(
      BIT_WIDTH => BIT_WIDTH,
      RESET_ACTIVE   => RESET_ACTIVE
  )
  port map(
    clk   => clk,      -- sample clock
    reset   => reset,
    en   => sample_en,
    D   => probe,
    Q   => sample_t0
  );

   sample_proc: process(clk, reset, sample_t0)

    constant ZERO : std_logic_vector(BIT_WIDTH-1 downto 0) := (others
=> '0');

   begin
      
      -- synchronuous store sample t-1
    if(reset = RESET_ACTIVE) then
      sample_t0   <= ZERO;
      sample_t1   <= ZERO;
      sample_trans <= '0';
      elsif rising_edge(clk) then
         sample_t1 <= sample_t0;   -- sample(t-1) <= sample(t0)   

         if(sample_t0 /= sample_t1) then
             sample_trans <= '1';
         else   
             sample_trans <= '0';
         end if;
      end if;  
   end process;
   
end behavioral;

und nun der TB:

architecture behavior of tb_la is 

   -- Constants
   constant PERIOD  : time   := 10 ns;   
   
   --Inputs
   signal clk :  std_logic := '0';
   signal reset :  std_logic := '0';
   signal probe :  std_logic_vector(7 downto 0) := (others=>'0');

begin

   -- simulate DUT, signals are slower than LA clk
   my_probe: block
      signal clk   : std_logic := '0';
   begin
      probe_clk_proc: process(clk)
      begin
         clk <= not clk after 3*PERIOD/5;
      end process;

      probe_prbs_i: entity work.LFSR8
      port map(
         clk   => clk,
         q   => probe 
      );  
   end block;

  -- Instantiate the Unit Under Test (UUT)
  uut: entity work.la
  generic map(
      BIT_WIDTH => 8,
      RESET_ACTIVE   => '1'    
  )
  port map(
    clk => clk,
    reset => reset,
    probe => probe,
    led_0 => led_0,
    led_1 => led_1
  );

   -- clock
   clock_proc: process(clk)
   begin
      clk <= not clk after PERIOD/2;
   end process;
   
  tb : process
  begin

    write(output, string'("run this TB 100 ns!"));
    reset <= '1', '0' after PERIOD;
    wait; -- will wait forever

  end process;

end;

Das verblüffende ist im Screenshot zu sehen, er übernimmt die Samples
von Probe nict in sample_t0. Anscheinend werden nur die '0'
übernommen.

Sinnigerweise bekomme ich die Warnung

All outputs of the instance <probe_latch_i> of the block <latch_g> are
unconnected in block <la>.

bei der Synthese. Ich behaupte jedoch, es richtig verknippert zu haben
- oder wer reisst mit das Brett vor'm Kopf weg?

Viele Grüße
Olaf

[Dirk (Gast)]

Hi,

wenn es sich um vectoren handeln musst du diese auch mit angeben beim
connecten. z.B. portx(7 downto 0) => output(7 downto 0)

Gruß,
Dirk

[FPGA-User (Gast)]

@Dirk
muss man nicht, es sei denn, sie haben unterschiedliche Bit-Breiten.

[Dirk (Gast)]

Hi,

@FPGA-USER

hm ich hatte das selbe Problem und konnte es nur so loesen. Ich dachte
auch das es nur bei unterschiedlichen Bitbreiten angegeben werden muss.


Es soll nur ein Tipp sein und Ope kann es mal gerne ausprobieren. Waere
nett ein Feedback zukriegen.

Gruß,
Dirk

[Jörn (Gast)]

>signal clk :  std_logic := '0';
>signal reset :  std_logic := '0';
>signal probe :  std_logic_vector(7 downto 0) := (others=>'0');

Lass mal die (others=>'0') Zuweisung weg. Zu hast zwei oder mehrere
Treiber, die auf sample_t0 gegeneinander arbeiten. Anders kann ich mir
es im Moment nicht erklären.

Gruß Jörn

[ope (Gast)]

die defaults bei probe habe ich weggelassen, es half leider nichts. MXE
auch:

Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic
operand, the result will be 'X'(es).
#    Time: 25 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 35 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 35 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 45 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 45 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 55 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 55 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 65 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 65 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 75 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 75 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 85 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 85 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 95 ns  Iteration: 0  Instance: /tb_la8/uut
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 95 ns  Iteration: 0  Instance: /tb_la8/uut

nichts neues aber auch nicht sehr hilfreich imo. Jede einzelne Entity
in ihrem TB funktioniert wie erwartet, nur für TB_la net :/

Was mich irritiert ist die Warnung von XST: All outputs of the instance
<probe_latch_i> of the block <latch_g> are unconnected in block <la>.

Versuche ich mir die RTL Schematics bzw Technologie Schematics
anzusehen, sind diese leer!

Viele Grüße
Olaf


PS: Ein
sample_t1(BIT_WIDTH-1 downto 0) <= sample_t0(BIT_WIDTH-1 downto 0)
hat auch nichts gebracht.

[ope (Gast)]

habe eben die Konstante
ONE : std_logic_vector(7 downto 0) := (others => '1');
im TB eingeführt und den Eingang probe der entity la damit verbunden
und bekomme als wave diesmal nur XXXXX, siehe Anhang. Evtl. hilft ja
dies.

[Jörn (Gast)]

Kannst du deinen akutellen Stand mal anhängen.

[ope (Gast)]

habe eben die Stelle ausfindig gemacht, an der die Probleme verursacht
werden, aber warum ist mir noch nicht klar:

[vhd]

   sample_proc: process(clk, reset, sample_t0)

    constant ZERO : std_logic_vector(BIT_WIDTH-1 downto 0) := (others
=> '0');

   begin

      -- synchronuous store sample t-1
    if(reset = RESET_ACTIVE) then
--      sample_t0   <= ZERO;
--      sample_t1   <= ZERO;
        sample_trans <= '0';
      elsif rising_edge(clk) then

[/vhdl]

und es gibt nur noch eine Warnung von MXE:

Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic
operand, the result will be 'X'(es).
#    Time: 15 ns  Iteration: 0  Instance: /tb_la8/uut

die, so denke ich, von dem uninitialisierten Werten her kommen dürfte.


Ich mache demnächst ein Archive vom aktuellen Stand.

Viele Grüße
Olaf

[ope (Gast)]

da isser.

[ope (Gast)]

ich denke, ich habe es:

   smpl_t1_proc: process(clk, reset, sample_t0)

    constant ZERO : std_logic_vector(BIT_WIDTH-1 downto 0) := (others
=> '0');

   begin
      
      -- synchronuous store sample t-1
    if(reset = RESET_ACTIVE) then
--      sample_t0   <= ZERO;
        sample_t1   <= ZERO;
      elsif rising_edge(clk) then
         sample_t1 <= sample_t0;   -- sample(t-1) <= sample(t0)   
    end if;  
   end process;

Ich darf im reset process sample_t0 nicht resetten. Evtl., weil dies
bereits im probe_latch_i geschieht? Aber warum dieses so nachhaltige
Wirkung zeigt, ist mir allerdings ein Rästel.

Das sich bei diesem synchronen? (bis auf dem reset) Design alles
verzögert, ist schon ätzend imo. Hier bekomme ich zB. einen Takt später
mit, dass sich die sampels geändert haben; kann es also im TB nicht mehr
so einfach nachprüfen. Für die Cotrl Logik wird's dann interessant.

Viele Grüße
Olaf

[ope (Gast)]

ein weiterer Tag ;-)

entity la_config is
  port(
    hw_conf_field : in  std_logic_vector(3 downto 0);
    num_of_sram   : out std_logic_vector(1 downto 0); -- max=4
    error       : out std_logic
  );
end la_config;


architecture behavioral of la_config is

begin
  
  sram_conf_proc: process(hw_conf_field)
  begin
    -- Bit 0,1: number of sram soldered
    case hw_conf_field(1 to 0) is
      when "01"   => num_of_sram <= conv_std_logic_vector(1, 2); -- 1
sram
      when "10"   => num_of_sram <= conv_std_logic_vector(1, 2); -- 2
sram
      when others => num_of_sram <= (others <= '0'); -- Line 45
                error <= '1';
    end case;
  end process;

end behavioral;

xst error:

Line 45. parse error, unexpected LE, expecting PIPE or ROW
Line 43. String literal "01" is not of size 0.
Line 44. String literal "10" is not of size 0.

Die erwartete size 0 verblüfft mich doch etwas, ist hier ein Syntax
Fehler? Wenn ich schreibe b"01" ändert dies auch nichts.

Viele Grüße
Olaf

[Jörn (Gast)]

> case hw_conf_field(1 to 0)

müßte das nicht "downto" heißen?

[ope (Gast)]

>müßte das nicht "downto" heißen?

yep - danke!, damit bleibt nur noch der Fehler auf Line 45. Ich habe
aber auch schon solche Sachen mit "to" gesehen, allerdings in einem
anderem Zusammenhang. Wann nimmt man eigentlich "downto" und "to"?

Viele Grüße
Olaf

[ope (Gast)]

ich bin verblüfft:

  when others => num_of_sram <= conv_std_logic_vector(0, 2);

funktioniert? Aber wieso denn nicht mit (others <= '0') ?

[Jörn (Gast)]

Weil es "(others=>'0');" heißen sollte ;)

Kommt drauf an wie du deinen Std_logic_vector zusammenbaust. Beides
müßte funktionieren:
(2 downto 0) oder (0 to 2)

Wenn du in deiner ersten Version 0 to 1 geschrieben hättest, wäre es
auch gegangen.

[ope (Gast)]

aja, das kleine Syntaxteufelchen :-) Jetzt ist der Unterschied auch
klar.

Momentan versuche ich einiges in packages und records zu packen, um den
Überblick nicht zu verlieren und hänge hierbei:

package la_pkg is

  subtype pcb_ver_t is std_logic_vector(2 downto 0); -- config fields =
3, max=8

  type num_sram_t is (  -- config fields = 2
    SRAM_N0,    -- internal used (FPGA)
    SRAM_N1,    -- external sram = 1  -- option #1
    SRAM_N2,    -- external sram = 2  -- option #2
    SRAM_N3   -- external sram = 3
  );

  type la_config_t is
  record
    pcb_ver     : pcb_ver_t;  -- I/O fields=3
    num_sram      : num_sram_t;   -- I/O fields=2
  end record;

  ...

  -- will nicht, wäre aber sehr nützlich; casts wie positive()
  -- hilft nicht.
  constant LA_CONF_FIELD_WIDTH  : positive 
    := (num_sram_t'high) + (pcb_ver_t'high);

end la_pkg;

- wie kann ich im Nachhinein die Größe des Vectors bestimmen von
selbstdefinierten typen?
- wie kann ich attribute wie length zB für num_sram_t implementieren

package body la_pkg is
  attribute length of num_sram_t : is ????
  ...

- der record soll an den I/O Port, wie kann ich die bitreihenfolge
absolut herausbekommen - entspricht die Reihenfolge der Typen einer
Bitfolge am Port anschliessend?

Ich wollte ungefähr so weiter machen:

entity la_config is
  port(
    hw_conf_field : in  std_logic_vector(LA_CONF_FIELD_WIDTH-1 downto
0);
    has       : out la_config_t;
    error       : out std_logic
  );
end la_config;


architecture behavioral of la_config is

begin
  
  conf_proc: process(hw_conf_field)
  begin

    ...
    has.pcb_ver     <= hw_conf_field(5 downto 3); -- funzt
    has.num_sram    <= hw_conf_field(7 downto 6);

    -- check for misc configurations
    error         <= '0';

  end process;

end behavioral;

da gibt's den Error:
Line 49. Type of . is incompatible with type of hw_conf_field.

Schade ist's auch, dass ich für machen records für in und welche für
out machen muss, da beides nicht in einem geht.

Viele Grüße
Olaf

[ope (Gast)]

edit : line 49 ist dabei

has.num_sram    <= hw_conf_field(7 downto 6);

[ope (Gast)]

hat keiner eine Lösung? Es ist ein generelles Problem.

Versuche es mit einer Konvertierungsfunktion; klappt aber auch nicht so
recht:

  type bitwidth_t is (  -- config fields = 3
    BIT_WIDTH_8,
    BIT_WIDTH_16,
    BIT_WIDTH_24,
    BIT_WIDTH_32,
    BIT_WIDTH_40,
    BIT_WIDTH_48,
    BIT_WIDTH_56,
    BIT_WIDTH_64
  );

  ...

  function to_bitwidth(vec : std_logic_vector) return bitwidth_t is
    variable bw : bitwidth_t;
  begin
    case (vec) is -- LINE 137
      when x"0" => bw := BIT_WIDTH_8;
      when x"1" => bw := BIT_WIDTH_16;
      when x"2" => bw := BIT_WIDTH_24;
      when x"3" => bw := BIT_WIDTH_32;
      when x"4" => bw := BIT_WIDTH_40;
      when x"5" => bw := BIT_WIDTH_48;
      when x"6" => bw := BIT_WIDTH_56;
      when x"7" => bw := BIT_WIDTH_64;
      -- avoid xst error, all bitwidth are handled.
      when others => bw := BIT_WIDTH_64;
    end case;
    return bw;
  end;

mit Line 137. Selector (Constant 'vec' of type std_logic_vector) is
an unconstrained array.

Tja, wie bekommt man das hin? mit to_integer(vec) gibt's:
Line 137. to_integer can not have such operands in this context.

Viele Grüße
Olaf

[ope (Gast)]

so, endlich mal ein pasendes Thema:

entity hitlength_trigger is
   generic (
      BIT_WIDTH   : positive := 8;
      RESET_ACTIVE  : std_logic := '1'
   );
   port (
      clk       : in  std_logic;
      reset       : in  std_logic;
      trig_hit      : in  std_logic;    
      hit_length    : in  std_logic_vector(BIT_WIDTH-1 downto 0);
      match       : out std_logic
   );
end hitlength_trigger;


architecture behavioral of hitlength_trigger is

   signal m_hitcount : std_logic_vector(BIT_WIDTH-1 downto 0);
   constant ZERO   : std_logic_vector(BIT_WIDTH-1 downto 0) := (others
=> '0');

begin

   proc: process (clk, reset) is
   begin

      if (reset = RESET_ACTIVE) then
         m_hitcount <= (others => '0');
         match <= '0';
      elsif rising_edge(clk) then
         if (trig_hit = '0') and (hit_length /= ZERO) then 
            m_hitcount <= (others => '0');
         elsif (hit_length /= ZERO) then
            m_hitcount <= m_hitcount + 1;
         end if;

         if (m_hitcount = hit_length) and (hit_length /= ZERO) then
            match <= '1';
         end if;
      end if;

   end process;

end behavioral;

Er macht das schon ganz ordentlich - hat einen Fehler: Er zählt zB.
einen hit mit einer clk cycle Länge nicht - konsequenter Weise steht
der m_hitcount bei zwei clk cycle Länge bei eins; zählt also immer eins
zuwenig. Das ist aufgrund des synchronen Designs, wie ich ihn aber zum
"richtig zählen" überzeugen kann, ist mir noch ein Rätsel. Auch der
work-arround für hit_length /= ZERO ist etwas hässlich. Hat jemand Rat
und Lösung?

Viele Grüße
Olaf

[ope (Gast)]

ein Bild sagt mehr .... Er sollte bei t=65ns eigentlich einen match =
'1' liefern.

[ope (Gast)]

Mit dem hitlength_trigger ist noch immer im Raum, keine Lösung?

Ich probiere mich momentan mit configurationen aus:

entity ram_1536x16 is
   generic (
      RESET_ACTIVE   : std_logic := '1';
      ...
   );
   port (
      clk            : in  std_logic;
      ...
   );
end entity ram_1536x16;

architecture RAMB4_S16_banking of ram_1536x16 is
   ...
end architecture RAMB4_S16_banking;

architecture infering of ram_1536x16 is
   ...
end architecture infering;

und nun der Testbench mit dem Fehler:
** Error: ../source/tb_vhdl/TB_ram_1536x16.vhd(33): (vcom-1141)
'ram_1536x16' is not a component declaration

entity tb_ram_1536x16 is
end entity tb_ram_1536x16;

architecture behavioral of tb_ram_1536x16 is

   for all : ram_1536x16 use entity work.ram_1536x16(infering); -- 33

   ...
begin
   ...
end architecture behavioral;

So habe ich es zumindest aus den Büchern so verstanden. Wie geht es
richtig?

Viele Grüße
Olaf

[unknown (Gast)]

probier mal:

for all ram_1536x16 : use entity work.ram_1536x16.infering;

[ope (Gast)]

Ist das nicht der Syntax, wie er in configurationen benutzt wird? D.h.
nach der arch noch conf ... In der archirecture selbst funzt es nicht.

[ope (Gast)]

OK, für folgende Probleme habe ich noch keine Lösung:

* [http://www.mikrocontroller.net/forum/read-9-234597.html#241016
hitlength]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#241453 vhdl
configuration]

Ganz neu: internes sram timing eines xc2s... Das schreiben und lesen
des blockrams klappt schon recht gut. Allerdings werden alle Aktionen
auf rising_edge ausgeführt. Das hat zur Folge, das ich (ich vermute es
mal) einen Takt später auch "ein" schreibe, und man kann es im TB
auch sehen, beim Auslesen meine Daten einen Takt später bekomme.

Sehe ich mir das Timing Modell im Datenblatt
[http://direct.xilinx.com/bvdocs/publications/ds001.pdf S.35] an, so
muss/sollte die Adresse vor rising edge anliegen damit spätestens zu
fallend Flanke die Daten von der Adresse anliegen. Dies ist derzeit
nicht der Fall.

So, nun die Frage dazu: Handel ich mir damit Ärger ein, da der ram
nicht registered ist? Auf rising/falling edge irgendwelche Aktionen zu
machen, wurde irgendwo hier im Forum als kontraproduktiv eingestuft.
Wäre eine neg. clock Signal => clk180 und rising edge darauf eine
Hilfe? Was macht man wie kleverer Weise?

Nachfolgend der Anfang einer Schreib- und Lesesequenz. Man beachte, ich
schreibe (hoffentlich) auf Adr. 0x00 den Wert 0xFFD3 und lese dann bei
0x00 0x16E8 (wo immer die her kommen mögen), welches imo irgendwelcher
Datenmüll ist (Erklärung/Lösung gesucht) und auf dem nachfolgenden
rising_edge meine 0xFFD3 wieder - eben 1 clk cylce verzögert.


Viele Grüße
Olaf

[ope (Gast)]

schreibe

[ope (Gast)]

lese

[ope (Gast)]

als zip

[ope (Gast)]

für folgende Probleme habe ich noch immer keine Lösung:

* [http://www.mikrocontroller.net/forum/read-9-234597.html#241016
hitlength]
* [http://www.mikrocontroller.net/forum/read-9-234597.html#241453 vhdl
configuration]

Inzwischen bin ich wegen der sram Ansteuerung (Timing) in der 6 Version
angekommen, mit der FSM ist evtl. doch gar nicht so schlecht, erspare
ich mir den mux/demuxer und die Kopfstände innerhalb der fsm wegen der
Ansteuerung dieser.

Kurz zum Prinzip: XC2S100 hat 40.960 bit.
- Speicher organisiert zu 512x80 (infering z.Zt., using blockram hat
noch einen nebensächlichen bug derzeit)
- Sampels bestehen aus 10 bit timestamp und den eigentlichen Samples zu
16bit; allg. unter dem Term "samples" desweiteren benutzt
- somit passen in die 80 bit 3 sample tuple, diese werden in der fsm
eingeschrieben.
- ausgelesen werden diese 80 bit byte weise durch die fsm.
- kont. Schreiben in den Ringbuffer (noch zu implementieren)
- bei aquire Startaddr. merken und bis zu x% Vorgeschichte
vollschreiben (noch zu implementieren)

Problem:
- Beim Auslesen fehlt das erste Byte. Keine Idee, wie ich
sinnvollerweise da ran kommen, habe schon einen 'pre'-state rd_state
vor den eigentlichen rd_b{0-11}_state gesetzt, ein weiterer sollte an
sich nicht nötig sein. Evtl. schreibe ich aber in das erste Byte Mist,
aber eher unwahrscheinlich durch die (2+8) byte des Timestamps.
- Warning mit unbekannter Ursache:
# run this TB 32 us!** Warning: There is an
'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the result will
be 'X'(es).
#    Time: 16040 ns  Iteration: 1  Instance: /tb_sample_ram/dut/fsm
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
arithmetic operand, the result will be 'X'(es).
#    Time: 16040 ns  Iteration: 2  Instance: /tb_sample_ram/dut/fsm

Sonstiges:
- Hinweise für den Aquire Mode?

Viele Grüße
Olaf

[ope (Gast)]

hier die interessante Stelle.

[ope (Gast)]

0 download vom src vom 23.10.2005 17:14 ?? Hat denn keiner Interesse
mehr am logic analyser?

[Antti (Gast)]

Hi Ope,

was erwartest du denn?

ein LA ist etwas dass aller gerne haben mochten, ofr frei oder
supergunstig. ein LA ipcore zu entickeln ist eigentlich kein grosseres
problem. auch die auswertung software ist nicht so schwer. und die
firmware kommunikation ist auch nichts schweres. aber das bedeutet noch
langst nicht das es so einfach ist ein 'einfaches und benutzbares
produkt' fertig zu kriegen :( lettzendlich muss jemand die handbucher
usw weiteres auch erledigen und das ist für ide hardcore entwickler
extrem langweilig.

ICH bin SEHR interessiert an LA, oder besser im OCI (On Chip
Instrumenation), dh LA inside FPGA, mess funktionenn in FPGA und mit
FPGA, aber dieses projekt hier, well... etwas fehlt. etwas fehlt um
wirklich erfolgreich zu sein.

erstens es gibt kein richtiges ziel.

falls das ziel ist unter 100EUR ein LA zu bauen denn die beste loesung
ware USB powered XC3S100E evalikit als 'basis' zu benutzen, es koster
69USD un hat 50 poliges stecker drauf. da kann mann adapter module haben
fur comparator und zusats speicher, etc.. basis system (evalkit +
adapter platine) bleibt immerhin unter 100EUR.

falls das ziel ist etwas gutes zu machen, dann sollte mann die besten
komponent aussuchen die man noch kriegt ohne ZILLION zu bezahlen. und
dann sollte man das preis ausrechnen was d sich ergibt.

FPGA is eigentlich billig und kommt immer billiger. mit low cost
FPGA's kann man LA mit sampling rate um 1GS/S machen. low speed grade
S3 geht bis mindestens 900MS/S (ich habe selber gemessesn clock speed
von etwa 470MHz in s3 fabric.)

was teuer ist ist schnelles speicher. das sollte man nicht sparen und
72 bit ZBTRAM benutzen.

und... LA und DSO sind sehr ahnlich so das man DSO funktionalitat auch
gleich mitbringen sollte. NI hat gerade 2GS/S ADC heraus gebracht. klar
die sind schweineteuer. aber ein high speed ADC add board interface furs
DSO funktionalitat sollte schon da sein.

es ist moeglich mit kommerzíellen herstellen zu konkurieren, mann
sollte einfach keine angst haben, und hoch traumend

antti

meine private seite :) w w w truedream o r g

mann sollte traumen, und richtig! und dann was davon auch verwirklichen
naturlich ;)

PS fur LA project macht KEIN sinn gleich eine PCB zu entwickeln, nicht
gleich noetig. es gibt haufen mengen von platinen mit FPGA und JTAG
konnektor, die alle sind potentialle platforme furs LA. es ware viel
mehr besser anfangs ALLE FPGA platinen zu unterstutzen uber JTAG, die
software un ipcores fertig und testen, und DANACH eigen hw entwickeln.

[ope (Gast)]

mmh, das mag ja alles richtig sein, aber wie soll ich dieses
vollbringen, wenn ich noch nicht einmal weiss, warum mein vhdl code
nicht das macht, was er soll. Soll heissen: Der Teufel liegt im
Detail.
Dennoch Danke für Deine Hinweise. Das DSO Feature wurde zB. wegen dem
Teufelchen gecancelt.

Viele Grüße
Olaf

[Andreas (Gast)]

Hallo,

wie ich vorher auch schon schrieb, habe ich sehr wohl noch Interesse an
diesem Projekt. Nach anfänglicher Begeisterung scheinen aber nicht mehr
viele übrig geblieben zu sein, was schade ist. Vor allem scheint die
überwiegende Arbeit an Olaf und möglicherweise ein, zwei anderen
Aktiven zu hängen. Entweder haben die übrigen, die kompetent genug
wären, keinen Bock mehr drauf, oder das Ganze ist eben doch ein wenig
anspruchsvoller, als es viele in ihrer ersten Euphorie geglaubt haben.

Was mich betrifft, ich habe absolut keine Ahnung von FPGAs oder CPLDs,
als "Wald- und Wiesenelektroniker" hatte ich damit weder privat noch
beruflich zu tun.
Sollte das Projekt dennoch fertig gestellt werden, und es wird Hilfe
bei der Erstellung einer Doku gebraucht (was sicherlich erst ganz am
Ende des Projektes wichtig werden wird), stelle ich mich gern zur
Verfügung. Fachkenntnisse sowie ein halbwegs fehlerfreies Deutsch kann
ich immerhin bieten. :) Zumal eine gute Doku zu erstellen nicht
langweilig ist.

Gruß,
Andreas

[Jens Meyer (Gast)]

Hallo,

Ich verfolge das ganze schon eine Weile und haette auch
Interesse an dem Geraet. Allerdings kann ich weder in
Sachen FPGA-Design noch bei der Eingangsstufe richtig
was beitragen (und da sehe ich die meiste Arbeit). Falls
ihr 2 seitige Musterplatinen braucht und die nicht allzu
gross sind könnte ich vielleicht helfen, einfach mal
melden wenn es soweit ist. Uebrigens habe ich den Schwenk
vom PLD zum FPGA nicht so ganz mitbekommen, gab es da
eine entsprechende Diskussion die ich uebersehen habe?

Jens

[Dirk (Gast)]

Hallo,

wir haben uns auf einen FPGA geeinigt damit wir den internen Blockram
nutzen koennen und somit kein externes Sram benoetigen. Der FPGA
vereinfacht sehr das Layout.

Das schlimmste ist nur das benoetigte Teile  schwer o. garnicht
zubeschaffen sind fuer Normalsterbliche.

Im Moment haenge ich ein bischen fest, weil ich gerne das ganze Geraet
Bus Powered am Usb betreiben moechte. Leider liefert USB keine 5V
sondern diese schwankt zwischen 5,2V - 4,4V laut USB Spec..
Um jetzt eine konstante Spannung von 5V zuerhalten benoetigt man einen
StepUpDown Wandler.

Bei diesen Wandler besteht das Problem das man keinen findet der bei
Reichelt und Co zukaufen ist.

Langsam  muss ich aber einen Kompromiss finden und werde wohl oder
uebel um eine externe Versorgungsspannung nicht herumkommen dadurch
wird die Platine wieder um einiges groesser.

Gruß,
Dirk

[stromi (Gast)]

Also ich lese auch mit grossem Interesse, ich schließe mich meinem
Vorredner an: Die FPGA-Geschicht, VHDL usw. ist dass, was ich nicht
checke und ich schätze, es geht vielen so.
Zum letzten Thema, Spannungsversorgung ? Da kann es doch nicht dran
hapern. Regler rein, Buchse drauf, externes Netzeil fertig.
Hier wundere ich mich, dass das überhaupt eine Frage wird.
Bei einem grösserem Projekt muss man dem die Einzelaufgaben geben, der
sich damit auskennt. Und bei VHDL und FPGA, wird es nicht so viele
geben.

[ope (Gast)]

>Uebrigens habe ich den Schwenk
>vom PLD zum FPGA nicht so ganz mitbekommen, gab es da
>eine entsprechende Diskussion die ich uebersehen habe?

Ja, dieser Wandel kam still und leise, ich hatte es auch mal beiläufig
in irgendeinenen Thread hier erwähnt. Hauptgund: AVR+CPLD+SRAM kommt
auf Euro Format. Vom XC2S100 versprechen wir uns nun die schon besagte
Zigarettenschachtelgröße ;-) Leider hat er nur 40kbit intern,
entsprechend muss man diesen gut organisieren (s.o.) und damit fangen
die Probleme an.

Viele Grüße
Olaf

[Stephan (Gast)]

Was wollt Ihr eigentlich noch mit 5V? Nehmt einen modernen Chip, der
läuft mit 3,3V.

Dann noch von Xilinx einen Virtex-4LX200, oder von Altera einen
CycloneII-EP1C3, dürfte das ganze Gerät machbar machen. Schnelles RAM
kann man sich auch in diese Chips hineinprogrammieren.

Allerdings wird dann der kleine, putzige Atmel arbeitslos... ;-)

Stephan.

[Antti (Gast)]

;) witzigman!

I habe den preis von LX200 nicht, aber das ist der grosste von Xilinx.
und den preis von den grossten stratix weiss ich, nahmlich runde 9,000
USD. LX200 schatze is auf jeden fall auch 5,000++

EP1 ist alternative aber cyclone 2 ist jedoch preiswertiger.

mit uralten 5V bausteinen sollte man heute NICHT mehr spielen, sei den
es handelt sich um eine fertige platine.

--

Ich habe gerade das eebit FPGA logic analazer ins VHDL translier und
zusammen mit PCI-LPT IP core in Xilinx FPGA geladen. Den original
source code für die auswerung software habe ich auch kompiliert, war
gar nicht so schwierig.

dh heisst ich habe ein LA fast fertig. in null komma nichts. :)

antti

[Stephan (Gast)]

@ Antti: Daumen hoch! :-)

Stephan.

[Antti (Gast)]

danke Stephan!

I habe

FPGA programmier in PCI slot, und kann die LA registers lesen.
die PCI inerface emuliert den LPT so das es kenne treiber noetig sind
und die LA register sind kompatible zu dem eebit design.

noch nich alles funktionier ein paar module sind noch leere
hullen aber as ist wirklich 'piece of cake' das auch fertig
zu kriegen. aber das spater heute, jetzt is schon 00:51 :)

antti

[Antti (Gast)]

FERTIG.

Software und FPGA beide O.K.

screenshot ist von FPGA in PCI slot, eingang ist ein counter als test
pattern. FPGA ist Virtex2 2000, als speicher 8 bit x 64,000 samples.
Der design baisert auf den eebit 'parallel port'
version die original software kann man fast direkt benutzen.
die Altera schematics wurde ins VHDL transliert und mit
einem PCI - LPT IP core verbunden so das ganze gerat
als LPT anerkannt wird, so das man keine windows treiber braucht.
naturlich wurde es auch am richtigen printer port arbeiten oder
mit irgenwas anderes interface wenn man die software andert.

:)

Antti

[Ppp M. (sanic)]

Hallo Antti,
das sieht ja wirklich gut aus!
Wie schnell ist das gute Stück denn ?
Was hat deine Software für Triggermöglichkeiten und co. ?

Grüße,
Patrick

[Antti L. (truedream)]

Danke.

die hardware ist register compatible zu dem eebit design und
dieselbe software kann fast direct benutzt werden.
Es gibt haufen mengen moeglichkeiten das ganze zu verbessern.

meine test system habe ich auf einer PCI FPGA karte getestet
und auch das PCI clock als sampling clock benutzt.

Wie schnell kann man nicht antworten. In prinzip sollte es
relative leicht sein etwas uber 200MHz in low cost FPGAs zu
schaffen. Mit ein bishen mehr muhe sollten sampling rates
von circa 900MS/s in low cost PFGA (Spartan-2 zb) moeglich
sein in high end FPGAs etwas uber 1G/S. Das braucht aber
ein bishen anderungen :)

Antti

[Dirk (Gast)]

Hi,

und laesst du die Allgemeinheit dran teil haben ?

Gruß,
Dirk

[Antti (Gast)]

Hi Dirk,

wenn die Allgemeinheit es nicht fur zu teuer halt dann Ja.
Ist alles komplett verfugbar von shop.openchip.org

Antti

[ope (Gast)]

Mal ein anderes Problem:

Ich habe 3 verschiedene Quellen Q0...Q2 (konkret Trigger), die unter
verschiedenen/bestimmten Bedingungen ein Signal abgeben, dass die
Bedingung erfüllt ist. Nun möchte ich diese Quellen kombinatorisch
vernüpfen, womit sich formal 9 Möglichkeiten ergeben, die jeweils durch
and/or/xor/not vernüpft werden können.

Konkret habe ich also die 3 Signale der Quellen, tja - und jetzt finde
ich keine einfache Lösung: Ein Register enthält eine Art Vektor 0...8,
der auf die Komb. der der Quellen zeigt (dispatched per case ...), ein
weiteres Register die Komb. and/or/xor/not. Letzlich eine einfache,
wenn auch starre Lösung.

Es kann aber auch möglich sein, (Q0 and Q1) or (not Q2) oder einfach
nur not Q0 bzw. Q0 - da wird diese Lösung kompliziert. Wer liefert
weitere Möglichkeiten, evtl. gleich mit VHDL Example?

Viele Grüße
Olaf

PS: Bin gerade am verkabeln der Entities, das Problem mit
http://www.mikrocontroller.net/forum/read-9-262347.html#new steht noch
immer.

[Antti (Gast)]

in Xilinx FPGA kann man ein beliebiges funktion von 4 eingangen in einem
LUT implementieren, die LUT content kann auch der benutzer laden wenn
man den slice als SRL16 verwendet, so das man fur LA trigger kann man 4
eingange trigger match in einem LUT oder 2 eingange in einem LUT falls
die flanken auch dabei sind

antti

[ope (Gast)]

@Antti: hast Du eine URL, wo man das konkrete WIE nachlesen kann?

Viele Grüße
Olaf

[Antti (Gast)]

einfach ein SRL16, nichts weiteres :)

hat 4 eingange und einen ausgang,

kann als 4 eingang LUT benutzt werden,

den LUT content kan man serial einschieben

alles einfach!

Antti

[ope (Gast)]

existiert auch eine portable Lösung?

Viele Grüße
Olaf

[antti (Gast)]

nein.
SRL16 gibts nur bei xilinx. fur alle andere muss man normale lut oder
was immer benutzen
antti

[ope (Gast)]

evtl. doch mit einem 'Combine'-Vektor? Allerdings gibt es für die
Verknüpfungen einen (2^3) und für die logischen Verknüpfungen auch noch
mal einen (xor, and, or, not 2^4) Vektor. Das schreiben macht dann auch
keinen Spass mehr, da viele case zu handeln sind. Ich hatte gehofft,
etwas mit einer Art Maske oder Ähnlichen als Lösung zu finden - komme
nur nicht 'drauf.

Viele Grüße
Olaf

[antti (Gast)]

ah es ist moeglich eine ding zu machen die ein paar generics hat
und dann furs alle familien einen generate durchfurt
so das man alles frei parametrierbar kann

wenn du selber nicht weiter kannst dann lade isplever runter
da ist irgendo ein program encode.exe

mit dieser programs kann mann lava.enc datei offnen
das den quellcode von lattice ispTRACY logic analyzer enthalt
viel spass

Antti
PS ich habe schon 2 verschieden VOLL funktionerende FPGA logic
analyzer loesungen, was machst du dennn da? alles furs spass nur?

[ope (Gast)]

gut, der erste wird wohl der auf ebay bzw. shop.openchip.org gegen Bares
sein. Der zweite besagter ispTRACY. Kannst Du nicht mit encode.exe und
lava.enc den ispTRACY encoden? Ich möchte nur ungern 800MB für den
ispLever reservieren, nur um ihn anschliessend wieder zu deinstallieren
um dann festzustellen, das mein Windows zerschossen ist.

Viele Grüße
Olaf

[Antti (Gast)]

ja kann ich machen

[ope (Gast)]

schon etwas erreicht?

[FPGA-User (Gast)]

@ope

haste die 5 Dollar bezahlt ? Sonst antwortet Antti nicht ;-)))

[antti (Gast)]

eigentlich antworte ich doch, aber, hmm wenn jemand einfach faul ist da
ist meine gegeisterung zu helfen auch minimal. Antworte habe ich ja
gegeben, aber ich wurde gebeten einen befehl auf meinem PC auszuführen
und dann ein datei zu schicken - und da nach ein bishen gedanken wurde
ich mich lieber zuruckhalten, eventuell konnte man ja sagen das es
irgenwelche urheberrechte verletzt. Wenn man das auf eigenen PC mach
ist es eine sache, aber weiterzugeben nicht so gut.

Grusse
Antti
PS in dem ebuch (8.30 EUR) da ist eigentlich fast nix nur gute
erklarung wie man 2 verschieden open-source logic analyzer design zum
leben bringt. die original designs sind im web frei verfugbar, aber..
die zeit die man damit auf eige faust totschlagen muss ist >2 tage so
dass das ebuch sich doch lohnen sollte.

[ope (Gast)]

> Ich möchte nur ungern 800MB für den ispLever reservieren, nur um ihn
> anschliessend wieder zu deinstallieren um dann festzustellen, das
> mein Windows zerschossen ist.

Nun ja, es ist schon eine gewisse Art von Faulheit. Mein Windoze ist
gut configuriert, das möchte ich nicht mal eben so platt machen. Zumal
ich nicht weiss, dass ich dort das finde, was ich suche (s.o.). Mal
abgesehen davon habe ich den Platz gar nicht (ich platze aus allen
Nähten =).

Aber wieder zurück zum Thema:

Synthese klappt nicht: Ich bekomme von xst die ober-schlaue Error
Meldung:

Type of i is incompatible with type of ..

von

   tlc : process (clk, rst_triggers) is
      variable i      : unsigned(trigger_cond.length_value'range);
      variable m_down : boolean;
   begin
      if (rst_triggers = RESET_ACTIVE) then
         i                := (others => '0');
         m_down           := false;
         hit_length_match <= '0'; 
      elsif rising_edge(clk) then
         if (tlc_ce = '1') and not m_down then
            if (i = 0) then
               m_down           := true;
               hit_length_match <= '1';
            else
               i := i - 1;
            end if;
         elsif (tlc_ce = '0') then 
            i := trigger_cond.length_value; -- HIER IST DER ERROR
         end if;
      end if;
   end process;

mit

   type trigger_cond_t is
   record
      ...
      length_value : unsigned(LA_HIT_LENGTH-1 downto 0);
   end record;

Ich bin recht ratlos, was er von mir will. Im Grunde ein nachladbarer
Zähler, nachgeladen bei tlc_ce /= '1'. Monostabil eben.

Viele Grüße
Olaf

[Sssssss (Gast)]

>variable i      : unsigned(...)
und
>i                := (others => '0');
Müsste das letzte nicht
i := 0;
heissen ?

[Antti (Gast)]

guter ratschlag fur VHDL: verwende NUR std_logic und std_logic_vector da
ist es meistens immer sicher was rauskommt.

antti
tut mir leid deine festplatte, und vielleicht hatte ich ein email auch
rausgeschickt aber habe deine email nicht gefunden :(

[ope (Gast)]

offenbar kann ich mir auf die Schulter klopfen - ich habe bzgl. dem tlc
Problem von oben einen bug in den xst gefunden. Packe ich den process
in eine entity - na ratet mal - klappt es.

Nicht sehr Vertauen erweckend. Offenbar muss man wie bei den C/C++
Compilern immer mehrere Synthese Tools zur Hand haben. Was nehme ich
nur? Quartus oder ispLever?

Viele Grüße
Olaf

[Thorsten (Gast)]

Hallo,

welche FPGA wurde denn ausgewahelt und wie gross waere die
Speichertiefe? (Bytes x Samples)

Schoene Gruesse aus London

Thorsten

[ope (Gast)]

mhh, London, coole Stadt ;-)

Momentan ist der XC2S100 bzw. XC2S200 (prefered)
(http://direct.xilinx.com/bvdocs/publications/ds001.pdf)
"state-of-the-art". Speicher ist 40k bzw 56k, wobei nur
Sampleänderungen abgespeichert werden um den Blockram (echter interner
RAM) besser ausnützen zu können. Yep, er ist veraltet etc., aber
verfügbar und im TQ144 oder PQ208 (prefered, da derzeitig bestellbar)
verhältnissmäßig preiswert zu bekommen. Siehe auch
http://www.mikrocontroller.net/forum/read-1-204570.html#new.

Z.Zt. bastel ich die einzelnen Entities zusammen und prüfe auf
Synthesefähigkeit, vereinfache und fasse signale zusammen. Aktuell ist
SPI zur Kommunikation vorgesehen, den Anschluss FPGA/SPI übernimmt dann
ein ARM (SAM7), da er billiger wird als ein FTDI. Auch ermöglicht er
einige Features wie Kompression u.a.

Als PC Frontend favorisere ich C++ und FoxToolkit, bin aber über die
Installation von mingw/msys noch nicht hiaus gekommen. Win32 Programing
ist für mich neu (endlich mal wieder etwas Neues nach VHDL).

Viele Grüße
Olaf

[Andreas (Gast)]

Machst Du neben der Hardwareentwicklung auch noch die Software?
FoxToolkit? Hm ... ich kenne einige Frontends, aber davon habe ich noch
nie gehört. Wie bist Du darauf gekommen?

Gruß,
Andreas

[ope (Gast)]

http://www.fox-toolkit.org
http://wiki.wxwidgets.org/wiki.pl?WxWidgets_Compared_To_Other_Toolkits
http://lists.trolltech.com/qt-interest/2002-06/msg01202.html

Für C++ ist imo WxWindows, Qt und eben Fox-Toolkit interessant.
WxWindows/WxWidgets hat Altlasten, die gehen bis Win 3.1 zurück, Qt
behagt mir die Geschichte mit den Moc Compiler nicht; auch wenn ich mit
Qt bereits (gute) Erfahrung habe, aber die neue Politik unter Windows
behagt mir nicht - der wird der Compiler vorgeschrieben, aber man wird
mit dem mingw alleine gelassen. Von der Seite her gibt's für mich
keinen Grund unbedingt Qt nehmen zu müssen. FLTK und Gtk lasse ich mal
ganz aussen vor.
Auch sollen viele Dinge in Fox besser gelöst sein, allerdings ist diese
auch jünger, so dass wohl auch einige GUI Klassen geschrieben werden
müssen. Mal sehen, ob sich Cairo
(http://cairographics.org/introduction) einbinden lässt, dann hätte man
gleich PDF Wave Plot Export prints und bessere Screen Graphic (kann aber
auch Overkill sein). Jedoch sind diese Aussagen eben ungeprüft.

Werde demnächst einen Thread unter PC Programmierung eröffnen müssen,
mal sehen, wer alles mit proggen möchte. Bis alles funktioniert, kann
man ja mit dummy Daten testen - bis alles richtig funktioniert, vergeht
eh noch etwas Zeit. Evtl. lohnt sich ja ein Projekt unter sourceforge
wegen dem cvs. Zumindest sollte es einen Grundkonsens finden um nicht
für jedes LA Projekt (alleine im Forum hier sheint es mind. 3
verschiedene Ansätze zu geben) ein neues Frontend entwerfen zu müssen
(Trennung Kommunikation/Daten und ihre Darstellung); Sprich die
klassischen OO Paradigmen.

Sicher gibt's tausende Gründe andere Sprachen zu nehmen, aber der es
programmiert sollte die Entscheidung treffen - es aber auch bis zu Ende
führen.

Derzeit bekomme ich unter mingw fox nicht als dll compiliert, scheint
ein Win32 Problem zu sein (progge selbst iA. unter unix und linux).

Viele Grüße
Olaf

[ope (Gast)]

wiki update.

Letztens schrie ich noch: Er lebt noch. Inzwischen würde ich sagen, er
steckt fest und ist in einem Dämmerzustand.

Viele Grüße
Olaf

[FPGAküchle (Gast)]

#offenbar kann ich mir auf die Schulter klopfen - ich habe bzgl. dem
tlc
#Problem von oben einen bug in den xst gefunden. Packe ich den process
#in eine entity - na ratet mal - klappt es.

IMHO ist es kein problem vom xst sondern von der unsigned Bibliothek.
Wahrscheinlich steht vor der entity in der du den prozess gepackt hast
ander
use anweisungen als vor der package in der das record steht. Und in den
Bibliotheken die du verwendest wird mehrmals unsigned definiert. Damit
ist
scheinen zwar zwei Signale/Variabken vom gleichen Typ (nämlich
unsigned) zusein. Wenn aber dieses Unsigned unterschiedlich definiert
ist (weil in verschiedenen benutzen Bibliotheken mehrmals) da sind die
beiden Variablen von versch. Typ obwohl beise unsigned heissen. Also
immer nur eine Bibliothek verwenden in der unsigned vorkommt.