Messages from 156825

Article: 156825
Subject: Re: What use of Python, Perl in FPGA development?
From: fl <rxjwg98@gmail.com>
Date: Sat, 5 Jul 2014 05:55:24 -0700 (PDT)
Links: << >> << T >> << A >>

On Friday, July 4, 2014 10:35:32 PM UTC-4, Aylons Hazzud wrote:
> Le vendredi 4 juillet 2014 19:15:14 UTC-3, fl a =E9crit=A0:
>=20
> > On Friday, July 4, 2014 8:20:34 AM UTC-4, fl wrote:
>=20
> >=20
>=20
> > > On Thursday, July 3, 2014 9:20:12 AM UTC-4, Aylons Hazzud wrote:
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > One example is the hdlmake project[1]: a very nice HDL project mana=
ger, build in Python. It allows you to flexibly manage multi-language and m=
ulti-plataform projects.
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > Another example is MyHDL[2], a python-based HDL code generator[2].
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > [1] http://www.ohwr.org/projects/hdl-make
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > [2] http://www.myhdl.org/
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > Le jeudi 3 juillet 2014 08:16:55 UTC-3, Thomas Stanka a =E9crit=A0:
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > > Hi,
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > > Around the tools (that indeed have usually TCL included) are ofte=
n a wide variety of additional scripts to help you automate your designflow=
 in several aspects (eg. code generators, make-mechanism, filter tool repor=
ts, manage regression tests,.... ).
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > > For these scripts is usually Phyton and Perl required, as TCL is =
not very compfortable.
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > > > regards Thomas
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > Thank you very much. It really looks like an excellent tool.
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > I am still new to Linux.I download the first (hdlmake-v1.0) from the =
below 4
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > files. And put it under ~(Home) directory in Ubuntu 12.04 LTS. I can =
rename
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > the full hdlmake-v1.0 to hdlmake (as in its tutorial of the author)?
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > hdlmake-v1.0 	05/05/2013 15:20 	37 kB 	184 =09
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > hdlmake-v1.0-isyp 	05/05/2013 15:21 	40.8 kB 	53 =09
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > hdlmake-v1.0-isyp.tar.gz 	05/05/2013 15:20 	220.3 kB 	62 =09
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > hdlmake-v1.0.tar.gz 	05/05/2013 15:20 	100.5 kB 	126
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > On the author's website, he said:
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > Downloading the compiled executable
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > For downloading the compiled executable, click here and choose one of t=
he files without extension. Download to a location of choice, and you're al=
most ready to use it! You can jump directly to the final steps.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > He said that "choose one of the files without extension". Is it this on=
e:
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > hdlmake-v1.0 	05/05/2013 15:20 	37 kB 	184=20
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > In which directory do you put it? I am using Ubuntu 12.04.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > Thanks,
>=20
>=20
>=20
> You may put it wherever it works best for you. When invoking the tool, yo=
u just have to make sure to use the full path.
>=20
>=20
>=20
> Later, if you want to, you may put the directory in the $PATH environment=
 variable so you won't have to use the full path every time you use the too=
l. Google how to do it, it is a very common task.


Thank you. I have managed to run the first synthesis with this tool. Great!
In the end, it says that there is an error:

ERROR:Xst:2793 - Top module <led_ctrl_top> specified via the -top switch wa=
s not found in any library.

I install Xilinx ISE 14.2 on Ubuntu 12.04 32-bit. Is the tool not compatibl=
e,
or the sample design, downloaded from the tool author's website intentional=
ly
having an error? I am still not very clear about the above error message.

Do you see where the "-top" switch? In which library does it search for?


Thanks,




Full message from my running:

robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ source /opt/Xilinx/14.=
2/ISE_DS/settings32.sh
. /opt/Xilinx/14.2/ISE_DS/common/.settings32.sh /opt/Xilinx/14.2/ISE_DS/com=
mon
. /opt/Xilinx/14.2/ISE_DS/EDK/.settings32.sh /opt/Xilinx/14.2/ISE_DS/EDK
. /opt/Xilinx/14.2/ISE_DS/common/CodeSourcery/.settings32.sh /opt/Xilinx
/14.2/ISE_DS/common/CodeSourcery
. /opt/Xilinx/14.2/ISE_DS/PlanAhead/.settings32.sh /opt/Xilinx/14.2/ISE_DS
/PlanAhead
. /opt/Xilinx/14.2/ISE_DS/ISE/.settings32.sh /opt/Xilinx/14.2/ISE_DS/ISE
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ env
SSH_AGENT_PID=3D2021
GPG_AGENT_INFO=3D/tmp/keyring-tFgbsf/gpg:0:1
XILINX_DSP=3D/opt/Xilinx/14.2/ISE_DS/ISE
TERM=3Dxterm
SHELL=3D/bin/bash
XDG_SESSION_COOKIE=3D32b521a8b574c9de6facec5a00000008-1404558998.97504-1715=
864184
WINDOWID=3D56623110
OLDPWD=3D/home/robert/pyprj/fmc-adc-100m14b4cha/play
GNOME_KEYRING_CONTROL=3D/tmp/keyring-tFgbsf
USER=3Drobert
LD_LIBRARY_PATH=3D/opt/Xilinx/14.2/ISE_DS/ISE/lib/lin:/opt/Xilinx/14.2/ISE_=
DS
/EDK/lib/lin:/opt/Xilinx/14.2/ISE_DS/common/lib/lin
LS_COLORS=3Drs=3D0:di=3D01;34:ln=3D01;36:mh=3D00:pi=3D40;33:so=3D01;35:do=
=3D01;35:bd=3D40;
33;01:cd=3D40;33;01:or=3D40;31;01:su=3D37;41:sg=3D30;43:ca=3D30;41:tw=3D30;=
42:ow=3D34;
42:st=3D37;44:ex=3D01;32:*.tar=3D01;31:*.tgz=3D01;31:*.arj=3D01;31:*.taz=3D=
01;31:*.lzh=3D01;
31:*.lzma=3D01;31:*.tlz=3D01;31:*.txz=3D01;31:*.zip=3D01;31:*.z=3D01;31:*.Z=
=3D01;31:*.dz=3D01;
31:*.gz=3D01;31:*.lz=3D01;31:*.xz=3D01;31:*.bz2=3D01;31:*.bz=3D01;31:*.tbz=
=3D01;
31:*.tbz2=3D01;31:*.tz=3D01;31:*.deb=3D01;31:*.rpm=3D01;31:*.jar=3D01;31:*.=
war=3D01;
31:*.ear=3D01;31:*.sar=3D01;31:*.rar=3D01;31:*.ace=3D01;31:*.zoo=3D01;31:*.=
cpio=3D01;
31:*.7z=3D01;31:*.rz=3D01;31:*.jpg=3D01;35:*.jpeg=3D01;35:*.gif=3D01;35:*.b=
mp=3D01;
35:*.pbm=3D01;35:*.pgm=3D01;35:*.ppm=3D01;35:*.tga=3D01;35:*.xbm=3D01;35:*.=
xpm=3D01;
35:*.tif=3D01;35:*.tiff=3D01;35:*.png=3D01;35:*.svg=3D01;35:*.svgz=3D01;35:=
*.mng=3D01;
35:*.pcx=3D01;35:*.mov=3D01;35:*.mpg=3D01;35:*.mpeg=3D01;35:*.m2v=3D01;35:*=
.mkv=3D01;
35:*.webm=3D01;35:*.ogm=3D01;35:*.mp4=3D01;35:*.m4v=3D01;35:*.mp4v=3D01;35:=
*.vob=3D01;
35:*.qt=3D01;35:*.nuv=3D01;35:*.wmv=3D01;35:*.asf=3D01;35:*.rm=3D01;35:*.rm=
vb=3D01;
35:*.flc=3D01;35:*.avi=3D01;35:*.fli=3D01;35:*.flv=3D01;35:*.gl=3D01;35:*.d=
l=3D01;
35:*.xcf=3D01;35:*.xwd=3D01;35:*.yuv=3D01;35:*.cgm=3D01;35:*.emf=3D01;35:*.=
axv=3D01;
35:*.anx=3D01;35:*.ogv=3D01;35:*.ogx=3D01;35:*.aac=3D00;36:*.au=3D00;36:*.f=
lac=3D00;
36:*.mid=3D00;36:*.midi=3D00;36:*.mka=3D00;36:*.mp3=3D00;36:*.mpc=3D00;36:*=
.ogg=3D00;
36:*.ra=3D00;36:*.wav=3D00;36:*.axa=3D00;36:*.oga=3D00;36:*.spx=3D00;36:*.x=
spf=3D00;36:
LIBGL_DRIVERS_PATH=3D/usr/lib/fglrx/dri:/usr/lib/i386-linux-gnu/dri:/usr/li=
b/dri
XDG_SESSION_PATH=3D/org/freedesktop/DisplayManager/Session0
XILINX_EDK=3D/opt/Xilinx/14.2/ISE_DS/EDK
XDG_SEAT_PATH=3D/org/freedesktop/DisplayManager/Seat0
SSH_AUTH_SOCK=3D/tmp/keyring-tFgbsf/ssh
SESSION_MANAGER=3Dlocal/MS-7696:@/tmp/.ICE-unix/1984,unix/MS-7696:/tmp/.ICE=
-
unix/1984
DEFAULTS_PATH=3D/usr/share/gconf/ubuntu.default.path
XDG_CONFIG_DIRS=3D/etc/xdg/xdg-ubuntu:/etc/xdg
PATH=3D/opt/Xilinx/14.2/ISE_DS/ISE/bin/lin:/opt/Xilinx/14.2/ISE_DS/ISE/sysg=
en
/util:/opt/Xilinx/14.2/ISE_DS/PlanAhead/bin:/opt/Xilinx/14.2/ISE_DS/EDK/bin
/lin:/opt/Xilinx/14.2/ISE_DS/EDK/gnu/microblaze/lin/bin:/opt/Xilinx/14.2/IS=
E_DS
/EDK/gnu/powerpc-eabi/lin/bin:/opt/Xilinx/14.2/ISE_DS/EDK/gnu/arm/lin/bin:/=
opt
/Xilinx/14.2/ISE_DS/common/bin/lin:/usr/lib/lightdm/lightdm:/usr/local/sbin=
:
/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
DESKTOP_SESSION=3Dubuntu
PWD=3D/home/robert/pyprj/fmc-adc-100m14b4cha/play/syn
GNOME_KEYRING_PID=3D1973
LANG=3Den_CA.UTF-8
MANDATORY_PATH=3D/usr/share/gconf/ubuntu.mandatory.path
QMAKESPEC=3D/home/robert/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/arm-ara=
go-linux-gnueabi/usr/share/qtopia/mkspecs/linux-g++
UBUNTU_MENUPROXY=3Dlibappmenu.so
COMPIZ_CONFIG_PROFILE=3Dubuntu
GDMSESSION=3Dubuntu
__KMP_REGISTERED_LIB_2052=3D0xb5fb5394-cafefce3-libiomp5.a
SHLVL=3D1
HOME=3D/home/robert
LANGUAGE=3Den_CA:en
GNOME_DESKTOP_SESSION_ID=3Dthis-is-deprecated
LOGNAME=3Drobert
XDG_DATA_DIRS=3D/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/s=
hare/
DBUS_SESSION_BUS_ADDRESS=3Dunix:abstract=3D/tmp/dbus-
Zr40Ve1bAV,guid=3Da407da5a3fa1e15c9f9840da0000003b
LESSOPEN=3D| /usr/bin/lesspipe %s
DISPLAY=3D:0
XILINX_PLANAHEAD=3D/opt/Xilinx/14.2/ISE_DS/PlanAhead
XDG_CURRENT_DESKTOP=3DUnity
LESSCLOSE=3D/usr/bin/lesspipe %s %s
XILINX=3D/opt/Xilinx/14.2/ISE_DS/ISE
COLORTERM=3Dgnome-terminal
XAUTHORITY=3D/home/robert/.Xauthority
_=3D/usr/bin/env
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ ./hdlmake-v1.0
INFO:    Running automatic flow
INFO:    Generating/updating ISE project
INFO:    Generating makefile for local synthesis.
WARNING: Connection data is not given. Accessing environmental variables in=
 the
