myhdl-list Mailing List for MyHDL (Page 16)
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list — Mailing list for discussions on MyHDL
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
| 2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
| 2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
| 2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
| 2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
| 2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
| 2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
| 2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
| 2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
| 2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
| 2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
| 2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
| 2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
| 2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
| 2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
| 2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Edward V. <dev...@sb...> - 2015-09-17 13:12:37
|
Hello All,Ran the test that Chris provided "time python ex_icestick.py" on 2 Ubuntu 12.04(2 core & 6 core AMD) and Pi 2B built w/yocto. GCC needed to be upgraded to 4.9 from 4.6 to compile the tools. This site provides and explanation on how to upgrade. http://charette.no-ip.com:81/programming/2011-12-24_GCCv47/ | Yocto Pi 2B | | | | | | real | 0m20.943s | | user | 0m12.210s | | sys | 0m0.500s | | | | | Ubuntu 2 core | | | real | 0m5.310s | | user | 0m1.865s | | sys | 0m0.197s | | | | | Ubuntu 6 core | | | | | | real | 0m3.956s | | user | 0m1.093s | | sys | 0m0.120s | Dave completed the layout of the ICE-40 board a few days ago. - Lattice iCE40-HX8K FPGA in 256-pin BGA. - 32 MByte SDRAM (16M x 16). - Serial configuration flash (at least 2 Mbit). - Three Grove connectors. - Two PMOD connectors. - One 20x2 header with 3.3V, ground and 18 FPGA I/Os. - Two SATA headers (for differential signals; don't know if they would work with SATA HDDs.) - DIP switch with four SPST switches. - Two momentary pushbuttons. - Four LEDs. - 32 KByte HAT EEPROM. - 40-pin RPi GPIO header. Excited to test. Let me know if you have any questions.Cheers Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Tuesday, September 15, 2015 7:11 AM, Edward Vidal <dev...@sb...> wrote: Chris,Test results myhdl 15 sec yosys 11 sec The resulting files are located at https://github.com/develone/raspberrypi2_yocto.git The folder benchmark_yosys contains the file bench_mark_yosys.txt the steps I used and the files generated on RaspBerry Pi 2B. It also has the iceiver folder. Note chmod +x iceriver/icestick.sh to make it work. Now need to compare the generated files that you got on Ubuntu.Let me if that is what you wanted. I do not have a board to test the bin file.Regards Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Monday, September 14, 2015 10:28 PM, Christopher Felton <chr...@gm...> wrote: On 9/14/15 2:32 PM, Edward Vidal wrote: > Hi Chris, I added code to compute the shasum and now the make test is > running longer. I now are seeing 29 bin files. This after > installing the shasum which is about 50 mins. > > ls -la ~/shasum ; date -rwxr-xr-x 1 root root 23216 Sep 14 17:27 > /home/root/shasum Mon Sep 14 18:09:18 UTC 2015 Kinda, but I was curious how long it would comparatively take to generate a bitstream starting with a myhdl file. I don't have an R2 (or 1) to test but the following is an example starting with a myhdl file, generating a bitstream for an icestick using the open-source tools [1]. I built this into some automation stuff I have used in the past. Running the example on my old'sh ubuntu system I get: >> time python ex_icestick.py real 0m3.6s The above converts the simple myhdl file, then runs the yosys/arachne/icestorm to generate the bitstream. I don't have an icestick so I couldn't test it. Regards, Chris [1] https://github.com/cfelton/rhea/blob/master/examples/build/ex_icestick.py ------------------------------------------------------------------------------ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list ------------------------------------------------------------------------------ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Edward V. <dev...@sb...> - 2015-09-15 13:11:30
|
Chris,Test results myhdl 15 sec yosys 11 sec The resulting files are located at https://github.com/develone/raspberrypi2_yocto.git The folder benchmark_yosys contains the file bench_mark_yosys.txt the steps I used and the files generated on RaspBerry Pi 2B. It also has the iceiver folder. Note chmod +x iceriver/icestick.sh to make it work. Now need to compare the generated files that you got on Ubuntu.Let me if that is what you wanted. I do not have a board to test the bin file.Regards Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Monday, September 14, 2015 10:28 PM, Christopher Felton <chr...@gm...> wrote: On 9/14/15 2:32 PM, Edward Vidal wrote: > Hi Chris, I added code to compute the shasum and now the make test is > running longer. I now are seeing 29 bin files. This after > installing the shasum which is about 50 mins. > > ls -la ~/shasum ; date -rwxr-xr-x 1 root root 23216 Sep 14 17:27 > /home/root/shasum Mon Sep 14 18:09:18 UTC 2015 Kinda, but I was curious how long it would comparatively take to generate a bitstream starting with a myhdl file. I don't have an R2 (or 1) to test but the following is an example starting with a myhdl file, generating a bitstream for an icestick using the open-source tools [1]. I built this into some automation stuff I have used in the past. Running the example on my old'sh ubuntu system I get: >> time python ex_icestick.py real 0m3.6s The above converts the simple myhdl file, then runs the yosys/arachne/icestorm to generate the bitstream. I don't have an icestick so I couldn't test it. Regards, Chris [1] https://github.com/cfelton/rhea/blob/master/examples/build/ex_icestick.py ------------------------------------------------------------------------------ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher F. <chr...@gm...> - 2015-09-15 04:27:32
|
On 9/14/15 2:32 PM, Edward Vidal wrote:
> Hi Chris, I added code to compute the shasum and now the make test is
> running longer. I now are seeing 29 bin files. This after
> installing the shasum which is about 50 mins.
>
> ls -la ~/shasum ; date -rwxr-xr-x 1 root root 23216 Sep 14 17:27
> /home/root/shasum Mon Sep 14 18:09:18 UTC 2015
Kinda, but I was curious how long it would comparatively
take to generate a bitstream starting with a myhdl file.
I don't have an R2 (or 1) to test but the following is
an example starting with a myhdl file, generating a
bitstream for an icestick using the open-source tools [1].
I built this into some automation stuff I have used in
the past. Running the example on my old'sh ubuntu system
I get:
>> time python ex_icestick.py
real 0m3.6s
The above converts the simple myhdl file, then runs the
yosys/arachne/icestorm to generate the bitstream. I
don't have an icestick so I couldn't test it.
Regards,
Chris
[1]
https://github.com/cfelton/rhea/blob/master/examples/build/ex_icestick.py
|
|
From: Edward V. <dev...@sb...> - 2015-09-14 19:32:21
|
tests/ |-- combinatorial | |-- generate.py | `-- run-test.sh |-- fsm | |-- 1k | | |-- uut_00000.log | | |-- uut_00000.pnr-log | | |-- uut_00000_gate.bin | | |-- uut_00000_gate.blif | | |-- uut_00000_gate.chip.txt | | |-- uut_00000_gate.pcf | | |-- uut_00000_gate.v | | |-- uut_00000_pp.log | | |-- uut_00000_pp.v | | |-- uut_00001.log | | |-- uut_00001.pnr-log | | |-- uut_00001_gate.bin | | |-- uut_00001_gate.blif | | |-- uut_00001_gate.chip.txt | | |-- uut_00001_gate.pcf | | |-- uut_00001_gate.v | | |-- uut_00001_pp.log | | |-- uut_00001_pp.v | | |-- uut_00002.log | | |-- uut_00002.pnr-log | | |-- uut_00002_gate.bin | | |-- uut_00002_gate.blif | | |-- uut_00002_gate.chip.txt | | |-- uut_00002_gate.pcf | | |-- uut_00002_gate.v | | |-- uut_00002_pp.log | | |-- uut_00002_pp.v | | |-- uut_00003.log | | |-- uut_00003.pnr-log | | |-- uut_00003_gate.bin | | |-- uut_00003_gate.blif | | |-- uut_00003_gate.chip.txt | | |-- uut_00003_gate.pcf | | |-- uut_00003_gate.v | | |-- uut_00003_pp.log | | |-- uut_00003_pp.v | | |-- uut_00004.log | | |-- uut_00004.pnr-log | | |-- uut_00004_gate.bin | | |-- uut_00004_gate.blif | | |-- uut_00004_gate.chip.txt | | |-- uut_00004_gate.pcf | | |-- uut_00004_gate.v | | |-- uut_00004_pp.log | | |-- uut_00004_pp.v | | |-- uut_00005.log | | |-- uut_00005.pnr-log | | |-- uut_00005_gate.bin | | |-- uut_00005_gate.blif | | |-- uut_00005_gate.chip.txt | | |-- uut_00005_gate.pcf | | |-- uut_00005_gate.v | | |-- uut_00005_pp.log | | |-- uut_00005_pp.v | | |-- uut_00006.log | | |-- uut_00006.pnr-log | | |-- uut_00006_gate.bin | | |-- uut_00006_gate.blif | | |-- uut_00006_gate.chip.txt | | |-- uut_00006_gate.pcf | | |-- uut_00006_gate.v | | |-- uut_00006_pp.log | | |-- uut_00006_pp.v | | |-- uut_00007.log | | |-- uut_00007.pnr-log | | |-- uut_00007_gate.bin | | |-- uut_00007_gate.blif | | |-- uut_00007_gate.chip.txt | | |-- uut_00007_gate.pcf | | |-- uut_00007_gate.v | | |-- uut_00007_pp.log | | |-- uut_00007_pp.v | | |-- uut_00008.pnr-log | | |-- uut_00008_gate.blif | | `-- uut_00008_pp.v | |-- generate.py | |-- run-test.sh | `-- temp | |-- uut_00000.v | |-- uut_00000.ys | |-- uut_00000_pp.ys | |-- uut_00001.v | |-- uut_00001.ys | |-- uut_00001_pp.ys | |-- uut_00002.v | |-- uut_00002.ys | |-- uut_00002_pp.ys | |-- uut_00003.v | |-- uut_00003.ys | |-- uut_00003_pp.ys | |-- uut_00004.v | |-- uut_00004.ys | |-- uut_00004_pp.ys | |-- uut_00005.v | |-- uut_00005.ys | |-- uut_00005_pp.ys | |-- uut_00006.v | |-- uut_00006.ys | |-- uut_00006_pp.ys | |-- uut_00007.v | |-- uut_00007.ys | |-- uut_00007_pp.ys | |-- uut_00008.v | |-- uut_00008.ys | |-- uut_00008_pp.ys | |-- uut_00009.v | |-- uut_00009.ys | |-- uut_00009_pp.ys | |-- uut_00010.v | |-- uut_00010.ys | |-- uut_00010_pp.ys | |-- uut_00011.v | |-- uut_00011.ys | |-- uut_00011_pp.ys | |-- uut_00012.v | |-- uut_00012.ys | |-- uut_00012_pp.ys | |-- uut_00013.v | |-- uut_00013.ys | |-- uut_00013_pp.ys | |-- uut_00014.v | |-- uut_00014.ys | |-- uut_00014_pp.ys | |-- uut_00015.v | |-- uut_00015.ys | |-- uut_00015_pp.ys | |-- uut_00016.v | |-- uut_00016.ys | |-- uut_00016_pp.ys | |-- uut_00017.v | |-- uut_00017.ys | |-- uut_00017_pp.ys | |-- uut_00018.v | |-- uut_00018.ys | |-- uut_00018_pp.ys | |-- uut_00019.v | |-- uut_00019.ys | |-- uut_00019_pp.ys | |-- uut_00020.v | |-- uut_00020.ys | |-- uut_00020_pp.ys | |-- uut_00021.v | |-- uut_00021.ys | |-- uut_00021_pp.ys | |-- uut_00022.v | |-- uut_00022.ys | |-- uut_00022_pp.ys | |-- uut_00023.v | |-- uut_00023.ys | |-- uut_00023_pp.ys | |-- uut_00024.v | |-- uut_00024.ys | `-- uut_00024_pp.ys |-- regression | |-- 1k | | |-- bram1.bin | | |-- bram1.txt | | |-- carry_pack_fail1.bin | | |-- carry_pack_fail1.txt | | |-- carry_route_fail1.chip.v | | |-- carry_route_fail1.log | | |-- carry_route_fail1.pcf | | |-- carry_route_fail1.txt | | |-- test1.bin | | |-- test1.txt | | |-- test2.bin | | `-- test2.txt | |-- 8k | | |-- bram1.bin | | |-- bram1.txt | | |-- carry_pack_fail1.bin | | |-- carry_pack_fail1.txt | | |-- carry_route_fail1.chip.v | | |-- carry_route_fail1.log | | |-- carry_route_fail1.pcf | | |-- carry_route_fail1.txt | | |-- test1.bin | | |-- test1.txt | | |-- test2.bin | | `-- test2.txt | |-- bram1.blif | |-- carry_pack_fail1.blif | |-- carry_route_fail1.blif | |-- carry_route_fail1.v | |-- run-test.sh | |-- test1.blif | `-- test2.blif |-- simple | |-- 1k | | |-- bram.bin | | |-- bram.txt | | |-- carry.bin | | |-- carry.txt | | |-- chipdb-1k.bin | | |-- chipdb2-1k.bin | | |-- sb_up3down5.bin | | |-- sb_up3down5.txt | | |-- sb_up3down5_l.bin | | |-- sb_up3down5_l.txt | | |-- sb_up3down5_packed.bin | | |-- sb_up3down5_packed.blif | | `-- sb_up3down5_packed.txt | |-- 8k | | |-- bram.bin | | |-- bram.txt | | |-- carry.bin | | |-- carry.txt | | |-- chipdb-8k.bin | | |-- chipdb2-8k.bin | | |-- sb_up3down5.bin | | |-- sb_up3down5.txt | | |-- sb_up3down5_l.bin | | |-- sb_up3down5_l.txt | | |-- sb_up3down5_packed.bin | | |-- sb_up3down5_packed.blif | | `-- sb_up3down5_packed.txt | |-- bram.blif | |-- carry.blif | |-- run-test.sh | |-- run-valgrind-test.sh | |-- sb_up3down5.blif | `-- txt.sum |-- test_bv |-- test_bv.cc |-- test_bv.d |-- test_bv.o |-- test_us |-- test_us.cc |-- test_us.d `-- test_us.o 10 directories, 225 files |
|
From: Christopher F. <chr...@gm...> - 2015-09-14 18:11:42
|
On 9/14/2015 12:30 PM, Edward Vidal wrote: > Hi all, I just completed building the tools (Yosys, arachne-pnr, and > icebox) for the Lattice ICE-40. It appears this will fit on a 4GB > SD card. > > With the board that XESS is making this will be a standalone > HDL development system with GTKWave, XSTOOLs, Iverilog, > arachne-pnr(place and route), Yosys (Yosys is a framework for Verilog > RTL synthesis), icebox(this will not be needed since XESS is going to > push the bit file with GPIO instead of USB), and MyHDL.These were > built on a custom image for the Raspberry Pi 2 B with Yocto. Do you have any benchmarks how long a small design takes to go through the complete toolflow on the R2? Regards, Chris |
|
From: Edward V. <dev...@sb...> - 2015-09-14 17:30:59
|
Hi all, I just completed building the tools (Yosys, arachne-pnr, and icebox) for the Lattice ICE-40. It appears this will fit on a 4GB SD card. With the board that XESS is making this will be a standalone HDL development system with GTKWave, XSTOOLs, Iverilog, arachne-pnr(place and route), Yosys (Yosys is a framework for Verilog RTL synthesis), icebox(this will not be needed since XESS is going to push the bit file with GPIO instead of USB), and MyHDL.These were built on a custom image for the Raspberry Pi 2 B with Yocto. If you have any questions let me know.Regards, Below are some tests that I ran on Raspberry Pi 2 B. g++ -Isrc -std=c++11 -MD -O2 -Wall -Wshadow -Wsign-compare -Werror -c -o tests/test_bv.o tests/test_bv.cc g++ -Isrc -std=c++11 -MD -O2 -Wall -Wshadow -Wsign-compare -Werror -o tests/test_bv tests/test_bv.o g++ -Isrc -std=c++11 -MD -O2 -Wall -Wshadow -Wsign-compare -Werror -c -o tests/test_us.o tests/test_us.cc g++ -Isrc -std=c++11 -MD -O2 -Wall -Wshadow -Wsign-compare -Werror -o tests/test_us tests/test_us.o ./tests/test_bv ./tests/test_us make -C examples/rot clean && make -C examples/rot make[1]: Entering directory '/home/root/arachne-pnr/examples/rot' rm -f rot.blif rot.txt rot.ex rot.bin make[1]: Leaving directory '/home/root/arachne-pnr/examples/rot' make[1]: Entering directory '/home/root/arachne-pnr/examples/rot' yosys -q -p "synth_ice40 -blif rot.blif" rot.v Warning: Wire top.ready has an unprocessed 'init' attribute. ../../bin/arachne-pnr -p rot.pcf rot.blif -o rot.txt seed: 1 device: 1k read_chipdb +/share/arachne-pnr/chipdb-1k.bin... supported packages: tq144 read_blif rot.blif... prune... read_pcf rot.pcf... instantiate_io... pack... After packing: IOs 6 / 96 LCs 66 / 1280 DFF 29 CARRY 23 CARRY, DFF 0 DFF PASS 5 CARRY PASS 2 BRAMs 0 / 16 WARMBOOTs 0 / 1 GBs 0 / 8 promote_globals... promoted clk$2, 29 / 29 promoted $abc$447$n1, 28 / 28 promoted 2 nets 1 sr/we 1 clk 2 globals 1 sr/we 1 clk realize_constants... realized 1 place... initial wire length = 1015 final wire length = 101 After placement: PIOs 4 / 96 PLBs 16 / 160 BRAMs 0 / 16 place time 2.03s route... pass 1, 0 shared. route time 0.72s write_txt rot.txt... icebox_explain rot.txt > rot.ex icepack rot.txt rot.bin make[1]: Leaving directory '/home/root/arachne-pnr/examples/rot' cd tests/simple && ICEBOX=/usr/local/share/icebox bash run-test.sh + arachne_pnr=../../bin/arachne-pnr + devices='1k 8k' + : /usr/local/share/icebox + rm -f txt.sum + for d in '$devices' + rm -rf 1k + mkdir 1k + ../../bin/arachne-pnr -d 1k -c /usr/local/share/icebox/chipdb-1k.txt --write-binary-chipdb 1k/chipdb-1k.bin seed: 1 device: 1k read_chipdb /usr/local/share/icebox/chipdb-1k.txt... write_binary_chipdb 1k/chipdb-1k.bin + ../../bin/arachne-pnr -d 1k -c 1k/chipdb-1k.bin --write-binary-chipdb 1k/chipdb2-1k.bin seed: 1 device: 1k read_chipdb 1k/chipdb-1k.bin... write_binary_chipdb 1k/chipdb2-1k.bin + cmp 1k/chipdb-1k.bin 1k/chipdb2-1k.bin + ../../bin/arachne-pnr -d 1k sb_up3down5.blif -o 1k/sb_up3down5.txt seed: 1 device: 1k read_chipdb +/share/arachne-pnr/chipdb-1k.bin... supported packages: tq144 read_blif sb_up3down5.blif... prune... instantiate_io... pack... After packing: IOs 24 / 96 LCs 50 / 1280 DFF 12 CARRY 0 CARRY, DFF 0 DFF PASS 7 CARRY PASS 0 BRAMs 0 / 16 WARMBOOTs 0 / 1 GBs 0 / 8 promote_globals... promoted clock$2, 12 / 12 promoted 1 nets 1 clk 1 globals 1 clk realize_constants... place... initial wire length = 383 final wire length = 169 After placement: PIOs 13 / 96 PLBs 15 / 160 BRAMs 0 / 16 place time 2.60s route... pass 1, 0 shared. route time 0.88s write_txt 1k/sb_up3down5.txt... + shasum 1k/sb_up3down5.txt run-test.sh: line 21: shasum: command not found Makefile:50: recipe for target 'test' failed make: *** [test] Error 127 Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 |
|
From: Christopher F. <chr...@gm...> - 2015-09-08 16:16:25
|
On 9/3/15 6:29 AM, Guy Eschemann wrote: > Hi, > > I wonder whether it would be possible to make error messages like the > following one a bit more verbose: > > myhdl.ConversionError: in file > E:\Projects\XXX\XXX\hg_hw\python\byte_align_resumable.py, line 58: > Type mismatch with earlier assignment: out_byte_idx_v > > Maybe print a list of the earlier assignments, along with the > corresponding type information. That could make debugging such issues a > bit easier. > What might be a little easier, is to add a "little" static analysis to the decorators. At that point a "warning" message could be supplied. But this could get ugly, at this point I don't know if this would generate many superfluous warnings (like many of the existing FPGA tools). Another common error (and sometimes hard to debug) is when folks mix `bool` and `intbv()[1:]`. Regards, Chris |
|
From: Josy B. <jos...@gm...> - 2015-09-08 12:07:40
|
Hi Guy, > I believe this has something to do with how name assignment works in Python. There's a section about this in the manual at http://docs.myhdl.org/en/stable/manual/conversion.html#intbv-objects > > > My only criticism is that if you do it wrong (e.g. forget the "[:]"), you get an error message that is of little help to debug the issue. > Thanks for pointing this out. I guess the error code could be extended to include "Did you forget [:]?" Assuming this error code only applies to exactly this case (it probably does). I experimented a bit and found out I was wandering astray somewhat. Using an intbv assignment without the [:] would bind the name to another object. Using [:] avoids this and updates the actual intbv object itself. Now I still am struggling a bit with the idea of having to use [:] on the LHS of the assignment especially as you don't have to when using an Augmented Assign (e.g. +=). I now also understand/recall avoiding this error by converting the arguments into integers in my code. Regards, Josy |
|
From: Guy E. <guy...@gm...> - 2015-09-08 07:13:17
|
Hi Josy, I believe this has something to do with how name assignment works in Python. There's a section about this in the manual at http://docs.myhdl.org/en/stable/manual/conversion.html#intbv-objects My only criticism is that if you do it wrong (e.g. forget the "[:]"), you get an error message that is of little help to debug the issue. Regards, Guy. On Mon, Sep 7, 2015 at 9:36 PM, Josy Boelen <jos...@gm...> wrote: > Hi Guy, > > I studied this a bit deeper and went looking for some 'variable' > examples in the MyHDL doc and found this one: > def bin2gray(B, G, width): > > """ Gray encoder. > > B -- input intbv signal, binary encoded > G -- output intbv signal, gray encoded > width -- bit width > > """ > > @always_comb > def logic(): > Bext = intbv(0)[width+1:] > Bext[:] = B > for i in range(width): > G.next[i] = Bext[i+1] ^ Bext[i] > > return logic > > And to my surprise it uses the [:] ... > So it may not be a bug, as it is actually _documented_ behaviour ... > But I maintain that it is inconsistent because e.g.: if I change > count_v = count_v + 1 > into: > count_v += 1 > the conversion will pass without errors. > > Regards, > > Josy > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Josy B. <jos...@gm...> - 2015-09-07 19:36:32
|
Hi Guy,
I studied this a bit deeper and went looking for some 'variable'
examples in the MyHDL doc and found this one:
def bin2gray(B, G, width):
""" Gray encoder.
B -- input intbv signal, binary encoded
G -- output intbv signal, gray encoded
width -- bit width
"""
@always_comb
def logic():
Bext = intbv(0)[width+1:]
Bext[:] = B
for i in range(width):
G.next[i] = Bext[i+1] ^ Bext[i]
return logic
And to my surprise it uses the [:] ...
So it may not be a bug, as it is actually _documented_ behaviour ...
But I maintain that it is inconsistent because e.g.: if I change
count_v = count_v + 1
into:
count_v += 1
the conversion will pass without errors.
Regards,
Josy
|
|
From: Josy B. <jos...@gm...> - 2015-09-07 09:41:00
|
Hi Guy,
> I actually run into this issue quite often, probably because of my
liberal use of variables to store intermediate results. Here's a code
snippet that triggers the conversion error:
>
> ---
>
> from myhdl import *
>
> def mymodule(clk_i, reset_i, count_o):
>
> count_r_s = Signal(intbv(0)[32:])
>
> <at> always_seq(clk_i.posedge, reset=reset_i)
> def logic():
> count_v = count_r_s[:]
> count_v = count_v + 1
> count_r_s.next = count_v
>
> <at> always_comb
> def outputs():
> count_o.next = count_r_s
>
> return instances()
>
> if __name__ == "__main__":
> clk_i = Signal(bool(0))
> reset_i = ResetSignal(0, active=1, async=False)
> count_o = Signal(intbv(0)[32:])
> toVHDL(mymodule, clk_i, reset_i, count_o)
>
> ---
>
>
> Of course, the fix is to change the second variable assignment to:
>
> count_v[:] = count_v + 1
>
> but this is not necessarily obvious from the error message, especially
if you're new to Python/MyHDL. Also, if the same variable gets assigned
many times same function, it may not always be easy to find the
assignment that overwrites the variable (instead of just its value).
>
To my idea, you should have been able to write it as follows:
def mymodule(clk_i, reset_i, count_o):
count_r_s = Signal(intbv(0)[32:])
@always_seq(clk_i.posedge, reset=reset_i)
def logic():
count_v = count_r_s
count_v = count_v + 1
count_r_s.next = count_v
@always_comb
def outputs():
count_o.next = count_r_s
return instances()
so without the [:].
Anyway also when written like this we get the same error message for the
same line. What happens, IMO, is that the converter thinks it sees a
second, duplicate variable declaration and complains ... If you add the
[:] the converter follows another path, as you are slicing, and doesn't
do the 'check' and all ends well. I only use variables sparingly and the
one example I could immediately find does a single assignment only:
endval = int(startValue) + int(Length)
explaining my 'rare' remark.
I'm not sure yet but this may be a bug. Can you show me some code where
you have a more elaborate use of a variable - saving me from writing one
myself?
Best regards,
Josy
|
|
From: Guy E. <guy...@gm...> - 2015-09-06 14:21:29
|
>
> Can you share your code? I looked into the relevant section in the MyHDL
> code and then looked for a trace in my RTL code, but the situation where
> that error might occur is very rare.
>
>
I actually run into this issue quite often, probably because of my liberal
use of variables to store intermediate results. Here's a code snippet that
triggers the conversion error:
---
from myhdl import *
def mymodule(clk_i, reset_i, count_o):
count_r_s = Signal(intbv(0)[32:])
@always_seq(clk_i.posedge, reset=reset_i)
def logic():
count_v = count_r_s[:]
count_v = count_v + 1
count_r_s.next = count_v
@always_comb
def outputs():
count_o.next = count_r_s
return instances()
if __name__ == "__main__":
clk_i = Signal(bool(0))
reset_i = ResetSignal(0, active=1, async=False)
count_o = Signal(intbv(0)[32:])
toVHDL(mymodule, clk_i, reset_i, count_o)
---
Of course, the fix is to change the second variable assignment to:
count_v[:] = count_v + 1
but this is not necessarily obvious from the error message, especially if
you're new to Python/MyHDL. Also, if the same variable gets assigned many
times same function, it may not always be easy to find the assignment that
overwrites the variable (instead of just its value).
What do you think?
Thanks,
Guy.
|
|
From: Josy B. <jos...@gm...> - 2015-09-03 18:26:57
|
> I wonder whether it would be possible to make error messages like the following one a bit more verbose: > > > myhdl.ConversionError: in file E:\Projects\XXX\XXX\hg_hw\python\byte_align_resumable.py, line 58: > Type mismatch with earlier assignment: out_byte_idx_v > > > Maybe print a list of the earlier assignments, along with the corresponding type information. That could make debugging such issues a bit easier. Can you share your code? I looked into the relevant section in the MyHDL code and then looked for a trace in my RTL code, but the situation where that error might occur is very rare. Regards, Josy |
|
From: Guy E. <guy...@gm...> - 2015-09-03 11:29:23
|
Hi,
I wonder whether it would be possible to make error messages like the
following one a bit more verbose:
myhdl.ConversionError: in file
E:\Projects\XXX\XXX\hg_hw\python\byte_align_resumable.py, line 58:
Type mismatch with earlier assignment: out_byte_idx_v
Maybe print a list of the earlier assignments, along with the corresponding
type information. That could make debugging such issues a bit easier.
Regards,
Guy.
|
|
From: Edward V. <dev...@sb...> - 2015-09-01 21:17:07
|
Chris,
The output signal status is the output of the module dut_test which is in the file "ifchains.v".
I can see that signal a in tb_ifchain1 changes from 0 to 12 & signal b in tb_ifchain1 changes from 0 to 2 at time 100 ns.
Just before the 100 ns. I see signal rstn in both tb_ifchain1 & dut_test go high to lo on the positive transition of the clk in both tb_ifchain1 & dut_test.
While the signal status in both tb_ifchain1 & dut_test is always red.
Also the signals a & b are yellow in dut_test and green in tb_ifchain.
Should this be normal, since the signals a & b are only used in dut_test?
I am thinking, not sure, that upper 2 bits of signal a 1100 and the 2nd bit of signal b 0010 should result in the status going to 1 in dut_test.
This would be green in the gtkwave figure. Instead I always see a red signal.
I get the same results on the Raspberry Pi as on the PC. On the PC I am using a different myhdl.vpi which changes the ifchain file at runtime.
My errors now must be how I am setting the values in the file tb_ifchains.v.
Let me if I can provide any other information.
thanks in advance.
Regards Edward Vidal Jr. e-mail dev...@sb... 915-595-1613
On Tuesday, September 1, 2015 1:23 PM, Christopher Felton <chr...@gm...> wrote:
On 9/1/2015 2:05 PM, Edward Vidal wrote:
> Still not getting the status to go green in my co-simulation.I just
> push my latest code to github.Thanks Regards
What "green light" status are you talking about?
Are you talking about travis-ci status? Or do
simply mean the test completes successfully?
Regards,
Chris
------------------------------------------------------------------------------
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list
|
|
From: Christopher F. <chr...@gm...> - 2015-09-01 19:22:58
|
On 9/1/2015 2:05 PM, Edward Vidal wrote: > Still not getting the status to go green in my co-simulation.I just > push my latest code to github.Thanks Regards What "green light" status are you talking about? Are you talking about travis-ci status? Or do simply mean the test completes successfully? Regards, Chris |
|
From: Edward V. <dev...@sb...> - 2015-09-01 19:06:00
|
Chris,Thanks for the information. That helped me.My vcd/ifchain.vcd is starting to show signs of life. I am trying to document my process. Can you take a look at the 2 files below and give me ideas on what is right and what is wrong. https://github.com/develone/raspberrypi2_yocto/blob/master/doc/simulate.pdf and https://github.com/develone/raspberrypi2_yocto/blob/master/doc/tb_xxxx.pdf Still not getting the status to go green in my co-simulation.I just push my latest code to github.Thanks Regards Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 On Tuesday, September 1, 2015 8:03 AM, Christopher Felton <chr...@gm...> wrote: On 8/31/2015 12:25 PM, Edward Vidal wrote: > Hello All, > I am testing VHD2VL and trying to test the outputted file ifchain.v with MyHDL & Iverilog > co-simulation on a Raspberry Pi 2 B. > > I created the files and folder vcd > https://github.com/develone/raspberrypi2_yocto/tree/master/vhd2vl/examples/tb > > ifchain myhdl.vpi tb_ifchain.v test_ifchain.py vcd > <snip> > If in stimlus section of test_ifchain.py. > I comment the lines 25 & 26 I get the results below. > > python test_ifchain.py > Running test... > 0 > *{'a': Signal(intbv(0L)), 'status': Signal(False), 'b': Signal(intbv(0L)), > compiling ... > iverilog -o ifchain ../ifchain.v ./tb_ifchain.v > cosimulation setup ... > vvp -m ./myhdl.vpi ifchain > VCD info: dumpfile vcd/ifchain1.vcd opened for output. > <myhdl._Cosimulation.Cosimulation object at 0x769f6870> > back from prep cosim > start (co)simulation ... > > This appears to work okay but when I gtkwave vcd/ifchain1.vcd > The signals a,b and clk red and status is yellow. > > When the I uncomment lines 25 & 26 try send values to the co-simulation. > The program does not run to completion but crashes with the following error. > File "/usr/lib/python2.7/site-packages/myhdl-1.0dev-py2.7.egg/myhdl/_Waiter.py", line 142, in next > clause = next(self.generator) > File "test_ifchain.py", line 25, in stimlus > a.next = 10 > This actually is not a cosimulation error. I ran your code and the resulting error is: ValueError: intbv value 10 >= maximum 8 In your code your `a` and `b` are: a = Signal(intbv(0)[3:]) b = Signal(intbv(0)[3:]) Now remember, in Python the upper limit is exclusive, you created 3bit bit-vectors. The max value that can be used is 7. You probably intended it to be: a = Signal(intbv(0)[4:]) b = Signal(intbv(0)[4:]) When I make the changes, you code executes without error. Regards, Chris ------------------------------------------------------------------------------ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher F. <chr...@gm...> - 2015-09-01 14:02:20
|
On 8/31/2015 12:25 PM, Edward Vidal wrote: > Hello All, > I am testing VHD2VL and trying to test the outputted file ifchain.v with MyHDL & Iverilog > co-simulation on a Raspberry Pi 2 B. > > I created the files and folder vcd > https://github.com/develone/raspberrypi2_yocto/tree/master/vhd2vl/examples/tb > > ifchain myhdl.vpi tb_ifchain.v test_ifchain.py vcd > <snip> > If in stimlus section of test_ifchain.py. > I comment the lines 25 & 26 I get the results below. > > python test_ifchain.py > Running test... > 0 > *{'a': Signal(intbv(0L)), 'status': Signal(False), 'b': Signal(intbv(0L)), > compiling ... > iverilog -o ifchain ../ifchain.v ./tb_ifchain.v > cosimulation setup ... > vvp -m ./myhdl.vpi ifchain > VCD info: dumpfile vcd/ifchain1.vcd opened for output. > <myhdl._Cosimulation.Cosimulation object at 0x769f6870> > back from prep cosim > start (co)simulation ... > > This appears to work okay but when I gtkwave vcd/ifchain1.vcd > The signals a,b and clk red and status is yellow. > > When the I uncomment lines 25 & 26 try send values to the co-simulation. > The program does not run to completion but crashes with the following error. > File "/usr/lib/python2.7/site-packages/myhdl-1.0dev-py2.7.egg/myhdl/_Waiter.py", line 142, in next > clause = next(self.generator) > File "test_ifchain.py", line 25, in stimlus > a.next = 10 > This actually is not a cosimulation error. I ran your code and the resulting error is: ValueError: intbv value 10 >= maximum 8 In your code your `a` and `b` are: a = Signal(intbv(0)[3:]) b = Signal(intbv(0)[3:]) Now remember, in Python the upper limit is exclusive, you created 3bit bit-vectors. The max value that can be used is 7. You probably intended it to be: a = Signal(intbv(0)[4:]) b = Signal(intbv(0)[4:]) When I make the changes, you code executes without error. Regards, Chris |
|
From: Christopher F. <chr...@gm...> - 2015-08-31 21:21:26
|
On 8/31/2015 3:03 PM, Edward Vidal wrote: > Chris, I mentioned Yosys in the co-simulation thread I just wanted to > provide supporting information if you were interested. Did not mean > to offend anyone. Regards Edward No offense taken but I want to make sure our communication is as efficient and clear as possible. Couple things, first there are numerous folks subscribed to this mailing-list, out of courtesy we don't want to fill peoples inboxes with too many unrelated posts. Second, it wasn't explicitly clear the intent (i.e. providing additional information on ...). The post, from my point of view, is very confusing. It doesn't clearly state what yosys is (although I believe many are familiar with it), it has a couple sentences talking about license? The website about [1] gives a much better description. Third, mentioning yosys in the co-simulation question is actually distracting because it has nothing to do with the issue at hand. I realize, you intend yosys to be part of your flow but for the cosimulation issue it is irrelevant. I am not suggesting the "HDL dev environment in a pi" is interesting or not - just that some of the posts are not particularly related to MyHDL and being a myhdl mailing-list we should try and keep the tangents to a minimum. Regards, Chris [1] http://www.clifford.at/yosys/ |
|
From: Edward V. <dev...@sb...> - 2015-08-31 20:03:26
|
Chris,
I mentioned Yosys in the co-simulation thread I just wanted to provide supporting information if you were interested. Did not mean to offend anyone.
Regards
Edward Vidal Jr. e-mail dev...@sb... 915-595-1613
On Monday, August 31, 2015 1:54 PM, Christopher Felton <chr...@gm...> wrote:
On 8/31/2015 2:43 PM, Edward Vidal wrote:
> Hello All,
>
> From the yosys manual:
> "The proposed custom HDL synthesis tool should be
> licensed under a Free and Open Source Software (FOSS) licence. So an
> existing FOSS Verilog or VHDL synthesis tool would have been needed
> as basis to build upon. The main advantages of choosing Verilog or
> VHDL is the ability to synthesize existing HDL code and to mitigate
> the requirement for circuit-designers to learn a new language. In
> order to take full advantage of any existing FOSS Verilog or VHDL
> tool, such a tool would have to provide a feature-complete
> implementation of the synthesizable HDL subset."
>
https://github.com/develone/raspberrypi2_yocto/blob/master/doc/yosys_manual.pdf
>
> Regards Edward Vidal
What in the world is this supposed to be in
context to? Is this intended to be part of
the previous thread? Or a post prematurely
sent? What does it have to do with MyHDL?
Regards,
Chris
------------------------------------------------------------------------------
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list
|
|
From: Christopher F. <chr...@gm...> - 2015-08-31 19:54:37
|
On 8/31/2015 2:43 PM, Edward Vidal wrote: > Hello All, > > From the yosys manual: > "The proposed custom HDL synthesis tool should be > licensed under a Free and Open Source Software (FOSS) licence. So an > existing FOSS Verilog or VHDL synthesis tool would have been needed > as basis to build upon. The main advantages of choosing Verilog or > VHDL is the ability to synthesize existing HDL code and to mitigate > the requirement for circuit-designers to learn a new language. In > order to take full advantage of any existing FOSS Verilog or VHDL > tool, such a tool would have to provide a feature-complete > implementation of the synthesizable HDL subset." > https://github.com/develone/raspberrypi2_yocto/blob/master/doc/yosys_manual.pdf > > Regards Edward Vidal What in the world is this supposed to be in context to? Is this intended to be part of the previous thread? Or a post prematurely sent? What does it have to do with MyHDL? Regards, Chris |
|
From: Edward V. <dev...@sb...> - 2015-08-31 19:44:03
|
Hello All,https://github.com/develone/raspberrypi2_yocto/blob/master/doc/yosys_manual.pdfFrom the yosys manual The proposed custom HDL synthesis tool should be licensed under a Free and Open Source Software (FOSS) licence. So an existing FOSS Verilog or VHDL synthesis tool would have been needed as basis to build upon. The main advantages of choosing Verilog or VHDL is the ability to synthesize existing HDL code and to mitigate the requirement for circuit-designers to learn a new language. In order to take full advantage of any existing FOSS Verilog or VHDL tool, such a tool would have to provide a feature-complete implementation of the synthesizable HDL subset. Regards Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 |
|
From: Edward V. <dev...@sb...> - 2015-08-31 18:51:15
|
Chris,I did run this on the a Ubuntu 12.04 on an AMD processor. I get the same results as on the Pi.
Dave is working on Lattice ICE-40 board for the Pi and I wanted to get some tools working on the Pi. So far I have I been able to get GTKWave, Myhdl, Iverilog, vhd2vl, FireFox, Python 2.7 & Python3, XSTOOLs(XuLA2-LX), samba and OpenCV on the Pi. The O/S for the Pi was created with Yocto which creates a custom Linux Distro and the supporting cross compiler.Also a tool which is needed but not running on the Pi is Yosys which is the tool used to generate the bit file for the Lattice ICE-40. This would in turn createa standalone HDL development system at a low cost. Dave indicates the XSTOOLs will not be needed for Lattice ICE-40. The bit file will be downloaded using GPIO instead of the USB. Dave tweeted last week that the board was almost ready. I hope I stated everything correctly.
If you have any questions let me know.
Thanks Edward Vidal Jr. e-mail dev...@sb... 915-595-1613
On Monday, August 31, 2015 12:24 PM, Christopher Felton <chr...@gm...> wrote:
On 8/31/2015 1:07 PM, Edward Vidal wrote:
> Yes,After installing MyHDL and Iverilog on the Raspberry Pi 2 BI did a make in mydhdl/cosimulation/icarus which created the myhdl.vpi for the arm.This was used by both alt.hdl & vhd2vl co-simulation. If you are testing on non arm system this should be replaced by the one created on your system.
> I maybe should have not added it to the github repository.
You might want to try running it on a desktop system
first, that way you can isolate system/OS issues.
Quickly reviewing the code nothing jumps out. My next
step to test it on an x86 desktop linux.
I have to admit, I am a little confused why you are
running the toolflow on the RPi2 - what is the goal?
Regards,
Chris
> Thanks
> Edward Vidal Jr. e-mail dev...@sb... 915-595-1613
>
>
> On Monday, August 31, 2015 11:49 AM, Christopher Felton <chr...@gm...> wrote:
>
>
> <snip>
>>
>> I created the files and folder vcd
>> https://github.com/develone/raspberrypi2_yocto/tree/master/vhd2vl/examples/tb
>>
>> ifchain myhdl.vpi tb_ifchain.v test_ifchain.py vcd
>>
>
> Did you build the myhdl.vpi locally on the machine
> you are running?
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
------------------------------------------------------------------------------
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list
|
|
From: Christopher F. <chr...@gm...> - 2015-08-31 18:21:10
|
On 8/31/2015 1:07 PM, Edward Vidal wrote: > Yes,After installing MyHDL and Iverilog on the Raspberry Pi 2 BI did a make in mydhdl/cosimulation/icarus which created the myhdl.vpi for the arm.This was used by both alt.hdl & vhd2vl co-simulation. If you are testing on non arm system this should be replaced by the one created on your system. > I maybe should have not added it to the github repository. You might want to try running it on a desktop system first, that way you can isolate system/OS issues. Quickly reviewing the code nothing jumps out. My next step to test it on an x86 desktop linux. I have to admit, I am a little confused why you are running the toolflow on the RPi2 - what is the goal? Regards, Chris > Thanks > Edward Vidal Jr. e-mail dev...@sb... 915-595-1613 > > > On Monday, August 31, 2015 11:49 AM, Christopher Felton <chr...@gm...> wrote: > > > <snip> >> >> I created the files and folder vcd >> https://github.com/develone/raspberrypi2_yocto/tree/master/vhd2vl/examples/tb >> >> ifchain myhdl.vpi tb_ifchain.v test_ifchain.py vcd >> > > Did you build the myhdl.vpi locally on the machine > you are running? > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Edward V. <dev...@sb...> - 2015-08-31 18:08:03
|
Yes,After installing MyHDL and Iverilog on the Raspberry Pi 2 BI did a make in mydhdl/cosimulation/icarus which created the myhdl.vpi for the arm.This was used by both alt.hdl & vhd2vl co-simulation. If you are testing on non arm system this should be replaced by the one created on your system.
I maybe should have not added it to the github repository.
Thanks
Edward Vidal Jr. e-mail dev...@sb... 915-595-1613
On Monday, August 31, 2015 11:49 AM, Christopher Felton <chr...@gm...> wrote:
<snip>
>
> I created the files and folder vcd
> https://github.com/develone/raspberrypi2_yocto/tree/master/vhd2vl/examples/tb
>
> ifchain myhdl.vpi tb_ifchain.v test_ifchain.py vcd
>
Did you build the myhdl.vpi locally on the machine
you are running?
Regards,
Chris
------------------------------------------------------------------------------
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list
|
54 messages has been excluded from this view by a project administrator.
