Using unregistered inputs in FSM

[ALuPin]

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é

 

[ALuPin]

Some additional info:

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

Rgds
André

 

[Hubble]

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.

 

[ALuPin]

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

André

 

[ALuPin]

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 ?

 

[Mike Treseler]

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

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

 

[Peter Alfke]

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

 

[Mike Treseler]

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

 

[Vladislav Muravin]

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

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é

 

[ALuPin]

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é

 

[Mike Treseler]

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

 

[Vladislav Muravin]

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



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é

 

[ALuPin]

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

Rgds
André

 

[ALuPin]

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]

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

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é

 

[Mike Treseler]

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]

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

 

[Vladislav Muravin]

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

 

[ALuPin]

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é