Lilleendede til Big konvertering, simulering resultaterne er ikke klare ..?

[Jansi Meena]

Please hjælp mig, har jeg fået denne fil, som de siger det konverterer lidt at storendet. Et modul har jeg giver data i (0 til 33) og et andet modul har (33 downto 0) datatype. Jeg har fået at vide, at nedenstående kode vil gøre convesion

 enhed le_2_be er port (ARRAY_IN: i std_logic_vector (0 til 33)); ARRAY_OUT: ud std_logic_vector (33 downto 0)); slutningen le_2_be, arkitektur le_2_be_arch af le_2_be er begynder LE_2_BE_PROC: processen (ARRAY_IN) begynder for i i 0 til 33 loop ARRAY_OUT (i)

 

[TrickyDicky]

Det har ændret sig. Hvis man ser på det faktiske antal, vil ARRAY_OUT (0) være lig med ARRAY_IN (33). Den måde det vises, er korrekt, da 0 er MSB for array_in, og 33 er MSB for række ud. Så MSB indeksændringer. Den kode du har, er en lille smule overkil. Du kan gøre det blot ved at skrive: ARRAY_OUT

 

[Jansi Meena]

OMG, koden er ubrugelig?. Jeg har aldrig troet på den måde. Så jeg spekulerer på, hvorfor det har været brugt i mange steder .... Så selvom jeg passerer en værdi fra "downto" til "til", plejer det tal eller nummer ændres?. Du kan få yderligere mig, som jeg i høj grad er forvirret .... For eksempel, er det bare for min klarhed og koden er ingen mening.

 proces (a, b) variabel en: std_logic_vector (0 til 3) variabel b: std_logic_vector (3 til 0) begynde en (0 til 3)

 

[TrickyDicky]

Først syntaksen fejl. Du mener 3 downto 0, ikke fra 3 til 0. a) C er "0010", "0010", alene har ingen betydning, indtil påføres en gruppering. en (3 downto 0) array. bits (3 downto 1) er '0 'og bit 0 er '1'. for (0-3) bit (0 til 2) er '0 'og bit 3 er '1'. b) Det er "0010". Big endethed eller lille endethed betyder ikke noget, nummeret er det samme. Det er bare den MSB indeks, ændringer. c) nr. medmindre a og b er signaler udefra. Du kan kun sætte signaler i en følsomhed liste. Du har nu fået lokale variable a og b at tilsidesætte det eksterne signal navne. Så de interne referencer til de variabler (og du har brugt den forkerte tildelingsoperatoren, for variabler er det: =). I denne

 

[xtcx]

C vil være 0010 alene. Se Endian kun er for indekset, som Tricky sagde, og det plejer ændre din tal værdi. Modulet der lyder lidt endian hvor som data er kommet fra store, bare have lidt rækkefølge reveresed og data vil simpelthen passe ind i åbningen. Det er, når du læser lidt klogt fx at skrive 32-bit data, og når du læser (15 downto 0), vil dette ikke være lig med din (0 til 15) Men som helhed 32-bit DWORD, vil tallet værdi altid forbliver uændret. på denne måde .... 0 1 2 3 0 0 1 0 (en) 3 2 1 0 0 0 1 0 (b) Her er et (0 til 2) er ikke lig med en (2 downto 0), men stadig en = b Cleared? ... .

 

[Jansi Meena]

først og fremmest, det syntaksfejl. Du mener 3 downto 0, ikke fra 3 til 0. a) C er "0010", "0010", alene har ingen betydning, indtil påføres en gruppering. en (3 downto 0) array. bits (3 downto 1) er '0 'og bit 0 er '1'. for (0-3) bit (0 til 2) er '0 'og bit 3 er '1'. b) Det er "0010". Big endethed eller lille endethed betyder ikke noget, nummeret er det samme. Det er bare den MSB indeks, ændringer. c) nr. medmindre a og b er signaler udefra. Du kan kun sætte signaler i en følsomhed liste. Du har nu fået lokale variable a og b at tilsidesætte det eksterne signal navne. Så de interne referencer til de variabler (og du har brugt den forkerte tildelingsoperatoren, for variabler er det: =). I denne

Ja, det skulle være "downto". Tak venner. En mere tvivl, er endian ikke for bitvis?.

 

[TrickyDicky]

endethed gælder for bitvis. 31 downto 0 er storendet, 0 til 31, er lille endian (IIRC). Det kan lidt mere kompliceret med computere, fordi bytes kan være storendet når det kommer ned til bits, og lille endian når det kommer til byte bestilling. Læsning bitmapfiler er lidt af en smerte.

 

[xtcx]

