Hi,
I'd like to have some further details about the generate options when generating for the Microblaze/uCLinux platform. In the examples a dual clock is used every time. Is that required or is it also possible to let the peripheral run with the same clock rate?
Another thing I'd like to get explained is the FSL connection in EDK and in the fsl header file. In the examples the fast simplex links are simply connected in order but it is not explained in detail. I have a situation with 5 FSL links where fsl_v20_0 is used for the debug module and 1-4 are added manually. How do I find in which order they have to be connected to which FSL of the processor? Which FSL=X parameter do I have to use in the makefile (I assume 1)?
Could you please give some more details, especially about the restrictions for this platform and general design hints?
As mentioned before I created an application using 4 FSL which connect between two hardware and two software processes. The application starts and the first software process sends something to the first hardware process. Nothing happens for about 3 seconds and then the XMD reports a "pipeline stalled" error.
A smaller test application with 2 FSL connections between 1 hardware and 1 software process worked without problems.
Thanks in advance and best regards
Jarno Radde
Océ Technologies B.V.
Full Version: Generate options etc.
Hi Jarno,
In your 4-process project, it sounds like one software process could be stalling the other. On the MicroBlaze uClinux platform, only one software process can run at one time, since there is no built-in thread support in the Impulse C library for that platform. The second software process won't start until the first has exited, which of course may cause a permanent stall.
A single software process, using non-blocking stream reads (co_stream_read_nb) to consume data output from hardware, may offer a solution. You can generate a template project using this method from the File > New Project menu item. Select template #9, One-process testbench in the new project wizard.
As for the dual-clock option, it's only necessary if you cannot meet timing and need to clock down the Impulse core.
Regards,
Ralph
In your 4-process project, it sounds like one software process could be stalling the other. On the MicroBlaze uClinux platform, only one software process can run at one time, since there is no built-in thread support in the Impulse C library for that platform. The second software process won't start until the first has exited, which of course may cause a permanent stall.
A single software process, using non-blocking stream reads (co_stream_read_nb) to consume data output from hardware, may offer a solution. You can generate a template project using this method from the File > New Project menu item. Select template #9, One-process testbench in the new project wizard.
As for the dual-clock option, it's only necessary if you cannot meet timing and need to clock down the Impulse core.
Regards,
Ralph
Hi Ralph,
thank you for the reply. That explains a lot.
I'm currently trying a one software process application, unfortunately I still get a pipeline stalled error. I'm not sure what is the cause for it.
The scenario I have is made of 3 processes and 6 streams this time:
sw process <==> hw process 1 <==> hw process 2
It is basically some kind of ping-pong with one player in the middle. The software process generates a number, writes it to console waits a second, then writes it to the stream where it is supposed to be forwarded by the middle process to the last one, then modified and sent back. So after writing the software process immediately reads and tries to print it to console. The two hardware processes do it the other way round but without a delay. The read and write. All processes read / write only a single item, so I do not understand how a pipeline stalled can occur. In the simulation everything works fine. When I try it on the real hardware I can see that the first number was generated and sent, then the application is frozen for a couple of seconds till the pipeline stalled error shows up in the XMD.
All reads and writes are blocking I also thought that would be okay because I am working with single items. The examples with the non-blocking calls seemed only to be needed when working with pipelining or multiple elements which have to be read. Maybe I did not understand that correctly. I thought the blocking calls would just wait till there is something available to read and then go on working which should be okay because they are all running in parallel. Do you have any hints?
Best regards
Jarno Radde
Océ Technologies B.V.
thank you for the reply. That explains a lot.
I'm currently trying a one software process application, unfortunately I still get a pipeline stalled error. I'm not sure what is the cause for it.
The scenario I have is made of 3 processes and 6 streams this time:
sw process <==> hw process 1 <==> hw process 2
It is basically some kind of ping-pong with one player in the middle. The software process generates a number, writes it to console waits a second, then writes it to the stream where it is supposed to be forwarded by the middle process to the last one, then modified and sent back. So after writing the software process immediately reads and tries to print it to console. The two hardware processes do it the other way round but without a delay. The read and write. All processes read / write only a single item, so I do not understand how a pipeline stalled can occur. In the simulation everything works fine. When I try it on the real hardware I can see that the first number was generated and sent, then the application is frozen for a couple of seconds till the pipeline stalled error shows up in the XMD.
All reads and writes are blocking I also thought that would be okay because I am working with single items. The examples with the non-blocking calls seemed only to be needed when working with pipelining or multiple elements which have to be read. Maybe I did not understand that correctly. I thought the blocking calls would just wait till there is something available to read and then go on working which should be okay because they are all running in parallel. Do you have any hints?
Best regards
Jarno Radde
Océ Technologies B.V.
Hi Jarno,
From your description, your application sounds like it should work using blocking stream operations. Are you closing/opening the streams in a loop, once for each datum?
Could you send some code to support@impulsec.com that demonstrates the problem? Feel free to take out any proprietary computational code--as long as we can reproduce the issue in our lab, it will be much easier to diagnose.
Regards,
Ralph
From your description, your application sounds like it should work using blocking stream operations. Are you closing/opening the streams in a loop, once for each datum?
Could you send some code to support@impulsec.com that demonstrates the problem? Feel free to take out any proprietary computational code--as long as we can reproduce the issue in our lab, it will be much easier to diagnose.
Regards,
Ralph
Hi Ralph,
thank you for the response. I modified the code meanwhile (did not solve be problem but tried something else) but I think can re-create what I did before. Currently I am a bit busy but I will do it again and send you the code as soon as possible.
The loops I used in the hardware processes looked like that:
Best regards
Jarno Radde
Océ Technologies B.V.
QUOTE (RalphBodenner @ Apr 25 2007, 10:09 PM) 
From your description, your application sounds like it should work using blocking stream operations. Are you closing/opening the streams in a loop, once for each datum?
Could you send some code to support@impulsec.com that demonstrates the problem? Feel free to take out any proprietary computational code--as long as we can reproduce the issue in our lab, it will be much easier to diagnose.
Could you send some code to support@impulsec.com that demonstrates the problem? Feel free to take out any proprietary computational code--as long as we can reproduce the issue in our lab, it will be much easier to diagnose.
thank you for the response. I modified the code meanwhile (did not solve be problem but tried something else) but I think can re-create what I did before. Currently I am a bit busy but I will do it again and send you the code as soon as possible.
The loops I used in the hardware processes looked like that:
CODE
do {
co_stream_open(istrm, O_RDONLY, INT_TYPE(32));
co_stream_open(ostrm, O_WRONLY, INT_TYPE(32));
do {
err = co_stream_read(istrm, &data, sizeof(data));
// do something with data
co_stream_write(ostrm, &data, sizeof(data));
} while (!err);
co_stream_close(istrm);
co_stream_close(ostrm);
} while(1);
co_stream_open(istrm, O_RDONLY, INT_TYPE(32));
co_stream_open(ostrm, O_WRONLY, INT_TYPE(32));
do {
err = co_stream_read(istrm, &data, sizeof(data));
// do something with data
co_stream_write(ostrm, &data, sizeof(data));
} while (!err);
co_stream_close(istrm);
co_stream_close(ostrm);
} while(1);
Best regards
Jarno Radde
Océ Technologies B.V.
Hi Jarno,
If you get a chance, try closing the write streams first after the inner loop. Closing a read stream waits for the upstream writer to close; if everyone's closing their read-end first, there's a race condition that could cause deadlock. This may not be observed in desktop simulation due to how the separate processes' threads get scheduled.
Ralph
If you get a chance, try closing the write streams first after the inner loop. Closing a read stream waits for the upstream writer to close; if everyone's closing their read-end first, there's a race condition that could cause deadlock. This may not be observed in desktop simulation due to how the separate processes' threads get scheduled.
Ralph
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.