| *** tpb has joined #yosys | 00:00 | |
| *** dpiegdon has quit IRC | 00:30 | |
| *** jevinskie has joined #yosys | 00:43 | |
| *** jevinskie has quit IRC | 01:02 | |
| *** cr1901_modern has quit IRC | 01:26 | |
| *** pthomas has joined #yosys | 01:27 | |
| *** cr1901_modern has joined #yosys | 01:28 | |
| *** gsi__ has joined #yosys | 02:29 | |
| *** gsi_ has quit IRC | 02:33 | |
| *** cr1901_modern has quit IRC | 03:07 | |
| *** emeb_mac has joined #yosys | 03:11 | |
| *** cr1901_modern has joined #yosys | 03:17 | |
| *** jevinskie has joined #yosys | 03:17 | |
| *** tlwoerner has quit IRC | 03:40 | |
| *** tlwoerner has joined #yosys | 03:41 | |
| *** leviathanch has joined #yosys | 04:19 | |
| *** _whitelogger has quit IRC | 04:37 | |
| *** _whitelogger has joined #yosys | 04:39 | |
| *** dys has quit IRC | 04:47 | |
| *** rohitksingh_work has joined #yosys | 05:17 | |
| *** proteusguy has quit IRC | 05:22 | |
| *** seldridge has joined #yosys | 05:26 | |
| *** srk has quit IRC | 05:27 | |
| *** srk has joined #yosys | 05:31 | |
| *** _whitelogger has quit IRC | 05:40 | |
| *** _whitelogger has joined #yosys | 05:42 | |
| *** rohitksingh_work has quit IRC | 05:53 | |
| * MoeIcenowy considering whether I should buy a UPduino2 | 06:08 | |
| *** rohitksingh_work has joined #yosys | 06:12 | |
| *** rohitksingh_work has quit IRC | 06:28 | |
| *** proteusguy has joined #yosys | 06:47 | |
| *** seldridge has quit IRC | 06:55 | |
| *** emeb_mac has quit IRC | 06:57 | |
| *** proteusguy has quit IRC | 07:12 | |
| *** proteusguy has joined #yosys | 07:13 | |
| *** dys has joined #yosys | 07:21 | |
| *** dys has quit IRC | 07:39 | |
| promach_ | Why https://gist.github.com/promach/5f2d9a9494704ed93cf65687c982198c passed yosys bmc base-case test but failed in iverilog simulation https://www.edaplayground.com/x/3TuQ ? | 08:50 |
|---|---|---|
| tpb | Title: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at gist.github.com) | 08:50 |
| MoeIcenowy | promach_: I don't think iverilog supports SV | 08:54 |
| promach_ | it does have systemverilog support, check -g 2012 option http://iverilog.wikia.com/wiki/Iverilog_Flags | 09:11 |
| tpb | Title: Iverilog Flags | Icarus Verilog | FANDOM powered by Wikia (at iverilog.wikia.com) | 09:11 |
| promach_ | MoeIcenowy | 09:11 |
| MoeIcenowy | promach_: "Actual SystemVerilog support is ongoing." | 09:26 |
| MoeIcenowy | if you enable -g 2012, it will enable the check for SV keywords, but no real SV support is present | 09:27 |
| *** finnb has joined #yosys | 09:34 | |
| *** citypw has quit IRC | 10:40 | |
| *** citypw has joined #yosys | 10:52 | |
| *** finnb has quit IRC | 11:38 | |
| promach_ | MoeIcenowy: ok, but why does cover(in_valid) failed ? https://gist.github.com/promach/5f2d9a9494704ed93cf65687c982198c#file-multiply-v-L181 | 11:40 |
| tpb | Title: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at gist.github.com) | 11:40 |
| *** s_frit has quit IRC | 12:01 | |
| *** s_frit has joined #yosys | 12:02 | |
| *** leviathanch has quit IRC | 13:23 | |
| *** _whitelogger has quit IRC | 13:55 | |
| *** _whitelogger has joined #yosys | 13:57 | |
| MoeIcenowy | I'm not familiar with formal verification... | 13:58 |
| sorear | all I know is that formal verification is infamous for not working with multipliers | 14:04 |
| ZipCPU | promach_: You are trying to verify a synchronous multiply. Why would you ever set "multiclock on"? or use $global_clock ? | 14:18 |
| *** jevinskie has quit IRC | 14:29 | |
| promach_ | ZipCPU: ok | 14:48 |
| promach_ | but why error : Unsupported cell type $dffsr for cell | 14:49 |
| promach_ | I have no code line number indicated in the error log | 14:49 |
| ZipCPU | With or without multiclock? | 14:49 |
| promach_ | without | 14:49 |
| ZipCPU | You have a latch within your design, or an always block with something other than the clock within it | 14:50 |
| ZipCPU | and by "within it" I mean something other than the clock in the sensitivity list | 14:50 |
| promach_ | yes, reset | 14:50 |
| promach_ | I have updated the gist | 14:50 |
| ZipCPU | Check 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 @(*) blocks | 14:55 |
| ZipCPU | Have you gotten rid of your $global_clock block? | 14:55 |
| promach_ | yes, already gotten rid of your $global_clock block | 14:56 |
| promach_ | yes, already gotten rid of my $global_clock block | 14:56 |
| ZipCPU | Sounds good. Is it building now? | 14:56 |
| promach_ | no, still error : Unsupported cell type $dffsr for cell | 14:56 |
| daveshah | Do you have any `posedge clk, posedge reset`s left? | 14:59 |
| promach_ | daveshah: what is wrong with always @(posedge clk, posedge reset) ? | 15:00 |
| daveshah | That is an async reset which creates the $dffsr | 15:00 |
| promach_ | and ? | 15:01 |
| daveshah | If you don't want to use multiclock, you have to have sync resets | 15:01 |
| ZipCPU | You don't need them: you are buiding/testing a multiply | 15:01 |
| qu1j0t3 | .b 34 | 15:01 |
| ZipCPU | Hike! | 15:01 |
| promach_ | daveshah ZipCPU: ok, it is building now using your suggestion | 15:03 |
| promach_ | but cover(in_valid) still fail :| | 15:03 |
| ZipCPU | What's your top-level? | 15:04 |
| promach_ | module multiply() | 15:04 |
| ZipCPU | multiply.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_valid | 15:05 |
| ZipCPU | Look harder | 15:06 |
| *** leviathanch has joined #yosys | 15:07 | |
| *** rohitksingh has joined #yosys | 15:09 | |
| promach_ | I commented out this line https://gist.github.com/promach/5f2d9a9494704ed93cf65687c982198c#file-multiply-v-L159 , but cover(in_valid) still fail :| | 15:12 |
| tpb | Title: A signed multiply verilog code using row adder tree multiplier and modified baugh-wooley algorithm · GitHub (at gist.github.com) | 15:12 |
| sxpert | ZipCPU: am progressing at a good pace here. small question though, what's the proper way to optimize a state machine ? | 15:30 |
| ZipCPU | sxpert: Normally the tools will do that for you | 15:31 |
| ZipCPU | But the answer is also state machine dependent | 15:31 |
| ZipCPU | The biggest thing you can do is to reduce the size of the state space | 15:31 |
| sxpert | ZipCPU: yeah, I saw that, but it takes a while to reduce all states | 15:32 |
| sxpert | ah, so recode the states with smaller numbers. ok | 15:32 |
| ZipCPU | Well ... yes/no | 15:32 |
| ZipCPU | Smaller size, but it may use more signals | 15:32 |
| ZipCPU | Many synthesizers will recognize a state machine, and automatically switch the encoding to a one hot encoding | 15:33 |
| ZipCPU | ... where there's one signal that's high for every possible state in the space | 15:33 |
| ZipCPU | I 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 FF | 15:34 |
| sxpert | so, instead of having one extra large always @(posedge clk), make plenty of tiny ones ? | 15:35 |
| *** emeb has joined #yosys | 15:41 | |
| sxpert | or have I misunderstood? | 15:42 |
| ZipCPU | sxpert: No, you aren't misunderstanding me | 15:46 |
| ZipCPU | That's what I do all the time. It's a style of mine, but that's why I do it | 15:47 |
| sxpert | leads to smaller things ? or just a writing style ? | 15:48 |
| sxpert | ah, clearly I'm doing something wrong ;) | 15:50 |
| sxpert | I'm getting an insult about combinatorial loops... | 15:51 |
| sxpert | https://pastebin.com/Lveh2fAy | 15:53 |
| tpb | Title: Info: Annotating ports with timing budgets for target frequency 5.00 MHz Info - Pastebin.com (at pastebin.com) | 15:53 |
| sxpert | hah, found my mistake | 16:05 |
| ZipCPU | sxpert: Have you found this link: http://zipcpu.com/blog/2017/06/12/minimizing-luts.html | 16:06 |
| tpb | Title: Minimizing FPGA Resource Utilization (at zipcpu.com) | 16:06 |
| ZipCPU | It sort of goes over my thoughts on logic minimization | 16:06 |
| * shapr snickers at "byte the bullet" | 16:09 | |
| sxpert | ZipCPU: yeah, I have read it, but I suspect this may come at a later stage, as I want something functional first | 16:11 |
| * ZipCPU offers shapr a .45, in case he wants to try it | 16:12 | |
| * ZipCPU figures a 0.45 is roughly an 0x73 in "byte" form | 16:14 | |
| *** AlexDaniel has joined #yosys | 16:22 | |
| * sxpert learns that sometimes things declared as reg should be wires | 16:30 | |
| ZipCPU | Inputs should always be declared as wires, ex: input wire i_clk; | 16:31 |
| ZipCPU | Outputs from submodules should always be declared as wires | 16:32 |
| ZipCPU | Anything with an assign statement should always be declared as a wire. | 16:32 |
| shapr | ZipCPU: I prefer 9mm, easier to fund for practice | 16:38 |
| * ZipCPU tries to convert 9mm to a byte representation | 16:38 | |
| shapr | heh | 16:39 |
| * ZipCPU figures a 9mm in "byte" form is roughly an 8'h5b | 16:39 | |
| shapr | oh man | 16:39 |
| *** lutsabound has joined #yosys | 16:42 | |
| *** supervacuus has joined #yosys | 17:26 | |
| *** m4ssi has quit IRC | 17:30 | |
| *** supervacuus has quit IRC | 17:32 | |
| *** FL4SHK has joined #yosys | 18:02 | |
| *** gsi__ is now known as gsi_ | 18:31 | |
| *** m4ssi has joined #yosys | 18:58 | |
| *** lutsabound has quit IRC | 19:02 | |
| *** rohitksingh has quit IRC | 19:06 | |
| emeb | ZipCPU: what's the rationale for "Outputs from submodules should always be declared as wires"? | 19:10 |
| *** fsasm_ has joined #yosys | 19:10 | |
| emeb | I guess you mean they need to be wires in the higher level module. | 19:15 |
| ZipCPU | emeb: Yes, that's exactly what I mean | 19:16 |
| ZipCPU | If module top has module sub beneath it, then within module top sub's outputs need to be declared as wires | 19:16 |
| ZipCPU | Within module sub, they can be declared as either--depending on how you want them to behave | 19:16 |
| emeb | Makes 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 |
| ZipCPU | My flavor of Verilog is rather ancient ... I'm surprised, though, I didn't realize there was something more ancient :D | 19:18 |
| emeb | ZipCPU: Well, this was like 25yrs ago. :P | 19:19 |
| ZipCPU | .... and? ;) | 19:19 |
| emeb | heh | 19:19 |
| emeb | VHDL 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 |
| emeb | don't know what the advantage of that is from a language standpoint. | 19:21 |
| daveshah | It avoids the issue that reading an `output` has different behaviour to reading an `inout` | 19:22 |
| daveshah | iirc VHDL also has a `buffer` type that behaves like a Verilog `output` | 19:23 |
| emeb | Hmm... never used that. | 19:23 |
| emeb | Speaking 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 |
| emeb | I 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 IRC | 19:29 | |
| *** seldridge has joined #yosys | 19:29 | |
| emeb | lol - I google for Module Compiler and find an old promotional article that quotes me -> https://www.design-reuse.com/news/1354/synopsys-module-compiler-slashes-design-time-boosts-performance-sicom-broadband-wireless-modem.html | 19:30 |
| tpb | Title: Synopsys' Module Compiler Slashes Design Time and Boosts Performance of SiCOM's New Broadband Wireless Modem (at www.design-reuse.com) | 19:30 |
| *** seldridge has quit IRC | 19:48 | |
| *** seldridge has joined #yosys | 19:52 | |
| *** seldridge has quit IRC | 20:15 | |
| *** m4ssi has quit IRC | 21:09 | |
| *** fsasm_ has quit IRC | 22:27 | |
| *** utzig has quit IRC | 22:49 | |
| *** utzig has joined #yosys | 22:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!