1/1 
|
Das Boot
by jt_eaton on Apr 10, 2012 |
jt_eaton
Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018 |
||
|
The boot_adr_sel line is no longer an input port and is tied off to 1'b0. We do still need this line for systems that run from an external rom but still have a small bit of embedded code for test or debugging. You want an external signal to be able to make that selection.
Converting the boot_adr from a `define to a parameter was a good idea. We can now build a multicore system and each core can have their own code set. I will propose that we add a second parameter for alt_boot_adr that defaults to the boot_adr and is selected when boot_adr_sel line is high. That line should also be restored back as an input port at the top level. Why is the boot select logic located in the inst mmu? All it does is combine signals from the cpu with boot_sel_i to create a signal that goes back to the cpu. This logic should be moved into the or1200_cpu module. Any Comments? John Eaton |
|||
|
RE: Das Boot
by olof on Apr 10, 2012 |
olof
Posts: 218 Joined: Feb 10, 2010 Last seen: Dec 17, 2018 |
||
|
Hi John,
Converting the boot_adr from a `define to a parameter was a good idea. We can now build a multicore system and each core can have their own code set.
I changed it to a parameter to make it easier for simulators to start directly from a preloaded RAM and still be able to boot from a ROM on real systems. The multicore reasons however are as important, and we should put more effort into reducing the number of defines in the code. I've been working on that for some of the peripheral cores that usually are used in OpenRISC systems.
The boot_adr_sel line is no longer an input port and is tied off to 1'b0. We do still need this line for systems that run from an external rom but still have a small bit of embedded code for test or debugging. You want an external signal to be able to make that selection.
Is this something that was changed recently? I took a quick look at the SVN logs, but didn't see that it was removed from the port list
I will propose that we add a second parameter for alt_boot_adr that defaults to the boot_adr and is selected when boot_adr_sel line is high. That line should also be restored back as an input port at the top level.
Having a way to set an alternative address externally sounds good, but I guess that could also be implemented by using a small boot rom that checks a gpio and uses the result from that to decide where to jump. A bit more complicated, but avoids having to add another top-level signal
Why is the boot select logic located in the inst mmu? All it does is combine signals from the cpu with boot_sel_i to create a signal that goes back to the cpu. This logic should be moved into the or1200_cpu module.
I haven't the faintest idea why the code is located there, but I would guess it was done that way by the original authors and no one bothered to move it somewhere else -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: olof.kindgren@orsoc.se ______________________________________________ FPGA, ASIC, DSP - embedded SoC design |
|||
|
RE: Das Boot
by jt_eaton on Apr 11, 2012 |
jt_eaton
Posts: 142 Joined: Aug 18, 2008 Last seen: Sep 29, 2018 |
||
|
Is this something that was changed recently? I took a quick look at the SVN logs, but didn't see that it was removed from the port list Well it's gone now. I have no idea when it dropped out but we shouldn't change the top level footprint on a whim.
Having a way to set an alternative address externally sounds good, but I guess that could also be implemented by using a small boot rom that checks a gpio and uses the result from that to decide where to jump. A bit more complicated, but avoids having to add another top-level signal
I think we should have a design with several different options for the system architects. One size does not fit all and you don't want the users to have to force their designs into one mode.
I haven't the faintest idea why the code is located there, but I would guess it was done that way by the original authors and no one bothered to move it somewhere else
That usually what happens. After you finish any design you need to go back and "refactor" it. Refactoring means to look at how all your modules exchange data with other modules and then move logic so that it minimizes the interconnect. You make a lot of assumptions during development and not all of them are correct. So you must go back and move logic so as to reduce the clutter and random signals that flow between different blocks. It's kind of like floor planning. The nice thing about refactoring is that you don't change any of the existing logic so if you have a robust test suite you can do a good job of refactoring will little chance of breaking something. The or1200 really needs this to make it a lot easier to maintain. I am currently trying out some ideals for refactoring the or1200 in my socgen project. I will be checking in some changes shorty into the socgen/projects/or1k directory. ( I tried earlier but got a weird server error). John Eaton BTW: Olof, Is your orpsocv3 project to the point where you are looking for testers? |
|||
|
RE: Das Boot
by olof on Apr 12, 2012 |
olof
Posts: 218 Joined: Feb 10, 2010 Last seen: Dec 17, 2018 |
||
|
Is this something that was changed recently? I took a quick look at the SVN logs, but didn't see that it was removed from the port list Well it's gone now. I have no idea when it dropped out but we shouldn't change the top level footprint on a whim. I fully agree. This is bad practice, and we need to be more careful in the future.
Having a way to set an alternative address externally sounds good, but I guess that could also be implemented by using a small boot rom that checks a gpio and uses the result from that to decide where to jump. A bit more complicated, but avoids having to add another top-level signal
I think we should have a design with several different options for the system architects. One size does not fit all and you don't want the users to have to force their designs into one mode. Yes, to a certain degree of course. Too many possibilities makes it harder to use and verify. For this particular case, I have no opinion, but it could be submitted as a wishlist bug, so that it is clearly labeled as a wanted feature.
After you finish any design you need to go back and "refactor" it. Refactoring means to look at how all your modules exchange data with other modules and then move logic so that it minimizes the interconnect. You make a lot of assumptions during development and not all of them are correct. So you must go back and move logic so as to reduce the clutter and random signals that flow between different blocks. It's kind of like floor planning.
The nice thing about refactoring is that you don't change any of the existing logic so if you have a robust test suite you can do a good job of refactoring will little chance of breaking something. The or1200 really needs this to make it a lot easier to maintain. This is high on my wishlist too, but as you say, it requires a robust test suite and a known good state prior to any refactoring. I just started a roadmap page on the wiki, with the hope of getting out a stable release. Once that is in place, we can start heavy refactoring. The test suite is worked on too, with an ongoing effort to convert all or1ksim tests to be executable in hardware. In general, I feel that many hardware engineers are more restrictive to refactoring than their software counterparts. I hope that this is something that will change in the future
BTW:
Olof, Is your orpsocv3 project to the point where you are looking for testers? It is still a bit too unpolished, and I haven't had time to work on it at all the last month. It's currently at the stage where I have stopped adding features and am trying to tidy up a few things. When that is done, I can send out a call for testers. -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: olof.kindgren@orsoc.se ______________________________________________ FPGA, ASIC, DSP - embedded SoC design |
|||
1/1