4 replies to this topic

[cenl]

Hi,

I'm still stuck with the genbus.tcl because of some design issues, so I'm moving on first to designing genlib.tcl for my psp.

From the Creating PSP Application note, i understand that co_init.c is the file that defines how the software processes access streams when the co_stream_open, co_stream_read, co_stream_write, co_steam_close functions are called. And the co_init.c is generated by genlib.tcl and impulse_lib.exe. Am i correct on this?

The board which I'm building the PSP for is the Nallatech BenNUEY-PCI-4E. The board can only be accessed through of one Nallatech's FUSE Interface:
1. Probe Tool (Java based GUI)
2. Tcl/tk plug-in
3. C/C++ Development API
4. DimeScript

A complete software application that controls the FPGA can be built using 2 or 3. For my PSP, I'm attempting to integrate the C/C++ Development API into the co_init.c file. For example, when the co_stream_write function is called in the software process, the co_init.c will use the equivalent write command from the C/C++ Development API. In this case, it would be:

viDIME_DMAWrite (viDIME handle, pointer to data location, word count, DMA channel, Timeout)

This is a bit of a workaround since the application can be developed with only 2 or 3. The reason i wanted to do this is to shield a new user from too many source code modification from the Impulse C programming environment.

Is what I'm trying to implement here feasible? If it is, could you give me some guidelines and ideas on how i should go about it.

Please advise.

Justin

[RalphBodenner]

From the Creating PSP Application note, i understand that co_init.c is the file that defines how the software processes access streams when the co_stream_open, co_stream_read, co_stream_write, co_steam_close functions are called. And the co_init.c is generated by genlib.tcl and impulse_lib.exe. Am i correct on this?

Yes.

The board which I'm building the PSP for is the Nallatech BenNUEY-PCI-4E. The board can only be accessed through of one Nallatech's FUSE Interface:
1. Probe Tool (Java based GUI)
2. Tcl/tk plug-in
3. C/C++ Development API
4. DimeScript

A complete software application that controls the FPGA can be built using 2 or 3. For my PSP, I'm attempting to integrate the C/C++ Development API into the co_init.c file. For example, when the co_stream_write function is called in the software process, the co_init.c will use the equivalent write command from the C/C++ Development API. In this case, it would be:

viDIME_DMAWrite (viDIME handle, pointer to data location, word count, DMA channel, Timeout)

This is a bit of a workaround since the application can be developed with only 2 or 3. The reason i wanted to do this is to shield a new user from too many source code modification from the Impulse C programming environment.

Is what I'm trying to implement here feasible? If it is, could you give me some guidelines and ideas on how i should go about it.

Yes, this is certainly feasible. Implementing the Impulse C API using the board's specific API is recommended for portability.

You can use the co_init.c to do any creating of viDIME and DMA channel objects, and storing those objects either in a custom version of the co_stream structure, or as global variables. Then co_stream_write and friends will be able to pass those objects to the Nallatech API as needed. The co_stream_attach function is used to associate things like addresses, handles, pointers, IDs, etc. with a particular stream.

The DIMEtalk PSP that ships with CoDeveloper does not include an Impulse C API implementation, but you can start with one from another PSP. The Pico E-14/E-16 PSP may be a good starting point.

Ralph

[cenl]

Thanks for your advise. I've been going through the Pico E-14/E-16 PSP and browsing through other available examples for genlib.tcl scripts. Even so, I still dont really a clear picture on how am i going to implement it. Hope you could fill me in on the questions below

Is it possible to automatically add codes to example_sw.c when compiling in Impulse C? I need to add a list of codes in the beginning that'll locate, open, configure and reset the FPGA card before data transfer and another list of codes at the end that'll close the FPGA card.

If it's not possible, then I'm thinking of putting all that codes in a C file which will be called by a function in example_sw.c.
So, the user will only need to add some single line function call and #include.
For example,

int main (int argc, char *argv[]) {
int param = 0;
co_architecture my_arch;

SETUP_FPGA;

my_arch = co_initialize(param);
co_execute(my_arch);

CLOSE_FPGA;
return(0);
}

What do you think? Please advise....

You can use the co_init.c to do any creating of viDIME and DMA channel objects, and storing those objects either in a custom version of the co_stream structure, or as global variables. Then co_stream_write and friends will be able to pass those objects to the Nallatech API as needed.

For the Nallatech Comm Core that I'm using, there are 5 specific functions that I'll use:

viDIME_Open - Returns a valid viDIME handle. On error returns NULL.
I'll add this to the SETUP_FPGA function

viDIME_Close - Closes down a valid viDIME handle.
I'll add this to the CLOSE_FPGA function

viDIME_DMAAbort - Terminates any DMA and resets the FIFOs within the Core.
link with co_stream_open and co_stream_close

