With the existing modes you can not do it with 2 smartpins.
For sure with a dedicated USB mode it needs only 2 pins
dedicated USB mode can mean many things,
I'm not sure it needs a full USB macrocell, but I think it does need USB_Tx and USB_Rx control flags.
These enable the very small support logic around USB specific bit level tasks.
A NCO should be able to generate the bitclock for USB with a little tweak. The NCO Frequency mode must get a variant that allows to reset the phase register on edges of input A or B. There are 16 bits in X left to configure such a mode.
The nice thing is that USB will work with every crystal/sysclock frequency maybe even with the internal oscillator because the bitclock gets synchronized on every edge in the USB datastream.
Agreed, NCO can (re)lock, if a USB_Edge sense is added to reset phase.
A re-lock NCO is also useful for doing Fractional Baud, & Chip is already thinking about this.
(on UART, NCO relocks on Start-bit)
...
If there is no dedicated USB smartmode, a second synchronized NCO with 1/6 the frequency can be used to detect a stuffbit (the green part in the diagram).
I'm not sure a full 32b NCO mode is the best for Stuff/Destuff, plus it would need dynamic Tx or Rx reconfig.
That's a lot of registers, and Stuff only needs to count to 6, ie 3 FF + 1 result FF & some state gates.
I think that is small enough it can be hard wired, simply using the 2 USB Config bits to enable as Rx or Tx Stuff.
I find this useful to read. It describes a lowspeed implementation but full speed is the same, only with 12MHz bitrate. Many low level details can be extracted from that description.
At the end of the page there is also a link to "USB in a nutshell" which describes the packet layer quite understandable.
I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.
I think I need to get a USB analyzer to see what is really going on, or needs to go on. I'm sure it isn't complex to do full-speed and low-speed USB hardware (low-level communication), but man, is this UGLY! You plug in a USB device and it wants to have a lengthy conversation about the weather and how it's feeling today, with the host needing a set of encyclopedias for reference. What a nightmare of a protocol.
I'm going to look for some analyzer that will let me see (hopefully) what happens in USB.
Two pins should be able to handle it, especially if odd and even pins had different USB smarts.
That's a good idea, would reduce my 2 config flags to a single USB_Helpers one.
There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy.
Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.
Using this USB Analyzer you may capture and display any traffic passing over USB connections of your computer. Captured communication data raw binary format is parsed and decoded into a human-readable form, allowing you to review the exchanged data and perform effective forensic analysis of transmitted data packets.
The key feature of this Freeware USB logic analyzer is its ability to process monitored packets in real-time even under high traffic load. Together with other powerful features of this Free USB explorer and analyser utility it makes you able to explore and trace USB requests of all modern devices and applications, which are compatible with Hi-Speed USB 2.0 480 Mbit/s and SuperSpeed USB 3.0 5 Gbit/s dataflow.
Two pins should be able to handle it, especially if odd and even pins had different USB smarts.
That's a good idea, would reduce my 2 config flags to a single USB_Helpers one.
There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy.
Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.
Using this USB Analyzer you may capture and display any traffic passing over USB connections of your computer. Captured communication data raw binary format is parsed and decoded into a human-readable form, allowing you to review the exchanged data and perform effective forensic analysis of transmitted data packets.
The key feature of this Freeware USB logic analyzer is its ability to process monitored packets in real-time even under high traffic load. Together with other powerful features of this Free USB explorer and analyser utility it makes you able to explore and trace USB requests of all modern devices and applications, which are compatible with Hi-Speed USB 2.0 480 Mbit/s and SuperSpeed USB 3.0 5 Gbit/s dataflow.
It looks like that monitors packet flow, which is too high level for what we need. I think we need something that monitors the wire-level activity, so we can see what is actually happening, signal-wise. Thanks, though. That may come in handy later.
Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.
Sounds good.
The P2 can also use the cross-pin feature to sniff onto the USB pins, and do a HW logic Analyzer which could correlate with that SW layer capture.
Getting 'example traffic' over a USB-UART/FIFO for example, is there on (all?) P2 boards, and the USB Rx code can work up to phantom RX only (where it listens, toggles pins on 1ms Frame info, and stores Rx info, but does no USB replies) - that allows test of CRC and Packet-decode etc.
Once USB Rx is aligned, USB Tx should be easier to code as the Rx Verilog is there as a reference.
Yes actually I think the streaming feature of the P2 might be as good as anything for capturing bit level info
I just scoped the usb data signals on a prop plug. Even when serial transmission is idle, its sending the same (heartbeat?) pulse over and over, about 1750 ns wide. Probably could do with a proper USB PHY chip, but its encouraging enough to be able to see the signals
I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.
I think I need to get a USB analyzer to see what is really going on, or needs to go on. I'm sure it isn't complex to do full-speed and low-speed USB hardware (low-level communication), but man, is this UGLY! You plug in a USB device and it wants to have a lengthy conversation about the weather and how it's feeling today, with the host needing a set of encyclopedias for reference. What a nightmare of a protocol.
I'm going to look for some analyzer that will let me see (hopefully) what happens in USB.
An USB packet is a stream of 64 bytes (in fullspeed) with a sync pattern at begin and a EOP signal at the end (2 bittimes low on both lines). There are no start and stopbits or pauses, just a continuous bitstream.
This 11+5 bits for example in the descriptions only show what is encoded in the bits.
It's okay if the USB receiver signals every byte on INx, and the cog does all the rest.
I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.
Payloads are 8 bit bytes, but a couple of headers are <> 8b per sub entity (eg 11+5 and 7+4+5, but fortunately those do add to 16b, so a Host emulation can send packed as 2 bytes, and a receive can input 2 bytes, then split in sw)
BitStuff further varies the actual bits used, but that is inserted/removed pretty much at the pins, so does not impact the data payloads. It will of course appear on any Logic Probe.
I'm still not convinced of the necessity to have USB support. Many use cases for the P2 will have no USB. Of those use cases that do have USB, I think the overwhelming majority (all?) will have exactly one bus implemented. That's two pins. Maybe two pin cells. With that in mind, it does not make sense to me to implement any more than the basic state detection, edge aligned NCOs, and NRZI output. Those are reasonably general-purpose features that can be used well beyond USB.
But not CRC-5-USB. Not bit stuffing. Those have too little (no?) application beyond USB. Leave that to software. No need to clutter up 63 other pin cells just so you can have it available for one cell.
Yes actually I think the streaming feature of the P2 might be as good as anything for capturing bit level info
I just scoped the usb data signals on a prop plug. Even when serial transmission is idle, its sending the same (heartbeat?) pulse over and over, about 1750 ns wide. Probably could do with a proper USB PHY chip, but its encouraging enough to be able to see the signals
At a Sync-clk of 40MHz, 5000 bytes can capture a full 1ms Frame with 3 1/3 samples per USB bit.
That should be enough to decode, or 80MHz could get 10k Bytes of samples at 6 2/3 samples per bit.
A few SW passes would remove bit stuff, and DPLL to extract actual data information.
With low average data rates, that information could be sent to the PC over a serial link.
Capture of USB pin pair to extract J.K.SE0 would be nice, but I think the capture modes may not be there, and the Pin-Cell bandwidth is (just) too low ?
jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
This'd also be useful for a general logic analyzer
jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
This'd also be useful for a general logic analyzer
I realize that, I was just looking for more compact forms.
Can the streamer currently capture 4b or 2b wide ?
I guess even BYTE wide is useful, as 6 pins can be usefully used as Hardware feedback from USB testing.
I also like the idea of a time-stamp based Logic Analyzer, but I think the limiting detail on that, is COG-Pin bandwidth ?
jmg, we can use the streamer to bring up to 32 pins at 80MHz to hub ram, continuously, then analyze from there
This'd also be useful for a general logic analyzer
I realize that, I was just looking for more compact forms.
Can the streamer currently capture 4b or 2b wide ?
It goes down to 8 bits, but I've been meaning to expand it to 4, 2, and 1.
re:Bob, I wonder if that kind of transaction record would be sufficient to reverse engineer the packet-level protocol that FTDI drivers execute.
The free version has some limitations but certainly we can learn a few tricks by playing with it. The price is right
IS there something specific you would like for me to try?
Nothing specific. We're going to need verification that the lowest-level signaling is correct. I think we'll need a hardware analyzer to see that. I found one for $400 that looks pretty decent. It shows all non-transactional signalling, which is below the radar of a software analyzer.
Even more than I wish I knew this stuff, I wish I wanted to know about it. I hate overwrought things, so I've avoided USB all these years. Not good business thinking, I know.
I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess. Trouble is, you've got to be neck deep before you can climb out.
Here's a few Video's for anyone interested in seeing the analyzer in action.
(Both videos refer to using a Beagle 480 analyzer - they also apply to the Beagle 12 analyzer because the Data Center software is used for both devices)
USB Debugging using a Real-Time USB Bus Monitor
Using the Bus Tree Feature of the Data Center Software for USB Debugging and Analysis
Two pins should be able to handle it, especially if odd and even pins had different USB smarts.
Something I've always wanted to see, but have never found anywhere, is a diagram of USB protocol from the wire level up. If there was something definitive to look at, this could be easy. Diving deep into the huge USB specification to try to construct such information by making lots of inferences has put me off. If I wanted someone to know how something worked, I would explain it in very direct terms. For whatever reason, these protocol standards are never written like that.
Chip,
LS and FS effectively reverses the functions of the pin pairs. But I guess we could swap the pin pair using the smart pins, so its not really an issue here.
I did a lot of work a long time ago in understanding to bottom level protocol. It is not that bad although the crc16 could do with some help. Before smart pins I had worked out how a couple of instructions would help make software life much easier. I posted the info a couple of years ago. Note I think there is an error in the way I worked the instructions out.
Comments
As Ariba pointed out, an NCO (16-bit) would be quite sufficient to get us the timing we'd need.
I'm not sure it needs a full USB macrocell, but I think it does need USB_Tx and USB_Rx control flags.
These enable the very small support logic around USB specific bit level tasks.
Agreed, NCO can (re)lock, if a USB_Edge sense is added to reset phase.
A re-lock NCO is also useful for doing Fractional Baud, & Chip is already thinking about this.
(on UART, NCO relocks on Start-bit)
I'm not sure a full 32b NCO mode is the best for Stuff/Destuff, plus it would need dynamic Tx or Rx reconfig.
That's a lot of registers, and Stuff only needs to count to 6, ie 3 FF + 1 result FF & some state gates.
I think that is small enough it can be hard wired, simply using the 2 USB Config bits to enable as Rx or Tx Stuff.
http://www.slideshare.net/franciscokelvin/usb-24403356
At the end of the page there is also a link to "USB in a nutshell" which describes the packet layer quite understandable.
Andy
Thanks! I looked through that and a few others.
I understand the bit stuffing and NRZ, but I'm not getting the bigger picture, yet. It looks like odd numbers of bits make up various packets. It would have been a lot cleaner to standardize at 8 bits per word. I still need to understand what kinds of responses come when.
I think I need to get a USB analyzer to see what is really going on, or needs to go on. I'm sure it isn't complex to do full-speed and low-speed USB hardware (low-level communication), but man, is this UGLY! You plug in a USB device and it wants to have a lengthy conversation about the weather and how it's feeling today, with the host needing a set of encyclopedias for reference. What a nightmare of a protocol.
I'm going to look for some analyzer that will let me see (hopefully) what happens in USB.
There will likely be some cross-handshakes between Cells, so odd/even pairs helps with that and keeps logic smaller still.
I've found this reasonable
http://www.usbmadesimple.co.uk/ums_3.htm
but not quite wire-level up you are after.
re:I think I need to get a USB analyzer
http://freeusbanalyzer.com/
Free USB Analyzer is a non-intrusive software USB sniffer and protocol analyzer for Windows.
Using this USB Analyzer you may capture and display any traffic passing over USB connections of your computer. Captured communication data raw binary format is parsed and decoded into a human-readable form, allowing you to review the exchanged data and perform effective forensic analysis of transmitted data packets.
The key feature of this Freeware USB logic analyzer is its ability to process monitored packets in real-time even under high traffic load. Together with other powerful features of this Free USB explorer and analyser utility it makes you able to explore and trace USB requests of all modern devices and applications, which are compatible with Hi-Speed USB 2.0 480 Mbit/s and SuperSpeed USB 3.0 5 Gbit/s dataflow.
That has some good info. Thanks.
It looks like that monitors packet flow, which is too high level for what we need. I think we need something that monitors the wire-level activity, so we can see what is actually happening, signal-wise. Thanks, though. That may come in handy later.
Sounds good.
The P2 can also use the cross-pin feature to sniff onto the USB pins, and do a HW logic Analyzer which could correlate with that SW layer capture.
Getting 'example traffic' over a USB-UART/FIFO for example, is there on (all?) P2 boards, and the USB Rx code can work up to phantom RX only (where it listens, toggles pins on 1ms Frame info, and stores Rx info, but does no USB replies) - that allows test of CRC and Packet-decode etc.
Once USB Rx is aligned, USB Tx should be easier to code as the Rx Verilog is there as a reference.
I just scoped the usb data signals on a prop plug. Even when serial transmission is idle, its sending the same (heartbeat?) pulse over and over, about 1750 ns wide. Probably could do with a proper USB PHY chip, but its encouraging enough to be able to see the signals
An USB packet is a stream of 64 bytes (in fullspeed) with a sync pattern at begin and a EOP signal at the end (2 bittimes low on both lines). There are no start and stopbits or pauses, just a continuous bitstream.
This 11+5 bits for example in the descriptions only show what is encoded in the bits.
It's okay if the USB receiver signals every byte on INx, and the cog does all the rest.
Andy
Payloads are 8 bit bytes, but a couple of headers are <> 8b per sub entity (eg 11+5 and 7+4+5, but fortunately those do add to 16b, so a Host emulation can send packed as 2 bytes, and a receive can input 2 bytes, then split in sw)
BitStuff further varies the actual bits used, but that is inserted/removed pretty much at the pins, so does not impact the data payloads. It will of course appear on any Logic Probe.
But not CRC-5-USB. Not bit stuffing. Those have too little (no?) application beyond USB. Leave that to software. No need to clutter up 63 other pin cells just so you can have it available for one cell.
That should be enough to decode, or 80MHz could get 10k Bytes of samples at 6 2/3 samples per bit.
A few SW passes would remove bit stuff, and DPLL to extract actual data information.
With low average data rates, that information could be sent to the PC over a serial link.
Capture of USB pin pair to extract J.K.SE0 would be nice, but I think the capture modes may not be there, and the Pin-Cell bandwidth is (just) too low ?
This'd also be useful for a general logic analyzer
Can the streamer currently capture 4b or 2b wide ?
I guess even BYTE wide is useful, as 6 pins can be usefully used as Hardware feedback from USB testing.
I also like the idea of a time-stamp based Logic Analyzer, but I think the limiting detail on that, is COG-Pin bandwidth ?
It goes down to 8 bits, but I've been meaning to expand it to 4, 2, and 1.
The free version has some limitations but certainly we can learn a few tricks by playing with it. The price is right
IS there something specific you would like for me to try?
: Control Transfer (
Nothing specific. We're going to need verification that the lowest-level signaling is correct. I think we'll need a hardware analyzer to see that. I found one for $400 that looks pretty decent. It shows all non-transactional signalling, which is below the radar of a software analyzer.
Even more than I wish I knew this stuff, I wish I wanted to know about it. I hate overwrought things, so I've avoided USB all these years. Not good business thinking, I know.
I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess. Trouble is, you've got to be neck deep before you can climb out.
re:It shows all non-transactional signalling, which is below the radar of a software analyzer.
Cool!
Can you please post the link when you pick one so we can see all the features.
re:I really look forward to getting the Prop2 standing on its own, so we could decouple from the modern mess.
That's too bad because you already know that doing proper USB on PROP2 is impossible LOL
Why is it impossible? If we can signal in a timely fashion, and software handles the higher level, where would the imperfection be?
Here is what looks best, so far (see USB 12 model):
http://www.totalphase.com/products/usbguide/?gclid=CL_Kqu_-gssCFQUIaQodk3YDfw
A Prop1 Cog can already do that quite well but limited by Hub access timing. A Prop2 Cog will be able to make use of WFLONG to excellent effect.
re: Why is it impossible?
Just a little humor
re:USB 12 model
Thanks!
Here's a few Video's for anyone interested in seeing the analyzer in action.
(Both videos refer to using a Beagle 480 analyzer - they also apply to the Beagle 12 analyzer because the Data Center software is used for both devices)
USB Debugging using a Real-Time USB Bus Monitor
Using the Bus Tree Feature of the Data Center Software for USB Debugging and Analysis
LS and FS effectively reverses the functions of the pin pairs. But I guess we could swap the pin pair using the smart pins, so its not really an issue here.
I did a lot of work a long time ago in understanding to bottom level protocol. It is not that bad although the crc16 could do with some help. Before smart pins I had worked out how a couple of instructions would help make software life much easier. I posted the info a couple of years ago. Note I think there is an error in the way I worked the instructions out.