Hello,

Upfront, I have never worked with the Cypress parts (or ARM with an RTOS) but have lots of "regular" FPGA and MCU (PICs) experience. So I should be able to follow your advice, but currently I just don't know where to start or look to begin with to get me going. Or even if this is possible.

My current hardware is the FX3 USB Developement Kit. I don't specifically need USB 3.0, but I do need high-speed 2.0 instead of the fullspeed 2.0 my project currently has.

The first part of my need is a USB to I2C translator. I need to send a bulk transfer to the device, decode these bytes, and wiggle the I2C line. Then when things are received by the I2C line, re-encode, and send back through another bulk transfer endpoint. The second need is to monitor all edges of the I2C and decode all I2C traffic independently. Currently I have all this working and implemented in a standard PIC32 overclocked (120MHz/120MIPS). So I am hoping with the regular 200Mhz/200MIPS I can get something similar working even if the speed improvement is minimal. I am essentially maxed out with the PIC, hence the move.

So architecturally, does this even work? Can I use the built in MCU to write my firmware? I would suspect so. How much slower is slower when the MCU interprets every USB data transfer? Using the standard stream demo I can get 8MB per second. Is the interrupt overhead large? On the PIC it is 12, so interrupting on every rising and falling edge of an IO pin was expensive, but doable. I am hoping to cut that down, but am unfamiliar with the interrupt scheme used, or if that is even required. If I can poll the signal fast enough, that should be OK (400KHz maximum).

Or should I just be using the part as a passthrough and routing the packets to some large parallel bus and then another FPGA later in the stream? If possible, keeping it on one chip would be nice especially given the cost.

Am I understanding that correctly? You intend to analyze/check every single dataBIT of the I2C transmition? or are you refering to every single transmitted BYTE?? Will you please explain a bit more if you may???

Bob

I assume you'll be following I2C protocol i.e. you're monitoring each of the I2C lines in your previous design because you don't have a dedicated hardware I2C.

In the case of FX3/FX2LP there is a hardware I2C. So you don't have to decode the I2C traffic, the data part will be available in a buffer. Will this work or any specific reason you want to monitor each pulse?

Regards,

Anand

I have to monitor every bit transition on SDA and SCL to decode I2C /SMBus/PMBus. My current solution has a hardware I2C peripheral and I use it for outbound data. But the other point is to just sit idle on the bus and see the data. Meaning it cannot ACK anything and it must listen to all addresses and all data. I have not seen an I2C library peripheral that meant for passive looking, they all require an address range that they deem theirs and then AC K when they see it. This is exactly what I do not want it to do.