Two independent GPIF/FIFO interfaces with one CY7C68013A?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
FrZa_2625781
Level 4
Level 4
First solution authored 25 replies posted 10 replies posted

Hi,

I am using a CY7C68013A for an interface with a Slave FIFO configuration. The FIFO operates in autonomous mode at 8 bit width and streams about 4 MB/s in Bulk mode (may go up to 8 MB/s in a future application).

Now I'd like to add a second Interface, which would be an SPI-Master interface. As the first interface is 8 bit wide and fully autonomous, I have port D left an the full processing capability of the 8051.

As there isn't a second GPIF interface, I would have to mimic its function in software, like checking if there is data in an OUT buffer sent by the USB host and bit-banging it out of the port D pins (one pin for Select, one for CLK and one for DOUT), while sampling another port D pin (being used as DIN) and writing that data into an IN buffer.

Is something like that possible and if yes, has one of you already done it and could provide some example code or code sniplets?

Many thanks,

Frank

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hello Frank,

As mentioned in the EZ-USB Technical Reference Manual, Mode 0 operation is identical to the standard 8051.

I have attached the datasheet of MCS51 from Intel which contains the serial port timing for shift register mode (mode 0).

Hope this is helpful.

Thanks,

Yatheesh

View solution in original post

0 Likes
14 Replies
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Frank,

It is possible to bit bang the port pins to make it operational as needed.

We do not have any example code where the port is bit-banged to function similar to GPIF.

Thanks,

Yatheesh

0 Likes

Hi,

I have found AN14558, which describes bit bang transfer and also the use of the UART interface as a SPI master.

Unfortunately the exact timing is not clear with the UART interface.

In the EZ-USB Technical Reference Manual I have found the info that "At both low and high speed in Mode 0, data on RXD0 is sampled two CLKOUT cycles before the rising clock edge on TXD0".

So in high speed mode (with TXD0 being 1/4 of CLKOUT), it is sampled exactly on the falling clock edge.

Unfortunately it is not mentioned when exactly the RXD0OUT change is triggered.

It would be nice if someone could name a document where this is specified in.

Thanks,

Frank

0 Likes

Hello,

Figure 14-9 and Figure 14-10 from the EZ-USB Technical Reference Manual describes the exact timing for the FX2LP when Serial Port is used in mode 0 for transmission. 

RXD0OUT is first driven with the data and then a low to high transition is initiated on TXD0. A high-low transition of TXD0 is initiated when the next data is driven on the RXD0OUT.

Please have a look at the "Figure 8. Logic Analyzer Trace of the UART Mode0 Byte Write" from AN14558 for confirmation.

Thanks,

Yatheesh

0 Likes

No, it's not exact.

"RXD0OUT is first driven with the data"

When exactly is the data driven?

There is no event before RXD0OUT changes it's state.

"and then a low to high transition is initiated on TXD0. A high-low transition of TXD0 is initiated when the next data is driven on the RXD0OUT."

Is the high-low transition initiated as soon as RXD0OUT is presumed to be stable? Or is RXD0OUT driven (changed to next value) some number of clock cycles before the falling edge of TXDO like RXD0 is sampled two CLKOUT periods before the rising edge of TXD0?

Or ist it driven just at the low-high transition of TXDO and just takes one CLKOUT period delay in order to start changing? Or is it driven one CLKOUT period after that low-high transition?

Also in high speed mode (Fig. 14-10) the transition time seems like a bit less than one CLKOUT period, while in low speed mode (Fig. 14-9) it seems to take almost twice as long.

"Please have a look at the "Figure 8. Logic Analyzer Trace of the UART Mode0 Byte Write" from AN14558 for confirmation."

Figure 8 does also rather confuse me than clarify. With the short CLK high peaks one cannot discern if the positive or negative edge is the trigger, as a possible delay has to be taken into account. And when you look at the first two bytes, you see that MOSI changes state with the negative edges at about 7 sec and about 26µsec, but also with the positive edges at about 14 and 33µsec.

