How to Write FSM???

Hi,
I am trying to draw a state machine for a the Data Processing Logic Of
A Controller Area Network code i am writing.

This is my first actual 'project' in VHDL, and is it wise to use the
FSM approch?

also i am trying to understand how to convert the CAN specs to a FSM
say i am receiving the Identifier,a 11 bit sequence, then i can be in
the 'identifier' state with the incoming bits as one of the
inputs,being stored in a shift register. Can you guys please tell me
how i describe the transition of state after 11 incoming bits?

my idea is to load a counter with 11d and decrement it till i get 00h
and use this as an input but the problem here is that i would be using
a circuitry specific to this state and this input specific to this
state and wont have relevance in other states. can we have this kind of
vestigial inputs for other states. i am sure that will work but i dont
think thats how it should be done....can anyone guide me?

is there any good literature i can refer to,to understand how to
convert real life problem to a FSM?

thank you
K Sabarinath
--
>>>When you really want something the whole world conspires in making you get it <<<

cafm

cafm wrote:


> say i am receiving the Identifier,a 11 bit sequence, then i can be in
> the 'identifier' state with the incoming bits as one of the
> inputs,being stored in a shift register. Can you guys please tell me
> how i describe the transition of state after 11 incoming bits?

Consider comparing the value of
an 11 bit shift register on each rising edge.

-- Mike Treseler

Mike Treseler

Sorry Mike did not get you...maybe i should rephrase the question...

the data frame format of CAN is

-------------------------------------------------------------------------------------------------------
SOF | Identifier | Control Field | Data Field | CRC Field | ACK Field|
EOF|
--1-------11+1-------------6-------------0-8bytes--------16--------------2--------------1---

numbers indicate length in bit...


each part needs to be processed seperatly in a different logic
module.....other than the length i dont find any distinguising
character to seperate the parts.So I could have the reception of each
part as a state.
My question was...If i were to implement a FSM which changes state
based on a dynamically loaded down counter containing the length of
each field, would that be good design. Or do i have to go on and define
states for each bit?
but now that i think of it even using the counter i am actually
defining more states, the state and the counter value taken together.

is this a good design method....since its like have a set of states
with in a state?

cafm

cafm wrote:
> Sorry Mike did not get you...maybe i should rephrase the question...
> the data frame format of CAN is
> -------------------------------------------------------------------------------------------------------
> SOF | Identifier | Control Field | Data Field | CRC Field | ACK Field|
> EOF|
> --1-------11+1-------------6-------------0-8bytes--------16--------------2--------------1---
>
> numbers indicate length in bit...

Looks like hdlc packets.
Step one is to recover data and clock from the line.
Step two is to find the flag characters at SOF/EOF
and remove the stuffed zeros in between.
Step three depends on what it is you want to do with the packets?
Check the CRC?
Gather statistics?
Buffer up the Data fields by Identifier for a uP?
Do you want to transmit also?

> My question was...If i were to implement a FSM which changes state
> based on a dynamically loaded down counter containing the length of
> each field, would that be good design.

Don't bother with design details until you
picked a design objective. My personal opinion
is that the state machine model is archaic
compared to the vhdl synchronous process model.

-- Mike Treseler

Mike Treseler

Thank you mike...
I just wanted to know if i should follow intuition for the design or
use a standard 'method' such as FSM based design....and after reading
your comments i think i should stick to intuition
>>> Do you want to transmit also?
yes....but i want to first be able to reliably read a bit stream from
the MCP 2515 standard CAN module....the bit timing logic of CAN seems a
bit tricky and i dont want to bite more that i can handle...for now

thank you again...
sabari

cafm

"cafm" <> escribió en el mensaje
news: oups.com...
> Thank you mike...
> I just wanted to know if i should follow intuition for the design or
> use a standard 'method' such as FSM based design....and after reading
> your comments i think i should stick to intuition
> >>> Do you want to transmit also?
> yes....but i want to first be able to reliably read a bit stream from
> the MCP 2515 standard CAN module....the bit timing logic of CAN seems a
> bit tricky and i dont want to bite more that i can handle...for now
>
> thank you again...
> sabari
>


A CAN Controller is not an easy project. I would recommend some other
(easier) to start playing with FSMs.

But if you wanna play with CAN...

In a CAN network, clock is not recovered from the incoming line.
Both transmitter and receiver should be configured to work at the same speed.
Receiver uses line transitions to resync its local clock (in finite steps or quantums).
So it's mandatory you have some timing configuration registers
to match the timing (speed, quantum) of your standard CAN controller that acts as
tranmitter.

You can simply copy the register profile of an existing CAN controller (MCP2510, SJA1000,
....),
but remember that the nominal bit time must be dinamycally adjusted
(by hard-synchronization or re-synchronization).

To ensure there are enough transitions, bit stuffing is used every 5 (or 6, I can't
remember now) bits.
That is, after a sequence of bits of the same polarity, a reverse polarity bit is sent by
the transmitter (and must be discarded by the receiver).
So there must be a bit-destuffing filter in the receiver side to discard those bits.

And _any_ receiver must be able to transmit.
For example, the receiver must send an error frame if a bit-stuffing error, frame error,
CRC error, etc. is detected.
Finally, if you don't ACK the frame you receive, the transmitter will
re-transmit if again and again until it reaches the bus-off condition, right?
You can start sending positive ACKs for any frame you receive,
and then add actual checking procedures (stuffing, frame format, crc, ...) one by one.
But sending the ACK is absolutely mandatory.

So, to answer your question about FSMs and counters, yes.
You can use a counter in a given state to decide the next transition
(for example, to remain in a state "RECEIVING_MSG_ID" for 11 consecutive bits).
If this counter is loadable it can be reused
(for example, to receive data bits, or to collect the 15-bit CRC).

But, taking bit-stuffing into account, the counter must have an enable to count
(while receiving meaningful bits) or not (to discard the incoming, stuffed bit).

Remember a CAN receiver should store the CAN ID, RTR, DLC and data fields
of the incoming frame in memory (in 8-bit chunks) so the microcontroller
of the receiver side can process the message. So you actually need two
different states to receive the msg ID, one to receive 8 bits
and the other to receive the remaining 3 bits, storing the received info
at the end of each state.

And there should be, at least, 2 different FSMs working at different frequencies.
The receiver resynchronization FSM, working at 1/Tq (Tq = Period of a bit quantum),
and the receiver/destuffing FSM, working at 1/Tb (Tb = Period of bit, multiple of Tq).

How are you planning to verify the design? Because just receiving frames
and displaying them (or sending them back to the original transmitter) is not enough.
Only if you can send faulty frames to the receiver you can test
its error checking mechanisms and verify they're working properly.

Regards and good luck

Paco

Francisco Rodriguez