AvalonST to Avalon MM Bridge
Test01
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?
Adam Górski
Test01
>
> 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?
KJ
>
> 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
Test01
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.
KJ
> On Nov 19, 10:08 pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> 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).
None of what you described has anything to do with either Avalon
streaming transfers or Avalon memory mapped interfaces...those
interfaces are simply the protocols for passing data.
> But if we use the Avalon-MM bus then all that is
> transparent. Is that true?
Transparent to what? If the PCIe core really does need you 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)" then you're completely mistaken if you think that
Avalon (or any other bus interface) will take care of any of that for
you.
> 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.
OK
> Is this not done by Avalon-ST to Avalon-MM
> bridge?
>
No. Bus interfaces don't give a hoot about what data is being
transferred. They exist to give a common framework for transferring
data. What data gets transferred, what higher level protocols get put
on top of that is not relevant. That's like wondering if the
specifications for to wire a building will somehow make the Ethernet,
TCP, IP protocols transparent...it won't...it's just wire.
> 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.
>
Now we get to the real problem and it has nothing to do with ST or
MM. Since I haven't looked at the PCIe core though I can't help you
out in interpreting the data that is coming and going, I was only
helping with the handshake protocol of ST and MM.
> 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.
The manual for the core is a good start.
Kevin Jennings