| *** tpb has joined #opencores | 00:00 | |
| mardinator_ | ZipCPU: i vaguely understand that the issue is about leaf cells, i understood it before, since i knew the definition, leaf cell should be a module that is outside the hierarchy, in contrast to hierarchical cell it does no instantiations by its own | 07:06 |
|---|---|---|
| mardinator_ | ZipCPU: someone else bonders with this thing | 07:07 |
| mardinator_ | https://workspace.accellera.org/Discussion_Forums/systemc-forum/archive/msg/msg?list_name=systemc-forum&monthdir=200811&msg=msg00031.html | 07:07 |
| mardinator_ | ZipCPU: something along the lines of flattening the verilog described here | 07:50 |
| mardinator_ | https://www.embecosm.com/appnotes/ean6/html/ch06s02s01.html | 07:51 |
| tpb | Title: 6.2.1. Module Hierarchy When Accessing Signals (at www.embecosm.com) | 07:51 |
| ZipCPU | mardinator_: Well ... Verilator does support flattening | 11:08 |
| ZipCPU | Although, I think it flattens by default | 11:08 |
| mardinator_ | is flattening akin for inlining? | 12:33 |
| ZipCPU | Not really | 13:43 |
| ZipCPU | It's more akin to losing all the structure within your design | 13:43 |
| mardinator_ | ok, well , I should look again for the definition of multiplexer, i have read all of that from e-books, it could be that i just confuse some details | 14:08 |
| mardinator_ | the single write port seems to have 6or7 multiplexers of 40entries each | 14:09 |
| mardinator_ | it may make 8*40 = 280 entries and it appears they get to be multipled with 4 too, the trace also shows that it slightly overshoots | 14:10 |
| mardinator_ | ZipCPU: yeah you are correct that flattening is not quite the same, i thought so too... | 14:11 |
| mardinator_ | it is more like inlining of a single instance and loosing others indeed | 14:11 |
| mardinator_ | i think i rambled a bit, and VCD output is correct still, i just confused the multiplexer, which overshoots the instances | 14:16 |
| mardinator_ | cause of code being inaccurate . but it can not be made more accurate easily, so some of the stuff gets left over, and never used by default | 14:17 |
| mardinator_ | i wonder if there is a distinction of write and read multiplexers, or would not that make much sense | 14:19 |
| mardinator_ | what i thought, was that multiplexer is a concept of resource sharing | 14:21 |
| mardinator_ | but looking closer at the dumps of ....Trace.cpp and also debug files of the lints | 14:23 |
| mardinator_ | it appears that instead of multiplexing the resources, it multiplexes only the access port | 14:23 |
| mardinator_ | https://github.com/VerticalResearchGroup/miaow/blob/master/src/verilog/rtl/issue/instr_info_table.v | 14:25 |
| tpb | Title: miaow/instr_info_table.v at master · VerticalResearchGroup/miaow · GitHub (at github.com) | 14:25 |
| mardinator_ | those crucial multiplexors from there | 14:25 |
| mardinator_ | it appears from the log, that those multiplexers have different storages still, that the storage is not shared | 14:26 |
| mardinator_ | yeah it actually is not a resource sharing thing, it is a switching inputs to the outputs | 14:38 |
| mardinator_ | to one certain output that is | 14:39 |
| mardinator_ | ah it is complicated, well the output port still kinda is common probably | 14:39 |
| mardinator_ | ZipCPU: i just let you know, that i am completly confused, and have not made any progress | 17:19 |
| ZipCPU | Is the code you are working on posted anywhere? | 17:32 |
| mardinator_ | ZipCPU: i think i can post the dumps, but i have not been actively involved posting stuff over the network, however in such hurry as i am witih my things, maybe i could use your help, and may do it later today | 17:43 |
| mardinator_ | what could be some service to use, to upload bunch of files or embedded text conviently? | 17:43 |
| mardinator_ | first . i have one freak theory, since the decoder_param_en.v has for loop in the definition called in the earlier instr_info_table.v | 17:44 |
| mardinator_ | maybe every multiplexer has four instances cause of the for loop that controls the port of | 17:45 |
| mardinator_ | reg_out | 17:45 |
| mardinator_ | now, things get messy, the chip has CU and SIMD arbiters | 17:46 |
| mardinator_ | and it may be that over four elements of instances their wavefront ID's get routed to different instance | 17:47 |
| mardinator_ | every time | 17:47 |
| mardinator_ | and final thing is the freakest observation | 17:48 |
| mardinator_ | it maybe that when no port is enabled it will generate a latch | 17:48 |
| mardinator_ | it seems highly difficult to read in the verilog, but again the trace.cpp is at another hand very large to process with gnome-calculator, but very confusing is the decoder_param_en.v in the instr_info_table.v it builds a two bit vector from wfid which is 6bits by default? | 18:04 |
| mardinator_ | how can one test the 40bits LSBs using only 2bits is pretty much a mistery for me | 18:06 |
| mardinator_ | say the value of wfid is 32, nothing should be in the first two bits | 18:06 |
| mardinator_ | or maybe it builds a 6bit value for the four different arrays and enables them | 18:08 |
| mardinator_ | hmm, it may append the FU to the wfid | 18:58 |
| *** ZipCPU has left #opencores | 19:52 | |
| *** mardinator_ has quit IRC | 22:33 | |
| *** mardinator_ has joined #opencores | 22:51 | |
| *** mardinator_ has quit IRC | 23:04 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!