First of all, I would like to congratulate you for the XEM. The USB concept of FPGA programming you implemented is brilliant and simple. The documentation and the library are neat and very clear. Moreover, it is very easy to put everything at work (not very common these days).
I have few suggestions/questions :rolleyes: :
Throttled pipes. In my current project I spent a good deal of time synchronizing the communication between my external hardware (a TI DSP) and the USB. Do you think it would be useful for others?
Is there a way to have access to a RESET signal coming from the Reset function in the FrontPanel library?
The function ReadFromPipe function is sometimes confusing. It returns always the number of bytes requested, even if there are not that many bytes in the buffer. Is it possible to return the actual number of bytes read?
the ti_control bus is somehow mysterious. Do you think it would be possible to know how the communication between the USB host and the endpoints is implemented?
The previous point bring also another point. I noticed that the simulated signals (in ti_control) in Modelsim for some kind of endpoints do not match with the real one (BufferedPipeOut).
I believe there is an error at pag. 60 of the FrontPanel manual. okFPsim_v2_ver is actually okFPsim_ver. Without that the simulation doesn’t work.
Pag. 28 of the same manual. It is not clear to me if the 2047-byte (8bits) buffered pipeout is actually 2047-word (16 bits) deep.
Thanks for the kind comments and good suggestions!
The two errors in the FrontPanel User’s Manual have been fixed. Thanks. The BufferedPipe[In|Out] is 2047-words deep for v2, and 2047-bytes deep for v1. The word-wide version uses two BRAMs. If you can use the Xilinx CORE generator, we actually suggest using the FIFO Core (from the FIFO Generator - v2.2 is the latest). The core allows better optimization for a particular application. It can be connected directly to the okPipe[In|Out] module. We provide the BufferedPipes for the many users that are using the Xilinx WebPack and therefore don’t have access to the Core Generator.
Let me explain our reasoning on the RESET function – it’s there to support the HDL endpoints because it is sync’ed to TI_CLK. User logic will typically not be sync’ed to TI_CLK and relying on a RESET on a different clock is asking for strange problems. It is better to use TriggerIns for user logic reset – that way you can decide what clock you want it on. In fact, you could have the same trigger (0x40:3, for example) mapped to multiple clock domains and it would provide a reset sync’ed to each clock. Just instantiate multiple okTriggerIn endpoints with the same address (0x40) and different EP_CLKs.
Regarding TI_CONTROL and the simulations… The simulations are designed to present the same signals at the ‘user-side’ of the endpoints. It is possible that the TI_CONTROL stuff may change at some future date to support more functionality. That’s why it is essentially hidden from view. It’s not intended to be mysterious – just undocumented BufferedPipes are implemented quite simply – an async FIFO and a Pipe[In|Out].
Regarding throttled pipes – we are trying to determine when and how to work this functionality into the design. Tell me a bit more about what you are doing with the TI and I may be able to suggest some other techniques to synchronize and increase performance.
Sure, I can tell you what my application is all about.
I’m building a real-time system based on a TI C6713 DSP. This system communicates to the PC a series of messages generated by the different hardware components. It is important to notice that the data is into a “message” form. Different parts of the system generate different messages, which are collected by the DSP and transmitted to the PC. Since the specifications of the system explicitly indicate messages, I cannot do otherwise. The messages are generated by the sub-systems every 1ms, and they are an undetermined number.
Every 5ms the PC collects all messages present in the communication buffer (reading all 2047 words), checks if the messages are well formed, and updates some internal status. The 5ms are strictly set by the 200Hz refresh rate of our graphic system, which uses the messages to update some stimuli on a CRT. The system works fine until there is no overlapping between the PC reading operation and the DSP writing operation.
The protocol I designed is very efficient at the moment. I wrote a simple VHDL component that sniffs if the PC is reading the information from a specific okBufferedPipeOut by monitoring the TI_CONTROL bus. If so, depending upon where this event occurs, the DSP resends the last message which was cut. The communication protocol works very well, and no message is ever lost.
My main concern is that I had to tap (sorry about that!) into the TI_CONTROL bus in order to know exactly when the PC was reading from a specific end-point (the FPGA contains several end-points with different functions). The very day you change the TI_CONTROL mechanism/protocol, I will have to change my VHDL component accordingly.
Throttled pipes would avoid the problem and insure the integrity of every single message in a very simple and effective way. The DSP would just need to disable the reading side of the okBufferedPipeOut only for the period needed to write the message. The PC would just need to check if any well formed message has arrived.
I hope I have been exhaustive, and let me know what you think.
I have a suggestion that may help, assuming I understand the reason you are using TI_CONTROL.
My understanding is that you are using TI_CONTROL because the “EP_READ” signal is embedded within the okBufferedPipeOut and therefore you don’t get any notice that the PC is reading from that endpoint.
I think exposing EP_READ to the user-side could be a valuable addition to the okBufferedPipeOut and will look into making that change for future HDL versions. In the meantime, consider the following:
Create an okPipeOut() instance and assign it the same endpoint, but do not connect the TI_DATA lines. This will ‘properly’ represent EP_READ to your logic without having to pull from TI_CONTROL. [Note I have not tested this, but see no reason why it wouldn’t work – we occasionally attach multiple TriggerIns to the same endpoint to get multiple triggers on different clock domains]
If you are using a Xilinx ISE version that allows you to generate Cores, I suggest not using okBufferedPipes at all. Instead, use the FIFO Generator and tie the connections directly to okPipe[In|Out]. The FIFO Generator builds better FIFOs than the FIFO in the BufferedPipes. It is my understanding that Xilinx intends to include the Core Generator in their free software due out this month.
Somehow I still think that throttled pipes would be a great addition to you product. Nevertheless, your suggestion definitely hits the point. The real problem is that I don’t know when the PC is reading the specific endpoint. I didn’t know that I could add two components with the same address. The EP_READ exposed by the okPipeOut will have exactly the same function of my VHDL component, without the drawback of the TI_CONTROL tapping :). Thank you! Did you ever think of creating a component only for the address decoding part? Just to give people the possibility to write their own components?
The CORE generator free in the Xilinx is another great news! I work only with the free version… and the free CORE generator will be a invaluable addition.
BufferedPipes are implemented quite simply – an async FIFO and a Pipe[In|Out].