Hi Joel,

I took some vacation for the end of June. I will spend a week coding and the other week traveling.

Some answers below.

Iztok Jeras

On Mon, Jun 3, 2013 at 1:52 PM, Joel Holdsworth <joel@airwebreathe.org.uk> wrote:
Hash: SHA1

Hi Iztok

> I found the most probable issue for your synthesis problems. In the
> file "rtl/sram_interface.v" there is generic code, which does not
> compile properly using XST (Xilinx Synthesis Tool).
> One issue is the $clog2 function (used to calculate the
> counter/address bus width for the FIFO/memory from the memory size)
> inside "rtl/cdc.v" and commented out in "rtl/sram_interface.v".
> Inside "rtl/sram_interface.v" is the 6kB memory for which XST
> consumes 16 blocks, instead of the actually necessary 12. This is
> probably why your project does not fit.

That's interesting. I will take a look.

For BRAMs is it usually possible to simply make a big register array,
or is there usually a vendor tool to generate a special "BRAM core" a.
la. Xilinx DCMs.

The generic approach is to write code which looks like a big register array, but the synthesis tool recognizes it as a memory and it consumes BRAM instead of flipflops. In the XST tool this feature only works correctly for 2^n sized memories, otherwise it rounds the size to 2^n (at least this is what it seems to happen). In our case instead of consuming 6kB it consumes 8kB. I implemented a workaround, which is specific not only for the Xilinx tool, but also for the FPGA memory size. The workaround RAM is composed of two segments one 4kB and one 2kB. Another option would be to use a generator of BRAM primitives, but it would require the definition of the same macros.

> This two Xilinx specific exceptions are inside an ifdef/endif
> block, and the macro "XC3S250E" must be available for this code to
> compile properly using XST. One way to solve this is to define this
> macro at the beginning of this files: `define XC3S250E The other
> option is to add macro definitions to the Xilinx project file, this
> is used in the project on my repo. Here are some instructions
> (under Verilog Macros):
> http://www.xilinx.com/itp/xilinx10/isehelp/pp_db_xst_synthesis_options.htm
Advanced settings have to be enabled for the option to be present:
> http://www.xilinx.com/itp/xilinx10/isehelp/pn_c_setting_advanced_properties.htm

so in terms of my hopes of universal configuration, I'd like to
be able to have a vendor macro: XILINX, ALTERA etc. a FPGA class
macro: XC3S, or SPARTAN3E etc. and a device specific macro XC3S250E.
The current use of the XC3S250E isn't quite right because it would
require a different constant for every device we ever port to.

There is no way to avoid vendor specific synthesis issues. And issues can manifest for various combinations of vendor, device and other parameters. For now I would use simple define macros, and later when we actually support many boards, we can make a list of workarounds and devise a more organized macro scheme. It would be great to have one now, but I do not know yet what would be best. I do have experience with vendor interoperability, but on the range of 4 combinations, while we plan to support 10 or more boards.

> I have created some more generic test environment code (not used
> much yet), and decided to start porting to a board I own
> (Ordb2a-ep4ce22<http://opencores.org/or1k/Ordb2a-ep4ce22>) or can
> borrow (Terasic
> DE1<http://www.terasic.com.tw/cgi-bin/page/archive.pl?No=83>). For
> this purpose I will revive the UART interface.

That makes sense. I believe the sigrok ols driver supports
SUMP-over-serial out of the box.

Yes, this is the main reason. It would actually be possible to test the board driver, by creating named pipes (mkfifo) which sigrok and a Verilog simulator can use to communicate. This way the driver can be developed almost entirely in software.


Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
sigrok-devel mailing list