The information in the datasheet about the RXD0 being sampled 2 CLKOUT periods before the rising edge of TDX0 is really great (of course it would be even better if there were also some information about the according setup and hold times, like for instance "10nsec plus 2 CLKOUT periods before the rising edge of TXD0 to 2 CLKOUT periods minus 8.5nsec before the rising edge of TXD0").

I'd just wish there was an according info for the time when RXD0OUT is being updated (even without the according setup and hold times).

I assume someone would know it, but highly probable they wouldn't know that I need that info.

Regards,

Frank

P.S.:

The info regarding the USART is quite sparse anyway. Like if it would be possible to send multiple bytes without those huge gaps in between like they can be seen in the logic analyzer trace in figure 8.

P.P.S.:

Please don't take this as a rant. I really appreciate that you look into my problem.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Frank,

As mentioned in the EZ-USB Technical Reference Manual, Mode 0 operation is identical to the standard 8051.

I have attached the datasheet of MCS51 from Intel which contains the serial port timing for shift register mode (mode 0).

Hope this is helpful.

Thanks,

Yatheesh

0 Likes

Ok, RXD0 sampled 2 CLKOUT periods before the rising edge of TXD0, with an additional setup time of 133ns and a hold time of 2 CLKOUT periods, so up to the actual rising edge.

Looks like that in both modes, low and high speed.

RXD0OUT driven 10 CLKOUT periods before the rising edge of TXD0 with a maximum delay of 133ns until RXD0OUT is valid.

With 12 CLKOUT cycles per TXD0 cycle this means that the next RXD0OUT value will be driven 2 CLKOUT periods after the rising edge of TXD0 with some uncertainty making it invalid 117ns earlier.

Looking at the low speed operation this could actually fit, if it is assumed that the crossing of the lines in the valid/invalid data pattern actually resembles the typical drive moment.

But with the high speed operation, driving RXD0OUT 2 CLKOUT periods after the rising edge of TXD0 would mean that it is driven exactly at the falling edge.

This is not what it looks like in figure 14-10 and this is also not how it should be, as the output should be stable at the time in the clock cycle where the input is sampled, because both serial communication partners would sample their inputs at roughly the same time in the clock cycle.

So I'd still be interested in the actual CLKOUT edge where the new RXD0OUT value is being driven to the pin and an approximate time delay until it is valid in the high speed operation mode.

Regards,

Frank

0 Likes

Hi,

Aren't there some schematics, design files or the like of the USART part of the chip where someone could have a quick look?

I can't measure it in the lab because of Covid lockdown but I have to finish the board design.

The SPI must communicate wth an AD5293 and all that is missing on the board is the connection to the AD part.

AD5293-SPI-Pattern.png

As the CY7C68013A seems to sample RXD0 on the negative edge and the AD5293 drives its SDO on the positive edge, which makes it stable on the negative edge, that part would already be fine.

But the exact time when the FX2LP drives the RXD0OUT would be needed in order to know if I would have to put in some logic in between like a delay in the RXD0OUT to DIN connection or some latching or the like.

Kind Regards,

Frank

0 Likes

Hello Frank,

The Serial Interface Mode 0 (Shift Register) of the FX2LP follows the standard 8051 timings. We have not characterized this separately for the FX2LP. This is basically because the setup and hold times do not depend on the clock rate.

Sorry for the inconvenience.

Regards,

Yatheesh

0 Likes

Ok, let's assume that the original implementation in the 8051 is sampling RXD0 on the positive edge of CLKOUT at 2 CLKOUT cycles before the rising edge of TXD0 and driving RxD0OUT on the positive edge of CLKOUT at 2 CLKOUT cycles after the rising edge of TXD0.

Of course the setup and hold times do not change with the frequency, but the CLKOUT cycle scheme must change. If there are only 4 CLKOUT cycles in one TXD0 cycle instead of 12 of them, you have to scrap 8 cycles and it really matters where they are scrapped.

As the 8051 timing seems to be referenced to the positive edge of TXD0, I would assume that one would not scrap CLKOUT cycles between the sampling point and the positive edge (as is confirmed by the note that the sampling is alwasy 2 CLKOUT cycles before the rising edge of TXD0 with both speed modes), and also not between the positive edge and the driving point (2 CLKOUT cycles after that positive edge).

