<tux3>
My LUT usage goes up 600% if I move my AXI clk from the interface declaration to the modport... that doesn't seem right
<ZipCPU>
Evenin tux3
<tux3>
Hello!
<ZipCPU>
I'm not sure I follow your question ... can you share the two options you are coding?
<ZipCPU>
Is Yosys now supporting interfaces?
<tux3>
Sortof, kinda!
<tux3>
I get warnings that every wire of the interface is undefined in every module, but it synthetizes just fine
<tux3>
That's a different story though =]
<tux3>
Essentially, I have this AXI4 Lite bus in my toy softcore. It was declared as "interface axi(input aclk, input aresetn);"
<ZipCPU>
Did it build into something useful?
<tux3>
Normally, yes. The module support seems to be hanging on by a thread, but as far as I can tell if all the stars align it works
<tux3>
s/module/interface/
<tux3>
But actually, I'd like to reset that bus from one of the modports deep into the hierarchy, instead of where it's declared in the top module. Right? So I moved the aclk and aresetn in the master modport.
<tux3>
After reducing the code a little, if I move the "assign bus.clk=clk" between my top module or a submodule, it goes from using 130 LUTs to 830
<ZipCPU>
Yeah ... that sounds like something's not working
<ZipCPU>
You aren't supposed to be able to assign to something in a submodule, such as assign bus.clk=clk
<ZipCPU>
It's supposed to go the other way, busclk = bus.clk
<ZipCPU>
But that's with dot notation into submodules, not interfaces
<ZipCPU>
My point is simply that ... I don't think the standard supports it, and above that I'm not sure Yosys even fully supports the SV standard that defines those functions
<tux3>
Hhhm not sure I understand. (Apologies if I'm a little slow, it's pretty late in my timezone!)
<ZipCPU>
Yeah ... getting late here
<ZipCPU>
The "dot" notation is supposed to only be used for unsynthesizable constructs--simulation test benches, formal properties, etc
<tux3>
What I meant is I'm writing to my bus from the master side, through the master modport. The other side reads through its modport. I declare the appropriate signals as input/output and it all works — as long as there's no clk
<ZipCPU>
That doesn't sound like it works then
citypw has joined #yosys
<tux3>
I was convinced modports were synthetizable, though I can understand SV features are pretty hit and miss in general...
<ZipCPU>
No clock? What is it building that doesn't have a clock, and how do you even know its building the right thing?
<tux3>
So. The clk comes from the declaration in the top module "axi4lite sys_bus(.aclk(clk), .aresetn(!rst));"
<tux3>
And then, I pass for example "sys_bus.master" to a submodule
<tux3>
And the read side to another module
<tux3>
Then they can talk to each other through their modports
<ZipCPU>
Ah, okay ... go on
<tux3>
Now, I tried moving aclk/aresetn to the master modport, because it turns out I'd like the master to be in control or the reset.
<tux3>
That blew up when I moved the clk.
<tux3>
Maybe I should stick to boring old Verilog 2005 features, I guess I am asking for trouble =]
<ZipCPU>
Have you tried using the yosys "show" command on a simple design as a way of seeing what yosys is up to with the design you've given it?
<tux3>
Nope. Not sure I'd be able to interpret the results to be entirely honest. I glanced at the routed results in the GUI, it looks like the read side of my bus is completely failing to meet timing and routed really poorly, but I don't really understand what's going on
<tux3>
(This is probably the point where I should admit that I'm a software person and I have very little clue what I'm doing!)
<ZipCPU>
See ... that's me when I chat with clifford, "I don't know what's going on. Clifford then says, "Let's take a look" and the first thing he does is simplify the design, then he uses the "show" command to visualize it
<ZipCPU>
I've been surprised more than once at his ability to simplify a concept down to 5-10 lines of Verilog
<ZipCPU>
The graph then tends to make a lot of sense as we examine what's going on
<tux3>
That sounds like a good plan. I wonder if there's something like creduce for verilog.
<tux3>
I'll see if I can boil it down to a few lines tomorrow. Thanks for the help
<ZipCPU>
;)
rohitksingh has quit [Ping timeout: 260 seconds]
<ZipCPU>
tux3: Out of curiosity ... what hardware are you using, and why are you using AXI at all?
<tux3>
I only have a tinyfpga BX right now, but I'm trying to pretend verilog is a portable language and retargetting my code to Xiling series 7 down the line will go Just Fine
<ZipCPU>
I just ask because AXI is a rather heavy-weight protocol
<ZipCPU>
On a TinyFPGA, you're probably going to want to make every LUT count
<ZipCPU>
There are ... cheaper protocols than AXI
<ZipCPU>
(faster ones too)
<tux3>
Well, it's AXI4-Lite and I'm implementing the bare minimum, but I'm actually trying really hard to exhaust the resources of my BX so I have an excuse to buy something bigger =]
<tux3>
I really just need a vaguely standard 64bit interface. Wishbone looked like a good alternative. Is there something else I could have used?
<ZipCPU>
A 64-bit interface? AXI4-Lite is restricted to 32-bits only
<ZipCPU>
I'm personally very biased towards Wishbone (b4, pipelined), and I use it in everything I do
<ZipCPU>
It's cheaper, and tends to be faster than AXI
<ZipCPU>
Are you building a slave or a master?
<ZipCPU>
Are you building a single AXI4-Lite component, or a system containing many?
<tux3>
Both
<tux3>
Right now I really just have a quad-spi flash reader on the reader side (so not exactly taking full advantage of the 64bit bandwidth!)
<tux3>
And the master is my ifetch
<tux3>
If I ever get to using a board with some kind of DDR, the plan is to plug that on the other side of the bus and not have to change any part of my core
<tux3>
I was going to go with axi4-lite for everything memory since that's the one I studied first and I don't really know any better, but I'm very open to suggestions =] !
<tux3>
Does the wishbone handshake roughly look like axi or is it something completely different?
<ZipCPU>
It's simpler
<ZipCPU>
The Valid/Ready request handshake is roughly the same when making a request, but there's only one request channel--not three
<ZipCPU>
There's also no stalling on the acknowledgment channel, and the write data doesn't need to be synchronized with the write address
<ZipCPU>
So, in AXI, you'd do ... if (AxVALID & AxREADY). In WB, this becomes if (i_wb_stb && !o_wb_stall)
<ZipCPU>
In AXI, you have to very carefully synchronize the AW* channel with the W* channel. In WB, if i_wb_stb && i_wb_we, it's a write request
<ZipCPU>
The write data is in i_wb_data, and the byte select lines in i_wb_sel
<ZipCPU>
The addresses are similar, save that AXI's addresses are octet addressed (w/ useless LSBs) whereas WB's are word addressed
attie has joined #yosys
<tux3>
Word addresses as in bus width?
<tux3>
(No unaligned reads?)
<ZipCPU>
No unaligned reads. Everything is the width of the bus
<tux3>
Hhm. That's a tradeoff, I can see how it'd make the slave side a lot simpler, but it might push some complexity into the master side
<ZipCPU>
Such as ... ?
<ZipCPU>
As far as I can tell, it just removes complexity
<ZipCPU>
For example, AXI slaves have to worry about setting AxREADY low when xREADY and xVALID have been high for more backpressure than the slave can handle
<ZipCPU>
However, in many Xilinx configurations, Xilinx guarantees that the xREADY lines are always high
<ZipCPU>
So that's a lot of excess slave logic you need to have that you aren't using
attie has quit [Ping timeout: 240 seconds]
<tux3>
Yeah, it's a bit of a pain, I'll grant you that!
<ZipCPU>
Of course, if you change the Xilinx IP config, all of this changes
klotz has quit [Quit: klotz]
<tux3>
However I do like that axi can expose the full capabilities of my slave side without having to emulate it right on the critical path in my core. Even though, to be fair, things like misaligned reads are pretty rare in practice
<ZipCPU>
What full capabilities does AXI expose?
<tux3>
Well, for example I was gawking at sifive's core designer recently
<ZipCPU>
Go on
<tux3>
(Not that I have any ambition of ever getting anywhere near what they're doing, of course)
<tux3>
They can happily swap out their bus data width between 32/64/128 AXI, and I don't think they need a whole lot of additional logic on the master side because of how flexible the bus is
<tux3>
AXI allows some pretty crazy requests
<ZipCPU>
I'll admit, AXI makes adjusting bus width easier, but that capability is lost in AXI-lite once you drop the AxSIZE field
<tux3>
That's fair
<tux3>
You probably know more about this than I do, too =]
<sorear>
they’re not doing that in Verilog
<ZipCPU>
We should continue this discussion later. I'm struggling to keep my eyes open ;)
<tux3>
Yeah
<ZipCPU>
sorear: How are they then doing it? In VHDL? ;)