Newb: FSM in no valid state?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hey all:

I'm working with Altera's Stratix 1S40 dev kit, and am debugging a CMOS
sensor interface where the FSM that control's the FIFO appears to be in
no state. The purpose of this CMOS sensor interface is to simply take
the 16-bit data from the sensor on every rising edge of the pixel clock
(27 MHz) and make it available to the Nios 2 processor (via the Avalon
bus; ~50 MHz).

To this end, I've used a dual clock FIFO, with the write port connected
to the sensor, and the read port to the avalon interface (+ glue logic,
of course). I also have a 3-state FSM (to control the FIFO) that (state
1) simply waits for the frame from the sensor to become valid, then
(state 2) wait for the horizontal line to be valid and finally (state 3)
writes to the fifo until its full.

Now the problem appears when I use Nios to transfer the contents of the
FIFO directly to the UART (and to a computer for some post-processing);
after a few 1000 pixels (around 15% of the total), the stream of data to
the computer stops. After some debugging with Nios' GDB/Eclipse getup
and SignalTap it appears that the constructed FSM is in no state (since
the signaltap signals <state_signal>.<state_name> for each of the 3
states were low).

During the compilation process, I received no warnings/errors regarding
timing constraints etc. or anything else for that matter. I am at a
complete loss as to how to even begin fixing this. Thoughts anyone?

Thanks in advance,

James

Re: Newb: FSM in no valid state?
Hi James,
If I understand you correctly, you are using a ONE-HOT encoding style
(3 flops - one for each state) . Try to convert the FSM encoding style
to GRAY and check it out. Maybe your FSM suffers from some asynchronous
related problems, if the GRAY will reduce or eliminate the occuronce
rate of this problem (no state problem) then you know that you have to
check your design for async hazards.

I hope that it is helpful, Moti.


Re: Newb: FSM in no valid state?
Quoted text here. Click to load it

I've recompiled the FSM with gray coding, so now it seems to be in a
valid state, but it seems that the FSM isn't the culprit now. It appears
that when my fifo write signal is asserted, the fifo doesn't actually
start storing information. The odd part was that it WAS doing that a few
microseconds ago at system reset, but no more, and nothing short of a
system reset is able to fix it.

Quoted text here. Click to load it

But it seems to me that everything in the circuit is synchronized to
either the pixel clock or the system clock, and from what little I
remember from my digital logic course I thought the dual clock fifo was
supposed to do the synchronization between the two clock domains, so I
don't really know where a hazard could exist.

Quoted text here. Click to load it

Re: Newb: FSM in no valid state?

Quoted text here. Click to load it

Consider a synchronous fifo on the fastest clock.
Synchronize the slow side to the fast clock.

Quoted text here. Click to load it

Smells like a logic race.
Bogus full or empty from the fifo?

  After some debugging with Nios' GDB/Eclipse getup
Quoted text here. Click to load it

Consider binary encoding.

Quoted text here. Click to load it

Logic races come without warning to
teach the lessons of synchronization.

           -- Mike Treseler

Re: Newb: FSM in no valid state?


Quoted text here. Click to load it

I'm sorry perhaps I don't understand the term "synchronous fifo" or what
a dual clock fifo is, but wouldn't the dc-fifo be synchronized on the
write side to the write clock, and on the read side to the read clock.
If it helps I'm using Altera's provided lpm_fifo_dc megafunction.

Quoted text here. Click to load it

Well since I'm using Altera's provided megafunction (lpm_fifo_dc), I've
assumed that it generates the full/empty signals correctly. But I
suppose I could try checking under the hood, tho I'd rather not cuz of
the daunting (from my point of view atleast) hierarchy present under the
lpm_fifo_dc megafunction.

I re-encoded my FSM using gray coding for the states, and it now seems
to be in the correct state. However the problem seems to have migrated
to the fifo, which doesn't want to store information. When I assert the
write signal, it doesn't take for some reason, and the fifo empty signal
stays active. Odd thing was that it worked fine but a few microseconds
earlier.

Quoted text here. Click to load it

--
James

Site Timeline