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.
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.
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,
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,
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?)
You are right. Looks like TSE small MAC doesn't support 8 bits 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.
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,
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,
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