• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About vr5

  • Rank

Contact Methods

  • Website URL
  1. vr5

    Working on Papilio Nano

    Indeed. However, we have two FPGA designs. The master designs always loads first, and can set those registers so that when the second (user) design loads, it is already set up. Alright. Sounds good! Not sure. I actually think we will not be able to use the method cause PC will always drive DP/DM signals... Well, actually I'd worry about another (almost opposite) thing. In DISCONNECTED state both data lines are weakly pulled to 0 (via 15k resistors) by host. And device/PHY will not see any traffic until hub/host port goes thru CONNECTED to ENABLED state. To go into CONNECTED state device has to pull one of the data lines high. Transition from CONNECTED to ENABLED state can be initiated by host SW by issuing port Reset command. However, Reset command will not do anything if port is in DISCONNECTED state. Ok, so if we, for example, connect SPK_L to Vcc via resistor, then host will try to reset and configure port/device and we will see some level transitions on SPK_x lines after switching PHY to audio mode. PHY/FPGA board will not respond to GetDescriptor command and host will put the port into DISABLED state, so we will not see any USB traffic again. But another port Reset command can be issued , and maybe signals on SPK_R can be used as reset signal for an FPGA/design running in FPGA. However there will be lots of transitions on SPK_x lines - so may be the low-pass RC filter will be needed. There is still one thing to think about - how PC software will discover a port to which Nano board is connected... And there are another things to try/study: - I'm not sure that PC operating system will allow to issue a port Reset command for USB host/hub if that port was transitioned to DISABLED state. - MicEn bit, will it do the same thing as SpkRightEn or "not exactly"?
  2. vr5

    Working on Papilio Nano

    Well, there are several things to consider: - PHY on FPGA board will not go into audio mode by itself, it needs a sequence of register writes from ULPI interface (6.7.2 from USB3340 spec). PC may have access to its own USB PHY registers but not to the ones on FPGA board. And PC can't signal that it wants USB mode change if there's no a controller in an FPGA. - PC access to it's PHY registers, direct USB signals driving - these will be highly PC motherboard/platform dependent. So for me, PHY's audio mode for reset generation does not look like a good solution... I think that we can use Alvie's controller when we need USB communication and reset generation, and also we may develop one more controller (rst) in Verilog/VHDL for the case when FPGA design does not need any USB functionality except resets - this controller may handle USB bus enumeration requests and implement 1 endpoint which will be easy to look up on a PC and will allow us to trigger a reset. So it could be something like this: (Maybe Alvie's controller already can work in exactly this way - I haven't studied all its details yet).
  3. vr5

    Working on Papilio Nano

    Well, if the only connection to the computer is the USB, then we have to have some sort of USB controller in FPGA. For handling reset requests it shouldn't take a lot of FPGA cells. That's for ZPU/wishbone resets. For triggering an FPGA reconfiguration we may need a button anyway. As for SPK_R, can you show me schematics on how you'd like to connect it and maybe you (or Alvie) can describe a sequence of actions for triggering a reset this way? I don't see how we can use this pin just yet... For uploading a configuration and general development, yes - JTAG dongle is pretty normal solution. I see more pro's than contra's in this.
  4. vr5

    Working on Papilio Nano

    Hi Alvie, EHCI is certainly nice thing to have, though probably not for Nano/Mini board and LX9 chip. For big CPUs like OpenRISC or RISC-V with Linux, U-Boot (and other similar software), EHCI is almost a "must have" thing. For smaller boards/designs, compatibility is not so important and any easy way for implementing USB devices or specialized USB hosts would be great. I think, low cost FPGA boards with (High-Speed!) USB PHY will be in high demand. Also nice caseworks for Mini board would help to boost popularity for this board even higher (so Jack's idea with GadgetBox is certainly the step in right direction).
  5. vr5

    Working on Papilio Nano

    Jack, I have some experience with HDL designs related to USB, so if any help is needed just ask me. Also, even if you will decide to go with serial converter chip, I'll still be interested in seeing EDA files with USB3300 PHY chip.