makefile
INFO:    Generating makefile for remote synthesis.
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ ls
hdlmake-v1.0  led_ctrl.ucf  led_ctrl.xise  Makefile  Manefest.py~  Manifest=
.py
  run.tcl
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ ls -al
total 88
drwxrwxr-x 2 robert robert  4096 Jul  5 08:40 .
drwxrwxr-x 7 robert robert  4096 Jul  5 08:03 ..
-rwx--x--x 1 robert robert 37848 Jul  4 06:46 hdlmake-v1.0
-rw-rw-r-- 1 robert robert 22270 Jul  4 20:59 led_ctrl.ucf
-rw-rw-r-- 1 robert robert  2095 Jul  5 08:40 led_ctrl.xise
-rw-rw-r-- 1 robert robert  2702 Jul  5 08:40 Makefile
-rw-rw-r-- 1 robert robert     0 Jul  5 08:33 Manefest.py~
-rw-rw-r-- 1 robert robert   236 Jul  5 08:33 Manifest.py
-rw-rw-r-- 1 robert robert    84 Jul  5 08:40 run.tcl
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$ make
echo "project open led_ctrl.xise" > run.tcl
echo "process run {Generate Programming File} -force rerun_all" >> run.tcl
xtclsh run.tcl

Started : "Synthesize - XST".
Running xst...
Command Line: xst -intstyle ise -ifn "/home/robert/pyprj/fmc-adc-100m14b4ch=
a/play/syn/led_ctrl_top.xst" -ofn "/home/robert/pyprj/fmc-adc-100m14b4cha/p=
lay/syn/led_ctrl_top.syr"
Reading design: led_ctrl_top.prj

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
*                          HDL Parsing                                  *
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Parsing VHDL file "/home/robert/pyprj/fmc-adc-100m14b4cha/play/hdl/design
/led_ctrl.vhd" into library work
Parsing entity <led_ctrl>.
Parsing architecture <behavioral> of entity <led_ctrl>.
Parsing VHDL file "/home/robert/pyprj/fmc-adc-100m14b4cha/play/hdl/design
/irq_controller_regs.vhd" into library work
Parsing entity <irq_controller_regs>.
Parsing architecture <syn> of entity <irq_controller_regs>.
Parsing VHDL file "/home/robert/pyprj/fmc-adc-100m14b4cha/play/hdl/design
/irq_controller.vhd" into library work
Parsing entity <irq_controller>.
Parsing architecture <rtl> of entity <irq_controller>.
Parsing VHDL file "/home/robert/pyprj/fmc-adc-100m14b4cha/play/hdl/design
/addr_dec.vhd" into library work
Parsing entity <addr_dec>.
Parsing architecture <behavioral> of entity <addr_dec>.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
*                            HDL Elaboration                            *
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR:Xst:2793 - Top module <led_ctrl_top> specified via the -top switch wa=
s=20
not found in any library.
-->=20


Total memory usage is 97520 kilobytes

Number of errors   :    1 (   0 filtered)
Number of warnings :    0 (   0 filtered)
Number of infos    :    0 (   0 filtered)


Process "Synthesize - XST" failed
INFO:TclTasksC:1850 - process run : Generate Programming File is done.
robert@MS-7696:~/pyprj/fmc-adc-100m14b4cha/play/syn$=20

Article: 156826
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: rickman <gnuarm@gmail.com>
Date: Sat, 05 Jul 2014 14:24:20 -0400
Links: << >> << T >> << A >>

On 7/5/2014 7:48 AM, MK wrote:
> On 05/07/2014 12:28, Brane2 wrote:
>> I'd probably toss verilog in a second.
>
>
> That's your problem - switch to VHDL and everything will be rosy !
>
> For what it's worth I use Aldec HDL (paid for $$$ but worth it) and only
> use the Lattice tools for some IP modules and synthesis. You get the
> Aldec tool (cut down but still quite good) in with the Lattice toolset.
>
> The stuff I do got way too big to want to think about gates a long while
> ago - latest project uses some 96 and some 128 bit arithmetic - I
> wouldn't fancy placing the flip-flops for that by hand !

I remember when the HDLs were still not mainstream with the FPGA users 
and the FPGA vendors were pushing to get everyone converted.  One of the 
expert users Ray Andraka had a full set of schematic modules which he 
could use hierarchically with place and route constraints which gave him 
tons of control over the actual design, much like what Brane is asking 
for.  So Ray was a serious hold out for schematics.

