AvalonST to Avalon MM Bridge
in [FPGA]
|
From: Test01 on 19 Nov 2009 09:17 For Altera Straix4 GX FPGA, Is there a bridge module available between the Avalon-ST to Avalon-MM? Trying to use the PCIE endpoint hard IP using Altera Megawizard software. But this interface generates the Avalon streaming output. I think for what I am doing I do not need very high performance bus and Avalon-MM may work. Avalon MM is much simpler bus The thing is that the PCIE endpoint interface needs to be connected to several modules with other users trying to design. It may be much easier in multi-user environment to use the Avalon-MM bus then to use the Avalon-ST bus. This is why I was just curious if there is Avalon-ST to Avalon-MM bus bridge? This way the endpoint can use the Avalon-ST bus but then bridge will have Avalon-MM interface which will allow numerous devices to be on that bus. I understand that SOPC flow provides this capability but here is what I am looking for from the PCIe endpoint Verilog module. - Needs to be verilog module that I can instantiate and synthesize in my Top verilog file. It seems to be generating the verilog output but it also has a lot other things in that file I may not need. The verilog output also has some stuff related to simulation. I guess it is OK to start removing the stuff form this file if I do not need it. For example I may not need the DMA controller module. - Only contains PCIe endpoint that has Avelon-MM interface on the the backside. It will be good to not have other modules. - I use VCS to simulate and Synplify for synthesis. I am not sure how well it fits in this flow. I am sure this is documented somewhere but it is taking some time for me to dig through the information. Any suggestions?
From: Adam Górski on 19 Nov 2009 09:38 Test01 pisze: > For Altera Straix4 GX FPGA, Is there a bridge module available > between > the Avalon-ST to Avalon-MM? Trying to use the PCIE endpoint hard IP > using Altera Megawizard software. But this interface generates the > Avalon streaming output. I think for what I am doing I do not need > very high performance bus and Avalon-MM may work. Avalon MM is much > simpler bus The thing is that the PCIE endpoint interface needs to > be > connected to several modules with other users trying to design. It > may be much easier in multi-user environment to use the Avalon-MM bus > then to use the Avalon-ST bus. This is why I was just curious if > there > is Avalon-ST to Avalon-MM bus bridge? This way the endpoint can use > the Avalon-ST bus but then bridge will have Avalon-MM interface which > will allow numerous devices to be on that bus. > > I understand that SOPC flow provides this capability but here is what > I am looking for from the PCIe endpoint Verilog module. > > > - Needs to be verilog module that I can instantiate and synthesize in > my Top verilog file. It seems to be generating the verilog output > but > it also has a lot other things in that file I may not need. The > verilog output also has some stuff related to simulation. I guess it > is OK to start removing the stuff form this file if I do not need it. > For example I may not need the DMA controller module. > - Only contains PCIe endpoint that has Avelon-MM interface on the the > backside. It will be good to not have other modules. > - I use VCS to simulate and Synplify for synthesis. I am not sure how > well it fits in this flow. I am sure this is documented somewhere > but > it is taking some time for me to dig through the information. > > > Any suggestions? http://www.altera.com/literature/hb/nios2/qts_qii55013.pdf?GSA_pos=2&WT.oss_r=1&WT.oss=Avalon%20ST%20to%20MM%20bridge Adam
From: Test01 on 19 Nov 2009 10:25 On Nov 19, 8:38 am, Adam Górski <totutousungors...(a)malpawp.pl> wrote: > Test01 pisze: > > > > > > > For Altera Straix4 GX FPGA, Is there a bridge module available > > between > > the Avalon-ST to Avalon-MM? Trying to use the PCIE endpoint hard IP > > using Altera Megawizard software. But this interface generates the > > Avalon streaming output. I think for what I am doing I do not need > > very high performance bus and Avalon-MM may work. Avalon MM is much > > simpler bus The thing is that the PCIE endpoint interface needs to > > be > > connected to several modules with other users trying to design. It > > may be much easier in multi-user environment to use the Avalon-MM bus > > then to use the Avalon-ST bus. This is why I was just curious if > > there > > is Avalon-ST to Avalon-MM bus bridge? This way the endpoint can use > > the Avalon-ST bus but then bridge will have Avalon-MM interface which > > will allow numerous devices to be on that bus. > > > I understand that SOPC flow provides this capability but here is what > > I am looking for from the PCIe endpoint Verilog module. > > > - Needs to be verilog module that I can instantiate and synthesize in > > my Top verilog file. It seems to be generating the verilog output > > but > > it also has a lot other things in that file I may not need. The > > verilog output also has some stuff related to simulation. I guess it > > is OK to start removing the stuff form this file if I do not need it. > > For example I may not need the DMA controller module. > > - Only contains PCIe endpoint that has Avelon-MM interface on the the > > backside. It will be good to not have other modules. > > - I use VCS to simulate and Synplify for synthesis. I am not sure how > > well it fits in this flow. I am sure this is documented somewhere > > but > > it is taking some time for me to dig through the information. > > > Any suggestions? > > http://www.altera.com/literature/hb/nios2/qts_qii55013.pdf?GSA_pos=2&.... > > Adam- Hide quoted text - > > - Show quoted text - Thanks for giving the information. It seems that I still need to use the SOPC flow to generate this. Is there Avalon-ST to Avalon-MM bridge Verilog module somewhere that can use?
From: KJ on 19 Nov 2009 23:08 On Nov 19, 10:25 am, Test01 <cpan...(a)yahoo.com> wrote: > > Thanks for giving the information. It seems that I still need to use > the SOPC flow to generate this. Is there Avalon-ST to Avalon-MM > bridge Verilog module somewhere that can use?- Hide quoted text - > The streaming transfer and memory mapped interfaces are logically almost the same, they name the signals differently though. The places where they are truly different represent things that don't map when trying to convert an ST to an MM protocol. The basic concepts in the protocols are: - In ST is that data transfers of occur between a 'source' and a 'sink'; in MM it is 'master' and 'slave'. - In ST data always goes from a source to a sink; in MM data can go in either direction. A 'write' command moves data from master to source; a 'read' command moves data from source to master. Given that, under certain scenarios, you can view an ST source as being logically the same as an MM slave; an ST sink as being logically the same as an MM master. In those scenarios, the 'ST to MM bridge' would simply consist of the following trivial logic which presumably you could write yourself and add it as a wrapper around the core. MM Signal Equivalent ST signal ======== =============== read ready waitrequest not(valid) or... waitrequest_n valid readdata data So now the question is what are the scenarios where this works? The key signals that ST has that MM doesn't are 'endofpacket' and 'channel'. If your system will always have either fixed size packets or the slave/source can be queried to determine the packet size then might not have a need for the 'endofpacket' signal to flag the end of a data transfer. If your slave/source has only a point to point connection to a single master/sink then you won't have a need for the 'channel'. There are a whole bunch of other signals that an ST interface could potentially have, per figure 6-1 in the Avlon Interface Specification. Basically any signal that is defined in that table as having a direction of 'source to sink' other than the 'data' and 'valid' signals are problems because there is no MM equivalent to work with. Whether those signals are required depends on your particular application and use of that interface and it may also depend on how the core you'd like to use is designed. The fact that there are these potentially problem signals means that you can't construct a generic ST to MM convertor without customizing the 'data' signal. To do this, one would start by constructing a data record that consists of the various other signals that go from source to sink (i.e. 'channel', 'error', 'startofpacket', 'endofpacket' and 'empty'). The ST to MM convertor would then simply append these signals with the ST data in order to make it be the MM readdata. Now the MM master receives a wider 'readdata' input that includes not only the ST 'data' but all of the other ST status signals. The one clinker in the above is the 'channel' signal. The ST 'channel' signal is the equivalent of an MM 'address' signal. The problem comes in that MM 'address' is generated by an MM master, not a slave. So if you need the capability provided by the channel signal, then your ST source will now need to become an MM master, rather than an MM slave. This isn't necessarily difficult it just means that the mapping of signals is different. Again the logic is rather trivial MM Signal Equivalent ST signal ======== =============== write valid waitrequest not(ready) writedata data It would also be possible to do the same trick with expanding ST data with the other ST status signals to widen the MM writedata that I described earlier. In fact, because of the lack of a suitable MM slave equivalent to the ST 'channel' signal it would likely be best that the ST to MM convertor be written so that the MM side is a master and not a slave. The last clinker will come in if your other Avalon devices require byte enables and data resizing. That's gets a bit more complex (but not impossible) then I want to go into here...suffice it to say that the resizing of data busses would best be accomplished as a separate module that then could get instantiated within your ST to MM convertor. No matter how you cut it, the logic to implement the ST to MM bridge is not at all difficult to come up with. Now that I've walked you through the basic steps for creating the convertor, the real question is why? ST data transfers are fundamentally nearly the same as MM. In some ways it is easier to grasp, I'm not getting how you think it is harder than MM and how any designer would have trouble with ST but not MM...makes no sense to me. But in any case, you should have enough info now to construct a bridge between the two protocols.. Good luck. Kevin Jennings
From: Test01 on 20 Nov 2009 16:12 On Nov 19, 10:08 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Nov 19, 10:25 am, Test01 <cpan...(a)yahoo.com> wrote: > > > > > Thanks for giving the information. It seems that I still need to use > > the SOPC flow to generate this. Is there Avalon-ST to Avalon-MM > > bridge Verilog module somewhere that can use?- Hide quoted text - > > The streaming transfer and memory mapped interfaces are logically > almost the same, they name the signals differently though. The places > where they are truly different represent things that don't map when > trying to convert an ST to an MM protocol. > > The basic concepts in the protocols are: > - In ST is that data transfers of occur between a 'source' and a > 'sink'; in MM it is 'master' and 'slave'. > - In ST data always goes from a source to a sink; in MM data can go in > either direction. A 'write' command moves data from master to source; > a 'read' command moves data from source to master. > > Given that, under certain scenarios, you can view an ST source as > being logically the same as an MM slave; an ST sink as being logically > the same as an MM master. In those scenarios, the 'ST to MM bridge' > would simply consist of the following trivial logic which presumably > you could write yourself and add it as a wrapper around the core. > > MM Signal Equivalent ST signal > ======== =============== > read ready > waitrequest not(valid) or... > waitrequest_n valid > readdata data > > So now the question is what are the scenarios where this works? The > key signals that ST has that MM doesn't are 'endofpacket' and > 'channel'. If your system will always have either fixed size packets > or the slave/source can be queried to determine the packet size then > might not have a need for the 'endofpacket' signal to flag the end of > a data transfer. If your slave/source has only a point to point > connection to a single master/sink then you won't have a need for the > 'channel'. > > There are a whole bunch of other signals that an ST interface could > potentially have, per figure 6-1 in the Avlon Interface > Specification. Basically any signal that is defined in that table as > having a direction of 'source to sink' other than the 'data' and > 'valid' signals are problems because there is no MM equivalent to work > with. Whether those signals are required depends on your particular > application and use of that interface and it may also depend on how > the core you'd like to use is designed. > > The fact that there are these potentially problem signals means that > you can't construct a generic ST to MM convertor without customizing > the 'data' signal. To do this, one would start by constructing a data > record that consists of the various other signals that go from source > to sink (i.e. 'channel', 'error', 'startofpacket', 'endofpacket' and > 'empty'). The ST to MM convertor would then simply append these > signals with the ST data in order to make it be the MM readdata. Now > the MM master receives a wider 'readdata' input that includes not only > the ST 'data' but all of the other ST status signals. > > The one clinker in the above is the 'channel' signal. The ST > 'channel' signal is the equivalent of an MM 'address' signal. The > problem comes in that MM 'address' is generated by an MM master, not a > slave. So if you need the capability provided by the channel signal, > then your ST source will now need to become an MM master, rather than > an MM slave. This isn't necessarily difficult it just means that the > mapping of signals is different. Again the logic is rather trivial > > MM Signal Equivalent ST signal > ======== =============== > write valid > waitrequest not(ready) > writedata data > > It would also be possible to do the same trick with expanding ST data > with the other ST status signals to widen the MM writedata that I > described earlier. In fact, because of the lack of a suitable MM > slave equivalent to the ST 'channel' signal it would likely be best > that the ST to MM convertor be written so that the MM side is a master > and not a slave. > > The last clinker will come in if your other Avalon devices require > byte enables and data resizing. That's gets a bit more complex (but > not impossible) then I want to go into here...suffice it to say that > the resizing of data busses would best be accomplished as a separate > module that then could get instantiated within your ST to MM > convertor. > > No matter how you cut it, the logic to implement the ST to MM bridge > is not at all difficult to come up with. > > Now that I've walked you through the basic steps for creating the > convertor, the real question is why? ST data transfers are > fundamentally nearly the same as MM. In some ways it is easier to > grasp, I'm not getting how you think it is harder than MM and how any > designer would have trouble with ST but not MM...makes no sense to > me. But in any case, you should have enough info now to construct a > bridge between the two protocols.. Good luck. > > Kevin Jennings Hi Kevin Thanks for providing lots of good information. You mention that Avalon-ST to Avalon-MM interface should be fairly straight forward. The thing that is confusing me is that the ST bus is packet based. For example, ST bus drive complete PCIe TLP packet. These packets contain PCIe protocol specific information. For example if it is a command request then it contains the tag, requester ID. Thus I see the command on ST bus form PCIe hatrdIP, I need to process the response that has some the attributes of the request - response may need to contain the tag used on the corresponding request (as per my understanding). But if we use the Avalon-MM bus then all that is transparent. Is that true? Avalon-MM bus master from HardIP side will issue address/data/command and then the slave device will respond to but the slave does not need to track the response with corresponding tag and other fileds. Is this not done by Avalon-ST to Avalon-MM bridge? I would like to use the Avalon-ST but I am trying to figure out how to interpret the Avalon-ST packets coming out of the PCIe hard IP. The Avalon ST interface that is coming from the Stratix4GX PCIe hard IP. I do not have enough understanding on this so I am not sure whom to ask about this. This is for the Stratix4GX Gen1 x1 PCIe endpoint hard IP simulation and the very first transaction on the Avalon ST bus. I see the following sequence on the waveform viewer. (1)Clock1 - Start of Packet = 1 (Pulse) - Rx_St_Data[63:0] = 0000_000F_4000_0001, Rx_St_Be0[7:0] = F0 Rx_St_Eop0 = 0 (2)Clock2 Start of Packet = 0 Rx_St_Data[63:0] = 0300_0000_0020_0010, Rx_St_Be0[7:0] = 0F, St_Eop0 = 0 (3)Clock3 Start of Packet = 0 Rx_St_Data[63:0] = 0000_0003_0000_0003, Rx_St_Be0[7:0] = 0F, St_Eop0 = 1 If anyone can help me interpet this then that will be great. This how I am interpreting this transaction Header0_Byte0 = 40 This means 32 Bit Memory write This is a 3DW memory write (32 bit address and not 64 bit address) Header0_Byte1 = 00 Header0_Byte2 = 00 Header0_Byte3 = 01 1 DW write? Header1_Byte4 = 00 Header1_Byte5 = 00 Header1_Byte6 = 00 - Tag = 0? (This does not make sense) Header1_Byte7 = 0F First DW is valid. //Following are the address bytes? Header2_Byte8 = 00 Header2_Byte9 = 20 Header2_Byte10 = 00 Header2_Byte11 = 10 - Address = 0020_0010hex Is that correct? Byte12 to 15 is not valid? This is because Rx_St_Be0[7:0] = 0F for the second clock. This is why there is third clock to complete the tranaction? The 3rd clock has DW data = 0000_0003h with BE = 0Fh. Lower DW of the Rx_St_Data [63:0] has valid data. In summary, it is trying to do 3 DW (32 bit address) memory write at address 0020_0010 with data 0000_0003h. Any suggestions will be great.
|
Next
|
Last
Pages: 1 2 Prev: LDPC FADING Next: TimingAnalyzer -- Build Timing Diagrams directly from VHDL or Verilog |