2 new UCF files for Xilinx ISE13.3 – Gullwing Bin file Builds

November 17th, 2011

-Tim Fairfield Senior FAE, Gennum Corp

Hi, This may have been a while coming but I have 2 new ucf files that can be used to build bin files of the Lambo code.

The history of this is that for ISE 10.x things worked fine but people were having issues with newer versions of the Xilinx ISE. It turns out after version 10.x Xilinx made timing corrections to the timing models and they are no more accurate. However that messed up builds as the early ucf was counting on the Xilinx timing to be accurate. We had made some fudge factor changes to get the early versions to work. So if you are using v10 ISE, do not change the ISE . For those using 12.x and higher you must use the new ucf. I have not tested for 11.x.

The first will work and all constraints will be met in the Xilinx ISE too for 100MHz builds. I have tested it to work up to 160 MHz without issues. I would recommend this if you are using GN4121 or do not need full 200MHz local bus.


The second UCF  will work up to 200 MHZ. The only issue with it is the Xilinx tool complains one time constraint fails. However after exhaustive testing over many days I see no issues as a result. So if you can live with this then this will work fr0m 100 to 200MHz.


While doing t testing, I managed to get some screenshots from the GN4124 Local bus P2L.  The P2L is DDR and as you can see the data is timed nicely at the 90 degree point of the clock.


200MHz LB Clk


200MHz LBI hold time Clk vs P2L_DATA1


100MHz LBI CLK vs P2L_Data1

100MHz LBI CLK vx P2L_Data1 hold time


GN4124 FMC Carrier boards now commercially available from 2 Vendors!

November 16th, 2011
-Tim Fairfield Senior FAE, Gennum Corp


If you thought Pico-Computing had a slick GN4124 implementation then you will like this one too. The code is open source, the boards are already made! What more could you ask for to jump-start your design.

Developed at Cern using Wishbone Architecture

The spec board is Featured in:


SPEC FMC Carrier, GN4124 seen under green dot




Available from Seven Solutions in Spain:


and available from Creotech in Poland




One example of its use today is for use with White Rabbit Timing Module: High Accuracy timing network (2000 nodes, 10 km, 1 nsec precision all over the place). Can be used to record synchronized measurements.


Or http://www.ohwr.org/projects/white-rabbit/wiki






GN4124 used on off-the-shelf M502 Pico Computing SuperComputing Modules

November 15th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

These modules have been available for some time. I figure the community would be interested in seeing some of the cool apps GN4124 has been used in.

Configurable, customizable, and scalable.

Pico Computing M-Series modules enable very high levels of FPGA computing performance, and allow you to configure your acceleration system to exactly match the requirements of your algorithm. The EX-500 board can be equipped with up to six M-Series modules.

See the GN4124 Marked in Green dots .



In the fully loaded card, 6 modules can be used (4 are shown here) A total of 12 GN4124 are used



See them at the  Supercomputing show Seattle Wa Nov 12-18 2011 booth# 2300.




Easy customization and Generation of GN4124 I2C hex file for Production

August 19th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

When you are ready for production you may need to modify some values such as subsystem ID Vendor ID and maybe starting clock parameters. Manually programming the I2C by bit addressing can be a bit confusing but I will show you an easy trick to get the Job done painlessly.
I take advantage of the I2C programming menu, in particular, program the I2c with default value feature.
You will have to have the ability to recompile Gendiag, so if in Linux you need the environment setup or if in windows have the Jungo tools installed and Microsoft compiler.

For this example we will add a subsytem id and vendor id to the eeprom hex file. Then this hex file can be used to pre-program your I2C at the manufacture stage during production.

In order to change the subsytem id we will want the PCIe config space to be modified at 0x2E

GN4124 Family Manual Subsys ID reference


First we will look at the original unmodified (click images to see larger view) :

EEPROM contents before

And the hex file content:


Here is the default value source file which should be modified, we will set the subsystem id to 1235 and leave the subsystem vendor ID the same 1A39 .

Source file for GN4124 default eeprom values


If you dont have a subsystem vendor id and you are not a member of PCISIG and need on for your GN4124 design , Gennum can assign you one. You simply need to contact Gennum for a subsystem ID agreement. You sill Use Gennums Vendor ID but will have your own unique subsystem device ID.

Now simply build and run this modified version of Gendiag. go to the I2C menu , save thenew defaults to the eeprom, then save the eeprom to the new hex file.

Steps for saving new defaults to hex file


