openHPSDR new Ethernet Protocol document

[Phil Harman]

I've updated the openHPSDR new Ethernet Protocol based on feedback from Steve, KF70.

The changes include:

• The Discovery response now includes the DSP clock frequency in Hz and the number of receivers implemented in the hardware
• An option for sending phase words rather than receiver or transmitter frequency
• The ability to send/receive data to/from  specific registers e.g. for use with an AD9866

The latest version (V1.1) is in the Documentation sub directory here:

http://svn.tapr.org/repos_sdr_hpsdr/trunk/Angelia_new_protocol 

My thanks to Steve for the constructive feedback and suggestions.

73 Phil...VK6PH 

[Alan Hopper]

Phil,

It is great that you are supporting the Hermes Lite. I like the new discovery stuff.

I can't see a way at the moment for client software to know whether to send frequency or phase word, perhaps this be could added to the discovery packet or have I missed something?  As this protocol is going to change over time I wonder if it is worth making the hardware also return the protocol version it is using, this would allow client software to avoid doing things like misinterpret blank fields from hardware running old firmware.  I guess for Hermes the firmware version can be used for this, for the hermes lite with a number of people playing with the firmware this is less controllable.

Steve,

do you want to try the phase word stuff in the current protocol?

73 Alan M6NNB

[Phil Harman]

Hi Alan,

Thanks for the feedback, I'll add frequency or phase word required to the Discovery reply packet. Discovery indicates the type of hardware connected and the installed  code version, if this is not sufficient then easy to add more information.

73 Phil...VK6PH 

[Steve Haynal]

Hi Phil,

Thanks for the additions. They will be very useful for us.

I noticed in your receiver block diagram that you are moving from Polyphase decimate by 8 FIR Filters to a Polyphase decimate by 2 FIR Filters. This should help with limited resources. Did you notice any performance or other trade-offs with this switch?

Also, have you considered replacing the cordic with NCOs? Most NCOs have IP licensing restrictions, but there is this one that I've been meaning to try. John Seamons started with the Hermes RTL for his WRX project but switched to NCOs (Xilinx IP) to reduce resource usage. Although they can use multipliers, overall the resource usage is supposedly lower. He has also done some interesting work on CIC pruning.   

73,

Steve

KF7O

[Steve Haynal]

Hi Alan,

I'd eventually like to try it. It may allow us to fit 3 receivers in the CV as we do in the SDK. I will get back to you when I actually get around to this. If you want to try, search for "This really should be done on the PC..." in hermes_lite_core.v and directly connect the Rx_ctrl words without the multiply and add. That is the computation that will have to be done on the PC.

73,

Steve

KF7O

[Phil Harman]

Hi Steve,

The move to decimate by 2 FIR Filters was to reduce the size of the receiver code  for the ANAN-10E board which has a small FPGA but also to increases the max sample rate to 1.536Msps.  This means we no longer need to stitch 3 receivers together in order to produce the wide bandscope display in PowerSDR. 

The small FIR meets the 0.01dB ripple requirement of PureSignal which is fine but the transition band is a little wider so a nudge of the bandscope width is required. Apart from that it works just fine. I was able to use Matlab to design the FIR coefficients, with a much reduced number of coefficients,  since the CIC droop is about 10dB which need to be perfectly compensated for optimum PureSignal operation.

I have also removed the interpolating FIR on the transmit side since we are now sending I&Q at 192ksps at 24 bits so can feed the CIC directly.  My latest FPGA code also uses phase words rather than frequency so I'll put that in SVN over the next few days.

Not looked at NCO's but thanks for the link and I'll follow up....even though my goal is to eliminate the FPGA :)

73 Phil...VK6PH 

[Alan Hopper]

Steve,

I had  a quick try and removed the *&+ from the code but it wasn't enough on its own to get 3 receivers in the cv.  The decimate by 2 fir success is great news in regard of moving the fir to the pc as the increase in bandwidth is then only x2.

got my 1.22 pcbs today, very excited by the vna/duplex prospect, I'm wondering if this can be neatly integrated into client radio software.

73 Alan M6NNB

[Steve Haynal]

Hi Phil,

