Hi Sébastien, On Mon, Nov 25, 2013 at 11:16 AM, Sébastien Bourdeauducq <[email protected]> wrote: > I have implemented some changes in that direction. I have split the > top.py file into a "gensoc" library that provides platform-independent > integration components, and some "targets" that add peripherals and > platform-dependent cores to gensoc. Additional platform-dependent > constraints are also moved out of the build system and into the targets.
> I have also added -Xt and -Xp options to make.py, that enable it to load > target and platform definitions from external directories. Those > external targets may of course use misoclib. This approach allows the > BIOS code to be shared, and avoids having several sets of generated > files around (sdram_phy.h, csr.h, etc.) which could easily lead to > external software including the wrong file. > The reset vector of LM32 is also set depending on the platform. It's > done in a slightly hacky way at the moment, it would be nice to have > LM32 rewritten in Migen at some point (also to avoid reset-related > problems). That sounds good! It makes reusing the soc components much simpler. But I think misoclib and make.py should become a python package. Then, one could separate one's own history from that of misoc. A project using misoc would comprise only the custom target, custom cores, and custom apps and not need to be a branch of misoc. Whether shipping bios source code and the verilog parts as "data" would be the right way, I don't know. I could imagine that the mixeo_videomixer target+app would still live within misoc both as an example and to simplify/drive its development. All that boils down to adding a setup.py. If this is acceptable, I am happy to do it. > The example target "simple" contains a basic SoC that works on the > Papilio Pro (http://papilio.cc/index.php?n=Papilio.PapilioPro), as a > test for the build system and a design with lower barriers to entry. > Significant missing parts are: > * BIOS XIP - I have merged and mapped your SPI flash core, and it works, > but the build system needs to be modified to run xc3sprog and load the > BIOS into the flash (or UrJTAG with the addition of SPI flash support) I have seen that on the microboard, the flash is left in a different state after jtag-loading than after flash-loading the fpga. I'll see whether I can put some configuration of the flash into the hdl. > * SDRAM - the Papilio Pro uses old PC133 SDR, and s6ddrphy needs some > modifications for supporting it. > >> Alternatively misoc could become a python package. Better yet, >> those cores that are basically hardware independent could in fact be >> moved to migen. Drawing the migen/misoc line between "algorithmic" and >> "protocol" cores appears artificial. > > Well, many of the cores in MiSoC are oriented towards building a > system-on-chip, and Migen is not specifically made for SoCs. Most > non-SoC FPGA designs do not need a UART or a timer for example, as such > functionality is already provided by whatever hard microcontroller/hard > SoC the device is using. I stil have trouble drawing the line between migen and misoc cores. That sounds like everything exposed via a csr or wishbone bus would end up in misoc. If you have not a cpu but an etherbone wishbone master that controls a couple of cores, it would be a non-SoC design but still want to make use of a lot of misoc. Apart from reducing the size of migen by a few kB, what is the advantage of having misoc separate? The advantage of merging them would be convenience ;) >> Again IMHO having three separate >> packages is unnecessary. At least mibuild and migen should be merged: >> migen is rarely used without mibuild, mibuild pulls in no further >> dependencies, and mibuild requires migen. > > Ok, I see it would be more practical to distribute them together. I have > put them into the same repository. Thanks! -- Robert Jordens. _______________________________________________ Devel mailing list [email protected] https://ssl.serverraum.org/lists/listinfo/devel
