Hi Robert, On 11/15/2013 11:47 PM, Robert Jordens wrote: >> what are your plans for the LX9 microboard? I don't know if you want >> full support for it merged into MiSoC (which would perhaps require some >> changes to the code organization). > > I am using it as a portable testbed for a few fpga ideas. And in general > it would be nice if the migen/build/soc stack would offer baseline > implementations for other boards. Since many boards are going to reuse a > lot of the misoc cores, I would suggest to split the reusable parts from > misoc.
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). 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) * 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. > 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. Sebastien _______________________________________________ Devel mailing list Devel@lists.milkymist.org https://ssl.serverraum.org/lists/listinfo/devel
