Post Analysis

[ope (Gast)]

Meine VHDL Modelle (ein Großteil zumindest) sind geschrieben und mit
einem TB bzgl des Verhaltens getestet. In XST kann ich mir nun Post
Synthese VHDL Files kreieren lassen. Nun liegen die Files im Xst Dir
und nicht im Source Dir, na gut.

Die Frage ist, wie kann ich meinen bisherigen TB zur Post Synthese
Simulation benutzen? Mittels configurationen? Kann man den post
synthesis architecture default Namen ändern?, er ist "Structure" und
kann leicht zur Namenskollisionen führen. Sinnvoll wäre auch eine
Änderung des Ausgabeverzeichnisses.

Da ich die "do" scripte verwende, habe ich aber auch keine grosse
Lust jedesmal die neuen post synth. vhdl Files hinzu zuschreiben.

Wie macht ihre die Post Synthese? Mal von den kommenden Problemen bei
der Auswertung abgesehen, von denen ich bereits gelesen habe.

Viele Grüße
Olaf


PS: Happy XMas

[Sven Johannes (Gast)]

Moin...

Womit simulierst du denn?
Wenn der Modelsim eingebunden ist, kannst du die entsprechenden Modelle
(Source, post Synthesis, post Routing) direkt anwählen. Das Tcl/Tk
Skript zum Aufruf wird automatisch generiert und um die
Namensverwaltung braucht man sich händisch nicht kümmern.

--
 Sven Johannes

[ope (Gast)]

Vielen Dank! Nutze Xilinx Webpack, also Modelsim. Da gibt's im ISE
(nach Einfügen des TB im Navigator) wirklich die Möglichkeit diese
Modell zu testen.

Allerdings gehen jetzt die (unerwarteten) Fehler auf. Modelsim meldet
plötzlich "Unknown identifier" bzgl der Generics im TB. Beim
Anschauen des Post Synthesis Modells fehlen auch wirklich die Generics,
auch hat xst aus meinem unsigned Vector einen std_logic_vector gemacht -
damit habe ich nun nicht gerechnet (eher Timing/Verhaltensfehler).

Habe ich hier irgendeinen prinzipiellen Fehler?

Viele Grüße
Olaf

[Sven Johannes (Gast)]

Moin...

Generics in Testbenches sind ein besonderer Fall. Verdreht unser
Mentor-Mensch auch immer die Augen, habe ich mir bereits abgewöhnt, ein
Kollege hier besteht aber drauf.

Die Generics müssen in der Synthese natürlich aufgelöst werden und
durch konkrete Werte ersetzt werden. Warum der ModelSim das nicht
frisst ist natürlich beliebig dusselig zu erraten. Ist dein "Problem"
klein genug um es zu veröffentlichen?

--
 Sven Johannes

[ope (Gast)]

leider nein (das LA Projekt). Vom Prinzip her:

