<cr1901>
Okay, back from prior engagement... let's see... I owe charlotte an issue, wq a PR, and I better look at the sim RFC
<cr1901>
Anything else I missed?
<cr1901>
mcc111[m]: Would you be willing to rejoin #openfpgaloader when you get the chance? I can probably explain what's going on
Degi has quit [Ping timeout: 260 seconds]
<cr1901>
re: the issue you opened 4 days ago. I've been pretty much away from a computer since Thursday afternoon, so I couldn't respond while you were there
<mcc111[m]>
<cr1901> "mcc111: Would you be willing..." <- Sure… wait, does openfpgaloader have an Element bridge? The reason I joined then disappeared was I was using irccloud
<mcc111[m]>
<cr1901> "mcc111: Would you be willing..." <- Note, I no longer need openfpgaloader since I successfully got ecpdap working. So if you explained to me what I needed to do I would politely listen but probably not actually install openfpgaloader at this time. Also your explanation in the github was helpful by itself.
sugarbeet has quit [Ping timeout: 245 seconds]
sugarbeet has joined #amaranth-lang
<cr1901>
I don't think OFL uses the element bridge, and ack re: the GH explanation
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 87e0e51 - Deploying to main from @ amaranth-lang/amaranth@c9416674d1e89b0537870d80588ee34b8cd12097 🚀
<adamgreig[m]>
Catherine: maybe I'm misunderstanding how add_testbench would be used, but it feels like I'd be calling it with `domain="sync"` like 95% of the time anyway; maybe adding an `add_sync_testbench()` would make sense? I read the comment about defaulting domain to `sync` in the RFC but didn't really understand why you couldn't default it anyway; callers could always explicitly set it to None or comb or something
<Chips4MakersakaS>
Regarding Amaranth simulation I think I get it now. I think my main origin of confusion was that in cocotb yield in the simulation is used exclusively for time advancement and in Amaranth it is also used for assignments and reading values of signals. So I was looking at Amaranth test benches with a cocotb mind set which is not a good ting (tm). Especially the use of yield without any argument in Amaranth test benches
<Chips4MakersakaS>
confused me.
<galibert[m]>
If I understand correctly (but I may not) bare yield in add_sync_process is equivalent to yield Tick("sync") in add_process
<whitequark[cis]>
adamgreig: this is true; that's one change I am amenable to
<Chips4MakersakaS>
So I think I can now approve RFC we discussed yesterday. Personally I would even advocate to in the end settle combinatorial logic in all testbenches automatically after inputs or regsiter change during simulation; not only for add_(sync_)testbench().
<whitequark[cis]>
Chips4Makers (aka Staf Verhaegen): that would mean entirely removing `add_sync_process` and making certain patterns (replacing Amaranth netlists with behavioral implementation) impossible
<whitequark[cis]>
so for example this makes replacing an UART with something that behaviorally implements an UART impossible.
<whitequark[cis]>
(settling automatically)
<Chips4MakersakaS>
Why ?
<whitequark[cis]>
it causes race conditions; please do take a look at yesterday's comments on this topic and let me know if it's still unclear
<Chips4MakersakaS>
Is there example of behavioral Amaranth simulation model that would cause race conditions race conditions with automatic settiling of combinatiorial logic ?
<Chips4MakersakaS>
So I can have a look. I do indeed don't see ATM why behavioral models can't be race free and still have automatic logic settling.
<Chips4MakersakaS>
s/race conditions//
<galibert[m]>
I have similar questions, I don't see how you can have a race without some kind of combinatorial loop
<Chips4MakersakaS>
I do know that there are Verilog and VHDL behavioral models that depend on the internal simulation model with delta cycles etc to work properly. But I don't think these should apply to Amaranth simulation behavioral models. I do think in Amaranth we should be able to align everything on rising/falling edges or other events.
<whitequark[cis]>
galibert: it indeed relates to comb feedback
<whitequark[cis]>
which is something that is possible with even a bus like Wishbone
<galibert[m]>
But comb loops are bug in amaranth, right? Currently UB, eventually hard error ?
<whitequark[cis]>
comb feedback != comb loop
<galibert[m]>
Unless you have a comb that goes into a domain as a clock, I still don’t see how anything can race
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 260 seconds]
jjsuperpower has joined #amaranth-lang
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 272 seconds]
<mcc111[m]>
Is anyone familiar with these things? They're all over ebay and seem to be cheaper than even the Nano 9k kit https://hackaday.com/tag/pano-logic/
<mcc111[m]>
The fact they're old and discontinued is a big blinking "do not approach" sign but I'm still curious lol
<whitequark[cis]>
that's a spartan-6
<whitequark[cis]>
you'll need to use a programming environment so old the windows 10 version is a vm with rhel5 or something inside
<mcc111[m]>
ok good to know never mind then
<whitequark[cis]>
they're really old
<mcc111[m]>
… i mean it's not that i'm opposed to running linux in a vm, just…
<whitequark[cis]>
spartan 6 was kind of old in 2013
<whitequark[cis]>
mcc111: trust me it's not a great experience
<whitequark[cis]>
i think you can use amaranth remote builds to automate it
<zyp[m]>
IIRC there were somebody in #litex playing with them a while ago, but I didn't bother looking too closely because of the tool situation
<zyp[m]>
code pattern question: let's say I've got a stream block that performs some operation with a few cycles of latency, and then I've also got some fields in the stream that's unrelated to the current operation, but that needs to tag along
<zyp[m]>
consider e.g. a multiplier block that's multiplying ADC samples by some gain, and the ADC channel numbers needs to tag along
<whitequark[cis]>
tag along how?
<zyp[m]>
the multiplier block doesn't care about the channel number, but downstream blocks still needs to know which channel the multiplication result belongs to
<whitequark[cis]>
I'm thinking some kind of split/join/delay operation
<zyp[m]>
I figure there's two obvious solutions to this; the first is to have the block take a constructor argument that describes extra data to pass along
<zyp[m]>
and the other is unzip/buffer/zip blocks, yes
<crzwdjk>
Consider a VGA sync generator that generates the horizontal/vertical counter, and also hsync/vsync signals. Downstream of that there's some logic to fetch stuff from memory, maybe composite some stuff, that takes a couple cycles. The hsync/vsync "tag along" and need to be delayed by the same amount as the processing takes.
<zyp[m]>
yeah
<crzwdjk>
Seems like a pretty common thing, maybe it makes sense to have it as a library function.
<whitequark[cis]>
that's something I would put into lib.stream, yeah
<crzwdjk>
In the meantime it's something I should probably pull out into a library function in my own code
<zyp[m]>
I figure the first approach of passing it through each block is potentially cheaper than a separate buffer since it can tie into the existing buffering logic, but more hassle to implement since it has to go into every single block that can be used that way
<zyp[m]>
whereas the second approach would work with arbitrary blocks
<zyp[m]>
as long as they're lossless
<whitequark[cis]>
would it really be cheaper?
<adamgreig[m]>
for a lot of the situations I had like this, I have a bram in the path, so the bram absolutely stores the tags alongside the data being processed, otherwise I'd need two brams
<adamgreig[m]>
helps when the brams are often 9 or 18 bits wide or whatever so for bytes you have a little extra space
<adamgreig[m]>
no use if the bram is already the perfect width of course
<whitequark[cis]>
where does BRAM fit here?
<whitequark[cis]>
as in, can you not buffer before/after?
<adamgreig[m]>
yea, for the parts that are just going through register pipelines or small skid buffers or whatever I suppose it doesn't make a difference if it's directly alongside or in some parallel track with the same latency
<whitequark[cis]>
yeah that's the idea, that you usually don't do BRAM+computation in one block
<whitequark[cis]>
and where you do I suppose that would be some list of tags yeah
<adamgreig[m]>
I guess it can make a difference, if you basically end up instantiating two skid buffers then the control logic is duplicated
<adamgreig[m]>
which is exactly what zyp said, I see, lol
<whitequark[cis]>
that can probably be merged by the toolchain
<whitequark[cis]>
and if not we need better toolchains
<zyp[m]>
what if you've got two or more blocks that the signal will be bypassing?
<whitequark[cis]>
are you sure this optimization actually pays its weight in the few flops it saves?
<zyp[m]>
no
<whitequark[cis]>
duplicating that logic won't impact your critical path and flops are cheap
<whitequark[cis]>
trying to shove around stuff to eke out minimal gains is expensive in bugs
<whitequark[cis]>
I'd want to see a justification for putting this much work into something before even considering it
<whitequark[cis]>
and it's not even elegant
<whitequark[cis]>
(see you tomorrow)
<zyp[m]>
what I see as the potentially larger problem is that the user needs to keep track of the internal latencies of the blocks to ensure the bypass buffer is large enough
sporniket has joined #amaranth-lang
sporniket has left #amaranth-lang [#amaranth-lang]
sporniket has joined #amaranth-lang
sporniket has left #amaranth-lang [#amaranth-lang]
richlatticefae[m has joined #amaranth-lang
<richlatticefae[m>
Hi everyone. What dose amaranth do for basic VHDL 2008 linting? I found VHDL tool online but the website is giving me a warning.
<whitequark[cis]>
Amaranth is entirely unrelated to VHDL 2008
bob_twinkles[m] has joined #amaranth-lang
<bob_twinkles[m]>
amaranth doesn't do anything with VHDL as far as I'm aware?