Multiport BRAM for custom CPUs
de4
I hope my question won't be naive or stupid or repeaded 100 times. I wanted
to ask if there is possibility of creating RAM using FPGA BlockRam that
have for example 8 read ports. I asking because I'm creating simple
multicore processor and I've got problems with performace. Memory with
single port is big bottle neck for 8 cores unfortunetly. It would be great
to have RAM based on BRAM that I can read simultanusly on 8 diffrent
address and can initialize using coe file.
Other way is to create cache for each core but I imagine this as more
difficult...
Thank you for help and sorry for my poor english.
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
Jon Beniston
de4
>
Write ports are not a problem because i've memory controller based on
priority and with writing I'm very careful because I'm afraid of unintend
overwriting data be many cores... I just wanted to speed up fetching
instruction and data from memory that is shared by many processor cores.
By the way thank you for reply...
Nial Stewart
> Write ports are not a problem because i've memory controller based on
> priority and with writing I'm very careful because I'm afraid of unintend
> overwriting data be many cores... I just wanted to speed up fetching
> instruction and data from memory that is shared by many processor cores.
Why don't you just write the same thing to 8 (or 4) different RAMS?
Nial.
de4
hmmm that is not bad idea. I'm only a beginner and this solution didn't
come to my instantly... Thank you very much - that is what I needed quick
solution
OK only last question in this thread : Is there a possibility to update
Memory Init Vector in already generated BitStream file with out using
Xilinx GUI.
John McCaskill
There is a program named Data2MEM that can take a data file and insert
it into the FPGA bitstream without having to reroute the design.
See the Data2MEM Users Guide, AKA UG658, for more details. You can get
to it through the ISE help menu.
Regards,
John McCaskill
www.FasterTechnology.com
Eric Smith
of all the blockrams it has placed? The post-PAR static timing
happens to tell me that memory/r[1].ram is RAMB16_X1Y17, because that
one is in a critical path, but grep through all of the generated files
for memory/r[ and RAMB16_X doesn't turn up any of the others.
I'd like to let PAR choose the locations of the blockrams, but use a
Python script to extract the locations from a report and generate a
BMM file.
Thanks,
Eric
Ed McGettigan
The data2mem tool doesn't require you to know the physical location of
a particular BlockRAM, it just needs to know what the name is like a
UCF file does.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2mem.pdf
Ed McGettigan
--
Xilinx Inc.
Eric Smith
> a particular BlockRAM, it just needs to know what the name is like a
Thanks! I'm still confused since that manual says (page 28) "The BMM
file <i>must</i> have LOC or PLACED constraints for each block RAM.
These constraints can be added manually, but they are most often
obtained as an annotated BMM file from Bitgen. For information, see
Using Integrated ISE(R) Design Suite Implementation Tools." I think
that is in reference to the "-bd" option to bitgen, but as far as I
can tell, that still needs to have physical location constraints for
the blockrams (page 33) "Placement information of each block RAM is
provided by teh NCD file. Any block RAM placement constraints that
appear in the BMM file are already reflected in the NCD information.
All othe rblock RAMs are assigned placement constraints by previous
tool steps."
I was originally using generic VHDL code to get XST to infer the
blockrams, and I couldn't figure out how to refer to them in
constraints, but I've given up on using inference and am now
instantiating RAMB16_S9 primitives.
Eric
Brian Drummond
On Sat, 12 Dec 2009 23:23:22 -0800 (PST), in comp.arch.fpga you wrote:
>> The data2mem tool doesn't require you to know the physical location of
>> a particular BlockRAM, it just needs to know what the name is like a
>> UCF file does.http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/data2...
>
>Thanks! I'm still confused since that manual says (page 28) "The BMM
>file <i>must</i> have LOC or PLACED constraints for each block RAM.
>These constraints can be added manually, but they are most often
>obtained as an annotated BMM file from Bitgen. For information, see
>Using Integrated ISE(R) Design Suite Implementation Tools."
The information you need is not where you need it, but probably exists somewhere
else.
Dim and distant memory leads me to:
Webcase 720619 may be relevant (though it was from the ISE7.1 and 9.1 days)
https://xapps2.xilinx.com/eSupport/eSupportJSP/CaseShow.jsp?id_number=720619
If you can't see it without too many registration steps, I'll post some excerpts
from it here.
Two quotes from it:
-----------------------------------------------------------------------------------------------------------------------------
Problem 1: XILINX TOOL DEFECT
When NGDbuild fails to process a BMM file, it does not issue a Warning or an
Error as it should; just a note in the .bld log file. This makes finding
problems harder. (May have been fixed since 7.1; I haven't checked with Webpack
9.2)
-----------------------------------------------------------------------------------------------------------------------------
What DID help were AR#23179 and AR#24296 which explained how the "magic"
worked.
Remember: The problem manifested as PAR failing to generate a _bd.bmm
file from a flow which previously worked. Yet none of the documentation
(prior to the above AR#s) explained how it did this, to help pinpoint
the problem.
So it was unclear what communicated the BMM filename or the need to
annotate into PAR; therefore where to look to solve the problem.
I had to find the above AR#s to understand that the BMM filename is
buried in the .ncd file as a result of NGDbuild parsing it correctly;
since it was missing in the XDL file, that pointed back to NGDbuild
(where I found the failure as an obscure note in the BLD file).
-----------------------------------------------------------------------------------------------------------------------------
So
http://www.xilinx.com/support/answers/23179.htm
and
http://www.xilinx.com/support/answers/24269.htm
may be helpful.
There was a Change Request (CR #457644) to address issues with the
documentation; I don't know what happens to CRs but the documentation may still
be incomplete. If you find this to be so, it is worth pursuing further with
Xilinx Support.
But essentially, you need to supply a BMM file (xxx.bmm) with BRAM names (and no
LOC constraints) to ... actually "Translate" aka NGDbuild - AND CHECK THE BUILD
REPORT .bld to see it was handled correctly...
(This .bmm file is usually generated by EDK, but you can hand-edit it, e.g. to
alter hierarchical names if you use an EDK generated design as a component in a
larger design)
Then the .bmm information disappears into the tool flow, only to re-emerge at
Bitgen, (I believe, though I said PAR in my quote above) which takes the same
BMM file and annotates it with placement, saving as xxx_bd.bmm.
Hope this helps.
- Brian
Eric Smith
Eric
Jim Wu
> Thanks, Brian! That's very helpful!
>
> Eric
FWIW, in case you do need to find out the BRAM locations in the
implementation for some other purpose, take a look at the message
below on Xilinx forum:
http://forums.xilinx.com/xlnx/board/message?board.id=Virtex&message.id=5177#M5177
Cheers,
Jim
http://myfpgablog.blogspot.com/