Lite endian til Big konvertering, simuleringsresultater er ikke klart ..?

[Jansi Meena]

Vennligst hjelp meg, har jeg fått denne filen, som de sier det konverterer litt for stor endian. En modul har jeg gir data i (0-33) og en annen modul har (33 downto 0) datatype. Jeg har blitt fortalt at under koden vil gjøre det convesion

 enhet le_2_be er port (ARRAY_IN: i std_logic_vector (0-33)); ARRAY_OUT: ut std_logic_vector (33 downto 0)); end le_2_be, arkitektur le_2_be_arch av le_2_be er begynner LE_2_BE_PROC: prosess (ARRAY_IN) begynne for jeg i 0-33 sløyfe ARRAY_OUT (i)

 

[TrickyDicky]

Det har endret seg. Hvis du ser på det faktiske antallet, vil ARRAY_OUT (0) være lik ARRAY_IN (33). Måten det vises er korrekt, fordi 0 er MSB for array_in, og 33 er MSB for matrisen ut. Så MSB indeksendringer. Koden du har er en liten bit av overkil. Du kan gjøre det ganske enkelt ved å skrive: ARRAY_OUT

 

[Jansi Meena]

OMG, er koden ubrukelig?. Jeg trodde aldri på den måten. Så jeg lurer på hvorfor det har blitt brukt mange steder .... Så selv om jeg passerer en verdi fra "downto" til "til", wont heltallet eller tallet endres?. Vennligst avklare meg, som jeg sterkt forvirret .... For eksempel er dette bare for klarhet min og koden er ingen mening.

 prosess (a, b) variabel en: std_logic_vector (0-3) variabel b: std_logic_vector (3-0) begynne en (0-3)

 

[TrickyDicky]

først av alt, det syntax error. Du mener tre downto 0, ikke 3-0. a) C er "0010" "0010" på sin egen ikke har noen mening, inntil brukt til en matrise. for en (3 downto 0) array. bits (3 downto 1) er '0 'og bit 0 er '1'. for (0-3) biter (0-2) er '0 'og bit 3 er '1'. b) Det er "0010". Big endianness eller lite endianness ingen rolle, er tallet det samme. Det er bare MSB indeksen som endres. c) Nei, med mindre a og b er signaler utad. Du kan bare sette signaler i en følsomhet liste. Du har da fått lokale variabler a og b som overstyrer de eksterne signal navn. Så de interne referansene er til variablene (og du har brukt feil oppdraget operatør, for variabler er det: =). I denne

 

[xtcx]

C vil være 0010 bare. Se Endian er kun for indeksen som Tricky sa, og det vil ikke endre din tall verdi. Modulen som leser lite endian der som data har kommet fra store, bare ha litt orden reveresed og dataene vil bare passe inn i sporet. Det er når du leser litt lurt for eksempel å skrive 32-bit data og når du leser (15 downto 0), vil dette ikke være lik din (0-15) Men som helhet 32-bit Dword, tallet verdien vil alltid forbli samme. som dette .... 0 1 2 3 0 0 1 0 (a) 3 2 1 0 0 0 1 0 (b) Her er en (0-2) er ikke lik en (2 downto 0), men likevel en = b fjernes? ... .

 

[Jansi Meena]

første av alle, syntaksfeil. Du mener tre downto 0, ikke 3-0. a) C er "0010" "0010" på sin egen ikke har noen mening, inntil brukt til en matrise. for en (3 downto 0) array. bits (3 downto 1) er '0 'og bit 0 er '1'. for (0-3) biter (0-2) er '0 'og bit 3 er '1'. b) Det er "0010". Big endianness eller lite endianness ingen rolle, er tallet det samme. Det er bare MSB indeksen som endres. c) Nei, med mindre a og b er signaler utad. Du kan bare sette signaler i en følsomhet liste. Du har da fått lokale variabler a og b som overstyrer de eksterne signal navn. Så de interne referansene er til variablene (og du har brukt feil oppdraget operatør, for variabler er det: =). I denne

Ja, det er ment å være "downto". Takk venner. En mer tvil, er endian ikke aktuelt for bitvis?.

 

[TrickyDicky]

endianness gjelder for bitvis. 31 downto 0 er stor endian, er 0-31 liten endian (IIRC). Det kan litt mer komplisert med datamaskiner, fordi byte kan være stor endian når det kommer ned til bits, og lite endian når det kommer til byte bestilling. Reading bitmap-filer er litt av en smerte.

 

[xtcx]

Generelt vil jeg si, MSB første bestillingen hva noensinne det være, litt \ byte \ Word \ dword \ QWORD etc, er det Big-endian. Det er lett å huske, rite? ... Tricky:

fordi byte kan være stor endian når det kommer ned til bits, og lite endian når det kommer til byte bestilling. Reading bitmap-filer er litt av en smerte.

Jeg ikke forstår hva du prøver å bety her? ....

 

[TrickyDicky]

