-
Notifications
You must be signed in to change notification settings - Fork 140
NetTM
- Status :
- Version :
- Authors :
- NetFPGA base source :
First, make sure that you installed the NetFPGA base properly (i.e. it is listed as a network device using ifconfig), that you can load a bitfile on the FPGA and verify that packets flow as expected through the design.
To run a program on the NetFPGA, you need to obtain the compiler package, install it, and run the sample applications. Once you establish that those applications work, you can move on to edit those applications or create your own.
Download from NetTM
The installation and compilation flow is the same as for NetThreads-RE (the compilation result is not binary compatible). Applications that ran on NetThreads should run on NetTM, with the caveats from the following section. For this reason, we did not include again the same benchmark for as in the original NetThreads release.
Since NetTM has split input and output packet buffer like NetThreads (but unlike NetThreads-RE), there should be very little code changes required to port an application to NetTM. The main aspect to keep in mind is that the lock identifiers have a meaning attached to each of them. In particular, looking in
support.hin
src/bench/common, the following lock identifiers:
#define LOCK_INIT 0 #define LOCK_PO_MEM 2 #define SENDING_LOCK 3 #define MALLOCFREE_LOCK 4
are non-transactional identifiers (e.g. normal).
#define LOCK_MISC 1
is not a lock identifier. Calling nf_lock() on this identifier will block the thread until a packet is available to be processed.
The other lock identifiers (5 to 15 inclusively) are transactional locks, meaning that nf_lock will trigger a transaction to start and nf_unlock, a transaction commit.
The choice of these identifiers is somewhat arbitary and can be changed at will when synthesizing the design.
As explained in the reference papers, 1 2, transactionally modified memory words are saved in a undo log. There is a provision of 1024 non-unique speculative writes per critical section (i.e. until the transaction commits), after which the undo log will overflow and bad things will happen. While this should be sufficient in the common case, we added hardware in the system to filter out of the undo log (i.e. those words don't count towards the 1024 words maximum) any transactional modification that is in the stack and below the stack pointer at the instant of checkpoint. For example,
main() {
nf_lock(TX_ID);
foo();
nf_unlock(TX_ID);
}
foo() {
int myvar;
for(i=0; i<5000; i++)
myvar =i;
}
The variable myvar will either create register accesses (in which case, there is no limitation on the number of modifications) or stack memory accesses. Since in this case, the stack pointer is lower than the stack pointer of the main() function, then all those accesses will not go to the undo log. This is correct because if a transaction abort occurs, we do not need to reset the uninitialized portion of the stack. If you are a computer scientist and are interested to count rollbacks or take different actions if a violation occurred, you are free to use this address space to store temporary data (you're doing so at you're own risk of course).
Non-transactional critical sections or packet I/O is not allowed inside transactional critical sections (aborting those transactions might lead to incorrect processor behavior). Transactions inside non-transactional locks are essentially ignored (i.e. the atomicity must be enforced by the regular lock). Transactions within transactions are safe and upon rollback, the processor re-executes from the outermost critical section.
Conflict detection is based around application-specific signatures (reference) . The signature used here is somewhat arbitrary as we have no way of knowing what would work best for your application without profiling it. The simulator in this package uses an ideal signature of infinite size.
Other versions of the processors exist (for example, single threaded and other new and more exciting features). There also exists an interface to trace processors as they run in hardware. If you have a serious interest in utilizing these other processors, or using the additional packages, please contact the authors. The source code can be made available.
We are always on the lookout for interesting applications to run on the NetFPGA: if you think that your program could be a good soft processor benchmark, please contact the authors.
For all NetFPGA-related problems, consult the NetFPGA forum.
Few hard-working researchers are involved in this project and unless you have a specific bug report regarding a specific piece of code that doesn't run the way it is expected to run, packaged in a way that we can easily reproduce, it is likely that we will not be able to assist you.