Dele integer buss [VHDL]

[Kirchhoff]

Hei, jeg har 5 stk moduler som inneholder en 5 stegs FSM. Jeg ønsker at hver av disse skal outpute data på en integer buss når de er på steg 5 i tilstandsmaskinen. Det er til en hver tid kun 1 modul som er i denne tilstanden.

 

Kan man sette integer til 'Z'? (high impedance)

Må jeg oversette til vector?

Må jeg benytte meg av negativ klokke flanke for å forsikre meg om at ikke to moduler prøver å drive bussen samtidig?

Endret 30. juli 2014 av Kirchhoff

[endrebjo]

Alle fysiske signaler må oversettes til std_logic for at oppførselen skal gi noe mening. I ditt tilfelle med integer må du derfor oversette et tilstrekkelig antall bit til std_logic_vector.

Om du må switche på negativ flanke avhenger av hvordan data på utgangen settes. Hvis utgangene forandres rent sekvensielt (Moore-maskin) skal det ikke være nødvendig å bruke mellom-states. Du får kanskje bittelitt lekkasjestrøm i overgangene, men Z-state er vanligvis så kjapp at det ikke skal være noe stort problem. Om utgangene derimot kan forandres kombinatorisk (Mealy-maskin) kan det være greit å være mer påpasselig.

[Kirchhoff]

Takk for svar! Er det lite lurt å bruke unsigned også da? Om jeg må oversette helt fra integer til vector så må jeg først oversette til unsigned og deretter oversette til vector.

[endrebjo]

Signed og unsigned (fra numeric_std std_numeric) er veldig fine datatyper siden de er både hardware-nære (basert på std_logic) og enkle å gjøre aritmetiske operasjoner på (pga. numeric_std std_numeric). Hele dataflyten kan ofte gjøres med signed/unsigned i stedet for integer, og derfra er det bare en enkel cast til std_logic_vector. Som du sier så må integer konverteres (ikke bare castes) til en annen datatype før den kan castes til std_logic_vector. Derfor liker jeg å bruke signed/unsigned på selve datastien.

Integers bruker jeg stort sett til konstanter, tellevariabler og annet småplukk rundt som ikke er data.

Endret 30. juli 2014 av endrebjo

[Kirchhoff]

Kan jeg multiplisere unsigned med hverandre vha en enkel * operator, slik som med integer? Om jeg kan det så kutter jeg ut integer, slik som du gjør.

[endrebjo]

Jepp. Ta en kikk på definisjonene i numeric_std. Det er disse enkle operasjonene (pluss, minus, gange, deling, sammenlikning) som er så fint med numeric_std. :-)

 

(Jeg ser jeg stokket om på navnet i forrige innlegg.)

 

Wiki om numeric_std

Endret 30. juli 2014 av endrebjo

[Kirchhoff]

Jeg prøver nå dette her:

Pseudo vhdl:

when state = 0:
a <= highImpedance    --vector med bare "Z"
 
...
when state = 3:
a(2) <= b*c;
--a <= aOut;
aOut <= a;
state = 0;

aOut er koblet til en buss som 3 andre identiske moduler er koblet til også. Alle modulene er i hver sin unike state.

 

I aldec active HDL får jeg denne advarselen:

 There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the result will be 'X'(es).

En mulighet er jo å ORe alle utgangene sammen. Endret 1. august 2014 av Kirchhoff

[endrebjo]

Jeg vil tippe at den advarselen betyr at enten b eller c er 'U/X/W/Z'.

 

I tillegg har a(2) multiple drivers. Er du sikker på at det er det du vil? Hvis aOut er felles-bussen vil det være mer naturlig å skrive til den, eller?

 

Og til sist kan jeg nevne at dette minner om Mealy-oppførsel hvor det gjelder å trå litt varsomt.

[Kirchhoff]

Ops. Mente aOut til venstre for likhetstegn. a er et signal og aOut er en out port.

 

Med forsiktig så mener du at jeg bør lage en modul som bitvis ORer de 4 signalene? Vil ikke det nesten like arealeffektivt på en fpga som å muxe det hos mottakeren ( noe som tok mye ressurser på min fpga, pga hver aOut er 32b bred.)

Endret 1. august 2014 av Kirchhoff

[endrebjo]

Med forsiktig så mener du at jeg bør lage en modul som bitvis ORer de 4 signalene? Vil ikke det nesten like arealeffektivt på en fpga som å muxe det hos mottakeren ( noe som tok mye ressurser på min fpga, pga hver aOut er 32b bred.)

Ikke nødvendigvis verken ORing eller muxing, men minst et tydelig skille mellom kombinatorisk og sekvensiell oppførsel.

F.eks

-- Kombinatorisk
process (a, b, c, d, ...)
    case state is
        when s0 =>
            a(2) <= b*c;
            aOut_next <= a;
            state_next <= s1;
        when s1 =>
            ...
end process;

-- Sekvensiell
process (clk, reset)
    if reset == 0 then
        blabla;
    elsif rising_edge(clk) then
        aOut <= aOut_next;
        state <= state_next;
    endif
end process;

