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.
Regards,
Iztok Jeras
On Mon, Jun 3, 2013 at 1:52 PM, Joel Holdsworth <[email protected]>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>
> Yeah,
> >
> 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.
>
> Joel
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRrINrAAoJEIsWlGmq62Ig7aMIAIMDkiyzHcH4QWzLK0u8v4av
> UfByBuZVigb5g8NtuB1ybYednOTkkMPiFek6V7yoj/KceeRTJVsvr0yMTQTsmHG+
> oa+cjwmd/E1n2mpoAxVv/OLL4PjH9PgDQgOT5NWzbLaEAB0V3pYuZeCVXs0fUBD2
> PjDcrSk3P9/LC9xkTxPV5ApVTfrm86SK12rI+vgqS2FqTXSnOA9qt2FqD7+b39cS
> iWTaorFNO9K9Z6gNb0Y9KeS1e27xAwAEEFYy0hd/3HwTDC7bEWriBiMh7BdmqBSX
> hhaMaw3gAHZnKFx1OhIqRSu199CfeTDi4hsURiveIAcobe7qpwOtODA7SD6BMOs=
> =8JmB
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> sigrok-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
