00:44 <mtrbot-ml> [mattermost] <sb10q> I just notice that it seems to work without build.rs and I don't understand what it does...

00:46 <mtrbot-ml> [mattermost] <sb10q> moving things into the lib sounds good anyway, then they don't need to be copied into projects using zc706

00:49 <mtrbot-ml> [mattermost] <sb10q> any idea about this?

03:05 <mtrbot-ml> [mattermost] <sb10q> this time, the reason it wasn't working is because I had the port open. just use ps aux/kill in those cases

03:06 <mtrbot-ml> [mattermost] <sb10q> okay this is fixed now - thanks!

03:07 <mtrbot-ml> [mattermost] <sb10q> though I don't see a corresponding code change - could it be what you did to the ttyUSB device?

08:36 <stroboko1p> hi, I have a small design with minverva as a core and I have a bug somewhere in the chain: the WishboneArbiter component in minerva/wishbone.py, nmigen, yosys, or even Xilinx XST synthesis..

08:37 <strobokopp> I was able to work around it but maybe you can help me narrow it down so I can open a proper bug report

08:37 <mtrbot-ml> [mattermost] <sb10q> stroboko1p: here's a full working example for a soc: https://git.m-labs.hk/m-labs/heavyx

08:37 <mtrbot-ml> [mattermost] <sb10q> what was the workaround?

08:38 <strobokopp> I rewrote the WishboneArbiter in nmigen, it doesn't use the priority encoder but has just two fixed ports

08:41 <strobokopp> the issue was that before synthesis, both simulations in pysim and Xilinx ISim were fine but after synthesis ("SImulate Post-Translate Model" in Xilinx ISE) the arbiter was broken

08:48 <strobokopp> now I'm not accustomed to verilog so it's hard to read, but I compared the two outputs from the two different arbiters. The broken one has always blocks doing this: casez(bus_pe_o) 1'h0: bus__adr = port__adr; 1'hz: bus__adr = \port__adr$1;

08:49 <strobokopp> the 1'hz looks wrong to me, and the working verilog code has 'default:' instead

08:53 <strobokopp> HeavyX looks interesting btw. Wait, it can incorporate SPinalHDL code as well? seeing VeXRiscv

08:54 <mtrbot-ml> [mattermost] <sb10q> yes

08:55 <mtrbot-ml> [mattermost] <sb10q> to an extent

09:22 <strobokopp> cool, I'll have a closer look. in the meantime I have some verilog output from the broken & working designs that maybe someone is curious enough to have a look at :)

09:22 <strobokopp> broken: https://pastebin.com/nyRYsms5

09:22 <strobokopp> working: https://pastebin.com/GtvSscvg

09:23 <strobokopp> my simple alternative arbiter code: https://pastebin.com/0M2vFz8w

09:24 <strobokopp> as I said I'm not good in verilog so I can't really tell if it's actually broken or not. and if it is, how would I find out if it's a bug in yosys or nmigen?

09:26 <strobokopp> I also saw https://github.com/lambdaconcept/minerva/commit/8c4d4eb3f74786bc44a721a9c9ce28cf37ee8cf4#diff-2332826518ff01a93fb46343a4a10a42 which I haven't tested yet btw.

09:58 <strobokopp> The results above are from yosys 0.9. I also tried the latest yosys from Git:

09:59 <strobokopp> (1) I have to manually fix "module i_sync_reset" in verilog, otherwise ISE complains: e

09:59 <strobokopp> e

10:00 <strobokopp> (middle-click pasting doesn't work well right now)

10:00 <strobokopp> No signals referenced in statement with implicit sensitivity list

10:04 <strobokopp> (2) design is still broken, verilog code changed a bit, notably the casez(bus_pe_o) statenent changed from 1'hz: to 1'h?:

10:54 <mtrbot-ml> [mattermost] <alexist> Execuse me... May I ask one more question...?

12:14 <mtrbot-ml> [mattermost] <sb10q> @alexist go ahead

12:26 <mtrbot-ml> [mattermost] <alexist> Based on git hub explanation, I thought there is no built-in DDS chip on Kasli. And only Urukul can perform DDS, and only Kasli can be used for DRTIO. Is it right...? I am not sure whether I can use AD9912 as DDS or kc705 as satelite which have been used in our laboratory with Kasli...

12:27 <mtrbot-ml> [mattermost] <sb10q> ad9912 on urukul can be used with kasli

12:27 <mtrbot-ml> [mattermost] <sb10q> kc705 as satellite is not supported, but theoretically doable

12:31 <mtrbot-ml> [mattermost] <alexist> Ah ha! Then should we modify gateware code to use kc705 as satelite? Or need other hardware to implement that?

12:32 <mtrbot-ml> [mattermost] <sb10q> no other hardware needed, but this is a nontrivial gateware project

12:32 <mtrbot-ml> [mattermost] <sb10q> probably more economical to get a kasli, unless your goal is to learn how to implement DRTIO on a new FPGA

12:35 <mtrbot-ml> [mattermost] <alexist> Ah ha! really thanks for kind explanation! :)