Generelt vil jeg sige, MSB første ordre, hvad der nogensinde er det, lidt \ byte \ Word \ dword \ QWORD osv., er det Big-endian. Det er nemt at huske, Rite? ... Tricky:

fordi bytes kan være storendet når det kommer ned til bits, og lille endian når det kommer til byte bestilling. Læsning bitmapfiler er lidt af en smerte.

I dont forstå, hvad du forsøger at betyde her? ....

 

[TrickyDicky]

Hver byte er bestilt (7 downto 0), men så byte nul er den mindst SIG byte af den første DWORD. så lidt så er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 osv irriterende.

 

[std_match]

[TILBUD = TrickyDicky; 1073690] Hver byte er ordnet (7 downto 0), men byte nul er den mindst væ byte af det første dword. så lidt så er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 osv irriterende. [/QUOTE] Det er little-endian både bits og bytes, og jeg foretrækker det. Det kan være naturligt i vores kultur, "venstre" er først, men der er ingen "venstre" og "højre" i hardware. Jeg foretrækker, at bit 0 er den mindst betydende bit, og det byte 0 er den mindst betydende byte. De Intel-processorer er sådan. Gamle Motorola processorer som 68000 er little-endian for bit, men big-endian for bytes (31 .. 24 23 .. 16 15 .. 8 7 .. 0). Det kan se "rigtige" for et menneske, men der er ingen fordel for hardware eller software. Power PC er storendet til bits og omskiftelige for byte. I det fuldt big-endian-tilstand bits er som denne: (0 .. 7 8 .. 15 16 .. 24 25 .. 31) Bit 0 er den mest betydningsfulde. Sig du vil kontrollere, om et tal i hukommelsen er lige eller ulige. I en lille-endian (for byte bestilling) system behøver du kun at kende startadressen af ​​ordet. I et big-endian (for byte bestilling), du skal kende startadresse og ordet størrelse.

 

[xtcx]

Hvorfor mener du det, kan du sige et eksempel ... [ COLOR = "Silver"] [size = 1] ---------- Indlæg tilføjes 12:14 ---------- Forrige post var på 12:10 ------ ---- [/size] [/color]

Hver byte er bestilt (7 downto 0), men så byte nul er den mindst SIG byte af den første DWORD. så lidt så er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 osv irriterende.

(7 .. 0 \ 15 .. 8) er virkelig hovedpine Hvordan håndterer du i så fald? . Skal vi nødt til at formatere byte rækkefølge igen og derefter behandle? ..... Eller hvordan er der taget omhu i moderne arkitektur ...?

 

[std_match]

Hvorfor mener du det, kan du sige et eksempel

I et big-endian-system henvisninger peger på den mest betydende byte (den første byte)?. For at finde den mindst betydende byte skal du kende ordet størrelse. Du får et lignende problem, hvis du ønsker at gøre en multi-word/byte adder eller en seriel adder. Du skal starte med den laveste ordet / byte / bit.

(7 .. 0 \ 15 .. 8) er virkelig hovedpine

std_logic_vector (7 downto 0) betyder ikke, at bit 7 er den første bit. Det er "venstre" bit. Den hardware, der ikke bekymrer sig om "venstre" eller "højre", så hvorfor siger, at bit 7 er den første? Jeg tror, ​​at alt er lettere, hvis jeg anser elementet med det laveste indeks, som den "første". Derefter 7 .. 0 15 .. 8 mm er den mest logiske bit / byte orden, da jeg gerne bit 0 at være den mindst betydende bit. Dette er, hvordan Intel-processorer gør det.

 

[xtcx]

I et big-endian-system henvisninger peger på den mest betydende byte (den første byte). For at finde den mindst betydende byte skal du kende ordet størrelse.

Ja, er enig. I tilfælde af lilleendet er ikke dette ord størrelse stadig påkrævet?.

std_logic_vector (7 downto 0) betyder ikke, at bit 7 er den første bit. Det er "venstre" bit. Den hardware, der ikke bekymrer sig om "venstre" eller "højre", så hvorfor siger, at bit 7 er den første? Jeg tror, ​​at alt er lettere, hvis jeg anser elementet med det laveste indeks, som den "første". Derefter 7 .. 0 15 .. 8 mm er den mest logiske bit / byte orden, da jeg gerne bit 0 at være den mindst betydende bit. Dette er, hvordan Intel-processorer gør det.

Tja, jeg ville sige at læse denne rækkefølge (31 .. 24) (23 .. 16) (15 .. 08) (07 .. 0) måske være lettere i forhold til at en (7 .. 0) (15 .. 8) etc. .... Dette er en endian ændring i byte for kun stedet, kan dette være nemt at (0 .. 7) (8 .. 15) osv. Men det er lidt ordreændring