Using unregistered inputs in FSM

Discussion in 'VHDL' started by ALuPin@web.de, Jul 20, 2005.

  1. Guest

    Hi,

    I have some doubts concerning the following problems:

    In my design I have an 8bit bidiretional bus "Data_ulpi".
    When the external module drives data into my FPGA
    I have to read that data and respond immediately that is
    I have NO time to synchronize the data with 2-stage-FFs/FIFO.

    .... NO time because the external module is expecting response on the
    next clock cycle.

    I have read several posts in this newsgroup
    explaining that the state machine would have to be very tricky
    to handle unregistered inputs.

    So how do I have to place bidirectional bus and control signals
    to have at least a chance of doing a good job ?
    What constraints do I have to take into consideration in that
    special case for tSU/tH ?

    Thank you for your advice.

    Rgds
    André
     
    , Jul 20, 2005
    #1
    1. Advertising

  2. Guest

    Some additional info:

    The clock of the FSM is provided by the external module.

    Rgds
    André
     
    , Jul 20, 2005
    #2
    1. Advertising

  3. Hubble Guest

    We are in a causal world, so there is always an event which signals
    valid data, so NO time seems to be an exaggeration.

    Without more information, the following can be said:

    > You can think of using latches. The read event will latch the last data.


    > You can delay signals and data appropriately to generate proper setup/hold conditions. Using delays, you can even design circuitry handling negative setup times properly etc.



    > The latched data can then be treated using 2-stage ffs or any other possibilties to handle unsychronized data.


    Hubble.
     
    Hubble, Jul 20, 2005
    #3
  4. Guest

    I have never used latches. What is the problem about them ? Do Fitter
    treat them predictable ?

    André
     
    , Jul 20, 2005
    #4
  5. Guest

    I have read the following in one post discussing latches:
    "None of the above applies to FPGA, you will have no control over
    anything and your timing will be horrible so forget it. "


    Comments ?
     
    , Jul 20, 2005
    #5
  6. wrote:

    > ... NO time because the external module is expecting response on the
    > next clock cycle.


    That's one external clock cycle, not zero.
    Use a fpga clock at least twice that fast.
    Send a handshake while you synchronize the data strobe.

    > I have read several posts in this newsgroup
    > explaining that the state machine would have to be very tricky
    > to handle unregistered inputs.


    Any synchronous design will have problems with asynchronous
    inputs. Note that registered inputs may or may not
    be synchronous to the fpga clock.


    -- Mike Treseler
     
    Mike Treseler, Jul 20, 2005
    #6
  7. wrote:
    > Some additional info:
    >
    > The clock of the FSM is provided by the external module.
    >

    In that case, you can just turn around the data strobe
    as a handshake and latch the data on the same
    clock tick.

    -- Mike Treseler
     
    Mike Treseler, Jul 20, 2005
    #7
  8. Peter Alfke Guest

    I think we need a better statement of the problem.
    You have an 8-bit wide incoming data bus. Is there a clock that defines
    valid data? What is the timing of that clock or clock edge? If there
    is no clock, how do you know that there is new data? What if the new
    data is identical with the old data?

    Peter Alfke
     
    Peter Alfke, Jul 20, 2005
    #8
  9. wrote:
    > I have read the following in one post discussing latches:
    > "None of the above applies to FPGA, you will have no control over
    > anything and your timing will be horrible so forget it. "


    In a synchronous design, even one with 30,000
    flops, I need only one synthesis constraint, Fmax.
    Synthesis is a formality.

    In an asynchronous design I need to constrain
    setup and hold times to every flop.
    Synthesis is tedious at best.

    -- Mike Treseler
     
    Mike Treseler, Jul 20, 2005
    #9
  10. Andre,

    There are a few alternatives.
    I am doing something similar in my design right now, but it depends on the
    speed of your clock/data rate and whether it's smooth or gapped.

    (*) You can generate a higher clock and do everything with it - nice, clean
    and quiet. In this case, use OFFSET constraint for external clock. You can
    apply either internal or EXTERNAL setup/hold settings for the OFFSET
    constraint (external means the specs of the external device, but make them a
    little harder than the spec).
    (**) You can try some very nice asynchronous switching by latches,
    but......................................... I am not a big fan of it.
    (***) NO time at all, try PAD to PAD delay, which you can contraint for the
    cases you have a PAD ==> combinational_logic ==> PAD.

    If you could give a few more details...

    Hope this helps.
    Vladislav

    P.S. .

    <> wrote in message
    news:...
    Hi,

    I have some doubts concerning the following problems:

    In my design I have an 8bit bidiretional bus "Data_ulpi".
    When the external module drives data into my FPGA
    I have to read that data and respond immediately that is
    I have NO time to synchronize the data with 2-stage-FFs/FIFO.

    .... NO time because the external module is expecting response on the
    next clock cycle.

    I have read several posts in this newsgroup
    explaining that the state machine would have to be very tricky
    to handle unregistered inputs.

    So how do I have to place bidirectional bus and control signals
    to have at least a chance of doing a good job ?
    What constraints do I have to take into consideration in that
    special case for tSU/tH ?

    Thank you for your advice.

    Rgds
    André
     
    Vladislav Muravin, Jul 20, 2005
    #10
  11. Guest

    Hi,
    thank you for your answers.
    With "NO time" I mean that I have no time to sychronize the input when
    using the external data clock in my FSM.

    Some more information on the interface:

    DATA[7..0]
    8-bit bidirectional data bus.
    The FPGA has to drive the bus LOW by default.
    By sending a non-zero data pattern called TXCMD (transmit command) the
    FPGA initiates transfers.
    The direction of DATA[7..0] is controlled by DIR. Contents of the bus
    lines must be ignored
    for one clock cycle whenever DIR changes value (turnaround)

    DIR
    Controls direction of data bus. The external PHY drives DIR LOW by
    default so that it can listen
    to TXCMDs from FPGA. The PHY drives DIR HIGH when it has data for the
    FPGA.

    STP
    The FPGA drives STP HIGH for one clock cycle after the last byte of
    data was sent to the PHY

    NXT
    The PHY drives NXT HIGH to throttle data. If DIR is LOW, the PHY
    asserts NXT to notify the FPGA to
    place the next data byte on DATA[7..0] in the following clock cycle. If
    DIR is HIGH the PHY asserts NXT HIGH to notify the FPGA a valid byte is
    on DATA[7..0].

    I have tried to illustrate the timing in the following diagram:
    http://mitglied.lycos.de/vazquez78/

    Some dynamic characteristics of the PHY which provides the 60MHz clock:

    timings with respect to positive edge of PHY clock
    tSETUP (input-only pins) max. 6.0 ns
    tHOLD (input-only pins) max. 0.0 ns
    tOUT (output-only pins) 2pF - ns
    12pF - ns
    30pF max. 9.0 ns


    As the plot shows I have to provide data on the next PHY clock cycle
    as soon the PHY accepts my TXCMD. So not really much time to do a good
    synchronous job ... ?

    Rgds
    André
     
    , Jul 21, 2005
    #11
  12. wrote:

    > I have tried to illustrate the timing in the following diagram:
    > http://mitglied.lycos.de/vazquez78/


    Looks like a standard synchronous handshake to me.
    fpga sees NXT then registers DATA and drives STP
    on the next clock (or later if collecting a burst)
    Good luck.

    -- Mike Treseler
     
    Mike Treseler, Jul 21, 2005
    #12
  13. Andre,

    From what I see on the web (timing diagram), i think it's just a pileline
    which needs to be enabled/disabled.
    Maybe I am wrong, but where you need to do everything on one cycle?
    You always "prepare" the next data before opening the bus towards the
    external PHY

    Vladislav



    <> wrote in message
    news:...
    Hi,
    thank you for your answers.
    With "NO time" I mean that I have no time to sychronize the input when
    using the external data clock in my FSM.

    Some more information on the interface:

    DATA[7..0]
    8-bit bidirectional data bus.
    The FPGA has to drive the bus LOW by default.
    By sending a non-zero data pattern called TXCMD (transmit command) the
    FPGA initiates transfers.
    The direction of DATA[7..0] is controlled by DIR. Contents of the bus
    lines must be ignored
    for one clock cycle whenever DIR changes value (turnaround)

    DIR
    Controls direction of data bus. The external PHY drives DIR LOW by
    default so that it can listen
    to TXCMDs from FPGA. The PHY drives DIR HIGH when it has data for the
    FPGA.

    STP
    The FPGA drives STP HIGH for one clock cycle after the last byte of
    data was sent to the PHY

    NXT
    The PHY drives NXT HIGH to throttle data. If DIR is LOW, the PHY
    asserts NXT to notify the FPGA to
    place the next data byte on DATA[7..0] in the following clock cycle. If
    DIR is HIGH the PHY asserts NXT HIGH to notify the FPGA a valid byte is
    on DATA[7..0].

    I have tried to illustrate the timing in the following diagram:
    http://mitglied.lycos.de/vazquez78/

    Some dynamic characteristics of the PHY which provides the 60MHz clock:

    timings with respect to positive edge of PHY clock
    tSETUP (input-only pins) max. 6.0 ns
    tHOLD (input-only pins) max. 0.0 ns
    tOUT (output-only pins) 2pF - ns
    12pF - ns
    30pF max. 9.0 ns


    As the plot shows I have to provide data on the next PHY clock cycle
    as soon the PHY accepts my TXCMD. So not really much time to do a good
    synchronous job ... ?

    Rgds
    André
     
    Vladislav Muravin, Jul 21, 2005
    #13
  14. Guest

    I think I will use a 120MHZ clock to do the job.

    Rgds
    André
     
    , Jul 22, 2005
    #14
  15. Guest

    >Maybe I am wrong, but where you need to do everything on one cycle?

    If I use the NXT signal directly from pin and I use the PHY clock as my
    FSM clock I have one cycle
    to answer with the appropiate data byte.
    The problem that arises is that I have to care about SETUP/HOLD timings
    because I check the signal NXT
    in almost all of my FSM states. If the FSM becomes large I have to
    assure that
    these timing are violated in NO state of the FSM.
    When working directly from pin it is not that easy as having registered
    NXT before. Am I right?

    Rgds
    André
     
    , Jul 22, 2005
    #15
  16. Andre,

    If you have one cycle to answer with the appropriate data byte, it means
    that there is no "no time".
    I think that this is the choice you have:
    (*) Sample NXT and then do everything combinationally.
    (**) Do everything combinationally and then sample the result (FSM state,
    data, etc)

    Both cases are viable solutions, but to resolve our worries with regards to
    setup/hold time, this is what you can do. 60 Mhz is ~16 ns. Let's talk about
    constraints again. What is the budget available for NXT signal? What's the
    budget for DATA in its output path (i.e. the input delay of the PHY device)?

    Regardless of the answer, you need to define a clock constraint, and OFFSET
    IN BEFORE / OFFSET IN AFTER for NXT signal.
    For the DATA output path, you have to use FROM TO to place the data_out FF
    accordingly.

    Vladislav

    <> wrote in message
    news:...
    >Maybe I am wrong, but where you need to do everything on one cycle?


    If I use the NXT signal directly from pin and I use the PHY clock as my
    FSM clock I have one cycle
    to answer with the appropiate data byte.
    The problem that arises is that I have to care about SETUP/HOLD timings
    because I check the signal NXT
    in almost all of my FSM states. If the FSM becomes large I have to
    assure that
    these timing are violated in NO state of the FSM.
    When working directly from pin it is not that easy as having registered
    NXT before. Am I right?

    Rgds
    André
     
    Vladislav Muravin, Jul 22, 2005
    #16
  17. wrote:

    > The problem that arises is that I have to care about SETUP/HOLD timings
    > because I check the signal NXT


    You don't have to worry about that if you use a synchronizer.
    Just assume that it works and the output is synchronous.
    Remember that you are using a 120MHZ fpga clock so you
    have several ticks to work with.

    > in almost all of my FSM states. If the FSM becomes large I have to
    > assure that
    > these timing are violated in NO state of the FSM.
    > When working directly from pin it is not that easy as having registered
    > NXT before. Am I right?


    No. Everything, even the synchronizer runs
    on the FPGA clock.

    -- Mike Treseler
     
    Mike Treseler, Jul 22, 2005
    #17
  18. Vladislav Muravin wrote:

    > If you have one cycle to answer with the appropriate data byte, it means
    > that there is no "no time".


    One cycle is plenty of time with a 120MHZ fpga clock.

    > I think that this is the choice you have:
    > (*) Sample NXT and then do everything combinationally.
    > (**) Do everything combinationally and then sample the result (FSM state,
    > data, etc)


    Or synchronize: NXT_raw-->[DQ]--[DQ]--NXT_Q--
    and do nothing combinationally.

    -- Mike Treseler
     
    Mike Treseler, Jul 22, 2005
    #18
  19. "Mike Treseler" <> wrote in message
    news:...
    > Vladislav Muravin wrote:
    >
    >> If you have one cycle to answer with the appropriate data byte, it means
    >> that there is no "no time".

    >
    > One cycle is plenty of time with a 120MHZ fpga clock.


    Yeah, I said " no "no time" ", which means !(!(time)) = plenty of time

    >
    >> I think that this is the choice you have:
    >> (*) Sample NXT and then do everything combinationally.
    >> (**) Do everything combinationally and then sample the result (FSM state,
    >> data, etc)

    >
    > Or synchronize: NXT_raw-->[DQ]--[DQ]--NXT_Q--
    > and do nothing combinationally.
    >
    > -- Mike Treseler


    Possibly, but 60 MHz constraints also would do just fine.
    In addition, if the state machine of Andre may be too complicated to run it
    on 120 MHz, we might have a problem.

    V
     
    Vladislav Muravin, Jul 22, 2005
    #19
  20. Guest

    But if I use a two stage FF synchronizer for NXT_raw
    and my answer byte to NXT_Q is also synchronous that is registered
    I would be one 120MHz clock cycle too late (?)

    Rgds
    André
     
    , Jul 25, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Lewin-Berlin

    Event handlers keep getting unregistered

    Steve Lewin-Berlin, Aug 6, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    323
    Steve Lewin-Berlin
    Aug 6, 2003
  2. Replies:
    6
    Views:
    602
  3. Ellie
    Replies:
    2
    Views:
    458
    Ellie
    Oct 30, 2008
  4. Ron

    Unregistered DLL in ASP

    Ron, Jul 24, 2003, in forum: ASP General
    Replies:
    1
    Views:
    105
    Tom Kaminski [MVP]
    Jul 24, 2003
  5. Paul Lalli

    groups of inputs using CGI.pm

    Paul Lalli, Aug 25, 2005, in forum: Perl Misc
    Replies:
    5
    Views:
    157
    Paul Lalli
    Aug 26, 2005
Loading...

Share This Page