Now the hex file will have the correctly formatted entries and this hex file can be used for production.

New hex file with new entry correctl;y formatted


If you reboot you will see the new subsystem ID


New Subsystem ID in Gendiag

There it is , folks!






Is pin swapping allowed for GN4124 PCIe lanes?

May 27th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

This is a common question I receive for support for board layout.
Q: Is pin swapping allowed for GN4124 PCIe lanes?

A:You can do lane reversal as it is required by the PCIe spec and GN4124 supports it.
you can map like this
lane0 -> lane3
lane1 -> lane2
lane2 -> lane1
lane3 -> lane0

As long as they are in ascending or descending consecutive order you are fine.

The P an N of each pair can be inverted. For the purpose of routing, P and N have no meaning.
so :
lane0p can map to lane0n
lane0n can map to lane0p

Remember that the source ASIC TX maps to the destination ASIC RX
I have seen on occasion designers confised based on the way some bus standards express it.
(PCIe cable actually swaps them in the cable!)
If you remember to check end to end that Tx maps to Rx you will be correct.


PCIe MSI Interrupt Generation with the GN4124 – A Lab example with Agilent PCIe Analyzer Captures

March 17th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

Recently there has been more demand in regards to Generating MSI’s (Message Signaled Interrupts) in applications using GN4124. The following is a comparison of legacy interrupt generation versus MSI interrupt generation and how to configure the GN4124 to send out the correct vectors.

I have recently had a handful of customers each running a different Operating System and required some assistance to get the MSI up an running. One customer was using Windows, Another running Mac OS Snow Leopard and the other Linux. The following is an experiment I carried out to demonstrate the functionality. Phase 1 demonstrates the setup and triggering of Legacy Interrupts and MSI. Phase 2 Describes what must be done in software to ensure the correct vector is generated.

While this entry discusses GN4124 specifics, it most likely will shed some light on the subject for anyone out there interested in PCIe MSI. I haven’t found much information to date showing an actual MSI being captured and demonstrated anywhere on the internet.

PHASE 1 Register Setup

A Windows XP system was used and the PCIe MSI mechanism on the GN4124 was tested. The goal was to test the silicon itself not the actual control software.
(Windows XP cannot do MSI natively) Windows XP was used to bring up the GN4124 into a known state.
2 Tests were performed:
1 to show Legacy interrupts
2.enable MSI messaging and emulate the stimulus to see that the messages were now being transmitted as MSI.

PCITree from http://www.pcitree.de was used to read/write and initialize registers. Any Memory Access application could be used.

An Agilent PCIe protocol analyzer was used to monitor and verify the traffic that was generated.

In PCIe, Legacy interrupts can be triggered by triggering on a PCIe Message code TLP. The analyzer will capture either Assert INT A or De-assert INT A depending on the interrupt type.
MSI messages will trigger differently. Memory writes and MSI look identical on a protocol analyzer.MSI and MSI-X requests are done using standard Memory Write Transactions, from section 2.2.7 of the PCI Express 2.0 Base Specification:
Message Signaled Interrupt (MSI/MSI-X) mechanisms use Memory Write Requests to represent interrupt Messages (see Section 6.1.4). The Request format used for MSI/MSI-X transactions is
identical to the Memory Write Request format defined above, and MSI/MSI-X Requests are indistinguishable from memory writes with regard to ordering, Flow Control, and data integrity.
For MSI Messages, We can trigger on a standard memory write, although as it mentions, it is indistinguishable from a regular memory write. One would need to specify the address that they are looking for.

In the EEPROM of the GN4124 RDK, the line that modifies 0x800 is set as follows.
0x800 0xXXXC_XXXX

The EEPROM Contents was as follows:
EEPROM content dump
1: 0xf808 = 0x0809f03c
2: 0xf808 = 0x0001f03c
3: 0xf05c = 0x00008002
4: 0xf060 = 0x00005840
5: 0xf850 = 0x00000028
6: 0xf800 = 0x000C5000
7: 0xffff = 0x00000000

The system was booted and the utility PCItree was run
The GN4124 was accessible and functioning.

MSI Capability was not enabled:
MSI disabled
0x48 should be 0xXXX0_XXXX or 0x0000_0000

To allow legacy interrupts on SW interrupt tests:
0x820 write 0x0000000F (actually only bit 3 needs to be set)

To assert a Software interrupt on the GN4124, write  0x814=0x0000_0004
The PCIe Protocol analyzer will show an Assert INTA message.
To perform a software interrupt deassert. Write 0x814= write 0x0000_0000
The PCIe Protocol analyzer will show a DeAssert INTA message.