Hvert byte er bestilt (7 downto 0), men da byte null er minst SIG byte av første DWORD. slik at bit for er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 etc irriterende.

 

[std_match]

Hvert byte er bestilt (7 downto 0), men da byte null er minst SIG byte av første DWORD. slik at bit for er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 etc irriterende.

Det er lite endian både for bits og bytes, og jeg foretrekker det. Det kan være naturlig i vår kultur at "venstre" er første, men det er ingen "left" og "riktig" i maskinvaren. Jeg foretrekker at bit 0 er den minst signifikante bit, og at byte 0 er de minst signifikante byte. Intel prosessorer er som dette. Gamle Motorola prosessorer som 68 000 er lite endian for bit, men big-endian for bytes (31 .. 24 23 .. 16 15 .. 8 7 .. 0). Det kan se "riktig" for ett menneske, men det er ingen fordel for maskinvare eller programvare. Power PC er stor endian for bits og valgbar for byte. I den fullt big-endian mode bitene er som dette: (0 .. 7 8 .. 15 16 .. 24 25 .. 31) Bit 0 er den mest betydningsfulle. Si at du vil sjekke om et tall i minnet er partall eller oddetall. I et lite endian (for byte bestilling) system trenger du bare å vite startadressen av ordet. I en stor-endian (for byte bestilling) system må du kjenne starten adressen og ordet størrelse.

 

[xtcx]

Hvorfor mener du det, kan du si et eksempel ... [ COLOR = "Silver"] [SIZE = 1] ---------- Post lagt ved 12:14 ---------- Forrige post var på 12:10 ------ ---- [/size] [/color]

Hvert byte er bestilt (7 downto 0), men da byte null er minst SIG byte av første DWORD. slik at bit for er 7 .. 0 15 .. 8 23 .. 16 31 .. 24 etc irriterende.

(7 .. 0 \ 15 .. 8) er virkelig hodepine Hvordan håndterer dere i så fall? . Bør vi må formatere byte orden igjen, og deretter behandle? ..... Eller hvordan er dette ivaretatt i moderne arkitekturer ...?

 

[std_match]

Hvorfor mener du det, kan du si et eksempel

I en stor-endian system pekere peker til den mest signifikante byte (første byte)?. For å finne den minst signifikante byte du må vite ordet størrelse. Du får et lignende problem hvis du ønsker å gjøre en multi-word/byte huggorm eller en seriell huggorm. Du må starte med lavest ordet / byte / bit.

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

std_logic_vector (7 downto 0) betyr ikke at bit 7 er den første biten. Det er "venstre" bit. Maskinvaren bryr seg ikke om "venstre" eller "riktig", så hvorfor si at bit 7 er den første? Jeg tror alt er enklere hvis jeg vurdere elementet med lavest indeks som den "første". Deretter 7 .. 0 15 .. 8 osv. er det mest logiske bit / byte rekkefølge siden jeg vil bit 0 til å være minst signifikante bit. Dette er hvordan Intel-prosessorer gjør det.

 

[xtcx]

I en stor-endian system pekere peker til den mest signifikante byte (første byte). For å finne den minst signifikante byte du må vite ordet størrelse.

Ja, enig. I tilfelle lite endian er ikke dette ordet størrelse fortsatt nødvendig?.

std_logic_vector (7 downto 0) betyr ikke at bit 7 er den første biten. Det er "venstre" bit. Maskinvaren bryr seg ikke om "venstre" eller "riktig", så hvorfor si at bit 7 er den første? Jeg tror alt er enklere hvis jeg vurdere elementet med lavest indeks som den "første". Deretter 7 .. 0 15 .. 8 osv. er det mest logiske bit / byte rekkefølge siden jeg vil bit 0 til å være minst signifikante bit. Dette er hvordan Intel-prosessorer gjør det.

Vel, jeg mente å si leser denne rekkefølgen (31 .. 24) (23 .. 16) (15 .. 08) (07 .. 0) kan være lettere i forhold til at en (7 .. 0) (15 .. 8) etc. .... Dette er en endian endring i byte for bare stedet, dette kan være lett (0 .. 7) (8 .. 15) etc Men dette er litt for endring

 

[Jansi Meena]

Takk, de fleste av enhetene, som noen Ti DSP har jeg arbeidet, er i stor endian bare. Dette er hva de brukes til SPI, andre kommunikasjon ... Hva er det å ha problemer med lese-rekkefølge?. I VHDL jeg finner er noen problemer i å bytte mellom Big \ Lille endian ....

 

[xtcx]

Jeg tror, ​​er det uavhengig. Noen produsenter gjør det som en standard og noen er programmerbare. I FPGA er det ingen problem. Fordi vi alltid håndtere bits vektorer og faktisk er det veldig enkelt. Men i prosessorer som 32-bit, er det en tøff jobb, kan det ta flere maskingevær sykluser for å få litt nivå informasjon i en DWORD. Derfor kan gjøre denne konvensjonen en hodepine ....