1
\$\begingroup\$

I'm modeling a camera-serial interface in Verilog. My design takes video frames in, packetizes them in a certain format, and then distributes them among 1 to 4 parallel lanes. Each lane is 8 bits wide. It is configurable how many lanes you want to use. The packetizer passes 32 bits to the lane distributor every clock cycle.

My question is what is the best way to pass data along without throttling if less than 4 lanes are used?

So if 32 bits are passed and only two lanes are open, the distributor can only pass 16 bits per clock. Is there a fast way to do this without control signals that stop the packtizer from send data every other clock. It seems like there isn't because the data would pile up.

Any help would be appreciated!

Another question: at the end of the data send, there needs to be and "End of Transmission" byte sent on every lane. How would you handle this if the number of bytes sent is not a multiple of the number of lanes? The EoT byte would be sent on different lanes at different clocks. Is there a nice way of modifying a state machine to handle these edge cases?

\$\endgroup\$
2
\$\begingroup\$

If you cannot stop the camera/packetizer from sending 32 bits per clock, then you either must do one of the following:

  1. Implement a huge FIFO in your logic which can store the overflow. If you have 16 bit output and 32 bit input, then the fifo must be large enough to store 50% of the total size of the camera image (as you can send out half the bytes as they come in). If you have only 8 bit output, then the fifo must be large enough to store 75% of the total size of one frame. Note if you do this you must allow time for the fifo to clear before starting the next frame.
  2. Make the output clock faster than the input clock. Needs to be 2x faster in the case of 16 bit output, or 4x faster in the case of 8 bit output.

Is there a nice way of modifying a state machine to handle these edge cases?

Not really, you just have to specify the behavior you want. There's not a magic statement that will automatically handle it. My suggestion is to just think hard about exactly how you want your protocol to work, and then code the transmitter and receiver to match the specification. If you're designing both the transmitter and receiver just pick however you want your EoT bytes to work that makes the most sense to you.

\$\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.