Re: [Fx2lib-devel] Bad GPIF Code

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Hi,
>
> I have noticed that my GPIF code created by GPIF Designer is not 
> acting properly.  I'm getting data sampled when I should be getting 
> nothing.
>
>
> Attached is my GPIF designer file where I am trying to sample data 
> from an imager using the frame valid and line valid signals as 
> triggers.  Also attached is a sample of what the imager output is like 
> (ImageWaves.jpg).  I have PIXCLK feeding IFCLK, FRAME_VALID (FV) 
> feeding RDY0, LINE_VALID (LV) feeding RDY1, and the data attached to 
> FD[7:0].  I can get valid data sampled through the GPIF, but I am also 
> getting non-data sampled from when FV and or LV is not active.  Here 
> are two cuts of imager data from Cyconsole:
>
> 0180  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 0190  10 10 10 10 10 10 10 10 10 10 10 FF 00 00 80 85
> 01A0  84 7D 84 85 83 7D 83 86 82 7E 82 86 83 7E 84 88
>
> And
>
> 00A0  7F 7E 85 7F 7F 7E 85 7E 80 7D 84 7E 80 7D 85 7C
> 00B0  81 7D 82 7E 80 7E FF 00 00 9D 10 10 10 10 10 10
> 00C0  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
>
> The data following F0 00 00 80 and preceding F0 00 00 9D is valid 
> imager data, 10 is the default imager output when FV and or LV is not 
> active.  FF 00 00 80 is start of line, FF 00 00 9D is end of line.  No 
> matter what I have tried I keep getting data sampled when FV and or LV 
> is low.  I am working with the 56 pin CY7C68014A so I do not have 
> access to the GSTATE bits for debug.  I would appreciate it if anyone 
> could help me out.
>
Your state 0 reads data.  No matter if FV, LV is high or low, you read a 
byte when you enter the state machine.  I think you need to perhaps swap 
state 1 and state 0.
Another issue I see though, is what happens if FV, LV are high when you 
enter the state machine?  Don't you need to wait for them to go low 
again and then start transferring data when the next time FV, LV goes high?

I spent the last couple weeks working with my own Fifo Read issues.  I 
found a few things:

* Rdy0,1, txpire etc, are registered (The data 7:0 is too).  That means 
if Rdy0, rdy1 are true when the decision point tests them, that they 
were actually set during the previous clock cycle.
* When you enter a state, any control lines you set are registered out.  
That means if you set ctl0 high on state 2, that whatever you connect to 
the gpif receives the high a clock cycle later.

I started to develop a behavioral model for this.  It goes something 
like this if you are familiar with Verilog:

reg [2:0] state;
reg rdy0, rdy1;
reg ctl0,ctl1,ctl2;
reg data[7:0];
always @(posedge clk) begin
  rdy0 <= <input signal>;
  rdy1 <= <input signal>;
  data <= <input signals>;
  case (state)
    STATE0:
     begin
       ctl0 <= 1;
       // decision point logic
       if (rdy0) begin
          state <= STATE1;
       end
     end
    STATE1:
      ctl2 <= 1; // whatever you set the control lines to in state 1.
    // read state // do something with data
      someoutput <= data; // whatever
      if ( !rdy0) begin // decision point logic
       state <= STATE2;
     end
    STATE2:   
    // etc... I don't yet have code to dynamically read the gpif output 
so until then, I just coded the same as I did in the gpif designer.
  endcase
end