I’m trying to send data from XEM6001 through python using either PipeOut or BlockPipeOut. According to the documentation, you want to initialize the buffer string similar to
“\x00”*16
for 16 bytes transfer. However, this means I will have 816 bits of data. When I tried this, I realized that the EP_READ signal is actually on for 16 cycles (which makes sense) however, the data for each cycle of PipeOut is 16 bit wide. Doesn’t this imply that I should get 1616 bits of data instead of 8*16 bits of data? Where does the rest go?
Thank you for any input.
First, doesn’t "\x00"16 mean you’ll have 168-bits of data?
Second, this should mean that EP_READ is asserted for 8 cycles. Do you have a ChipScope trace to indicate otherwise?
Yes, "\x00"16 means I should have 816 bit of data. So you are saying that if we request only 8*16 bit of data then the PipeOut should try to read only for 8 cycles?
Specifically what I’m trying (as a prototyping stage) is to have PipeOut read from FIFO output. In the test circuit I write a sequence of 16-bit wide number into FIFO like 0,1,2,3,4,5?.. and then have PipeOut read from it.
The result I got is instead 1,3,5,?. (there’s also another issue: it’s not always 1,3,5,… sometimes it becomes other things like 1,3,5,6 8,10?) So I think there’s a funny thing going on in the timing of the FIFO and the read.
The reason I said that I think EP_READ is on for 16 cycles is that I look at the last data_out from the FIFO after the PipeOut request has been carried out. From the sequence of data you now see that I always get double the number.
Another general question I always has is about clocking and timing.
For PipeOut, once you have EP_READ high, at the next clocking cycle, DATA has to be present. Is it a general practice to have the data (which you fetch from, for example, a FIFO) right at the clock edge or half the cycle before? Because I might think some data corruption might occur if the data is not fully stable at the clock.
I don’t know whether the question is clear? I will try again if you have trouble understanding.
Thank you very much!
With regards to timing, the Xilinx Spartan-6 datasheet has all the details on setup and hold timing for the flip flops as well as propagation delays through LUTs. The FPGA editor can provide you detailed information about routing delays.
Usually, however, clock timing is supplied as a constraint. Assuming the HDL a well-behaved synchronous design, as is the favor in modern FPGA architectures, then the tools generally assure that setup/holds are appropriately satisfied.
So in most FPGA timing diagrams, you’ll see that an input value is ‘sampled’ on the rising edge and outputs need to be stable prior to the rising edge.
Have you looked at our DESTester, PipeTest, and RAMTest samples? These all use pipes and have some memory attached to the pipe. How do these compare to your design?
I see now. This is indeed very useful information. I will see and play around and will ask more if anything comes up.
Thank you very much.
PS: I can only import ok in python 2.6 (mac). Is there a way to do this in python 2.7?
I know now what’s wrong. I didn’t use the same clock for the FIFO and the ti_clk for USB interface. I used the default 100 MHZ from the on-board PLL so that’s why it’s sampling twice the sending to PipeOut. Changing to the right clock solved it.