| *** tpb has joined #yosys | 00:00 | |
| *** ZipCPU|Laptop has joined #yosys | 00:05 | |
| *** svenn has quit IRC | 00:07 | |
| *** svenn has joined #yosys | 00:07 | |
| *** promach__ has joined #yosys | 00:07 | |
| *** ZipCPU|Laptop has quit IRC | 00:47 | |
| *** cemerick has joined #yosys | 00:56 | |
| *** seldridge has quit IRC | 01:24 | |
| *** promach__ has quit IRC | 01:34 | |
| *** xrexeon has quit IRC | 01:40 | |
| *** emeb_mac has joined #yosys | 01:45 | |
| *** ZipCPU|Laptop has joined #yosys | 02:01 | |
| *** ZipCPU|Laptop has quit IRC | 02:28 | |
| *** digshadow has quit IRC | 02:29 | |
| *** jkiv has joined #yosys | 02:36 | |
| *** emeb has quit IRC | 02:47 | |
| *** promach_ has joined #yosys | 03:01 | |
| *** jkiv has quit IRC | 03:11 | |
| *** digshadow has joined #yosys | 03:32 | |
| *** AlexDaniel has quit IRC | 03:45 | |
| *** promach_ has quit IRC | 04:31 | |
| *** X-Scale has quit IRC | 04:51 | |
| *** pie___ has joined #yosys | 04:52 | |
| *** digshadow has quit IRC | 05:04 | |
| *** cemerick has quit IRC | 05:20 | |
| *** philtor has quit IRC | 05:44 | |
| *** philtor has joined #yosys | 05:44 | |
| *** promach_ has joined #yosys | 06:03 | |
| *** emeb_mac has quit IRC | 06:29 | |
| *** sklv has quit IRC | 06:44 | |
| *** GuzTech has joined #yosys | 06:55 | |
| *** pie___ has quit IRC | 07:00 | |
| *** pie_ has joined #yosys | 07:01 | |
| *** digshadow has joined #yosys | 07:59 | |
| *** promach_ has quit IRC | 09:12 | |
| *** promach_ has joined #yosys | 09:42 | |
| *** svenn_ has joined #yosys | 10:10 | |
| *** shapr_ has joined #yosys | 10:18 | |
| *** Max`P has joined #yosys | 10:18 | |
| *** indy_ has joined #yosys | 10:18 | |
| *** svenn has quit IRC | 10:19 | |
| *** indy has quit IRC | 10:19 | |
| *** fouric has quit IRC | 10:19 | |
| *** quigonjinn has quit IRC | 10:19 | |
| *** philtor has quit IRC | 10:19 | |
| *** Max-P has quit IRC | 10:19 | |
| *** shapr has quit IRC | 10:19 | |
| *** Max`P is now known as Max-P | 10:19 | |
| *** philtor has joined #yosys | 10:21 | |
| *** promach_ has quit IRC | 10:25 | |
| *** fouric has joined #yosys | 10:27 | |
| *** leviathan has joined #yosys | 10:43 | |
| *** eduardo_ has joined #yosys | 11:11 | |
| *** eduardo__ has quit IRC | 11:12 | |
| *** indy_ is now known as indy | 11:25 | |
| *** indy has quit IRC | 11:34 | |
| *** indy has joined #yosys | 11:41 | |
| *** proteusguy has quit IRC | 12:11 | |
| *** xrexeon has joined #yosys | 12:46 | |
| *** maartenBE has quit IRC | 12:47 | |
| *** cemerick has joined #yosys | 12:49 | |
| *** maartenBE has joined #yosys | 12:51 | |
| *** leviathan has quit IRC | 12:58 | |
| *** leviathan has joined #yosys | 12:58 | |
| *** cemerick_ has joined #yosys | 13:41 | |
| *** cemerick has quit IRC | 13:44 | |
| *** seldridge has joined #yosys | 13:47 | |
| *** pie_ has quit IRC | 13:52 | |
| cr1901_modern | ZipCPU: The TLDR to where I'm stuck is basically "verifying a design for a parametric module w/ arbitrary value for the parameter". I don't have time right now to go into detail, but >> | 13:52 |
|---|---|---|
| *** pie_ has joined #yosys | 13:52 | |
| cr1901_modern | someone on birdsite recommended an optimization _I believe is analogous_ to what clifford uses for riscv formal to reduce the state space to check: https://twitter.com/erincandescent/status/921838346216845314 | 13:53 |
| cr1901_modern | (emphasis on _I believe is analogous_. When I have more time I could come up with a minimal example and corresponding visual aid lol.) | 13:54 |
| ZipCPU | cr1901_modern: I haven't gotten there yet, but I do know Clifford's solution which I intend to apply soon. | 14:00 |
| ZipCPU | Clifford's solution is based around "task"s within SymbiYosys. | 14:00 |
| ZipCPU | You can create a SymbiYosys file that sets parameters to a particular solution, and then split that file further into "tasks"--each of which sets the parameter values to a different value. | 14:01 |
| ZipCPU | I've also used a different approach for my multiply: I've created an abstract multiply that returns a result in 1-8 clocks. (My true multiply returns a result in 1, 2, 3, or 4 clocks--never changing) | 14:02 |
| ZipCPU | By using this abstract multiply, I can prove that *all* of the parameter based multiplies will work. | 14:02 |
| ZipCPU | (Incidentally, the result of the abstract multiply is ... random--part of the abstraction) | 14:02 |
| * cr1901_modern is trying to remember how to code verilog... please stand by | 14:04 | |
| cr1901_modern | ZipCPU: Ack, I'll have to read into that later, but here's my contrived example: https://hastebin.com/ifudafolin.erl | 14:08 |
| cr1901_modern | This is a crappy verilog counter that outputs a signal when the counter overflows | 14:08 |
| cr1901_modern | (there is a missing ov <= 0 under the rst block) | 14:08 |
| ZipCPU | I like { ov, cnt } <= cnt + 1; for that, but ... okay | 14:09 |
| cr1901_modern | Oh that works? TIL | 14:09 |
| ZipCPU | So ... what would you like to prove? | 14:10 |
| ZipCPU | assert(ov == (cnt == 0)); ? | 14:10 |
| cr1901_modern | "assuming rst=1 initially, ov eventually becomes 1" | 14:10 |
| ZipCPU | That'd be a fun assertion, and you'd find some failures in your code as well. | 14:10 |
| ZipCPU | To prove that "ov eventually becomes 1", use a cover statement and cover(ov); | 14:11 |
| cr1901_modern | Then I want to prove for arbitrary width | 14:11 |
| ZipCPU | Hmm, that means we'd need to change the assert as well, how about: assert(($past(i_reset)(||(ov == (cnt == 0))); ? | 14:11 |
| cr1901_modern | doesn't take much brain power for me to realize "no matter what the width", ov => 1 | 14:12 |
| cr1901_modern | "ov will eventually => 1"* | 14:12 |
| cr1901_modern | How do I prove that | 14:12 |
| cr1901_modern | what is prefix-||? | 14:12 |
| ZipCPU | To prove "ov will eventually => 1", use cover(ov); | 14:13 |
| ZipCPU | Oh, sorry, there is no "prefix-||" ... just a typo on my part while trying to maintain a property you weren't interested in proving. | 14:13 |
| cr1901_modern | But I want to do that for arbitrary width. I.e. "the parameter width is allowed to vary." | 14:13 |
| cr1901_modern | (I may have screwed up the Verilog. I almost never write it anymore.) | 14:14 |
| ZipCPU | Suppose you make width an arbitrary constant instead? | 14:14 |
| ZipCPU | And then allow your internal width to be 32 or some maximum value? | 14:14 |
| ZipCPU | Then, you can adjust your logic so that: always @(posedge i_clk) if (i_reset) ov <= 0; else if (&cnt[width-1:0]) ov <= 1; | 14:15 |
| ZipCPU | To prove "ov" is eventually set, cover(ov); | 14:16 |
| ZipCPU | The next question, though, is how do you do this for a 32-bit width without taking 2^32 steps? That's where abstraction comes into play. | 14:16 |
| *** cemerick has joined #yosys | 14:16 | |
| cr1901_modern | What do you mean by "internal width"? | 14:17 |
| cr1901_modern | versus an "arbitrary constant" | 14:17 |
| ZipCPU | Arbitrary constant: wire [5:0] width = $anyconst; | 14:18 |
| ZipCPU | That's also what I mean by "internal width" | 14:18 |
| ZipCPU | This is slightly different from: parameter width = 4; | 14:18 |
| ZipCPU | I suppose you might do: `ifdef FORMAL\n wire [4:0] width = $anyconst;\n`else\nparameter width = 4;\n`endif | 14:19 |
| *** cemerick_ has quit IRC | 14:19 | |
| cr1901_modern | Okay, so I forgot about $anyconst. Also I didn't know this was possible: | 14:19 |
| cr1901_modern | wire [5:0] width = $anyconst; wire [width-1:0] my_wire; | 14:20 |
| cr1901_modern | I thought you could only do that with, well, parameters | 14:20 |
| ZipCPU | No, it's not possible. Let me clarify: | 14:22 |
| ZipCPU | wire [5:0] width = $anyconst; wire [63:0] my_wire; // is possible however. | 14:22 |
| ZipCPU | Then, you can choose to only pay attention to the lower width bits of my_wire. | 14:22 |
| cr1901_modern | Hmmm... | 14:23 |
| * cr1901_modern is thinking | 14:25 | |
| cr1901_modern | I'm guessing cover can't be used w/ induction | 14:25 |
| ZipCPU | Sigh. No, it cannot. | 14:25 |
| ZipCPU | However, you could do the assertion: "assert(!|my_wire[63:width] || ov);" | 14:26 |
| ZipCPU | That'd pass induction nicely. | 14:26 |
| cr1901_modern | >Then, you can choose to only pay attention to the lower width bits of my_wire. | 14:27 |
| cr1901_modern | Did you mean higher width bits? | 14:27 |
| cr1901_modern | B/c that's what that assert does afaik- only considers the higher width bits | 14:27 |
| ZipCPU | No, I meant lower bits when I said it, the higher bits idea was only a more recent one. | 14:28 |
| cr1901_modern | ZipCPU: Oh sorry, I can't do OR to save my life | 14:30 |
| cr1901_modern | !| == "if any of the bits are 1, the whole expression is 0"? | 14:30 |
| ZipCPU | That's what I meant, yes. | 14:31 |
| ZipCPU | I haven't actually tried that expression through a Verilog parser to know that it works though .... | 14:31 |
| cr1901_modern | Okay, this approach assumes you've put an upper limit to the counter width you want to check. What I had intended to check for in my counter example w/ the parameter was: | 14:32 |
| cr1901_modern | No upper limit. Prove for finite-"n" | 14:32 |
| ZipCPU | Yeah ... I'm not sure how to do that. | 14:32 |
| cr1901_modern | counter could be 1 bit, 64 bits, 1024 bits, 65536 bits | 14:32 |
| ZipCPU | For a fixed counter, it's easy. | 14:33 |
| cr1901_modern | We both know that no matter how big the counter is, it will eventually overflow for all finite values of parameter "width" | 14:33 |
| ZipCPU | Yeah, but the proof for 65536 bits isn't trivial. :P | 14:33 |
| cr1901_modern | I simply wonder if there is a way to express this without e.g. actually having to check the 65536 bit proof | 14:34 |
| ZipCPU | At this point in our discussion, I do not know of a way. I know of a way to check counters of width 1-N, for fixed N, but not 1-infinity. | 14:34 |
| cr1901_modern | ZipCPU: Well, I need some time to think before we continue (I understand the convo isn't done- you were about to discuss abstractions). Is that okay? | 14:35 |
| ZipCPU | Well, okay, sure, let's move on to abstractions then. | 14:35 |
| ZipCPU | The idea behind abstractions is that if you can prove "A -> B", then it must also be true that "(AC) -> B" | 14:36 |
| ZipCPU | I would need to use abstractions to cover your 65536 bit case, otherwise cover (which must start at init, as currently written) would never get there. | 14:36 |
| ZipCPU | To do that, we make an abstract counter instead, and then step by an amount chosen by the formal solver subject to your constraints. | 14:37 |
| ZipCPU | The abstract counter doesn't step by one, in other words, but it might step by one. | 14:37 |
| ZipCPU | Hence, the case that you are interested in is one of many cases described by the abstraction. | 14:37 |
| ZipCPU | If the formal properties you choose still succeed, then you know they will succeed even if the counter only steps by one. | 14:38 |
| *** seldridge has quit IRC | 14:38 | |
| cr1901_modern | Hmmm | 14:38 |
| ZipCPU | Hence, if "(counter monotonically increases) -> B" is true, then so also must be if "(counter increments by one) -> B" | 14:39 |
| ZipCPU | On the other hand, it might be true that "(counter monotonically increases)" doesn't imply B, but "(counter increments by one)" does. | 14:40 |
| ZipCPU | In other words, if "A -> B" is false, it might still be true that "(AC)->B". So failing to prove "A -> B" (the abstract version) doesn't really tell you that "(AC)-> B" will fail to prove as well. | 14:41 |
| *** cemerick_ has joined #yosys | 14:41 | |
| * cr1901_modern is plugging "(A -> B) -> ((AC) -> B)" into z3 | 14:42 | |
| cr1901_modern | https://rise4fun.com/Z3/SJpl Yup, "(A -> B) -> ((AC) -> B)" is true, cool | 14:45 |
| *** cemerick has quit IRC | 14:46 | |
| cr1901_modern | so (counter monotonically increases) is "A" in your example and (counter increments by one), being more specific is "(AC)" in your example? | 14:46 |
| ZipCPU | Yes | 14:47 |
| *** proteusguy has joined #yosys | 14:47 | |
| *** AlexDaniel has joined #yosys | 14:47 | |
| cr1901_modern | This is really weird (and profound), and messing w/ my head | 14:49 |
| *** shapr_ is now known as shapr | 14:50 | |
| *** shapr has joined #yosys | 14:50 | |
| ZipCPU | Would you like me to share an example that I'm currently using? | 14:51 |
| cr1901_modern | Not right now, I would prefer to struggle/sit on this some more if that's okay :) | 14:52 |
| *** cr1901_modern has quit IRC | 14:52 | |
| *** cemerick_ has quit IRC | 14:53 | |
| ZipCPU | Ok, I'll post it to my dev branch of the ZipCPU then if anyone else requests it. | 14:53 |
| *** cr1901_modern has joined #yosys | 14:53 | |
| *** cemerick_ has joined #yosys | 14:54 | |
| *** promach__ has joined #yosys | 14:54 | |
| cr1901_modern | It seems like to take advantage of "(A -> B) -> ((AC) -> B)", you not only have to prove "A" holds, but also that "AC" holds | 14:55 |
| *** quigonjinn has joined #yosys | 14:56 | |
| cr1901_modern | ZipCPU: I have to go right, now. Would you be willing to paste a link to your example? | 14:56 |
| ZipCPU | Exactly. However, I think the formalism is getting to you. My formal proof is going the other way. | 14:57 |
| ZipCPU | Ok, sure, I'll paste the link ... one moment .... | 14:57 |
| cr1901_modern | (Well I assume proving "A -> C" is enough to show that "AC" holds) | 14:59 |
| ZipCPU | True. | 14:59 |
| ZipCPU | Ahh, sorry about my criticism starting with "Exactly. However, ..." ... looking over it again, I think you got it right. | 15:00 |
| * ZipCPU is reminded never to do (predicate) math in public ... | 15:00 | |
| cr1901_modern | No worries, I didn't even notice what you meant the first readthru :P | 15:01 |
| cr1901_modern | The reason I bring that up is because you could choose a "C" that has no relation to the truth value of "A" whatsoever and make "(A -> B) -> ((AC) -> B)" hold. | 15:01 |
| cr1901_modern | But choosing a "C" that's not derived from "A" is useless for the proof I want to do | 15:01 |
| ZipCPU | Not quite. In the example I gave of (counter is monotincally increasing), (counter increments by one) was not derived from "A" | 15:02 |
| cr1901_modern | (Perhapos I meant you need to show C -> A | 15:03 |
| ZipCPU | Ok, that makes sense. | 15:03 |
| ZipCPU | I like to think of C as a subset of A, but in predicate math C -> A might be just as equivalent. | 15:03 |
| cr1901_modern | e.g. A = (counter is monotincally increasing) and C = (true) satisfies "(A -> B) -> ((AC) -> B)" | 15:03 |
| cr1901_modern | err, crap | 15:04 |
| cr1901_modern | I'm gonna stop while I'm ahead and think more | 15:04 |
| cr1901_modern | ignore the last few msgs | 15:04 |
| * ZipCPU just posted his abstract multiply at https://github.com/ZipCPU/zipcpu/blob/dev/bench/formal/abs_mpy.v | 15:04 | |
| cr1901_modern | tyvm, I'll take a look when I have more time :) | 15:05 |
| * cr1901_modern splits for a bit | 15:05 | |
| cr1901_modern | thanks for the help as always | 15:06 |
| awygle | I never thought of using $anyconst like that! Great idea | 15:23 |
| *** maartenBE has quit IRC | 15:25 | |
| *** seldridge has joined #yosys | 15:26 | |
| *** maartenBE has joined #yosys | 15:29 | |
| *** seldridge has quit IRC | 15:30 | |
| *** maartenBE has quit IRC | 15:51 | |
| *** maartenBE has joined #yosys | 15:55 | |
| keesj | do you guys also use gtkwave for looking at change value dumps or are you using..somethine else? | 16:16 |
| ZipCPU | I personally use gtkwave all over the place. | 16:17 |
| *** GuzTech has quit IRC | 16:21 | |
| awygle | I use gtkwave but I'm sad about it | 16:22 |
| *** cemerick_ is now known as cemerick | 16:22 | |
| *** promach__ has quit IRC | 16:32 | |
| *** emeb has joined #yosys | 16:40 | |
| *** AlexDani` has joined #yosys | 16:44 | |
| *** AlexDaniel has quit IRC | 16:44 | |
| *** cr1901_modern1 has joined #yosys | 16:47 | |
| *** cr1901_modern has quit IRC | 16:49 | |
| *** cr1901_modern1 has quit IRC | 16:50 | |
| *** cr1901_modern has joined #yosys | 16:52 | |
| *** digshadow has quit IRC | 17:02 | |
| *** sklv has joined #yosys | 17:03 | |
| *** seldridge has joined #yosys | 17:08 | |
| *** digshadow has joined #yosys | 17:25 | |
| *** GuzTech has joined #yosys | 17:31 | |
| *** seldridge has quit IRC | 17:33 | |
| *** cemerick_ has joined #yosys | 17:34 | |
| *** cemerick has quit IRC | 17:38 | |
| keesj | awygle: why? | 17:39 |
| keesj | I have some asserts in my test code (and quite happy about it) but do use gtkwave to view stuff. There are small things I would like changed (and like sigrok's puslveview ) would like logic analysers | 17:41 |
| keesj | (but sigrok/pulseview currently are not ... 100% ready for handling many singals) | 17:42 |
| keesj | and ... just out of curiosity... what do you use when it does not work on the "real" hardware? | 17:45 |
| kc8apf | I use http://www.logicpoet.com/scansion/ when I'm on a Mac | 17:52 |
| tpb | Title: Scansion (at www.logicpoet.com) | 17:52 |
| awygle | keesj: it's not well integrated on windows, the UI is unintuitive, and it doesn't support real time streaming afaict | 17:56 |
| awygle | on real hardware I currently use vendor tools, but hope to develop a suite of tools along the lines of what ZipCPU discussed on his blog in the future | 17:56 |
| *** seldridge has joined #yosys | 17:57 | |
| ravenexp | what's wrong with good old procedural testbenches? | 17:59 |
| ravenexp | it's been quite a while since I've last stared on the marching waves | 18:00 |
| keesj | I have only limited experience but on the papilio pro I used sump / ols (e.g. http://papilio.cc/ only 32 channels and 200Mhz ) but did get the job done) but it did not feel a professional as some vendor tools | 18:04 |
| awygle | I am astonished that no one has yet implemented a live debugger for FPGAs | 18:04 |
| tpb | Title: Papilio FPGA Platform (at papilio.cc) | 18:04 |
| ravenexp | does chipscope count as a live debugger? | 18:05 |
| ravenexp | not to speak of the soft cpu trace ports | 18:05 |
| keesj | ravenexp: what do you mean by procedural testbenches? | 18:05 |
| awygle | ravenexp: can you single step the clock? Can you modify the HDL on the fly? | 18:05 |
| awygle | (no and no) | 18:05 |
| ravenexp | I can't thing of why it would be a good idea to single step an fpga | 18:06 |
| keesj | I mean: testing works fine .. but ... what do you do when it does not | 18:06 |
| ravenexp | keesj: I stop and think about my tests | 18:06 |
| ravenexp | then I fix them and it works both in tests and on the live hw | 18:06 |
| awygle | Granted something like that is more often useful in a simulator but it doesn't exist even there | 18:07 |
| awygle | I want to step through my state machines and figure out why the valid signal is getting asserted one cycle before the data is actually valid | 18:07 |
| *** cemerick has joined #yosys | 18:07 | |
| ravenexp | you can do that in like 10 lines of verilog | 18:08 |
| awygle | But every time I bring this up I get the same "just be perfect" response, so... *shrug* | 18:08 |
| ravenexp | and one you've written this test, it stays there | 18:08 |
| ravenexp | so you won't ever regress on it | 18:08 |
| awygle | you can verify correctness in 10 lines, but determining the cause of incorrectness is still done with very blunt tools | 18:09 |
| ravenexp | many small module-level tests are way better at catching logic errors than whole system debuggers could ever be | 18:09 |
| awygle | FPGA debugging sucks primarily because of how comically long the feedback loops are | 18:09 |
| awygle | why not both? | 18:10 |
| ravenexp | pls, some people do asics | 18:10 |
| keesj | well. I think I have written decent tests and (this is my first real project) and I felt happy about it. I even had some kind of confidence. building up tests and seeing it pass was awesome. using gtkwave was only a basic .. visualisation but I needed real... failing? tests | 18:10 |
| awygle | I imagine Asic debugging sucks worse. Doesn't mean fpga debugging doesn't suck. | 18:10 |
| *** cemerick_ has quit IRC | 18:10 | |
| ravenexp | complaining about fpga loopback cycles is somehat... | 18:10 |
| keesj | but I feel there is still a distance between that and .. the real thing | 18:11 |
| ravenexp | keesj: I use verilog models for things both inside and outside the fpga | 18:11 |
| keesj | because of bad simulation? | 18:11 |
| ravenexp | you can do board level debugging before you can even get your hands on the real hw | 18:12 |
| ravenexp | when I was an fpga noob I used chipscope and real logic analyzers a lot | 18:13 |
| ravenexp | nowadays I mostly do "make ; make program" and things just work... | 18:13 |
| * keesj did use a real logic analyzer today | 18:14 | |
| ravenexp | you can't do CI with people with logic analyzers | 18:15 |
| ravenexp | with good test suites you actually can | 18:15 |
| *** GuzTech_ has joined #yosys | 18:33 | |
| *** GuzTech has quit IRC | 18:35 | |
| *** jkiv has joined #yosys | 18:38 | |
| *** seldridge has quit IRC | 18:39 | |
| *** GuzTech_ has quit IRC | 18:43 | |
| *** GuzTech_ has joined #yosys | 18:43 | |
| *** seldridge has joined #yosys | 18:59 | |
| *** dys has joined #yosys | 19:17 | |
| *** GuzTech__ has joined #yosys | 19:21 | |
| *** GuzTech_ has quit IRC | 19:24 | |
| keesj | are there travis/github type hosted CI projects I might want to look into ? | 19:26 |
| keesj | (example stuff) | 19:26 |
| ZipCPU | What sort of stuff are you looking for? | 19:27 |
| *** cemerick_ has joined #yosys | 19:31 | |
| *** cemerick has quit IRC | 19:35 | |
| ZipCPU | awygle: I've single stepped my FPGA designs before. | 19:39 |
| ZipCPU | It's not all that hard to do, but you do need to plan to be able to do so from the beginning. | 19:40 |
| ZipCPU | Further, I think a lot of ASIC engineers single-step their designs once the ASIC comes back from the fab--usually they have a logic chain of some type (can't remember the name off the top of my head) that allows them to see everything and then step everything. | 19:41 |
| keesj | ZipCPU: I don't really know what I am looking for sorry, I guess information on how others deal with this type of issues and good examples | 19:42 |
| keesj | (but ... I won't start doing it today so mostly out of interest) | 19:43 |
| ZipCPU | I have a lot of example designs at https://github.com/ZipCPU feel free to browse and then come back with questions if you would like. | 19:43 |
| tpb | Title: ZipCPU (Dan Gisselquist) ยท GitHub (at github.com) | 19:43 |
| sorear | those are called scan chains, and they are primarily used to test the chip as manufactured against the netlist, not for finding new problems in the netlist | 19:44 |
| ZipCPU | Ahh ... that's the word I was looking for. Thank you, sorear! Thank you for the clarification as well. | 19:44 |
| awygle | ZipCPU: yes, it doesn't seem difficult, but it's very uncommon. and even when it is done, the surrounding tooling doesn't support it well (most vcd renderers won't do live update for example) | 19:46 |
| ZipCPU | That makes sense. When I did it last, I used a WB bus to read the internal state back off of the device, and then dumped the data into a file I could read and process using Octave. | 19:48 |
| ZipCPU | It worked really well when stepping through signal processing algorithms | 19:48 |
| ZipCPU | Indeed, I never used any simulation on that project at all--it was all HITL testing. | 19:48 |
| *** Kensan has joined #yosys | 20:07 | |
| *** milkii has joined #yosys | 20:25 | |
| *** jkiv has quit IRC | 20:56 | |
| *** cemerick_ is now known as cemerick | 21:01 | |
| *** jkiv has joined #yosys | 21:19 | |
| *** leviathan has quit IRC | 21:58 | |
| *** GuzTech__ has quit IRC | 22:23 | |
| *** cemerick_ has joined #yosys | 22:45 | |
| *** cemerick has quit IRC | 22:49 | |
| *** AlexDani` is now known as AlexDaniel | 23:15 | |
| *** dys has quit IRC | 23:19 | |
| *** jkiv has quit IRC | 23:49 | |
| *** digshadow has quit IRC | 23:52 | |
| *** digshadow has joined #yosys | 23:53 | |
| *** seldridge has quit IRC | 23:58 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!