Difference between revisions of "METIS"
(→Update: 11 Fenruary 2010) |
|||
| Line 10: | Line 10: | ||
Project Leader: Phil, VK6APH | Project Leader: Phil, VK6APH | ||
| − | ===Update: 11 | + | ===Update: 11 February 2010=== |
Have now implemented ARP and PING in OyzII so most of the IP Discovery code is now working. My PC will send an ARP request when KISS Konsole first starts to determine the MAC address of OzyII. | Have now implemented ARP and PING in OyzII so most of the IP Discovery code is now working. My PC will send an ARP request when KISS Konsole first starts to determine the MAC address of OzyII. | ||
| − | Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog. | + | Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog. |
| − | + | ||
| − | + | ||
===Update: 31 January 2010=== | ===Update: 31 January 2010=== | ||
Revision as of 05:24, 11 February 2010
OzyII (or maybe Aussie II?) will be a high speed PC interface. Whilst the original Ozy board has served us well to date, in order to implement some of the future HPSDR projects we are going to need a faster interface between the various boards on the Atlas bus and the PC.
Aussie II is a kick off point for this project. Since this board will not need to support the SDR1000 there will be room for testing other high performance/speed interfaces.
Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY.
User input relating to the design and features is requested via the HPSDR reflector.
Project Leader: Phil, VK6APH
Contents
Update: 11 February 2010
Have now implemented ARP and PING in OyzII so most of the IP Discovery code is now working. My PC will send an ARP request when KISS Konsole first starts to determine the MAC address of OzyII.
Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.
Update: 31 January 2010
Now have OzyII sending and receiving UDP/IP frames. Have also implemented UDP/IP in KISS Konsole. Still have to add all the IP Discovery code but the concept basically works! Many thanks to Bill, KD5TFD, for dragging me up the Ethernet learning curve :)
Screen shot of KISS Konsole tuned to a Broadcast station below.
Update: 29 January 2010
I now have OzyII sending UDP/IP frames to my PC. Using C# .NET Sockets to receiver the data is very straightforward. Next step is to add UDP/IP support to KISS Konsole.
Update: 14 January 2010
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap. I've also added Ethernet support to Kirk's Ozy code. OzyII now sits on the Atlas bus, works with Mercury and Penny etc and talks to K.I.S.S Konsole.
There is an issue when using the Micrel KSZ9021RL evaluation board in full duplex but I think this is crosstalk due to the long leads from the chip to the edge of the board.
A prototype PCB is presently being layed out.
Update: 27 October 2009
I now have the receive code working in the FPGA and have been able to couple it to Kirk's v 1.7 Ozy code. That enables me to produce audio from the Mercury card using some PC software written by Bill, KD5TFD, that emulates data from PowerSDR or KK over Ethernet. Next step is to add the Ethernet transmit code to Ozy so we can send I&Q data from Mercury to the PC. By replacing the USB interface in PowerSDR or KK we will be able to test the entire system.
Lyle, KK7P, commenced drawing the schematic for OzyII.
Update: 27 September 2009
I now have the CRC32 generator working in the Ozy FPGA. The board can now generate Layer II Ethernet frames without being connected to a PC. This should be the last major building block necessary to complete the board design.
Update: 26 September 2009.
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).
The choice of a Micrel KSZ9021RL PHY chip looks like paying off. The chip uses the RGMII interface standard which means it only requires 12 pins in order to connect to the associated FPGA. Given the low pin count 'we' (i.e. Lyle KK7P) should be able to support both the PHY and an FX2 chip on the PCB. It's also only needs a single supply, is small, low power and low cost.
We can use the FX2 as a conventional USB interface, just like Ozy/Majster, to program the FPGAs associated Flash memory by making it emulate an Altera USB Blaster and also perhaps hand off some of the Ethernet protocol processing to it (later on).
Micrel provide a very nice evaluation board for the KSZ9021RL (see nearby photo).
This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal registers of the PHY. There is also a very nice GUI on the PC that they also provide so you can play with all the register settings.
I've been able to interface the evaluation board to an Ozy board (see nearby photo) so that I can write FPGA code to test the PHY in ernest.
By using the USB port on Ozy I can format any Ethernet frame I like on the PC, send it to Ozy and then onwards to the PHY and my lab Ethernet switch. Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.
Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.
We intend to include an FX2 on the final OzyII board to enable it to be used as an Ozy board, enable the FPGA and/or its Flash memeory to be programed via a pseudo Altera USB Blaster and perhaps provide UDP or TCP support.
I've written a simple C# program on the PC that allows me to format an Ethernet frame, or send a canned one, to the PHY. The PC sends the entire frame, including calculating the CRC32. I can also display any received Ethernet frames on the PC. Again, there is a screen shot of the PC software nearby.
Being able to generate any type of Ethernet Fame on the PC is so much faster and easier than doing the code in the FPGA. Once I have the basic code working in C# then I can port it to Verilog.
So far this all seems to work just fine. If I use the MAC address of the Ethernet Card in my PC as the 'To MAC address' then my Ethernet Switch correctly forwards the frames to the PC. Similarly the switch learns the MAC address I have use as the 'From MAC address' and returns frames just to the PHY board.
This will be a useful developement platform as we move to more advanced protocols in the future.
The next step is to get the FPGA code to generate the Ethernet preamble plus MAC addresses, get the data Payload from the PC via USB, and calculate and append the CRC32.
I have this code working in simulation but have yet to try it in the actual Ozy + PHY hardware. (Now working in the FPGA - see update above).
Once that is working I can grab Mercury I & Q data off the Atlas bus and send that to the PC via Ethernet. Similary, the demodulated audio and I & Q data can be returned via Ethernet. We will need a modified version of PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do this.
In order to use this initial software it will be necessary to program the MAC address of the PC you intend to use with OzyII into the board. We will provide a Flash memory chip on the PCB that will be programmed with the boards MAC address during manfacture.
With the FPGA <> PHY hardware interface working we can start designing the schematic for OzyII and Lyle KK7P will commence that after his holidays.
By using a large FPGA it offers the potential to add a soft core microprocessor in the future so that the board can run a full TCP/IP stack, UDP etc. e.g. uIP http://www.sics.se/~adam/uip/index.php/Main_Page
Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate.
Feedback and comments are requested via the HPSDR reflector.
Ethernet Notes:
In general, an Ethernet subsystem is divided into two parts: the media access controller (MAC) and the physical device (PHY or line interface). Generally, the MAC handles generating and parsing physical frames and the PHY handles how this data is actually moved to or from the wire. The PHY is just a means of transmitting raw bits rather than logical data packets over a physical link that are connecting network nodes.
Useful info:
http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281
http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf
Altera White paper on Ethernet using Cyclone III and NIOS soft core
http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690