Then the FPGA folks showed him how to apply the same constraints to VHDL 
with the same hierarchy (I'm sure it works the same with Verilog) as 
well as the advantages of text files for development and archival... he 
was sold!  I believe he never looked back.

Who am I to argue with Ray Andraka?

-- 

Rick

Article: 156827
Subject: Re: What use of Python, Perl in FPGA development?
From: fl <rxjwg98@gmail.com>
Date: Sat, 5 Jul 2014 12:46:49 -0700 (PDT)
Links: << >> << T >> << A >>

On Thursday, July 3, 2014 9:20:12 AM UTC-4, Aylons Hazzud wrote:
> One example is the hdlmake project[1]: a very nice HDL project manager, b=
uild in Python. It allows you to flexibly manage multi-language and multi-p=
lataform projects.
>=20
>=20
>=20
> Another example is MyHDL[2], a python-based HDL code generator[2].
>=20
>=20
>=20
> [1] http://www.ohwr.org/projects/hdl-make
>=20
> [2] http://www.myhdl.org/
>=20
>=20
>=20
> Le jeudi 3 juillet 2014 08:16:55 UTC-3, Thomas Stanka a =E9crit=A0:
>=20
> > Hi,
>=20
> >=20
>=20
> > Around the tools (that indeed have usually TCL included) are often a wi=
de variety of additional scripts to help you automate your designflow in se=
veral aspects (eg. code generators, make-mechanism, filter tool reports, ma=
nage regression tests,.... ).
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > For these scripts is usually Phyton and Perl required, as TCL is not ve=
ry compfortable.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > regards Thomas
Hi,
Finally, it passes Manifest.py. When I run synthesis with make utility, it =
has
such errors (see below for complete message please):

ERROR:ProjectMgmt - The software version (13) is older than the version sav=
ed in
   the project file (14).

I do not know which file it says. Could you help me?

Thanks,



..............................................................
Jeff@Jeff-PC ~/fmc-adc-100m14b4cha/play/syn
$ ./hdlmake-v1.0
INFO:    Running automatic flow
INFO:    Generating/updating ISE project
INFO:    Generating makefile for local synthesis.
WARNING: Connection data is not given. Accessing environmental variables in=
 the makefile
INFO:    Generating makefile for remote synthesis.

Jeff@Jeff-PC ~/fmc-adc-100m14b4cha/play/syn
$ make
echo "project open led_ctrl.xise" > run.tcl
echo "process run {Generate Programming File} -force rerun_all" >> run.tcl
xtclsh run.tcl
ERROR:ProjectMgmt - The software version (13) is older than the version sav=
ed in
   the project file (14).
   Opening newer project with older software releases is not supported.
ERROR:ProjectMgmt - The software version (13) is older than the version sav=
ed in
   the project file (14).
   Opening newer project with older software releases is not supported.
ERROR:TclTasksC:project_085: Error opening specified project "C:/cygwin64/h=
ome/Jeff/fmc-adc-100m14b4cha/play/syn/led_ctrl.xise": ERROR:TclTasksC:tcl_p=
roject_mgr_007 - Internal error. Can not open "C:\cygwin64\home\Jeff\fmc-ad=
c-100m14b4cha\play\syn\led_ctrl.xise".
.
    while executing
"project open led_ctrl.xise"
    (file "run.tcl" line 1)
Makefile:11: recipe for target 'local' failed
make: *** [local] Error 1

Article: 156828
Subject: Re: What use of Python, Perl in FPGA development?
From: al.basili@gmail.com (alb)
Date: 6 Jul 2014 11:14:42 GMT
Links: << >> << T >> << A >>

Hi Hazzud,

Aylons Hazzud <aylons@gmail.com> wrote:
> One example is the hdlmake project[1]: a very nice HDL project 
> manager, build in Python. It allows you to flexibly manage 
> multi-language and multi-plataform projects.

IMO hdlmake fails in being a 'simple' makefile generation tool, since 
it added the complexity of the VCS management and remote synthesis 
features which IMO are out of the scope for a 'make' utility (and can 
be simply handled separately).

To give an example I installed hdlmake to give it a go and wanted to 
start with one of the examples provided with the documentation and 
BANG, I was cloning a ~2GB git repository to test an example!

A 'make' tool resolves dependencies, that's all it does. I use vmk to 
build my dependencies and I do not ask more to a 'makefile generator'. 
The Makefile has hooks that you can use to run whatever other tool or 
script you can imagine and is not bound to any X vendor.

There are only two shortcoming of vmk: 

1. the library management is not straight forward and I do believe the 
author did have another utility to fill the gap (IIRC is called lmk). 
While this is a bit of a pity is certainly not a show stopper for using 
it.

2. supports only vhdl-93, which is a bit disappointing especially for 
testbenches which I tipically write leveraging the new features of 
vhdl-2008.

I'm not aware which language standard hdlmake is supporting, at least 
I didn't find it in the documentation.

Al

Article: 156829
Subject: wishbone bus between two fpgas
From: al.basili@gmail.com (alb)
Date: 6 Jul 2014 11:36:44 GMT
Links: << >> << T >> << A >>

Hi everyone,

we are in the preliminary phase of the architecture definition for our 
system and we estimated FPGA resources (for a particular target) to be 
~80% of the target's capabilities.

Being at such level at this stage is rather risky since we can easily 
find ourselves in deep troubles during implementation.

Unfortunately the target is an RTAX2000S, with the bigger sister being 
nearly as 3 times more expensive with only double the resources
(RTAX4000S).

For this reason we are more incline to split the architecture into two 
FPGAs but that choice is certainly not free of hassles either.

Now comes the overhead of connection between the two devices and I came 
up with a very stupid idea: what if my SoC bus (possibly a wishbone) 
gets extended to the other FPGA as well?

With this approach I would simply move masters and slave around the two 
FPGAs without having to think too hard and they will interact as if 
they were sitting on the same fabric (except maybe for some extra 
latency).

Moreover, if we've been extremely good during our preliminary phase in 
anticipating the needed resources we can still fit everything in one 
FPGA without the need to change too much (just adding components on the 
bus).

Any opinion/experience/advice on the subject?

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 156830
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: Brane2 <brankob@avtomatika.com>
Date: Sun, 6 Jul 2014 07:55:13 -0700 (PDT)
Links: << >> << T >> << A >>

Dne sobota, 05. julij 2014 18:24:20 UTC je oseba rickman napisala:
>  One of the=20
>=20
> expert users Ray Andraka had a full set of schematic modules which he=20
>=20
> could use hierarchically with place and route constraints which gave him=
=20
>=20
> tons of control over the actual design, much like what Brane is asking=20
>=20
> for.  So Ray was a serious hold out for schematics.
>=20

1. AFAIK he was working for XIlinx. His focus might have been more toward h=
igh end of application spectrum.

2. I'm not arguing for schematics but for something much closer to pcb part=
.

Substantial difference is that PCB substrat by itself is homegenous- non pa=
tterned. So you need several step approach, first you choose elements and t=
hen wire them symbolically and in second step you map those symbols to "mea=
t" ( element housings etc), place them and shape copper between them

With FPGA, you don't have those degrees of freedom. Everything is already p=
re patterned and placed on LEGO landscape and all you need to do is flip th=
e right subset of switches on.

If i could click on PFU and enter simple equation and system would configur=
e FLASH for its ROM table, that'd be great. Same with output flip-flop, gat=
es etc tidbits. Seeing actual wires could also help with autorouting. I cou=
ld plan in advance which wires to use for what etc.

Once I would complete say 4-bit counter, I could make a group, which could =
move around as a whole. Simple SW logic might take care of tidbits. Like if=
 I move group somewhere that violates some wiring demands, that it would si=
mply erase those wires and show me fresh ratsnest etc.

HDL for me is just another layer of obfuscation that fogs things and demand=
s whole new learning curve etc.

After all, our brain evolved so that we have visual "accelerators", not rel=
ational ones. If visual data is presented right, brain can filter interesti=
ng patterns and edges out ouf vast array of pixels and details.

Article: 156831
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 06 Jul 2014 14:43:49 -0400
Links: << >> << T >> << A >>

On 7/6/14, 10:55 AM, Brane2 wrote:
> Dne sobota, 05. julij 2014 18:24:20 UTC je oseba rickman napisala:
>> One of the
>>
>> expert users Ray Andraka had a full set of schematic modules which
>> he
>>
>> could use hierarchically with place and route constraints which
>> gave him
>>
>> tons of control over the actual design, much like what Brane is
>> asking
>>
>> for.  So Ray was a serious hold out for schematics.
>>
>
> 1. AFAIK he was working for XIlinx. His focus might have been more
> toward high end of application spectrum.
>
> 2. I'm not arguing for schematics but for something much closer to
> pcb part.
>
> Substantial difference is that PCB substrat by itself is homegenous-
> non patterned. So you need several step approach, first you choose
> elements and then wire them symbolically and in second step you map
> those symbols to "meat" ( element housings etc), place them and shape
> copper between them
>
> With FPGA, you don't have those degrees of freedom. Everything is
> already pre patterned and placed on LEGO landscape and all you need
> to do is flip the right subset of switches on.
>
> If i could click on PFU and enter simple equation and system would
> configure FLASH for its ROM table, that'd be great. Same with output
> flip-flop, gates etc tidbits. Seeing actual wires could also help
> with autorouting. I could plan in advance which wires to use for what
> etc.
>
> Once I would complete say 4-bit counter, I could make a group, which
> could move around as a whole. Simple SW logic might take care of
> tidbits. Like if I move group somewhere that violates some wiring
> demands, that it would simply erase those wires and show me fresh
> ratsnest etc.
>
> HDL for me is just another layer of obfuscation that fogs things and
> demands whole new learning curve etc.
>
> After all, our brain evolved so that we have visual "accelerators",
> not relational ones. If visual data is presented right, brain can
> filter interesting patterns and edges out ouf vast array of pixels
> and details.
>

I HAVE used tools like that, for parts much smaller than we have today. 
One of the first PLD configuration tools I used had a mode which brought 
up the full fuse map so you could configure your 16 FF PLD letting you 
choose from the logic modes of the logic block and configure the routing 
matrix for the and/or/xor input block. It was much preferable to enter 
in the equations and let the compiler figure all this out. Looking at 
the map might help if you were getting "too complex" errors to let you 
see what was the problem. And by letting you try to do it yourself you 
could actually convince yourself it was too complicated, or let you 
figure out how to express it directly so the compiler could work it out 
(This normally due to tweaking "don't care" conditions).

Later, when we had real FPGA's, the tools would have a mode where you 
could see each of the individual LE as a little box that you could 
assign your logic elements as defined by equations or schematic, and see 
the "rats nest" of connections, and an indication of how stressed the 
routing matrix was in that area. A printout of this sort of layout could 
take a good part of a wall for a whole chip.

Sometimes, for a small complicated circuit, you could sit down and 
pre-fit pieces to help the fitter. More often often you could help some 
by assigning chunks of the design to regions of the device. The one spot 
where this ability really helped was if you had to place pins to start 
the board layout before you finished the FPGA design. You could enter 
basic designs for the things driving the outputs and see what were 
natural placements for them and what pins they could directly drive.

I am much happier not to need to get down to that level most of the 
time. Being able to see things at the HDL level give a much better 
understanding of the over all function. It would be somewhat like 
deciding to work on a large software package by throwing out the 
compiler and saying it obfuscates what really happens, you REALLY need 
to design that system at low level assembly.

This doesn't say that in some special cases there won't be a need to dig 
in and look at the raw results generated to solve a performance issues, 
but that is the exception, and normally for just a small piece of the 
system.

Note, that even though they are HDLs, there normally IS a way to force 
low level effects, this signal WILL be the output of a logic element, 
this signal WILL use the carry change, to allow you to define things 
exactly as you want the compiler to generate the logic.

Article: 156832
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Jul 2014 12:03:56 -0700 (PDT)
Links: << >> << T >> << A >>

On Sunday, July 6, 2014 10:55:13 AM UTC-4, Brane2 wrote:
>=20
>=20
> If i could click on PFU and enter simple equation and system would config=
ure=20
> FLASH for its ROM table, that'd be great. Same with output flip-flop, gat=
es=20
> etc tidbits. Seeing actual wires could also help with autorouting. I coul=
d=20
> plan in advance which wires to use for what etc.
>=20

'Simple' is the keyword in all of that.  You would only be able to create '=
simple' designs, nothing complex, nothing that could be easily maintained. =
 Good luck being productive, others will pass you right by.  You would take=
 forever to create a design...or be let go before you complete it.

>=20
> Once I would complete say 4-bit counter, I could make a group, which coul=
d
> move around as a whole. Simple SW logic might take care of tidbits. Like =
if I=20
> move group somewhere that violates some wiring demands, that it would sim=
ply=20
> erase those wires and show me fresh ratsnest etc.
>=20

But there is not much call for 4-bit counters.  Move them around all you li=
ke and let us know if you can create a video coder/decoder or some other fu=
nctionality that has usefulness.  Even your statement "Once I would complet=
e say 4-bit counter", shows the lack of being productive.  Most anyone skil=
led in HDL would probably have trouble even quantifying the amount of time =
required to 'complete a 4-bit counter' it would be so small.=20

>=20
> HDL for me is just another layer of obfuscation that fogs things and dema=
nds=20
> whole new learning curve etc.
>=20

Maybe you should work your up way up the learning curve and see if that fog=
s clears up.  For most, that is what happens.

Kevin Jennings

Article: 156833
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: Tim <tim@bugblatbugblat.com>
Date: Sun, 06 Jul 2014 21:56:01 +0100
Links: << >> << T >> << A >>

Interesting. Have they cancelled the XO3-H?

On 04/07/2014 12:06, Brane2 wrote:
<snip>
>
> Bummer. First they silently deleted whole XO3-H part of the series
> and now they want $$$ for a licence for ECP5 that is in absence of
> XO3-H my next choice.
>

Article: 156834
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: rickman <gnuarm@gmail.com>
Date: Mon, 07 Jul 2014 00:10:25 -0400
Links: << >> << T >> << A >>

On 7/6/2014 10:55 AM, Brane2 wrote:
> Dne sobota, 05. julij 2014 18:24:20 UTC je oseba rickman napisala:
>>   One of the
>>
>> expert users Ray Andraka had a full set of schematic modules which he
>>
>> could use hierarchically with place and route constraints which gave him
>>
>> tons of control over the actual design, much like what Brane is asking
>>
>> for.  So Ray was a serious hold out for schematics.
>>
>
> 1. AFAIK he was working for XIlinx. His focus might have been more toward high end of application spectrum.

I believe Ray used Xilinx parts almost exclusively but he did not work 
*for* Xilinx.  I'm not sure he even worked at the "high end" per se.  He 
did utilize the parts to their maximum capabilities, both in speed and 
density.  He did a lot of work in the days when what you want would have 
been practical in the way you picture it.

> 2. I'm not arguing for schematics but for something much closer to pcb part..
>
> Substantial difference is that PCB substrat by itself is homegenous- non patterned. So you need several step approach, first you choose elements and then wire them symbolically and in second step you map those symbols to "meat" ( element housings etc), place them and shape copper between them
>
> With FPGA, you don't have those degrees of freedom. Everything is already pre patterned and placed on LEGO landscape and all you need to do is flip the right subset of switches on.
>
> If i could click on PFU and enter simple equation and system would configure FLASH for its ROM table, that'd be great. Same with output flip-flop, gates etc tidbits. Seeing actual wires could also help with autorouting. I could plan in advance which wires to use for what etc.

What you are talking about would be direct instantiation of hard 
features in the FPGAs.  I believe you can instantiate PFUs and then 
assign logic to them from the HDL.  It may not be portable across 
vendors, but that's no surprise.

> Once I would complete say 4-bit counter, I could make a group, which could move around as a whole. Simple SW logic might take care of tidbits. Like if I move group somewhere that violates some wiring demands, that it would simply erase those wires and show me fresh ratsnest etc.
>
> HDL for me is just another layer of obfuscation that fogs things and demands whole new learning curve etc.
>
> After all, our brain evolved so that we have visual "accelerators", not relational ones. If visual data is presented right, brain can filter interesting patterns and edges out ouf vast array of pixels and details.

Yes, we are more visual, but when using text based design entry we can 
get the computer to do things for us more easily and some functions like 
version control work better.

If you are willing to use an HDL you can do what you are talking about. 
   It is the graphical interface that is not going to happen.

-- 

Rick

Article: 156835
Subject: Re: wishbone bus between two fpgas
From: "jt_eaton" <84408@embeddedrelated>
Date: Mon, 07 Jul 2014 09:55:57 -0500
Links: << >> << T >> << A >>

>Hi everyone,
>
>
>Now comes the overhead of connection between the two devices and I came 
>up with a very stupid idea: what if my SoC bus (possibly a wishbone) 
>gets extended to the other FPGA as well?
>
>


If you do a full bus the number of signals will be a problem so you will
want to trim them down. You may also want to combine the read and write
datas in a single bidirectional bus to save pins.

Do assign the slave fpga it's own memory space so that any time you move a
module then it's address will change. Otherwise you have to wait for a
slower out of chip response on every access.

I have seen this done using fpgas with SERDES to serialize a amba ahb.

John Eaton	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156836
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: Brane2 <brankob@avtomatika.com>
Date: Mon, 7 Jul 2014 11:52:45 -0700 (PDT)
Links: << >> << T >> << A >>

Dne nedelja, 06. julij 2014 20:56:01 UTC je oseba Tim napisala:
> Interesting. Have they cancelled the XO3-H?
> 

Look at their website. After all fanfares, they revealed XO3 that was functionally on paper nothing like what was promised.

Then, they hastily added in the XO3 family introduction that this is only low end of the family and that high end XO3H is yet to come.

And now that sentence has dissapeared. If you click on XO3 family intro on latticesemi.com, there is nothing about XO3H. 
Crap.

Article: 156837
Subject: Using FPGA as dual ported ram
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Tue, 08 Jul 2014 16:43:32 +0200
Links: << >> << T >> << A >>

To interface a fast sampling ADC to a CPU I'm considering to use a fifo
or dual ported ram and a small controlling CPLD. Cypress has a nice
offering of fifos and dp-rams, but looking at the prices of 512kb
density parts I got a bit of a shock: $75 for the fifo and $45 for the
dp-ram. That's in single quantity, but they don't go down fast either:
$30/1000+ for the dp-ram. :-(
(prices from cypress website)

For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+
$14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD'
for free. OK you still need a config memory.
(prices from avnet website)

Can you just connect one side of the block ram to IO pins and read that
from a CPU as if it where a dp-ram? Other side interface would even be
simpler as you can keep it internal.

Am I missing something here or is it really that simple?
(And yes, I do realize  I have to program the FPGA to perform the
required function ;-) )

Sample rate is not extremely high (10MSPS), but too fast for the CPU to
read on interrupts directly. There may be other options, still
investigating.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

One man's constant is another man's variable.
		-- A.J. Perlis

Article: 156838
Subject: Re: Using FPGA as dual ported ram
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Tue, 8 Jul 2014 08:55:40 -0700
Links: << >> << T >> << A >>

On Tue, 08 Jul 2014 16:43:32 +0200
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

> 
> Can you just connect one side of the block ram to IO pins and read that
> from a CPU as if it where a dp-ram? Other side interface would even be
> simpler as you can keep it internal.
> 
> Am I missing something here or is it really that simple?
> (And yes, I do realize  I have to program the FPGA to perform the
> required function ;-) )
> 