Below is a capture when repeating the 0x814 writes

Click to Enlarge

NOTE: Useful Detailed Information on MSI registers can be found in this document:

To generate MSI,it must be turned on in EEPROM
The line that modifies 0x800 was set as follows.
0x800 0x000e5000, (it has been set to 0x000C_5000 in the default GN4124 RDK EEPROM)
This ensures MSI capability is turned on in the linked list. 0x48 is read by the bios that the MSI capability is present.
The entire EEPROM Contents was as follows:
EEPROM content dump
1: 0xf808 = 0x0809f03c
2: 0xf808 = 0x0001f03c
3: 0xf05c = 0x00008002
4: 0xf060 = 0x00005840
5: 0xf850 = 0x00000028
6: 0xf800 = 0x000e5000
7: 0xffff = 0x00000000

Check after the system boot that 0x48= 0x00805805
After boot write the following value:
0x48 = 0x00A5_5805

//this enables multiple messaging and enables MSI messages.
Even if only one interrupt source is used, multiple messaging is turned on to ensure proper function. If only one interrupt pin is used, the other vector sources can be masked off.

0x4c needs a test value in the address area for the MSI address (on Non-MSI Capable systems this is filled in manually for testing, this is usually filled by the system)

In this test, 0x4c is populated with 0x1234_5678. I populated a test value that wont get decoded by root complex, it will simply be ignored. In this test, this is placed outside of the upstream decode range. The PCIe analyzer will see this address and trigger on it when an MSI is sent. My goal is just to see that the event was triggered, as I am not testing the driver interrupt handling.
0x50 = 0x1234_5678 optional upper 64bit address
0x54= 0x0000_A5A0 Part of the MSI Message ( the last 4 bits of the vector are supplied by the interrupting source.)

Click to Enlarge

A write is performed, 0x820 = 0x0000000F, to enable Software triggered interrupts ( Designer will change this value to unmask whatever source creates interrupt in the end application)
In reality only 1 sw trigger source bit needed to be unmasked but more were set in this example. Usually only 1 bit is set as interrupt source.

To assert a Software interrupt, assert a write 0x814= 0x0000_0004
The PCIe Analyzer will capture a downstream memory write, (the setting of this bit) and an upstream memory write. This memory write is the MSI (No Assert INT A will be seen.) The data value in the memory write will be the MSI data value integrating also the vector of the source interrupt.
Then a software deassert is done. Write 0x0000_0000 to 0x814
The PCIe analyzer will not see a write, the interrupt is simply internally reset.

To repetitively test MSI output.
to sw assert write 0x000004 to 0x814
to sw deassert write 0x00 to 0x814
:goto loop

The PCIe analyzer will show memory writes every time a software trig is set.

To test the various vectors generated and see them reflected in the MSI data value. Set all MSI sources to allow sw trigger by setting the following
MSI source 0 0x820 –>0x0000_000F
MSI source 1 0x824 –>0x0000_000F
MSI source 2 0x828 –>0x0000_000F
MSI source 3 0x82C –>0x0000_000F

Click to Enlarge

A SW interrupt is asserted (which is hardwired to all of them). They all fired.
(Assert the SW interrupt by Writing the following: write 0x000004 to 0x814)

if the MSI data register 0x54 contains 0xa5a0 then the vectors that will be generated is as follows:
MSI source 0 0x820 sets vector 0xA5A0
MSI source 1 0x820 sets vector 0xA5A1
MSI source 2 0x820 sets vector 0xA5A2
MSI source 3 0x820 sets vector 0xA5A3

The PCIe analyzer captures the following:

Click to Enlarge

It was also tested to see that if 2 masks were turned off that those vectors would not be generated.
Set only 2 MSI sources to allow sw trigger by setting
MSI source 0 0x820 –>0x0000_000F
0x824 –>0x0000_0000
0x828 –>0x0000_0000
MSI source 3 0x82C –>0x0000_000F

Click to Enlarge

The result was as expected, only the 1st and last source fired and it can be seen that they provided the last 2 bit data information.

When 1 source was set at a time only one MSI was fired when asserting the Software test register and the data value matched the offset of which msi mask register was being used. Offset 0 and 2 are shown for an example:

Click to Enlarge

Click to Enlarge

PHASE 2 Sending the correct vector

