SpaceWire VC

[Michael]

Hey all,

I have a question about how one might go about creating a VC for a communication protocol such as SpaceWire, where there is no clear Master/Slave relationship between the nodes.

My concern is that in order to establish a connection with a SpaceWire node, some handshaking needs to be done between the sender and receiver. Due to the fact that one SpaceWire node consists of tx and rx lines, would it make sense to break the VC up into two separate VC’s: a tx and rx? If that is done, would you have shared variables that communicate between your TestControl processes that allow the handshaking to occur?

If you were to wrap the tx and rx into one VC, would that be handled in one process in the TestControl? If that is done, how would you be able to independently send “send” and “get” commands to your node?

I know these are pretty vague, high-level questions, but I’m considering adding a SpaceWire VC to our library, but it doesn’t follow the same flow control as a UART or HDLC protocol.

Regards,
Michael

[Jim Lewis]

Hi Michael,
I looked at this a little bit in the past.

The approach to modeling here requires thinking about the interface side (the handlers), the internal control side (for initialization and other tasks), and the transaction side (here TX and RX). I think in TestCtrl, transactions for TX and RX still need to be able to be dispatched separately – so they need separate transaction interfaces (records).

If you think about a UART, OSVVM created its UART as separate UartTx and UartRx VC. This is one possible implementation. Another is to combine them into a single VC. Since the handlers for UartTx and UartRx are independent, this could be done by encapsulating the current implementation into that bigger VC. This results in having a separate transaction interface for TX and RX.

If we return to SpaceWire, structurally it is similar to combining the UartTx and UartRx into a single VC and removing the extra level of hierarchy (the entity for UartTx and UartRx) as SpaceWire has TX and RX functionality that interact – particularly during system startup.

This is a VC that I am interested in working on and have already done a read of the Spec.

Best Regards,
Jim

[Michael]

Hey Jim,

Thanks for the info! I am planning on making one VC that encapsulates both tx and rx, but takes two transaction interfaces so that you can send and receive independently. Similar to how you mentioned in your first paragraph.

Due to how much the tx and rx need to talk to each other with regards to flow control and intialization, I am thinking of setting up the SpaceWire VC to use the rx and tx fifo that comes with the protocol to interface with the transaction records.

For example, a send command would write the data into the tx fifo, which would then alert the VC that data is ready to be transmitted. The VC would then initalize the link (if not yet initialized) and interleave the data in the tx fifo with the flow control tokens and time codes as necessary. If the tx fifo is empty and the link is connected, then it would simply send null characters until either the link is disconnected or there is data in the tx fifo.

A get command would poll the rx fifo to see if the SpaceWire has received data. The VC internals would take care of managing the flow control tokens being sent out. The SpaceWire VC would continue to receive data until it has run out of flow control tokens and would only allow more data to be read in as you pull it out the other end of the fifo using the get commands (essentially replenishing the flow control token count).

You don’t necessarily have to comment on this, unless you see an obvious error! I am mostly thinking aloud.

Thanks again!

[Author]

Posts