Comments (4)
threewholefish
commented on May 28, 2024
1
Further to this, I think that any information in an INFO line should be short and sweet, and the full details of the frame reserved for DEBUG. IMO, RX and TX frame of length n should be sufficient information for the INFO line.
from cocotbext-axi.
alexforencich
commented on May 28, 2024
Well, I think the first one shouldn't really a problem as I don't think you would ever put the sink and the monitor on the same connection. That's only done for the unit test, in actuality you would likely use only one of the three, with the exception of maybe putting a TX and monitor on the same interface if you want to see the rx_sim_time field for packets sent into a design. Although maybe there is a better way to get feedback for TX packets, perhaps I can add some fields for events to AxiStreamFrame for tx_start, tx_complete, etc. that can be used if required.
As to the second point, the full log output does include the bus name. However, since in that testbench, all three are connected to the same pins, the name is the same for all of the messages:
10.00ns INFO cocotb.test_axis.axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=None, tid=1, tdest=1, tuser=None, rx_sim_time=None)
12.00ns INFO cocotb.test_axis.axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=None, tid=2, tdest=2, tuser=None, rx_sim_time=None)
12.00ns INFO cocotb.test_axis.axis axis.py:658 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=[1], tid=[1], tdest=[1], tuser=[0], rx_sim_time=12)
12.00ns INFO cocotb.test_axis.axis axis.py:853 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=[1], tid=[1], tdest=[1], tuser=[0], rx_sim_time=12)
16.00ns INFO cocotb.test_axis.axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01\x02'), tkeep=None, tid=3, tdest=3, tuser=None, rx_sim_time=None)
16.00ns INFO cocotb.test_axis.axis axis.py:658 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=[1, 1], tid=[2, 2], tdest=[2, 2], tuser=[0, 0], rx_sim_time=14)
16.00ns INFO cocotb.test_axis.axis axis.py:853 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=[1, 1], tid=[2, 2], tdest=[2, 2], tuser=[0, 0], rx_sim_time=14)
Again, this is only a problem for this specific unit test, as there is no reason you would connect multiple instances to the same HDL port.
On a different testbench that actually connects things to different ports, the log entries are different:
50.00ns INFO cocotb.axis_adapter.s_axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=None, tid=1, tdest=1, tuser=None, rx_sim_time=None)
60.00ns INFO cocotb.axis_adapter.s_axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=None, tid=2, tdest=2, tuser=None, rx_sim_time=None)
70.00ns INFO cocotb.axis_adapter.m_axis axis.py:658 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=[1], tid=[1], tdest=[1], tuser=[0], rx_sim_time=70000)
80.00ns INFO cocotb.axis_adapter.s_axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01\x02'), tkeep=None, tid=3, tdest=3, tuser=None, rx_sim_time=None)
90.00ns INFO cocotb.axis_adapter.m_axis axis.py:658 in _run RX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=[1, 1], tid=[2, 2], tdest=[2, 2], tuser=[0, 0], rx_sim_time=80000)
110.00ns INFO cocotb.axis_adapter.s_axis axis.py:400 in _run TX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01\x02\x03'), tkeep=None, tid=4, tdest=4, tuser=None, rx_sim_time=None)
from cocotbext-axi.
Reisswolf
commented on May 28, 2024
-
Maybe you are right about the monitor use, I just thought it would make the information presentation a bit more clear.
-
It's embarrassing to admit that I did not see the bus name in the log all the way to the left. I find it however a bit painful to trace the lines back and forth. I was thinking of something along:
- TX frame -> s_axis: AxiStreamFrame(tdata=bytearray(b'\x00'), tkeep=None, ....)
- m_axis -> RX frame: AxiStreamFrame(tdata=bytearray(b'\x00\x01'), tkeep=[1, 1],...)
would be more informative since you have everything in one place. I understand this would be a duplication but I feel it adds some value.
It just some suggestions and maybe even bad ones. Feel free to close the issue.
from cocotbext-axi.
alexforencich
commented on May 28, 2024
Yeah, it's not a bad idea. Also, a lot of people probably run with the 'condensed log' output that only shows the log entries and not the logger names. Since the logger name is shown, I didn't want to be redundant by including the signal name again, but perhaps displaying the path more prominently in the output message would be a good idea.
from cocotbext-axi.
Related Issues (20)
- axi address width causing overflow HOT 5
- address may exeed signal width HOT 2
- Axi Streaming is missing support for tstrb
- Is the repo unmaintained / closed to new features? HOT 2
- AxiStreamSink cannot handle tdata X-bytes for bytes to ignore (tkeep=0) HOT 1
- Missing signal results in AssertionError During handling of the above exception, another exception occurred: HOT 5
- Axis DUT signal naming HOT 1
- manually set tlast=1 when sending the last sample HOT 4
- Something is broken between 0.1.20 and 0.1.22
- AxiStreamSink not reading signed_int from dut HOT 5
- Conditional logging
- No support for suffixed AXI bus signal names
- AxiStreamSource shows unexpected behaviour with TUSER and multiple byte_lanes HOT 4
- Setting optional arguments arid,awid in AxiMaster don't seem to work
- Axi stream receiving 8b chunks when sending 32b data HOT 3
- Assigning value to individual signals of AXI Read Address Channel HOT 9
- Issue accessing AXI4Lite bus signals wrapped in a VHDL record HOT 2
- AxiStreamMonitor: Monitor AXIS in a hierarchy deeper than top dut HOT 1
- Writing to / Reading of AxiRam from the hardware DUT hang when adding when loops to the test bench
- cocotb-bus.bus implements the bus_separator to which you removed access to the axi-lite
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cocotbext-axi.