logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Implementacja pamięci ROM z pomocą pliku .mif i jej odczyt

nowak83 06 Wrz 2010 20:34 2733 13
REKLAMA
  • #1 8483127
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    Witam, chciałbym zaimplementować pamięć ROM za pomocą pliku .mif i sprawdzić czy poprawnie ją odczytuje i tutaj mam kilka pytań. Jak najlepiej tworzyć plik .mif z moimi danymi oraz jak później użyć tego pliku w projekcie?

    Mój plik mif
    
    1101010100
    0111111011
    1111110010
    0111110101
    1101111000
    1111010100
    1101110100
    1011111000
    1101110011
    1111010100
    .
    .
    .
    
  • REKLAMA
  • #2 8483304
    tymon_x
    Poziom 30  
    Posty: 1021
    Pomógł: 171
    Ocena: 15
    Instrukcja użytkowania Core Generator.
    Przygotowujesz plik *.coe, Przykład pliku *.coe (wystarczy notatnik, nadać rozszerzenie *.coe). Ważny jest nagłówek:
    MEMORY_INITIALIZATION_RADIX=2;
    MEMORY_INITIALIZATION_VECTOR=

    puszczasz przez Core Generator, dostajesz takie pliki *.vhd i *.mif. Uwzględniasz w projekcie Add Copy Source, opis w *.vhd odwołuje się do pliku *.mif w symulacji. *.vho zawiera już gotowy opis komponentu i połączeń (ctrl+c, ctrl+v do swojego *.vhd pliku projektu). Wykorzystuje się je tylko do symulacji!
    Opis pozostałych plików do innego użycia (np. implementacji w układ): Opis plików wytworzonych z Core Generator'a.

    EDIT.
    No chyba, że interesuje Cię ręczne klepanie *.vhd, możesz podpatrzeć jak wytwarza je Core Generator (;
  • REKLAMA
  • #3 8483914
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    Dzięki za opis jak to wygląda w Core Generator, jednak używam układu Lattica i ispLever, wiesz może jak to wygląda w tym narzędziu (IPexpress)? generalnie pobawiłem się trochę w nim, ale z tego co zauważyłem jest tam ograniczenie na 16 bitów adresowych, a potrzebuje trochę więcej(18 bitów), no i nie wiem jak się pozbyć zbędnych wejść/wyjść, wystarczyłoby mi ADDRESS(17-0): in; DATA(17-0):out.
  • #5 8484011
    J.A
    Poziom 28  
    Posty: 596
    Pomógł: 159
    Ocena: 12
    nowak83:
    Cytat:
    chciałbym zaimplementować pamięć ROM za pomocą pliku .mif

    to niby drobiazg terminologiczny, ale plik mif to zawartosc pamieci,
    ten plik, czy za pomoca tego pliku pamieci sie nie implementuje;
    pamiec mozna wygenerowac, miedzy innymi tak, jak podpowiada tymon,
    albo napisac kod, ktory wiekszosc [o ile nie wszystkie] narzedzi do syntezy
    rozpoznaje jako rom;
    ponizej 2 przyklady:
    
    module rom_mem
    (
      input                     clk,
      input      [(addr_w-1):0] address_0, address_1,
      output reg [(dat_w-1):0]  data_0, data_1
    );
    
    parameter dat_w  = 8,
              addr_w = 6;
    /// pierwszy sposob  ////
     reg [dat_w-1:0] rom0[2**addr_w-1:0];
    
     initial
      begin  $readmemh("rom_content.txt", rom0); end 
      // plik rom_content.txt to zwykly plik tekstowy w formacie:
      // 20
      // 21
      // 22
      // itd, gdzie 20 to wartosc spod adresu 0, 21 spod adresu 1 itd;
      
    
    always @ (posedge clk)
      data_0 <= rom0[address_0];
    
    /// drugi sposob ////
     reg [dat_w-1:0] rom1[2**addr_w-1:0];
    
     always @(posedge clk)
       case (address_1)
         6'h00   : data_1 <= 8'h12;
         6'h01   : data_1 <= 8'h32;
         6'h02   : data_1 <= 8'ha2;
         6'h03   : data_1 <= 8'hc2;
         6'h04   : data_1 <= 8'h34;
         ///  i t d
       endcase
    
     endmodule


    przyklad w verilogu, ale idea chyba jest jasna rowniez dla
    posugujacego sie vhdl;

    tymon
    Cytat:
    No chyba, że interesuje Cię ręczne klepanie *.vhd

    korzystanie z roznych 'generatorow' ise/quartusa/inne
    to generalnie zla praktyka a to temu, ze kod jest 'przywiazany'
    do okreslonego narzedzia, a nam inzynierom zwykle zalezy na tym,
    by dzialal na dowolnej platformie;

    J.A
  • #6 8484064
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    No właśnie moje narzędzie syntezy nie rozpoznaje "ręcznie" napisanego kodu jako ROM, stad też cala synteza trwa sporo czasu i zabiera sporo logiki z układu. chciałem to w jakiś sposób przyspieszyć i zoptymalizować ilość zużywanych bramek.
    Może istnieją jakieś atrybuty, które wymusiłyby zapisanie tego jako ROM, może się ktoś orientuje?
  • #7 8484080
    tymon_x
    Poziom 30  
    Posty: 1021
    Pomógł: 171
    Ocena: 15
    Kolega prosił o zastosowanie *.mif, to w dodatku rozpędziłem się o pakiet Xilinx'a (;
     
     library ieee;
     use ieee.std_logic_1164.all;
     use ieee.numeric_std.all;
    
    --taki przykład
    
    entity ROM is
       port (
         address : in  std_logic_vector (3 downto 0);   
         data_out : out std_logic_vector (4 downto 0));  
     end ROM;
     
     architecture BEHAVIOR of ROM is
     
       type rom_table is array (0 to 15) of std_logic_vector (4 downto 0);
     
       constant romdata : rom_table := (
         "10101",                     --pierwszy adres (nr 0) i tak dalej...       
         "11111",                            
         "10101",
         "11110",
         "10110",
         "10101",
         "11010",
         "10010",
         "10110",
         "11101",
         "10110",
         "10111",
         "00110",
         "11101",
         "10010",
         "10110"                            --nr 15
         );
     
     begin  
     ROM_data:  process (address )
       begin 
     
         data_out <= romdata(to_integer(unsigned(address))); -- lub CONV_INTEGER() z biblioteki IEEE.std_logic_arith
     
       end process;
     
     end BEHAVIOR;

    Ma tą zaletę, że wystarczy dodać do danych klauzulę "XXXX", np. wspomagając się jakimś Matlab'em czy SciLab'em i wkleić. No tam wiadomo co resztę pozmieniać (; Chociaż nie zalecam korzystania z array przy dużych danych, bo jest to bardzo nieefektywne.
  • #8 8484105
    J.A
    Poziom 28  
    Posty: 596
    Pomógł: 159
    Ocena: 12
    nowak83 napisał:
    No właśnie moje narzędzie syntezy nie rozpoznaje "ręcznie" napisanego kodu jako ROM, stad też cala synteza trwa sporo czasu i zabiera sporo logiki z układu. chciałem to w jakiś sposób przyspieszyć i zoptymalizować ilość zużywanych bramek.


    nie za wiele wiem o Lattice wiec i nie za wiele pomoge;
    nie sadze, by Lattice nie rozpoznal standardowych konstrukcji, ktore
    podalem jako przyklady pamiec rom,
    [sprobuj skompilowac jedna z wersji przykladu, by sie przekonac]
    byc moze chodzi o ograniczenia sprzetowe ?
    Moze w kostce ktora chcesz uzyc nie ma tyle pamieci ?

    jesli glowna przeszkoda jest to, ze dopuszczalna szerokosc adresu wynosi
    16, a ty potrzebujesz 18 bitow, to moze da sie 'skleic' 2 rom-y, jeden
    o 16, drugi o 2 bitowym adresie;
    podobnie z danymi, jesli to tu jest problem [jesli lattice dopuszcza maksymalnie
    16 bitowe dane]
    powodzenia

    J.A
  • REKLAMA
  • #9 8484136
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    w tej chwili kompiluje takie coś i tego nie rozpoznaje jako strukturę ROM, zajmuje sporo miejsca ale w układzie się mieszczę, chciałem to zoptymalizować, a co do Lattica to nie ma ograniczeń w ilości bitów w wektorze, tylko generator IPexpress ma, chyba pokombinuje z dwoma romami, ale wolałbym tego nie rozbijać

    
    entity mem_rom is
    	port (
    		ADDR    : in   std_logic_vector (17 downto 0);
    		DATA    : out std_logic_vector (17 downto 0)
    		);
    end entity;
    
    architecture behavior of mem_rom is
    
    begin
    
    	with ADDR select
    DATA	<=	 
                 "000000000000000000"	when	"000000000000000000",
    	          "101010010101010010"	when	"000000000000000001", 
    --			  .
    --			  .
    --			  .
    --			  .
    --			  .
    --			  .
    		       "000000000000000000"   when	others;	
    end architecture;
  • REKLAMA
  • #10 8484151
    tymon_x
    Poziom 30  
    Posty: 1021
    Pomógł: 171
    Ocena: 15
     "000000000000000000"   when   others;

    nowak83 napisał:
    w tej chwili kompiluje takie coś i tego nie rozpoznaje jako strukturę ROM...

    Oj, wystrzegałbym się tego others jak ognia w tym przypadku. Nie wiadomo jak Lattice na takie coś zareaguje. Lepiej zrobić tak jak my podaliśmy. Te metody można uznać za taki "standard".
  • #11 8484152
    J.A
    Poziom 28  
    Posty: 596
    Pomógł: 159
    Ocena: 12
    przejrzyj dokladnie komunikaty, zwlaszcza warnings, kompilatora;
    bardzo mozliwe, ze tam znajdziesz odpowiedz, czemu narzedzie
    nie jest w stanie zaimplementowac konstrukcji jako rom;
    J.A
  • #12 8487594
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    Ze względu na bardzo dużą ilość danych, przez to też zużycie logiki rozpatruje użycie RAMu, na boardzie mam 2 kości Async. SRAM (2 x 4 Mbit organized 256 words of 32bits) czyli 18 bitów na adres i 16 bitów na dane na jeden SRAM, będą mi potrzebne 18 bitów danych(16 bitów z SRAM Low i 2 bity SRAM High) i 17 bitów adresowych, po zapisie danych do ramu nie będę ich już nadpisywał(coś jak ROM), moje pytanie to jak się najlepiej do tego zabrać, jak wrzucić tam dane, żeby potem program mógł sobie je odczytywać.
  • #13 8489044
    J.A
    Poziom 28  
    Posty: 596
    Pomógł: 159
    Ocena: 12
    nowak83 napisał:
    /.../

    ja bym jednak, zanim wezmiesz sie za zewnetrzny ram,
    poeksperymentowal z IPexpress i sprobowal ten rom
    wygenerowac wewnatrz kostki, moze nie w projekcie nad
    ktorym aktualnie pracujesz, a jakims malym testowym, z tym
    rom-em tylko;
    IPexpress musi miec jakis ram/rom generator, zmieniajac
    parametry [szerokosc adresu/danych] znajdziesz w koncu
    warunki, dla ktorych pamiec jest, i dla ktorych pamiec
    nie jest implementowana;
    wtedy rozwiazanie problemu bedzie juz proste;

    uzycie zew. sram wymaga budowy jakiegos interface'u do tej pamieci,
    jakiejs logiki, ktora po starcie/reset wypelniala by te pamiec
    i jakiejs komunikacji ze swiatem zewnetrznym, by zawartosc
    pamieci sczytac i do pamieci wpisac, troche klopotliwe,
    jesli twoj projekt takiego polaczenia aktualnie nie ma;
    J.A
  • #14 8490741
    nowak83
    Poziom 10  
    Posty: 15
    Ocena: 1
    No właśnie bawiłem się już z tymi generatorami, generalnie wszystko fajnie tworzą ROM, działa poprawnie, problem pojawił się z implementacja w układzie mam za mało rejestrów EBR, przeznaczonych na pamięć, stąd też pewnie nie chciało mi zdefiniować tego od razu jako ROM, dlatego też zdecydowałem się na ten zew SRAM, który mam na boardzie, posiadam na nim również kilka interfejsów. Chciałem się dowiedzieć czy robił ktoś coś takiego i jak mniej więcej wygląda sposób implementacji tego.

Podsumowanie tematu

✨ W dyskusji poruszono temat implementacji pamięci ROM za pomocą pliku .mif oraz wyzwań związanych z używaniem narzędzi takich jak Core Generator i IPexpress w kontekście układów Lattice. Użytkownicy dzielili się doświadczeniami w tworzeniu plików .mif oraz kodu VHDL do symulacji pamięci ROM. Zwrócono uwagę na ograniczenia adresowe w IPexpress oraz na problemy z rozpoznawaniem ręcznie napisanego kodu jako ROM przez narzędzia syntezy. Wskazano na możliwość użycia zewnętrznego SRAM jako alternatywy, a także na potrzebę optymalizacji zużycia logiki w układzie. Użytkownicy sugerowali eksperymentowanie z generatorami pamięci w celu znalezienia odpowiednich parametrów do implementacji ROM.
Wygenerowane przez model językowy.
REKLAMA