Re: [lowrisc-dev] BRAM logic in chip_top.sv

Dear Olof, I checked the FuseSOC intro, it seems really interesting. Especially its extendable and can help building on different tool-chains and FPGA flows. The task of porting a SoC design to a different device is not an easy task, so in what aspects can FuseSOC help? Also, how modular is "modular"? this is in particular is interesting because of the increasing importance of updates and dependency tracking in a growing community. We had an interesting discussion earlier this month that could be relevant to this: https://listmaster.pepperfish.net/pipermail/lowrisc-dev- lists.lowrisc.org/2017-November/000826.html Thank you Regards, Ahmed Khalaf On Thu, Nov 23, 2017 at 12:57 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk&gt; wrote: > Dear Olof, > Our simulator of choice is verilator. We only use XSim when VHDL > components are instantiated (such as for DDR controller simulation). > > All our memories take advantage of the Xilinx feature of being > preloadable and writable. We would have to change this when we reach ASIC > ready stability. Verilator does not support true dual-port RAM easily > because of the way it schedules changes. So the situation when > ADD_MINION_SD is enabled is not simulatable in Verilator. We will be > looking for a different solution in our next release. The purpose in this > case is to provide two way communication through dual-port RAM between > Rocket and Minion processors. > > Jonathan > > Ok, so you are looking at creating a tool-agnostic RAM with initial >> contents, with byte enable, configurable width and depth which can also be >> used by vendor tools for post-implementation initialization? >> >> The good part is that I spent quite some time doing something very >> similar a few years ago. The bad part is that I found it was in practice >> impossible to do this in a tool-agnostic way. Either, the byte enable >> signals were ignored, or it didn't map efficiently to RAM resources in ISE, >> Quartus or Vivado. My conclusion was that it is actually better to do this >> as a tech-agnostic frontend with selectable backends using available FPGA >> primitives and a fallback to pure HDL for simulation. (In a wider scope >> this is one situation where my dream of HDL standard libraries would be >> very beneficial :) http://olofkindgren.blogspot.c >> om/2017/01/the-dream-of-hdl-standard-libraries.html) >> >> Right now I also see that there are explicit instantiations of Xilinx >> primitives when ADD_MINION_SD is defined which means that it's not really >> tech-agnostic anyway. >> >> I would like to rewrite this part as a stand-alone component instead. >> Can't promise to find the time, but if I do, could you tell me a bit more >> about the details of this implementation. I sense that there is some extra >> trickery going on here that I haven't fully grasped yet. Are you trying to >> append two memories to a larger one when ADD_MINION_SD is defined? Do you >> need ISim support (the simulator in ISE) or is it really XSim (the >> simulator in Vviado) support you refer to with the comments? Do you want it >> as a RAM or would a ROM be good enough? >> >> //Olof >> >> >