OpenCores

OpenCores

or1ksim: ETE bit in DMR1

no use

no use

1/2

Next

Last

or1ksim: ETE bit in DMR1 by Unknown on Feb 2, 2004			Not available!
The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description? Heiko The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description? Heiko

or1ksim: ETE bit in DMR1 by Unknown on Feb 2, 2004			Not available!
----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Monday, February 02, 2004 10:21 AM Subject: [openrisc] or1ksim: ETE bit in DMR1 [q] The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description?[/q] Yes. I'm also thinking to simply a couple of things. This would of course mean some modifications on your side (or1ksim). Would this be OK? regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Monday, February 02, 2004 10:21 AM Subject: [openrisc] or1ksim: ETE bit in DMR1 The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description? Yes. I'm also thinking to simply a couple of things. This would of course mean some modifications on your side (or1ksim). Would this be OK? regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 2, 2004			Not available!
[q]The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description?[/q] Yes. I'm also thinking to simply a couple of things. This would of course mean some modifications on your side (or1ksim). Would this be OK?[/q] Sure. That would of course mean some modifications on your side (the architecture manual). ;-) In particular, I've been wondering if it would be possible to make the watch point chaining optional. Also, the ETE bit could be ignored, and any breakpoint which is enabled in DMR2[WGB] would cause a trap exception. What simplifications have you been thinking about? Heiko The ETE bit is not implemented yet. I just want to verify that I understand it right and that it's implemented in that way in the HDL. If a DVR/DCR combo matches the current processor status, and its chain criteria is met, a watchpoint is generated. If the watchpoints' WGB bit in DMR2 is set, a breakpoint is generated. The breakpoint itself nas no meaning and nothing will happen as a direct result of a breakpoint. Only if ETE is set, a breakpoint will generate a trap exception. So without ETE set, all debug unit logic has no effect (except for Single-step trace / Branch trace). Is that an accurate description? Yes. I'm also thinking to simply a couple of things. This would of course mean some modifications on your side (or1ksim). Would this be OK? Sure. That would of course mean some modifications on your side (the architecture manual). ;-) In particular, I've been wondering if it would be possible to make the watch point chaining optional. Also, the ETE bit could be ignored, and any breakpoint which is enabled in DMR2[WGB] would cause a trap exception. What simplifications have you been thinking about? Heiko

