<d1b2>
<pln> However its not clear to me if the mapping is 1-1, meaning tck - pmod1a pin 7, tms, pmod1a pin 8, etc. or if they are bound in any other way.
<d1b2>
<pln> (As no names are defined in the resource binding.
<d1b2>
<pln> I guess its obvious once you figure out how the amaranth project is stitched together. Its just that I cannot see the obvious here.
<d1b2>
<pln> Also its kind of weird that the debug signals is not tied to the ftdi chip onboard, it should be possible to re-map the bitbanging jtag to use some free gpios connected to the lattice for that purpose. This is not an amaranth thingy by itself but rather a design decision by the author of the MCU (and should be easy to remap). I guess using an extarnal jtag has its advantages too. But at far as I can tell its not really documented in the
<d1b2>
repo.
adamgreig[m] has quit [Quit: You have been kicked for being idle]
pie__ has quit [Ping timeout: 240 seconds]
pie_ has joined #amaranth-lang
<d1b2>
<OmniTechnoMancer> I believe without soldering some jumper resistors there is only a UART Rx/tx connection between the ice40 and ftdi
<d1b2>
<josuah_dem> So starting to top right while looking at the connector on the board: 1, 2, 3, 4, -, -, then on the next row, 7, 8, 9, 10, -, -. With the - representing the pins to skip in the numbering
<d1b2>
<josuah_dem> It is not so obvious without a bit of explanations, I should collect some time to add that to the doc
<d1b2>
<josuah_dem> But indeed, here as you say, it is not obvious from this line how it ends-up being mapped. I would have been using SubSignals with human-readable names, since this is what Amaranth is good at.
<d1b2>
<josuah_dem> I think he does not have a JTAG connection bound to anything by default.
<d1b2>
<josuah_dem> My suggestion would be to adding your own resource, then connecting that to the JTAG instance.
<d1b2>
<josuah_dem> For a quick test, you could add that with platform.request() directly onto jtag.py: that's the advantage of platform.request(), it can be called from anywhere, no need to route all the way down from top.py to your sub-sub-sub-submodule
whitequark has quit [Quit: Bridge terminating on SIGTERM]
pepijndevos[m] has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
Chips4MakersakaS has quit [Quit: Bridge terminating on SIGTERM]
DeVector[m] has quit [Quit: Bridge terminating on SIGTERM]
suwako[m] has quit [Quit: Bridge terminating on SIGTERM]
kivikakk1 has quit [Quit: Bridge terminating on SIGTERM]
xiretza[m] has quit [Quit: Bridge terminating on SIGTERM]
cesar12 has quit [Quit: Bridge terminating on SIGTERM]
kivikakk has quit [Quit: Bridge terminating on SIGTERM]
imlostlmao[m] has quit [Quit: Bridge terminating on SIGTERM]
antoinevg[m] has quit [Quit: Bridge terminating on SIGTERM]
jfng[m] has quit [Quit: Bridge terminating on SIGTERM]
xiretza[m] has joined #amaranth-lang
whitequark has joined #amaranth-lang
pepijndevos[m] has joined #amaranth-lang
mikolajw has joined #amaranth-lang
kivikakk has joined #amaranth-lang
jevinskie[m] has joined #amaranth-lang
cesar has joined #amaranth-lang
suwako[m] has joined #amaranth-lang
kivikakk1 has joined #amaranth-lang
Chips4MakersakaS has joined #amaranth-lang
jfng[m] has joined #amaranth-lang
DeVector[m] has joined #amaranth-lang
antoinevg[m] has joined #amaranth-lang
bl0x has quit [Ping timeout: 240 seconds]
bl0x_ has joined #amaranth-lang
<d1b2>
<pln> Thanks for the deep insights. I got hold of a diligent ftdi and mapped is according to what I thought would be the right pins. To no avail of course. So I contacted the author Mateusz to confirm. And indeed (as you also concluded) the jtag has only been tested in simulation and not tested against hw probes (so some mappings might be missing). We will try to look into it, would be so cool to have that up and working. Let's see.
<d1b2>
<pln> Have you an example of a platform request, and do you think the top level debug resource is correctly defined for the purpose.
<d1b2>
<pln> (then again there might be more things missing, not sure if the physical characteristics, pull/up/down/speed etc. of the pins needs to be configured somewhere.
<d1b2>
<pln> And regarding the jtag, will the probe provide the clk (I hooked up an oscilloscope and tried to probe the clk signal out of the ftdi (JTAG-HS3).
<d1b2>
<pln> I could see no action on the TCK (not sure if that is expected).
<d1b2>
<pln> I tried with the latest openocd in the arch repo.
<d1b2>
<josuah_dem> Oops, sorry for the delay...
<d1b2>
<josuah_dem> The top level "debug" resource seems unrelated to this MCU's JTAG port, you would have to add a new one.
<d1b2>
<josuah_dem> First, the platform definition: in the Pin declaration, you can set here what kind of pin it is: - an input (with only an .i signal, configured in high-z mode), - an output (with only a .o signal, configured in push-pull mode) - an "output enable" (with a .o for the data and an .oe for switching between High-Z and Push-pull, some way to do an open-drain that way)
<d1b2>
<josuah_dem> The conn="xxx" allows you to specify pin numbers relative to one PMOD connector (4,3,2,1 for the top row, 10,9,8,7 for the bottom row) rather than the chip package's pins (to lookup in the board's datasheet, or sometimes printed as board silkscreen).
<d1b2>
<josuah_dem> From that, you could define your own connector layout, maybe something a bit like this: Resource("jtag", 1, Subsignal("tdi", Pins("42", conn=gpio, dir='i')), Subsignal("tdo", Pins("43", conn=gpio, dir='o')), Subsignal("tms", Pins("43", conn=gpio, dir='i')), Subsignal("tck", Pins("43", conn=gpio, dir='i')), Subsignal("rst", NPins("43", conn=gpio, dir='i')), ) (sorry for the big blob, IRC users)
<d1b2>
<josuah_dem> Note the presence of NPins(), which is the same as Pin, but inverted, so that the signal you use in the RTL are always active high, so that you do not have to remember between active-low or active high
<d1b2>
<josuah_dem> Then, after jtag = platform.request("jtag", 1), you would have access to all your JTAG pins, such as m.d.comb += jtag.tdi.o.eq(tdo)
<d1b2>
<josuah_dem> Note that I do not know how JTAG works in depth, so the directions might be wrong above.
<d1b2>
<josuah_dem> I also picked pin 43 and conn=gpio which might not be right in your case
<josuah>
You might encounter a lot of types in Amaranth, which are often wrappers around the very few *core types*
<josuah>
once the core types are understood, adding more types yourself, or using those from the various libraries helps making things much less verbose and readable to the experienced eye
<josuah>
there is a bit of a steep initial learning curve, but once the principles are acquired, progress goes really really linear in my experience
<whitequark>
ideally we'd have a flatter learning curve and fewer of the inessential types
<whitequark>
the resource system is a particularly bad offender
<josuah>
I like the principle, but maybe you had an idea to reduce that further?
<whitequark>
there are a few issues with it, a notable one is that the .request() method does both too much (it's so complicated) and not enough (it doesn't let the PHY to request the right data rate multiplier for example, the toplevel has to do it which is awkward)
<whitequark>
i now have a better understanding of the domain and could implement a far better design
<josuah>
I would welcome this change that seems easier for developers and maintainers, although I wonder about existing code
<whitequark>
there's a way to do this in a backwards compatible way, of course
<josuah>
since it is all python, it is not too difficult to offer new wrapper types that progressively replace the old ones, and keep the old ones for a while
<josuah>
ah, there is compat for that: breaking users's code but allowing a 1-line diff that can be automated for the whole source
<whitequark>
yeah
<d1b2>
<pln> Thanks again for the elaborate information.
<d1b2>
<pln> I'll look further into it tomorrow. I guess I'll start by looking how the LEDs are abstracted that might be a good starting point.