Cypress GPIF waveform behavioral model

I sent an email to the fx2lib mailing list that I thought would make good information for a bigger audience. Eventually, I’ll probably provide a Verilog behavioral model for the GPIF on the Cy7C68013 (and variants), but for now, this may help a few of you:

  • 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_r, rdy1_r;
reg ctl0_r,ctl1_r,ctl2_r;
reg data_r[7:0];
always @(posedge clk) begin
rdy0_r <= // rdy0 signal
rdy1_r <= // rdy1 signal
data_r <= // data signals
case (state)
     ctl0_r <= // state 0 ctl0 state
     // example decision point logic
     if (rdy0_r) begin
        state <= STATE1;
    ctl2_r <= // whatever you set the control lines to in state 1.
   // example read state // do something with data  
    someoutput <= data_r; // whatever
    if ( !rdy0_r) begin // decision point logic
     state <= STATE2;
   // etc... I don't yet have code to dynamically read the gpif output 
   // so until then, I just coded each state the same as I did in the
   // gpif designer.

Anyway, I was able to get a functioning simulation of my device from the perspective of the 8051 by modeling the GPIF this way. When I get some time, I'd like to make this generic enough to parse the GPIF designer output and model each state dynamically so the simulation can simply call the single read, single write, and fifo waveforms and the model will execute the waveform correctly. For now, if you're going down this road of simulation, you should be able to simply mimic your GPIF waveform this way.


This entry was posted in Hardware, Programming and tagged , , , , , , , . Bookmark the permalink.

4 Responses to Cypress GPIF waveform behavioral model

  1. jmelson says:

    Much appreciate your work on the FX2 chip. I have applied for membership on the mailing list, but in the meantime have a question. I have downloaded fx2lib, and am tinkering with the examples. I started with what looked like the simplest one, lights.c I have gotten it so compile without errors with sdcc, and have tried to load it with cycfx2prog, but I don’t see any output. I assume this is supposed to ripple some of the data pins? I haven’t figured out how _light_dummy maps out to the I/O ports, so I couldn’t guess what pins it was supposed to toggle, so I checked them all.

    I have used Wolfgang Wieser’s fx2pipe program which at least loads and runs. I have not been able to figure out the relationship between the data transfer rates reported by that program and the FLAG bit outputs coming from the FX2 chip, but that is a totally different matter.

    Anyway, the project at hand is to control some custom hardware that is currently driven through a parallel port. So, 8 data bits and 3 write strobes (select module, select register, write data to register).
    The GPIF ought to be able to do this with very little additional logic except for maybe a 2:4 decoder and bus driver chips. The idea is to send a bunch of device commands in one packet, the data in the even bytes, the control strobes in the odd bytes, and the GPIF would provide suitable delays and gate the strobes with one of the FLAG pins to provide adequate setup times and pacing. But, I’m finding it very hard to figure out how to make all this work. (Doesn’t help that I had to put this project aside for 3-4 months while other stuff needed attention.)



  2. Dennis says:

    Hi Jon,

    I’ll go ahead and respond on the mailing list then.

  3. spiegelt says:

    Hi Dennis,

    can you please send me the verilog code of your Cypress GPIF waveform behavioral model?


  4. Dennis says:

    What you see there is what you get.

    I eventually gave up entirely on the GPIF in favor of slave fifo. The gpif just had too many quirks and exceptions to make it useful for other than experimenting. I worked with Cypress Technical support on one particular issue for a month or so and they never did provide a good working solution. I think if you have one of the parts they specifically designed the GPIF for, you’d be ok. If you have an FPGA though, there is no reason to not use slave fifo.

Comments are closed.