What is your plan to connect the ADC/DAC to the TK 1 without a FPGA?

My thinking is that even though not absolutely necessary, a FPGA is at least very useful for logic glue and interfacing. And once you commit to a small ~$10 FPGA, you might as well use some of the DSP resources to take the edge off computational requirements and make the job easier for a cheap SBC. I definitely want to reduce what is done on the FPGA, especially control, and move it to software where it is easier to deal with. For version 2.0, I am looking a the new MAX 10 devices and a gigabit ethernet connection. They have a family of 2K LE (<$10) to 50K LE ($57, similar size to Hermes FPGA) devices all in the same easy to solder 144-LQFP footprint. With these, we can stuff a board with the larger parts for a more conventional SDR, or use one of the smaller devices for glue to a Jetson or equivalent to leverage your DFC work. Given that the AD9866 costs ~$30, we can have an entire transceiver for around $100.

73,

Steve

KF7O

[Steve Haynal]

Hi Alan,

Thanks for the report. I too would like to integrate at least some basic antenna VNA in client software. I think if we have a standard board, we can even assume what OSL will be for rough measurements. With my pysdrvna software for the softrock RXTX ensemble, I get good antenna analysis even without a real reflection bridge. 

I'm also rethinking adding an ADC for power and other measurements in rev 2.0. The part costs $8.00 and the integrated ADC costs $15 on the MAX 10. We already have a good ADC. I'd like to use it for these types of measurements, and since it is fast we can do real VNA stuff.

73,

Steve

KF7O

[Phil Harman]

Hi Steve,

My current plan is to just use the FPGA for I/O control and no DSP.  The current DFC code simply sends 16 bit ADC samples using raw Ethernet frames at a Gigabit. That requires the least packet over head so I can send samples at 61.44Msps and takes only a fraction of the FPGA LEs 

The Hermes board then connects directly to the Ethernet socket on the Nvidia  TK1 board.  Using about 50% of the 192 CUDA cores and 100% of one of the quad CPU cores we can implement a real-time 1M bin FFT and four independent receivers. The trick was to send Jumbo Ethernet frames of 8192 bytes in order to minimize the number of CPU interrupts and also match the internal register lengths of the TK1.  We can also write directly to  CUDA memory from the Ethernet /dev  so we eliminate the time delays of CPU <> CUDA ram swaps. 

There will most likely be a small FPGA in the future designs since its a cost effective way of doing I/O etc but all the DSP will be in the SBC.  

The receiver proof of concept is very close now and then we are going to try the reverse process to implement the transmitter i.e. send the DAC data over the Ethernet and again no DSP in the FPGA.

We are also testing the new Nvidia Shield  box ($200) that has twice the CUDA cores of the TK 1 and also runs 64 bit CPUs. With a keyboard, mouse and screen attached that should provide a complete transceiver. 

73 Phil....VK6PH  

[Sid Boyce]

Hi Phil,
Details of the NVidia Shield are a little bit sketchy about the screen details other than the excellent resolution.

If the Shield uses a touch screen it should be possible to use touch instead of mouse and keyboard or does the controller provide alternatives?

Exploring compact format SDR's, I am running Hermes-Lite 1.21 with an ODROID-C1, Ubuntu 14.04.2 ARM with openHPSDRJ and a 7" HDMI touchscreen - 720x480 @ 32bpp.
One problem I have yet to solve, it overflows the screen though it is horizontally scrollable to allow access to all the buttons but the waterfall is off the bottom of the screen.

I am seeing the same with HiQSDR rasdr on the -C1 which on the standalone HiQSDR using a Raspberry Pi model B and a 7" touchscreen is crystal clear and fits perfectly.
73 ... Sid.

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[John Williams]

Model numbers for displays, pls. Just bought a rasp pi 2.

[John Laur]

Sid, 

NVidia has 3 products now under the Sheild name; the one Phil is talking about is the Android device that plugs into the TV and has an Ethernet port. It is commercially available right now and is essentially the consumer version of the evolution of the Jetson TK-1 board.

