6 replies to this topic

[gmadderley]

Repost from http://www.impulse-support.com/forums/inde...p?showtopic=333

Ok, I have a colleague here at UAH who also looked into some FSL info from you guys. I've looked at the uBlaze FSL examples (FIR, 3DES) but can't seem to figure out what the problem is.

I'm trying to build just a simple system a Producer that sends to a Filter in hardware via microblaze FSL and recieve back from the hardware via fsl. I've noticed the use of HW_STREAM_XXX instead of co_stream_xx on the software processes side. But I'm still not getting any communication between the hardware process and software process when implemented and downloaded in EDK.

Everything works once I remove all impluseC software code and build generic C code using microblaze fsl macro calls to my impulseC generated hardware. At the end of the day I can go with this solution but I'd really like to make the ImpulseC software code work in conjuction with the ImpulseC hardware via Microblaze FSLs.

Contact me at adderlg@uah.edu to set up an indepth discussion if needed.

----------------------
OK...I've paid close attention to the FIR FSL Example and still no lightbulb.

I've attached the codeveloper project folder. Just take a look and see if I have things on the impulseC side of the design in order. I have not generated a dual clock as I don't think I need one. Software simulation works accordingly. Hardware Simulation in CoDeveloper works accordingly.

Exporting and setting up EDK system with Microblaze with 2 FSL links and attaching and importing impulseC software seems to be where the problem lies.

Attached File(s)

•  uBlazeFSL.zip (2.56K)
  Number of downloads: 28

[gmadderley]

Earlier Post: http://www.impulse-support.com/forums/index.php?showtopic=30 since I am using EDK 7.1 tools.

[gmadderley]

Here are my findings pertaining to the EDK 7.1 Microblaze FSL and ImpulseC software processes issue.

First of all after upgrading to version 2.20.f.6, EDK build on the design completely flopped. After some digging, I've noticed you guys added an extra port to FSL design MPD files (SYS_RST). Unfortunately that signal is not declared or cannot be binded in the FSL VHDL component files generated, hence spitting out an EDK build error.

As for the microblaze fsl communication, (for 7.1) the step where you let the Base sytem builder create a TestPeripheral SW project, needs to be removed. Doing everything from scratch got the HW_STREAM_xx macros functioning. I had to create a SW Application Project in EDK, generate a linker_script changing the heap value to 0x0. Then add the ImpulseC software files.

[gmadderley]

Now that I've seen to find a solution for one problem another has arisen.

Putting the system under a hard reset destroys the system. Producer will run and Consumer again blocks, after four or five successive resets, multiple malloc fails are seen.

The quick solution I've found to that is that presently there seems to be no real need for HW_STREAM_CLOSE and co_stream_open or HW_STREAM_OPEN which appears to utilize some malloc function call.

Removing OPEN and CLOSE calls from the software fixes the reset system problem for the first hard five resets. According to another colleague that had reset issues also 5 resets seems to be the magic number before total anarchy.

Also it could be the co_stream_attach function call in the co_init.c file. Maybe doesn't take care of memory de-allocation (dump) upon reset. It is a possibility as I noticed the error message included in the co_stream_create function.

co_stream.c
#include "co.h"

#include <malloc.h>
#include <string.h>

co_stream co_stream_create(char * name, co_type datatype, int buffer_depth)
{
co_stream stream = malloc(sizeof(co_stream_t));
if ( stream != NULL ) {
stream->name = strdup(name);
stream->datatype = datatype;
stream->buffer_depth = buffer_depth;
stream->direction = CO_NO_DIRECTION;
stream->io_addr = 0;
} else co_msg_print("malloc failed!");
return stream;
}

void co_stream_attach(co_stream stream, int io_addr, co_stream_direction dir)

{
stream->io_addr=io_addr;
stream->direction=dir;
}



Again this is under
EDK 7.1, Codeveloper 2.20.f.6, and Virtex II V2MB1000 board.

[RalphBodenner]

Hi Michael,

It sounds like the reset issue is the main problem, but several different things seem to be going on:

1. malloc() fails

If malloc() is failing only after several resets, I would think that the cause would be improper reset handling by the MicroBlaze processor, or some kind of stack corruption problem. The malloc() function is provided by the MicroBlaze's C library, and if it is maintaining heap state between resets somehow, that could cause the heap to be over-allocated and malloc() to fail. The Impulse C driver assumes that a hardware reset "frees" all memory on the heap.

