[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Parallella Community • View topic - What happens when eCores return? Can't reuse them w/o reset
Page 1 of 1

What happens when eCores return? Can't reuse them w/o reset

PostPosted: Tue Jul 30, 2013 12:01 am
by mipt98

Re: What happens when eCores return? Can't reuse them w/o re

PostPosted: Tue Jul 30, 2013 2:54 am
by ysapir
Iven,

Using the e_reset_system() API inside a tight loop is not the way to go. If you need quick cycles of program restart - then don't exit the program in the first place. Make it a "service" that runs in an infinite loop, waiting for a signal from the host to start crunching. The cost of writing a value to a mailbox on the core is the same as if writing the SYNC signal by e_start().

That said, there is also the e_reset_core() API that is faster (does not have the delay of the system reset), but is less safe in certain situations, and in addition, is required to be activated on each core in the group. BTW, if you want to reset a workgroup, then e_system_reset() is not appropriate anyway, as it will terminate whatever processes running on other workgroups.

Re: What happens when eCores return? Can't reuse them w/o re

PostPosted: Wed Jul 31, 2013 12:58 am
by mipt98
No problem, I can do it this way, thanks!

One more question, maybe actually a bug -- IVT doesn't get reset by system_reset(). In other words, if an interrupt has been registered (I'm meaning writing an instruction to IVT address manually) by some program it's impossible to clear it without accessing the register explicitly. Even rebooting the system doesn't help and one has to power off/on to bring IVT to the default state. I believe either system_reset() or e-reset should be able to handle it. Otherwise one always has to track what interrupt has been registered and when, it's very hard and bug prone.
-Ivan

Re: What happens when eCores return? Can't reuse them w/o re

PostPosted: Wed Jul 31, 2013 6:17 am
by ysapir
The IVT is just a section of the core's SRAM. SRAM is not being set or cleared by reset. Even if it were, then opcode 0 means "B 0x00000000", or branch to self. This is as meaningful just as any other opcode. The point is that at reset, the GID and IMASK registers are cleared, thus enabling all interrupts (and particularly, the SYNC int.), which is why we set the bits of IMASK during the program start phase. This happens in the epiphany_start() function which is a part of CRT0 and calls the user's main() function.

When you enable an IRQ line in your program (e_irq_mask()), then you should attach a valid ISR. This will ensure that the relevant vector is up-to-date and valid.