Clocking questions for Serial Input and Output
Cluso99
Posts: 18,069
I am looking at USB timing for Full Speed (12Mbps)...
I anticipate that I can use the video counters to output a serial stream using a counter setup to shift out at 12Mbps - is this correct?
It appears that the SNDSER and RCVSER only work at the full clock rate (60MHz on the DE0 & DE2) - is this correct?
Can the SDRAM hardware run at anything other than the P2 clock frequency (ie can I use a counter to provide the clock)?
Is there any other P2 hardware assist I can use to aid in sending/receiving serial bit streams?
I anticipate that I can use the video counters to output a serial stream using a counter setup to shift out at 12Mbps - is this correct?
It appears that the SNDSER and RCVSER only work at the full clock rate (60MHz on the DE0 & DE2) - is this correct?
Can the SDRAM hardware run at anything other than the P2 clock frequency (ie can I use a counter to provide the clock)?
Is there any other P2 hardware assist I can use to aid in sending/receiving serial bit streams?
Comments
Yes.
No, same restrictions as SNDSER.
That is one of the laments that Chip had about the design, the lack of time to put in a proper SerDes in the P2.
You can transmit single cycle with the SHL PHSB, #1 instruction and you can receive with 2 cycles using GETP WC and RCL D, #1
For USB you need to shift out the bits to two pins at the same time, one inverted, one not inverted. And you should also generate the stuff-bits in real time while you shift the bits out, otherwise the handling of the USB-packets gets complicated.
With 160 MHz this should be not a problem, but FullSpeed with 60MHz is a challenge. I think with the FPGA we are limited to LowSpeed.
Serial output with the Video hardware is possible, it just needs to go thru the DACs.
Andy
Perhaps the VGA would have been a little more complex since I don't think we can read back the registers that output the data.
I don't even mind if I have to add one of those tiny gate packages to perform the inversion. The bit stuffing could be predone in software, particularly if we had a 32 bit sender. We could preset 32 bits and let it run while we prepared the next 32 bits.
For input, as long as we could read the register while the input was being assembled, we could remove the timing constraints of the code.
It's still possible we can shift out in 2 clocks by using one of the pin configurations to invert. However, that does not relieve us of the problem that there is a need to also be doing hub ops. Whenever this occurs, the data sync gets lost.
I would have thought we can still use the VGA like we did on the P1, even tho' there have been some changes to the video.
Of course, I am going to try this with a single cog (I have a DE0). So I won't be doing anything complex with the data, just proving I can read and reply to packets. I was sort of hoping someone may have found a trick/way to use the extra hardware in the P2.
The LOW speed option, means code debug could be done first at that speed.
Ideally, you want a Differential RX, and some ESD, and looking at TI I see :
TUSB1106P 55c/1ku Advanced Universal Serial Bus Transcievers ±15-kV Human-Body Model
they also have
TUSB1210 80c/1k USB 2.0 ULPI Transceiver (ESD is only 2kV)
This also claims
- Complete HS-USB Physical Front-End: Supports High Speed (480 Mbit/s), Full Speed (12 Mbit/s) and Low Speed (1.5 Mbit/s)
– Bit-Stuffing Insertion During Transmit and Removal During Receive
- but it is not clear how the ULPI interface scales with USB speed.
There is an explanation of all the USB line states here: http://www.usbmadesimple.co.uk/ums_3.htm
Yes, I used too few words : USB sends/receives in both directions, (strictly called half-duplex), so any coms design has to be able to do both.
That means there is little merit in having hardware assist for one direction only.
So you have no plans to worry about ESD handing, or differential Rx ?
... any real numbers for the ESD rating of P2 pins yet ?