OPENCORES.ORG

From: graham at imperas.com<graham@i...>
Date: Wed Sep 10 10:25:26 CEST 2008
Subject: [openrisc] Re: OpenRISC Digest, Vol 50, Issue 6

Hi, I work at Imperas with the technology released by OVPworld.org. Have you seen the demonstration of ucLinux running on an OR1K that has been made available on the OVP World site attachment-0001.htm> To: Date: Mon Feb 25 07:33:50 CET 2008 Subject: [openrisc] Re: OpenRISC Digest, Vol 50, Issue 6 > Hi all, > > I am an associate professor in an engineering school in Tunisia. We > are > trying to integrate OPEN RISC in the official courses. Thus we need > to do > some basic experiments (at least simulating linux with OR1K). I > consulted > many tutorials, all seems to be old and many files suggested does > not exist > in the actual CVS. > So, first of all I need to know if somone has tried the 0R1K in > Debian or > Ubuntu. The we would be very grateful if somone could provide us a > complete > package of The OR1k or OR1K2 simulation kit with a complete > tutorial. > Best regards. > Zied BEN SALEM PhD.Eng. > 2008/2/23, attachment-0001.htm> > > Content-Type: text/plain; charset=us-ascii > > > > > > i don't figure out the printf either. > > so i delete all printf in my code... > > > > > > Rahul Wagh wrote: > > > > > > Hi, > > > > > > As you might have seen, when we say > printf("....") in a OR1k testcase > > > written in C, it calls the printf routine written in > support.c file. > > That > > > does not give the actual printing of the message within > "..." though. > > > Anybody has tried that in OR1k ? Any suggestions / > pointers ? > > > > > > At my end, I figured out that the GPR R3 gets the > starting address of > > the > > > memory location where the message in printf is stored. > Using that, I > > wrote > > > a > > > small code in verilog monitor (or1200_monitor.v) to > access the memory > > > (till > > > you get an ASCII equivalent of NULL or something like > that) and display > > > the > > > things in %c format to get the message. However, this > helps only for > > > 'pure-text' type messages. It does not work for messages > like the > > following > > : > > > > > printf("Register value = %x",reg_value); > > > > > Can anybody throw some light on how to do this ? (How does one > track the > > location of the arguments passed to the printf > statement ? etc..) > > > > Thanks, > > > > > Rahul. > > > > > _______________________________________________ > > > attachment-0001.htm > > > > > > -- > View this > message in context: > attachment-0001.htm > Sent from the > OpenCores - RISC mailing list archive at Nabble.com. > > > > > ------------------------------ > > Message: 3 > Date: > Thu, 21 Feb 2008 01:06:17 -0800 (PST) > From: yueng > <attachment-0001.htm> > Subject: Re: [openrisc] or1ksim 's > question > To: attachment-0001.htm > Message-ID: > <attachment-0001.htm> > Content-Type: text/plain; > charset=us-ascii > > > thanks > the CPU core you > mentioned BA22 /BA14 is opensource free or commercial? > > > best regard > yeung > > > Matjaz Breskvar-5 wrote: > > > > > Hi Yeung, > > The or1ksim cycles count is not > very accurate, and even if you set the > > right > > > memory delays it is just a rough esstimation. > > Having said > that, the toolchain for OpenRISC is very unoptimized and the > > > OpenRISC itself is lacking in some areas. To improve all that > the Beyond > > Semiconductor was founded by the creators of > OpenRISC. First we have > > cosiderably optimized the > OpenRISC RTL, and the result is Beyond BA12 > > processor, > fully backwards compatible. Things that could not be improved > > > due > > to instruction set were addressed with Beyond > BA22 which features the > > world > > highest code > density and has ~55% clock-for-clock performance increase > > > comparing to OpenRISC (with optimized toolchain). > > > > > Another interesting product is BA14 processor, an out-of-order > dual > issue > > processor, which offers ~10x performance > comparing to OpenRISC. > > > > Currently we are in > discussion how to offer all this developments to > > comunity > in a way not to disturb the founding such development requires. > > > Hopefully things get wrapped up soon. > > > > > For more info on OpenRISC compatible processors (in the sense that > only > > sofware recompile is needed) and peripherals you may > visit our website > at: > > > > attachment-0001.htm > > > > > Yeung, please feel free to contact me, if you'd > like to evaluate > > performance > > of our processors > with optimized toolchains against ARM. Te results will > > be > > > much more favorable. > > > > best regards, > > > matjaz. > > > > > > > > * yueng > (attachment-0001.htm) wrote: > >> > >> thanks > > >> > >> i just want to compare or1k's > perfomance with arm7 or arm9, so i use > some > >> > algorithm ,for example > >> jpeg decode run both on or1k > and arm. to see which one use less cycles. > >> and my > result is or1ksim use 300M cycle and 200M instruction to finish > > a > >> 320x240 jpegdecode compared > >> with > arm7 50M cycle and 40M instruction. > >> > >> > > >> > >> Dimitri?s Orfanos wrote: > >> > > > >> > Oh, and something else. I am not a > maintainer of this project but > I've > >> > > involved because of my university has put me an assignment(actually > a > >> > master thesis). So by reading the code of the > or1ksim0.2.0 I have > >> > concluded that there is no > good measuring of cycles so I've done > >> > something > else. I've set on my own some CPI(clocks per instruction) > and > > >> > with little scripting I can see which commands > are executed (from the > >> > executed.log) and how > many times these commands are executed and I > >> > > calculate the total cycles of my own. For example I've set that the > > >> > "l.and" command uses 1 cycle if with > my little script sees that there > >> > are 3 > "l.and" I measure 3*1 total cycles. The simulator uses a > > >> scheduler > >> > which every n cycles > tries to communicate with virtual devices that > are > > >> > defined in the sim.cfg like keyboard, uart, etc . > These cycles are > also > >> > added in the > simulation cycles, so there is not so accurate. If you > > >> want > >> > to use the simulator for cycle > counting do something similar with me > >> > make a > little script and count the commands from the executed.log . > > If > >> > you just want to use the simulator to run > programs then you don't > need > >> > to count > cycles. > >> > DO > >> > > >> > > yueng wrote: > >> >> I change the sim.cfg , mem read > and write both delay 1. > >> >> i run jpeg decode in > the or1ksim > >> >> the result is > >> > >> 310,200,242 cycles, 171,816,396 instructions > >> > >> compare with arm7 it use only 56,000,000 cycle, and > 40,000,000 > >> >> instructions > >> > >> > >> >> i remember that i read or1ksim is > about 90% cycle accurate > somewhere, > >> >> > same jpeg decode C code ,why or1ksim use so many instructions? and > > so > >> >> many > >> >> cycles. > > >> >> > >> >> > >> > >> thank you > >> >> > >> > > _______________________________________________ > >> > > attachment-0001.htm > >> > > >> > > > >> > >> -- > >> View this message in > context: > >> attachment-0001.htm > >> Sent from > the OpenCores - RISC mailing list archive at Nabble.com. > > >> > >> > _______________________________________________ > >> > attachment-0001.htm > > > _______________________________________________ > > > attachment-0001.htm > > > > > > -- > View this > message in context: > attachment-0001.htm > Sent from the > OpenCores - RISC mailing list archive at Nabble.com. > > > > > ------------------------------ > > Message: 4 > Date: > Thu, 21 Feb 2008 14:27:43 +0200 > From: attachment-0001.htm > > Subject: Re: [openrisc] Printf using OR1K C test and verilog. > > To: attachment-0001.htm > Message-ID: > <attachment-0001.htm> > Content-Type: text/plain; > charset=ISO-8859-1; DelSp="Yes"; > > format="flowed" > > Hi, > > Maybe this helps: > > www.da.isy.liu.se/courses/tsea02 > lab0-4 > > hw_sw\lab0-4\hw\monitor\firmware\src\printf.c > Copyright 2001, > 2002 Georges Menie (www.menie.org) > > Regards, > > Laurentiu Duca > attachment-0001.htm > > Quoting Rahul > Wagh <attachment-0001.htm>: > > > Hi, > > > > > As you might have seen, when we say printf("....") > in a OR1k testcase > > written in C, it calls the printf > routine written in support.c file. > That > > does not > give the actual printing of the message within "..." > though. > > Anybody has tried that in OR1k ? Any suggestions > / pointers ? > > > > At my end, I figured out that the > GPR R3 gets the starting address of > the > > memory > location where the message in printf is stored. Using that, I > > wrote a > > small code in verilog monitor (or1200_monitor.v) > to access the memory > (till > > you get an ASCII > equivalent of NULL or something like that) and display > the > > > things in %c format to get the message. However, this > helps only for > > 'pure-text' type messages. It does not > work for messages like the > following > > : > > > > > printf("Register value = %x",reg_value); > > > > > Can anybody throw some light on how to do this ? > (How does one track the > > location of the arguments passed > to the printf statement ? etc..) > > > > Thanks, > > > > > Rahul. > > > > > _______________________________________________ > > > attachment-0001.htm > > > > -- > > This message > has been scanned for viruses and > > dangerous content by > MailScanner, and is > > believed to be clean. > > > > > > > > > -- > > > -- > This message has > been scanned for viruses and > dangerous content by MailScanner, > and is > believed to be clean. > > > > > ------------------------------ > > Message: 5 > Date: Thu, > 21 Feb 2008 14:33:50 +0200 > From: attachment-0001.htm > > Subject: Re: [openrisc] or1ksim 's question > To: Pier Francesco > Maria Santi <pfm.santi at elsydeng.com> > Cc: openrisc at > opencores.org > Message-ID: <20080221143350.vii0kq4n40gow008 > at mail.cs.pub.ro> > Content-Type: text/plain; > charset=ISO-8859-1; DelSp="Yes"; > > format="flowed" > > Hi, > > Maybe this helps: > > > > attachment-0001.htm > > > attachment-0001.htm > > attachment-0001.htm > > attachment-0001.htm > > attachment-0001.htm > > > attachment-0001.htm > > > I have ported lab1 from > > www.da.isy.liu.se/courses/tsea02 > to Digilent Nexys Board. > > > > Regards, > Laurentiu-Cristian Duca > > attachment-0001.htm > > > Quoting Pier Francesco > Maria Santi <pfm.santi at elsydeng.com>: > > > Hi > everybody. > > Anyone have a Windows complete toolchain for > OPENRISC? > > > > yueng ha scritto: > >> I > change the sim.cfg , mem read and write both delay 1. > >> > i run jpeg decode in the or1ksim > >> the result is > 310,200,242 cycles, 171,816,396 instructions > >> compare > with arm7 it use only 56,000,000 cycle, and 40,000,000 > > instructions > >> > >> i remember that i read > or1ksim is about 90% cycle accurate somewhere, > >> same > jpeg decode C code ,why or1ksim use so many instructions? and so > > many > >> cycles. > >> > >> > > >> thank you > >> > > > > > _______________________________________________ > > > attachment-0001.htm > > > > > -- > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > -- > > > -- > > This message has been scanned for viruses and > dangerous > content by MailScanner, and is > believed to be clean. > > > > > ------------------------------ > > Message: 6 > > Date: Fri, 22 Feb 2008 00:31:15 +0100 (CET) > From: rich_daddio > at yahoo.com > Subject: Re: [openrisc] Printf using OR1K C test > and verilog. > To: openrisc at opencores.org > Message-ID: > <20080221233115.9A250F00116 at www.opencores.org> > > > Hi, > I am not sure if this is what you are looking for but take > a look at > OpenRISC 1000 Architecture Manual under > "Function Calling Sequence" > and the table of > registers, and that might help you. > > > attachment-0001.htm > > > > HTH & Best Regards, > > Rich d > ----- > Original Message ----- > From: Rahul Wagh<rahul.wagh at > m...> > To: > Date: Wed Feb 20 09:14:25 CET 2008 > > Subject: [openrisc] Printf using OR1K C test and verilog. > > > > Hi, > > > > As you might have seen, when we say > printf("....") in a > > OR1k testcase > > > written in C, it calls the printf routine written in support.c > > > file. That > > does not give the actual printing of the > message within > > "..." though. > > Anybody > has tried that in OR1k ? Any suggestions / pointers ? > > At > my end, I figured out that the GPR R3 gets the starting address > > > of the > > memory location where the message in > printf is stored. Using that, > > I wrote a > > small > code in verilog monitor (or1200_monitor.v) to access the > > > memory (till > > you get an ASCII equivalent of NULL or > something like that) and > > display the > > things in > %c format to get the message. However, this helps only > > > for > > 'pure-text' type messages. It does not work for > messages like the > > following > > : > > > printf("Register value = %x",reg_value); > > Can > anybody throw some light on how to do this ? (How does one > > > track the > > location of the arguments passed to the > printf statement ? etc..) > > Thanks, > > Rahul. > > > > > > > > ------------------------------ > > > Message: 7 > Date: Thu, 21 Feb 2008 23:53:12 -0800 (PST) > > From: Yuping <3031133033 at zju.edu.cn> > Subject: > [openrisc] or1k's simulation > To: openrisc at opencores.org > > Message-ID: <15628960.post at talk.nabble.com> > > Content-Type: text/plain; charset=us-ascii > > > hi: > > I installed the toolchain :drp-0.6 toolchain (or32-elf-**) and goto > > orp_soc/sw/support/ fold and do make; next, I goto > orp_soc/sw/basic/ fold > and do make, it doesnot work, error > messages are: > > or32-elf-ld -T ../support/orp.ld basic.o > ../support/reset-nocache.o -o > basic-nocache.or32 > ../support/libsupport.a > basic.o: In function `_T7': > > basic.S:(.text+0x54c): undefined reference to `_exit' > > ../support/reset-nocache.o: In function `_start': > > reset.S:(.text+0xec): undefined reference to `_reset' > > ../support/libsupport.a(support.o): In function `_read_timer': > > support.c:(.text+0x94): undefined reference to `_gettimeofday' > > support.c:(.text+0xa4): undefined reference to `___mulsi3' > > ../support/libsupport.a(support.o): In function `_report': > > support.c:(.text+0xe0): undefined reference to `_printf' > make: > *** [basic-nocache] Error 1 > > > Does anybody encounter > this problem? I want to generate *.hex file and do > hardware > simulation, pls help me > -- > View this message in context: > > > attachment-0001.htm > > Sent from the OpenCores - RISC mailing list archive at > Nabble.com. > > > > ------------------------------ > > > Message: 8 > Date: Fri, 22 Feb 2008 02:00:48 -0600 > > From: "James Cotton" <peabody124 at gmail.com> > > Subject: [openrisc] debugger doesn't return from stepi > To: > "List about OpenRISC project" <openrisc at > opencores.org> > Message-ID: > > <a08e8e760802220000y6d165dbcu62ecb66e1855a2e2 at > mail.gmail.com> > Content-Type: text/plain; > charset=ISO-8859-1 > > I'm trying to get linux to boot up on > my spartan 3e / or1200 system. > I can load hello-world through > the jtag into SDRAM and receive it just > fine. However, when I > try and load up my kernel it loads fine, and > when I look at > the instructions about to be executed they are all > correct. > However, around when it tries to access the uart (as I said > > hello world works fine, so I know the address is right and working) > > gdb never returns after the stepi instruction. Specifically > it's a > l.sb to that register (when I've caught it). Even more > strangely, > when I then load hello-world it also locks up in a > similar way. > > So my question is, what sort of errors will > cause the debug interface > not to return from a stepi command. > Would this be characteristic of > something being set wrong with > a data/instruction cache? I can > simulate the same code (in > iverilog and or1ksim) and don't see a > problem. > > > > ------------------------------ > > > _______________________________________________ > OpenRISC > mailing list > OpenRISC at opencores.org > > attachment-0001.htm > > > > End of OpenRISC Digest, Vol 50, Issue 6 > > *************************************** > -------------- next > part -------------- An HTML attachment was scrubbed... URL: > attachment-0001.htm >