| *** tpb has joined #yosys | 00:00 | |
| *** lutsabound has joined #yosys | 00:35 | |
| *** promach_ has joined #yosys | 00:51 | |
| *** m_t has quit IRC | 00:56 | |
| cr1901_modern | mithro: Verilog mandates `ifdef SYNTHESIS if synthesis is taking place | 01:04 |
|---|---|---|
| cr1901_modern | in practice, everyone uses //synopsis translate_on/off | 01:04 |
| cr1901_modern | (which yosys complains about, and I've asked clifford for an option to remove those warnings, but to no avail :P) | 01:05 |
| cr1901_modern | synopsys* | 01:05 |
| ZipCPU|Laptop | .... but //synopsis translate ... is a message to the synopsis synthesizer, not to any other synthesizers. | 01:08 |
| cr1901_modern | //synthesis translate_on/off also works | 01:09 |
| cr1901_modern | Idk if it's strictly synopsys-only in practice that accepts those constructs (yosys does as well, but complains). | 01:10 |
| cr1901_modern | I do know I've almost never seen `ifdef SYNTHESIS, even though Verilog says this is the correct way to split simulation and synthesis sections | 01:11 |
| cr1901_modern | Verilog spec8 | 01:11 |
| ZipCPU|Laptop | So ... just to play devil's advocate, should yosys be required to change because someone else's code is out of spec? | 01:13 |
| ZipCPU|Laptop | Wouldn't it be more appropriate to fix the code that's out of spec? | 01:13 |
| cr1901_modern | No, yosys is correct, I just can't convince the rest of the world to change their own code or Verilog-generators :D. | 01:18 |
| cr1901_modern | ^asking clifford for an option to suppress the warnings (b/c they are noise- I _know_ what I'm doing is morally wrong) was my backup when I realized the above lol | 01:20 |
| ZipCPU|Laptop | I suppose you could always patch yosys for this purpose, and maintain an out-of-tree patch ... | 01:23 |
| *** promach_ has quit IRC | 01:35 | |
| *** ZipCPU|Laptop has quit IRC | 01:36 | |
| *** kristianpaul has quit IRC | 01:52 | |
| *** kristianpaul has joined #yosys | 01:53 | |
| *** promach has quit IRC | 02:47 | |
| *** ZipCPU|Laptop has joined #yosys | 03:03 | |
| *** ZipCPU|Laptop has quit IRC | 03:13 | |
| puddingpimp | isn't it synopsys? | 03:43 |
| puddingpimp | also does synopsys' synthesizer also support the standard way? | 03:44 |
| *** seldridge has quit IRC | 03:55 | |
| *** promach has joined #yosys | 04:21 | |
| *** promach has quit IRC | 04:37 | |
| *** promach has joined #yosys | 04:40 | |
| *** promach has quit IRC | 04:41 | |
| *** promach has joined #yosys | 04:41 | |
| *** lutsabound has quit IRC | 05:09 | |
| *** leviathan has joined #yosys | 05:15 | |
| daveshah | Please don't use the old comments | 05:57 |
| daveshah | There is literally no reason not to use ifdef synthesis | 05:58 |
| cr1901_modern | I wish Migen didn't generate them, but I'm guessing one of the 5 supported synthesizers only accepts the comments | 06:00 |
| daveshah | I doubt that, ifdef synthesis has been around for a good time now | 06:00 |
| cr1901_modern | ISE supports it at least, based on a test (but I'm not about to grep for SYNTHESIS in a large manual) | 06:11 |
| mjoldfield | If you just want to suppress the warnings can't you pipe the output of yosys through a filter, or equivalently write a wrapper for the combo and invoke that ? It sounds better than maintaining your local version. | 06:14 |
| *** kuldeep has quit IRC | 06:14 | |
| daveshah | You can just use -w regex already | 06:15 |
| daveshah | That makes any warning matching a regex into a regular message | 06:15 |
| *** emeb_mac has quit IRC | 07:05 | |
| *** dys has quit IRC | 07:18 | |
| *** sklv has quit IRC | 07:33 | |
| *** GuzTech has joined #yosys | 07:53 | |
| *** kuldeep has joined #yosys | 08:13 | |
| *** jwhitmore has joined #yosys | 08:38 | |
| *** kraiskil has joined #yosys | 08:51 | |
| *** jwhitmore has quit IRC | 08:57 | |
| *** fsasm has joined #yosys | 09:13 | |
| *** m_t has joined #yosys | 10:28 | |
| *** pie__ has quit IRC | 11:47 | |
| *** elms has quit IRC | 12:16 | |
| *** elms has joined #yosys | 12:16 | |
| *** lutsabound has joined #yosys | 13:05 | |
| *** promach_ has joined #yosys | 13:23 | |
| *** fsasm has quit IRC | 13:45 | |
| *** pie__ has joined #yosys | 14:03 | |
| *** pie__ has quit IRC | 14:16 | |
| *** kraiskil has quit IRC | 14:23 | |
| *** jwhitmore has joined #yosys | 14:33 | |
| *** quigonjinn has quit IRC | 15:17 | |
| *** pie__ has joined #yosys | 15:29 | |
| *** develonepi3 has joined #yosys | 15:35 | |
| *** GuzTech has quit IRC | 16:06 | |
| *** quigonjinn has joined #yosys | 16:07 | |
| *** m_t has quit IRC | 16:22 | |
| *** jwhitmore has quit IRC | 16:29 | |
| *** seldridge has joined #yosys | 16:36 | |
| *** lutsabound has quit IRC | 16:44 | |
| *** sklv has joined #yosys | 17:01 | |
| *** dxld has quit IRC | 17:04 | |
| *** dxld has joined #yosys | 17:05 | |
| *** promach_ has quit IRC | 17:05 | |
| *** philtor is now known as calloc | 17:16 | |
| *** calloc is now known as Guest89057 | 17:17 | |
| *** Guest89057 is now known as philtor | 17:17 | |
| *** kraiskil has joined #yosys | 17:32 | |
| *** luismarques has joined #yosys | 17:47 | |
| *** seldridge has quit IRC | 17:50 | |
| *** kraiskil has quit IRC | 17:57 | |
| *** seldridge has joined #yosys | 19:15 | |
| *** X-Scale has quit IRC | 19:22 | |
| mithro | This might be a stupid question - but does yosys understand clock relationships to modules? I'm unsure what I mean by "understand" and "relationship" here :-P | 19:29 |
| mithro | Basically, I want to know what clock net is being used for a flip flop if a "data" net drives a flip flip | 19:31 |
| mithro | daveshah: Do you know if that is possible? ^ | 19:41 |
| daveshah | No idea | 19:41 |
| daveshah | Yosys has some handling of clock domains when it shoves stuff into ABC | 19:41 |
| daveshah | It's probably also doable with some crazy select statement | 19:42 |
| mithro | daveshah: Is this a clifford question? | 19:44 |
| daveshah | I'd say so | 19:45 |
| *** X-Scale has joined #yosys | 19:49 | |
| *** leviathan has quit IRC | 20:11 | |
| *** dys has joined #yosys | 20:11 | |
| *** kraiskil has joined #yosys | 20:17 | |
| mithro | daveshah: what does "c:* %x:+[CLK] a:CLOCK=1 %u c:* %d" do? select all the things which have the CLOCK attribute right? | 20:37 |
| mithro | But also maybe things which have 'CLK' in the name? | 20:39 |
| daveshah | mithro: It selects everything which connects to a port named CLK or has the CLOCK attribute set to 1 | 20:39 |
| mithro | daveshah: Is there an easy way to filter that down to just top level ports? (IE any top level port which connects to a port name "CLK" or has the "CLOCK attribute set to 1") ? | 20:40 |
| daveshah | mithro: it might do it already, I'm not sure | 20:41 |
| daveshah | Need to look at the syntax docs | 20:41 |
| mithro | daveshah: Doesn't seem to... | 20:41 |
| daveshah | Definitely doable though | 20:41 |
| daveshah | mithro: FYI http://www.clifford.at/yosys/cmd_select.html | 20:42 |
| tpb | Title: Yosys Open SYnthesis Suite :: Command Reference :: select (at www.clifford.at) | 20:42 |
| mithro | I'm looking at https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/utils/vlog/vlog_to_model.py#L123-L127 which took me too https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/utils/vlog/yosys/run.py#L150-L173 | 20:42 |
| tpb | Title: symbiflow-arch-defs/vlog_to_model.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:42 |
| daveshah | mithro: adding something like i:* %i to the end might work | 20:43 |
| daveshah | That means push all the inputs to the stack (i:*) | 20:43 |
| daveshah | Then take the intersection of the two sets at the top of the stack | 20:44 |
| mithro | wholly crap is the select language complicated :-/ -- is this based on some standard or something? | 20:45 |
| daveshah | Don't think so | 20:45 |
| daveshah | But tbh you could probably just use it to do place and route :P | 20:45 |
| daveshah | Just need to write a LLVM target for it | 20:45 |
| mithro | Ha | 20:46 |
| daveshah | Not sure if it's actually Turing complete | 20:46 |
| daveshah | But I feel like it's not far off | 20:46 |
| mithro | daveshah: adding 'x:* %i' does what I want I guess -- although I guess 'x:*' and 'i:*' should be the same mostly? | 20:47 |
| daveshah | mithro: yeah - I think clocks from VPR's point of view are inputs only? | 20:47 |
| daveshah | x:* includes inputs and outputs, if that matters | 20:48 |
| mithro | daveshah: Not quite, they do have support for things like PLLs which have clock outputs | 20:48 |
| daveshah | mithro: but do they call them clock? | 20:48 |
| mithro | daveshah: https://docs.verilogtorouting.org/en/latest/tutorials/arch/timing_modeling/#clock-generators | 20:50 |
| daveshah | mithro: great, use x:* then | 20:50 |
| mithro | daveshah: What is "select -list {} %x* i:* o:* %u %i a:ASSOC_CLOCK={} %u {} %d" doing? | 20:50 |
| mithro | daveshah: Looking for things which have an ASSOC_CLOCK={} attribute and ... ? | 20:51 |
| daveshah | mithro: Yeap. I think it also looks for wires connected to the same cell as the clock signal so they can be added automagically instead of requiring ASSOC_CLOCK to be specified | 20:53 |
| mithro | From clifford -- You should be able to do that with a select expression. Something like "net %co:+$dff[D] net %d %ci:+[CLK] n:* %i" | 20:53 |
| daveshah | mithro: yeah | 20:54 |
| daveshah | That seems about right | 20:54 |
| mithro | In answer to my question: I'm trying to figure out if a "data net" is going into a flipflop what the name of the "clock net" that is driving the flipflop | 20:54 |
| daveshah | I would start with the above expression from clifford and play about | 20:55 |
| mithro | daveshah: That assumes my "flip flops" are all $dff objects right? | 20:58 |
| daveshah | mithro: yeah | 20:58 |
| daveshah | ie you've run proc on a flattened elaborated netlist | 20:58 |
| mithro | daveshah: So, 'c:* %x:+[CLK] a:CLOCK=1 %u c:* %d x:* %i' lists the clock signals -- how do I find all "models" that a clock is connected to a given name? | 20:58 |
| daveshah | mithro: too late for me to work that out right now | 20:58 |
| cr1901_modern | That's the most readable perl I've ever seen | 20:59 |
| mithro | daveshah: When I say "models" I probably mean "cells" right? -- IE black boxes / internal yosys objects like dffs / etc? | 20:59 |
| daveshah | mithro: yeah. What they will be depends on your yosys script | 21:00 |
| daveshah | If you want models as in cells instantiated your Verilog, then you don't want to flatten | 21:00 |
| mithro | daveshah: So I would start with selecting all the cells and the filtering out the ones which do not have a connection to the given net name? | 21:00 |
| daveshah | mithro: yes, probably | 21:01 |
| mithro | Okay - and the missing piece seems to be the | 21:02 |
| mithro | '%x' | 21:02 |
| mithro | which lets me get cells connected to selected wires.. | 21:02 |
| daveshah | Yeah, %x is the magic glue | 21:02 |
| daveshah | Not sure if I really understand it either though | 21:03 |
| mithro | I don't quite understand why it has "expand top set <num1> times" -- but it seems like I can just use * | 21:05 |
| daveshah | Yes, it depends if you want to repeat until nothing more is found or not | 21:06 |
| daveshah | You can specify a number if you want a limit instead | 21:06 |
| daveshah | e.g. only one layer of hierarchy | 21:06 |
| *** kraiskil has quit IRC | 21:11 | |
| *** luismarques has quit IRC | 21:26 | |
| mithro | daveshah: Ahh - it's for the hierarchy stuff - which doesn't make much sense after you have flattened? | 21:33 |
| daveshah | mithro: yeah, I think it will depend on that | 21:34 |
| daveshah | But obviously the pb_type stuff needs hierarchy | 21:34 |
| daveshah | You will likely need to sometimes use a flattened design with Yosys and sometimes nit | 21:34 |
| daveshah | *not | 21:34 |
| mithro | daveshah: Yeah - That is enough context I can figure it out | 21:36 |
| *** lutsabound has joined #yosys | 21:48 | |
| *** seldridge has quit IRC | 22:06 | |
| *** dys has quit IRC | 22:09 | |
| *** seldridge has joined #yosys | 22:18 | |
| *** emeb_mac has joined #yosys | 22:47 | |
| mithro | So 'select -list w:*' gets me all the wires -- I'm confused why 'select -list w:*/INPUT_CLK' doesn't seem to return anything? | 23:09 |
| mithro | 'select -list w:*INPUT_CLK' seems to work.... | 23:10 |
| mithro | Any idea how "walk through" combinational cells like $and or $or cells? | 23:18 |
| mithro | Is that what %x* is all about? | 23:18 |
| mithro | When the docs say "expand top set" I took that to mean that it means the top of the stack, so when I do "select w:*INPUT_CLK %a %x*" why do I get OUTPUT_CLK? | 23:23 |
| mithro | Hrm... I wonder if this is what the "input or output cones" means? | 23:27 |
| mithro | Looks like it... | 23:40 |
| mithro | Looks like what I want is called the "output cone" | 23:41 |
| mithro | daveshah: Looks like what I want is "select -list w:*INPUT_CLK %a %co* o:* %i" | 23:44 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!