Raspberry Pi (1 and 2) btw have compromised network performance. The ethernet interface hangs off of the USB2 bus; packet latency is variable and there is a lot of CPU overhead handling network traffic. It is not a particularly good candidate for the HPSDR protocol although you can use lower bandwidths OK. (Plus you have to share the USB bus with an audio device) BeagleBoneBlack and ODROID are much better candidates in this respect, though the cost is slightly more.

73, John K5IT

[Sid Boyce]

http://www.sainsmart.com/7-inch-tft-lcd-monitor-for-raspberry-pi-touch-screen-driver-board-hdmi-vga-2av.html which comes with a separate controller card, USB touch interface board and  a switch board. Once HDMI is selected the switch board can be hidden away permanently, likewise for the USB touch interface board.
 
I screwed the controller board on to 4 6mm high threaded posts glued to the back of the LCD as can be seen on my QRZ.com page.

root@raspberrypi:~# xinput_calibrator

That command generates parameters for the file /etc/X11/xorg.conf.d/99-calibration.conf, dependent on the touchscreen. When I replaced a screen where I had accidentally damaged the ribbon cable, I had to run it again to get it spot on.
It did not contain SwapAxes, I had to add it to get touch to work in the correct sense instead of pointer upwards action actually moving pointer down and vice versa, same for the horizontal movement.

root@raspberrypi:~# cat /etc/X11/xorg.conf.d/99-calibration.conf    
Section "InputClass"
       Identifier      "calibration"
       MatchProduct    "eGalax Inc. USB TouchController"
       Option  "Calibration"   "1997 74 222 1976"
       Option "SwapAxes" "1"
EndSection

root@raspberrypi:~# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=raspbian
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

I also have a touchscreen that is fully encased, used on the ODROID-C1, more costly than the SainSmart but works the same.

root@odroid-c1:/usr/src# cat /usr/share/X11/xorg.conf.d/99-odroidtouch.conf    
Section "InputClass"
       Identifier      "calibration"
       MatchProduct    "eGalax Inc. Touch"
       Option  "Calibration"   "1965 -26 70 1952"
       Option  "SwapAxes"      "0"
EndSection

73 ... Sid.

On 01/07/15 16:33, John Williams wrote:

Model numbers for displays, pls. Just bought a rasp pi 2.

On 9:56AM, Wed, Jul 1, 2015 Sid Boyce <boyc...@gmail.com> wrote:

Hi Phil,
Details of the NVidia Shield are a little bit sketchy about the screen details other than the excellent resolution.

If the Shield uses a touch screen it should be possible to use touch instead of mouse and keyboard or does the controller provide alternatives?

Exploring compact format SDR's, I am running Hermes-Lite 1.21 with an ODROID-C1, Ubuntu 14.04.2 ARM with openHPSDRJ and a 7" HDMI touchscreen - 720x480 @ 32bpp.
One problem I have yet to solve, it overflows the screen though it is horizontally scrollable to allow access to all the buttons but the waterfall is off the bottom of the screen.

I am seeing the same with HiQSDR rasdr on the -C1 which on the standalone HiQSDR using a Raspberry Pi model B and a 7" touchscreen is crystal clear and fits perfectly.
73 ... Sid.

On 01/07/15 14:39, Phil Harman wrote:

Hi Steve,

My current plan is to just use the FPGA for I/O control and no DSP.  The current DFC code simply sends 16 bit ADC samples using raw Ethernet frames at a Gigabit. That requires the least packet over head so I can send samples at 61.44Msps and takes only a fraction of the FPGA LEs 

The Hermes board then connects directly to the Ethernet socket on the Nvidia  TK1 board.  Using about 50% of the 192 CUDA cores and 100% of one of the quad CPU cores we can implement a real-time 1M bin FFT and four independent receivers. The trick was to send Jumbo Ethernet frames of 8192 bytes in order to minimize the number of CPU interrupts and also match the internal register lengths of the TK1.  We can also write directly to  CUDA memory from the Ethernet /dev  so we eliminate the time delays of CPU <> CUDA ram swaps. 

There will most likely be a small FPGA in the future designs since its a cost effective way of doing I/O etc but all the DSP will be in the SBC.  