viDIME_DMARead - Reads data from the FPGA to the PC
link with co_stream_read

viDIME_DMAWrite - Writes data from the PC to the FPGA
link with co_stream_write

However to use viDIME_DMARead and viDIME_DMAWrite i need to pass some the following arguments to it.
viDIME handle - from viDIME_Open
Data - pointer to the PC memory that receives data or contains the data to be written
WordCount - the number of words to be written
DMAChannel - The channel used to transmit or receive data
Timeout -

My concern is with the WordCount and the DMAChannel.
For the WordCount in DMAWrite, i think i can add codes to count the number of words to be written from co_stream_write.
For the WordCount in DMARead, maybe i can retain back the last word count value from DMAWrite?

For the DMAChannel, the way i coded the hardware wrapper is such that the first input and output stream will get channel 0 and will increment with the respective input or output streams. Looking at the genlib.tcl script, i guess this shouldnt be a problem either.

The Pico E-14/E-16 PSP implements a customized co_stream structure as specified in co_stream.c. If i were to follow this example, i would only need to change the co_stream.c. The two other common files are co_process.c and co_type.c but they look kinda similar in other PSP, so i assume i dont have to change anything there.

The co_stream_attach function is used to associate things like addresses, handles, pointers, IDs, etc. with a particular stream.

The Impulse C user guide states that the co_stream_attach function associates a stream object with a specific hardware location.

In the Pico E-14/E-16 PSP, the hardware location or the io parameter values starts with 10 and increments with a new stream. I'm not sure where the value 10 points to but i guess it is defined in some Pico library or header file? PicoStream.h? For my case, i think i'll be using the io parameter to associate the DMA channel value with the input/stream.

Looking at the example, co_stream_attach in co_init.c passes the stream object from example_sw.c to co_stream.c which uses that object to associate any reading or writing of that stream.

In a nutshell, I need to include the co_stream_attach statement in my genlib.tcl script with the appropriate DMA channel numbering as the io parameter. Then i need to modify the co_stream.c to define the data transfer procedures when any co_stream_read/write is called. The data transfer procedures must include a way i can count the data prior to actual data write, while the number of data to be read will retain the last value of the data count in data write.

Please comment and advise. Hopefully i got my understanding of the problem right.

Sincerely,
Justin

[RalphBodenner]

Is it possible to automatically add codes to example_sw.c when compiling in Impulse C? I need to add a list of codes in the beginning that'll locate, open, configure and reset the FPGA card before data transfer and another list of codes at the end that'll close the FPGA card.

Three Tcl procedures should be defined in your genlib.tcl, which you can use to insert code into the co_init.c file generated by the compiler: GenerateIncludes, GenerateBegin, and GenerateInit. Please see the "Impulse C Software Interface Generation API" HTML documentation for details on these.

In a nutshell, I need to include the co_stream_attach statement in my genlib.tcl script with the appropriate DMA channel numbering as the io parameter. Then i need to modify the co_stream.c to define the data transfer procedures when any co_stream_read/write is called. The data transfer procedures must include a way i can count the data prior to actual data write, while the number of data to be read will retain the last value of the data count in data write.

You can do this in GenerateInit by looping over the list of connections, finding the streams, and printing "co_stream_attach..." function calls for each one, incrementing the DMA channel number. Then make the changes to co_stream.c to implement the functions there in terms of the DIMEtalk API.

Regards,
Ralph

[cenl]

I've completed an draft code of the sw interface but i have a couple of questions to ask.
Before that, here's a brief explanation of what i've done so far:

[1] Copied the genlib.tcl and related files from the Pico E-14/E-16 PSP
[2] Edited genlib.tcl
- added co_attach_stream to link co_stream functions to the Nallatech functions
[3] Edited co.h
- commented out the functions that is not applicable
[4] Edited co_types.h
- changed the co_stream structure
[5] Edited co_stream.c
- changed the co_stream_write/read functions to suit the Nallatech DMA write/read functions
[6] Edited projectname_sw.c
- because of the nature of the Nallatech functions, i've defined two versions of co_stream_write/read
- One version for desktop simulation(IF_SIM) and the other for target platform compilation like Visual Studio(IF_NSIM)

I've compiled all the files in Visual Studio 2005 and did a simple dma data transfer test. It works well so far.

Questions
[1] Are the co_process_create and co_execute in co_process.c and co_process structure in co_types.h standard? Do i need to change these if i dont have any
specific requirements?
[2] This will sound silly. It is possible/Have you seen ppl implement more processes on the sw part for code segregation purposes? For example, Producer1 sends data to
Producer2 which in turn sends data to Filter 1 in hardware. If this was possible, i would need to redesign my sw interface to cater for such condition so that sw-
hw/hw-sw stream and sw-sw stream uses the correct function...right?

Please advise.

sincerely,
justin