The issue is that the FS mode is negotiated during attach/port reset event. Any HS device signals the connect event by pulling up D+ data line just as a FS device would do. The host, seeing the connect, initiates "USB_RESET" state, dragging both D+ and D- to ground with 45-Ohm driver. Then, if a device is HS, it pulls "Chirp-K" signal on D- wire. A HS device must always do this, you can't avoid this signal phase.
The host does recognize the Chirp-K, and after a special chirping sequence, both Host ans Device recognize the HS mode. You can find more details HERE.
The problem in your case is that suppressing signal quality at HS mode doesn't remove the chirping sequencing. Since the chirping comes at much lower switching rate (~ 10MHz), you can't suppress it without harming the FS data signaling mode. That's why a simple impeding of HS data rate doesn't work.
There are three options to validate a HS device ability to run on FS mode:
- Have a USB 1.1 hub, as suggested by duskwuff;
- Get a USB host that supports only USB 1.1 (Arduino flavours, Cypress, whatever)
- Get a normal (older) PC that is built around Intel EHCI controller, and disable the EHCI part of it in Device Manager. The remaining UHCI controller (or OHCI in AMD line) will provide the FS functionality.
CORRECTION: The chirp sequence J-K-J-K-... is specified to have pulses between 40us and 60us, see Section 7.1.7.5. of USB 2.0 specifications. All designs have it in the center, 50 us. Which makes the chipring frequency at 10 kHz, not 10 MHz, my bad. This frequency disparity makes it impossible to suppress chirps by filtering given the FS signaling rate is 6 MHz.
Best Answer
In general, no. There really is no such thing as a low-speed-only host port; it would violate the USB standard.
But even if such a thing did exist, the USB protocol does not support having a host negotiate a device down from full speed to low speed.