You'll find that the CPU memory bus interface and the FPGA BRAM
interface don't 100% match up, so you have to put a bit of glue logic
(in the FPGA fabric) in the middle, but more yes than no.

It'll be things like, the BRAM is going to be synchronous whereas the
memory bus expects to be asynch, so you'll want to latch the membus
signals and resynchronize the strobes (CS, WE, OE) to make sure you
don't have any glitches, etc.  But yeah, you're talking about
instantianting a BRAM from the library and throwing a few dozen lines
of code around it.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 156839
Subject: Re: ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit
From: Brane2 <brankob@avtomatika.com>
Date: Tue, 8 Jul 2014 09:28:34 -0700 (PDT)
Links: << >> << T >> << A >>

Dne nedelja, 06. julij 2014 19:03:56 UTC je oseba KJ napisala:


>=20
> But there is not much call for 4-bit counters.  Move them around all you =
like and let us know if you can create a video coder/decoder or some other =
functionality that has usefulness.=20


You are comparing apples to helicopters. I used 4-bit counter just as an si=
mple example. Just as you can use symbollics to describe more complex struc=
tures in HDL, there is nothing preventing that in graphically oriented appr=
oach.



>  Even your statement "Once I would complete say 4-bit counter", shows the=
 >lack  of being productive.  Most anyone skilled in HDL would probably hav=
