<conventia[m]>
I think I've read most of that page, though perhaps I don't quite grasp the consequences yet. 🙂
<whitequark[cis]>
so basically if you use a comb read port, the memory will synthesize to a big multiplexer on ice40, like if it was an Array
<whitequark[cis]>
this is completely untenable for large memories, but it gives you the 0-cycle delay that you can't get from a BRAM
<conventia[m]>
Interesting. I'm comparing the amaranth code with the verilog with inferred memory and it seems like the verilog is using asynchronous ram.
<whitequark[cis]>
there is no such thing as "asynchronous ram"
<whitequark[cis]>
well, not in an FPGA
<whitequark[cis]>
block RAM is always synchronous; everything that is asynchronous must be synthesized to logic elements
<conventia[m]>
Oh, perhaps it works because it's using a different clock.
jjsuperpower__ has joined #amaranth-lang
<whitequark[cis]>
anyway, to continue answering your question: people usually use comb read ports when they really need that timing budget; so often the CPU register file will use a "comb" memory
<whitequark[cis]>
in almost every other case, the space savings from using a block RAM and not having to waste logic elements on memory are vastly preferred to the small 1-cycle latency that you can often fold into other delays
jjsuperpower_ has quit [Ping timeout: 248 seconds]
<conventia[m]>
I'm mostly just curious (for educational purposes) why the verilog version seems to work fine without 1-cycle latency whereas the amaranth version doesn't. Though, the logs don't seem to give enough info to figure this out at my level of knowledge. 🙂
<whitequark[cis]>
it's probably some other difference
<whitequark[cis]>
i would expect that if you had an accurate translation of the verilog version into amaranth it would work the same way
<whitequark[cis]>
(if not it's a bug)
<conventia[m]>
That's my goal, an accurate translation. But it seems not for the faint of heart.
<whitequark[cis]>
it's a fairly challenging first project, yeah
<whitequark[cis]>
I keep wanting to write a Verilog-to-Amaranth correspondence table for people coming from Verilog but not enough time...
<conventia[m]>
I am glad that amaranth is so much easier to use, though.
<conventia[m]>
Does the playground let you run testbenches and see the waveforms?
<whitequark[cis]>
yes
<whitequark[cis]>
the default playground script has the code that displays waveforms, and it has a testbench too
<conventia[m]>
Sorry, I forgot that there was a ? tab. 😛
<conventia[m]>
Just curious, given a synchronous memory, is this the best you can do in terms of cycles, given that both addr and result are registers and you want the next addr to depend on result?
<whitequark[cis]>
you can advance the increment one cycle
<conventia[m]>
Not if it depends on result?
<whitequark[cis]>
whenever you increment addr, that becomes visible on the next cycle. if on that cycle you also do m.d.comb += rd.addr.eq(addr + 1), then you'll do the fetch and increment in parallel
<conventia[m]>
Basically, minimize time to first read and cycle clock count.
<conventia[m]>
Anyways, thanks for the help.
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #amaranth-lang
<benny2366[m]>
quick question , is there a way to have the Language guide availble as a pdf?
<whitequark[cis]>
try print-to-pdf
<zyp[m]>
sphinx can also output to pdf
<whitequark[cis]>
not with amaranth (the wavedrom role is only defined for html)
Psenteee has quit [Quit: Off]
Psentee has joined #amaranth-lang
Psentee has quit [Quit: Off]
Psentee has joined #amaranth-lang
whitequark[cis] has quit [Quit: Reconnecting]
whitequark[cis] has joined #amaranth-lang
whitequark[cis] has quit [Client Quit]
whitequark[cis] has joined #amaranth-lang
benny2366[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
duskwuff[m] has quit [Quit: Bridge terminating on SIGTERM]
miek__[m] has quit [Quit: Bridge terminating on SIGTERM]
zyp[m] has quit [Quit: Bridge terminating on SIGTERM]
conventia[m] has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
ydnatag[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #amaranth-lang
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #amaranth-lang
annabelle_adelai has joined #amaranth-lang
annabelle_adelai has quit [Quit: Ping timeout (120 seconds)]
annabelle_adelai has joined #amaranth-lang
Guest6830 has joined #amaranth-lang
zyp[m] has joined #amaranth-lang
<zyp[m]>
Is there a meeting today?
whitequark[cis] has joined #amaranth-lang
<whitequark[cis]>
oh, sorry, I think I'm too tired
annabelle_adelai has quit [Quit: Client closed]
Guest6830 has quit [Remote host closed the connection]
<qookie>
am i being silly? am i blind or is this documented somewhere? i am using a Resource with two DiffPairs subsignals to represent a hdmi output, and i'm driving it at ddr by specifying `xdr={"clk": 2, "data": 2}` to `platform.request()`, but i need to manually drive hdmi.clk.o_clk=ClockSignal("hdmi")? i would've expected to have to pass the clock domain somewhere instead
<qookie>
`o_clk` is not mentioned anywhere in the docs as far as i can see, and i only figured it out by looking at the impl of `amaranth.build.res.PinBuffer`
<whitequark[cis]>
that entire part of the language is deprecated (you should've got a warning) because it is terribly designed
<whitequark[cis]>
please save yourself a lot of headache by using amaranth.lib.io, which is extensively documented
<whitequark[cis]>
the only non-deprecated way to use request() is with dir="-", which gives you an IOValue you pass to io.Buffer/FFBuffer/DDRBuffer. those use the domain system as normal
<qookie>
ah i see, good to know, thanks
<qookie>
i haven't gotten a deprecation warning but perhaps that's because i'm using amaranth 0.5.4 and not 0.6.0 from git?
<whitequark[cis]>
try running python with PYTHONWARNINGS=all
<whitequark[cis]>
or -Wdev
<whitequark[cis]>
something like that
<qookie>
ah yeah i see them now
<qookie>
(with the env var)
<whitequark[cis]>
we really should add this to some part of the manual
<qookie>
while i'm asking questions, is there a way to feed in an extra verilog file when generating cxxrtl?
<whitequark[cis]>
not sure where tho
<qookie>
i saw that there is a way to feed in rtlil but saw no way to turn verilog input into rtlil without poking at amaranth._toolchain.yosys myself
<whitequark[cis]>
re: cxxrtl: that part is a bit unfinished, feel free to poke at the code, we never merged a better solution due to prioritization shift
<whitequark[cis]>
oh, yeah, you can use uh... amaranth-yosys or yowasp-yosys to convert verilog to rtlil
<whitequark[cis]>
speaking of which i should add yosys-slang support to yowasp-yosys
<qookie>
yeah that's what i meant by poking at _toolchain.yosys, using it to automatically figure out what yosys to use
<whitequark[cis]>
mm yeah
<qookie>
i assume it's not intended to be used by the end user due to the underscore prefix in the package name
<qookie>
hence the question
<whitequark[cis]>
formally that is an internal module, and our policy is that these change without warning
<whitequark[cis]>
practically speaking though that one is not exported just to avoid baking in a perma dependency on yosys