The receiver proof of concept is very close now and then we are going to try the reverse process to implement the transmitter i.e. send the DAC data over the Ethernet and again no DSP in the FPGA.

We are also testing the new Nvidia Shield  box ($200) that has twice the CUDA cores of the TK 1 and also runs 64 bit CPUs. With a keyboard, mouse and screen attached that should provide a complete transceiver. 

73 Phil....VK6PH  

On Wednesday, July 1, 2015 at 11:49:33 AM UTC+8, Steve Haynal wrote:

Hi Phil,

What is your plan to connect the ADC/DAC to the TK 1 without a FPGA?

My thinking is that even though not absolutely necessary, a FPGA is at least very useful for logic glue and interfacing. And once you commit to a small ~$10 FPGA, you might as well use some of the DSP resources to take the edge off computational requirements and make the job easier for a cheap SBC. I definitely want to reduce what is done on the FPGA, especially control, and move it to software where it is easier to deal with. For version 2.0, I am looking a the new MAX 10 devices and a gigabit ethernet connection. They have a family of 2K LE (<$10) to 50K LE ($57, similar size to Hermes FPGA) devices all in the same easy to solder 144-LQFP footprint. With these, we can stuff a board with the larger parts for a more conventional SDR, or use one of the smaller devices for glue to a Jetson or equivalent to leverage your DFC work. Given that the AD9866 costs ~$30, we can have an entire transceiver for around $100.

73,

Steve

KF7O

On Monday, June 29, 2015 at 11:14:22 PM UTC-7, Phil Harman wrote:

....even though my goal is to eliminate the FPGA :)

73 Phil...VK6PH

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sid Boyce]

Thanks John,
Good information.
The only drawback with ODROID compared to the NVidia TV probably is ODROID only has a 4-core GPU.
73 ... Sid.

On 01/07/15 17:29, John Laur wrote:

Sid, 

NVidia has 3 products now under the Sheild name; the one Phil is talking about is the Android device that plugs into the TV and has an Ethernet port. It is commercially available right now and is essentially the consumer version of the evolution of the Jetson TK-1 board.

Raspberry Pi (1 and 2) btw have compromised network performance. The ethernet interface hangs off of the USB2 bus; packet latency is variable and there is a lot of CPU overhead handling network traffic. It is not a particularly good candidate for the HPSDR protocol although you can use lower bandwidths OK. (Plus you have to share the USB bus with an audio device) BeagleBoneBlack and ODROID are much better candidates in this respect, though the cost is slightly more.

73, John K5IT

On Wed, Jul 1, 2015 at 10:33 AM, John Williams <jswi...@gmail.com> wrote:

Model numbers for displays, pls. Just bought a rasp pi 2.

On 9:56AM, Wed, Jul 1, 2015 Sid Boyce <boyc...@gmail.com> wrote:

Hi Phil,
Details of the NVidia Shield are a little bit sketchy about the screen details other than the excellent resolution.

If the Shield uses a touch screen it should be possible to use touch instead of mouse and keyboard or does the controller provide alternatives?

Exploring compact format SDR's, I am running Hermes-Lite 1.21 with an ODROID-C1, Ubuntu 14.04.2 ARM with openHPSDRJ and a 7" HDMI touchscreen - 720x480 @ 32bpp.
One problem I have yet to solve, it overflows the screen though it is horizontally scrollable to allow access to all the buttons but the waterfall is off the bottom of the screen.

I am seeing the same with HiQSDR rasdr on the -C1 which on the standalone HiQSDR using a Raspberry Pi model B and a 7" touchscreen is crystal clear and fits perfectly.
73 ... Sid.

On 01/07/15 14:39, Phil Harman wrote:

Hi Steve,

My current plan is to just use the FPGA for I/O control and no DSP.  The current DFC code simply sends 16 bit ADC samples using raw Ethernet frames at a Gigabit. That requires the least packet over head so I can send samples at 61.44Msps and takes only a fraction of the FPGA LEs 

