<cr1901_modern>
Can it do full speed (more than sufficient for my potential use case and doesn't require me to interface to a pesky PHY)?
<mtrbot-ml_>
[mattermost] <sb10q> ULPI doesn't have "special features" afaik
<mtrbot-ml_>
[mattermost] <sb10q> There's a soft full-speed phy in milkymist soc if you need one
<Dar1us>
sb0: BTW USB transfer latency is impacted by how the USB host controller is programmed (based on an email from the FreeBSD USB stack maintainer)
<key2>
i could add fs by rewriting the phy
<cr1901_modern>
key2: I have to leave for a bit, but since you're here... I know ULPI PHYs handle FS, but the idea was I wanted to opt out of HS support and just have FS, so the PHY can be implemented purely digitally on 3.3V I/O pins.
<cr1901_modern>
(Well until azonenberg adapts his Ethernet PHYs using resistors to USB.
<key2>
yea it’s possible
<key2>
and thought this way
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
harryho has quit [Remote host closed the connection]
_whitelogger has joined #m-labs
<whitequark>
sb0: isochronous endpoints drop packets on overflow
<whitequark>
that'sthe whole point
<whitequark>
so that is not any better than dropping packets inside the FPGA
<ZirconiumX>
wq: So, the MiSTer I/O board goes over the top of the DE10-Nano, making things like switches impossible to reach. As a practical matter, do I still put them in resources?
<whitequark>
do you want to add mister as a subclass of de10-nano or as a completely new board?
<ZirconiumX>
I thought we agreed on subclass
<_whitenotifier>
[m-labs/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0] https://git.io/JelvI
<_whitenotifier>
[m-labs/nmigen-boards] whitequark d07839a - de0cv→de0_cv, for consistency with de10_nano
<whitequark>
then you would add more resources, never remove any, no?
<ZirconiumX>
Hmm, okay
* ZirconiumX
is installing EAGLE just to read the schematics of the I/O and SDRAM boards
<whitequark>
do they not have PDFs?
<ZirconiumX>
Nope
<ZirconiumX>
I'm not even sure if it *is* EAGLE actually
<_whitenotifier>
[m-labs/nmigen-boards] whitequark pushed 1 commit to master [+1/-1/±0] https://git.io/Jelvj
<_whitenotifier>
[m-labs/nmigen-boards] whitequark dcf7c47 - de0cv→de0_cv, for consistency with de10_nano
<ZirconiumX>
wq: I feel like converting from the GPIO connector pins back to the FPGA pin is going to be error prone
<whitequark>
is it described in terms of FPGA connector pins?
<whitequark>
i mean, you could just add MiSTer as a new board entirely
<whitequark>
if thats easier
<whitequark>
there's no real policy
<ZirconiumX>
It's described in terms of GPIO connector pins
<ZirconiumX>
So I have to look at what the FPGA pin connected to that GPIO pin is and enter that as the given pin location
<ZirconiumX>
Unless I'm being an idiot
<ZirconiumX>
What I'm looking for is, I dunno, self.connectors["j0"][4] or whatever
<whitequark>
sure? you can use that?
<whitequark>
instead of eg AA10 specify j_0:4
<ZirconiumX>
But connectors is a list, right?
<whitequark>
in the resource Pins()
<ZirconiumX>
Ah, I see, thank you
<cr1901_modern>
Re: adding as a new board, I think most accurately MiSTer is an add-on that is by design only usable with a single DE0-variant board?
<ZirconiumX>
Yeah
<ZirconiumX>
Bikeshedding: the I/O Board has three LEDs with intended purposes; one for board power, one for disk access, and another as general user access
<ZirconiumX>
Is this special enough to give names? Would that be three Resources, or one Resource with three subsignals?
<whitequark>
you can have both
<whitequark>
Resource("led", 0)
<whitequark>
Resource("led_disk", 0)
<ZirconiumX>
Do resources with the same name get appended?
<whitequark>
nope, they're just independent
<whitequark>
you can only request one at a time
<_whitenotifier>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JelUL
<_whitenotifier>
[m-labs/nmigen] whitequark a7cc88f - vendor: yosys is a required tool for all Verilog-based flows.
<whitequark>
the LEDs should be separate resources
<whitequark>
other than that looks fine
<whitequark>
feel free to fix stylistic issues, or not
<Dar1us>
ZirconiumX: nice work BTW
<cr1901_modern>
Potential non verilog arcade ports in the future
<ZirconiumX>
For that I'll wait for you to add conn as a kwarg for SDRAMResource (at least)
<ZirconiumX>
cr1901_modern: We can dream :P
<whitequark>
no I mean, didn't you want to avoid using indirection through the connector at all?
<ZirconiumX>
No?
<whitequark>
ah
<ZirconiumX>
I actually prefer using the connector
<whitequark>
ok
<whitequark>
I misunderstood
<whitequark>
feel free to add conn to SDRAMResource, SDCardResource, etc in a separate PR
<ZirconiumX>
wq: I'm partly considering deprecating/removing DE10NanoPlatform for MisterPlatform, because you can use a subset of MisterPlatform for the same functionality as DE10NanoPlatform
<whitequark>
uhh, I don't like that at all
<ZirconiumX>
<whitequark> the LEDs should be separate resources <--- but the switches are OK?
<whitequark>
switches too
<whitequark>
they're all separate resources in nmigen