Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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$=20Article: 156826
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? -- RickArticle: 156827
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 1Article: 156828
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. AlArticle: 156829
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
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
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
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 JenningsArticle: 156833
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
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. -- RickArticle: 156835
>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.comArticle: 156836
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
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. PerlisArticle: 156838
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
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
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.comArticle: 156841
>> 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.comArticle: 156842
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
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
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. -- GaborArticle: 156845
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? -- GaborArticle: 156846
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. -JohnGArticle: 156847
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
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. ProsserArticle: 156849
>=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
Threads starting:
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