The Hermes board then connects directly to the Ethernet socket on the Nvidia  TK1 board.  Using about 50% of the 192 CUDA cores and 100% of one of the quad CPU cores we can implement a real-time 1M bin FFT and four independent receivers. The trick was to send Jumbo Ethernet frames of 8192 bytes in order to minimize the number of CPU interrupts and also match the internal register lengths of the TK1.  We can also write directly to  CUDA memory from the Ethernet /dev  so we eliminate the time delays of CPU <> CUDA ram swaps. 

There will most likely be a small FPGA in the future designs since its a cost effective way of doing I/O etc but all the DSP will be in the SBC.  

The receiver proof of concept is very close now and then we are going to try the reverse process to implement the transmitter i.e. send the DAC data over the Ethernet and again no DSP in the FPGA.

We are also testing the new Nvidia Shield  box ($200) that has twice the CUDA cores of the TK 1 and also runs 64 bit CPUs. With a keyboard, mouse and screen attached that should provide a complete transceiver. 

73 Phil....VK6PH  

On Wednesday, July 1, 2015 at 11:49:33 AM UTC+8, Steve Haynal wrote:

Hi Phil,

What is your plan to connect the ADC/DAC to the TK 1 without a FPGA?

My thinking is that even though not absolutely necessary, a FPGA is at least very useful for logic glue and interfacing. And once you commit to a small ~$10 FPGA, you might as well use some of the DSP resources to take the edge off computational requirements and make the job easier for a cheap SBC. I definitely want to reduce what is done on the FPGA, especially control, and move it to software where it is easier to deal with. For version 2.0, I am looking a the new MAX 10 devices and a gigabit ethernet connection. They have a family of 2K LE (<$10) to 50K LE ($57, similar size to Hermes FPGA) devices all in the same easy to solder 144-LQFP footprint. With these, we can stuff a board with the larger parts for a more conventional SDR, or use one of the smaller devices for glue to a Jetson or equivalent to leverage your DFC work. Given that the AD9866 costs ~$30, we can have an entire transceiver for around $100.

[John Williams]

I picked the rasp pi 2 to play with win 10. More of an experiment than a solid plan.

John w9jsw

[John Laur]

John, Absolutely; nothing wrong with the device itself. I have a pile of Raspberry Pi and similar SBC and development boards. For the price it is hard not to have them around. I do think they might stand a chance to make a good client for a few 48/96khz receivers with Hermes-Lite. The Winbook TW700 is also a fun device for low end windows. Being x86 has some advantages. I have added a USB hub that has built in ethernet in order to take Hermes-Lite portable. It seems to work OK.

John

[Alan Hopper]

Phil,

this is great, thanks very much.  I'm very intrigued with the dfc stuff, I would love to know how all the frequency domain interpolation and windowing works, I imagine it is very far from trivial.

73

Alan M6NNB

On Wed, Jul 1, 2015 at 1:48 PM, Phil Harman <ph...@pharman.org> wrote:

Hi Alan,

 

I’ve added to the Discovery reply packed the version of the protocol that the hardware has implemented and also if frequency or a phase word is required. 

 

Latest version (V1.2) is in SVN here:

 

http://svn.tapr.org/repos_sdr_hpsdr/trunk/Angelia_new_protocol/Documentation

 

73 Phil....VK6PH

 

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[James Ahlstrom]

 Hello Phil,

This looks like a great protocol; good work.  I just have a couple of nits.

The document refers to MSB, or Most Significant Byte first as Little-Endian.  I believe it is Network Byte Order, or Big-Endian.

If the Discovery Packet were kept the same, namely <0xEFFE><0x02><60 bytes of 0x00>, then the PC would not need to know the type of hardware protocol to query; or it could avoid sending both forms of discovery packet.  The PC would still have to deal with both forms of reply packet.  The idea here is that the old and new protocols would coexist for some time.

Jim

N2ADR

[Alan Hopper]

Steve,

this has got me thinking,  have you any pointers to good reading matter on vna theory.

Alan M6NNB

[Steve Haynal]

Hi Alan,

N2PK has a good page: http://n2pk.com/. He helped me with pysdrvna and will answer e-mail you send him. There is a lot of information here too: http://www.wetterlin.org/sam/.

73,

Steve

KF7O

[Steve Haynal]

Hi Phil,

