Hallo,

Ik probeer juist dit uit:


signal counter: integer range 0 to 500;
process(CLK,Reset_n)
begin
    if(Reset_n='0') then
       counter <= 250;
       output <= '1';
    elsif(clk'event and clk='1') then
       ...
    end if;
end process

Hier is heel wat weggelaten, maar wat telt is het volgende: de output wordt hoog gezet, maar de counter waarde wordt niet gezet. In de RTL zie je wel degelijk de reset_n pin naar de PRE_n pin gaan, maar toch wordt in de simulatie de counter niet op 250 gezet, maar op 0. Kan dit gewoonweg niet?

EDIT: in de technology map vieuwer zijn de PRE_n pinnen van de counter flipflops inderdaad niet meer geconnecteerd... Hoe komt dit?

[Bericht gewijzigd door stecj366 op (10%)]

Ik denk dat het foutgaat omdat je Reset een asynchroon signaal is. De compiler neemt dan een fictieve waarde aan voor Reset en gaat er niet vanuit dat het signaal ook '1' kan worden. En daaruit volgt dat je de teller ook geen waarde kunt geven.

Als je de reset synchroon maakt, dus onder de clk'event harkt, dan werkt het waarschijnlijk wel.

dit komt omdat je een onvolledige case hebt !. ik heb daar onlangs ook nog mijn gat aan verbrand.

ik heb in het 'fpga voorbeelden topic van foto_opa , juist nog een episteltje gepost over dergelijke miserie.

wat jij schrijft is het volgende :

als reset nul is doe dit
anders ALS clkevent en clk

je geeft nooit op aan de synth wat je wilt dat er gebeurt als er GEEN clockevent is en resetn is 1. !

en er is weinig verschil tussen de sint en de synth ... als je het niet vraagt krijg je het niet ! Synths zijn domme dingen.

pas dat eens aan als volgt :


if (reset_n='0') then
   counter <=250;
else
   if  ( clkevent )   
       tellen !
   else      // geen clockevent ? huidige waarde latchen !
       counter <=counter;

waarschijnlijk mapt jouw ding uit naar een latch circuit.

asynchrone presets zijn ook gevaarlijk op ene andere manier : de meeste fpga hebben geen asynchrone presets op hun flipflops. alleen asynchrone resets .... dus je kan asynchroon wel iets op nul zetten , maar iets voorladen ( 1 zetten ) lukt niet ....

Dit klopt van geen kanten FE! TS, wat je daar opschrijft is het schoolvoorbeeld van een flipflop (aangenaam) in VHDL. Je hoeft helemaal geen default counter<=counter op te geven. Immers, een FF houdt gewoon z'n oude waarde als er geen reset is en geen clk. Dat weet elke synthese tool.
Er is dus iets anders aan de hand met die reset. Je hebt het over reset_n die niet meer aan PRE_n zit? Zit reset_n helemaal niet meer aan die FF? Ook niet op de reset pin?
Om wat dingen uit te sluiten zou ik even een klein stukje code nemen, zoiets als je in je post hebt. En dan ook even die integer vervangen door een std_logic_vector. Al zou een integer ook moeten werken.

Op 13 november 2007 21:49:42 schreef flipflop:
Dit klopt van geen kanten FE!

-snipperdesnip-

"Dat weet elke synthese tool."

tjah ... mijne vhdl is roestig.

let op met die synthese tools. ! voor je het weet proberen ze een latch te maken. en de ene reageert al anders dan de andere ...

Ts wil een ASYNCHRONE reset maken.
ik vraag me af of je niet beter de 'reset' opneemt in de sensitivity lijst ... en dan checkt of het om reset ging of om clk ...

in verilog :


always @(posedge clk, posedge reset)
  if(reset )  ctr <=250;
  else ctr <= ctr -1;

dit spul tript altijd op zowel de clock als de reset.
telkens dat tript wordt er EERST naar de reset gekeken. staat die aan : RESET. staat die niet aan : doe normaal ( met andere woorden het was ene clock event.

dus zelfs al houdt je de RESET hoog en blijf je clocken : dat spul blijft hangen in reset.

Op 13 november 2007 22:15:07 schreef free_electron:
tjah ... mijne vhdl is roestig.

Te lang uit je "homeland" weg zeker? :p

TS heeft ook een asynchrone reset opgeschreven. Eigenlijk precies hetzelfde als in jouw Verilog voorbeeld. Keurig clk en reset in de sens.list. Schoolvoorbeeld. Er is dus ook niets mis mee. Ik denk TS dat je toch teveel hebt weggelaten in de stukje code. Er moet een andere oorzaak zijn.

Een synchrone reset is dit overigens:


process(CLK,Reset_n)
begin
  if(clk'event and clk='1') then
    if(Reset_n='0') then
       counter <= 250;
       output <= '1';
    else
       ...
    end if;
  end if;
end process

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity Ram_to_DAC is
	port(
		Addr_out			: out std_logic_vector(12 downto 0);
		CLK					: in std_logic;
		Reset_n				: in std_logic
	);
end Ram_to_DAC;


architecture RTL of Ram_to_DAC is
signal internal_addr: std_logic_vector(12 downto 0);
begin
	Addr_out <= internal_addr;
	process(CLK,Reset_n)
	begin
		if(Reset_n='0') then
			internal_addr <= "0101010101010";
		elsif(CLK'event and CLK='1') then
			internal_addr <= internal_addr + conv_std_logic_vector(1,13);
		end if;
	end process;
end RTL;

Dit werkt dan weer wel. Ik denk dat het iets in de rest van de code was dat het om zeep hielp. De oude code heb ik niet meer, had het dan al anders opgelost. Maar toch bedankt

In theorie moet een compiler als jij de reset-toestand '0110' toekent aan een register er voor kunnen kiezen dat bit 1 en 2 (de middelste twee) niet opgeslagen worden, maar hun inverse. Ook operaties als "teller <= teller + 1" kunnen booleaans uitgedrukt worden als je alleen "~ teller[1]" hebt ipv "teller[1]".

Of de compiler zo slim is, weet ik niet. En ALS hij zo slim is, dan heb je als designer weer minder controle over wat er nu uiteindelijk geimplementeerd wordt. Dat kan als je er echt verstand van hebt weer verkeerd uitpakken.

Dit volg ik niet. Wat bedoel je met het opslaan van de inverse? Hoe kan een FF de inverse opslaan?