Using unregistered inputs in FSM

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é
 
Some additional info:

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

Rgds
André
 
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.
Click to expand...

The latched data can then be treated using 2-stage ffs or any other possibilties to handle unsychronized data.
Click to expand...
Hubble.
 
I have never used latches. What is the problem about them ? Do Fitter
treat them predictable ?

André
 
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 ?
 
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
 
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. .

<ALuPin@web.de> wrote in message
news:1121846253.756193.223170@g44g2000cwa.googlegroups.com...
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é
 
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é
 
Maybe I am wrong, but where you need to do everything on one cycle?
Click to expand...
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é
 
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

<ALuPin@web.de> wrote in message
news:1122016975.381235.236820@o13g2000cwo.googlegroups.com...
Maybe I am wrong, but where you need to do everything on one cycle?
Click to expand...
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é
 
ALuPin@web.de wrote:

The problem that arises is that I have to care about SETUP/HOLD timings
because I check the signal NXT
Click to expand...
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?
Click to expand...
No. Everything, even the synchronizer runs
on the FPGA clock.

-- Mike Treseler
 
Vladislav Muravin wrote:

If you have one cycle to answer with the appropriate data byte, it means
that there is no "no time".
Click to expand...
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)
Click to expand...
Or synchronize: NXT_raw-->[DQ]--[DQ]--NXT_Q--
and do nothing combinationally.

-- Mike Treseler
 
"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:TKqdncuTH9VhYn3fRVn-tQ@comcast.com...
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.
Click to expand...
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
Click to expand...
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
 
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é
 
So, Andre...

What's up?
How are things going?
Are you successful so far?

V

<ALuPin@web.de> wrote in message
news:1122288612.740510.231080@g14g2000cwa.googlegroups.com...
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é
 
Hi Vladislav,

I am waiting for the new board release.

When I can test it I will give account.

Rgds
André
 
Hi,
I have one more question about placing registers:

If I have a bidirectional bus do I have to make the decision
whether to place the "input"bus into input registers (for better
tSU/tH) or whether to place
the "output" bus into output registers (for better tCO) ?
Or is there some option for both ?

I can imagine of situations when using input AND output registers could
be necessary,

Thank you for your answers.

Rgds
 
ALuPin@web.de writes:

Hi,
I have one more question about placing registers:

If I have a bidirectional bus do I have to make the decision
whether to place the "input"bus into input registers (for better
tSU/tH) or whether to place
the "output" bus into output registers (for better tCO) ?
Or is there some option for both ?
Click to expand...
You can register both, but the target silicon will dictate whether you
get the performance you want.

For example, the Flex10K architecture only has one flop in the IO
cell, so the other has to go in teh fabric. Altera claim this is
mitigated by the fast local interconnect, but I could never get the
timing to be reliable over all temp/voltage/process for a 100MHz SDRAM
interface. I either met tsu because the input register was packed in
the IO cell, or tco, because the output one was. I could never
persuade the software to place the "other" register close enough in
the fabric to meet timing.

Still, it worked in the environment we needed it to in the end - so
long as it didn't get too hot.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
 
ALuPin@web.de wrote:

If I have a bidirectional bus do I have to make the decision
whether to place the "input"bus into input registers (for better
tSU/tH) or whether to place
the "output" bus into output registers (for better tCO) ?
Or is there some option for both ?
Click to expand...
Registers are inferred from the code,
only placement can be constrained.
If I use both input and output registers
then I usually only need Fmax as a constraint and
I can let the place and route pick the
register location. Without an input
register, timing constraints are more
complicated.

-- Mike Treseler
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top