This sounds great. We should be able to flash a v2.0 Hermes-Lite with firmware that works with your DFC or implements a traditional SDR.

How do you plan to handle CW where latency may matter through the ethernet and jetson? What is you motivation for sending the entire spectrum on TX? Why do you prefer no DSP in the FPGA?

We were using 61.440 MHz with the Hermes-Lite but switched to 73.728 MHz as the AD9866's interpolating DAC was producing a strong alias as the TX frequency came closer to Fs/2 on 10M. Perhaps your DAC will do the same.

I think we have a disconnect on the price. I can't see how someone who does not have any openhpsdr hardware can buy the hardware and NVidia shield for under $1000. With the Hermes-Lite, we can have a HF transceiver + 5W PA + Filters for under $200, closer to $100 if you leave off the PA + filters. Adding DFC via a Nvidia shield would cost another $200 until the prices come down. We really want a SDR that is in the same price range as a SoftRock RXTX Ensemble + good sound card and uses a computer that most people already have.

73,

Steve

KF7O

[Sid Boyce]

Hi Steve,
Fair point on the NVidia Jetson or the TV set top box, but I would expect it to run on any already owned PC with a NVidia Video card.
73 ... Sid.

--

You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Haynal]

Hi Phil,

I agree that hardware development is slower going than software development. To speed things up, there is quite a bit of RTL and IP reuse. Unfortunately, hardware IP/libraries/source RTL is often not free or inexpensive as it is with software. I'll wager that you are using several software/CUDA libraries with DFC and are not coding your FFTs from scratch so as to speed up development. The openHPSDR RTL is unique in that everything I have seen appears to be coded up from scratch by hams. That represents substantial work and I thank you and the others for writing it and making it open source.

The openHPSDR RTL is IP for reuse to me. More than 90% of the Hermes-Lite RTL is essentially openHPSDR RTL. This enables me to work faster. Just the other evening I was able to try an idea of transmitting the same WSPR signal simultaneously on 20M and 15M just by reusing an existing cordic. Today I made good progress in porting the new gigabit MAC/UDP stack to the CVA9. It would have taken me much longer to do either of these from scratch. 

Although you can conceive of scenarios where a 16-bit ADC will outperform the 12-bit AD9866, I do not think you see much compromise in real world operation. The AD9866 has a builtin -12 to +48 dB LNA which provides great extension to the dynamic range. In my original experiments, having extra gain on 10/15M enabled the Hermes-Lite to spot more WSPR signals than the Hermes in a head-to-head match-up. At $30 a piece for the entire LNA/DAC/ADC package, it is quite the value.

73,

Steve

KF7O

On Fri, Jul 3, 2015 at 12:44 AM, Phil Harman <ph...@pharman.org> wrote:

Hi Steve,

Thanks for the most interesting exchange. At the moment I don't know how
we are going to do CW but I do have lots of ideas!  Putting CW generation
in the FPGA fixed the latency issues for Hermes but with a Gigabit
connection we may be able to move it back into the PC.

My motivation in sending the entire spectrum on Tx is exactly the same as
DFC. The SBC or PC + graphics card can process the data in either
direction.

It also greatly simplifies PureSignal operation since we no longer need to
return the DAC data in a designated DDC - the SBC/PC already knows exactly
what it sent to the DAC.

A few years ago we had to use an FPGA since CUDA SBC and graphics cards
were not available. Now they are we no longer have to do any DSP in the
FPGA. FPGA programing is slow and has very poor tools compared with a
modern API.  Also there are many more programmers that can program on a PC
than can program, and fully meet timing, in an FPGA.

I consider myself a reasonably proficient Verilog programer but when I
look what fully tested and working code I can write in an evening in
Verilog compared with C# then C# wins hands down.  The industry bench mark
is about 10:1 and that has been my experienced.

I agree with your comments about Tx sampling rate but at the moment we are
at proof of concept stage and I think there are ways around the alias
issues.

I also think we are on the same page regarding entry price.  A Hermes-Lite
will be able to run DFC code and, assuming a suitable CUDA based graphics
card in the PC, then we are looking at 100's of receivers.  We are very
close to having DFC working on both a Jetson board and a regular PC +
Nvidia graphics card.