På den måten sikrer du at alle utganger er spikret sekvensielt, og ikke kan forandre seg på pussige inputs og skape multiple drivers. Det du i prinsippet gjør er å sikre at alle utganger består av kun flip-flops og eventuelle tri-state buffers koblet til flip-flops.

 

Se f.eks et et komplett FSM-eksempel.

[Kirchhoff]

Skjønner. Men da må jeg ha en gjøre en state sjekk i den sekvensielle delen da, for å unngå kortslutning mellom de forskjellige modulene?

process (clk, reset)
    if reset == 0 then
        blabla;
    elsif rising_edge(clk) then
        if(state = 3) then
           aOut <= aOut_next;
        else
           aOut <= high_imp;
        end if;
        state <= state_next;
    endif
end process;

[endrebjo]

Neida. Å sette høy impedans sørger du for å gjøre i den kombinatoriske delen. Det går helt fint. Hele poenget er at den sekvensielle biten ikke skal inneholde noe kombinatorikk.

[Kirchhoff]

-- Kombinatorisk
process (a, b, c, d, ...)
    case state is
        when s0 =>
            a(2) <= b*c;
            aOut_next <= a;
            state_next <= s1;
        when s1 =>
            aOut_next <= high_imp; 
            ...
end process;

Slik altså?

 

 

EDIT:

ERROR:Xst:528 - Multi-source in Unit <pxCombiner> on signal <colorOut<3><1>>; this signal is connected to multiple drivers.

Får en slik error for alle de 32 bitene i busen når jeg prøver å syntisere i Xilinx ISE Project navigator 2013. Får ingen advarsel eller simuleringsproblemer i active HDL. colorOut blir bare gitt verdi i denne prosessen. All koden min er vedlagt.

sekv : process(clk, rst)
begin
	if(rst = '1') then
		state <= 0;
	elsif(clk'event and clk = '1') then
		state <= state_next;
		colorOut <= colorOut_next;
	end if;	
end process;

kirchhoff.zip

Endret 2. august 2014 av Kirchhoff

[endrebjo]

colorOut_next er ikke definert i state 1 og 2 såvidt jeg ser. Det kan kanskje skape trøbbel. Og others-løsningen kan også være opphav til multiple-drivers i og med at du kan lese bussdata fra andre moduler og prøve å skrive denne til buss. Strengt tatt ser jeg ikke noe behov for at colorOut skal være inout i stedet for bare out, siden eneste gangen du leser denne er i others-staten. I others kan det kanskje være like greit å sette utgangen til Z bare for å være på den sikre siden.

 

Du skriver heller ikke hvilken FPGA du bruker. Har du sett i dokumentasjonen om det må gjøres noe spesielt på din FPGA når du skal bruke tri-states?

[Kirchhoff]

Takk! Jeg skal se på det i morgen.

Fpgaen jeg bruker er en xilinx spartan 3a (XC3S50A-4VQG100C).

Endret 3. august 2014 av Kirchhoff

[endrebjo]

Jeg har kikket litt i User Manual for Spartan-3(A). Der finner jeg en del om dedikerte og billige muxer. Og samtidig, på side 263, litt om tri-state buffers:

Related Uses of Multiplexers

 

Multiplexers and Three-State Buffers

 

The LUT and mux resources multiplex one of several input signals onto an internal routing

resource, using the routing like an internal bus. This is equivalent to the BUFT-based

multiplexers found in other FPGA architectures. In most modern FPGA families, these

three-state buffers actually are implemented as dedicated logic gates to avoid possible

contention when more than one is enabled at a time. The Spartan-3 generation families

reduce die size and cost by eliminating the overhead of these internal three-state buffer

gates. Instead, internal functions defined as a three-state buffer in the Spartan-3 generation

families must be implemented in the LUTs and dedicated muxes.

 

The CLB multiplexers provide binary encoding of the select lines, requiring fewer signals

than the one-hot encoding of the BUFT-based multiplexers. CLB-based multiplexers have

no limit on width as BUFT-based multiplexers did, nor any special placement

considerations.

 

The BUFT component, representing a three-state buffer, is not available in the

Spartan-3 generation libraries, except for the output function in the IOBs. The CORE

Generator functions of the BUFT-based Multiplexer (and the equivalent BUFE-based

Multiplexer) will be implemented as multiplexers in the CLBs.

VHDL-eksempler for muxer begynner på side 264.

 

Så det er kanskje greiest å bruke mux i stedet for ren tri-state-oppførsel på din FPGA. At muxen din tidligere ble veldig stor kan være pga av uheldig VHDL-koding. Best practice er blant annet beskrevet på side 264 i manualen jeg linket til, og burde generere ganske billige muxer. Sånn jeg forstår det skal du ha 5-til-1-muxer, ikke 32-til-1-muxer.

[Kirchhoff]

Takk for at du tok deg tid til å se gjennom dokumentasjonen. Jeg forandret lengden til FSMen til 4 steg, så blir 4 til 1 mux. Men blir 32bit x4 til 32bit x1 mux. Jeg brukte inout bare for å teste om det hjalp syntisereren til å skjønne at jeg ønsket tri-state buffer.

 

Jeg skal prøve å gjøre endringene (inkludert de om udefinert colorOut_Next) og se hvilke resultat jeg får.