Thread: [myhdl-list] Interfaces in hierarchcal way
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Jos H. <jos...@gm...> - 2015-07-06 11:38:32
|
Hi
Suppose we have an AXI4 streamig interface:
class AXI4S:
'''Interface for AXI4 Streaming protocol
'''
def __init__(self, wd = 32):
self.valid = Signal(False)
self.data = Signal(intbv(0xe5)[wd:])
self.accept = Signal(True)
Could we define an AXI4_lite interface like?:
--
class AXI4_lite:
'''Interface for AXI4 Lite protocol, consisting of 5 AXI Stream Channels
'''
def __init__(self, wa = 32, wd = 32, wr = 8):
self.aw = AXI4S(wa)
self.w = AXI4S(wd)
self.ar = AXI4S(wa)
self.r = AXI4S(wd)
self.b = AXI4S(wr)
--
In fact we obtain the 5 transport channels of an AXI4_lite protocol.
While trying verilog generation all interface signals disappear.
You can try verilog generation for:
--
def axi4s_reg(clk, rst, ai, ao):
''' AXI4-Stream register. Not verified.
'''
accept = Signal(bool(1))
@always_comb
def acc():
ai.accept.next = (ao.accept and ao.valid) or \
accept
@always_seq(clk.posedge, rst)
def reg():
xi = ai.accept and ai.valid
xo = ao.accept and ao.valid
if xi:
ao.data.next = ai.data
ao.valid.next = xi or (ao.valid and not ao.accept)
accept.next = (ai.accept and not ai.valid) # or not xi
return reg, acc
--
for which verilog generation seems OK and:
--
def axi4_lite_reg(clk, rst, ai, ao):
''' Pipeline register on each channel
'''
# Master -> slave communication
aw = axi4s_reg(clk, rst, ai.aw, ao.aw)
w = axi4s_reg(clk, rst, ai.w, ao.w)
ar = axi4s_reg(clk, rst, ai.ar, ao.ar)
# Slave -> master communication
r = axi4s_reg(clk, rst, ao.r, ai.r)
b = axi4s_reg(clk, rst, ao.b, ai.b)
return aw, w, ar, r, b
if __name__ == "__main__":
clk = Signal(False)
rst = ResetSignal(0, active=0, async=True)
ai = AXI4S()
ao = AXI4S()
toVerilog(axi4s_reg, clk, rst, ai, ao)
ai = AXI4_lite()
ao = AXI4_lite()
toVerilog(axi4_lite_reg, clk, rst, ai, ao)
--
Thanks,
Jos
|
|
From: Christopher F. <chr...@gm...> - 2015-07-06 11:56:47
|
On 7/6/2015 6:38 AM, Jos Huisken wrote:
> Hi
>
> Suppose we have an AXI4 streamig interface:
<snip>
>
> While trying verilog generation all interface signals disappear.
Jos,
When I convert the example you provided the signals
that are used are preserved the signals that are
not driven are not converted to the target HDL.
Example, the first `@always_comb` is converted to:
assign ai_accept = ((ao_accept && ao_valid) || accept);
This is for the first conversion, the second conversion
converts to:
assign aw_ai_accept = ((aw_ao_accept && aw_ao_valid) || aw_accept);
Both these look correct. I don't see which *used* signals
are not being converted?
Regards,
Chris
|
|
From: Jos H. <jos...@gm...> - 2015-07-06 14:12:38
|
Christopher Felton <chris.felton <at> gmail.com> writes: > > On 7/6/2015 6:38 AM, Jos Huisken wrote: > > Hi > > > > Suppose we have an AXI4 streamig interface: > <snip> > > > > While trying verilog generation all interface signals disappear. > > Jos, > > When I convert the example you provided the signals > that are used are preserved the signals that are > not driven are not converted to the target HDL. > > Example, the first ` <at> always_comb` is converted to: > > assign ai_accept = ((ao_accept && ao_valid) || accept); > > This is for the first conversion, the second conversion > converts to: > > assign aw_ai_accept = ((aw_ao_accept && aw_ao_valid) || aw_accept); > > Both these look correct. I don't see which *used* signals > are not being converted? > > Regards, > Chris > Hi Chris, I was looking at the interface of the verilog modules, not at the body. For axi4s_reg the generated verilog gives: -- module axi4s_reg ( clk, rst, ai_valid, ai_data, ai_accept, ao_valid, ao_data, ao_accept ); -- For axi4_lite_reg the verilog start with: -- module axi4_lite_reg ( clk, rst ); -- So all other ports (defined in a hierarchical interface) are gone... I was expecting something like: -- module axi4_lite_reg ( clk, rst, aw_ai_valid, aw_ai_data, aw_ai_accept, aw_ao_valid, aw_ao_data, aw_ao_accept, ... w_ai_valid, w_ai_data, w_ai_accept, ... ); -- Or am I missing something? I expect all signals are used... Best regards, Jos |
|
From: Christopher F. <chr...@gm...> - 2015-07-06 14:32:04
|
<snip> > > Hi Chris, > > I was looking at the interface of the verilog modules, not at the body. > For axi4s_reg the generated verilog gives: > -- > module axi4s_reg ( > clk, > rst, > ai_valid, > ai_data, > ai_accept, > ao_valid, > ao_data, > ao_accept > ); > -- > For axi4_lite_reg the verilog start with: > -- > module axi4_lite_reg ( > clk, > rst > ); > -- > So all other ports (defined in a hierarchical interface) are gone... I was > expecting something like: > -- > module axi4_lite_reg ( > clk, > rst, > aw_ai_valid, > aw_ai_data, > aw_ai_accept, > aw_ao_valid, > aw_ao_data, > aw_ao_accept, > ... > w_ai_valid, > w_ai_data, > w_ai_accept, > ... > ); > -- > > Or am I missing something? I expect all signals are used... > Sorry for the confusion, yes the ports should exist. Not sure what happened here? I looks likes, as you suspected, with the hierarchical interfaces there is a top-level port conversion bug. Regards, Chris |
|
From: Keerthan JC <jck...@gm...> - 2015-07-06 17:52:21
|
This is a known limitation: https://github.com/jandecaluwe/myhdl/blob/master/myhdl/conversion/_analyze.py#L1255 I will add that to the docs. I'm currently working on a major restructuring of the conversion code. This will most likely be fixed in the next major release (0.10/1.0) On Mon, Jul 6, 2015 at 10:31 AM, Christopher Felton <chr...@gm...> wrote: > <snip> > > > > Hi Chris, > > > > I was looking at the interface of the verilog modules, not at the body. > > For axi4s_reg the generated verilog gives: > > -- > > module axi4s_reg ( > > clk, > > rst, > > ai_valid, > > ai_data, > > ai_accept, > > ao_valid, > > ao_data, > > ao_accept > > ); > > -- > > For axi4_lite_reg the verilog start with: > > -- > > module axi4_lite_reg ( > > clk, > > rst > > ); > > -- > > So all other ports (defined in a hierarchical interface) are gone... I > was > > expecting something like: > > -- > > module axi4_lite_reg ( > > clk, > > rst, > > aw_ai_valid, > > aw_ai_data, > > aw_ai_accept, > > aw_ao_valid, > > aw_ao_data, > > aw_ao_accept, > > ... > > w_ai_valid, > > w_ai_data, > > w_ai_accept, > > ... > > ); > > -- > > > > Or am I missing something? I expect all signals are used... > > > > Sorry for the confusion, yes the ports should exist. > > Not sure what happened here? I looks likes, as you > suspected, with the hierarchical interfaces there > is a top-level port conversion bug. > > Regards, > Chris > > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- have a nice day -jck |
|
From: Jos H. <jos...@gm...> - 2015-07-06 20:25:11
|
Keerthan JC <jckeerthan <at> gmail.com> writes: > > This is a known limitation: > This will most likely be fixed in the next major release (0.10/1.0) > Hi JC, Thanks for pointing out, I'll wait for it! ;-) The work-around I just tried is quite clumsy, using conversion functions (and taking care that signal assignments go in the correct direction). So, as soon as you have something: I'm very much interested. I was trying to create an AXI subsystem for Altera Cyclone V boards... Regards, Jos |
|
From: Josy B. <jos...@gm...> - 2015-07-07 20:01:43
|
Jos Huisken <jos.huisken <at> gmail.com> writes: > I was trying to create an AXI subsystem for Altera Cyclone V boards... > Excuse me for barging in, but if you are using Altera components, wouldn't it be easier to use Qsys to connect all those AXI (and other) components? Or am I missing something? Regards, Josy |
|
From: Christopher F. <chr...@gm...> - 2015-07-08 12:45:17
|
On 7/7/2015 3:01 PM, Josy Boelen wrote: > Jos Huisken <jos.huisken <at> gmail.com> writes: > > >> I was trying to create an AXI subsystem for Altera Cyclone V boards... >> > > Excuse me for barging in, but if you are using Altera components, wouldn't > it be easier to use Qsys to connect all those AXI (and other) components? > Or am I missing something? > I don't know, I really dislike Qsys and the whole approach. It is impossible to create flexible and modular systems. And yes you might be missing something (or I am :). I think in this case an AXI subsystem was created in myhdl and is being converted to Verilog and integrated with more Verilog presumably (?). Regards, Chris |
|
From: Josy B. <jos...@gm...> - 2015-07-08 17:43:47
|
Christopher Felton <chris.felton <at> gmail.com> writes: > I don't know, I really dislike Qsys and the whole > approach. It is impossible to create flexible and > modular systems. > > And yes you might be missing something (or I am :). > I think in this case an AXI subsystem was created > in myhdl and is being converted to Verilog and > integrated with more Verilog presumably (?). > > Regards, > Chris > We already talked about that, and yes you can't create parametrizable systems with Qsys. But I'm not sure that bespoke AXI subsystems are that flexible either. And connecting them all up in an hierarchical way can be tedious. I have only used Avalon MM interfaces and am quite OK with wiring them in Qsys, but then our Qsys projects are very 'fixed'. I have been contemplating on abandoning Qsys, but then I need a good alternative for connecting those master and slave interfaces together. I have been working on a Xilinx project (consulting for) and was impressed by the overhead of building such an AXI system manually. Now I was just curious, and I had hoped that Jos Huysken enlightened me :) Regards, Josy |
|
From: Martin S. <ha...@se...> - 2015-07-09 14:12:02
|
Hi guys, > > We already talked about that, and yes you can't create parametrizable > systems with Qsys. > ... > I have been contemplating on abandoning Qsys, but then I need a good > alternative for connecting those master and slave interfaces together. > Having a deja vu here... I've found all the SOPC/Qsys and their Xilinx/Lattice counterparts not really friendly for maintenance, so I've ended up with an approach based on GNU make, kconfig (linux kernel config) and an XML device description (called DClib/devdesc). Like IP-XACT, but way less complex. Could be enhanced to spit out MyHDL (currently, it can only generate VHDL based Wishbone-capable SoCs). There's also a graphical tool called "kactus2", but I haven't looked at it in detail. The XML approach turned out to be quite robust and future compatible, unlike the known migration nightmares that make you freeze old software versions in a VM... Once hierarchy can be maintained in MyHDL, this might become very interesting, due to a vast amount of powerful XML processing tools in the Python domain. Greetings, - Martin |
|
From: Josy B. <jos...@gm...> - 2015-07-10 14:40:49
|
Martin Strubel <hackfin <at> section5.ch> writes: > Having a deja vu here... > I've found all the SOPC/Qsys and their Xilinx/Lattice counterparts not > really friendly for maintenance, so I've ended up with an approach based > on GNU make, kconfig (linux kernel config) and an XML device description > (called DClib/devdesc). Like IP-XACT, but way less complex. Could be > enhanced to spit out MyHDL (currently, it can only generate VHDL based > Wishbone-capable SoCs). There's also a graphical tool called "kactus2", > but I haven't looked at it in detail. > The XML approach turned out to be quite robust and future compatible, > unlike the known migration nightmares that make you freeze old software > versions in a VM... > > Once hierarchy can be maintained in MyHDL, this might become very > interesting, due to a vast amount of powerful XML processing tools in > the Python domain. > > Greetings, > > - Martin Grüezi Martin, IP-XACT and XML are total strangers to me ... I'll read up on it. Thanks for the link on 'kactus2'. My colleague thinks it may be very usable, but we need some time to experiment and an electronic engineer never has enough time (at least 99% of them). Unfortunately 'kactus2' doesn't read Qsys xxx_hw.tcl files, but I'm confident I can rewrite my xxx_hw.tcl generator, when I find the time :) Regards, Josy |
|
From: Jos H. <jos...@gm...> - 2015-07-13 06:24:12
|
Josy Boelen <josyboelen <at> gmail.com> writes: > > Jos Huisken <jos.huisken <at> gmail.com> writes: > > > I was trying to create an AXI subsystem for Altera Cyclone V boards... > > > > Excuse me for barging in, but if you are using Altera components, wouldn't > it be easier to use Qsys to connect all those AXI (and other) components? > Or am I missing something? > > Regards, > > Josy Hi all, The idea is ultimately to create mainly streaming interfaces toward hardware, i.e. AXI4S, the amount of streaming interfaces parameterized and usable from a device driver in linux. You can maybe imagine that it becomes conveniently feasible to use hardware accelerators and, for instance, use them from GNU-Radio. I haven't found that much, except maybe 'xillybus' which seems like a solution. I'm using Qsys as well, but indeed as Chris mentioned, not easily parameterized and missing the IP to go streaming. Maybe others have been looking into such architectural setup, I expect at least that I'm not unique in realizing something like this. Regards, Jos |
|
From: David H. <da...@ad...> - 2015-07-13 18:46:58
|
Using MyHDL, I did create a full DMA controller for transferring radio data from our digital receivers to user applications. The controller accepts data from our DDC's via AXI4-Stream signaling, and then it sends the PCIe MWr TLP's (packets) to the Xilinx PCIe interface over AXI4-Stream as well. The Linux driver supports zero-copy I/O for direct transfer into user application buffers, and MSI-X with message ring-buffers for relaying status back to the driver. There are no kernel "bounce" buffers and thus no time wasted on memcpy. This way, customers may happily buy and plug more of our hardware into their hosts, or they may use their hosts' available CPU and memory bandwidth for more intensive signal processing. I briefly looked at XillyBus, but opted to design my own low-latency scheme. Leading up to and in support of this DMA controller, I did create a few smaller AXI4-Stream building blocks in MyHDL such as synchronous FIFO's, skid-buffers, and priority arbiters. (yes, even though Xilinx offers equivalent blocks...) They were written around the time of MyHDL 0.7 and 0.8-dev (before MyHDL's hierarchical signal ), so I did end-up implementing a number of work-arounds to avoid some MyHDL peculiarities at the time. In summary, these smaller [1] vendor-agnostic streaming blocks would work just fine on Altera, but their code is pretty ugly with the work-arounds. Perhaps with MyHDL 0.9, a rewrite of these blocks would make them less internally ugly and thus worthy of being shared. Footnote: 1] For my larger DMA controller block, its PCIe output AXI4-S interface is written to expect the signaling that the Xilinx IP core uses over the "user" bits, so I'm not sure how cleanly this particular block would port from Xilinx to Altera. On 7/13/15 2:23 AM, Jos Huisken wrote: > Josy Boelen <josyboelen <at> gmail.com> writes: > >> Jos Huisken <jos.huisken <at> gmail.com> writes: >> >>> I was trying to create an AXI subsystem for Altera Cyclone V > boards... >> Excuse me for barging in, but if you are using Altera components, > wouldn't >> it be easier to use Qsys to connect all those AXI (and other) > components? >> Or am I missing something? >> >> Regards, >> >> Josy > Hi all, > > The idea is ultimately to create mainly streaming interfaces toward > hardware, i.e. AXI4S, the amount of streaming interfaces parameterized > and usable from a device driver in linux. > You can maybe imagine that it becomes conveniently feasible to use > hardware accelerators and, for instance, use them from GNU-Radio. > I haven't found that much, except maybe 'xillybus' which seems like a > solution. > I'm using Qsys as well, but indeed as Chris mentioned, not easily > parameterized and missing the IP to go streaming. > > Maybe others have been looking into such architectural setup, I expect > at least that I'm not unique in realizing something like this. > > Regards, > Jos > > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Jos H. <jos...@gm...> - 2015-07-15 13:32:14
|
David Holl <david <at> ad5ey.net> writes: > Using MyHDL, I did create a full DMA controller for transferring radio > data from our digital receivers to user applications. The controller > accepts data from our DDC's via AXI4-Stream signaling, .... > ... They were written around the time of MyHDL 0.7 > and 0.8-dev (before MyHDL's hierarchical signal ), so I did end-up > implementing a number of work-arounds to avoid some MyHDL peculiarities > at the time. Hi David, You're clearly much further than I am... I'm just starting to learn writing a linux device driver. So anything which can be shared would be helpful! For instance I could try a port to Altera-SoC. The hierarchical AXI interface was just my initial step to get going. So, I'm going into the same direction as you by first trying to create a fifo in hardware, which can be written and read from the CPU side. Best regards, Jos |
|
From: Jos H. <jos...@gm...> - 2015-07-13 06:48:01
|
Josy Boelen <josyboelen <at> gmail.com> writes: > We already talked about that, and yes you can't create parametrizable > systems with Qsys. > But I'm not sure that bespoke AXI subsystems are that flexible either. > And connecting them all up in an hierarchical way can be tedious. I have > only used Avalon MM interfaces and am quite OK with wiring them in Qsys, > but then our Qsys projects are very 'fixed'. The idea is to use the lightweight AXI master for configuring both the streaming interfaces and the connected IP, and that the axi-master and axi-slave only serve as stream drivers and stream receivers respectively. So configuration can be quite simple, I guess. But streaming interfaces are blocking so deadlock may occur: but that problem should be avoided by higher level mapping techniques. This looks like a nice simple model to me, which can later be used easily toward silicon implementation. I prefer platform independence as much as reasonably possible, and think that this would also work out for Xilinx (although I haven't checked it yet) Regards, Jos |
|
From: Christopher F. <chr...@gm...> - 2015-07-08 12:44:08
|
On 7/6/2015 12:51 PM, Keerthan JC wrote: > This is a known limitation: > https://github.com/jandecaluwe/myhdl/blob/master/myhdl/conversion/_analyze.py#L1255 > > I will add that to the docs. I'm currently working on a major restructuring > of the conversion code. This will most likely be fixed in the next major > release (0.10/1.0) I think there are some other small issues as well. I have seen cases when single-level interface port names are not maintained. Meaning that the interface port name was replaced with another identifier - assume an artifact of the design being flattened. The expanded port names, in this case, seem to be random. Regards, Chris |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X