The DFC FPGA code is trivial compared with what we need at the moment  -
no ARP, or DHCP, or Ping, or UDP, no frequency or phase words etc

If you want a stand alone solution then the Jeston or Shield becomes your
PC, and a very cost effective PC at that. However, I do accept that it's
not RPi prices :)

I'm working on a totally different hardware architecture that is along the
lines of a Hermes-Lite, with a small FPGA for I/O purposes, but with no
performance compromises.

Exciting times and just not enough hours in the day!

73 Phil..VK6PH

[Steve Haynal]

Hi Phil,

Since the last e-mail, I was only able to spend a little time on the gigabit interface this weekend -- too much going on. I haven't run into any logical bugs but have done only limited testing. Most of my work has been changes so that it will run on the CV A9. Here is a summary:

• I've carved out a standalone ethernet module. This allows quick turns with Quartus and simplifies testing.
• I removed the eeprom support and use static MAC and IP or DHCP.
• The CV A9 does not use the 125MHz clock from the PHY. I created a new PLL to generate the required clocks from the available 50 MHz oscillator.
• The CV A9 specifies a different PHY address as a strap option. I updated addresses in my copy of the code.
• I adjusted the delays on the PHY. The updated phy_cfg initialization is shown below. Note that I have a 1.68 ns clock skew for the RX signals. The CV A9 appears pretty sensitive to this and from experiments I must be in a window of +/- .12 ns. Also note that I updated the TX path to have 0 skew with no delay. The settings in your original code also had 0 skew, but delay was active (a value of 7 is no delay).
  
  

assign values[8] = {6'b0, allow_1Gbit, 9'b0};

assign values[7] = 16'h8104;

assign values[6] = {8'hc0, 8'h77};  //rx and tx clock delay, in 0.12 ns units to reg 104h, changed 25 Sept

assign values[5] = 16'h8105;

assign values[4] = 16'h0000; // no Rx pad skews, reg 105h

assign values[3] = 16'h8106;

assign values[2] = 16'h7777; // no Tx pad skews, reg 106h, added 25th Sept

assign values[1] = 16'h1300;

assign values[0] = 16'hxxxx;

• The CV A9 does not use the recommended reset circuit. I had to add appropriate reset and delays for PHY_RESET_N.

With these changes I am able to flood ping the CV A9 without packet loss for >250000 packets. I also verified that DHCP is working. What are some of the last few bugs I should be watching for? I am using your June 20 drop and can test a later release if you like.

I also refactored the Hermes-Lite RTL so that the ethernet interface is organized in similar standalone fashion to the new interface. My intent is to interface the new ethernet MAC with the old protocol at the UDP fifo level (no new sdr_send and sdr_receive). Do you see any problems with that approach?

How do you plan to handle 100 Mbits/s in the new RTL?

73,

Steve

KF7O

On Mon, Jul 20, 2015 at 8:09 PM, Phil Harman <ph...@pharman.org> wrote:

Hi Steve,

 

Just returned home from my overseas holiday and catching up on the email backlog.

 

All noted regarding your comments below.

 

How are you progressing with porting the Gigagbit MAC/UDP code to the CVA9 please.  I noted you had made some changes to the timing and also compensated for PCB tracking changes in relation to the PHY.

 

I would appreciate if you could let me know what changes you have made since this could be of great assistance in tracking down the last few bugs in the Gigabit code.

 

Thanks.

 

73 Phil...VK6PH

[Steve Haynal]

Hi Phil,

Attached is the .sdc file I am using. It is derived from yours, and like yours follows the Altera's AN477 closely. One difference is the PHY input delays. Mine match AN477 and are:

#PHY Data in 

set_input_delay  -max 0.8  -clock virt_PHY_RX_CLOCK [get_ports {PHY_RX[*] PHY_DV}]

set_input_delay  -min -0.8 -clock virt_PHY_RX_CLOCK -add_delay [get_ports {PHY_RX[*] PHY_DV}]

set_input_delay  -max 0.8 -clock virt_PHY_RX_CLOCK -clock_fall -add_delay [get_ports {PHY_RX[*] PHY_DV}]

