TI_CLK and HI_CLK are really the same. They come from the Cypress USB >device which uses the on-board 24 MHz crystal to generate the 48 MHz >signal for the host interface. At the moment, they are tied together (within >the host interface HDL module), but we wanted to leave open the option to >disjoin them. Generally you should use TI_CLK since that’s the “target >interface” clock. HI_CLK is “reserved” for the host interface, but again, >they’re the same right now.
At one point I got unstable readings when I clock by circuit (fully synchronized, single clock) on hi_clk and it was solved when I switched to ti_clk. I tried to reproduce it now but could not. Maybe the flow add some buffer between them (??). Anyway, we are using ti_clk now and I believe this is safer.
You may want to use a DCM if your application will use them a fair bit. The >DCM will help minimize on-chip clock skew to the board-level signal.
Thanks for the pointer. Currently all of our I/O is asyncrhonous so the clock is used only within the chip.
To answer your questions:
- For pipes, use ti_clk. For triggers, you provide any clock you want. For >wires, there is no clock since these are officially asynchronous signals. To >synchronize data with them, you should do something like:
xem->UpdateWireIns(); // Setup the wire in values
xem->ActivateTriggerIn(xxx, xxx); // Latch the wire ins.
For wire signals, this accomplishes the same thing with very little >performance penalty. The reliability factor is typically worth the penalty.
I am clocking my design on ti_clk so I presume it is safer to assume that wire in/out are synchronous on the positive edge of ti_clk, right? (that is, no need to latch with a triger in).
- Generally, the TI_CLK will only disappear if the device (USB micro) is >placed in suspend mode by the host. If you’re having trouble with this >occurring, please contact us (email@example.com) and we can try to >figure out why this is happening.
I am not sure what can cause the host to put the device in ‘suspend mode’. I am using a Ubuntu based Linux server. Hopefully it does not do that. I noticed it when I disconect the USB cable.
Since there is such advantage of using the ti_clk for user designs (everything is synchronous on the same clock), you may want to consider having the ti_clk running continiously. This can also be the first choice of user clock unless the user must have a differnt clock.
It is derived from the 24 MHz crystal by the USB microcontroller.
The crystal is +/- 100ppm. output from the USB micro should be 45% to >55% duty cycle but you’ll typically see 50% pretty steady.
Thanks, 100ppm should be good enough for us.
- Not really. But, if your design really is time sensitive (how time sensitive?), >we would advise supplying a clock that meets your guidelines. The clock >system on the XEM devices are good for digital systems, but they are not >tightly constrained.
We are using a very accurate 1PPS (pulse per second) time base so we can only about the monotonicity of the XEM3010 over a period of 1 sec (we compensate out basic inaccuracy of long time drift) so I think we should be
ok with the current ti_clk.
If you have constraints to meet with your clock, I would recommend >supplying it externally. From your previous posts, it does not sound as >though your design needs to transfer data to the PC very quickly. Is there a >reason that the wire/trigger combination will not work for your application?
It should work (though we don’t need it since we are clocking on ti_clk). However, you can write once a cross clock domain synchronous wire in/out and your users will reuse it many times (avoiding the extra trigger update, extra buffer in the FPGA, etc). Kind of work for you and simplicity for us
Also, users typically prefer to use pipes to transfer data to/from FIFOs in a >synchronous manner. Is this what you’re doing?
I followed your advice and Coregen’ed a FIFO (single clock, 32K * 16bit, with data count output). It seems to work very well and the board and the computer talks very efficently. 32K*16 was the max I could fit into the FPGA, probably we will need to make things a little bit more complicated and implement an SDRAM based FIFO for larger depth. We will base it on your SDRAM controller module unless you already have a design for a SDRAM based FIFO with count output (hint, hint ;-))
We currently have a working prototype that covers all the risky elements of the design (other than the SDRAM based FIFO). Overall the development was a pleasure and we enjoyed working with your HDL and host side abstractions of the USB communication. Next step is to get it to production quality.
Thanks for your help,