<charlottia>
I see that Memory's docstring states "Uninitialized memories are not currently supported." Nevertheless, I was a bit surprised that the difference between a ~4KiB Memory without init (which I guess just means zero-init) and one with actual data was exactly -1 SB_LUT4 for the variant with data! I'm assuming this is just due to chance optimisation?
<charlottia>
I was hoping to save logic by reading ROM data out of SPI flash into a Memory, but it just got bigger! :3
<galibert[m]>
probably depends a lot on the fpga
<galibert[m]>
In the semantics of the language, you can't write the same signal on two different domains, but you can read it on different domains, right?
<galibert[m]>
Yeah, otherwise it wouldn't be possible to do any CDC in the first place
<charlottia>
(I see too that this is probably fundamental; I tried omitting the $meminit cell entirely and the cell counts increased again. :) I'm guessing there's just no omitting the initial state in the bitstream.)
<galibert[m]>
in the cyclonev the initial values of m10k and mlabs are in the bitstream no matter what. When the memory in synthesized from FFs is gets more interesting because the poweron/async reset state is fixed 0, so a non-zero requires inverters or propagating the inversion
<Sarayan>
(ping test)
<galibert[m]>
ok, discord on one side and (irc, matrix) on the other are disconnected
<charlottia>
<galibert[m]> "In the semantics of the language..." <- I think this makes intuitive sense if you omit CDC for a moment and think about just `comb` and `sync` as an example. Signals can be driven by only one, but their values can be derived from anywhere.
<galibert[m]>
How can I pysim-simulate a system running on two phase-opposite domains? Or should I have only one domain and use two explicit enables instead in the current state of the code?
<galibert[m]>
I have a system with a 33.8688MHz clock and a dual-edge 16Mhz (hence 32) clock, I guess the best is to just plonk an enable on the 33.8 to get close enough to 32
<mwk>
galibert[m]: you can add multiple clock signals in pysim, it should work
<galibert[m]>
ok, gonna need to try that
<galibert[m]>
also, is there a way to have memories in your testbench but not have them instanciate as millions of signals in the vcd?
<mwk>
charlottia: generally most FPGAs support initialized memory (though it depends on both FPGA and memory kind; eg. on Ultrascale+ you can't init ultraram); whether it's free or not depends on FPGA and bitstream mode
<mwk>
galibert[m]: wrt vcd, nothing ready-to-use AFAIK, though you can roll something yourself by using simulate=False on the memory and replacing it with something manually coded as a pysim coroutine
<galibert[m]>
ok, simpler not to use a Memory and bring up the signals so that the sim can act on them then
<galibert[m]>
Thy don't even need to be up, the sim that reach down
<galibert[m]>
(22Megs of rom, 128k of ram)
<galibert[m]>
(vcd file size and simulation times blew up)
<galibert[m]>
s/Thy/They/, s/that/can/
<charlottia>
<mwk> "charlotte: generally most..." <- right, thank you! I figure I’ll tackle SPRAM next and see how hard that is to get going :)
<mwk>
ice40 SPRAM? that one has no init capability at all
<galibert[m]>
Hmm, implemented a cpu is complicated, who would have thought that?
crzwdjk has joined #amaranth-lang
<crzwdjk>
charlottia: SPRAM is pretty easy to get going, you just need to create an Instance and you can look at Verilog examples for how to us it. I wrote a pretty concise demo that's like 20 lines for a blinky (writing some data to SPRAM and then blinking LEDs based on data read back from it)
crzwdjk has quit [Quit: Client closed]
sauce has quit []
sauce has joined #amaranth-lang
<mwk>
these days yosys should be capable of infering an SPRAM too, if you ask nicely
<mwk>
Memory(..., attrs={"ram_type": "huge"}) should do it, I think?
<mwk>
er
<mwk>
Memory(..., attrs={"ram_style": "huge"})
<FL4SHK>
that is good information for my exploits
<FL4SHK>
hopefully that'll work for Xilinx FPGAs too
<FL4SHK>
though with other "ram_style"s
<FL4SHK>
hoping to write an SDRAM controller
<FL4SHK>
not now
<FL4SHK>
It'd be cool if I could do that though, after all these years, finally being able to use SDRAM as main memory for a project
<FL4SHK>
note that I don't mean any kind of DDR
<FL4SHK>
...though I want to do that as well
<charlottia>
<mwk> "Memory(..., attrs={"ram_style":..." <- Thanks so much! I'm trying this approach now.