Behavior for Single MSI interrupt source Setting: PCIe config space register 0x48 contains 0x0081_5805
MSI Data vector will appear to be Hardwired to 0x0 . Last 2 bits of MSI always forced to 0 regardless of MSI data value in register 0x54. In addition only int_cfg0 source will trigger an msi vector to be sent.
1. If MSI data= 0xXXXX_XXX1 and and interrupt is received on source configured by int_cfg0, an MSI is sent with vector 0xXXXX_XXX0
2. If MSI data= 0xXXXX_XXX2 and and interrupt is received on source configured by int_cfg3, an MSI is sent with vector 0xXXXX_XXX0
3. If MSI data= 0xXXXX_XX01 and and interrupt is received on source configured by int_cfg1, an MSI is sent with vector 0xXXXX_XXX0

Click to Enlarge

Behavior for Multiple interrupt source Setting: PCIe config space register 0x48 contains 0x00A5_5805
1. If MSI data= 0xXXXX_XXX1 and and interrupt is received on source configured by int_cfg0, an MSI is sent with vector 0xXXXX_XXX0
2. If MSI data= 0xXXXX_XXX2 and and interrupt is received on source configured by int_cfg3, an MSI is sent with vector 0xXXXX_XXX3
3. If MSI data= 0xXXXX_XXX1 and and interrupt is received on source configured by int_cfg1, an MSI is sent with vector 0xXXXX_XXX1

The problem: the user does not have control of what offset is populated in the MSI data field by the system. The MSI vector that is generated by the interrupt source must match the MSI data field vector that was populated by the system or the application may not see the vector.

Click to Enlarge

Workaround for a single pin interrupt source.
MSI must be set for Multiple interrupt sources or only source from Int_CFG0 will work and the last 2 MSI vector bits will always be 0b00. Do this by writing PCIe config space register 0x48 with 0x00A5_5805
A single pin interrupt source is most common and usually has a single pin connected to a GPIO input that is level triggered.
Register settings in the Int_cfg[3:0] (MSI interrupt source select] registers allow mapping of this pin interrupt source to any or all of the int_cfg sources.
The goal is to make sure the interrupt source will trigger the same data vector that the system has written to offset 0x54 (MSI_data register).
The driver should read that value and then configure the int_cfgx source that matches the required offset.

1. If MSI data= 0xXXXX_XXX1 and and interrupt is received on source configured by int_cfg0, an MSI is sent with vector 0xXXXX_XXX0
To remedy this, the int_cfg1 source should be set to select the interrupt source, All int_cfg0, 2 and 3 should be not have sources set. Now when the interrupt source fires, the vector offset will be 0xXXXX_XXX1 as expected.

Click to Enlarge

Finally here is the basic flow that should be followed when setting up MSI with the GN4124.

MSI register setup on GN4124 (Click for Complete Flow Chart)

I hope this sheds some light on the MSI interrupt mechanism.
until next time,

Low Cost FPGA-less PCIe Interfacing to the TMS320C674x/OMAP-L1x Processor Host Port Interface (HPI)

January 27th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

NO FPGA REQUIRED DESIGNS saves cost, debug time and board real-estate. Getting your DSP on PCIe bus couldn’t be simpler!
In another FPGA-Less example, this lab note shows you how to exploit some extra pins on the GN4124 to allow interfacing PCIe to the Texas Instruments HPI bus.
The GPIOs on the GN412x are used for the multiplexed Address /Data line. The FCL SPRI lines can also be used for 6 additional GPIO. The Local bus RX-Error is used as an input. It is ideal as an interrupt source and has been used in the past by designers who have forgotten to route an interrupt pin to a GPIO line from the FPGA. Finally the RSTOUT33 can be used as an output pin. All of these signals are accessible in GN412x Bar 4 register space.
The advantage of this design is NO FPGA and no CPLD glue logic, significantly simplifying layout and cost.
The GN412x can be connected to a PCIe x1 Intel Atom Processor for embedded and industrial applications.

(Click to Enlarge and click again to zoom) Interfacing To TI HPI

C6000 High Performance DSP
Refer to the table for Products which utilize the HPI interface.

Dynamic Configuration of Multiple FPGAs with PCIe and G4124/GN4121

January 19th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

In applications such as pin bed testers and high performance configurable computing, the need arises to be able to reconfigure multiple FPGAs on-the-fly. The GN412x family is well suited to this application. One of the most sought after features of the GN4124 is live reconfiguring of the FPGA. The FPGA flash is not needed in this application and the SPI interface is attached to the GN412x allowing the FPGA configuration data to be clocked into the FPGA. The diagram below expands on the single fpga implementation showing how multiple FPGAs can be reconfigured in a system. A CPLD is used for simplicity, and it handles the muxing and steering of the FPGA configuration signals. With the abundance of GPIO lines theoretically up to 65536 FPGAs could be loaded in sequence. However there are better ways of dealing with that many FPGAs.

