Newb: FSM in no valid state?

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

Reply to
James
Loading thread data ...

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.

Reply to
Moti

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

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

After some debugging with Nios' GDB/Eclipse getup

Consider binary encoding.

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

-- Mike Treseler

Reply to
Mike Treseler

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.

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.

Reply to
James

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.

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.

--
James
Reply to
James

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.