6 replies to this topic

[Brett]

First, the setup:
ml401 board
MemoryIO example integrated into platform
EDK/ISE 7.1

The only extra work needed in the normal toolchain process is to add void interrupt handlers to the exported software. I attach opb_memoryio as a busmaster (took a while to figure that out). After download the processes run, however the output isn't what it should be and isn't consistent. As far as I can tell nothing but garbage is being read back from memory. I have stuck some debugging sections into the software to try and determine when the memory block is being corrupted but to no avail. In fact, I find some completely bewildering behavior. Such as:

1. software "consumer" proceeding when the producer signal to the hardware module has been commented out. It should just hang.
2. With enough debug prints embedded I get a consistent output - the same data written into ram by the producer is printed out by the consumer. It is as though the hardware module never ran, but the consumer proceeds as if he had gotten the "done" signal.
3. if, after having run a scenario described in #2, I remove one set of prints and download, I will consistently get 1 correct execution, sometimes I can reset and get multiple correct executions up until about 5 resets by which time all designs I've tried lockup the board (different discussion). If I download again it will not work until downloading a setup from #2 and then repeat with this setup.

I realize this is rather vague, but it's got my head spinning and I'm not sure where to look next. I've already downclocked the design to 50MHz jsut in case I was tempting the threshold of the DDR controller. My next steps will be:

1. reconfigure the impulseC design to use internal bram and see if behavior can be replicated.
2. try to diagnose with chipscope

Any other ideas?

Brett

[Brett]

First, the setup:
ml401 board
MemoryIO example integrated into platform
EDK/ISE 7.1

The only extra work needed in the normal toolchain process is to add void interrupt handlers to the exported software. I attach opb_memoryio as a busmaster (took a while to figure that out). After download the processes run, however the output isn't what it should be and isn't consistent. As far as I can tell nothing but garbage is being read back from memory. I have stuck some debugging sections into the software to try and determine when the memory block is being corrupted but to no avail. In fact, I find some completely bewildering behavior. Such as:

1. software "consumer" proceeding when the producer signal to the hardware module has been commented out. It should just hang.
2. With enough debug prints embedded I get a consistent output - the same data written into ram by the producer is printed out by the consumer. It is as though the hardware module never ran, but the consumer proceeds as if he had gotten the "done" signal.
3. if, after having run a scenario described in #2, I remove one set of prints and download, I will consistently get 1 correct execution, sometimes I can reset and get multiple correct executions up until about 5 resets by which time all designs I've tried lockup the board (different discussion). If I download again it will not work until downloading a setup from #2 and then repeat with this setup.

I realize this is rather vague, but it's got my head spinning and I'm not sure where to look next. I've already downclocked the design to 50MHz jsut in case I was tempting the threshold of the DDR controller. My next steps will be:

1. reconfigure the impulseC design to use internal bram and see if behavior can be replicated.
2. try to diagnose with chipscope

Any other ideas?

Brett

It would appear that by modifying the signal being sent between the producer software process and the hawdware process to require a specific value (and spinning until it is received), that my problem has gone away. Now I can comment out the producer signal emit and the system will hang - just as it should. This is a fix that should be made to that example.

On a more troubling note, I'm at a loss as to why it continues to misbehave after a reset. My only explanation is that nothing is erasing the DDR memory and the signal is probably implemented that way - not sure, though. Probably need to read more.

FWIW,

Brett

[Brett]

It would appear that by modifying the signal being sent between the producer software process and the hawdware process to require a specific value (and spinning until it is received), that my problem has gone away. Now I can comment out the producer signal emit and the system will hang - just as it should. This is a fix that should be made to that example.

On a more troubling note, I'm at a loss as to why it continues to misbehave after a reset. My only explanation is that nothing is erasing the DDR memory and the signal is probably implemented that way - not sure, though. Probably need to read more.

FWIW,

Brett

Seeing the posting for the release of 2.20.f.4 I decided to start over with the vanilla example and try again (this time under edk 8.1). I get different behavior:

1. EDK 8.1 doesn't define MICROBLAZE so the software doesn't see the ext0_alloc function
2. Now the consumer hangs waiting for the signal from pe_run. Connecting in with XMD after the program starts and printing the first several memory locations reveals no change to the initialized values meaning that the pe_run hardware process has never run. So we've gone from the co_signal_wait() never waiting to it now never waking up.

Brett

[RalphBodenner]

Hi Brett,

The producer is blocking because the consumer hasn't started running yet. Unless you're running uClinux on the MicroBlaze (or some other multithreading OS with a Platform Support Package), processes run sequentially on the embedded processor.

I've reworked the MemoryIO example to use a single producer/consumer software process. The code is attached here, but I haven't had a chance to run it on an ML401 yet.

We're looking into the #define/ext_alloc problem with 8.1. Thanks for your detailed feedback, it's important for us to hear what difficulties you're running into.

Regards,
Ralph

Attached File(s)

•  MemoryIO.zip (36.93K)
  Number of downloads: 13

[Brett]

Hi Brett,

The producer is blocking because the consumer hasn't started running yet. Unless you're running uClinux on the MicroBlaze (or some other multithreading OS with a Platform Support Package), processes run sequentially on the embedded processor.

I've reworked the MemoryIO example to use a single producer/consumer software process. The code is attached here, but I haven't had a chance to run it on an ML401 yet.

We're looking into the #define/ext_alloc problem with 8.1. Thanks for your detailed feedback, it's important for us to hear what difficulties you're running into.

Regards,
Ralph

Tried updated example. No change in behavior. Still blocks waiting on signal back from pe_run and using XMD to connect via an MDM shows no change in shmem contents from initialized values. Just as before, I set "active-low reset" flag on the codeveloper options screen. I'm using the
"Xilinx Microblaze OPB (VHDL)" BSP.

Any ideas as to where I go next?

[Brett]

Tried updated example. No change in behavior. Still blocks waiting on signal back from pe_run and using XMD to connect via an MDM shows no change in shmem contents from initialized values. Just as before, I set "active-low reset" flag on the codeveloper options screen. I'm using the
"Xilinx Microblaze OPB (VHDL)" BSP.

Any ideas as to where I go next?

After looking at you previous post I'm even more bewildered. In both variants the consumer is obviously running because the "Waiting for signal..." printf is called.

Brett

[sekiyama]

Tried updated example. No change in behavior. Still blocks waiting on signal back from pe_run and using XMD to connect via an MDM shows no change in shmem contents from initialized values. Just as before, I set "active-low reset" flag on the codeveloper options screen. I'm using the
"Xilinx Microblaze OPB (VHDL)" BSP.

Any ideas as to where I go next?

Hello ImpulseC users:

I encountered the same problem as Brett did, when trying to run the updated version of MemoryIO design.
The software process (producer_consumer) hung waiting for signals from the hardware process (pe_run).
It seems pe_run failed to access the external memory.

I attached the ImpulseC and XPS project files (All the generated files have been deleted).
Any suggestions would be appreciated.

[design]
the single-software-process version of MemoryIO design (posted by Ralph on Feb. 27, 2007)

[Linker Script setting]
Heap and Stack area was set in the External Memory.

[tool versions]
CoDeveloper: 2.20.h.3
ISE: 8.1.03i
XPS: 8.1.02i

[board]
Memec Virtex-4 MB SX35 Development Kit (with 64MB DDR-SDRAM)

Regards,
sekiyama

Attached File(s)

•  MemoryIO.zip (17.13K)
  Number of downloads: 3