| --- Log opened Mon Jul 10 00:00:07 2017 | ||
| promach | stekern: why do you requires such large width as in https://github.com/skristiansson/diila/blob/master/rtl/verilog/diila.v#L149 ? | 00:03 |
|---|---|---|
| stekern | promach: what do you mean? they're rams with 1024 entries | 06:32 |
| promach | stekern: I am referring to line 149, not line 150 | 06:33 |
| stekern | so am I | 06:33 |
| promach | what is the purpose of trig_mem ? | 06:34 |
| stekern | to store the trigger data | 06:36 |
| stekern | it could have been included into the data_mem as well, but I choose to keep it separate | 06:37 |
| promach | what do you exactly mean by 'trigger data' ? | 06:42 |
| promach | stekern: I thought 'trigger' is a 'one-bit' signal | 06:46 |
| stekern | no, trigger can be up to 32-bit | 06:47 |
| promach | why do you need 32-bit for trigger signal ? | 06:48 |
| stekern | to be able to trigger on up to 32-bit data... | 06:50 |
| promach | huh ? why would 'one-bit' trigger signal not be able to trigger on 32-bit data ? | 06:51 |
| stekern | ? | 06:51 |
| stekern | you feed the input with a 32-bit signal, then you compare that with what you want to trigger on | 06:51 |
| stekern | e.g. an address | 06:52 |
| stekern | so if you want to trigger on different addresses, 1-bit is not enough | 06:52 |
| promach | your 32-bit trigger is actually based on address ? | 06:52 |
| stekern | no, it doesn't have to be an address, it was just an example | 06:53 |
| stekern | if you only need a 1-bit trigger, you can connect only one bit to trig_i | 06:54 |
| promach | stekern: my understanding of trigger is based on figure 5 of http://zipcpu.com/blog/2017/06/08/simple-scope.html | 06:56 |
| promach | seems like we have different ways to define trigger, just like we have different ways to trigger on analog waveforms in oscilloscope | 06:57 |
| promach | stekern: your definition is more on like triggering on i2c or spi address | 06:57 |
| promach | that blog link is more like edge triggering at different point in time of the analog waveform | 06:58 |
| stekern | yeah, but it's the same thing... just that my ILA does an equality check on two values (an input and a choosen value) to generate the trigger event | 07:00 |
| stekern | rather than just taking a 1 bit input signal | 07:01 |
| stekern | the former is a lot more practical, since you can then change the trigger condition without having to resynthesize the logic | 07:03 |
| stekern | you could make it even more flexible by introducing another signal that would mask the bits you are interested in | 07:05 |
| promach | stekern: introducing another signal that would mask the bits you are interested in ??? could you elaborate more ? | 07:25 |
| ZipCPU | if (A==B) vice if ((A&MSK)==B) | 07:26 |
| stekern | yes | 07:26 |
| promach | ZipCPU: what MSK ? what 'vice if' ? | 07:30 |
| ZipCPU | MSK and B in my example would be set by the user post-synthesis time. | 07:30 |
| ZipCPU | The "vice" is an English term (not a Verilog term) to separate the two possibilities and show you the difference. | 07:30 |
| promach | how is " if (A==B) vice if ((A&MSK)==B) " being more 'flexible' ? | 07:32 |
| ZipCPU | "if ((A&MSK)==B)" is more flexible than "if (A==B)" | 07:33 |
| promach | flexible in what way ? | 07:33 |
| promach | ZipCPU: I thought https://github.com/ZipCPU/wbscope/ can change the trigger condition without having to resynthesize the logic ? | 07:34 |
| ZipCPU | Read the code. MSK and B can be set via writing to a register. Set MSK to -1, and you get "if (A==B)". Set MSK to anything else, and you can do a bit-select on the input. | 07:34 |
| ZipCPU | Not as written. wbscope requires an external trigger. If you wish to change that external trigger, you'll either have to resynthesize or build a piece of logic allowing you to select from among whatever external triggers you would like to select from. | 07:35 |
| stekern | (just to note, my code does not do the mask thing, it was just a sidenote) | 07:35 |
| stekern | but the condition can be changed at runtime | 07:35 |
| promach | stekern: ok ZipCPU: external trigger ? so, why need to resynthesize ? | 07:36 |
| promach | this is my initial top-level https://paste2.org/macJOE4L | 07:36 |
| ZipCPU | It's a start. | 07:39 |
| promach | ZipCPU: https://github.com/ZipCPU/wbscope/ could also change user trigger and user holdoff values at run-time, right ? | 07:40 |
| ZipCPU | Check the spec. What does the spec say about that? | 07:40 |
| promach | You can even change the holdoff while the scope is running by writing a new holdoff value together with setting | 07:51 |
| promach | the RESET n bit of the control register. | 07:51 |
| promach | and i_trigger is an input | 07:51 |
| ZipCPU | Yep! | 07:54 |
| stekern | ...but you can't change the trigger condition at runtime... | 08:06 |
| promach | stekern: wait, are you referring to ZipCPU source code ? | 08:10 |
| stekern | yes | 08:10 |
| ZipCPU | promach: stekern's right. | 08:10 |
| promach | ZipCPU: why cannot change the trigger condition at runtime ? | 08:10 |
| ZipCPU | As built, you can't change the trigger condition at runtime. | 08:10 |
| ZipCPU | I haven't had a need to add that capability in. | 08:11 |
| ZipCPU | Neither can you change the data you are sampling at run time. | 08:11 |
| ZipCPU | It's fixed with the build. | 08:11 |
| promach | https://github.com/ZipCPU/wbscope/blob/master/rtl/wbscope.v#L129 | 08:12 |
| ZipCPU | Well, yes, you can "manually" trigger the scope. | 08:13 |
| ZipCPU | That takes a bus interaction to do, but it is doable. | 08:13 |
| promach | So, why cannot change the trigger condition at runtime ? | 08:13 |
| promach | I am just curious | 08:14 |
| stekern | promach: because there's only a 1-bit trigger input | 08:14 |
| stekern | and that input needs to be 1 for the trigger event to happen | 08:14 |
| stekern | it's fixed to 1-bit and you can't change the polarity | 08:14 |
| stekern | ...and that's been enough for ZipCPU | 08:15 |
| promach | i_trigger is either zero or one | 08:15 |
| ZipCPU | stekern: Well said, thank you. | 08:15 |
| promach | and it is an input to wbscope softcore | 08:15 |
| stekern | I needed to change the trigger condition at runtime, so I made it a 32-bit signal | 08:15 |
| promach | 1-bit trigger --> cannot change the trigger condition at runtime ?? | 08:16 |
| promach | 32-bit trigger --> can change the trigger condition at runtime ?? | 08:16 |
| stekern | .. and compare that to a runtime configurable value | 08:16 |
| promach | what about changing value of 1-bit i_trigger at run-time | 08:17 |
| promach | ? | 08:17 |
| stekern | if you have tree signals, a, b and c. How would you trigger on a=1, b=1 and c=1 with ZipCPU's scope? | 08:18 |
| stekern | how would you configure it at runtime to trigger at a=1, b=1 and c=0? | 08:18 |
| ZipCPU | You'd need an external LUT: scope_trigger <= (a)&&(b)&&(c); | 08:18 |
| ZipCPU | always @(posedge i_clk) scope_trigger <= (a)&&(b)&&(!c); | 08:18 |
| ZipCPU | But ... I think I'm proving stekern's point. | 08:19 |
| promach | I thought this is an external logic | 08:19 |
| promach | instead to be done inside wbscope | 08:19 |
| stekern | well... exactly, in wbscope you have to add external logic for it, in diila it is built in... | 08:20 |
| ZipCPU | Yes | 08:20 |
| promach | I was thinking if the user could feed i_trigger <= (a)&&(b)&&(c); into wbscope | 08:21 |
| promach | without modifying wbscope | 08:21 |
| ZipCPU | Of course the user can ... but it would require you to re-synthesize your design. | 08:21 |
| promach | i_trigger is an input to wbscope | 08:22 |
| ZipCPU | Likewise, you can change c to !c, but you'd still need to resynthesize the design--just like stekern is saying. | 08:22 |
| promach | right ? | 08:22 |
| ZipCPU | Yes, i_trigger is an input to wbscope. | 08:22 |
| promach | resynthesise the design ? which design ? | 08:24 |
| promach | wbscope itself ? | 08:24 |
| promach | or blocks other than wbscope ? | 08:24 |
| ZipCPU | I am not aware of any synthesis tool that allows you to synthesize portions of your design without also resynthesizing the whole design. | 08:25 |
| promach | partial reconfiguration | 08:25 |
| ZipCPU | I've been told they exist, but ... I am not aware of any. | 08:25 |
| promach | I mean I am just asking which blocks require a change | 08:25 |
| stekern | regardless, you have to resynthisize something | 08:26 |
| ZipCPU | The only logic change is the line defining the scope's trigger. Everything else can stay the same if you would like. | 08:26 |
| stekern | != runtime | 08:26 |
| ZipCPU | Exactly. | 08:26 |
| promach | stekern: ok, how would 32-bit helps to change in run-time ? | 08:28 |
| stekern | because then you can compare it against an at runtime user configurable value | 08:32 |
| stekern | ...which is written to the module via the wishbone bus | 08:33 |
| ZipCPU | stekern: Out of curiosity, what use case has made your 32-bit trigger selector the most useful to you? | 08:38 |
| stekern | because that's the size of the data on the wb-bus | 08:38 |
| stekern | ...i.e. 32-bit just matches the user configurable value | 08:39 |
| ZipCPU | So ... do you trigger off of such things as when the bus has a write to (or read from) a particular address? Is that how you would use it? | 08:40 |
| stekern | I quite often used it to match addresses, yes | 08:40 |
| stekern | so, I'd take the address and some control signals in the lsb, and trigger on that | 08:41 |
| ZipCPU | That's a slick solution. I like it, and I can see the application for it. | 08:42 |
| promach | ZipCPU: I think for now, edge triggering is enough for me. I will go for stekern address triggering mode after this for i2c and SPI controller | 10:53 |
| promach | stekern: would your ILA be able to do something like Figure 1 of http://zipcpu.com/blog/2017/06/08/simple-scope.html ? | 11:53 |
| shorne | stekern: sorry, it looks like the discussion went in a different direction yesterday | 16:56 |
| shorne | I was looking a bit more into cache coherency issue | 16:56 |
| shorne | I noticed a few things, in PTE there is a bit for CC, it seems its always set (because it used to be used as PRESENT bit) | 16:57 |
| shorne | however I am not so sure how its used in the RTL | 16:58 |
| shorne | There seems to be a feature sdram address snooping. used for both | 16:58 |
| shorne | - Snooping dram access to ensure lwa/swa atomic operations are not invalidated by a secondary processor | 16:59 |
| shorne | - Snooping dram access to clear lines written to by secondary processor | 16:59 |
| shorne | (but the later does not seen enabled by default) | 17:00 |
| shorne | any reason for that? | 17:00 |
| shorne | In terms of the PTE/DTLBWyTRn [CC] bit I dont see it used for cache coherency | 17:12 |
| shorne | in rtl/verilog/mor1kx_dmmu.v | 17:12 |
| shorne | Maybe you know better? | 17:12 |
| --- Log closed Tue Jul 11 00:00:09 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!