Prev: Some Active-HDL questions
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: Weng Tianxiang on 9 Mar 2010 13:25 On Mar 9, 10:15 am, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > On Mar 9, 7:24 am, Weng Tianxiang <wtx...(a)gmail.com> wrote: > > > > > > > On Mar 9, 12:32 am, Tricky <trickyh...(a)gmail.com> wrote: > > > > On 9 Mar, 01:46, Weng Tianxiang <wtx...(a)gmail.com> wrote: > > > > > Hi, > > > > I have a question about when to generate a latch. > > > > > In Example_1 and Exmaple_2, I don't think it will generate a latch. I > > > > don't know why. > > > > > Example_1: process(RESET, CLK) > > > > Begin > > > > If RESET = 1 then > > > > StateA <= S0; > > > > Elsif CLKevent = 1 and CLK = 1 then > > > > If SINI = 1 then > > > > StateA <= S0; > > > > Elsif E2 = 1 then > > > > null; -- missing a signal assignment statement > > > > -- I suppose it will not generate a latch, why? > > > > Elsif StateA = S1 then > > > > StateA <= S3; > > > > Else > > > > StateA <= StateA_NS; > > > > End if; > > > > End if; > > > > End process; > > > > > Example_2: process( ) > > > > Begin > > > > Case StateA is > > > > ...; -- no signal assignement statements are missing > > > > End case; > > > > End process; > > > > > Weng > > > > In my mind, it generated a register with enable and async reset. > > > Latches are only created when you dont have a clock in a process and > > > you forget to assign something between process iterations. > > > Example_1: process(RESET, CLK) > > Begin > > If RESET = 1 then > > StateA <= S0; > > Elsif CLKevent = 1 and CLK = 1 then > > If SINI = 1 then > > StateA <= S0; > > Elsif E2 = 1 then > > null; -- missing a signal assignment statement > > -- I suppose it will not generate a latch, why? > > Elsif StateA = S1 then > > StateA <= S3; > > Elsif C1 /= '1' then > > StateA <= StateA_NS; > > -- else -- missing a signal assignment statement > > -- null; -- I suppose it will not generate a latch, why? > > End if; > > End if; > > End process; > > > Example_2: process( ) > > Begin > > Case StateA is > > ...; -- no signal assignement statements are missing > > End case; > > End process; > > > Weng- Hide quoted text - > > > - Show quoted text - > > It isn't clear what you are looking for or trying learn with this code > snippets. In both case these are the classical register coding > styles. > > 1) The process has two signals, RESET and CLK, in the sensitivity list > 2) There is only one signal, StateA, assignment > 3) The RESET is coded as an active high level asynchronous reset > function > Note: S0 should be a fixed static value or this will cause > problems > 4) The CLK is coded as a rising edge clock and generates the register > element. > Note: Everything within this ELSIF statement is evaluated only on > the rising edge > > I would strongly encourage you to change the RESET function from > asynchronous to synchronous. > > Ed McGettigan > -- > Xilinx Inc. Ed, Thank you. Weng
From: Andy on 10 Mar 2010 13:04 Weng, Let's look at what behavior generates a latch: The need for the circuit to remember a previous assignment from a previous execution of the process, when no other storage media is implied (i.e. in a combinatorial process). In a clocked process, the register does the remembering, since the process will have to remember the previous assignment when it executes on the falling edge too). A clock enable is added when the process must remember over more than one clock cycle. Looking at it another way, conceptually, a latch is nothing than a mux with feedback around whatever the input logic was (combinatorial). A register with clock enable is conceptually just a mux with feedback too, but the feedback is from the output of the register back to its input. So, in a combinatorial process with a missed assignment, you get a latch, whereas in a clocked process, it gets implemented with a clock enable on the register, and no latch is needed. Some synthesis tools may be getting smart enough to optimize an inferred latch from a combinatorial process into a clock enable on the corresponding register implied by the clocked process. But if there are any other combinatorial processes that use that latched output of the first combinatorial process, then the latch cannot be replaced by a clock enable on a register. Andy
From: Andy on 10 Mar 2010 13:06 On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > I would strongly encourage you to change the RESET function from > asynchronous to synchronous. On what basis do you make this recommendation, and what does this have to do with latches? Andy
From: Ed McGettigan on 10 Mar 2010 14:24 On Mar 10, 10:06 am, Andy <jonesa...(a)comcast.net> wrote: > On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > > > I would strongly encourage you to change the RESET function from > > asynchronous to synchronous. > > On what basis do you make this recommendation, and what does this have > to do with latches? > > Andy Synchronous versus asynchronous resets have been discussed at length in other threads. Asynchronous resets have their place in a designer's toolbox, however they should be used sparingly. Some reasons to use these are for handshakes crossing clock domains, anticipated loss of clock and asynchronous inputs to the synchronous domain. In a synchronous domain, such as the original state machine example, the asynchronous functionality offers no additional benefit in FPGAs as the area cost is identical for both. Asynchronously asserting and de-asserting a reset across multiple registers may/will result in the registers being released before and after a clock edge due to large net delay and skew on the reset net. This will result in different parts of a design coming out of reset across clock boundaries and being out of sync with each other. Synchronous resets simplify timing analysis and timing closure without having to worry about the consequences of the asynchronous functions and how to correctly constrain them. I often see problems with FPGA designs that are built with asynchronous resets, but I have yet to see a problem with a FPGA design that was traced to a synchronous reset. In an FPGA there is no downside to a synchronous reset, but there are many pitfalls with an asynchronous reset. None of this has anything to do with a latch, which you also want to avoid using in an FPGA. Ed McGettigan -- Xilinx Inc.
From: Peter Alfke on 10 Mar 2010 14:49
On Mar 10, 10:06 am, Andy <jonesa...(a)comcast.net> wrote: > On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > > > I would strongly encourage you to change the RESET function from > > asynchronous to synchronous. > > On what basis do you make this recommendation, and what does this have > to do with latches? > > Andy Please allow me to chime in with a basic tutorial: Latches and flip/flops=registers have common features and also a big difference: They both are storage elements, both have a Data input (D) and a data output ( Q), and both have a control input called Enable or Clock. (Let me ignore the contentious issue of asynchronous or synchronous Reset/clear or Preset) The big difference: A latch is transparent,( i.e. Q follows D, and thus there is no storage), whenever the Enable input is active. But Data is stored when Enable is inactive. A flip-flop is NEVER transparent. (D can never affect Q directly). Q assumes the state that D had right before the rising edge of the clock. How is this done? Inside the flip-flop, there are two cascaded latches (called Master and Slave). The Master latch is transparent and its internal output follows the D input as long as the Clock is low. The Slave latch is transparent and its external output Q follows the slave's internal output whenever the Clock is High, but during this time the Master is non-transparent = locked up. So the two cascaded latches have the opposite enable polarity. Thus the flip-flop's Q output can only change on (i.e. right after) the rising clock edge. I do not want to belabor the advantages of either design, just to avoid confusion. The flip-flop or register is the prevalent design. It wins the Oscar in most (but not all) cases..., but RAM cells always use the simpler latch structure. Peter Alfke, (teacher at heart) |