-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB example, submodules.car, and no direct platform support #281
Comments
One thing to note is that the connection noise on Windows can be a little misleading, all it takes is detecting a pull-up on one of the data lines to generate that noise & an entry in device manager. It doesn't necessarily mean that any actual communication is taking place. Since it fails in the descriptors, there probably isn't any communication happening. Disabling the clock-and-reset (car) submodule is a problem, because that generates all the required clocks for everything to work. Unless you're creating those clocks yourself in some other code outside of what you've posted, the USB gateware won't be running. You can see an example of the implementation for ECP5 here: luna/luna/gateware/architecture/car.py Lines 192 to 380 in be05684
Usually the way to support a new board is to create a platform class that defines details of the FPGA, how to setup the clocks, and all the relevant resources/pins available. Some examples are here: https://github.com/greatscottgadgets/cynthion/tree/main/cynthion/python/src/gateware/platform and here: https://github.com/greatscottgadgets/luna-boards/tree/main/luna_boards |
Dear @miek, thanks for responding--appreciate it! From what I can tell, the working example verilog (generated by Luna), is based on acm_serial.py. I cannot find any references in the verilog to clocks other than the ulpi_clk (60hz). Neither do I find a reference to "car" anywhere. See screenshot, my generation of acm_serial.py is a carbon copy of the working example verilog (except for some dynamic naming changes). I copy the working project and only overwrite my version of the verilog from acm_serial.py. Even the modules hierarchy is exactly the same! Despite that, it just does not work... |
As well as the One other thing is that you may be hitting #280, so it's worth trying an older version before that issue was introduced. |
Dear Mike (@miek), thanks for responding. It was quite frustrating, but once or twice I had the device actually enumerate as 'Test Device' (basically based on the usb example). (IThe problem cannot be with the actual fpga or usb3317 chip, one would assume, because the pre-generated Gowin verilog example I mentioned earlier enumerates consistently; what does not work is my code). Going back to an earlier commit (the one to which you alluded), did not really help in this case. Interestingly, coming back to your point on the ulpi and usb clocks. Obviously I can feed in a 120 MHz clock. However, I think it was in the usb translator module, there is an assign usb_clk = ulpi_clock. Hence, that creates two interesting problems. First of all, I cannot drive the usb_clk in the top module via a 120mhz_clk_input. Moreover, the ulpi clock is 60hz. On a final note, per your advice I looked at the luna boards and I made my own board file. I played around with a variety of board examples, but this one I find the most noteworthy: https://github.com/greatscottgadgets/luna-boards/blob/main/luna_boards/openvizsla.py
It's clock domain generator is quite simple (no special instance being used, no plls being called, and so forth). If that is all it takes...one would assume I could easily replicate it and make my code finally work. (Alas it did not though). |
Tang primer 20k has a working example of the usb3317 being used (https://github.com/sipeed/TangPrimer-20K-example/tree/main/USB).
This example has been generated via https://luna.readthedocs.io/en/latest/. Unfortunately the author did not include the original .py files that generated the verilog.
I have been trying to reconstruct for two weeks what the original file might have been, but no luck (since I do not want a serial device but a simple custom device for bulk transfers).
I generated a file that fails at the descriptor stage as far as I can tell from Windows (although the connection sound does play. In other words, the device does appear in the device manager.
I suspect there might be an issue with my customization (i.e., disabling submodules.car and platform.request and using a Record instead):
The .car submodule seems to be addressed(?) in the Gowin project as follows (I assume):
What am I overlooking here? Did I do something counter to the Luna framework?
The text was updated successfully, but these errors were encountered: