01:57 <mtrbot-ml> [mattermost] <sb10q> @astro ftdi_layout_signal nSRST -data 0x2000 is in the file already, no?

01:57 <mtrbot-ml> [mattermost] <sb10q> @astro why is it "something like a power-cycling"?

02:02 <mtrbot-ml> [mattermost] <sb10q> what a fucking piece of shit

02:04 <mtrbot-ml> [mattermost] <sb10q> @astro you mean when it misbehaves you reset it with "ftdi_layout_init 0x20e0 0x3feb" and then go back to the original file?

02:04 <mtrbot-ml> [mattermost] <sb10q> well the original file also doesn't work very well because of https://git.m-labs.hk/M-Labs/zc706/issues/8

02:05 <mtrbot-ml> [mattermost] <sb10q> which is also a new issue I had not seen before

02:05 <mtrbot-ml> [mattermost] <sb10q> and btw we have an actual power cycler, please don't break this zynq stuff with e.g. i/o contention more than what it is already broken by design

02:22 <mtrbot-ml> [mattermost] <sb10q> I've just ordered a blackmagic (whitequark's favorite), hopefully that'll works better than this openocd/ftdi crap

02:22 <mtrbot-ml> [mattermost] <sb10q> it claims it supports Zynq-7000, likely we won't be able to access the FPGA part with it and only the ARM, but we can load the FPGA from the ARM

11:04 <mtrbot-ml> [mattermost] <rikstarmans> @whitequark.. will post pastebins in the future. The following [gist](https://gist.github.com/hstarmans/8bd9c49eeca4cfb5e7710779bf2060bb) produces ram which can be inferred.

11:04 <mtrbot-ml> [mattermost] <rikstarmans> It turns out that for yosys to be able to infer sram it is required that data read is marked as output in the module header. The current solution is not ideal as I am forced to mark data read as output.

11:05 <whitequark> that is not a requirement for yosys to infer a block RAM

11:05 <whitequark> why do you think it is required?

11:19 <mtrbot-ml> [mattermost] <rikstarmans> @whitequark with output sram is inferred from verilog and without output but as internal signal it is not inferred see [gist](https://gist.github.com/hstarmans/3e47fb1e8b98fa80ee046df12fc26bb0)

11:24 <whitequark> your conclusion is incorrect

11:25 <mtrbot-ml> [mattermost] <rikstarmans> :-) .. i thought you were going to say that... so why doesn't it infer sram in the second example?

11:26 <whitequark> if you do not use any logic (like if you do not read from a memory), yosys will remove that logic

11:27 <whitequark> for that matter, if your design does not have any outputs, then yosys will always remove the entire design, because it's useless

11:28 <mtrbot-ml> [mattermost] <rikstarmans> okay.. so I should add a led which is turned on if the value in the memory equals some value?

11:28 <whitequark> for example, yes

11:29 <mtrbot-ml> [mattermost] <rikstarmans> thanks will try that then..

12:16 <Astro-_> new programmer? \o/

13:17 <mtrbot-ml> [mattermost] <rikstarmans> @whitequark fixed the code and it is able to infer memory if I do something non trivial with it see my updated [gist](https://gist.github.com/hstarmans/8bd9c49eeca4cfb5e7710779bf2060bb) ..

13:17 <mtrbot-ml> [mattermost] <rikstarmans> Anyhow, I am trying to build a laser writer using a fpga. My current plan is as follows. I assume I need two SRAM blocks. Yosys does still not support dual port sram, so I plan to mitigate this with two srams. To the first sram block I write data via SPI. From the second SRAM I read data. If the laser is finished with the second SRAM it proceeds with the first SRAM.

13:17 <mtrbot-ml> [mattermost] <rikstarmans> The host continuously tries to write to the sram as fast as possible. The fpga signals if data is accepted, if not the host writes the data again. I assume the writing from the SPI is faster than the reading from the laser.

13:17 <mtrbot-ml> [mattermost] <rikstarmans> Would you go for a design with two sram blocks or is there an other option?

13:17 <mtrbot-ml> [mattermost] <rikstarmans>

13:17 <mtrbot-ml> [mattermost] <rikstarmans>

13:19 <whitequark> it does support dual port BRAMs

13:19 <whitequark> what it doesn't support is what's called "true dual port BRAM", which iCE40 does not have anyway

13:26 <mtrbot-ml> [mattermost] <rikstarmans> True, read that [here](https://github.com/YosysHQ/yosys/issues/1101) that's why i was confused. Okay, so I will try to infer a dual port SRAM block with two ports.

13:26 <mtrbot-ml> [mattermost] <rikstarmans> What would be the best way to signal the host, in my case a raspberry, the FPGA is ready for new data; by returning bytes over SPI or by flipping a pin or doesn't it matter?

13:45 <mtrbot-ml> [mattermost] <sb10q> @astro is the zc-10 also exhibiting this bug btw?