Hello,
I have had similar problems running the multiprocessor tutorial -
I got no text output in the IDE Console window, but the code appeared to be running as I could use debug mode and single step etc.
I am also using Quartus II 5.1 with Nios II 5.1, am using the Cyclone II Edition dev kit board and built a hardware design based on the Standard project.
I wondered if there was a cpuid problem, as that would cause problems for the 'generic' source code, which relies on the cpuid to tailor the program flow for specific CPUs (and more specifically, to perform the JTAG UART comms [only] on cpu1, as that is where the JTAG UART is assumed - by the supplied hello_world_multi.c source file - to be attached)
--- Quote Start ---
originally posted by paolo.gai@Jan 7 2006, 10:16 AM
...about the cpu 1 id... when you debug, you can find the cpu id in the register window of the debugger... what are the values for the three cpus?
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12032)
--- quote end ---
--- Quote End ---
So I ran the system in Debug mode, where it breakpoints at main() -
then single-stepped each CPU in turn until the CPUID control
register is read (via the macro call NIOS2_READ_CPUID(id) )
The following cpuid allocations were observed:
SOPC CPU Name -> cpuid register -> id variable (after the "id += 1;" )
cpu1 -> 2 -> 3
cpu2 -> 0 -> 1
cpu3 -> 1 -> 2
These values tie up with the NIOS2_CPU_ID_VALUE# defines that can be seen in the three 'system.h' header files, and the values in the system definition (.ptf) file.
--- Quote Start ---
originally posted by baycool@Jan 10 2006, 02:57 AM
however, in the tutorial my cpu 1 is assigned a cpuid = 0x2. i looked back over the tutorial, and this value is assigned by system. i am not sure how system makes this assignement but it is not based, i believe on the names of the cpu in sopc. this is where the potential for the bug lies.if you follow the tutorial you connect your jtag uart to cpu1 assuming that the system will assign cpu1= 0x0. if the system assigns another value to this register then you have a problem
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12079)
--- quote end ---
--- Quote End ---
So, for me, cpu1 was assigned cpuid = 0x2, as for baycool...
Therefore, it is the s/w executing on cpu2 that will run the
printf(...) code ; but cpu2 is not connected to the JTAG UART, so no output!
baycool's solution, to connect the JTAG UART to cpu2 instead of cpu1 is one workaround.
I tried modifying the software instead, so that it checked for an id variable value of 3, instead of 1 :
//if(id == 1)
// fudged code:
if(id == 3)
and this worked for me...
--- Quote Start ---
originally posted by paolo.gai@Jan 10 2006, 08:44 AM
the best thing imho would have been either to be able to assign the cpuid values directly, or to have a combo box in the mutex component.
in any case, the problems seems to be solved in nios ii 5.1 where it is clearly stated in a subnote of the mutex component (open sopcbuilder, insert a mutex component, giva a value != 0, and the note appears :-) ) that cpuids are assigned from 0 upwards following the cpu order in the sopcbuilder list.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12091)
--- quote end ---
--- Quote End ---
It would definitely be good if the CPUID values could be assigned in SOPC Builder!
Failing that, the CPUID value should be visible in SOPC Builder, rather than having to dig around in header files etc.
I see the subnote that paolo refers to, but it seems to be that CPUIDs are *not* being assigned "from 0 upwards following the CPU order in the SOPCBuilder list"
(at least for me and baycool!). I have cpu1, cpu2 and cpu3, in that order, top to bottom, in SOPC Builder.
I am using SOPC Builder 5.1 from the Quartus II 5.1 installation.
Anybody have any more insight into why SOPCBuilder is assigning CPUIDs this way?
Regards
Mike
Honored Contributor