Click for Larger Image

How to Perform Manual Disassembly of the GN4124 Discriptor Sequence code and Scatter Gather List

January 6th, 2011
-Tim Fairfield Senior FAE, Gennum Corp

I love cooking shows like Iron Chef (The Japanese version is the best) where they come up with cool names like Deconstructed Chocolate Schlock, and the like. It involves taking what normally goes together in a homogeneous mix and plating it in in its basic component form.

Well this is my own form I guess. One thing that is very important when writing the Host side software code is that you should be checking that the Sequencer code and the Scatter gather list (SG List) is what you intended. You need to verify that the ram buffer area is correctly populated in the GN4124 IP .

This is especially important when you have written software and debugged the heck out of it and your system still crashes when you go to do that DMA. Once you set the sequencer running it is going to execute independently of what the host software is doing and if you have some bad code in there, a bad program execution sequence or SGlist entries, you will have a heck of a time debugging.

Most people do not have the luxury of a PCIe analyzer which is usually my first weapon in my FAE bag of tricks.

Luckily I can show you a few tricks using our good friend PCItree and manually checking the code, along with that, if you are lucky enough that your host system doesn’t crash you can actually monitor the sequencer program counter and the present sglist entry that is being executed to give you a few clues.  In fact you can even halt the DMA and change the sequencer code and even write in your own NOPs, or stop your host software just before the code executes and rewrite everything using PCItree or your favorite memory editor, and then continue running.

This opens up a number of options to the debugger , which is always a good thing.

To begin you have to know the address wherethe host accesses bar 0.

Then you need to look at offset to bar 0 ram  where the host is placing the sequence code and the SGlist entries. This is usually offset 0x4000

Another use for this is working backwards to figure out how a particular data transfer is being done, so called reverse engineering, without having to look at what the host code has done.

When first inspecting the memory area you need to check:

  • The start address and the constants are correct and in the correct place.
  • The scatter gather list is of the correct length and contains valid host addresses
  • That the sequence code is gracefully terminated with a halt when done or a loop somewhere in the sequence  or even to itself.

(Click to enlarge) PCItree view of Descriptor memory aread showing Sequence code, and descriptor entries for each stream.

Steps to disassemble above sequencer code:
You will need to have the GN4124 FLEXDMA Sequencer Guide and memory dump of the code that is starting offset 0x4000, usually this is the start address unless the code start address has been changed.

Table 3.1 includes the instruction coding, that is, the top 4 bits of the sequencer instruction.

(Click to enlarge) Instruction Encoding

Decode this first. Then look up the commands for bit decoding for each instruction. Finally write down the decoded instructions in a spreadsheet.
Its a fairly simple process once you go through it once.

Here is a worked out example using a 2 stream with a single descriptor entry each.

(Click to enlarge, then click on it in browser to zoom in) This is a worked out step by step example of descriptor code from a previous blog entry re: DMA with Semaphore

A summary and description of the code flow can now be created.

(Click to enlarge, then click on it in browser to zoom in) This is a summary of the sequencer code flow that was created after disassembly.

Thats it for now, Happy diassembling.

Adding a Second DMA Upstream – a simple Semaphore Example

January 4th, 2011
-Tim Fairfield, Sr Fae Gennum Corp.

Need a starting point for a 2 stream upstream DMA? This article shows you how.

Code for this entry is here 2stream.rar

Gendiag shows single upstream example but some of you out there need more than 1 stream. The basics as presented here show where to get started. This requires modification in both the IP code and in Gendiag software source.

I have done some test to show 2 streams running to the host.

I have made some changes to dmatest_r0_9.cpp in my test version and the result is below.

Also in order to have something come back when reading stream 2, I have it hard coded to a single value. I have not put in a fifo or anything at this point. You will need to use the bin file in the archive for this. All I did was change stream 2 data value and rebuilt in Xilinx ISE.

as shown below.

(click to enlarge) Gendiag Example running showing 44 bytes stream 1 followed by a 4 byte semaphore

My output when running does this:

It runs, and I have bypassed the data compare tests since my values wont match.

It will do a small transfer from a pattern generator macro then send part of the semaphore on the last 4 bytes.

