Is there any hazard to mix synchronous and asynchronous reset? I am making an RS232 controller and I generally use asynchronous reset in my design except in a process that serve to load the control word (indicate speed, data length, parity...) where I load the control word when reset = '1' or ctr_load ='1' , like that it load the control word at every reset and when we ask to reload it by ctrl_load
Regards
Alexis
my code :
decodeur : process(clk,rst) begin
if rising_edge(clk) then if ctl_load='1' or rst='1' then parity_bit
Note : the sensitivity list is incorrect : rst should be removed.
Are you sure you want/need to load an input or a register during a reset ? If ctl_word is internal (registers) as I suspect, why not load asynchronously the same default value as these registers ? (like from a package)
Are you sure you want/neet to give these registers a special treatment if the rest of your design has an asynchronous reset ?
Mixing both sync and async reset may (according to the FPGA technology and whether your reset will use a global or not) not be a good idea. Synchronous reset means reset will be part of your datapath. It may then add a logic level which isn't always welcome. You may also prevent some tools from dissolve your global reset if you don't use it. And you force static timing into analyzing your reset within fmax/Tsu/Th...
Can you explain why you need mixing both and what functionality it allows that not mixing would prevent ?
btw : the divider decoding might be expressed in a simpler way. Like in this example (dtmf coder):
------
-- Fclock is a generic parameter = 60E6 for Tornado constant fDiv_Max : natural := Fclock/(697*64)-1; subtype IntDiv_t is integer range 0 to fDiv_Max; type Ftable_t is array (0 to 3) of IntDiv_t; constant F1table : Ftable_t := ( Fclock/(697*64)-1, Fclock/(770*64)-1, Fclock/(852*64)-1, Fclock/(941*64)-1 ); signal Div1 : IntDiv_t; signal or input Fsel : std_logic_vector (1 downto 0); .../... the decoder is then simply : Div1 '0'), and it means less cumbersome conversions and type conversions. You must verify that your design rules accept integer ranges (I know some disallow them, but mines don't). Obviously, this also means you should have the freq div in the same module as the UART core to benefit from the integer range (they are ruled out in ports). But that brings another debated issue of partitioning granularity....
No in fact I don't really need to load during a reset , it's just because i wanted to reset my uart and loading the ctrl_word only by pushing one button
It 's only what I wanted to know => if it is a problem to do that or not (indeed I already implemented my design and it's work fine) but I wanted to know if it's could be considerated or not as clean code because use a rst as a simple signal could look like a bit strange
Using a table constant look an interesting issue but would it really make a different (and better) hardware??or is it just a simplest way of writing my decoder?? And as you notice my freq div is in an another module so there is the problem of outport
Thank you , it always help still i am yet newbie in fpga world
Generally asynchronous resets have the same problems as any asynchronous signal being used in synchronous logic. If the input fails set-up and hold timing then some flip-flops may react to the reset on one clock edge and some on the next. This is mainly a problem where flip-flop values are used together in something like a state machine. The consequence of this is that the state machine enters an unwanted state.
Personally my approach is to use a single flip-flop which the input reset signal asynchronous resets (reset active) but the exit from the active reset state is synchronous. Typically I would write this in VHDL as the example below which has active high resets.
process(input_reset, clk) begin if (input_reset = '1') then main_reset
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.