Using unregistered inputs in FSM

Some additional info:

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

Rgds Andr=E9

One way to help is to multiply your clock up so that you have several edges to react on. You can register the input with one of these edges and that should have a fixed minimum relationship to your main clock if your multipled clock is phase locked to the input clock. Another similar and crude way is to use the negative edge of the clock if your timing allows to sync the input. The state machine then uses it on the positive edge.

Failing that grey-encoded machines or even one-hot machines where effectively the input is "looked at" by a single flip-flop are also a reasonable thing to do.

John Adair Enterpoint Ltd. - Home of MINI-CAN. The Spartan3 CAN Development Board.

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é

conditions. Using delays, you can even design circuitry handling negative setup times properly etc.

possibilties to handle unsychronized data.

Hubble.

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

Andr=E9

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 ?

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.

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

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

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

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

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. .

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é

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:

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=E9

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

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

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:

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é

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

Rgds Andr=E9

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=E9

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

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é

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.

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

-- Mike Treseler

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

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

-- Mike Treseler

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

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