e >trouble even quantifying the amount of time required to 'complete a 4-bi=
t >counter' it would be so small.=20

Really ? Examples around me say exactle the opposite. FPGA is relatively ex=
pensive. It's not a peanut like some ARM. And it carries quite a few additi=
onal considerations.=20

At least in my price and volume ranges, chip utilisation counts. My extra w=
ork less so.

And quite frequently I can find people trying to see through the "fog" and =
to aqueeze extra performance. Then all those symbolic levels start working =
against the designer.

But this is theme for another dilemme.

I'v got renewed license. It supports a couple of ECP5-U and ECP5-UM, probab=
ly those models that they have in productions already.

If anyone is inteerseted in details, as of this moment, I can select:

LFE5U, LFE5UM and LAE5UM in 25F,45F and 85F densities.

Article: 156840
Subject: Re: Using FPGA as dual ported ram
From: "mnentwig" <24789@embeddedrelated>
Date: Tue, 08 Jul 2014 12:05:48 -0500
Links: << >> << T >> << A >>

Hi,

Maybe this helps,an FPGA module with a mid-size Spartan 6 LX 75 device and
lots of IOs:
http://numato.com/saturn-spartan-6-fpga-development-board-with-ddr-sdram
Best enjoyed with a JTAG programmer (i.e. Xilinx "USB" JTAG from ebay) as
it doesn't support direct FPGA programming via USB, but reprogramming goes
through the somewhat slower Flash memory.

