6:32 p.m.
On Thu, Nov 23, 2017 at 9:57 AM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk>
wrote:
If you are talking about the boot memory block RAM controller, it is
written in such
a way as to allow different widths of AXI bus to be used, as well as to
make it convenient to
read in a program and update it via data2mem. As such part of the
objectives of the project
are to make it as library independent as possible and to use RAM inference
where possible.
This means minimizing structural inferences as much as possible. Having
said that there are
several authors plus adaptations of previously existing code involved as
well. I haven't used IP-XACT at all.
On 23/11/17 08:50, Olof Kindgren wrote:
> One of the things I would like to do with LowRISC is a clean separation of
> structural and behavioural logic to eventually use IP-XACT or other
> configuration formats to easier build modular designs
>
> In chip_top.sv I found a big chunk of logic that seems to be related to
> creating an boot memory.
> Could someone please enlighten me what this code is supposed to do? I
> can't
> really figure out from looking at the source, and the elaborated design
> doesn't provide any addtional clues.
>
> //Olof
>
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.com/2017/01/the-dream-of-hdl-standard-librar...
)
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