Wednesday, 2019-02-06

*** tpb has joined #yosys00:00
*** dpiegdon has quit IRC00:30
*** jevinskie has joined #yosys00:43
*** jevinskie has quit IRC01:02
*** cr1901_modern has quit IRC01:26
*** pthomas has joined #yosys01:27
*** cr1901_modern has joined #yosys01:28
*** gsi__ has joined #yosys02:29
*** gsi_ has quit IRC02:33
*** cr1901_modern has quit IRC03:07
*** emeb_mac has joined #yosys03:11
*** cr1901_modern has joined #yosys03:17
*** jevinskie has joined #yosys03:17
*** tlwoerner has quit IRC03:40
*** tlwoerner has joined #yosys03:41
*** leviathanch has joined #yosys04:19
*** _whitelogger has quit IRC04:37
*** _whitelogger has joined #yosys04:39
*** dys has quit IRC04:47
*** rohitksingh_work has joined #yosys05:17
*** proteusguy has quit IRC05:22
*** seldridge has joined #yosys05:26
*** srk has quit IRC05:27
*** srk has joined #yosys05:31
*** _whitelogger has quit IRC05:40
*** _whitelogger has joined #yosys05:42
*** rohitksingh_work has quit IRC05:53
* MoeIcenowy considering whether I should buy a UPduino206:08
*** rohitksingh_work has joined #yosys06:12
*** rohitksingh_work has quit IRC06:28
*** proteusguy has joined #yosys06:47
*** seldridge has quit IRC06:55
*** emeb_mac has quit IRC06:57
*** proteusguy has quit IRC07:12
*** proteusguy has joined #yosys07:13
*** dys has joined #yosys07:21
*** dys has quit IRC07:39
promach_Why passed yosys bmc base-case test but failed in iverilog simulation ?08:50
tpbTitle: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at
MoeIcenowypromach_: I don't think iverilog supports SV08:54
promach_it does have systemverilog support, check -g 2012 option
tpbTitle: Iverilog Flags | Icarus Verilog | FANDOM powered by Wikia (at
MoeIcenowypromach_: "Actual SystemVerilog support is ongoing."09:26
MoeIcenowyif you enable -g 2012, it will enable the check for SV keywords, but no real SV support is present09:27
*** finnb has joined #yosys09:34
*** citypw has quit IRC10:40
*** citypw has joined #yosys10:52
*** finnb has quit IRC11:38
promach_MoeIcenowy: ok, but why does cover(in_valid) failed ?
tpbTitle: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at
*** s_frit has quit IRC12:01
*** s_frit has joined #yosys12:02
*** leviathanch has quit IRC13:23
*** _whitelogger has quit IRC13:55
*** _whitelogger has joined #yosys13:57
MoeIcenowyI'm not familiar with formal verification...13:58
sorearall I know is that formal verification is infamous for not working with multipliers14:04
ZipCPUpromach_: You are trying to verify a synchronous multiply.  Why would you ever set "multiclock on"?  or use $global_clock ?14:18
*** jevinskie has quit IRC14:29
promach_ZipCPU: ok14:48
promach_but why error : Unsupported cell type $dffsr for cell14:49
promach_I have no code line number indicated in the error log14:49
ZipCPUWith or without multiclock?14:49
ZipCPUYou have a latch within your design, or an always block with something other than the clock within it14:50
ZipCPUand by "within it" I mean something other than the clock in the sensitivity list14:50
promach_yes, reset14:50
promach_I have updated the gist14:50
ZipCPUCheck your always @(*) blocks for values that aren't always set too.  Those can infer latches which will get in the way of things as well.14:54
promach_the multiply code does not have any always @(*) blocks14:55
ZipCPUHave you gotten rid of your $global_clock block?14:55
promach_yes, already gotten rid of your $global_clock block14:56
promach_yes, already gotten rid of my $global_clock block14:56
ZipCPUSounds good.  Is it building now?14:56
promach_no, still  error : Unsupported cell type $dffsr for cell14:56
daveshahDo you have any `posedge clk, posedge reset`s left?14:59
promach_daveshah: what is wrong with  always @(posedge clk, posedge reset)  ?15:00
daveshahThat is an async reset which creates the $dffsr15:00
promach_and ?15:01
daveshahIf you don't want to use multiclock, you have to have sync resets15:01
ZipCPUYou don't need them: you are buiding/testing a multiply15:01
qu1j0t3.b 3415:01
promach_daveshah ZipCPU: ok, it is building now using your suggestion15:03
promach_but cover(in_valid) still fail  :|15:03
ZipCPUWhat's your top-level?15:04
promach_module multiply()15:04
ZipCPUmultiply.v, and in_valid is an input to multiply.v?  Check your assumptions.15:04
promach_module multiply(clk, reset, in_valid, out_valid, in_A, in_B, out_C);15:04
promach_ZipCPU: just checked, nothing to do with the assumption related to in_valid15:05
ZipCPULook harder15:06
*** leviathanch has joined #yosys15:07
*** rohitksingh has joined #yosys15:09
promach_I commented out this line , but cover(in_valid) still fail :|15:12
tpbTitle: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at
sxpertZipCPU: am progressing at a good pace here. small question though, what's the proper way to optimize a state machine ?15:30
ZipCPUsxpert: Normally the tools will do that for you15:31
ZipCPUBut the answer is also state machine dependent15:31
ZipCPUThe biggest thing you can do is to reduce the size of the state space15:31
sxpertZipCPU: yeah, I saw that, but it takes a while to reduce all states15:32
sxpertah, so recode the states with smaller numbers. ok15:32
ZipCPUWell ... yes/no15:32
ZipCPUSmaller size, but it may use more signals15:32
ZipCPUMany synthesizers will recognize a state machine, and automatically switch the encoding to a one hot encoding15:33
ZipCPU... where there's one signal that's high for every possible state in the space15:33
ZipCPUI like to optimize my state machines by working my way through my always blocks, and trying to minimize the number of input wires needed to determine the input of any FF15:34
sxpertso, instead of having one extra large always @(posedge clk), make plenty of tiny ones ?15:35
*** emeb has joined #yosys15:41
sxpertor have I misunderstood?15:42
ZipCPUsxpert: No, you aren't misunderstanding me15:46
ZipCPUThat's what I do all the time.  It's a style of mine, but that's why I do it15:47
sxpertleads to smaller things ? or just a writing style ?15:48
sxpertah, clearly I'm doing something wrong ;)15:50
sxpertI'm getting an insult about combinatorial loops...15:51
tpbTitle: Info: Annotating ports with timing budgets for target frequency 5.00 MHz Info - (at
sxperthah, found my mistake16:05
ZipCPUsxpert: Have you found this link:
tpbTitle: Minimizing FPGA Resource Utilization (at
ZipCPUIt sort of goes over my thoughts on logic minimization16:06
* shapr snickers at "byte the bullet"16:09
sxpertZipCPU: yeah, I have read it, but I suspect this may come at a later stage, as I want something functional first16:11
* ZipCPU offers shapr a .45, in case he wants to try it16:12
* ZipCPU figures a 0.45 is roughly an 0x73 in "byte" form16:14
*** AlexDaniel has joined #yosys16:22
* sxpert learns that sometimes things declared as reg should be wires16:30
ZipCPUInputs should always be declared as wires, ex: input wire i_clk;16:31
ZipCPUOutputs from submodules should always be declared as wires16:32
ZipCPUAnything with an assign statement should always be declared as a wire.16:32
shaprZipCPU: I prefer 9mm, easier to fund for practice16:38
* ZipCPU tries to convert 9mm to a byte representation16:38
* ZipCPU figures a 9mm in "byte" form is roughly an 8'h5b16:39
shaproh man16:39
*** lutsabound has joined #yosys16:42
*** supervacuus has joined #yosys17:26
*** m4ssi has quit IRC17:30
*** supervacuus has quit IRC17:32
*** FL4SHK has joined #yosys18:02
*** gsi__ is now known as gsi_18:31
*** m4ssi has joined #yosys18:58
*** lutsabound has quit IRC19:02
*** rohitksingh has quit IRC19:06
emebZipCPU: what's the rationale for "Outputs from submodules should always be declared as wires"?19:10
*** fsasm_ has joined #yosys19:10
emebI guess you mean they need to be wires in the higher level module.19:15
ZipCPUemeb: Yes, that's exactly what I mean19:16
ZipCPUIf module top has module sub beneath it, then within module top sub's outputs need to be declared as wires19:16
ZipCPUWithin module sub, they can be declared as either--depending on how you want them to behave19:16
emebMakes sense. I remember long ago we had some Verilog tools that wouldn't let you take a reg straight out of a module. You had to assign it to a wire before going out.19:17
ZipCPUMy flavor of Verilog is rather ancient ... I'm surprised, though, I didn't realize there was something more ancient :D19:18
emebZipCPU: Well, this was like 25yrs ago. :P19:19
ZipCPU.... and?  ;)19:19
emebVHDL has something like that - it won't let you use an output signal in the module that creates it. You have to reassign it to something else.19:20
emebdon't know what the advantage of that is from a language standpoint.19:21
daveshahIt avoids the issue that reading an `output` has different behaviour to reading an `inout`19:22
daveshahiirc VHDL also has a `buffer` type that behaves like a Verilog `output`19:23
emebHmm... never used that.19:23
emebSpeaking of strange languages - did anyone here ever use a language called "Module Compiler"? This was something that Synopsys acquired & sold for a while back in the late 90's. I got pretty good at using it for DSP stuff. It looked sort of like Verilog but did all the pipeline balancing and much of the math at a high level.19:26
emebI suspect that today a lot of what it did is handled in plain Verilog through more advanced inference, but it was like magic at the time.19:27
*** leviathanch has quit IRC19:29
*** seldridge has joined #yosys19:29
emeblol - I google for Module Compiler and find an old promotional article  that quotes me ->
tpbTitle: Synopsys' Module Compiler Slashes Design Time and Boosts Performance of SiCOM's New Broadband Wireless Modem (at
*** seldridge has quit IRC19:48
*** seldridge has joined #yosys19:52
*** seldridge has quit IRC20:15
*** m4ssi has quit IRC21:09
*** fsasm_ has quit IRC22:27
*** utzig has quit IRC22:49
*** utzig has joined #yosys22:50

Generated by 2.13.1 by Marius Gedminas - find it at!