0% found this document useful (0 votes)
89 views

NetFPGA Tutorial 2 Spring2014

This document provides an overview of NetFPGA Tutorial 2. It discusses modifying the project.xml file to specify where to instantiate modules. It also describes hardware and software registers, with hardware registers being read-only from the Linux host and software registers allowing writing command line patterns for the NetFPGA to read. The document notes that the ids.xml file maps top-down in XML to right-to-left in the Generic_regs instantiation in IDS.v. It provides instructions for using the register addresses generated in reg_defines_IDS.h in the Idsreg.pl Perl script and possible causes of the 0XDEADBEEF problem.

Uploaded by

puneethkprocks
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
89 views

NetFPGA Tutorial 2 Spring2014

This document provides an overview of NetFPGA Tutorial 2. It discusses modifying the project.xml file to specify where to instantiate modules. It also describes hardware and software registers, with hardware registers being read-only from the Linux host and software registers allowing writing command line patterns for the NetFPGA to read. The document notes that the ids.xml file maps top-down in XML to right-to-left in the Generic_regs instantiation in IDS.v. It provides instructions for using the register addresses generated in reg_defines_IDS.h in the Idsreg.pl Perl script and possible causes of the 0XDEADBEEF problem.

Uploaded by

puneethkprocks
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 9

NetFPGA Tutorial 2

(Some slides are borrowed from NetFPGA summer camp)

Changing project.xml
<nf:memalloclayout="reference">
<nf:groupname="core1">
<nf:instancename="device_id"/>
<nf:instancename="dma"base="0x0500000"/>
<nf:instancename="mdio"/>
<nf:instancename="nf2_mac_grp"count="4"/>
<nf:instancename="cpu_dma_queue"count="4"/>
</nf:group>
<nf:groupname="udp">
<nf:instancename="in_arb"/>

<nf:instancename=IDS"/>

Specify where to
instantiate modules

<nf:instancename="strip_headers"/>
<nf:instancename="output_queues"/>
</nf:group>
</nf:memalloc>
</nf:project>

Hardware and Software


register
Hardware

register : The hardware


will write some values into a 32
bit register. This is READ ONLY
FROM LINUX HOST.
Software register : The Script
running on Linux will allow you to
write
some
command
line
patterns that NetFPGA can read
and use to do pattern matching.
It is READ ONLY FOR HARDWARE.

Ids.xml

Top Down in XML = Right to left in


Generic_regs instantiation in IDS.v

Generic Registers Module


DO NOT CHANGE !!!!

generic_regs # (
.UDP_REG_SRC_WIDTH

(UDP_REG_SRC_WIDTH),

.TAG

(`IDS_BLOCK_ADDR),

.REG_ADDR_WIDTH

(`IDS_REG_ADDR_WIDTH),

.NUM_COUNTERS

(0),

.NUM_SOFTWARE_REGS

(3),

.NUM_HARDWARE_REGS

(1))

DO NOT HARDCODE THESE


VALUES
BY GIVING SOME
NUMBER!

IDS_regs (
.reg_req_in

(reg_req_in),

.reg_src_out

(reg_src_out),

.software_regs ({ids_cmd,pattern_low,pattern_high}),
.hardware_regs

(matches),

The .h File

.h
.h

is generated in lib>C folder that consists


of latest addresses These might change
between every compilation run
USE THESE ADDRESSES IN
PERL SCRIPT

Idsreg.pl

SAME ADDRESS AS GENERATED IN


reg_defines_IDS.h

0XDEADBEEF
There

are many number of


reasons why 0XDEADBEEF
problem happens :

1. The address you read from might be wrong.


2. Connection to hardware/software register is not made
appropriately.
3. Improper definitions in xml or in ids.v generic regs
INSTANTIATION.

4. Logically , there might be some error Something


wrong in the code.

You might also like