library in ise 12.1 for flip flop

Discussion in 'Embedded Systems and Microcontrollers' started by maia31, Aug 3, 2011.

  1. maia31

    Thread Starter New Member

    Jul 20, 2011
    6
    0
    if i want use d flip flop
    from schematic of ise12.1
    as component
    in vhdl code
    which library i need to add?
     
  2. kavli

    New Member

    Aug 1, 2011
    23
    2
    You mean a D-latch?

    I have made my own collection of basic logic elements that I usually include in all my projects.

    Here is my d-latch:

    If you really need edge triggering, replace the enable signal with a "rising_edge(Clk_I)" instead.

    -- K

    Code ( (Unknown Language)):
    1.  
    2. -- Bona Fide D-latch
    3. --
    4. ENTITY D_Latch IS
    5.   PORT (
    6.     Enable_I :  IN std_ulogic;
    7.            D :  IN std_ulogic;
    8.            Q : OUT std_ulogic
    9.   );
    10. END ENTITY D_Latch;
    11.  
    12.  
    13. ARCHITECTURE D_Latch_arch OF D_Latch IS
    14.  
    15. BEGIN
    16.  
    17.   D_latch : PROCESS (Enable_I, D)
    18.  
    19.   BEGIN
    20.     IF Enable_I = '1' THEN
    21.       Q <= D;
    22.     END IF;
    23.  
    24.   END PROCESS D_latch;
    25.  
    26. END ARCHITECTURE D_Latch_arch;
    27.  
     
    Last edited: Aug 3, 2011
  3. guitarguy12387

    Active Member

    Apr 10, 2008
    359
    12
    Kavli, I am somewhat perplexed by your answer. DFFs are much more commonly used than latches and are what are implemented as logical primitives on the FPGA. In fact, I don't even think latches fit into good synchronous design techniques... they are much more prone to glitches!

    Anyway, check out this link:
    http://fet.hut.edu.vn/sip-lab/Files/DTSo/VHDLofDFF.pdf

    Also, you can probably use the vhdl library templates in ISE.
     
  4. kavli

    New Member

    Aug 1, 2011
    23
    2
    An interesting comment.

    Generally I can agree with your general concern for asynchronous logic. If one doesn't understand the ramifications, bad things can happen. If, for instance the Enable_I is connected to an input pin, bad things will sooner or later happen with this design. Sooner or later the condition will switch at the same time as the test of the condition, and **** will hit the fan.

    It is all about the design of the logic and about making sure that the condition always is stable during the test of the condition. This can only be done by using it inside a synchronous process, as, let's say as part of a state-machine, where the state-machine is clocked on one half phase, and the data-flow is on the other half phase.

    Regarding glitches it is just as possible to get it with synchronous logic, if the design is wrong. Let's just say you try to latch a signal synchronously direct from a pin as part of the condition. Been there, done that, got the t-shirt.

    So for me, I don't have much problems with transparent latches, as long as I know the limitations.

    -- K
     
    Last edited: Aug 5, 2011
  5. guitarguy12387

    Active Member

    Apr 10, 2008
    359
    12
    Ahhh that is an interesting approach! I'm glad to have learned this perspective. You can save latency using your approach too, now that i think about it! Cool, thanks!

    I just assumed by the content of the original post that he wouldn't have understood those tradeoffs haha. Or at least they wouldn't have been obvious and he'd have to learn the hard way haha!

    One more thing i thought of on this topic: It is typically advisory in large designs to pipeline your logic using synchronous techniques because it helps implementation tools analyze the timing of the design and make appropriate optimizations. If a bunch of complex combinational logic mucks up the critical path, the tools will freak out and not be able to make optimizations because it can't analyze the timing as effectively.
     
Loading...