set_input_delay  -min -0.8 -clock virt_PHY_RX_CLOCK -clock_fall -add_delay [get_ports {PHY_RX[*] PHY_DV}]

Yours are:

#PHY Data in 

set_input_delay  0.8  -clock virt_PHY_RX_CLOCK {PHY_RX[*] RX_DV}  

set_input_delay  0.8  -clock virt_PHY_RX_CLOCK {PHY_RX[*] RX_DV}  -clock_fall -add_delay

This is equivalent to -min 0.8, not -min -0.8. It may not matter much, but the AN477 constraints are a bit tighter. I do have some hold violations on the RX paths though. I will eventually have to tweak the phase of the virtual RX clock to match the skews I am setting in the PHY.

So far the failures I've seen are all or nothing. Maybe I will see what you are seeing once I start sending more data. When you see receiver problems, does ping flood still show no dropped packets?

sudo ping -f -c 50000 <ipaddress>

73,

Steve

KF7O

On Tue, Jul 21, 2015 at 12:10 AM, Phil Harman <ph...@pharman.org> wrote:

Hi Steve,

 

Thanks for this, much appreciated. 

 

Have you made any changes to the sdc file or have you  created your own?  If so I would appreciate a copy since I’ve still a lot to learn since although the current settings give timing closure I’m not confident that the process I’ve used is correct.

 

The main issue I have is that I can make a trivial change to the code (say change the code version) and one of more receivers will no longer work.

 

I have a version of the new MAC code that will auto select between 100/1000T based on the connect speed or you can force 100T mode via a jumper.

 

I wanted to get the basic 1000T working first before I add that feature but I does appear to work correctly and will provide you with  copy once I satisfied it works OK.

 

I missed the fact that that the Tx delay was active so will fix that now.

 

Very good idea to use the new PHY code with the current protocol.  I  may have to do the same if I can’t fix the current instability bug.

 

Thanks for your input.

 

73 Phil...VK6PH

 

[Steve Haynal]

Hi Phil,

I am very surprised that changing the rxc_pad_skew has no effect for you. The only values that work for me are C and D.

With the dp83848 on the WaveShare, I did not see some timing errors until I used ping flood. Only when 50000+ ICMP packets were sent at a high rate would I start to see some loss. Are you using ping flood? I think it is only easily available under Linux.

73,

Steve

KF7O

On Tue, Jul 21, 2015 at 10:07 PM, Phil Harman <ph...@pharman.org> wrote:

Hi Steve,

Thanks for the update. I'll have a look at the PHY input delays as you
suggest.

I made the changes to the PHY Tx configuration to match yours but it had
no effect.

I find I can vary the Rx clock phase from 0 to F and it makes no
difference to the operation of the code.

The ping reply seems hit and miss, sometimes it will not respond  but the
rest of the code runs OK and others it will work but some of the receivers
will fail.

I found that with just the Network code implemented then ping and DHCP
would run just fine, it was not until I added the bulk of the Rx and Tx
code that ping would sometimes not respond.

73 Phil...VK6PH

[Steve Haynal]

Hi Phil,

You can start the TimeQuest timing analyzer and load different SDC files for the same design run. This is how I verified the difference in the SDC constraints.

Tonight I started sending some UDP traffic from the FPGA to figure out how the TX interface works. I'm seeing the packets as expected with Wireshark. With this UDP traffic being sent, I can still flood ping the device without packet loss for 500000+ packets. Hopefully this weekend I will hook up the SDR portion and may then see similar problems to yours. I will let you know how it goes.

73,

Steve

KF7O

On Wed, Jul 22, 2015 at 5:35 AM, Phil Harman <ph...@pharman.org> wrote:

Hi Steve,

 

Thanks for the sdc file. I tried the same PHY data in settings that you are using but it did not make any difference.  My understanding was that If setup and hold delays are equal then only need to specify once without max or min.  However, I’ve still a lot to learn regarding sdc settings so will use the individual settings as you are to be 100% sure.

 

I have a version of code that appears to run 7 receivers OK (put ping not working).  As a complete check I need to modify KK so that I can individually set the frequency of each receiver.

 

73 Phil...VK6PH