<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b307e3e - Deploying to main from @ amaranth-lang/amaranth-soc@f5d44534ed729cc1f7419fffef4da679c4b84c56 🚀
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 14c4204 - Deploying to main from @ amaranth-lang/amaranth-stdio@f43669d04bb5d5f8c1092ba68087226ec05277ae 🚀
_DuBPiRaTe_ has quit [Remote host closed the connection]
_DuBPiRaTe_ has joined #amaranth-lang
E_Bomb has joined #amaranth-lang
_DuBPiRaTe_ has quit [Read error: Connection reset by peer]
d_olex has quit [Remote host closed the connection]
d_olex has joined #amaranth-lang
d_olex has quit [Max SendQ exceeded]
d_olex has joined #amaranth-lang
<_whitenotifier-9>
[yosys] whitequark closed issue #32: Please add examples on how to use this module yowasp openfpgaloader - https://github.com/YoWASP/yosys/issues/32
<jfng[m]>
- remove differences between resource and window names which have been a thorn in our side for a long time (i introduced them a few years ago, without thinking it through)
<whitequark[cis]>
I think the only contentious point in the above is regarding the ordering of strings and integers, but I think people may well come up with unusual uses for this functionality and we should watch how it's used before adding restrictions
<jfng[m]>
re: `__repr__`, my concern is that resource paths are currently just tuples of names, and their repr would then be `(MemoryMap.Name(....), MemoryMap.Name(...), ...)`, which would be quite unreadable
<tpw_rules>
so for each item in the resource tuple, that represents one particular MemoryMap?
<whitequark[cis]>
I suspect that window names will be treated differently than resource names, eg ('video_core', 0, 'lut') may be mapped to video_core.lut[0] with a stride by the SVD builder, but ('axi', 0) will be just axi[0]
<whitequark[cis]>
jfng[m]: that doesn't seem unreadable o me
<jfng[m]>
re: empty tuples, this would be an alternative to the current proposal, where window names are optional and default to `None`
<whitequark[cis]>
just going by the examples, (MemoryMap.Name('uart', 0), MemoryMap.Name('rx', 'config')) isn't bad at all
<whitequark[cis]>
and I find the nested tuples actually a fair bit confusing
<tpw_rules>
can we just call it Name?
<jfng[m]>
re: ordering, this works if a BSP generator is capable of recognizing specific resource types. this should be as simple as a call to `isinstance()`, i guess
<tpw_rules>
(in the __repr__)
<whitequark[cis]>
re: empty tuples, I see what you mean now, I guess the two alternatives are "non-empty tuple or None" or "empty or non-empty tuple" and in the first alternative, constructing an empty MemoryMap.Name() is forbidden
<whitequark[cis]>
tpw_rules: yeah, the rules for `__repr__` do allow that
<whitequark[cis]>
I'm fine with it
<jfng[m]>
tpw_rules: each item except the last item in a resource path represents a `MemoryMap`, indeed
<whitequark[cis]>
hm, so for transparent memory maps, ideally they would not be visible in the resource path at all
<whitequark[cis]>
so I think I prefer the non-empty-tuple-only and no path element corresponding to transparent maps
<whitequark[cis]>
which I think might actually be what's being proposed in the RFC? it's unclear
<whitequark[cis]>
it looks like the RFC doesn't explicitly call out transparent windows
<tpw_rules>
is there a reason to consider joining all the names in a path together? that's how it was before iirc
<whitequark[cis]>
tpw_rules: this will make them unusable
<tpw_rules>
i guess suppose in amaranth you have a MemoryMap object and a name like ('video_core', 0, 'lut'), how would you access it
<jfng[m]>
whitequark[cis]: yes, it is not explicitly specified because transparent windows aren't affected by the RFC
<whitequark[cis]>
the BSP generator must know the distinction between window names and resource names
<whitequark[cis]>
having a window called "uart" with a resource "rx",0 in it is not the same as having a resource "uart","rx",0
<jfng[m]>
i prefer `None` instead of empty tuples: when a transparent window is added to a memory map, the two namespaces are merged together, so names that were local to the window may collide with names in the parent memory map
<whitequark[cis]>
and you shouldn't put too much weight on "how it was before" because I never seriously considered how to write a BSP generator for the original design I came up with
<tpw_rules>
so you know if it's a resource name because it's the last element in the path?
<whitequark[cis]>
jfng[m]: yes, this sounds good to me
<jfng[m]>
jfng[m]: and not having a name at all simplifies the collision detection algorithm
<whitequark[cis]>
tpw_rules: yes
<whitequark[cis]>
the reason a resource name is itself a tuple is to avoid requiring BSP generators to parse shit like uart.rx[0] which is horrifically error-prone and annoying
<whitequark[cis]>
and which many vendor tools attempt to do and miserably fail at
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark eff37c9 - Deploying to main from @ amaranth-lang/playground@8baaf5b7a99f8093ba2c16e6884512c72fc78cbf 🚀
Hoernchen has quit [Ping timeout: 252 seconds]
Hoernchen has joined #amaranth-lang
Hoernchen has quit [Ping timeout: 252 seconds]
lonjil[m] has joined #amaranth-lang
<lonjil[m]>
Hello! I've just started learning about hardware design, and am using Amaranth. Just wanted to say thanks for having so much excellent documentation :)
<whitequark[cis]>
thank you lonjil!
<whitequark[cis]>
I worked hard to write it, I'm glad you like it
<lonjil[m]>
Made it very easy to get started!
<lonjil[m]>
I will get a little ice40 board next week, but having fun simulating things for now.
<whitequark[cis]>
nice
<whitequark[cis]>
does the lack of a tutorial bother you?
<lonjil[m]>
The getting started section was enough to make the guide easy to follow. A tutorial would be nice, but the guide has been enough for me so far. I may have other feedback later, of course.
Hoernchen has joined #amaranth-lang
<lonjil[m]>
I read a bit of one of the linked tutorials, but it was outdated.
<lonjil[m]>
Though, presumably not so outdated that I wouldn't learn a lot from it.
<lonjil[m]>
The only thing I haven't seen anything about that's been on my mind, is simulating circuits in the context of a platform, such as the board I'm getting next week. Right now, I have some code that asks the platform for a 7 segment display, and then drives that display. Obviously that won't work if there is no platform (or the platform supplied doesn't have such a display)!
<lonjil[m]>
If there is no such option, I'll just have to refactor my code so I can test the logic without a platform, no biggie.
<whitequark[cis]>
<lonjil[m]> "The getting started section..." <- oh, that's excellent to hear! I wrote the guide with the intent of not requiring any advanced preexisting knowledge, though it's light on general digital logic concepts
<whitequark[cis]>
did you find that the order of introduction of Shape and Value was fine, or do you think it should be swapped? (I'm evaluating past feedback)
<whitequark[cis]>
<lonjil[m]> "I read a bit of one of the..." <- yeah, these are still useful but they're getting increasingly bitrotten as years pass
<whitequark[cis]>
I will learn how to write tutorials and write a first-party one, probably, this year, though no specific promises
<whitequark[cis]>
lonjil[m]: > <@lonjil:matrix.org> The only thing I haven't seen anything about that's been on my mind, is simulating circuits in the context of a platform, such as the board I'm getting next week. Right now, I have some code that asks the platform for a 7 segment display, and then drives that display. Obviously that won't work if there is no platform (or the platform supplied doesn't have such a display)!
<whitequark[cis]>
> If there is no such option, I'll just have to refactor my code so I can test the logic without a platform, no biggie.
<whitequark[cis]>
for the longest time, we could not reasonably provide such functionality, for a variety of reasons but they boil down to "the design of various internal was immature or defective"
<whitequark[cis]>
which is why you don't see it anywhere
<whitequark[cis]>
since the 0.5 release that actually became possible though, and I'm going to think about it again--thank you for reminding me
<lonjil[m]>
whitequark[cis]: I didn't have any thoughts either which way. The introduction of shapes is quite short, so you're reading about values almost immediately anyway.
<whitequark[cis]>
thanks
zyp[m] has joined #amaranth-lang
<zyp[m]>
RFC #69 will be another step in the direction of platform simulation
<whitequark[cis]>
yes, RFC 69 is one of the final missing pieces
<whitequark[cis]>
(though you could reasonably make a SimulationPlatform that introduces SimulationPort as its implementation detail already, like Glasgow does)
<lonjil[m]>
whitequark[cis]: I'll have feedback on your WIPs when you write them :)
<whitequark[cis]>
thanks
<zyp[m]>
Catherine: the RGMII stuff you were doing a while back, is that all in glasgow#562?
<lonjil[m]>
And regarding platform simulation: I see, that makes sense. For now I'll refactor my code, or maybe dig into what Glasgow does and try that.
<whitequark[cis]>
zyp: yes, eventually that will probably migrate to -stdio too
<zyp[m]>
nice, I might borrow it and attempt getting it going at gigabit on ECP5
<whitequark[cis]>
I once accidentally ran it at gigabit speeds on Glasgow
<whitequark[cis]>
it didn't work but I vaguely remember the result being interesting
<zyp[m]>
without DDR IO buffers, I guess you were getting every other nibble
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark 4ad0adb - Deploying to main from @ amaranth-lang/rfcs@4709748646e93de14254b86d0907f768c8a2afeb 🚀
<tpw_rules>
whitequark[cis]: are you around? i am trying out the new I/O system but i think there's still stuff that needs to be revamped behind platform.request
<whitequark[cis]>
hi
<tpw_rules>
i have a board from amaranth-boards and it has a connector and i just want to hook buffers to the connector. is that possible yet?
<whitequark[cis]>
that is unquestionably true
<tpw_rules>
or do i still have to go through Resource and Pins?
<whitequark[cis]>
no, you cannot hook things up to the connector, on purpose
<whitequark[cis]>
(for the same reason you can't hook things up directly to an FPGA ball "A1" or something)
<tpw_rules>
is there a way to have a resource with blank pins like you can in connectors?
<tpw_rules>
in my PCB design for something that plugs into that GPIO connector i have the pins indexed according to that table, and i'd like to translate it into amaranth
<whitequark[cis]>
you can't, since resources are intended for a logical view, not a physical view (connectors are the physical view)
<whitequark[cis]>
but you can make each GPIO an individual resource, which is the only fully general solution anyway
<whitequark[cis]>
nothing stops you from only having "gpio",5 and "gpio",7
<tpw_rules>
and io.Buffers is supposed to be given the logical resource?
<tpw_rules>
s/s//
<whitequark[cis]>
correct
<whitequark[cis]>
well, a logical port, which is a part of a port group, which is what requesting a resource by name gives you
<tpw_rules>
okay, thank you. making them an individual resource is straightforward and makes sense. might also be able to make a resource for the object i'm trying to plug in
<whitequark[cis]>
I don't actually currently plan on changing the resource/connector split, the main problem that I see is that (a) you can't use ports in simulation, (b) you can't create a port group yourself (it's an empty class so it's not a huge deal, but it's definitely a speed bump), and (c) there is nothing like wiring.signature for ports