<whitequark[cis]>
PSA: testing of PR #893 is very welcome!
<whitequark[cis]>
please run it on any designs with memories you have, in simulation or synthesis
Guest66 has quit [Quit: Client closed]
adamgreig[m] has joined #amaranth-lang
<adamgreig[m]>
Catherine: I'm getting a bunch of `ValueError: invalid literal for int() with base 2: '0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000` for some tests against that branch, investigating
<adamgreig[m]>
(tests passed on amaranth main branch)
<adamgreig[m]>
it's because my init list has some negative values, and they're being turned into "negative" binary and concatenated together
<adamgreig[m]>
so the big init string in hdl/mem.py L125 that's being passed to int(init, 2) contains like "00000-010101-110001-000000000000000-1010111010100"
<cr1901>
The generated Verilog from converting reader.py is usable as it's own separate IP. So the bare minimum conversion is done. Deciding whether I want to port the demo, and EFB modules tonight (neither of them are going to be very fun)
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] d8b2f67 - Deploying to main from @ amaranth-lang/amaranth@8c4a15ab92af10d5640be4d15f27f0e8843ec154 🚀
<cr1901>
Lattice doesn't actually give you the parameter values. And I couldn't find them by running the scuba binary through strings. So I made a Python script that checks the filesystem for when I generate a SCUBA module while varying each parameter, and then slurps up the generated file into a JSON file that's flushed to disk periodically.
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0dc089a - Deploying to main from @ amaranth-lang/amaranth@21b5451036f94d97ed0022db170fdda61a4c5d6b 🚀
<whitequark[cis]>
what is SCUBA?
<cr1901>
It's the CLI program that Lattice Wizards run to generate IP
<whitequark[cis]>
the parameters are probably in some kinda XL
<whitequark[cis]>
s/XL/XmL/
<whitequark[cis]>
s/XL/XML/
<cr1901>
Maybe I'll take another look this week. It's not like I want to parse the shitload of JSON anyway. And it's a horrible script.
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 398b03d - Deploying to main from @ amaranth-lang/amaranth@f135226a79fddf5caf894030ac7f49995774c3a7 🚀
<galibert[m]>
What should be the order between the docstring and the interface annotations for a Component derivative?
<galibert[m]>
that's a corner of python I really don't know
<mwk_>
docstring before annotations
mwk_ is now known as mwk
<galibert[m]>
thanks
<galibert[m]>
""amaranth._unused.MustUse"" what a beautiful name
<galibert[m]>
Can I use self.counter = Signal(unsigned(self.width), reset=-1)
<galibert[m]>
to say that I want all bits set?
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
Chips4MakersakaS has quit [Quit: Idle timeout reached: 172800s]
vipqualitypost[m has joined #amaranth-lang
<vipqualitypost[m>
i'm trying to implement an a-b encoder module and struggling with this. initially I was thinking just to check on clock edges if the inputs have changed since the last clock cycle, but this actually seems really wasteful and I feel like I should be able to do something like setting one of the inputs as a clock domain and sampling the other pin when the "clock" changes
<vipqualitypost[m>
i'm having a bit of trouble with that, but the real thing I am confused about is how I would do "quad' resolution, where it would sample on both rising and falling edge of the clocked input. does amaranth support that? i couldn't find many notes on it
<vipqualitypost[m>
i see that there is `ClockDomain("<domain-name>", clk_edge="<pos|neg>")` to name the edge but I think if you make two of these, I'll have two domains and that will cause a problem with my counter register - right?
<galibert[m]>
maybe not. You cannot write from two different domains but you can read from both as long as they're from the base underlying clock signal
<adamgreig[m]>
Probably best to do what you first thought and sample both inputs on your main clock, ideally through a flipflop in the io cell too. Generally speaking it's best to avoid trying to use some input signal as a clock, and even if you did, you'd have to do some clock domain crossing to move the count back into your main clock domain anyway....
<adamgreig[m]>
Plus then it's straightforward to respond to both rising and falling edges of your encoder
<galibert[m]>
Oh, a quad encoder. Well, decoder I guess
mcc111[m] has joined #amaranth-lang
<mcc111[m]>
Okay I'm installing Quartus today so I will soon be asking for help with connecting Amaranth to it!
<mcc111[m]>
I now have my Analogue Pocket. I also ordered a Colorlight i5 devboard, and the package arrived, but instead of containing a Colorlight i5 devboard it contained an action figure of "Trunks" from Dragonball Z.
<mcc111[m]>
* Dragonball Z. So for now I only have the Pocket.
<galibert[m]>
Quartus with amaranth just works. Caveats: jtag programming requires uncompressed bitstreams, and memory synthesis by Quartus is horribly slow, instancing m10k goes infinitely faster. Horribly slow = 40mn for 64k iirc
<adamgreig[m]>
wonder what's going wrong there
<galibert[m]>
in quartus you mean?
<adamgreig[m]>
yea, is it failing to infer a ram?
<galibert[m]>
It's not failing, it's using way too much time to do it is all
<adamgreig[m]>
I haven't had to use it in ages and ages, but didn't have issues on cyclone iv/v
<galibert[m]>
I probably could ty to find out what's going on in there, but what would the point be? :-)
<galibert[m]>
were you inferring 64k of bram?
<adamgreig[m]>
hmm, too far ago to remember, but at least a few kB
<adamgreig[m]>
this was probably long ago enough to not be relevant, anyway, just surprised that something's going that poorly
<cr1901>
The only Altera board I have is a Cyclone II. So yea, that board is prob never seeing the light of day again.
<adamgreig[m]>
i actually really enjoyed the cyclone v soc chip, the integration with the arm core was surprisingly fine, even (especially?) without touching any quartus guis or anything
<galibert[m]>
it's like quadratic I think. So it's not that noticeable at the start
<galibert[m]>
when it takes a couple of minutes for 4K, you think "well, quartus is known to be slow", it's when it takes 40mn for 64k that you really start to wonder what's going on
<adamgreig[m]>
you could just instantiate a cyclonev_hps_interface_hps2fpga_light_weight with an AXI3 port and talk directly to/from the arm's memory space, and then separately there was also a 32-pin gpi/gpo port which you could also use for interrupts and such
<adamgreig[m]>
from what I hear of zync it's much better. shame everyone ended up using zync and the amd soc stuff seems relatively unloved
<adamgreig[m]>
* from what I hear of zync, altera was much better. shame everyone ended up using zync and the amd soc stuff seems relatively unloved
<galibert[m]>
plus you have the interrupt lines, direct sdram ports, it's very nice
<galibert[m]>
and even clocks originating from the hps
<adamgreig[m]>
mcc111: did you hear anything from the seller about the trunks figure? seems hard to mix up :p
<galibert[m]>
also the memory thing may be a kink of the specific version of quartus I use, who knows
<mcc111[m]>
adamgreig[m]: they accepted my request for a refund and return without comment lol
<galibert[m]>
I haven't updated in a long while
<adamgreig[m]>
hah, oh well
<adamgreig[m]>
gonna order another? the ecp5 on the colorlight is a nice small fpga, but i guess the analogue pocket is both a more fun platform and maybe more relevant to what you actually wanna do
<adamgreig[m]>
iirc it has two fpgas, and you put your user code on one of them, and the other keeps handling basic system stuff for you or something?
<mcc111[m]>
mcc111[m]: now i need to decide whether to re-order the i5 or go with the colorlight i9 instead… it's not totally clear to me what the difference is. they sound almost identical but one is like $20-30 more expensive, which if this is going to be my "beefy" fpga, i'm now realizing is not unreasonable. but i don't know like, what's beefier or how much. i'm just assuming it's better because 9 is better than 5 and it's more expensive
<mcc111[m]>
adamgreig[m]: yes, that's correct. however i wanted to get a "regular" fpga to give myself a sense of what it's like doing normal fpga work instead of living in analogue's slightly-idiosyncratic box.
<adamgreig[m]>
i5 is a lattice semiconductor ECP5 fpga, which has a good and mature open-source toolchain, but is a sort of mid-size fpga in terms of clock speed, number of logic blocks, amount of ram, that sort of thing
<adamgreig[m]>
i use them a lot for work because the toolchain is so convenient and also they're "big enough"
<mcc111[m]>
So i got two things, a nano 9k in a kit with a tiny screen connected by ribbon cable, and the colorlight i5. I felt kind of silly getting both but i figured what if i can't get both working. it'll be nice to have a backup.
<mcc111[m]>
i didn't anticipate one of them would literally be a non-electronic action figure
<galibert[m]>
is the cyclonev of the pocket or the de10-nano mid-size or considered more than that?
<adamgreig[m]>
oh, for some reason I thought the i9 was a different fpga, but the i9 I'm looking at is another ecp5, so
<mcc111[m]>
galibert[m]: i don't have near enough knowledge to evaluate this question.
<adamgreig[m]>
ah, the i9+ is a xilinx fpga
<mcc111[m]>
oh, wait, that sounds bad
<adamgreig[m]>
but the i9 is ecp5 😅
<mcc111[m]>
oh.
<mcc111[m]>
i got the sense xilinx is more unpleasant propreitary than lattice.
<adamgreig[m]>
the amd cyclone-v in the pocket is a much beefier fpga than the ecp5 on the colorlight
<galibert[m]>
ok, I know the arrias are big-size but they're so damn expensive it's not funny
<mcc111[m]>
is the ecp5 in the i9 not-plus different from the one in the i5?
<mcc111[m]>
adamgreig[m]: ahh, really
<adamgreig[m]>
the xilinx in the i9+ is maybe comparable with the ecp5 in the i5/i9?
<adamgreig[m]>
well let's check the actual part numbers rather than going on vibes, hold up
<galibert[m]>
de10-nano is 5CSEBA6U23I7, analogue pocket is 5CEBA4F23C8
<mcc111[m]>
Google searches are highly polluted by the Intel general purpose CPUs of the same name…
<mcc111[m]>
I was gonna ask Whitequark as she was the one who recommended the Nano and Colorlight boards to me, but of course timezones and such
<adamgreig[m]>
colorlight i5 is usually a lattice 25k-LUT ECP5, colorlight i9 v7.2 is a lattice 45k-LUT ECP5 (LFE5U-45F-6BG381C), so about the same speed but twice as much logic
<adamgreig[m]>
but honestly the variation between what you get when you order "colorlight i5" on aliexpress is enough that you might get 25/45k on either, I think
<adamgreig[m]>
they're plug in modules for controlling big LED displays, so the thing their usual buyers care about is that they can drive those displays
<mcc111[m]>
haha
<mcc111[m]>
do you know the LUT on the pocket's cyclone v, or can i compare those numbers directly?
<adamgreig[m]>
i9+ is a xilinx XC7A50T-FGG484 which is 50k LUTs so about the same amount of logic as the ECP5s, I think probably a similar sort of clock speed but not sure
<adamgreig[m]>
looks like the pocket's 5CEBA4F23C8 is also on the order 50k LUTs?
<mcc111[m]>
ok
<galibert[m]>
pocket's has 1848 labs or mlabs, each being 10 labcells
<mcc111[m]>
what should i look up (say on wikipedia) to understand the definition of lab, mlab, and LUT?
<galibert[m]>
labcell = lut6 or 2xlut5 or 4xlut4
<mcc111[m]>
anyway. sounds like equivalent lattice fpga but nearly twice as big.
<mcc111[m]>
here is a question, when i build for the lattice in the colorlight i9, will i be able to measure (or profile) the space my build takes up?
<mcc111[m]>
if for some absurd reason i later want to go "i wonder if this build i'm placing on the i9 *would* have fit well on the i5" can i easily answer that question?
<adamgreig[m]>
ah right, it has two FPGAs, the cyclone v with 50k elements that you program, and a cyclone 10 with 15k elements that I guess runs the rest of the system
<mcc111[m]>
adamgreig[m]: yeah, i think the cyclone 10 is so that you can load cores onto the cyclone v without interrupting basic stuff like usb i/o?
<adamgreig[m]>
yea, when you run the build it will report how much of each resource you used, what % full it is, that sort of thing
<adamgreig[m]>
and you could also just ask it to run a build for the smaller fpga and see if it succeeds, too
<galibert[m]>
the second fpga also does all the video scaling
<adamgreig[m]>
so yea, on balance I guess the i9/i9+/pocket are all similar order of magnitude FPGAs despite being from three different families, the i5 is usually half the size
<adamgreig[m]>
the other things you compare are how much RAM they have onboard, and how many things like DSP blocks
<mcc111[m]>
adamgreig[m]: ok great. i think i'll go for the i9.
<mcc111[m]>
i have this absurd idea "maybe if i make something really neat, i can buy more i5s and sell a little device with my build loaded" but i don't know if that's good thinking and also i'm so far from making any of my ideas real
<galibert[m]>
nano has 4191 labs/mlabs, somewhat bigger, and an embedded dual-core arm
<adamgreig[m]>
the 45k ecp5 has about 2Mbit RAM, the pocket's cyclone-v is about 3.4Mbit, the xilinx in the i9+ is about 2.6Mbit... all fairly comparable
<galibert[m]>
the m10k are 256x40bits, there are 308 in the pocket and 553 in the nano
<mcc111[m]>
adamgreig[m]: "not much" lol
<mcc111[m]>
this is what i'm looking at and it is somewhat unreliable. for example, the seller puts "RISC-V" in the item title despite all they mean being you could potentially use the fpga to build a risc-v.
<adamgreig[m]>
in their pictures, the i5 is indeed the 25k and the i9 is the 45k
<mcc111[m]>
galibert[m]: so are you saying the nano might actually be better? Or do you just mean it will be larger with potentially other downsides.
<galibert[m]>
de10-nano is an evaluation board. It's very nice, but it does not have the form factor of the pocket
<mcc111[m]>
i think it would be good to have at least one of my other boards "similar to" the pocket in capabilities enough i could move things i wrote back and forth
<mcc111[m]>
Whitequark said that the i5/i9 devboard had an HDMI outlet on it, which i could potentially run actual HDMI out of
<mcc111[m]>
to me it would be interesting to make something that runs on the convenient Pocket form factor, then see if I can reproduce it as a single box plugged directly into a television
<mcc111[m]>
This is, again, getting far ahead of myself.
<galibert[m]>
the cyclonev in the de10-nano is significantly larger than the pocket's, and also slightly faster
<galibert[m]>
de10-nano has an hdmi output with sound support (some other cyclone v eval boards don't have the sound connected)
<galibert[m]>
it's not directly connected to the hdmi pins, it has a ADV7513 to help
<mcc111[m]>
galibert[m]: That price is much better.
<adamgreig[m]>
the tang nano 9k is indeed a totally different fpga from a fourth vendor, a quarter the size of the lattice/altera/xilinx ones you're looking at
<galibert[m]>
de10-nano is what is underlying the mister fpga thing, which is used for emulation of lots of stuff. Which means people have developed interesting additional boards and cases
<mcc111[m]>
aha
<galibert[m]>
sdram boards, i/o boards with vga, that kind of stuff
<mcc111[m]>
now i understand how everything fits together
<adamgreig[m]>
just coincidence that there's also an altera board called de10-nano
<adamgreig[m]>
it's "paying full price for an fpga dev board" rather than "buying weird cheap boards from alix" territory, but it's super popular for emulation so yea, lots of support for it there
<mcc111[m]>
Terasic and Altera appear to work together sometimes, I think my "official" altera programmer was actually manufactured by Terasic?
<adamgreig[m]>
lattice ecp5 is well supported by the open source toolchains (i.e. yosys and nextpnr)
<galibert[m]>
open source support for the cv is being worked on
<adamgreig[m]>
not sure about the tang nano
<galibert[m]>
tang nano is gowin
<mcc111[m]>
ok. this is all really helpful. i'm gonna buy the i9 without waiting to hear from Catherine, and I'm going to keep the de10-nano link in my notes. if i get to the point i am making openfpga cores, maybe i can convince the MiSTER community to buy me a de10-nano/mister. And if I can't reach that point, then maybe that implies i'm not doing anything useful enough it justifies porting to MiSTER in the first place :)
<adamgreig[m]>
I look forward to seeing how you get on with the pocket though, seems fun!
<galibert[m]>
untested by me, obviously
<galibert[m]>
I need to buy a pocket at some point
<mcc111[m]>
ok. that's not a surprise because the reason i picked it in the first place is it's apparently the device Catherine targets for her in-progress tutorial.
<mcc111[m]>
adamgreig[m]: yeah, i'm really excited! i had like an hour or two of frustrating leaning curve when i was first setting it up, but then it was like i broke free and now i'm really happy with both the power and convenience. and we're still waiting for a hopefully-soon firmware update that will supposedly resolve most of the remaining issues.
<mcc111[m]>
i have so many ideas for things to make.
<mcc111[m]>
okay, time to turn off my computer, so i can plug in my spare hard drive, so i can actually have enough space to install the Altera toolchain D:
<cr1901>
Gowin FPGAs are fine... their built-in DRAM is cool too.
<galibert[m]>
kevtris ensured that the pocket was a good design, with in particular a bunch of fast memory ports
<galibert[m]>
it's just that the price put a ceiling on the size of fpga they could use
<mcc111[m]>
So far, it seems wholly adequate for the target platforms (all 2D game systems?)
<mcc111[m]>
The one relevant machine I'm not sure whether it's ever going to be able to cover is the Saturn. But even software emulation struggles with that.
<cr1901>
CDi is also very difficult to emulate (and few ppl want to b/c the game library is bad).