AFAIK, also the larger LX 75 can be programmed without paying for a
license. A google search "Spartan 6 LX 75 board" shows some boards but I
haven't tried any of those.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156841
Subject: Re: Using FPGA as dual ported ram
From: "mnentwig" <24789@embeddedrelated>
Date: Tue, 08 Jul 2014 12:29:24 -0500
Links: << >> << T >> << A >>

>> Best enjoyed with a JTAG programmer 
correction: one post on the linked page states that it can now be
programmed directly => no need for JTAG.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156842
Subject: Perl + Xilinx + commandline = Module::Build::Xilinx
From: vicash <walburn@gmail.com>
Date: Tue, 8 Jul 2014 13:03:05 -0700 (PDT)
Links: << >> << T >> << A >>

Hello

I have released Module::Build::Xilinx (currently at version 0.05) to CPAN. (https://metacpan.org/pod/Module::Build::Xilinx)

This is a tool that you can use to create a simple makefile like Build.PL script such as done by standard perl modules.

Module::Build::Xilinx subclasses Module::Build to create, build, simulate, view and program Xilinx FPGA development boards by using Perl to manage the Xilinx ISE environment.

You can now do all of this from the commandline and create a lot of required files automatically by typing a couple of commands on the command line.

For example, to create a new project from existing source code with VHDL files in the following tree structure:

--+Build.PL
--+src/toplevel.vhd (and any number of other VHDL files in sub-directories)
--+tb/testbench.vhd (and any number of testbenches)

You will just have to write the following:

$ perl ./Build.PL

The above will create the custom Build file for your project which can be used as below to build a bitstream:

$ ./Build pbuild

This will build the bitstream as expected using the installed Xilinx ISE software.

To run a simulation of a testbench you can do:

$ ./Build simulate

This will use Xilinx's fuse to create a testbench EXE and executes it.

To view the output using ISimGUI you run

$ ./Build view

To program an FPGA device using iMPACT you do:

$ ./Build program --device=/dev/mydevice

The software works the same way on both Windows and Linux. On Windows, I recommend using Strawberry Perl or similar to run Perl and not Cygwin.

More details such as examples and detailed documentation can be seen at : 
https://metacpan.org/pod/Module::Build::Xilinx

As time progresses and if there is a demand, I will add Verilog support which may be trivial to add to the software.

Please let me know if you end up using it and if you have issues or feature suggestions. Please email me at the email below for issue/bug-reports.

Thanks
vicash (vikas_AT_cpan.org) (replace _AT_ with @)

Article: 156843
Subject: Re: Perl + Xilinx + commandline = Module::Build::Xilinx
From: vicash <walburn@gmail.com>
Date: Tue, 8 Jul 2014 13:08:35 -0700 (PDT)
Links: << >> << T >> << A >>

In addition to this Xilinx ISE 13.x has been thoroughly tested and if you have Xilinx Vivado or a higher version please try and let me know.

Thanks
vikas (vikas_AT_cpan.org)(replace _AT_ with @)

Article: 156844
Subject: Re: Using FPGA as dual ported ram
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 08 Jul 2014 16:54:21 -0400
Links: << >> << T >> << A >>

Stef wrote:
> To interface a fast sampling ADC to a CPU I'm considering to use a fifo
> or dual ported ram and a small controlling CPLD. Cypress has a nice
> offering of fifos and dp-rams, but looking at the prices of 512kb
> density parts I got a bit of a shock: $75 for the fifo and $45 for the
> dp-ram. That's in single quantity, but they don't go down fast either:
> $30/1000+ for the dp-ram. :-(
> (prices from cypress website)
> 
> For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+
> $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD'
> for free. OK you still need a config memory.
> (prices from avnet website)

You wrote 512kB which usually means kilobytes.  The LX9 has 512 Kb which
means kilobits, or 64 kilobytes.  If you really needed 512 kilobytes,
you would need a much larger part: Spartan 6 LX100, or Artix-7 100T.
On the other hand you wrote 512kb when you talked about Cypress parts...

> Can you just connect one side of the block ram to IO pins and read that
> from a CPU as if it where a dp-ram? Other side interface would even be
> simpler as you can keep it internal.
> 
> Am I missing something here or is it really that simple?
> (And yes, I do realize  I have to program the FPGA to perform the
> required function ;-) )
> 
> Sample rate is not extremely high (10MSPS), but too fast for the CPU to
> read on interrupts directly. There may be other options, still
> investigating.
> 

As others have said, the work involved is not a lot and depends on
the CPU bus.  I suspect that the "small controlling CPLD" code would
include pretty much the same logic you'd plug into the FPGA other
than the DP RAM.

-- 
Gabor

Article: 156845
Subject: Re: Perl + Xilinx + commandline = Module::Build::Xilinx
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 08 Jul 2014 16:59:01 -0400
Links: << >> << T >> << A >>

vicash wrote:
> In addition to this Xilinx ISE 13.x has been thoroughly tested and if you have Xilinx Vivado or a higher version please try and let me know.
> 
> Thanks
> vikas (vikas_AT_cpan.org)(replace _AT_ with @)

On the web page I see:

The language supported in the project is VHDL. We do not yet support 
Verilog.

Any plan to support Verilog or mixed language projects?

-- 
Gabor

Article: 156846
Subject: Re: Linux driver for Xilinx axi_10g_ethernet_0_ten_gig_eth_mac core?
From: JohnG <gomijacogeo@gmail.com>
Date: Tue, 8 Jul 2014 14:15:28 -0700 (PDT)
Links: << >> << T >> << A >>

On Tuesday, June 3, 2014 1:15:28 PM UTC-7, wza...@gmail.com wrote:
> OK. I have not described the setuo fully. This is a system implemented
> on the FPGA based board (now the standard KC705, later a custom board).
> The system consists of the Microblaze wit DDR RAM and some peripherials
> including the Xilinx 10Gb/s MAC:
>
> http://www.xilinx.com/products/intellectual-property/DO-DI-10GEMAC.htm
> http://www.xilinx.com/support/documentation/ip_documentation/ten_gig_eth_mac/v13_1/pg072-ten-gig-eth-mac.pdf
>
> The Linux system for the above embedded system was successfully compiled
> with Buildroot environment, but I was not able to find the appropriate driver
> for that MAC.
>
> I've searched all accessible kernel repositories (including
> https://github.com/Xilinx/linux-xlnx/tree/master/drivers/net/ethernet/xilinx
>  ) for driver declaring
> compatibility with "xlnx,ten-gig-eth-mac-13.0", but nothing seems to be available.
>
> Of course I can get rid of Microblaze and this MAC, and build something
> based on Wishbone, with MAC: http://opencores.org/project,xge_mac
> (especially if I have to develop the driver myself, I'd rather prefer to
> do it for an open solution, than for the commercial one).
>
> Regards,
> Wojtek