also you will see that when viewing bar 0 , there are 2 entries for the descriptor, I used PCITREE to show this.

(Click to enlarge) PCItree view of Descriptor memory aread showing Sequence code, and descriptor entries for each stream.

Attached is the bin file and the ldm.v and the dma ro9 code. When you run it, in unit test it is unit test 13. I may have hacked some other unit tests in the Gendiag source I have attached so just to test this out please keep in mind other tests may be modified or not work normally. This is my debug version.

(click to enlarge) Updated ldm.v file snapshot

void DMATest_R0_9::SingleDMAGen(void * DRam, UINT32 DRamSize, UINT64 kernelAddr, UINT32 DMABufferSize, UINT32 direction)


UINT64 location;

UINT16 size;

memset(DRam, 0, DRamSize);


UINT32 * buffPtr = (UINT32*) DRam;

/* RA holds the offset to the DMA entry */

/* Offset 0: SYS_ADDR_L */

/* Offset 1: SYS_ADDR_H */

/* Offset 2: XFER_CTL */

*(buffPtr) = VDMA_LOAD_RA(0xe);

*(buffPtr + 1) = VDMA_LOAD_SYS_ADDR(_RA,0);

*(buffPtr + 2) = VDMA_LOAD_XFER_CTL(_RA,2);

*(buffPtr + 3) = VDMA_LOAD_RA(0xf);//load addr of dma entry 2

*(buffPtr + 4) = VDMA_LOAD_SYS_ADDR(_RA,0);

*(buffPtr + 5) = VDMA_LOAD_XFER_CTL(_RA,2);

*(buffPtr + 6) = VDMA_SIG_EVENT(1,1,0×0); /* Stop VDMA */

/* Generate interrupt (event = 1) and halt VDMA */


*(buffPtr + 0xe) = 0x10; /* Offset to the first DMA entry */

*(buffPtr + 0xf) = 0x13; /* Offset to the first DMA entry */

size = DMABufferSize-4;

*(buffPtr + 0x10) = (kernelAddr) & 0xFFFFFFFF; /* SYS_ADDR_L */

*(buffPtr + 0x11) = (kernelAddr >> 32) & 0xFFFFFFFF; /* SYS_ADDR_H */

//CreateXferCtlInstruction(UINT8 c, UINT8 streamID, UINT8 direction, UINT8 xfer_en, UINT16 cnt)

//*(buffPtr + 0x12) = m_VDMA->CreateXferCtlInstruction(0, 1, direction, 1, DMABufferSize); /* XFER_CTL */

//timdebug stream 2, stream 2 is a static number that is returned from modified ldm.v in Lambo 0x0123456789ABCDEF

*(buffPtr + 0x12) = m_VDMA->CreateXferCtlInstruction(0, 1, direction, 1, size); /* XFER_CTL */

size = 4;

location = kernelAddr+DMABufferSize-4;

//semaphore dma

*(buffPtr + 0x13) = ( location ) & 0xFFFFFFFF; /* SYS_ADDR_L */

*(buffPtr + 0x14) = (kernelAddr >> 32) & 0xFFFFFFFF; /* SYS_ADDR_H */

//CreateXferCtlInstruction(UINT8 c, UINT8 streamID, UINT8 direction, UINT8 xfer_en, UINT16 cnt)

//*(buffPtr + 0x12) = m_VDMA->CreateXferCtlInstruction(0, 1, direction, 1, DMABufferSize); /* XFER_CTL */

//timdebug stream 2, stream 2 is a static number that is returned from modified ldm.v in Lambo 0x0123456789ABCDEF

*(buffPtr + 0x15) = m_VDMA->CreateXferCtlInstruction(0, 2, direction, 1, size); /* XFER_CTL */


VDMA_CodeGen_Init(DRam, DRamSize);


/* RA holds the offset to the DMA entry */

/* Offset 0: SYS_ADDR_L */

/* Offset 1: SYS_ADDR_H */

/* Offset 2: XFER_CTL */

/* Offset 3: dummy XFER_CTL */




SIG_EVENT(1,1,0×0); /* Stop VDMA */

/* Generate interrupt (event = 1) and halt VDMA */



CONST_WORD(0x10); /* Offset to the first DMA entry */

i = (kernelAddr) & 0xFFFFFFFF;


i = (kernelAddr >> 32) & 0xFFFFFFFF;


i = m_VDMA->CreateXferCtlInstruction(0, 1, direction, 1, DMABufferSize);