100Base-FX
How can we send data at 125 Mbps?
Is the streamer the best tool for this?
I am thinking about something like this code below (borrowed from some HDMI code):
'******************************************** '* 100BASE-FX Test * '******************************************** CON DAT org ' ' Setup ' hubset ##%1_000001_0000011000_1111_10_00 'config PLL, 20MHz/2*25*1 = 250MHz waitx ##20_000_000 / 200 'allow crystal+PLL 5ms to stabilize hubset ##%1_000001_0000011000_1111_10_11 'switch to PLL setxfrq ##$4000_0000 'set streamer freq to 1/2 clk (125 MHz) ' ' Ethernet frame ' ' ARP Who has 1.1.1.1? Tell 192.168.2.1 ' ' 0000 ff ff ff ff ff ff 11 11 11 11 11 11 81 00 00 64 ' 0010 81 00 00 c8 08 06 00 01 08 00 06 04 00 01 11 11 ' 0020 11 11 11 11 c0 a8 02 01 00 00 00 00 00 00 01 01 ' 0030 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ' 0040 5B 00 6C 87 Preamble byte $55, $55, $55, $55, $55, $55, $55 ' SFD byte $d5 ' DMAC byte $ff, $ff, $ff, $ff, $ff, $ff ' Destination MAC SMAC byte $11, $11, $11, $11, $11, $11 ' Source MAC VLAN1 byte $81, $00, $00, $64 ' QinQ VLAN 100 VLAN2 byte $81, $00, $00, $c8 ' QinQ VLAN 200 PAYLOAD byte $08, $06, $00, $01, $08, $00, $06, $04 $00, $01, $11, $11, $11, $11, $11, $11 $c0, $a8, $02, $01, $00, $00, $00, $00 $00, $00, $01, $01, $01, $01, $00, $00 $00, $00, $00, $00, $00, $00, $00, $00 $00, $00, $00, $00 FCS byte $5B, $00, $6c, $87 IFGAP byte $00, $00, $00, $00 $00, $00, $00, $00 $00, $00, $00, $00
Those above are bytes. Actually 100Base-FX will need to encode 4B/5B and then send with NRZ-I
4B 5B ---- ----- 0000 11110 0001 01001 0010 10100 0011 10101 0100 01010 0101 01011 0110 01110 0111 01111 0000 10010 1001 10011 1010 10110 1011 10111 1100 11010 1101 11011 1110 11100 1111 11101 NRZ-I: 0 -> no signal change 1 -> signal invert in the middle of bit period.
Comments
Are you not planning to use a PHY for this? Eg, are you trying to get direct differential serial output to modulate a SFP at 125Mbps?
If so, you could get the 4 to 5 bit translation done in the pin streamer using a LUT mode. However adding NRZI will be trickier because it requires a different sequence depending on the state of the line on the prior bit. You might be able to select which 1 bit "palette" is to be used based on the prior ending bit which can create the two outcomes from an initial state. This means some more COG intervention per nibble and you lose the efficient packed modes where nibbles are read per long and streamed directly from hub. You'll probably need to read data and extract nibbles and send them in immediate mode to the streamer. But given you only need to transfer 25M nibbles/s then you have spare cycles for doing this with the FIFO. Eg. 5 instructions per nibble (250MHz P2) just gets there in a REP loop, something like:
You'd also need to prime the streamer because of the asymmetry in the XCONT timing (11,9,11,9 clock spacing).
Receive will be more challenging at 125Mbps to decode.
Thank you for your reply, I will definitely need help from someone with knowledge.
At first, I was looking how to send from COG RAM (to avoid HUB synchronization mistakes), and drive directly without PHY or SFP.
(Not even thinking about receiving yet.)
I was planning to drive directly an electro-optical converter (HP 83402C)
But I can consider other options if they are easier to achieve. Will need time to digest the code above. No idea how the instructions work, is there any debugger out there to help me check the registers execution step by step?
I have equipment to test any rate (10M,100M/1000M and 10G). But have zero P2 programming skills. No idea on how to start coding.
![](https://forums.parallax.com/uploads/editor/oo/0k2uqclkgpwz.jpg)
The code above is an idea only not final code and needs further work etc to figure out the streamer commands and setup lookup table etc. There is a debugger that @ozpropdev developed that may help you at some point. You will certainly need to learn quite a lot of PASM2 code for this project. It is challenging, particularly RX. Probably a little easier to start with using MII I think. Then it's only 25M nibbles per second to process then and easier for the P2 to keep up rather than push it to the limit right away to decode received data serially bit by bit (but perhaps a serial smart pin can clock up to 125Mbps and you could try to capture raw unframed and encoded data for later decoding/processing, don't know).
By the way, I found that you can probably send out entire encoded bytes at a time via the streamer so the code above simplifies to something like this (uses up 256 LUT entries for a table). This saves clocks and you only need 11 P2 clocks per byte sent now to keep up instead of the 20 above.