or1ksim: ETE bit in DMR1 by Unknown on Feb 2, 2004			Not available!
[q] Sure. That would of course mean some modifications on your side (the architecture manual). ;-)[/q] Of course. This shouldn't cause ny inconvinience to nobody since AFAIK nobody implement this part of debug specification. [q] In particular, I've been wondering if it would be possible to make the[/q] Chaining already is optional. If you don't enable it then every condition is separate and can form it own watchpoint. [q] watch point chaining optional. Also, the ETE bit could be ignored, and[/q] Wouldn't this cause some confusion when ETE is used and when not? [q] any breakpoint which is enabled in DMR2[WGB] would cause a trap exception. What simplifications have you been thinking about?[/q] For example one thing I have in mind is to make chains shorter. Ie no more than max up to 4 conditions per chain. This is to have a little faster hardware. regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] Sure. That would of course mean some modifications on your side (the architecture manual). ;-) Of course. This shouldn't cause ny inconvinience to nobody since AFAIK nobody implement this part of debug specification. In particular, I've been wondering if it would be possible to make the Chaining already is optional. If you don't enable it then every condition is separate and can form it own watchpoint. watch point chaining optional. Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? any breakpoint which is enabled in DMR2[WGB] would cause a trap exception. What simplifications have you been thinking about? For example one thing I have in mind is to make chains shorter. Ie no more than max up to 4 conditions per chain. This is to have a little faster hardware. regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 3, 2004			Not available!
[q]> Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not?[/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Heiko > Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Heiko

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]> Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't[/q] You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q] a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 [q] We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q] > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] > > Well, looks to me as if the ETE bit is redundant. I noticed some more > redundancy; the DP bit in the DCR registers. What is it good for?[/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q]> a single bit per watchpoint enough, enabling/disabling a trap[/q] exception? [q]> What other purposes are served by the second set of per-watchpoint[/q] bits, [q]> and by the all-encompassing ETE? > > If the manual is being reworked, I suggest a little terminology[/q] change. [q]> OR1K has these watchpoints that can be used to check various processor > conditions. But the term "watchpoint" generally refers to checking the > effective data load/store address only, and the term "Breakpoint" to > checking the program counter only. > So I suggest calling these registers "Checkpoint registers" or in[/q] short [q]> "Checkpoints". We should get rid of all occurences of "Breakpoint" and > "Watchpoint" in the manual. Instead of saying "Watchpoints generating > Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints[/q] generating [q]> Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q]> > Heiko > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" BKorsedal@bms-inc.com> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? > > Well, looks to me as if the ETE bit is redundant. I noticed some more > redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. > a single bit per watchpoint enough, enabling/disabling a trap exception? > What other purposes are served by the second set of per-watchpoint bits, > and by the all-encompassing ETE? > > If the manual is being reworked, I suggest a little terminology change. > OR1K has these watchpoints that can be used to check various processor > conditions. But the term "watchpoint" generally refers to checking the > effective data load/store address only, and the term "Breakpoint" to > checking the program counter only. > So I suggest calling these registers "Checkpoint registers" or in short > "Checkpoints". We should get rid of all occurences of "Breakpoint" and > "Watchpoint" in the manual. Instead of saying "Watchpoints generating > Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating > Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan > > Heiko > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
Heiko, I have attached debug chapter. Why don't you go and modify all the stuff you want to have it different and send it back to me and I'll throw in my modifications and if everybody is happy then we can freeze the debug unit spec and finish implementation in or1ksim and or1200. Is it a deal? Of course do not modify parts that are already in use, like DSR, DRR etc. FYI currently breakpoint exceptions are perfomed by replacing insn where breakpoint should occur with l.trap insn. So how l.trap causes exception and the DMR1[ST] should remain unchanged. regards, Damjan ----- Original Message ----- From: "Damjan Lampret" <<A HREF="mailto:lampret@opencores.org">lampret@opencores.org</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, February 04, 2004 3:51 AM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q] ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q] > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] > > Well, looks to me as if the ETE bit is redundant. I noticed some more > redundancy; the DP bit in the DCR registers. What is it good for? Isn't[/q] You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q]> a single bit per watchpoint enough, enabling/disabling a trap exception? > What other purposes are served by the second set of per-watchpoint bits, > and by the all-encompassing ETE? > > If the manual is being reworked, I suggest a little terminology change. > OR1K has these watchpoints that can be used to check various processor > conditions. But the term "watchpoint" generally refers to checking the > effective data load/store address only, and the term "Breakpoint" to > checking the program counter only. > So I suggest calling these registers "Checkpoint registers" or in short > "Checkpoints". We should get rid of all occurences of "Breakpoint" and > "Watchpoint" in the manual. Instead of saying "Watchpoints generating > Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating > Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al[/q] lthe [q] changes and you review them (this second alternative might take more time) regards, Damjan [q]> > Heiko > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] -------------- next part -------------- A non-text attachment was scrubbed... Name: openrisc_debug_chapter.doc Type: application/msword Size: 245760 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums/openrisc/attachments/20040204/6bfb2d45/openrisc_debug_chapter-0001.doc">http://www.opencores.org/forums/openrisc/attachments/20040204/6bfb2d45/openrisc_debug_chapter-0001.doc</A> Heiko, I have attached debug chapter. Why don't you go and modify all the stuff you want to have it different and send it back to me and I'll throw in my modifications and if everybody is happy then we can freeze the debug unit spec and finish implementation in or1ksim and or1200. Is it a deal? Of course do not modify parts that are already in use, like DSR, DRR etc. FYI currently breakpoint exceptions are perfomed by replacing insn where breakpoint should occur with l.trap insn. So how l.trap causes exception and the DMR1[ST] should remain unchanged. regards, Damjan ----- Original Message ----- From: "Damjan Lampret" lampret@opencores.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 3:51 AM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? > > Well, looks to me as if the ETE bit is redundant. I noticed some more > redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. > a single bit per watchpoint enough, enabling/disabling a trap exception? > What other purposes are served by the second set of per-watchpoint bits, > and by the all-encompassing ETE? > > If the manual is being reworked, I suggest a little terminology change. > OR1K has these watchpoints that can be used to check various processor > conditions. But the term "watchpoint" generally refers to checking the > effective data load/store address only, and the term "Breakpoint" to > checking the program counter only. > So I suggest calling these registers "Checkpoint registers" or in short > "Checkpoints". We should get rid of all occurences of "Breakpoint" and > "Watchpoint" in the manual. Instead of saying "Watchpoints generating > Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating > Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan > > Heiko > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- A non-text attachment was scrubbed... Name: openrisc_debug_chapter.doc Type: application/msword Size: 245760 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20040204/6bfb2d45/openrisc_debug_chapter-0001.doc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
<A HREF="http://www.opencores.org/projects/8051/">http://www.opencores.org/projects/8051/</A> ----- Original Message ----- From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>>; "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Thursday, February 05, 2004 12:24 AM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 [q] Are their any open source 8051 cores? We have a programmer here who loves[/q] the 8051, so if I can give him a soft 8051 @ 5 Mhz inside our FPGA, I think he would love it. [q] -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> on behalf of Bill Cox Sent: Wed 2/4/2004 12:01 PM To: List about OpenRISC project Cc: Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: [q]>Go with 8051 or something like that. I think there is no legal issues[/q] with [q]>8051. > >regards, >Damjan > >----- Original Message ----- >From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> >To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> >Sent: Wednesday, February 04, 2004 6:38 PM >Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 > > > > [q]>We need a very simple 8-bit microcontroller inside an FPGA. I've found >a few here on opencores, but I am not sure about their legality. Is >there any way the or1k can be reduced to an 8-bit version or would it be >easier to write an 8-bit microcontroller than used the or1k instruction >set? > >We want a completely legal 8-bit soft core with a good C compiler. Any >suggestions? > >-Brian > >-----Original Message----- >From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> >[mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret >Sent: Tuesday, February 03, 2004 2:52 PM >To: List about OpenRISC project >Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > > >----- Original Message ----- >From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> >To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> >Sent: Tuesday, February 03, 2004 6:07 PM >Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > > > > [q]>Also, the ETE bit could be ignored, and > > >Wouldn't this cause some confusion when ETE is used and when not? > >[/q] >Well, looks to me as if the ETE bit is redundant. I noticed some more >redundancy; the DP bit in the DCR registers. What is it good for? > >[/q] >Isn't > >You mean the DVR/DCR (Register Pair) Present? > >This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are >there. Yes if you implement configuration registers then it is >redundant. > > > [q]>a single bit per watchpoint enough, enabling/disabling a trap > >[/q] >exception? > > [q]>What other purposes are served by the second set of per-watchpoint > >[/q] >bits, > > [q]>and by the all-encompassing ETE? > >If the manual is being reworked, I suggest a little terminology > >[/q] >change. > > [q]>OR1K has these watchpoints that can be used to check various processor >conditions. But the term "watchpoint" generally refers to checking the >effective data load/store address only, and the term "Breakpoint" to >checking the program counter only. >So I suggest calling these registers "Checkpoint registers" or in > >[/q] >short > > [q]>"Checkpoints". We should get rid of all occurences of "Breakpoint" and >"Watchpoint" in the manual. Instead of saying "Watchpoints generating >Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints > >[/q] >generating > > [q]>Trap exception". > >[/q] >Sounds good. > >Lets agree how to change the documentation. Do you wanna go and change >the >way you like it and then I'm gonna add my changes, do should I make al >lthe >changes and you review them (this second alternative might take more >time) > >regards, >Damjan > > > [q]>Heiko >_______________________________________________ ><A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > >[/q] >_______________________________________________ ><A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > >_______________________________________________ ><A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > >[/q] > >_______________________________________________ ><A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > > >[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] http://www.opencores.org/projects/8051/ ----- Original Message ----- From: "Brian Korsedal" BKorsedal@bms-inc.com> To: "List about OpenRISC project" openrisc@opencores.org>; "List about OpenRISC project" openrisc@opencores.org> Sent: Thursday, February 05, 2004 12:24 AM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 Are their any open source 8051 cores? We have a programmer here who loves the 8051, so if I can give him a soft 8051 @ 5 Mhz inside our FPGA, I think he would love it. -----Original Message----- From: openrisc-bounces@opencores.org on behalf of Bill Cox Sent: Wed 2/4/2004 12:01 PM To: List about OpenRISC project Cc: Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: >Go with 8051 or something like that. I think there is no legal issues with >8051. > >regards, >Damjan > >----- Original Message ----- >From: "Brian Korsedal" BKorsedal@bms-inc.com> >To: "List about OpenRISC project" openrisc@opencores.org> >Sent: Wednesday, February 04, 2004 6:38 PM >Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 > > > > >We need a very simple 8-bit microcontroller inside an FPGA. I've found >a few here on opencores, but I am not sure about their legality. Is >there any way the or1k can be reduced to an 8-bit version or would it be >easier to write an 8-bit microcontroller than used the or1k instruction >set? > >We want a completely legal 8-bit soft core with a good C compiler. Any >suggestions? > >-Brian > >-----Original Message----- >From: openrisc-bounces@opencores.org >[mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret >Sent: Tuesday, February 03, 2004 2:52 PM >To: List about OpenRISC project >Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > > >----- Original Message ----- >From: "Heiko Panther" heiko.panther@web.de> >To: openrisc@opencores.org> >Sent: Tuesday, February 03, 2004 6:07 PM >Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > > > > >Also, the ETE bit could be ignored, and > > >Wouldn't this cause some confusion when ETE is used and when not? > > >Well, looks to me as if the ETE bit is redundant. I noticed some more >redundancy; the DP bit in the DCR registers. What is it good for? > > >Isn't > >You mean the DVR/DCR (Register Pair) Present? > >This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are >there. Yes if you implement configuration registers then it is >redundant. > > > >a single bit per watchpoint enough, enabling/disabling a trap > > >exception? > > >What other purposes are served by the second set of per-watchpoint > > >bits, > > >and by the all-encompassing ETE? > >If the manual is being reworked, I suggest a little terminology > > >change. > > >OR1K has these watchpoints that can be used to check various processor >conditions. But the term "watchpoint" generally refers to checking the >effective data load/store address only, and the term "Breakpoint" to >checking the program counter only. >So I suggest calling these registers "Checkpoint registers" or in > > >short > > >"Checkpoints". We should get rid of all occurences of "Breakpoint" and >"Watchpoint" in the manual. Instead of saying "Watchpoints generating >Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints > > >generating > > >Trap exception". > > >Sounds good. > >Lets agree how to change the documentation. Do you wanna go and change >the >way you like it and then I'm gonna add my changes, do should I make al >lthe >changes and you review them (this second alternative might take more >time) > >regards, >Damjan > > > >Heiko >_______________________________________________ >http://www.opencores.org/mailman/listinfo/openrisc > > >_______________________________________________ >http://www.opencores.org/mailman/listinfo/openrisc > >_______________________________________________ >http://www.opencores.org/mailman/listinfo/openrisc > > > >_______________________________________________ >http://www.opencores.org/mailman/listinfo/openrisc > > > _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
[q] So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception".[/q] Probably even better would be calling them "Matchpoint". Heiko So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Probably even better would be calling them "Matchpoint". Heiko

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]> Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for?[/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q] a single bit per watchpoint enough, enabling/disabling a trap[/q] exception? [q] What other purposes are served by the second set of per-watchpoint[/q] bits, [q] and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology[/q] change. [q] OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in[/q] short [q] "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints[/q] generating [q] Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
8051 Common as dirt. Rick Draganowski ----- Original Message ----- From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, February 04, 2004 9:38 AM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]> Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for?[/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q] a single bit per watchpoint enough, enabling/disabling a trap[/q] exception? [q] What other purposes are served by the second set of per-watchpoint[/q] bits, [q] and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology[/q] change. [q] OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in[/q] short [q] "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints[/q] generating [q] Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> 8051 Common as dirt. Rick Draganowski ----- Original Message ----- From: "Brian Korsedal" BKorsedal@bms-inc.com> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 9:38 AM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 4, 2004			Not available!
The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: [q]Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 [q]We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? [/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? [/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q]a single bit per watchpoint enough, enabling/disabling a trap [/q] exception? [q]What other purposes are served by the second set of per-watchpoint [/q] bits, [q]and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology [/q] change. [q]OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in [/q] short [q]"Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints [/q] generating [q]Trap exception". [/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q]Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" BKorsedal@bms-inc.com> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 5, 2004			Not available!
Are their any open source 8051 cores? We have a programmer here who loves the 8051, so if I can give him a soft 8051 @ 5 Mhz inside our FPGA, I think he would love it. -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> on behalf of Bill Cox Sent: Wed 2/4/2004 12:01 PM To: List about OpenRISC project Cc: Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: [q]Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" <<A HREF="mailto:BKorsedal@bms-inc.com">BKorsedal@bms-inc.com</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 [q]We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? [/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? [/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q]a single bit per watchpoint enough, enabling/disabling a trap [/q] exception? [q]What other purposes are served by the second set of per-watchpoint [/q] bits, [q]and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology [/q] change. [q]OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in [/q] short [q]"Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints [/q] generating [q]Trap exception". [/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q]Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> Are their any open source 8051 cores? We have a programmer here who loves the 8051, so if I can give him a soft 8051 @ 5 Mhz inside our FPGA, I think he would love it. -----Original Message----- From: openrisc-bounces@opencores.org on behalf of Bill Cox Sent: Wed 2/4/2004 12:01 PM To: List about OpenRISC project Cc: Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 The 8051 choice seems natural. Does anyone know if it's OK to clone PIC cores? I can't find anything on the topic either way, but the MiniRISC core on OpenCores looks promising for very small applications. Bill Damjan Lampret wrote: Go with 8051 or something like that. I think there is no legal issues with 8051. regards, Damjan ----- Original Message ----- From: "Brian Korsedal" BKorsedal@bms-inc.com> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 6:38 PM Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 Also, the ETE bit could be ignored, and Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or1ksim: ETE bit in DMR1 by Unknown on Feb 5, 2004			Not available!
PicoBlaze from Xilinx is very small, very fast and very simple. However, it has no C compiler and has very limited memory space. -philip -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Brian Korsedal Sent: Wednesday, February 04, 2004 12:38 PM To: List about OpenRISC project Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: <A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A> [mailto:<A HREF="mailto:openrisc-bounces@opencores.org">openrisc-bounces@opencores.org</A>] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 [q]> Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not?[/q] Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for?[/q] Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. [q] a single bit per watchpoint enough, enabling/disabling a trap[/q] exception? [q] What other purposes are served by the second set of per-watchpoint[/q] bits, [q] and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology[/q] change. [q] OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in[/q] short [q] "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints[/q] generating [q] Trap exception".[/q] Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> PicoBlaze from Xilinx is very small, very fast and very simple. However, it has no C compiler and has very limited memory space. -philip -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Brian Korsedal Sent: Wednesday, February 04, 2004 12:38 PM To: List about OpenRISC project Subject: RE: [openrisc] or1ksim: ETE bit in DMR1 We need a very simple 8-bit microcontroller inside an FPGA. I've found a few here on opencores, but I am not sure about their legality. Is there any way the or1k can be reduced to an 8-bit version or would it be easier to write an 8-bit microcontroller than used the or1k instruction set? We want a completely legal 8-bit soft core with a good C compiler. Any suggestions? -Brian -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org] On Behalf Of Damjan Lampret Sent: Tuesday, February 03, 2004 2:52 PM To: List about OpenRISC project Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Tuesday, February 03, 2004 6:07 PM Subject: Re: [openrisc] or1ksim: ETE bit in DMR1 > Also, the ETE bit could be ignored, and > > > Wouldn't this cause some confusion when ETE is used and when not? Well, looks to me as if the ETE bit is redundant. I noticed some more redundancy; the DP bit in the DCR registers. What is it good for? Isn't You mean the DVR/DCR (Register Pair) Present? This bit is there to tell the user (gdb, stub etc) how many DVR/DCRs are there. Yes if you implement configuration registers then it is redundant. a single bit per watchpoint enough, enabling/disabling a trap exception? What other purposes are served by the second set of per-watchpoint bits, and by the all-encompassing ETE? If the manual is being reworked, I suggest a little terminology change. OR1K has these watchpoints that can be used to check various processor conditions. But the term "watchpoint" generally refers to checking the effective data load/store address only, and the term "Breakpoint" to checking the program counter only. So I suggest calling these registers "Checkpoint registers" or in short "Checkpoints". We should get rid of all occurences of "Breakpoint" and "Watchpoint" in the manual. Instead of saying "Watchpoints generating Breakpoint" (as in DMR2[WPE] documentation) say "Checkpoints generating Trap exception". Sounds good. Lets agree how to change the documentation. Do you wanna go and change the way you like it and then I'm gonna add my changes, do should I make al lthe changes and you review them (this second alternative might take more time) regards, Damjan Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

no use

no use

1/2

Next

Last

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.