<adamgreig[m]>
yay, my amaranth uart->dac design for the tinytapeout 02 asic run arrived and it works 🚀
<adamgreig[m]>
i can output voltages with 8 bits of resolution, tens of millivolts of ripple, at 20 samples per second, with a few hz of bandwidth... but it does output voltages!
<tpw_rules>
super cool
<adamgreig[m]>
there's also an adc->uart half of the design which i haven't tested yet but in theory might have as many as 12 bits of resolution at... 60 samples/second lol
<tpw_rules>
i didn't know they let you do analog?
<adamgreig[m]>
they do for tt06 which is now open actually! but this tt02 design is digital, the DAC outputs a pulse-density-modulated signal and an external rc filter finishes the conversion to analogue
<tpw_rules>
ahh
<adamgreig[m]>
the ADC is another DAC instance with external RC feeding external comparator, input signal to measure to other side of comparator, binary comparator output goes back into the ASIC
<tpw_rules>
i should make a blinky or something just for fun
<adamgreig[m]>
then feedback adjusts the DAC to match the external signal and sends the DAC code out the UART as the ADC reading
<tpw_rules>
and to have an excuse to nixify the gds flow
* tpw_rules
is suspicious of the nested docker containers and github actions
<adamgreig[m]>
the gha is very convenient though, I just cloned the repo, added my amaranth script (plus a makefile to build it into verilog), then push, and a few minutes later gds run is complete
<adamgreig[m]>
I think the process has evolved a bit since like mid-2022 when this got submitted, lol
<tpw_rules>
do the tinytapeout people pull the gds direct from that?
<adamgreig[m]>
I think for tt02 they actually grab your verilog and re-synth the whole chip and gds that
<tpw_rules>
what can you do with the gds yourself?
<adamgreig[m]>
because they couldn't afford for someone to have built something that eg shorted vcc-gnd and breaks the chip for everyone
<adamgreig[m]>
just look at them I guess. it lets you check it fits inside the size limit and pass drc etc
<tpw_rules>
fair. yeah don't they just bond the chip differently for everyone?
<adamgreig[m]>
for general multi-project wafers yes, but tinytapeout is one project on an mpw, which further subdivides into loads of tiny projects
<adamgreig[m]>
they use 8 inputs on the chip to select which internal project is active
<adamgreig[m]>
on the first versions (like this tt02 which has finally been made and arrived this week) it's an internal jtag-esque scan chain between all 256 internal project slots
<tpw_rules>
ah. so you could try everyone's projects if you wanted
<adamgreig[m]>
yea! which is fun
<adamgreig[m]>
but it's sooo slow
<tpw_rules>
selecting a project?
<adamgreig[m]>
the fastest I can clock my design is 2.5kHz, so my DAC UART is running at 253 baud
<tpw_rules>
oh
<tpw_rules>
why?
<adamgreig[m]>
the 8 inputs (one of which is your clock if you want a clock) and 8 outputs are on a long scan chain
<adamgreig[m]>
it scans them in and shifts them to/from all designs
<adamgreig[m]>
so the design only sees an update of the inputs/outputs at like a few 10s of kHz?
<tpw_rules>
oh, i guess that would be hard to mux. so you clock your design at 2.5KHz*256?
<adamgreig[m]>
I'm not sure of the exact clocking setup, but the clock signal into my design is 2.5kHz max, you can make it divide it down slower if you like lol
<adamgreig[m]>
but for the new tapeouts, like tt06 now running, it's totally different
<tpw_rules>
sorry, i mean the chip itself
<adamgreig[m]>
they've improved the mux design dramatically so it's now an actual mux, not a scan chain, and each design is independently power gated too
<adamgreig[m]>
so you can clock your design at up to 60MHz
<tpw_rules>
oh dang
<adamgreig[m]>
the clock is separate to the 8 inputs and 8 outputs, and there's also 8 bidi pins too now, and you can pay a bit extra to get up to 8 analogue pins
<tpw_rules>
did you submit back in 2022?
<adamgreig[m]>
and you can now submit any gds you want so long as it passes the drc
<adamgreig[m]>
so totally custom/analogue designs are ok
<adamgreig[m]>
(since it's power gated they no longer worry about one project killing the chip I think)
<adamgreig[m]>
yea, for the original tt01 run, which never made it to the end users, but all the designs got put into tt02 which just arrived
<tpw_rules>
i'll have to think of somethig to do
<adamgreig[m]>
tempted to try and think of something for the new run because 60MHz and analogue pins is a whole different ball game
<adamgreig[m]>
like you could actually do something useful :P
<adamgreig[m]>
still 100µm x 100µm iirc, so not a ton of gates
<tpw_rules>
what voltages?
<adamgreig[m]>
but defo could fit a small mcu, or maybe I could spend it all on a capacitor and make an actual adc or dac
<adamgreig[m]>
1v8 core, 3v3 io I believe
<adamgreig[m]>
well
<adamgreig[m]>
the chip is supplied 1v8 but I don't know if it further regulates internally. 130nm process iirc
<tpw_rules>
ah i meant i/o voltage
<adamgreig[m]>
I believe fixed at 3v3 io
<tpw_rules>
can you buy 10 slots and have them all work together
<adamgreig[m]>
don't even need to "work together", you can just have one big design
<tpw_rules>
5V "absolute maximum" is a bit scary
<tpw_rules>
isn't it something like $5k for an MPW slot
<adamgreig[m]>
the chipignite service they use is nominally $10k for 100 qfn chips
<adamgreig[m]>
but they get 300 odd designs into a chip, and the chips and the carrier pcbs etc are sponsored by various companies, so in the end for early-bird submissions it's $150 for one tile including getting the chip back on a carrier pcb and with a dev board
<tpw_rules>
yeah i had seen that, was jsut curious
<adamgreig[m]>
but $150 sure is more approachable for a fun messing around project than $5k, heh
<adamgreig[m]>
admittedly now it's working it's not so different from having an ice40 qfn on a carrier board and I pretend it loaded its bitstream from flash, except it's much slower and worse, so I'm not sure I exactly learnt anything new
<tpw_rules>
just thinking the things i need small amounts of custom logic for, i would also like in a bit of quantity...
<adamgreig[m]>
usually going from fpga to asic should increase clock speeds, right :P
<tpw_rules>
yeah that too
<tpw_rules>
is it really that hard to e.g. power an ice40
<adamgreig[m]>
but nevertheless it's very fun and satisfying to see it working and imagine that my little uart decoder and sigma-delta modulator have been turned into a few doped silicon atoms
<tpw_rules>
eh just need to filter and take advantage of nyquist
<adamgreig[m]>
hah, yes, my "reconstruction filter" is just whatever random pth resistor and capacitor i could find lying around to stick into a breadboard
<adamgreig[m]>
haven't breadboarded pth parts in many years so didn't have much to pick from really
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 7aac3ed - Deploying to main from @ amaranth-lang/amaranth@09854fa77551ea68096b4e6911d4d7b73806dba5 🚀
<whitequark[cis]>
<tpw_rules> "i guess it's not possible to..." <- sorta is but i dont want to reimplement webusb on top of python-libusb
<_whitenotifier-5>
[amaranth-lang/amaranth] wanda-phi 6e06fc0 - hdl.ir: associate statements with domains.
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 40957ef - Deploying to main from @ amaranth-lang/amaranth@6e06fc013f54063afbe261787a6047c9ae1154e3 🚀
notgull has joined #amaranth-lang
<whitequark[cis]>
Wanda: oh, I just realized that MemoryInstance means both the deprecated `hdl.Memory` and the new `lib.memory` can both share a backend
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a023b9c - Deploying to main from @ amaranth-lang/amaranth@83a9149c4c6f0b2898a0557b92f033f00ecdca24 🚀
<_whitenotifier-5>
[amaranth] whitequark opened issue #1097: Consistently use "comb" for combinatorial domain instead of sometimes "comb" and sometimes None - https://github.com/amaranth-lang/amaranth/issues/1097
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] ec4d9b1 - Deploying to main from @ amaranth-lang/amaranth-soc@68c0c59f66bc23369f3eae67d3235c6b8b7e8b65 🚀
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] e9ac84d - Deploying to main from @ amaranth-lang/amaranth-soc@1e1490ef85433493b9c43050eae8925ec85b2a53 🚀
<jfng[m]>
any project depending on amaranth-soc main has broken just now :')
<jfng[m]>
CSR Register API is merged to main, docs will follow soon-ish
antoinevg[m] has joined #amaranth-lang
<antoinevg[m]>
jfng[m]: > <@jfng:matrix.org> any project depending on amaranth-soc main has broken just now :')
<antoinevg[m]>
> CSR Register API is merged to main, docs will follow soon-ish
<antoinevg[m]>
🎉
<antoinevg[m]>
Fantastic work.
<jfng[m]>
thanks!
<whitequark[cis]>
great job, JF!
<jfng[m]>
and it is time for the weekly SoC meeting
<jfng[m]>
i have nothing in the agenda, actually
<jfng[m]>
the short-term focus will now shift to documentation
<tpw_rules>
hi
<tpw_rules>
oh dang, i just updated all my stuff to use the PR
<tpw_rules>
it went smoothly
<jfng[m]>
amaranth-soc needs documentation of a similar quality as upstream amaranth, and have include diagrams etc
<jfng[m]>
tpw_rules: excellent
galibert[m] has joined #amaranth-lang
<galibert[m]>
Welcome csr api
<tpw_rules>
i had some nits about the docstrings i guess that i didn't have time to add before merge
<tpw_rules>
in particular i think csr.action.R and csr.action.W should mention the meaning of the ports without reference to FieldPort
<tpw_rules>
i also noticed that Bridges no longer have names?
<jfng[m]>
tpw_rules: agreed
<cr1901>
> any project depending on amaranth-soc main has broken just now :') <-- this is actually good for me; gives me something to procrastinate doing Sentinel refactors that I don't feel like down
<cr1901>
doing*
<jfng[m]>
tpw_rules: their name is the `name=` parameter of their `memory_map`
<tpw_rules>
how do you set that? should as_memory_map take a name?
<tpw_rules>
(i actually thought having to supply a name was a bit silly and would prefer not to, but if they still can take one it would be good to set it easily)
<tpw_rules>
ah, Builder can take one and presumably gives it to the memory map it creates
<jfng[m]>
tpw_rules: it is the name of the `csr.Builder`, that gets passed to the memory map it creates
<jfng[m]>
yeah
<jfng[m]>
i haven't put much effort in the docstrings of `csr.reg`, given that i'm going to rework them alongside the rest of the docs
<jfng[m]>
e.g. the `csr.Bridge` docstrings do not mention how the register offsets are converted to `MemoryMap` addresses
<jfng[m]>
nor does it provide examples
<jfng[m]>
csr.Builder* sorry
<jfng[m]>
unless anyone has -soc related questions, we can conclude this very short meeting
<tpw_rules>
not at the moment
<_whitenotifier-5>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-1078-83a9149c4c6f0b2898a0557b92f033f00ecdca24 - https://github.com/amaranth-lang/amaranth
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b69d290 - Deploying to main from @ amaranth-lang/amaranth@b6c5294e5031fccaf9af517c4433c94a18dd9928 🚀
<_whitenotifier-5>
[amaranth] whitequark closed issue #1097: Consistently use "comb" for combinatorial domain instead of sometimes "comb" and sometimes None - https://github.com/amaranth-lang/amaranth/issues/1097
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c281db5 - Deploying to main from @ amaranth-lang/amaranth@45dbce13dfa4e3e5a7bd6e1d9482882b5d52a1b4 🚀
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] e977956 - Deploying to main from @ amaranth-lang/amaranth@05ac36751a04c6c574f65702a4a441ed865bf69f 🚀
<nfbraun>
I'm using AsyncFIFO in an FPGA design, and Vivado gives me inter-clock timing violations between the read domain and write domain clocks.
<nfbraun>
It this expected, i.e. am I supposed to silence them (using set_false_path or whatever)?
<nfbraun>
Or am I holding it wrong?
<whitequark[cis]>
can you file an issue on this, with a minimal design, and the Vivado report included?
<whitequark[cis]>
actually, wait
<whitequark[cis]>
are the domains completely independent?
<whitequark[cis]>
i.e. no phase relationship at all?
<nfbraun>
It's a Zynq, both clocks come from the PS7, but according to the TRM, they are "completely asynchronous to each other".
<whitequark[cis]>
can you show me the report real quick?
<whitequark[cis]>
you are probably missing a set_clock_groups -asynchronous
<nfbraun>
set_clock_groups -asynchronous does indeed make the problem disappear, but it seems to hide other (real) problems as well?
<whitequark[cis]>
which real problems, and which command are you specifying?
<nfbraun>
If I do something like foo = Signal(8); m.d.clk2 += foo.eq(foo+1); m.d.sync += output.eq(foo) that's wrong, and I would like to continue to get a warning for it.
<nfbraun>
I do something like `set_clock_groups -group clk_ -group clk2_ -asynchronous`.
<whitequark[cis]>
are you looking at the output of report_cdc?
<whitequark[cis]>
that should be marked with CDC-2, i think
<tpw_rules>
i had some issues related to this sort of problem due to the resets being sort of shared in quartus. idk if it's related enough to be helpful. amaranth does try to automatically generate the timing constraints
<nfbraun>
I guess I'm only looking at the output of report_timing_summary right now (or whatever generates the _timing.rpt file).
<whitequark[cis]>
you should definitely look at the output of report_cdc to find CDC errors
<whitequark[cis]>
and in fact, I think you will need to mark the clocks as asynchronous for Vivado to not consider them related and therefore expect to need CDC there
<tpw_rules>
(didn't quite remember the details)
<whitequark[cis]>
though don't quote me on that second message
<whitequark[cis]>
tpw_rules: Xilinx platform does automatically add constraints for ResetSynchronizer
<tpw_rules>
whitequark[cis]: is this not why amaranth uses vendor sync primitives?
<tpw_rules>
it does for quartus/intel too but i think there's a quirk that amaranth does not currently address
<whitequark[cis]>
tpw_rules: for quartus? no, it uses whatever it instantiates for quartus because uh
<whitequark[cis]>
iirc, unlike with vivado, you don't get to have just an FDPE that covers every device ever designed
<whitequark[cis]>
you get like 5 different weird things depending on the family
<nfbraun>
Thanks for your input, I'll look into it.
<whitequark[cis]>
although, hm, looks like you can instantiate a DFFEAS?
<whitequark[cis]>
ok, the docs list dffe, dffea, and dffeas
<nfbraun>
The combination of `set_clock_groups -asynchronous ` and `report_cdc` indeed seems to do what I want, giving a "Warning" ("Safe") for the AsyncFIFO and a "Critical" ("Unknown") for the deliberate error.
<nfbraun>
Thanks a lot for your help!
<whitequark[cis]>
np
<Wanda[cis]>
ah yeah, the "we're definitely better than xilinx" genre of paper
<Wanda[cis]>
they did make a few of those
<whitequark[cis]>
fantastic choice of cores too
<whitequark[cis]>
"this random aes core from opencores that got removed before we finished writing"
<whitequark[cis]>
nothing screams "relevance" quite like that