entity foo is
  generic (
     BIT_WIDTH : natural := 8;
  ...

und im TB

   constant BIT_WIDTH : natural := 8; 

   DUT: entity work.foo
      generic map (
         BIT_WIDTH        => BIT_WIDTH,
   ...

In dem Post Translate (entspricht das dem Post Synthese Modell?) sind
die generics alle bereits aufgelöst und das design platt getreten, bei
den records wurde ein name mangeling durchgeführt. Klar, dass dann mein
TB aus der Functional Simulation nicht mehr passt (zumindest bzgl. der
Generics). Ich habe aber auch keinen Schalter dafür gefunden (7.1.04
Web Editition).

Bis jetzt habe ich mir immer meine do scripte zusammengebastelt mit
ihren Depencies. Im ISE ist es mir noch nicht gelungen, diese
einzuführen. Nur Modelsim (MS) hat eine Compile Order. Da aber direkt
MS aus ISE aufgerufen wird, nutzt mir mein Script nichts, auch kein MS
Projekt. Die tolle Hierarchy mit den packages im ISE ist wohl nur
Makulatur, ich musste nach dem Aufruf aus dem ISE die packages in MS
selbst compilieren.

Viele Grüße
Olaf

[ope (Gast)]

ok, mal ausführlicher:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-- pragma synthesis_off
use std.textio.all;
use work.image_pkg.all;
-- pragma synthesis_on

use work.pkg_config.all;
use work.pkg_trigger.all;


package pkg_la_register is

   -- Base/Offset Address and Bit Index Types:
   subtype addr_t is unsigned(7 downto 0);
   subtype addr_base_t is unsigned(addr_t'range);
   subtype addr_offset_t is natural range 0 to 15;
   subtype bit_offset_t is natural range 0 to 15;

   -- Base/Offset Addresses:
   -- |7.6.5.4.3.2.1.0|
   -- |T.T.S.C.-.O.O.O|
   -- T = Trigger Base Register
   -- S = Status Base Register
   -- C = Control Base Register 
   -- O = Offsets
   constant TRIGGER0_BASE    : addr_base_t := (7   => '1', others =>
'0');
   constant TRIGGER1_BASE    : addr_base_t := (6   => '1', others =>
'0');
   constant EXT_TRIGGER_BASE : addr_base_t := (7|6 => '1', others =>
'0');
   constant CONTROL_BASE     : addr_base_t := (5   => '1', others =>
'0');
   constant STATUS_BASE      : addr_base_t := (4   => '1', others =>
'0');

  
----------------------------------------------------------------------------
   -- WRITE MODE
  
----------------------------------------------------------------------------

   -- address offsets of internal trigger register
   constant TRIGGER_PATTERN_VALUE   : addr_offset_t := 0;
   constant TRIGGER_PATTERN_MASK    : addr_offset_t := 1;
   constant TRIGGER_EDGE_RISING     : addr_offset_t := 2;
   constant TRIGGER_EDGE_FALLING    : addr_offset_t := 3;
   constant TRIGGER_EDGE_MASK       : addr_offset_t := 4;
   constant TRIGGER_COMBINE         : addr_offset_t := 5;
   constant TRIGGER_LENGTH_VALUE    : addr_offset_t := 6;
   -- internal trigger pattern/edge combine bits
   constant TRIGGER_PECOMB0_BIT     : bit_offset_t  := 0;
   constant TRIGGER_PECOMB1_BIT     : bit_offset_t  := 1;
   constant TRIGGER_PECOMB2_BIT     : bit_offset_t  := 2;
   constant TRIGGER_INVERT_BIT      : bit_offset_t  := 3;
   -- external trigger settings
   constant EXT_TRIGGER_ACT_LVL_BIT : bit_offset_t  := 0;
   constant EXT_TRIGGER_INVERT_BIT  : bit_offset_t  := 1;  -- unused
   -- control address offsets
   constant CONTROL_CMD             : addr_offset_t := 0;
   constant CONTROL_CLK_DIVIDER     : addr_offset_t := 1;
   constant CONTROL_POSTTRIGGER_MEM : addr_offset_t := 2;
   constant CONTROL_TRIGGER_SELECT  : addr_offset_t := 3;  -- int/ext
   -- control trigger select bits
   constant CONTROL_TRIGGER_INT_BIT : bit_offset_t  := 0;
   constant CONTROL_TRIGGER_EXT_BIT : bit_offset_t  := 1;

   -- control register commands
   type command_t is (
      idle,
      run,
      stop,
      reset,
      ld_clkdiv);

  
----------------------------------------------------------------------------
   -- READ MODE
  
----------------------------------------------------------------------------

   -- trigger matching address offsets
   constant TRIGGER_COND_MATCH : addr_offset_t := 0;

   -- status trigger match bits
   constant TRIGGER_COND_MATCH_PATTERN_BIT : bit_offset_t := 0;
   constant TRIGGER_COND_MATCH_EDGE_BIT    : bit_offset_t := 1;
   constant TRIGGER_COND_MATCH_LENGTH_BIT  : bit_offset_t := 2;

   -- status offsets
   constant STATUS_TRIGGER   : addr_offset_t := 0;
   constant STATUS_ERRORCODE : addr_offset_t := 1;

   -- status bits
   constant STATUS_INT_TRIGGER_MATCH_BIT : bit_offset_t := 0;
   constant STATUS_EXT_TRIGGER_MATCH_BIT : bit_offset_t := 1;
   constant STATUS_TRIGGER_MATCH_BIT     : bit_offset_t := 2;

  
----------------------------------------------------------------------------
   -- convenience types
  
----------------------------------------------------------------------------
   type control_register_t is record
      command : command_t;
   end record control_register_t;

   type config_register_t is record
      clk_divider        : unsigned(LA_CLKDIV_LENGTH-1 downto 0);
      posttrigger_mem    : unsigned(3 downto 0);  -- 0 to 8 (9 values)
      trigger0_cond      : trigger_cond_t;
      ext_trigger_cond   : ext_trigger_cond_t;
      enable_trigger_int : std_logic;
      enable_trigger_ext : std_logic;
   end record config_register_t;

   type status_register_t is record
      trigger0_match    : trigger_match_t;
      int_trigger_match : std_logic;
      ext_trigger_match : std_logic;
      trigger_match     : std_logic;
      error_code        : unsigned(7 downto 0);
   end record status_register_t;

  
----------------------------------------------------------------------------
   -- OTHERS
  
----------------------------------------------------------------------------
   procedure check_pkg_sanity;
   procedure c_header (constant fname : in string);

   function slv2pec (signal slv : std_logic_vector) return
pattern_edge_comb_t;
   function slv2cmd (signal slv : std_logic_vector) return command_t;

end package pkg_la_register;

-------------------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-- pragma synthesis_off
use std.textio.all;
use work.image_pkg.all;
-- pragma synthesis_on

use work.pkg_config.all;
use work.pkg_trigger.all;
use work.pkg_la_register.all;


entity la_register is
   
   generic (
      BIT_WIDTH      : natural   := 16;
      RESET_ACTIVE   : std_logic := '1';
      WRITE_C_HEADER : boolean   := false;
      C_HEADER_FILE  : string    := "la.h");

   port (
      clk              : in  std_logic;
      reset            : in  std_logic;
      rd               : in  std_logic;
      wr               : in  std_logic;
      address          : in  addr_t;
      rd_data          : out std_logic_vector(BIT_WIDTH-1 downto 0);
      wr_data          : in  std_logic_vector(BIT_WIDTH-1 downto 0);
      config_register  : out config_register_t;
      control_register : out control_register_t;
      status_register  : in  status_register_t);

end entity la_register;

wird breitgestampft zu:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
library SIMPRIM;
use SIMPRIM.VCOMPONENTS.ALL;
use SIMPRIM.VPACKAGE.ALL;

entity la_register is
  port (
    clk : in STD_LOGIC := 'X'; 
    status_register_trigger0_match_pattern : in STD_LOGIC := 'X'; 
    status_register_trigger0_match_length : in STD_LOGIC := 'X'; 
    reset : in STD_LOGIC := 'X'; 
    rd : in STD_LOGIC := 'X'; 
    status_register_int_trigger_match : in STD_LOGIC := 'X'; 
    status_register_trigger0_match_edge : in STD_LOGIC := 'X'; 
    wr : in STD_LOGIC := 'X'; 
    status_register_ext_trigger_match : in STD_LOGIC := 'X'; 
    status_register_trigger_match : in STD_LOGIC := 'X'; 
    config_register_ext_trigger_cond_active_level : out STD_LOGIC; 
    config_register_enable_trigger_ext : out STD_LOGIC; 
    config_register_trigger0_cond_invert : out STD_LOGIC; 
    config_register_enable_trigger_int : out STD_LOGIC; 
    address : in STD_LOGIC_VECTOR ( 7 downto 0 ); 
    status_register_error_code : in STD_LOGIC_VECTOR ( 7 downto 0 ); 
    wr_data : in STD_LOGIC_VECTOR ( 15 downto 0 ); 
    config_register_clk_divider : out STD_LOGIC_VECTOR ( 7 downto 0 );

    config_register_trigger0_cond_pattern_mask : out STD_LOGIC_VECTOR (
15 downto 0 ); 
    config_register_trigger0_cond_edge_mask : out STD_LOGIC_VECTOR ( 15
downto 0 ); 
    config_register_trigger0_cond_length_value : out STD_LOGIC_VECTOR (
7 downto 0 ); 
    control_register_command : out STD_LOGIC_VECTOR ( 2 downto 0 ); 
    rd_data : out STD_LOGIC_VECTOR ( 15 downto 0 ); 
    config_register_posttrigger_mem : out STD_LOGIC_VECTOR ( 3 downto 0
); 
    config_register_trigger0_cond_edge_falling : out STD_LOGIC_VECTOR (
15 downto 0 ); 
    config_register_trigger0_cond_edge_rising : out STD_LOGIC_VECTOR (
15 downto 0 ); 
    config_register_trigger0_cond_pattern_value : out STD_LOGIC_VECTOR
( 15 downto 0 ); 
    config_register_trigger0_cond_pattern_edge_comb : out
STD_LOGIC_VECTOR ( 1 downto 0 ) 
  );
end la_register;

Klar, dass dann der TB nicht mehr passt. Irgendwelche Hinweise? Möchte
nur ungern alles umschreiben auf RTL. Hat Quartus das gleiche Problem?

Viele Grüße
Olaf

[ope (Gast)]

keine 'ne Idee was ich bzw. xst da falsch macht?

Viele Grüße
Olaf

[ope (Gast)]

Kann es sein, dass für die Postsynthesis Simulation (schätze mal auch
für die Post Mapping etc.) die generics des TB einfach weggelassen
werden müssen, d.h. der TB mit den Generic Defaults läuft? In diesem
Fall müsste ich dann für die Functional/Post Synthesis Simulation den
map generic part mit pragma synthesis_off/on "klammern" (mal
probieren); was aber wohl nicht gehen wird - hier fehlt dann wirklich
ein ifdef Konstrukt in der Sprache VHDL.

Das nach der Postsynthese der unsigned nicht mehr existiert ist zwar
ärgerlich, aber umgehbar. Annti schrieb 'mal, immer nur
std_logic_vector zu benutzen, trifft dieses generell zu oder nur auf
die Ports? Intern in der architectutr würde ich wieder mit unsigned
arbeiten.

Wie macht ihr die Postsynthese: keine Generics, nur std_logic?

Viele Grüße
Olaf

[ope (Gast)]

na ja, meine records erleiden ja auch einem namemangeling, so einfach
geht's wohl doch nicht. Wäre ein "TB-Port-Wrapper" eine
Möglichkeit?

Werde demnächst mal Web/ISE 8.1 probieren.

Viele Grüße
Olaf

[Xenu (Gast)]

Es gibt da eine tolle Erfindung, die nennst sich Suchmaschine, die
solltest Du mal ausprobieren.

Wenn ich bei Google die Suchbegriffe "testbench generic xilinx"
eingebe,
kommt an zweiter(!) Stelle ein Link auf die Xilinx-Antwortdatenbank mit

der Antwort auf Deine Frage.

Lustig, oder?

Du könntest natürlich auf gleich in der Xilinx-Datenbank suchen.
Wenn ich da "testbench generic" eingebe, kommt die Antwort an erster
Stelle...

[Klaus F. (kfalser)]

Du brauchst nur eine neue Top-Level Entity ohne Generics schreiben,
welche eine Instanz Deiner konfigurierbaren Komponente enthält. Diese
Instanz wird mit den gewünschten Generics aufgerufen.
Schließlich ist es ja meisten so, daß man zwar die Komponenten
generisch hält, damit man sie wiederverwenden kann, aber bei der
Synthese für ein bestimmtes Projekt ergeben sich die Werte der Generics
(fast) immer aus den Spezifikationen (z.B. Busbreite).

Wenn Du dies machst, dann stimmt die Interface Beschreibung für deine
selbstgeschriebene Architecture und die vom Compiler überein und Du
hast keine Probleme über Configurationen die gewünschte architecture
auszuwählen.
Den Namen der generierten Post-Synthese Architecture kann man wählen,
ebenso wie den Filenamen. Außerdem ist es günstig, im generierten
VHDL-File die Interface-Beschreibung zu unterdrücken.
Du kannst dann das generierte File einfach in Deine Work-Library
kompilieren und voilà!, Du hast Deine Top-Level Entity mit 2
architectures.
Schreibe ein 2 Konfigurationen für Deine Testbench, eine für einen
Aufruf mit Deiner Architecture und eine für einen Aufruf mit der vom
Compiler generierten.
Oder ändere deine Testbench indem Du beide Architectures aufrufst und
die Ausgangssignale vergleichst.
Grüße
Klaus

[Karl (Gast)]

was bezweckt eine post simulation überhaupt?
ein design muss man doch sowieso auf der hardware verifizieren. deshalb
bringe ich mein design nach einer verhaltenssimulation auf das board und
teste dann die gewünschten funktionen.

[Xenu (Gast)]

>ein design muss man doch sowieso auf der hardware verifizieren.

Stimmt. Aber mit der Begründung kannst Du Dir jede Simulation sparen.
Wenn Du grundsätzlich fehlerfreie Designs erstellst, Respekt!

>deshalb bringe ich mein design nach einer verhaltenssimulation auf
>das board und teste dann die gewünschten funktionen.

Und was passiert wenn Dein Design sehr zeitkritisch ist und es durch
Laufzeiten z.B. zu gleichzeitigen Buszugriffen kommt? Wie willst Du das
denn mit 'nem Oszi rausfinden? Im Simulator sieht man das sofort.
Evtl. machst Du Dir sogar Deine Hardware kaputt.

[Karl (Gast)]

@ xenu:
dein sarkasmus in allen ehren...(denn schliesslich bist du immer recht
hilfreich bei fragen hier im forum)

bin bisher immer ohne post simulation ausgekommen.
laufzeitverzögerungen sind sicherlich ein störendes problem, aber auch
mit messungen feststellbar, denn schliesslich kann man das erwartete
Ergebnis nachmessen.
wenn die post simulation so wichtig ist, warum hilfst du nicht bei opes
problem, sondern einen herablassenen kommentar? keiner ist
vollkommen....

[Xenu (Gast)]

>wenn die post simulation so wichtig ist, warum hilfst du nicht bei
>opes problem, sondern einen herablassenen kommentar?

Habe ich das nicht?
Vielleicht solltest Du Dir meinen Beitrag nochmal genau durchlesen...

Gib auf der Xilinx-Seite in der Suchmaske "testbench" und "generic"
ein und das erste Suchergebniss ist die Antwort.

Wie ich oben bereits geschrieben habe.

[ope (Gast)]

Xenu meint dies hier:
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17952.

Ich wollte es zuvor mit Configurationen versuchen, bin aber nicht zum
testen bisher gekommen (kann also u.U. auch nicht funtionieren):

architecture behaviorial of TB_la_register is
...
configuration behaviorial_cfg of TB_la_register is
   for behaviorial
      for DUT : la_register
         use entity work.la_register(behaviorial);
      end for;
   end for;
end behaviorial_cfg;

configuration postsynthesis_cfg of TB_la_register is
   for behaviorial
      for DUT : la_register
         use entity work.la_register(postsynthesis)
            generic map (
               BIT_WIDTH      => 16,
               RESET_ACTIVE   => '1',
               WRITE_C_HEADER => false,
               C_HEADER_FILE  => "la.h");
      end for;
   end for;
end postsynthesis_cfg;

Das Problem (ist kein wirkliches) das ich mit der "netgen -a" Lösung
habe ist, dass ich mal eben in der Console die architecture erzeugen
muss; d.h. ich kann es wohl weder mit den do-Scripten (wäre sicher mit
tcl machbar - kann ich aber (noch) nicht) noch im ISE durchführen.
Wenn man ständig hin- und herspringt, vergisst man leicht einen
Zwischenschritt und klickt, klickt und klickt und simuliert noch mit
den alten Daten...

Schwieriger ist das platt treten der records, was imo aus Hardwaresicht
verständlich ist, aus Sicht der Simu jedoch nicht unbedingt einleuchtend
ist.

Klaus sein Ansatz werde ich ebenfalls (hoffentlich) dieses Wochenende
probieren können, auch wenn ich noch keine konkrete Vorstellung von der
Umsetzung habe.

Bei google u.a. ist das Problem die richtigen Suchbegriffe zu finden,
ich hatte gleich zu Begin der Suche zu stark eingeschränkt; man lernt
eben nicht aus.

Vielen Dank für die Hilfe und viele Grüße
Olaf

[Klaus F. (kfalser)]

Wenn
- das Design funktional verifiziert ist,
- das Timing der I/O Signale überlegt und mittels Timing Constraints
erzwungen wurde,
dann hat der Designer seinen Teil getan.
Die Post Simulation (Post Synthese und Post Place&Route) dienen dann
nur dazu zu sehen, ob die Tools Fehler gemacht haben.
Wer die Post Simulation braucht, um zu sehen ob das Timing korrekt ist,
ist wirklich ein bischen spät dran (gut, besser zu spät als nie).
Wenn man FPGA's entwirft, dann wird man meisten auf die Post
Simulation verzichten, aber jemand der ASIC's entwickelt wird sie
garantiert verwenden.

Klaus

[Karl (Gast)]

@ xenu:
habe schon in deinem o.g. beitrag feststellen können, dass du auf
ope's problem ein gegangen bist, nur gefiel mir dein ton dabei nicht,
denn schliesslich ist es ein problem gewesen, dass nicht in neuen
threads hier alltäglich besprochen wird.
dass man nicht vollkommen ist, und das man eben nicht stundenlang
sucht, gibt doch den sinn dieses forums wieder, in dem man fragen
stellen kann, in der hoffnung auf lösungsansätze und hilfreiche tipps.
es kam mir so vor, als wenn es aus deiner sicht nichts einfacheres
gibt, als lösungsansätze selber zu erarbeiten. manchmal sieht man den
wald vor lauter bäumen nicht, deshalb habe ich auf den ton deines o.g.
beitrags nicht für sehr hilfreich empfunden. du bist doch recht
erfahren in vhdl plus designumgebung, ergo musst du nicht so erfahrende
leute me so über den mund fahren. nix für ungut.

by the way, danke klaus für die aussagen der post simulation. ich habe
nach einer funktionalen verhaltenssimualtion und nach festlegen der
time constraints und der festen zuweisung der i/o pins für mein design
in einer oder direkt benachtbarten i/o banks eigentlich kaum probleme
mit meinem design bezüglich des timings gehabt. sicherlich kommt es zu
laufzeitverzögerungen, die man aber mit area constraints auch wieder
minimieren kann.

[Xenu (Gast)]

>kann ich aber (noch) nicht) noch im ISE durchführen.

Bei "Generate Post-Place & Route Simulation Model" rechte Maustaste
->
Properties. Im Properties-Fenster "Property Display Level" auf
"Advanced" stellen.
Unter "Other NETGEN Command Line Options" kannst Du jetzt "-a" mit
einfügen.

[ope (Gast)]

cool, Danke!

[ope (Gast)]

Ich habe es wie Klaus vorgeschlagen das ganze Wochenende versucht, bin
aber immer irgendwie wieder gescheitert. Dazu habe ich ein kleines
Counter Projekt zum testen initiiert (ist übersichtlicher als das LA
Projekt):

entity reciprocal_counter_g is
   generic (
      RESET_ACTIVE        : std_logic;
      BITWIDTH_TIME_CNTR  : natural;
      BITWIDTH_EVENT_CNTR : natural);
   port (
      clk         : in  std_logic;
      reset       : in  std_logic;
      start       : in  std_logic;
      stop        : in  std_logic;
      events      : in  std_logic;
      time_count  : out std_logic_vector(BITWIDTH_TIME_CNTR-1 downto
0);
      event_count : out std_logic_vector(BITWIDTH_EVENT_CNTR-1 downto
0));
end entity reciprocal_counter_g;

architecture behavioral of reciprocal_counter_g is
  ...

mit dem TB:

entity TB_counter is
end entity TB_counter;

architecture behavioral of TB_counter is
   constant RESET_ACTIVE        : std_logic := '1';
   constant BITWIDTH_TIME_CNTR  : natural   := 32;
   constant BITWIDTH_EVENT_CNTR : natural   := 32;
   ...
   component reciprocal_counter_g is
      port (
         clk         : in  std_logic;
         reset       : in  std_logic;
         start       : in  std_logic;
         stop        : in  std_logic;
         events      : in  std_logic;
         time_count  : out std_logic_vector(BITWIDTH_TIME_CNTR-1 downto
0);
         event_count : out std_logic_vector(BITWIDTH_EVENT_CNTR-1
downto 0));
   end component reciprocal_counter_g;
begin
   DUT : reciprocal_counter_g
      port map (
         clk         => clk,
         reset       => reset,
         start       => start,
         stop        => stop,
         events      => events,
         time_count  => time_count,
         event_count => event_count);

Die Postsynthese erzeugt nur die architecture "Structural" (keine
entity, switch -a bzw. in 8.1 gab es an anderer Stelle direkt die
Möglichkeit des Abschaltens).

Die neue non-generic Top-Level entity für diese synthetisierte
architecture sieht wie folgt aus:

entity reciprocal_counter_32 is
   port (
      clk         : in  std_logic;
      reset       : in  std_logic;
      start       : in  std_logic;
      stop        : in  std_logic;
      events      : in  std_logic;
      time_count  : out std_logic_vector(31 downto 0);
      event_count : out std_logic_vector(31 downto 0));
end entity reciprocal_counter_32;

architecture behavioral of reciprocal_counter_32 is
   component reciprocal_counter_g is
      generic (
         RESET_ACTIVE        : std_logic;
         BITWIDTH_TIME_CNTR  : positive;
         BITWIDTH_EVENT_CNTR : positive); 
      port (
         clk         : in  std_logic;
         reset       : in  std_logic;
         start       : in  std_logic;
         stop        : in  std_logic;
         events      : in  std_logic;
         time_count  : out std_logic_vector(BITWIDTH_TIME_CNTR-1 downto
0);
         event_count : out std_logic_vector(BITWIDTH_EVENT_CNTR-1
downto 0)); 
   end component reciprocal_counter_g;
begin
   counter32 : reciprocal_counter_g
      generic map (
         RESET_ACTIVE        => '1',
         BITWIDTH_TIME_CNTR  => 32,
         BITWIDTH_EVENT_CNTR => 32)
      port map (
         clk         => clk,
         reset       => reset,
         start       => start,
         stop        => stop,
         events      => events,
         time_count  => time_count,
         event_count => event_count);
end architecture behavioral;

Mit den Konfigurationen:

configuration behavioral_cfg of TB_counter is
   for behavioral
      for DUT : reciprocal_counter_g
         use entity work.reciprocal_counter_g(behavioral)
            generic map (
               RESET_ACTIVE        => '1',
               BITWIDTH_TIME_CNTR  => 16,
               BITWIDTH_EVENT_CNTR => 16);
      end for;
   end for;
end behavioral_cfg;

configuration synthesis_cfg of TB_counter is
   for behavioral
      for DUT : reciprocal_counter_g
         use entity work.reciprocal_counter_32(behavioral)
            for counter_32 : reciprocal_counter_g
               use entity work.reciprocal_counter_g(structural);
            end for;
      end for;
   end for;
end synthesis_cfg;

Bis zur Synthese bin ich gar nicht mal gekommen. Modelsim 6.0d
compiliert das behavioral architecture fehlerfrei durch, aber vsim
meldet nun:

Generic 'reset_active' has not been given a value.

Ich dachte durch die Konf. werden die Generics gleich gemapped. Das
Prinzip habe ich hoffentlich verstanden, nur in der Realisierung hapert
es noch ...

Viele Grüße
Olaf

[Klaus F. (kfalser)]

Du muß mit deiner Testbench "TB_counter" die Entity
"reciprocal_counter_32" testen, nicht die generische.
Wenn Modelsim die Konfiguration synthesis_cfg compiliert, erwartet sie
für DUT eine Einheit mit dem selben Interface wie
"reciprocal_counter_g", also inclusive generics. Du setzt aber
"reciprocal_counter_32" ein, welche gar keine generics hat und mit
Interface Beschreibung nicht übereinstimmt.

Grüße
Klaus

[ope (Gast)]

irgenwie bringe ich das nicht :/

Ich habe mal das besagte Testprojekt angehängt. Das Problem liegt in
diesen Configurations, die ich nicht leider hinbekomme. Die behavioral
Simu selbst klappt.

Wäre schon, wenn hier ein Muster Bsp. für die Postsynthese mit generics
entstehen würde. Das Web ist da nicht hilfreich (zumindest mit meinen
Suchbegriffen), da nur non-generics examples exisitieren - und selbst
die Tests fallen nach der Synthese mit Web/ISE 8.1 oftmals durch.

Vielen Dank und Grüße
Olaf

[ope (Gast)]

so, inzwischen komme ich zur Postsynthese (abgesehen von config
Problemen aus dem Nachbar Thread), allerdings klappt der TB nicht bei
der Simu mit dem synthetisierten Modell.

Die folgende Meldung bekomme ich vom Fitter:
WARNING:Xst:737 - Found 1-bit latch for signal <arm>.

Der entsprechende Source schaut wie folgt aus:

entity synchronized_gate is
   port (
      start    : in  std_logic;         -- start synchronizing
      stop     : in  std_logic;         -- stop synchronizing
      en       : out std_logic);        -- status of synchronized gate
end entity synchronized_gate;

architecture behavioral of synchronized_gate is
   signal arm  : std_logic;
begin
   -- arming FF (asynchronous)
   arming_ff : process (arm, start, stop) is
   begin
      if (start = '1') and (stop = '0') then
         arm <= '1';
      elsif (start = '1') and (stop = '1') then
         arm <= '0';
      elsif (start = '0') and (stop = '0') then
         -- reset arming
         arm <= '0';
      else
         -- infer latch
         arm <= arm; 
      end if;
   end process arming_ff;

   en <= arm;
end architecture behavioral;

Soll das heissen, das er das Signal arm gleich durch das signal en
ersetzt hat? Dann wäre ISE/XST sehr geschwätzig ... Die einzige
verbleibende Meldung ist noch:

WARNING:Xst:737 - Found 1-bit latch for signal <arm>.

Ich denke, er meldet hier ein impliziet generiertes latch, welches ich
imo jedoch expliziet hingeschrieben habe.

Wie dem auch sei, die entity, welche das synchronized_gate benutzt
fängt nicht an zu zählen, ich vermute mal, da das enable signal nicht
aktiv wird:

entity reciprocal_counter_g is  
   generic (
      RESET_ACTIVE        : std_logic;
      BITWIDTH_TIME_CNTR  : natural;
      BITWIDTH_EVENT_CNTR : natural);
   port (
      clk         : in  std_logic;
      reset       : in  std_logic;
      start       : in  std_logic;
      stop        : in  std_logic;
      events      : in  std_logic;
      time_count  : out std_logic_vector(BITWIDTH_TIME_CNTR-1 downto
0);
      event_count : out std_logic_vector(BITWIDTH_EVENT_CNTR-1 downto
0));
end entity reciprocal_counter_g;

architecture behavioral of reciprocal_counter_g is
   signal ce_cntr : std_logic;
begin
   -- asynchronous time/event counter gate control
   sync_time_gate : entity work.synchronized_gate
      port map (
         start => start,
         stop  => stop,
         en    => ce_cntr);

   time_counter : entity work.counter_g
      generic map (...)
      port map (en    => ce_cntr, ...);

   event_counter : entity work.counter_g
      generic map (...)
      port map (en    => ce_cntr, ...);
end architecture behavioral;

An sich habe Einstellungen wie keep/retain hierarchy eingestellt, aber
im Post Synthese Modell fehlen mir die inneren Signale, so dass es ein
Black-Box (BB) Verhalten ist, was ich in MXE zu sehen bekomme.

Habe ich trozdem noch falsche Einstellungen, dass ich zur BB komme? Wie
kommt man solchen Problemen auf die Spur?

Viele Grüße
Olaf

[ope (Gast)]

Mist, die erste Fehlermedlung ist Mist, da habe ich das Falsche
gepasted. Die Meldung lautete sinngemäß:

Warning: Signal /path/to/arm minimized.

Kann heute Abend nochmals die genaue Meldung angeben.

Viele Grüße
Olaf

[ope (Gast)]

Hier die korrekte Warnung:

WARNING:Cpld:828 - Signal 'reciprocal_counter_i/ce_cntr.SETF' has
been minimized

Viele Grüße
Olaf

[ope (Gast)]

Evtl. wäre noch wichtig, dass ich einen XC95144XL-5-TQ100 eingestellt
habe zum testen.

[Karl (Gast)]

ich habe jetzt auch mal eine post place&route simulation gestartet, aber
nach 10 minuten wieder abgebrochen, da sich nichts tut.
dauert diese simulation wirklich so lange mit ise7.1 und modelsim?
gut, lange ist relativ und richtig sich sicherlich auch nach dem
design. ich habe eine simualtionslaufzeit von 1 ms eingestellt.

[T.M. (Gast)]

Ich habe mal mein Design (Mikroprozessor, BlocKRAM, Uart, LCD-Treiber
und Kleinkram) auch einer Post Synthese Simulation unterzogen. Das
dauert wirklich so lange ;-) Nach 45 Min. waren noch nicht mal 30ms
durch gewesen. Das kostenlose Modelsim ist aber auch ausgebremst, sonst
würde ja niemand mehr die Vollversion kaufen.

Hängt aber auch sehr von der Komplexität des Designs ab...

[ope (Gast)]

hier ist die aktuelle Fassung des synchronized gates. In ISE 8.1 macht
der Fitter für CPLD XC95000 Mist, habe also einen Bug erwischt (siehe
NG comp.arch.fpga).

Die Behavior Simu dauert kaum 1s bei mir (P4/2.6GHz). Die
Post-Fit/Synthese bricht zuvor ab (Selftest).

Ich nehme an, Du hast den counter selber synthetisiert und anschl.
simuliert - yep, das dauert. Aber auch, weil versch. Freq. und je Freq.
3 versch. duty cycles (90,50,10%) durchgetestet werden. Also unten im TB
nur einen Test scharf machen.

Viele Grüße
Olaf