Which memory have you assigned the heap to in the linker script? How large is it? Have you tried putting the heap in a different memory?

2. SYS_Rst not connected

Have you tried connecting this port manually to the system reset signal in XPS?

3. HW_STREAM macros not working if tutorial steps followed

Not sure if I'm stating this one correctly, but is it true that if you ask XPS to create the sample software project and then replace that project's source code with the Impulse-exported source code, the stream macros don't work, but they do if you create a software project from scratch? Or are you saying that it's just not necessary to use a generated sample project as a base in XPS?

We're testing a fix for the reset issue in the lab and hope to have a comprehensive fix soon.

Ralph

[gmadderley]

1. Malloc() fails
That is understandable - microblaze control of heap that doesn't clear and ends up over-allocating. The heap and stack I normally leave as default to dlmb/ilmb when building a system from base system builder. Never tried assigning to another memory device. So basically its an EDK uBlaze issue. However, my end goal design is multi-microblaze and I haven't seen the malloc failed on reset of multi-microblaze running ImpC SW independently (just got that working yesterday) - but then again I probably need to run a numerous hard reset test to confirm it doesn't malloc fail on me. I've only done the hard reset about 5-6 times and didn't get any memory failure.

2. SYS_Rst
Yes I had SYS_Rst of my ImpC FSL HW peripheral connected to system_reset, and that's when the build error came into play. It could not find a port in the ImpC FSL HW VHDL to bind to system_reset. I just got confirmation of 2.20.f8 release to attempt to fix the FSL rst issue. I will give that a try and see if the build error occurs. But to get around that error before I go into the MPD file of the ImpC HW and remove the SYS_RST port.


3. HW stream macros
Your statement is correct. Here's my assumption: I am not sure what the settings are when a sample project is built, specifically heap settings in linker script. But building a software project from scratch and setting heap to 0x0 in linker script generation worked for me. I can probably narrow the issue down to the linker script. Maybe if I create the sample project when the system is built in base builder, then remove the files and add the ImpC SW file, go back into Generate Linker Script and generate a new linker script ensuring heap is set to 0x0. Now I know the question comes up why a setting for heap of 0x0. Well honestly, I don't know. It's something that stuck in my head after doing a random tutorial on building a software project in XPS. (Also, had to remove all stream open and close function calls in SW - design would not work with those included...go figure).

Hi Michael,

It sounds like the reset issue is the main problem, but several different things seem to be going on:

1. malloc() fails

If malloc() is failing only after several resets, I would think that the cause would be improper reset handling by the MicroBlaze processor, or some kind of stack corruption problem. The malloc() function is provided by the MicroBlaze's C library, and if it is maintaining heap state between resets somehow, that could cause the heap to be over-allocated and malloc() to fail. The Impulse C driver assumes that a hardware reset "frees" all memory on the heap.

Which memory have you assigned the heap to in the linker script? How large is it? Have you tried putting the heap in a different memory?

2. SYS_Rst not connected

Have you tried connecting this port manually to the system reset signal in XPS?

3. HW_STREAM macros not working if tutorial steps followed

Not sure if I'm stating this one correctly, but is it true that if you ask XPS to create the sample software project and then replace that project's source code with the Impulse-exported source code, the stream macros don't work, but they do if you create a software project from scratch? Or are you saying that it's just not necessary to use a generated sample project as a base in XPS?

We're testing a fix for the reset issue in the lab and hope to have a comprehensive fix soon.

Ralph

[gmadderley]

Sorry it took a little while, but here are my findings:

-2.20.f8 has indeed fixed FSL design resets (along with other items) and functions accordingly.

-I am able to do multiple hard resets without hitting malloc failed error with a multi-microblaze design with Impulse-C SW.

-Able to communicate through FSL using HW_STREAM_READ and WRITE macros (including co_stream_open and HW_STREAM_CLOSE calls).

-It appears the heap setting in Linker Script Generator could remain at the default of 0x400. Design works with default linker script settings.


As far as I can tell in my venture, everything is running and playing together as I expect and as Impulse-C expects.
Will prepare a white paper in the near future for those interested in multi-microblaze/Impulse-C designs.