But in fig. 14-10 it rather looks like there is only one CLKOUT cycle between the positive edge of TXD0 ant the crossing of the lines describing the RXD0OUT state.

So either Cypress has deviated from the "2 CLKOUT cycles after TXD0" and made this only one cycle, or fig. 14-10 is inaccurate and the RXD0OUT pattern would have (should be) shifted one TXD0 cycle to the right.

As the TXD0 high pulse is only 2 CLKOUT cycles long with the high speed mode instead of the 3 cycles with the low speed mode (which seem necessary as the duty cycle would be quite high if all the scrapped CLKOUT cycles would have taken from the TXD0 low pulse), it might actually be the case that the onc cycle scapped here was one ot the two cycles that were before the driving edge of the RXD0OUT signal.

Is there really no way to have this clarified/confirmed?

Regards,

Frank

P.S.:

Is there an "official" high speed mode of an 8051 successor and therefore some kind of reference implementation, which would have been a guide in the FX2LP's USART development? And might that be documented somewhere?

P.P.S:

Ok, I found something in the DS80C320 datasheet.

It seems that that chip drives the data line also 1 clock cycle after the rising edge in the fast mode, as it seems to be the case in the FX2LP according to the figure 14-10.

But then the input data timings seem not to really match...

DS80C320-USART.png

0 Likes

Hello Yatheesh,

is there a way to confirm that with the fast mode RXD0OUT is driven ONE CLKOUT cycle after the rising edge of TXD0.

I know, with Covid-19 it may be problematic to measure this in the lab, but maybe this can be more easily confirmed with the design documentation of the FX2LP or with a simulation run.

Regards,

Frank

0 Likes

Hello Frank,

I will check for this internally and let you know if this data is available or if we have any additional data on Serial port Mode 0 timing of FX2LP.

As we have mentioned earlier, we have not characterized this data separately for FX2LP and have given the nominal timing diagram for reference in the Technical Reference Manual as per the standard 8051 implementation.

Thanks,

Yatheesh

0 Likes

Hello Yatheesh,

Yes, with the low speed operation the timings are just like with the original (output is updated 10 clock cycles before the positive edge, input is sampled 2 clock cycles before the positive edge) . An exception may be the position of the negative edge of TXD0 (it looks like the duty cycle would be 50% in the Intel 8051 family, while it is 25% with the CY7C68013A), but as all the timings are referenced to the positive edge, this would be more of a "cosmetic" difference.

Now with the high speed operation, there seems to be no real "standard 8051 implementation", and everyone seems to cook their own soup.

It is obvious that the timings have to deviate from the low speed timings, at least for the "output is updated 10 clock cycles before the positive edge" one, as there are only 4 clock cycles in one bit frame.

I think your engineers did a good job preserving the position of the input sampling action at 2 clock cycles before the positive edge and stating this in the datasheet.

Now for the position for the output updating action, keeping 10 cycles is impossible as I had mentioned before, so your engineers had to choose a new position. If there is a standard high speed operation, according to which your engineers have chosen the position of the output update action, it should be sufficient to refer to that standard implementation.

I think I don't really need setup and hold times as with modern technologies they are way shorter than the clock cycles we are talking about. I just need the number of clock cycles before or after the relevant TXD0 edge where the output is actually switched from data n to data n+1.

Regards,

Frank

P.S.:

The only other 8051 based chip I found that has a documented timing for the high speed operation is the DS80C320, but that one already deviates from the Intel 8051 timing even in the low speed mode (seems to sample the input 1 clock cycle before the rising edge instead of 2 clock cycles).

0 Likes

Hello Yatheesh,

Have you been able to find additional info internally?

Also, is there a possibility to send data via the USART faster than one byte at a time and having to wait until the flag is set before being able to write the next byte into the SBUF register?

Regards,

Frank

0 Likes

Hello Frank,

As of now we do not have any internal documents regarding the timings you are requesting for.

I will create an internal case regarding this and will update you with the details.

Thanks,

Yatheesh

0 Likes