<adamgreig[m]>
better to use the clock to sample the signal and compare to its previous value, which is still very efficient to do
<cr1901>
mcc111[m]: If you want to know more about CDCs, I recommend the EETimes "Clock Domain Crossings Made Easy" post. It is the most viewed post on the site by a large margin. It goes over basically everything except handshaking (REQ signal sent one way, ACK signal sent the other)
<cr1901>
"Understanding Clock Domain Crossing (CDC) Checks and Techniques"*... I mixed up the title w/ something else, sorry
GenTooMan has quit [Ping timeout: 246 seconds]
<whitequark[cis]>
<mcc111[m]> "That makes sense, it seems..." <- FPGAs do have edge detection parts (any flop detects an edge), however usually when you make an edge detector you want to have a well defined timing relationship between the input signal and the output
<whitequark[cis]>
and if you use a flop's clock input to make an edge detector, the relationship between them is not well defined in the simplified abstraction that much of the toolchain uses
<whitequark[cis]>
(this isn't exactly accurate as stated, but I'm doing my best to convey what's going on to someone without much FPGA experience)
GenTooMan has joined #amaranth-lang
<mcc111[m]>
Thanks
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #amaranth-lang
<mcc111[m]>
OK so I have a couple real ignorant questions
<mcc111[m]>
- I'm working with a device with a 4x4 matrix of LEDs. A kind person in this channel (charlotte) gave me this :
<charlottia>
(👋 lessee if I can answer some more!)
<mcc111[m]>
… for the board definition file.
<mcc111[m]>
This looks like something "standard"
<mcc111[m]>
what am I… looking at here?
<charlottia>
This is part of a platform definition! It's just another subclass, defining a list of resources that you can request from an instance of it.
<charlottia>
The first two parameters are name/index which the user of the platform can then look them up by (platform.request("aled") will get you the first "aled" for your platform); the Pins(...) are what actually map to the hardware proper.
<charlottia>
These are a bit heavy to look at at first because they're mostly helper and diagnostic.
<mcc111[m]>
sorry i mean i think i can figure out how to go from there to the amaranth manual
<charlottia>
The end result is that, when you use these in your actual components, the created pins/signals will get mapped to the correct thing on the FPGA (by the definition there).
<mcc111[m]>
what i don't understand is the aled/kled thing, or what types any of these 5 values (the one anode or one cathode) are, or how I map these eight (?) values to 16 real LEDs
<mcc111[m]>
I feel like there is some hardware concept I am unaware of that makes this make sense
<charlottia>
Oh, okay! This was on the last page of the Doppler schematic iirc
<mcc111[m]>
i think I know what an anode and cathode are in the form of a literal single LED
<mcc111[m]>
oh! well let me go look that up
<charlottia>
So the cathodes/kled are on the left-hand side (labelled IOT_42B/4.3B, IOT_41A/4.3B, ...), and the anodes/aled are on the right-hand side (IOT_51A/4.2B, IOT_49A/4.2B, ...).
<charlottia>
Using them together you can select the 16 LEDs.
<charlottia>
They're wired in such a fashion that you can select just one (or multiple) by using each side as indices, I guess?
<mcc111[m]>
I think what I am missing is conceptual/theoretical :(
<mcc111[m]>
Okay so a basic question. When I see "IOT_51A/4.2B" on that port. What "is" that? Is that a single GPIO pin? What on this schematic lead you to the conclusion that the LED anodes should be one 4-bit value and the knodes (cathode nodes?) should be four one-bit values?
<crzwdjk>
IOT_51A is a GPIO pin on the FPGA
<Darius>
mcc111[m]: if it is on a part it would usually match the name teh vendor calls that pin
<crzwdjk>
(tedious irrelevant detail: the GPIOs on these come in "banks" so IOT_51A means it's an IO from the Top bank)
<charlottia>
(that's really helpful!! I didn't know that!)
<Darius>
crzwdjk: I think that is helpful as it explains the why the name is what it is!
<crzwdjk>
There is some mapping from the GPIOs to the actual pin numbers on a specific package, because the same FPGA can come in different packages
<charlottia>
But yeah, on the previous page you can see IOT_51A along the top, and so on. They all feed directly into the FPGA.
<Darius>
dunno what the '3.3C' in 'USBD_P/3.3C' means though
<Darius>
for FPGA dev boards a lot of the net names are very generic because the FPGA is very generic
<Darius>
especially where they just go to pin headers - they have no meaning apart from "connects to pin X on the FPGA".
Degi has joined #amaranth-lang
<charlottia>
You can specify dir = "i" (input), "o" (output), or "oe" (output enable, aka "tristate"). Tristate means you can not only control whether you're putting out a 0 or 1 on that pin, but also whether you're putting anything at all. (i.e. are you connecting it to ground, to positive voltage, or leaving it unconnected/floating/"high impendence".) The Verilog example didn't actually set the cathode pins to 0, which would ground
<charlottia>
them, but instead toggled on/off whether or not they were being output to whatsoever.
<charlottia>
dir="oe" gives you one "output enable" for the whole Pins(...), but we need one-per-pin, so we have to specify one resource per cathode.
<charlottia>
(This could also be done in other ways, but this was just the simplest route to reproduce their example.)
<crzwdjk>
But stepping back a bit: the LEDs are in a grid, and some FPGA I/Os correspond to wires running along the rows and others to wires along the columns, so if you set a given row-wire low and column-wire high (or vice versa), the LED at the intersection of the row and column will light up. So you have 4 bits for row and 4 for column and you set 1 of each to select 1 LED
<crzwdjk>
And if you want multiple LEDs you just go through all the ones you want to light up really quickly I guess
<mcc111[m]>
crzwdjk: Okay this may have been what I was missing
<charlottia>
They use a 32-bit counter and spend a little bit of time on each index in the input bits.
<crzwdjk>
mcc111[m]: if you are familiar with how a keyboard scan matrix works, this is the same thing but in reverse, kind of.
<mcc111[m]>
okay thank you for the explanations
<crzwdjk>
So going through that verilog example, it always sets one bit to 0 in aled, the counter[6:5]'th one, and (potentially, depending on ledbits) one bit to 1 in kled, the counter[8:7]'th one.
<crzwdjk>
I wouldn't write it quite the same way in Amaranth, I think. Well, particularly the "always @(posedge counter[4])" part.
<mcc111[m]>
bit 0 aled is "active"?
<mcc111[m]>
my next question, again kind of bouncing off charlotte's example… is there a standard debounce part/library for amaranth?
<crzwdjk>
Debounce for switches? I don't think so but for a single input switch it's not hard to write one
<mcc111[m]>
Yeah, I think I can probably imagine one even with my zero hw experience
<mcc111[m]>
i'll just give it a shot. thanks y'all
<crzwdjk>
You're welcome, glad to be of help
GenTooMan has quit [Ping timeout: 252 seconds]
<crzwdjk>
And yeah, apparently you need to set a 0 in the corresponding position of aled and a 1 in the corresponding position of kled to get the LED at that row/column position to light up
<crzwdjk>
Which makes sense, the LED lights up only when the + end gets 3.3 volts and the - end gets 0 volts
Wanda[cis] has joined #amaranth-lang
<Wanda[cis]>
<mcc111[m]> "my next question, again kind..." <- a very non-obvious thing: before you start debouncing, you'll need a `FFSynchronizer` to even look at that button from inside your clock domain
<crzwdjk>
Fortunately that is a thing that amaranth does come with, which is very handy.
<whitequark[cis]>
<mcc111[m]> "my next question, again kind..." <- there is not; in my experience it's easy enough to write whenever you need it, which is not often
<Darius>
debouncing is a bit different to FF synchronising IMO
<Darius>
since you want changes at like..10Hz
<Darius>
I used a shift register and changed output when it was all 0s or all 1s - seemed to work :)
GenTooMan has joined #amaranth-lang
<mcc111[m]>
Darius: Oh, that's good
<mcc111[m]>
uhhh, that leads to another thing i was wondering
<mcc111[m]>
is there a drop-in shift register part for amaranth
<whitequark[cis]>
nope! it's literally two lines of code
<mcc111[m]>
because a shift register can be a register. ok
<mcc111[m]>
i keep forgetting fpga is ok with hundreds-of-bits values
<whitequark[cis]>
yep!
<whitequark[cis]>
well, depending on the device
<whitequark[cis]>
your FPGA only has 70 hundreds of bits or so
<mcc111[m]>
right. but i could put all 70 hundreds in a single Signal if I wanted I assume
<mcc111[m]>
One more question, and this is very embarrassing because it's another "I do not know how to read a schematic" question… where on that could I see what clock rate the iCE40UP5K has? Like how long I should expect a cycle to be? I found a datasheet but it looks like it's saying the iCE40UP5K has external clock (?). I find the ice40 on page 4 of my device's schematic
<whitequark[cis]>
<mcc111[m]> "right. but i could put all 70..." <- yes
<whitequark[cis]>
well, literally doing that will fail due to routing congestion
<whitequark[cis]>
oh, wait, you have an up5km
<whitequark[cis]>
* oh, wait, you have an up5km
<whitequark[cis]>
s/up5km/up5k?/
<whitequark[cis]>
thats 5000
<sorear>
if all you're planning to do is compare it to all-1s or all-0s you can do that with log2(N) state bits
<whitequark[cis]>
which is called a counter
<whitequark[cis]>
that is the normal way people implement debouncers
<whitequark[cis]>
for physical buttons i mean
<Darius>
oh you people with your thinking and logical reasoning
<Darius>
good idea tho
<crzwdjk>
mcc111[m]: I don't see any clock inputs to the FPGA, which means it's using the internal oscillator, so the clock is whatever the default for that is
<whitequark[cis]>
SB_HFOSC os uh
<whitequark[cis]>
* SB_HFOSC is uh
<whitequark[cis]>
6, 12, 24, or 48 MHz depending on the divisor
<mcc111[m]>
thanks
SpaceCoaster has quit [Ping timeout: 256 seconds]
SpaceCoaster has joined #amaranth-lang
SpaceCoaster has quit [Ping timeout: 245 seconds]
SpaceCoaster has joined #amaranth-lang
<josuah>
oh, catircservices is synapse
<josuah>
let's try that
<whitequark[cis]>
for general use i recommend conduit
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c704879 - Deploying to main from @ amaranth-lang/amaranth@7b992672aa5f334af25b0c3290a959d64aa3bbd5 🚀
sugarbeet has quit [Ping timeout: 245 seconds]
sugarbeet has joined #amaranth-lang
galibert[m] has quit [Quit: Idle timeout reached: 172800s]
<mcc111[m]>
"Because Amaranth ensures that the width of a variable left shift expression is wide enough to represent any possible result, variable left shift by a wide amount produces exponentially wider intermediate values, stressing the synthesis tools… Although Amaranth will detect and reject expressions wide enough to break other tools, it is a good practice to explicitly limit the width of a shift amount in a variable left shift."
<mcc111[m]>
What does "explicitly limit" mean in practice? Does this mean "assign to a Signal with a known width" or does it just mean "& 0xFFF" or something? or like… `.cast(5)` maybe? What's idiomatic?
<josuah>
I think it is to cap the amount to shift
<josuah>
to give a known size to the signal that holds the amount to shift
<josuah>
hmm, good question though: when "b" is over 12, "(a < b) & 0xFFF" and "a < Min(b, 12)" have different results...
<mcc111[m]>
josuah: That makes sense, I think what I'm asking "is the correct way to cap the amount to shift to say for example `(a << 5).cast(8)` or is there a better way I'm missing?"
<mcc111[m]>
actually related question I guess, does amaranth have a "rotate by variable amount" operation?
<josuah>
during some kind of optimization, "(a < b) & 0xFFF" or ".cast(8)" would allow limitting the max value of "b", but that is not explicit in the design
<josuah>
ah, I thought you wanted to shift by a variable amount
<josuah>
where both "a" and "b" are signals
<josuah>
this would generate an exponential amount of intermediate values, whereas "a << 5" might be quite safe I think
<josuah>
for a rotate by variable amount, I think you could have something done like this to cap it:
<mcc111[m]>
josuah: i don't want anything right now, I'm just reading the manual and trying to make sure I understand what I'm reading
<josuah>
"(a < Min(b, 8 + 8)).cast(8)": namely: casting the result, but also limiting the the internal shift value by a constant, to avoid stress on the synthesis tools as explained
<josuah>
you could have been luckier and find someone writing Amaranth every day, I'm getting a bit rusty myself...
<josuah>
too much infrastructure and deployment and configuration and not enough HDL for me! :)
<crzwdjk>
Re variable rotates, the manual says "Rotate operations with variable rotate amounts cannot be efficiently synthesized for non-power-of-2 widths of the rotated value. Because of that, the rotate operations are only provided for constant rotate amounts, specified as Python ints"
<josuah>
thank you for restablishing the truth, looks like I a few more hours diving down the doc
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 1c3050e - Deploying to main from @ amaranth-lang/amaranth@f976754e15e625d5b88beb7798e64f8b7ca20f48 🚀
<_whitenotifier-9>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-863-7b992672aa5f334af25b0c3290a959d64aa3bbd5 - https://github.com/amaranth-lang/amaranth
<mcc111[m]>
"The signal driven by the AsyncFFSynchronizer is asserted asynchronously and deasserted synchronously, eliminating metastability during deassertion." does this mean "set high asynchronously and set low synchronously"?
<mcc111[m]>
so say I want to "compose" one Elaboratable inside another— what's the correct way to do this? Just manufacturing inside elaborate() (see highlight) feels wrong especially
<mcc111[m]>
Should I… create the Elaboratable subclass inside __init__ then pass on the elaborate() in Top.Elaborate? Or is there some ~affordance~ for doing this sort of thing automatically?
<whitequark[cis]>
modern LEDs are so high efficiency that barely any power makes them too bright to look at
<whitequark[cis]>
I had that problem on early Glasgows
<mcc111[m]>
ok
<whitequark[cis]>
i ran the LEDs at something like 10 mA (on the high side but reasonable) and that resulted in like... >0.1 cd of light
<whitequark[cis]>
which you can use as a flashlight
<whitequark[cis]>
that's a single LED
<whitequark[cis]>
if it's connected to the FPGA pins directly with no resistors it'll run hot
<mcc111[m]>
ok. maybe i'll… only light these one out of every four cycles or something.
<mcc111[m]>
Say I'm gonna have like, 8 signals which all contain (EXPRESSION &) as a term. Intuitively it seems like I'll get a "performance" boost from setting EXPRESSION to a comb signal than repeating expression in each of the other signals' expressions. Is that good or bad or dangerous thinking?
<whitequark[cis]>
no, it makes absolutely no difference
<whitequark[cis]>
you can try it and look in the log or tim file
<mcc111[m]>
ok. so i will just do what produces nicer looking code
<mcc111[m]>
for this use case do I need to use bit_select or word_select?
<mcc111[m]>
And, if so, this raises a question: what is the difference between bit_select and word_select? the doc says the first is "overlapping" and the second is "nonoverlapping" and I don't know what that means.
josuah_dem[m] has joined #amaranth-lang
<josuah_dem[m]>
why not just storing attenuate_power and use self.current_led.count[0:self._led_attenuate_bits] == 0?
<josuah_dem[m]>
I think this is plain python syntax issue here
<josuah_dem[m]>
l = [i for i in range(100)]; l[range(0,10)]
<josuah_dem[m]>
This gives "TypeError: list indices must be integers or slices, not range"
<josuah_dem[m]>
I do not know python much. but this bother my python at least!
<mcc111[m]>
slices aren't ranges? :(
<mcc111[m]>
josuah_dem[m]: because one of the bit ranges I need is ` self._highlight_bits = (attenuate_power+4, attenuate_power+4+highlight_bits) # active 0`. I need to store two indexes in one variable.
<mcc111[m]>
I'm now just using tuples and destructuring them when calling bit_select. I think this is working properly but I'm not totally sure yet.
<josuah_dem[m]>
I just learned that range() was a special class, like list()... Fancy!
<mcc111[m]>
I guess there's just a slice() method.
Degi has quit [Ping timeout: 240 seconds]
<mcc111[m]>
I'm still confused by the difference, if any, between signal[slice(a,b)), signal.bit_select(a,b), and signal.word_select(a,b).
<mcc111[m]>
josuah_dem[m]: I am looking at this, but I sincerely don't understand the difference between "bit slicing" and "part select", nor "overlapping" and "non-overlapping".
<josuah_dem[m]>
With the "Equivalent Python code"
<josuah_dem[m]>
(the table under that)
<mcc111[m]>
oh
<mcc111[m]>
thanks
GenTooMan has joined #amaranth-lang
<zyp[m]>
<whitequark[cis]> "i ran the LEDs at something like..." <- IME if you've got a green InGaN LED, it's plenty bright as an indicator at 100uA
<whitequark[cis]>
we run our LEDs at a fraction of that
<whitequark[cis]>
iirc at 56 uA?
<zyp[m]>
sounds reasonable
<zyp[m]>
InGaN green has like two orders of magnitude more light output than the traditional AlGaInP green LEDs
<zyp[m]>
I've made the mistake of picking an InGaN LED and setting the current limiting resistor as if for an AlGaInP LED…
<whitequark[cis]>
mcc111: no, slices and ranges are different. a slice is constructed by `5:3` in `x[5:3]`, mostly because `__getitem__` cannot accept multiple arguments so they had to invent an intermediate class
<whitequark[cis]>
oh, no, I'm wrong
<whitequark[cis]>
consider that you could have a dictionary = {range(5)}
<whitequark[cis]>
if slices were ranges, then doing dictionary[0:5] would be ambiguous
<whitequark[cis]>
* consider that you could have a dictionary = {range(5): "something"}
<whitequark[cis]>
adamgreig: o/
<adamgreig[m]>
o/
<whitequark[cis]>
wanted to check in with you on the LFSR project
<adamgreig[m]>
I've written up most of an rfc, a few outstanding points of discussion around how in depth support for things like error detection or parallel generation of both Galois and Fibonacci type registers should be etc, the basic design is probably gonna be v similar to crc since both have a sort of Algorithm, Parameters, generator and some predefined algorithms
<adamgreig[m]>
But, I'm travelling until Tuesday and probably won't have signal let alone time, so doubt I'll have it submitted before the Monday meeting
<whitequark[cis]>
ohhh that's really nice to hear! I'm excited
<whitequark[cis]>
yeah that's completely okay
<mcc111[m]>
<whitequark[cis]> "if slices were ranges, then..." <- Because dictionaries can take an iterator as key…? Returns what, an iterator over values?
<adamgreig[m]>
Not sure how much people will care about generating both types of structure. The output is the same (modulo a time shift) but for doing fast lfsrs in asics my guess is it's an important choice
<adamgreig[m]>
So I planned on having both for the single bit generation, but once it's a parallel generation it looks quite different anyway, so not sure it still makes sense to differentiate
<whitequark[cis]>
mcc111: no, that specific thing is just a type error
<whitequark[cis]>
but having ranges as a key in your container makes sense
<adamgreig[m]>
Anyway it'll be in the RFC :p
<whitequark[cis]>
because you can take values from the user, e.g. for caching
<whitequark[cis]>
and they can be ranges
<whitequark[cis]>
let me rephrase: there is an implicit expectation that dict[x] and dict[y:z] do two fundamentally different operations, no matter what x could be
<whitequark[cis]>
* let me rephrase: there is an implicit expectation that obj[x] and obj[y:z] do two fundamentally different operations, no matter what x could be
<whitequark[cis]>
because, among other things, the types of obj[x] and obj[y:z] are fundamentally different, and being able to rely on types returned by indexing is a useful guarantee to have
<whitequark[cis]>
does that make sense?
<whitequark[cis]>
this does carry the implication that using slice objects for anything except for this very narrow use case can cause random breakage in third party code that sees them, which is probably the case
<zyp[m]>
Catherine: I've been thinking a bit about starting to draft a streams RFC; would that be useful or would I be getting into stuff you've already got plans for? It would obviously depend on the interfaces RFC, but I figure that is firm enough by now that it's possible to at least start outlining streams in a draft
<whitequark[cis]>
sounds good to me!
<zyp[m]>
then I'll see what I find time for, no promises until I do :)