0
\$\begingroup\$

Seriously, I mean the "logic": not AND and OR gates, but the intuition behind it.

This will be an investment of time for whoever answers, so I understand those who don't want to! I'm using this half as a way to get my thoughts in order, but to also get valuable insight from others on this website.

Here is my situation:

I have a CPU that is hardwired to a Kintex-7 FPGA. From the CPU, I am using "Xilinx System Generator" (an add-on to Simulink) to program the FPGA. From the FPGA, we have a 6 RX fiber optic cables and 6 TX fiber optic cables.

In our current setup, we are using all 6 of the TX cables in order to send gate signals to a three-phase half-bridge converter. Obviously, using 6 cables to drive 6 gate signals isn't a very elegant solution.

What I would like to do is remove the need for 5 of the cables. My plan is to take all of the gate signal information (which should only be 6 bits at a time), and feed it to a "Lattice" FPGA (I think Lattice is one of the major players in the FPGA market, and their products are quite cheap on Digikey).

My idea is as so: on the Lattice, have a counter and an incrementer. On the single fiber optic cable, the first bit would be a clock pulse: this first bit would reset the counter and incrementer on the Lattice FPGA. The following 12 bits would be gates 1-12. By resetting the counter, I think it would be easy to tell which gate signal to go where: the first clock cycle following the reset would trigger the first gate, the second would trigger the second, and so on.

As I was writing this, I realized this isn't going to be trivial: assuring that the Kintex-7 FPGA and the Lattice FPGA are phase- and clock-locked may not be a simple task. I believe this is the area that I need the most help in. Once I can get the FPGA's clocks to be locked together, I believe this will be an easy task.

Any opinions on how I can accomplish this? Having 6 TX/RX fiber optic cables doing the job of 1 cable makes me cringe; I know I can

\$\endgroup\$
  • \$\begingroup\$ What is your convertor frequency, input and output voltage? I assume that the 6 optically isolated signals are nothing to do with high speed signals, but to do with the non-grounded drive required for the half bridges. The Half-bridge gate drives may be separated by hundreds of volts if you are doing larger scale power conversion. So getting all the signals into one channel would be pointless. \$\endgroup\$ – Jack Creasey Aug 29 '17 at 3:33
1
\$\begingroup\$

Once I can get the FPGA's clocks to be locked together

Rather than do this, consider using the typical solution for transferring high speed serial data along a single lane: use an encoding from which the clock can be recovered. 8b/10b is perhaps the most common encoding for this, used in HDMI/DVI/DisplayPort/Firewire/SATA/SAS and so on. 8b/10b will ensure your signal is DC-balanced and has enough edges to reliably recover a clock.

I am not very familiar with Lattice FPGAs, but most FPGAs (with the exception of very low cost devices have built in SERDES blocks. Transceiver IP can greatly the configuration of these transceivers. Given that you are using a Kintex-7, you should have GTX transceivers at your disposal, which can operate plenty quick (12.5 Gbps). Additionally, you will likely want to implement some rudimentary protocol (to perhaps carry more refined timing information) on top of the 8b/10b encoding, but for your use case it can probably be quite simple.

You didn't provide any details of your fiber transceiver(s), but I'm assuming it's designed to be driven by some flavour of high-speed serial transceiver, and should be easy to connect to the transceivers at both ends. What is the interval between gate signals (i.e. what clock rate is the far end operating at)? If it's long enough, you can send an entire symbol to indicate each gate state change. Linking a timing diagram of your gate drives would be helpful.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the answer, @uint128_t; very insightful. The switching frequency is only 4kHz, so I'm thinking I could probably used a SERDES block. I've never heard of these before, so I will look into it right away. \$\endgroup\$ – Lerbi Aug 29 '17 at 16:14
1
\$\begingroup\$

Essentially you are asking for a circuitry to convert 6-bit parallel code into one serial link, and then de-serialize it back into 6 channels. Electronic industry has invented this kind of circuitry long time ago. This line of ICs is called "SERDES". Example: enter image description here Several companies make similar circuits for all kind of applications, TI, ONsemi, Maxim, Intersil, etc. Xilinx FPGA'a have built-in high-speed SerDes IO blocks. Google for "serdes", you will find plenty of references.

\$\endgroup\$
1
\$\begingroup\$

as uint128_t has pointed out indirectly this problem has been solved many times over. 8b/10b is pretty old there are a number of others newer and older. And numerous ways to serialize and extract the data. If bursty data and you can tolerate some latency then you store it up and burst it out with a network like header long enough string of ones and zeros as a pattern then the data. If you need continous look at IRIG 106 chapter 4 pulse code modulation standards, been around forever, hardly worth writing a standard for, it is a somewhat obvious solution. Just do a straight parallel to serial conversion, but put a frame around it with a sync pattern that you can find on the other end, like uart but for more than 8 or 9 bits per frame. You can go even simpler and take the mil-std-1553 idea. Use biphase-l (see the pcm code definitions of irig one or two of these are used in other areas using different names like manchester or manchester II) which insures you wont have more than two half bit cells at the same level...for the sync pattern violate that on purpose three half cells high three low then some number of bits, repeat, easy to detect the sync pattern and re-parallelize the data. biphase-l (manchester II and other names) makes it easy to recover the clock and lock on the data stream, then you need a sync pattern of some sort to know where to start slicing the bytes/words from the stream of bits. Look up the technologies that uint128_t pointed out. maybe add a few more pcie, ethernet. slower speed ethernet uses 8b/10b faster uses something similar but less overhead.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.