Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
219 Views

Tripple Speed Ethernet (tse) Avalon-ST interface format

I am using the tse in small mac mode for a fixed 100M only connection.
The project is in Quartus 16.

I am a bit confused as to how the avalon-ST interface works. I have read the avalon-ST user guide, (and I have written my own sources and sinks compatible with the FIR core, using 1 & 2 channels, but this iplementation does not use the empty signal).
My question is, in 32bit wide mode, I send 4 bytes in line with the start pulse (SOP) and the remaining bytes in line with the end pulse (EOP) including the empty quantity.
What if my last packet is only 3 bytes for example. Do I send 3 bytes in line with SOP and set the empty number to '1'?
Do I subsequently send a EOP by itself (i.e. with padded data)?
What if my last packet is only 4 bytes for example.

Konrad

0 Kudos
13 Replies
Highlighted
Moderator
206 Views

HI,


If you are using datawidth = 32 bits then you must use "ff_tx_mod[1:0]" so called empty signal to mask out invalid/extra data transfer in last data packet sent.


Else you can also consider to use datawidth = 8 bits to give you more flexibility in taking care of last data packet transaction issue. Then you will not face the problem anymore.


Thanks.


Regards,

dlim


0 Kudos
Highlighted
Beginner
203 Views

OK, I have re-read the user guide and figured out I can assert Start of Packet (SOP) and End of Packet (EOP) at the same time if the packet is 4 bytes or less.

0 Kudos
Highlighted
Moderator
187 Views

ok, great.


You found another method to workaround the issue. Does it help to resolve your issue ?


Regards,

dlim


0 Kudos
Highlighted
Beginner
182 Views

I still am confused.

To send 64 bytes using 32bit words for example, I send 1 word with SOP,  followed by 62 words in line with the rising clock followed by 1 word with EOP.  This is what I think is inline with the user guide.

But, the TSE Megawizard in Qsys shows an example picture when you click on the interface with 1 word with SOP followed imediately with another word with EOP to send 2 words (an 8-byte packet), followed by another 8-byte packet.

My question is therfore, do I send the whole Ethernet packet as 1 Stream Packet (which is what I am doing) or should I send the Ethernet packet as multiple Stream Packets? 

 I have started testing this out and I get jumbled data out, bytes and nibbles in the wrong place/wrong order.   The output is always consistent to what I put in, (i.e. I change the send data and the output changes) but is corrupt.

I shall post the Avalon-ST output traces I am using generated by Model Sim.

I have simulated my own vhdl files, but I have never simulated built in IP.  This I suppose will be my next step,

regards

Konrad

0 Kudos
Highlighted
Moderator
178 Views

Hi,


You are using unique way with EOP to chop of the packet instead of using mask bit or 8 bits transfer (not 32 bits). So, yup, it's recommended for you to test it out in simulation better.


For the Ethernet packet length control,

  • Min length is 64 bytes (if enabled padding and actual packet transfer is less than 64 bytes, then TSE MAC will insert padding bytes)
  • Max length is 1500


Thanks.


Regards,

dlim



0 Kudos
Highlighted
175 Views

Hi,

I do not want to do this in a unique way.  I am asking which is the correct way.  I am happy to use either method.

I am using the small MAC, so I have to use 32bits.....because 8 bits is not supported.....(or have I misread the User Guide?)

regards

Konrad

0 Kudos
Highlighted
170 Views

This is the format I am currently usingThis is the format I am currently using

0 Kudos
Highlighted
Moderator
139 Views

Hi Konrad,


You are right. Looks like TSE small MAC doesn't support 8 bits option.

  • The only way to enable 8 bits FIFO option is to use other TSE MAC configuration like 10M/100M/1000M MAC option

The recommended and right way is to use the the mask bit signal "ff_tx_mod[1:0]" for 32 bits transfer as I explained in my first reply. You will need to modify your Tx source user logic design accordingly to use mask bit signal.


Thanks.


Regards,

dlim


0 Kudos
Highlighted
Beginner
118 Views

I have found the problem I had.  I had connected 125MHz from the PLL instead of 25MHz from the PHY.  A stupid oversight I had meant to correct.

For other users with problems, the avalon-st as in the trace I have posted seems to be correct.

I have another problem now.  I lose the first 2 bytes that I send, i.e. the upper MSB bytes of the first 32-bit word clocked into the TSE.  I can send multiple 32-bit words consistently without error, but the first two bytes are never sent.  It is as if the TSE is dropping these bytes, as the other half of the 32-bit word is OK.

e.g. I send 0x11223344 0x55667788 0x99AABBCC etc, and I receive  0x33445566 0x778899AA 0xBBCCDDEE

I am sending the data directly into a piece of test equipment that guarantees that the pre-amble is OK.

Even more confusing is that if I set the TSE to fill in the MAC address, the received MAC is in the correct place, i.e. 0x33445566 0x7788mmmm 0xmmmmmmmm

The SignalTap shows that the 32-bit words on the avalon-st are OK and not corrupted,

If anyone has any ideas as to what I am doing wrong I would love some feedback,

Konrad

 

0 Kudos
Highlighted
Beginner
109 Views

found it, ...if you tick the Megafunction "Align to 32-bit boundaries" it clearly states in the user guide that the core drops 2 bytes...missed it

0 Kudos
Highlighted
Moderator
80 Views

Sound good.


You have found the 32 alignment setting.


Just wonder is your TSE project working correctly, now ?


Regards,

dlim


0 Kudos
Highlighted
Beginner
76 Views

The Transmit side of the TSE is all working thanks....yes

I have still to implement the Recieve side.  It is not standard Ethernet, it is an Avionics version that uses 2 identical channels that must be compared for both content and jitter when received (in the FPGA).  It is taking me a while to plan this out,

regards

Konrad

0 Kudos
Highlighted
Moderator
66 Views

HI Konrad,


ok, noted.


Hopefully your receiving side project development will be smoother this time.


For now, I am setting this case to closure first as Tx side issue is resolved


Thanks.


Regards,

dlim




0 Kudos