I think your trouble is that you only have a MAC core, not an entire NIC solution.  I think you still need the blocks to interface to the block's AXI4 ports to do DMA to the host(MicroBlaze), manage TX and RX rings, generate interrupts, etc.

Maybe this: https://github.com/NetFPGA/NetFPGA-public/wiki/NetFPGA-10G-Reference-NIC

http://www.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf
Figure 2-19 shows a prototype ethernet for MicroBlaze architecture.
-JohnG

Article: 156847
Subject: Re: Using FPGA as dual ported ram
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Tue, 08 Jul 2014 23:18:21 +0200
Links: << >> << T >> << A >>

In comp.arch.fpga,
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> On Tue, 08 Jul 2014 16:43:32 +0200
> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>> 
>> Can you just connect one side of the block ram to IO pins and read that
>> from a CPU as if it where a dp-ram? Other side interface would even be
>> simpler as you can keep it internal.
>> 
>> Am I missing something here or is it really that simple?
>> (And yes, I do realize  I have to program the FPGA to perform the
>> required function ;-) )
>> 
>
> You'll find that the CPU memory bus interface and the FPGA BRAM
> interface don't 100% match up, so you have to put a bit of glue logic
> (in the FPGA fabric) in the middle, but more yes than no.
>
> It'll be things like, the BRAM is going to be synchronous whereas the
> memory bus expects to be asynch, so you'll want to latch the membus
> signals and resynchronize the strobes (CS, WE, OE) to make sure you
> don't have any glitches, etc.  But yeah, you're talking about
> instantianting a BRAM from the library and throwing a few dozen lines
> of code around it.

OK, still need the resync, no direct connect to BRAM. So it will be
very similar to a simple I/O register interface that I did years ago in
a spartan-3. Thanks for the heads up.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Plan to throw one away.  You will anyway."
- Fred Brooks, "The Mythical Man Month"

Article: 156848
Subject: Re: Using FPGA as dual ported ram
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Tue, 08 Jul 2014 23:36:34 +0200
Links: << >> << T >> << A >>

In comp.arch.fpga,
GaborSzakacs <gabor@alacron.com> wrote:
> Stef wrote:
>> To interface a fast sampling ADC to a CPU I'm considering to use a fifo
>> or dual ported ram and a small controlling CPLD. Cypress has a nice
>> offering of fifos and dp-rams, but looking at the prices of 512kb
>> density parts I got a bit of a shock: $75 for the fifo and $45 for the
>> dp-ram. That's in single quantity, but they don't go down fast either:
>> $30/1000+ for the dp-ram. :-(
>> (prices from cypress website)
>> 
>> For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+
>> $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD'
>> for free. OK you still need a config memory.
>> (prices from avnet website)
>
> You wrote 512kB which usually means kilobytes.  The LX9 has 512 Kb which
> means kilobits, or 64 kilobytes.  If you really needed 512 kilobytes,
> you would need a much larger part: Spartan 6 LX100, or Artix-7 100T.
> On the other hand you wrote 512kb when you talked about Cypress parts...

Sorry for the typo, the second should also have been "kb", so the LX9
should be OK.

I wouldn't dare looking up the price of a cypress 512kB FIFO after what
I saw on their website earlier today. ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Asynchronous inputs are at the root of our race problems.
		-- D. Winker and F. Prosser

Article: 156849
Subject: Re: Perl + Xilinx + commandline = Module::Build::Xilinx
From: vicash <walburn@gmail.com>
Date: Tue, 8 Jul 2014 15:17:01 -0700 (PDT)
Links: << >> << T >> << A >>


>=20
> Any plan to support Verilog or mixed language projects?


Yes I do have a plan. If you have a sample example that you can provide for=
 each that does something really simple like a flip-flop or register then I=
 can use that as a basis for testing and development. Supporting Verilog sh=
ould just be a matter of minutes if not a couple of hours.

I am a novice VHDL programmer and do not do any Verilog yet.

--vicash=20

Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search