yosyshq / icestorm Goto Github PK
View Code? Open in Web Editor NEWProject IceStorm - Lattice iCE40 FPGAs Bitstream Documentation (Reverse Engineered)
License: ISC License
Project IceStorm - Lattice iCE40 FPGAs Bitstream Documentation (Reverse Engineered)
License: ISC License
The following design should not be place-able on the iCE40-HX1K VQ100
pll.tar.gz
Hi,
Recently i updated my OS from Ubuntu 16.04 to 17.10 and tried to compile icestorm (I'm on the current master HEAD (722790a)).
When i try to compile icestorm i got:
icestorm $ make
for dir in icebox icepack iceprog icemulti icepll icetime icebram; do \
make -C $dir all || exit; \
done
make[1]: Entering directory '/home/d3bug/icestorm/icebox'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/d3bug/icestorm/icebox'
make[1]: Entering directory '/home/d3bug/icestorm/icepack'
make[1]: *** No rule to make target '/usr/include/xlocale.h', needed by 'icepack.o'. Stop.
make[1]: Leaving directory '/home/d3bug/icestorm/icepack'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
So searching a bit i found this release notes for glibc 2.26.
The nonstandard header xlocale.h has been removed in this release.
To know the version of glibc on my box i used:
$ ldd --version
ldd (Ubuntu GLIBC 2.26-0ubuntu2.1) 2.26
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
So that why i can't compile icestorm nor arachne (i got the same error output). I tried searching xlocale on the icepack source but i couldn't find it (i haven't searched deeply tho).
I know this is not directly a icestorm problem but i wanted to ask for suggestions to solve it, i have found this workaround tho.
Can this be solved directly on icestorm/arachne or should i find a way to downgrade glibc?
Regards.
There is no python2 installed on OSX. I created a link on my own machine, but that's not possible for people without admin rights (e.g. running on travis-ci).
When attempting to generate a timing report for any given global clock net names (verified to exist in the corresponding arachne-pnr output) icetime always returns:
icetime -m -d hx8k -p test.pcf -P ct256 -T secondary_clock test.int
// Reading input .pcf file..
// Reading input .asc file..
// Reading 8k chipdb file..
// Creating timing netlist..
icetime topological timing analysis report
==========================================
Info: max_span_hack is enabled: estimate is conservative.
Report for secondary_clock:
--------------------------------------
Net not found: secondary_clock
Yet the symbol exists:
.sym 6 secondary_clock
Is this a bug? There is next to no documentation on icetime for anything other than generating an absolute worst case timing estimate for the entire design.
Thanks!
Ignore this comment!
For icebram to work as a drop-in replacement for incuding the hexfiles directly with $readmemh, it should accept the same hexfile syntax. The differences I have found:
Hi
When running make -j$(nproc)
I get:
make -C icebox
make[1]: Entering directory '/home/habiloid/icestorm/icebox'
python icebox_chipdb.py > chipdb-1k.new
python icebox_chipdb.py -8 > chipdb-8k.new
Traceback (most recent call last):
File "icebox_chipdb.py", line 250, in
print_tile_nonrouting_bits("logic", ic.logic_tiles.keys()[0])
TypeError: 'dict_keys' object does not support indexing
Makefile:6: recipe for target 'chipdb-1k.txt' failed
make[1]: *** [chipdb-1k.txt] Error 1
make[1]: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "icebox_chipdb.py", line 250, in
print_tile_nonrouting_bits("logic", ic.logic_tiles.keys()[0])
TypeError: 'dict_keys' object does not support indexing
Makefile:10: recipe for target 'chipdb-8k.txt' failed
make[1]: *** [chipdb-8k.txt] Error 1
make[1]: Leaving directory '/home/brett/BUILDS/COMPILATIONS/icestorm/icebox'
Makefile:3: recipe for target 'all' failed
make: *** [all] Error 2
Any help would be appreciated
Ta
When icepll
is used to generate a PLL for an input frequency of 12MHz and an output of 25MHz, it gives this output:
F_PLLIN: 12.000 MHz (given)
F_PLLOUT: 25.000 MHz (requested)
F_PLLOUT: 24.000 MHz (achieved)
FEEDBACK: SIMPLE
F_PFD: 12.000 MHz
F_VCO: 768.000 MHz
DIVR: 0 (4'b0000)
DIVF: 63 (7'b0111111)
DIVQ: 5 (3'b101)
FILTER_RANGE: 1 (3'b001)
However, when iCEcube2 is given the same parameters, it generates a PLL with these parameters:
DivR: 0000 (0)
DivF: 1000010 (66)
DivQ: 101 (5)
Output frequency: 25.13MHz
It seems that iCEcube2 sets DIVF outside its documented range of [0,63], and gives a PLL configuration that more closely matches the frequency requested. Could the DIVF range given in the datasheet simply be a mistake?
I can't verify this at the moment as I don't have an oscilloscope.
Using attached bitstream, fpga-icestorm 0~20160218gitf2b2549-
from Debian and running icetime -d hx8k -p board/iCE40HX8K-B-EVM.pcf -P ct256 test.txt
.
test.txt
This would be handy; as a workaround I'm just supplying a stripped .pcf to icebox_vlog vs arachne-pnr.
On Fedora 23, iceprog cannot be built because it requires additional linker and compiler flags for libftdi. I tried to fix this, but it seems like different GNU/Linux distributions have different library names for pkg-config. I'm not quite sure how to process this in makefile.
Fedora 23:
[user@fedora]$ pkg-config --libs --cflags libftdi1
-I/usr/include/libftdi1 -I/usr/include/libusb-1.0 -lftdi1 -lusb-1.0
Ubuntu 12.04:
user@ubuntu:~$ pkg-config --libs --cflags libftdi
-lftdi
As a side note, maybe it would be more convenient to have a more flexible build system, like cmake, autotools or premake? With premake, for example, it would be easier to provide configurations for variety of compilers for different platforms. Here is a quick example for icestorm.
The syntax of the .comment
statement expected by IceStorm does not appear to match the syntax output by arachne-pnr
.
icepack
expects comments to be in the following syntax:
.comment
First line
Second line
Everything following .comment
on the first line is ignored. Each subsequent line is treated as a comment until the comment block is terminated by a line starting with .
. This line is treated normally; it is not ignored. If multiple comment blocks are specified, all except the last one are ignored.
icepack
includes the comments in the following form at the beginning of the .bin
output:
ff 00 <First line> 00 <Second line> 00 00 ff
However, arachne-pnr
outputs a comment of the following form:
.comment arachne-pnr <version> (git sha1 <commit>, <compiler version and options>)
This is understood by icepack
as an empty comment block, so it adds the pattern
ff 00 00 ff
at the beginning of every .bin
file generated from arachne-pnr
output.
I stumbled across this when I realized that icepack
actually interprets .comment
statement. I'm not sure what the correct behavior is supposed to be, but I guess it's one of the following:
.comment
blocks are intended as a mechanism to include arbitrary strings in a .bin
file, but arachne-pnr
got the format wrong, so instead of the version string, an empty comment block is included in the output.comment
blocks are intended as a mechanism to include arbitrary strings in a .bin
file, but arachne-pnr
mistook the syntax for a βrealβ comment and inadvertently inserts an empty comment block in every file.comment
statements are intended as a way to be able to add comments to an .asc
file; icepack
is not supposed to include their content in the outputThis is fine:
# D9
set_io led[0] B5
This breaks (but is accepted by arachne-pnr):
set_io led[0] B5 # D9
Clifford,
Has LVDS out been tested**?
code sample: lvds.txt
simple LVDS code builds with no errors reported:
using iCEcube2 runs as expected
Total number of logic levels: 12
Total path delay: 14.37 ns (69.58 MHz)
on iCEstorm does not run as expected
Total number of logic levels: 22
Total path delay: 23.95 ns (41.76 MHz)
**I only found reference to LVDS in:
http://www.clifford.at/icestorm/io_tile.html
I think it would be useful to allow loading icebox data path during runtime. The binary would be a more flexible binary.
When icepll saves PLL configuration as a module, it includes a comma after the last port in the port list.
Yosys synthesizes it with no problems, but Icarus Verilog considers the extra comma a syntax error.
Would it be better to remove the comma after .PLLOUTCORE(clock_out)
?
$ icepll -m -f pll.v
F_PLLIN: 12.000 MHz (given)
F_PLLOUT: 60.000 MHz (requested)
F_PLLOUT: 67.500 MHz (achieved)
FEEDBACK: SIMPLE
F_PFD: 12.000 MHz
F_VCO: 540.000 MHz
DIVR: 0 (4'b0000)
DIVF: 44 (7'b0101100)
DIVQ: 3 (3'b011)
FILTER_RANGE: 1 (3'b001)
PLL configuration written to: pll.v
pll.v
/**
* PLL configuration
*
* This Verilog module was generated automatically
* using the icepll tool from the IceStorm project.
* Use at your own risk.
*
* Given input frequency: 12.000 MHz
* Requested output frequency: 60.000 MHz
* Achieved output frequency: 67.500 MHz
*/
module pll(
input clock_in,
output clock_out,
output locked
);
SB_PLL40_CORE #(
.FEEDBACK_PATH("SIMPLE"),
.DIVR(4'b0000), // DIVR = 0
.DIVF(7'b0101100), // DIVF = 44
.DIVQ(3'b011), // DIVQ = 3
.FILTER_RANGE(3'b001) // FILTER_RANGE = 1
) uut (
.LOCK(locked),
.RESETB(1'b1),
.BYPASS(1'b0),
.REFERENCECLK(clock_in),
.PLLOUTCORE(clock_out),
);
endmodule
$ iverilog -t null pll.v /usr/local/share/yosys/ice40/cells_sim.v
pll.v:31: syntax error
pll.v:25: error: Syntax error in instance port expression(s).
I'm getting the following error:
Traceback (most recent call last):
File "/usr/local/bin/icebox_vlog", line 344, in <module>
for s in sorted(net_segs):
TypeError: unorderable types: str() < tuple()
The offending input is here: https://gist.github.com/cseed/7c648bd527f00fd40be1. Just run icebox_vlog carry_route_fail1.txt
.
Some important information in timing report present in textual format and absent in JSON.
$auto$alumacc.cc:470:replace_alu$9.C[3]
text:
lc40_1_2_1 (LogicCell40) carryin -> carryout: 0.126 ns
1.987 ns net_4014 ($auto$alumacc.cc:470:replace_alu$9.C[2])
lc40_1_2_2 (LogicCell40) carryin -> carryout: 0.126 ns
2.113 ns net_4020 ($auto$alumacc.cc:470:replace_alu$9.C[3])
json:
{ out_net: "net_4014", cell: "lc40_1_2_1", cell_type: "LogicCell40", cell_in_port: "carryin", cell_out_port: "carryout", delay_ns: 1.987, },
{ out_net: "net_4020", cell: "lc40_1_2_2", cell_type: "LogicCell40", cell_in_port: "carryin", cell_out_port: "carryout", delay_ns: 2.113, },
I currently provide automated nightly builds of the icestorm toolchain, and I am finally getting around to upstreaming the horrible ugly build system hacks that I've been using. I noticed that icestorm has a special mxebin
makefile target that is used to create a Windows package. Is there a particular reason why the normal install
target cannot be fixed to work? Would you accept a patch that fixes install
for cross-building Windows packages?
On the icestorm official web page :
http://www.clifford.at/icestorm/
It's written that we can break our icestick with this project. Have you ever break an icestick or it's just a warning ?
Thanks
From Project Icestorm homepage:
Notes for Linux: Create a file /etc/udev/rules.d/53-lattice-ftdi.rules with the following line in it to allow uploading bit-streams to a Lattice iCEstick and/or a Lattice iCE40-HX8K Breakout Board as unprivileged user:
ACTION=="add", ATTR{idVendor}=="0403", ATTR{idProduct}=="6010", MODE:="666"
This did not work for me on Debian9. Other tries like setting the device node's ownership/permissions right for my account failed too.
After digging a while, I found Debian's fpga-icestorm_*.deb
includes this UDEV rule:
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"
This one worked here and now I can drop sudo
for loading the FPGA.
When following the build instructions (copy+pasted the apt-get), it seems libftdi1-dev is missing:
make[1]: Entering directory '/space/home_laforge/projects/git/icestorm/iceprog'
cc -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -I/usr/local/include -c -o iceprog.o iceprog.c
iceprog.c: In function βmainβ:
iceprog.c:387:13: error: βINTERFACE_Cβ undeclared (first use in this function); did you mean βINTERFACE_Bβ?
ifnum = INTERFACE_C;
^~~~~~~~~~~
INTERFACE_B
iceprog.c:387:13: note: each undeclared identifier is reported only once for each function it appears in
iceprog.c:389:13: error: βINTERFACE_Dβ undeclared (first use in this function); did you mean βINTERFACE_Cβ?
ifnum = INTERFACE_D;
^~~~~~~~~~~
INTERFACE_C
iceprog.c:589:7: warning: implicit declaration of function βftdi_usb_open_stringβ; did you mean βftdi_usb_get_stringsβ? [-Wimplicit-function-declaration]
if (ftdi_usb_open_string(&ftdic, devstr)) {
^~~~~~~~~~~~~~~~~~~~
ftdi_usb_get_strings
<builtin>: recipe for target 'iceprog.o' failed
make[1]: *** [iceprog.o] Error 1
make[1]: Leaving directory '/space/home_laforge/projects/git/icestorm/iceprog'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
After installing the relted package, the build went through successful.
I tried with rgb example here ...
https://github.com/cliffordwolf/icestorm/tree/master/examples/up5k_rgb
I used the same connections as a working setup with Lattice Diamond programmer, FTDI2232H (channel A).
I get no errors on "sudo make prog" after successful "make", but fpga don't get programmed.
I can see ft2232 pins "talk" to fpga board when i type "sudo make prog" with a logic analyzer but I have no experience with SPI or jtag to go further.
Someone has a working setup with RGB example trough "Makefile" and "make prog" con FTDI2232?
THanks
...
make -C iceprog
make[1]: Entering directory '/home/drom/work/github/cliffordwolf/icestorm/iceprog'
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -c -o iceprog.o iceprog.c
iceprog.c:27:10: fatal error: 'ftdi.h' file not found
#include <ftdi.h>
^
1 error generated.
<builtin>: recipe for target 'iceprog.o' failed
make[1]: *** [iceprog.o] Error 1
make[1]: Leaving directory '/home/drom/work/github/cliffordwolf/icestorm/iceprog'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2
Below Verilog does not work (only 2 leds come on), but is fixed when I uncomment the unused wire 'idle' in module debounce. I may be missing something obvious of course...
module button(input clk, input [1:0] buttons, output [3:0] led);
assign led = leds;
reg [3:0] leds = 4'b0;
wire on;
wire off;
wire pressed;
debounce dbon(.clk(clk),.button(buttons[0]),.state(on));
debounce dboff(.clk(clk),.button(buttons[1]),.state(off));
assign pressed = on | off;
always @(posedge pressed)
leds <= (on) ? 4'b1111 :
(off) ? 4'b0000 : leds;
endmodule
module debounce(input clk, input button, output reg state);
//wire idle;
reg sync;
reg [15:0] count;
always @(posedge clk) begin
sync <= ~button;
count <= (state == sync) ? 0 : count + 16'b1;
if(&count)
state <= ~state;
end
endmodule
IceStorm vers:
Yosys 0.5+460 (git sha1 45af4a4, clang 3.4-1ubuntu3 -fPIC -Os)
arachne-pnr 0.1+136+0 (git sha1 1a4fdf9, g++ 4.8.4-2ubuntu1~14.04.1 -O2)
I got a new Icestick to start experimenting with verilog. The normal programming works fine, but programming it with
iceprog -S file.bin
does not work. The leds on the stick then go into the half-on state and nothing else happens. Also it prints cdone: low
at the end.
Attached is a wireshark usb capture, if that helps.
program_iceprog_sram.zip
Is there a special reason not to remove $(PROJ).rpt
in icestorm/examples/iceblink
?
icestorm/examples$ grep -A1 -B0 clean: */Makefile
hx8kboard/Makefile:clean:
hx8kboard/Makefile- rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
--
iceblink/Makefile:clean:
iceblink/Makefile- rm -f $(PROJ).blif $(PROJ).asc $(PROJ).bin
--
icestick/Makefile:clean:
icestick/Makefile- rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
--
icezum/Makefile:clean:
icezum/Makefile- rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
Hi, Is there a plan to unify the chipdb binary files between Icestorm and Arachne-pnr?
Now there is a share/icebox directory with the chipdbs*.txt (about ~44Mb) and other share/arachne-pnr directory with the same information chipdb*.bin (about ~12Mb) for the same toolchain.
Do you plan to generate those chipdb*.bin from the icebox tools and read those chipdb*.bin files in the icetime tool?
Thanks!
Hi,
At least on Cygwin vasprintf declarations in stdio.h are protected by _GNU_SOURCE so this needs to be added in appropriate places. Attached patch adds the definition it in relevant source files, similar to what's already done for iceprog.cc.
0001-Explicitly-ask-for-vasprintf-where-appropriate.patch.txt
At the risk of inciting a huge flamewar, I would like to request that the newly-added high-level configuration tool be licensed under a non-copyleft license rather than the copyleft GPLv3+. The rest of the IceStorm project is under the ISC license.
When running this https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version with icestorm (the latest) and IceCube2 I get two quite different results:
Hello,
The make fails with:
[Geoffreys-MacBook-Pro-2:fpga/tools/icestorm] geoffc% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C icebox
make[1]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icepack make[1]: Nothing to be done for
all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C iceprog
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -c -o iceprog.o iceprog.c
In file included from iceprog.c:27:
/usr/local/include/ftdi.h:20:10: fatal error: 'usb.h' file not found
^
1 error generated.
make[1]: *** [iceprog.o] Error 1
make: *** [all] Error 2
I'm not sure which package I might need to supply the usb.h file. Has anyone else run across this one?
Thanks.
Geoff
cc @rlutz
I just tried running icebox_asc2hlc.py and icebox_hlc2asc.py on a "real" design, and icebox_hlc2asc.py fails to round-trip the design. It instead raises a ParseError:
Traceback (most recent call last):
File "./icebox/icebox_hlc2asc.py", line 1052, in <module>
main()
File "./icebox/icebox_hlc2asc.py", line 1049, in main
main1(args[0])
File "./icebox/icebox_hlc2asc.py", line 985, in main1
stack[-1].read(fields)
File "./icebox/icebox_hlc2asc.py", line 882, in read
super().read(fields)
File "./icebox/icebox_hlc2asc.py", line 754, in read
raise ParseError
__main__.ParseError
The high-level bitstream file is here. Let me know if you would like me to try to minimize it.
Hi Clifford,
I just pulled revision af36a8a and I got compiler errors that are possibly related to gcc version 6.1:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC)
I'm using Arch Linux and I have the latest packages for everything. The output I get:
make -C icebox
make[1]: Entering directory '/home/aaa/Software/icestorm/icebox'
python3 icebox_chipdb.py > chipdb-1k.new
mv chipdb-1k.new chipdb-1k.txt
python3 icebox_chipdb.py -8 > chipdb-8k.new
mv chipdb-8k.new chipdb-8k.txt
make[1]: Leaving directory '/home/aaa/Software/icestorm/icebox'
make -C icepack
make[1]: Entering directory '/home/aaa/Software/icestorm/icepack'
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include -c -o icepack.o icepack.cc
clang -o icepack icepack.o -lm -lstdc++
ln -sf icepack iceunpack
make[1]: Leaving directory '/home/aaa/Software/icestorm/icepack'
make -C iceprog
make[1]: Entering directory '/home/aaa/Software/icestorm/iceprog'
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -c -o iceprog.o iceprog.c
clang -o iceprog iceprog.o -L/usr/local/lib -lm -lftdi -lusb
make[1]: Leaving directory '/home/aaa/Software/icestorm/iceprog'
make -C icemulti
make[1]: Entering directory '/home/aaa/Software/icestorm/icemulti'
clang -MD -O0 -ggdb -Wall -std=c++11 -c -o icemulti.o icemulti.cc
clang -o icemulti icemulti.o -lm -lstdc++
make[1]: Leaving directory '/home/aaa/Software/icestorm/icemulti'
make -C icepll
make[1]: Entering directory '/home/aaa/Software/icestorm/icepll'
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include -c -o icepll.o icepll.cc
clang -o icepll icepll.o -lm -lstdc++
make[1]: Leaving directory '/home/aaa/Software/icestorm/icepll'
make -C icetime
make[1]: Entering directory '/home/aaa/Software/icestorm/icetime'
python3 timings.py > timings.inc.new
mv timings.inc.new timings.inc
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include -DPREFIX='"/usr/local"' -c -o icetime.o icetime.cc
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:471:67: error:
pack expansion contains parameter packs '_Elements' and '_UElements' that
have different lengths (1 vs. 3)
return __and_<is_constructible<_Elements, const _UElements&>...>::value;
~~~~~~~~~ ~~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:645:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, int> &>::_ConstructibleTuple<int, int, int>'
requested here
_ConstructibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, int>, _Dummy = void]
constexpr tuple(const tuple<_UElements...>& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
(no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:339:11: note: in instantiation of member function
'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
>::operator[]' requested here
pin_pos[key] = tok;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:477:65: error:
pack expansion contains parameter packs '_UElements' and '_Elements' that
have different lengths (3 vs. 1)
return __and_<is_convertible<const _UElements&, _Elements>...>::value;
~~~~~~~~~~ ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:647:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, int> &>::_ImplicitlyConvertibleTuple<int, int, int>'
requested here
_ImplicitlyConvertibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, int>, _Dummy = void]
constexpr tuple(const tuple<_UElements...>& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
(no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:339:11: note: in instantiation of member function
'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
>::operator[]' requested here
pin_pos[key] = tok;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:483:62: error:
pack expansion contains parameter packs '_Elements' and '_UElements' that
have different lengths (1 vs. 3)
return __and_<is_constructible<_Elements, _UElements&&>...>::value;
~~~~~~~~~ ~~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:669:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, int> &>::_MoveConstructibleTuple<int, int, int>'
requested here
_MoveConstructibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, int>, _Dummy = void]
constexpr tuple(tuple<_UElements...>&& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
(no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:339:11: note: in instantiation of member function
'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
>::operator[]' requested here
pin_pos[key] = tok;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:489:60: error:
pack expansion contains parameter packs '_UElements' and '_Elements' that
have different lengths (3 vs. 1)
return __and_<is_convertible<_UElements&&, _Elements>...>::value;
~~~~~~~~~~ ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:671:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, int> &>::_ImplicitlyMoveConvertibleTuple<int, int,
int>' requested here
_ImplicitlyMoveConvertibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, int>, _Dummy = void]
constexpr tuple(tuple<_UElements...>&& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
(no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:339:11: note: in instantiation of member function
'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
>::operator[]' requested here
pin_pos[key] = tok;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:471:67: error:
pack expansion contains parameter packs '_Elements' and '_UElements' that
have different lengths (1 vs. 3)
return __and_<is_constructible<_Elements, const _UElements&>...>::value;
~~~~~~~~~ ~~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:645:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, std::__cxx11::basic_string<char> >
&>::_ConstructibleTuple<int, int, std::__cxx11::basic_string<char> >'
requested here
_ConstructibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = void]
constexpr tuple(const tuple<_UElements...>& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = (no value), $2 = (no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:450:15: note: in instantiation of member function
'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
std::allocator<std::pair<const std::tuple<int, int,
std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
x_y_name_net[key] = seg.net;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:477:65: error:
pack expansion contains parameter packs '_UElements' and '_Elements' that
have different lengths (3 vs. 1)
return __and_<is_convertible<const _UElements&, _Elements>...>::value;
~~~~~~~~~~ ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:647:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, std::__cxx11::basic_string<char> >
&>::_ImplicitlyConvertibleTuple<int, int, std::__cxx11::basic_string<char>
>' requested here
_ImplicitlyConvertibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = void]
constexpr tuple(const tuple<_UElements...>& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = (no value), $2 = (no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:450:15: note: in instantiation of member function
'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
std::allocator<std::pair<const std::tuple<int, int,
std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
x_y_name_net[key] = seg.net;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:483:62: error:
pack expansion contains parameter packs '_Elements' and '_UElements' that
have different lengths (1 vs. 3)
return __and_<is_constructible<_Elements, _UElements&&>...>::value;
~~~~~~~~~ ~~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:669:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, std::__cxx11::basic_string<char> >
&>::_MoveConstructibleTuple<int, int, std::__cxx11::basic_string<char> >'
requested here
_MoveConstructibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = void]
constexpr tuple(tuple<_UElements...>&& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = (no value), $2 = (no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:450:15: note: in instantiation of member function
'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
std::allocator<std::pair<const std::tuple<int, int,
std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
x_y_name_net[key] = seg.net;
^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:489:60: error:
pack expansion contains parameter packs '_UElements' and '_Elements' that
have different lengths (3 vs. 1)
return __and_<is_convertible<_UElements&&, _Elements>...>::value;
~~~~~~~~~~ ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:671:21: note:
in instantiation of function template specialization 'std::_TC<true, const
std::tuple<int, int, std::__cxx11::basic_string<char> >
&>::_ImplicitlyMoveConvertibleTuple<int, int,
std::__cxx11::basic_string<char> >' requested here
_ImplicitlyMoveConvertibleTuple<_UElements...>()
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note:
while substituting prior template arguments into non-type template
parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = void]
constexpr tuple(tuple<_UElements...>&& __in)
^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note:
while substituting deduced template arguments into function template
'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
_Dummy = (no value), $2 = (no value)]
std::tuple<const key_type&>(__k),
^
icetime.cc:450:15: note: in instantiation of member function
'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
std::allocator<std::pair<const std::tuple<int, int,
std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
x_y_name_net[key] = seg.net;
^
8 errors generated.
<builtin>: recipe for target 'icetime.o' failed
make[1]: *** [icetime.o] Error 1
make[1]: Leaving directory '/home/aaa/Software/icestorm/icetime'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2
This repros on an ICE40-HX8K breakout board using Icestorm tools built from head as of a week or so ago. The board is in "sram" mode, and I'm flashing it using "iceprog -S ..."
To repro -
module placeholder(input clk_in, output reg [7:0] out_debug, output reg out_trap);
assign out_debug = 8'b10101010;
endmodule
module blockram_bug(input clk, output reg [7:0] out_debug);
reg [31:0] memory[0:127];
initial begin
memory[0] = 32'hFFFFFFFF;
memory[1] = 32'hFFFFFFFF;
memory[2] = 32'hFFFFFFFF;
memory[3] = 32'hFFFFFFFF;
memory[4] = 32'hFFFFFFFF;
memory[5] = 32'hFFFFFFFF;
memory[6] = 32'hFFFFFFFF;
memory[7] = 32'hFFFFFFFF;
end
reg [25:0] count = 0;
reg [31:0] mem_raddr = 32'hFFFFFFFF;
always @(posedge clk) begin
if (count == 0) begin
mem_raddr <= 7;
out_debug <= 32'hFFFFFFFF;
end
if (count == 36) begin
out_debug <= memory[mem_raddr];
end
count <= count + 1;
end
endmodule
If the bug does not repro, the LEDs will light up immediately. If the bug does repro, the LEDs should be off for ~5 seconds until the counter rolls over, then they should light up. Changing the "if (count == 36)" to 37 or higher will cause the bug to not repro.
Flash the board a second time with the same .bin from step 2. The bug should not repro (LEDs light up immediately).
Flash the board with the placeholder again, then flash with blockram_bug. The bug should repro again.
Hi. I found a strange thing running icetime.
If a logic tile with Y=1 has C_ON set for LC_0 (which my design has for some reason, don't know if this is normal), icetime will call make_lc40() with Y=0. But Y=0 is not a logic tile, it's an IO tile. So trying to interpret the config bits as a logic tile will probably produce garbage. Under some circumstances it even proceeds to Y=-1 and crashes.
As I said, no idea if C_ON for a logic cell in this position is normal, but the design was generated with yosys 0.6 and latest arachne-pnr, and does not contain any hand-rolled logic cells...
Very good feature π
But about File format. There are couple of issues to make it JSON
Now:
[
{ out_net: "net_8353", cell: "lc40_3_2_4", cell_type: "LogicCell40", cell_in_port: "[clk]", cell_out_port: "lcout", delay_ns: 0.640, },
{ out_net: "net_252", cell: "odrv_3_2_8353_252", cell_type: "Odrv4", cell_in_port: "I", cell_out_port: "O", delay_ns: 1.012, },
]
Should be:
[
{ "out_net": "net_8353", "cell": "lc40_3_2_4", "cell_type": "LogicCell40", "cell_in_port": "[clk]", "cell_out_port": "lcout", "delay_ns": 0.640 },
{ "out_net": "net_252", "cell": "odrv_3_2_8353_252", "cell_type": "Odrv4", "cell_in_port": "I", "cell_out_port": "O", "delay_ns": 1.012 }
]
I have tested in three different laptops. What I got is:
$ time sudo iceprog scicad1.bin
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x12 0x67 0x21 0x23 0x00 0x21 0x00 0x43 0x04 0x11 0x11 0x5F 0x7D
file size: 32220
erase 64kB sector at 0x000000..
programming..
reading..
VERIFY OK
cdone: high
Bye.
real 0m33.554s
user 0m0.016s
sys 0m0.056s
It takes 33 seconds to perform the programming. But in other computers it just takes 3 seconds.
I made one test in two laptops with ubuntu 15.10. Same kernel, same linux distro. Laptop A took 30 seconds and Laptop B only 3sec
Laptop A: High-end laptop: i7, 8GB RAM
Laptop B: Low-end laptop: intel core duo, 4GB RAM (five years old)
Any help or suggestions on test to perform are welcome
While building this (yesterday's pull and reinstall of the icestorm/arachne/yosys)
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version
I get an arachne-pnr dump
After placement:
PIOs 21 / 39
PLBs 541 / 660
BRAMs 30 / 30
place time 22.68s
route...
36 -> 77837 75389 76613 26219 77633 75593 28667 28463 78041 76205 77021 27647 77225 75797 28871 28055 78241 76409 76817 27851 77429 76001 29071 28259 26423 26627 26831 27035 27239 27443 78429
arachne-pnr: src/route.cc:793: void Router::route(): Assertion `unrouted.empty()' failed.
Aborted (core dumped)
Not sure it comes from the design itself or from the experimental UP5k..
Does the 10000XX.XX indicate a design issue here (yesterday's icestorm/arachne/yosys pull from github and reinstall), chip ice40UP5k?
Sources: https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version
icetime topological timing analysis report
==========================================
Report for critical path:
-------------------------
loop-start at net_34778
t7262 (LocalMux) I -> O: 0.330 ns
inmux_9_15_38650_38720 (InMux) I -> O: 0.260 ns
t1267 (CascadeMux) I -> O: 0.000 ns
lc40_9_15_7 (LogicCell40) in2 -> lcout: 0.379 ns
1000000.968 ns net_34778 (_j1.insn_from_memory[13])
odrv_9_15_34778_38506 (Odrv4) I -> O: 0.372 ns
t7288 (LocalMux) I -> O: 0.330 ns
inmux_10_14_42377_42392 (InMux) I -> O: 0.260 ns
t1388 (CascadeMux) I -> O: 0.000 ns
lc40_10_14_1 (LogicCell40) in2 -> lcout: 0.379 ns
1000002.307 ns net_38480 ($abc$26981$n3234_1)
odrv_10_14_38480_42090 (Odrv4) I -> O: 0.372 ns
t8348 (Span4Mux_h4) I -> O: 0.316 ns
t8347 (Span4Mux_h4) I -> O: 0.316 ns
t8346 (Span4Mux_h1) I -> O: 0.175 ns
t8345 (LocalMux) I -> O: 0.330 ns
inmux_20_14_80032_80082 (InMux) I -> O: 0.260 ns
lc40_20_14_3 (LogicCell40) in3 -> lcout: 0.316 ns
1000004.390 ns net_76486 ($abc$26981$n3939_1)
odrv_20_14_76486_53935 (Odrv12) I -> O: 0.540 ns
t15878 (Span12Mux_h2) I -> O: 0.168 ns
t15877 (LocalMux) I -> O: 0.330 ns
inmux_11_14_46195_46251 (InMux) I -> O: 0.260 ns
lc40_11_14_6 (LogicCell40) in0 -> lcout: 0.449 ns
1000006.137 ns net_42316 ($abc$26981$n3938_1)
t8921 (LocalMux) I -> O: 0.330 ns
inmux_11_13_46065_46106 (InMux) I -> O: 0.260 ns
t1542 (CascadeMux) I -> O: 0.000 ns
lc40_11_13_2 (LogicCell40) in2 -> lcout: 0.379 ns
1000007.105 ns net_42189 ($abc$26981$n3937_1)
odrv_11_13_42189_45906 (Odrv12) I -> O: 0.540 ns
t8884 (Span12Mux_h4) I -> O: 0.217 ns
t8883 (Sp12to4) I -> O: 0.449 ns
t8882 (Span4Mux_v0) I -> O: 0.203 ns
t8881 (Span4Mux_h0) I -> O: 0.147 ns
t8880 (Span4Mux_v1) I -> O: 0.203 ns
t8879 (LocalMux) I -> O: 0.330 ns
inmux_9_12_38294_38319 (InMux) I -> O: 0.260 ns
lc40_9_12_2 (LogicCell40) in0 -> lcout: 0.449 ns
1000009.903 ns net_34404 (_j1.pcN[1])
odrv_9_12_34404_34311 (Odrv4) I -> O: 0.372 ns
t7065 (Span4Mux_v4) I -> O: 0.372 ns
t7064 (Span4Mux_h4) I -> O: 0.316 ns
t7063 (Span4Mux_v4) I -> O: 0.372 ns
t7082 (Span4Mux_h4) I -> O: 0.316 ns
t7081 (Span4Mux_h4) I -> O: 0.316 ns
t7080 (Span4Mux_h4) I -> O: 0.316 ns
t7108 (Span4Mux_h0) I -> O: 0.147 ns
t7107 (Span4Mux_v4) I -> O: 0.372 ns
t7106 (Span4Mux_h0) I -> O: 0.147 ns
t7105 (Span4Mux_v4) I -> O: 0.372 ns
t7104 (Span4Mux_h0) I -> O: 0.147 ns
t7103 (Span4Mux_v4) I -> O: 0.372 ns
t7102 (Span4Mux_h4) I -> O: 0.316 ns
t7101 (Span4Mux_v4) I -> O: 0.372 ns
t7100 (Span4Mux_v4) I -> O: 0.372 ns
t7099 (Span4Mux_v4) I -> O: 0.372 ns
t7098 (Span4Mux_h4) I -> O: 0.316 ns
t7097 (Span4Mux_v4) I -> O: 0.372 ns
t7096 (Span4Mux_v2) I -> O: 0.252 ns
t7095 (IoSpan4Mux) I -> O: 0.323 ns
t7094 (Span4Mux_h0) I -> O: 0.147 ns
t7093 (Span4Mux_v4) I -> O: 0.372 ns
t7092 (Span4Mux_v4) I -> O: 0.372 ns
t7091 (Span4Mux_v4) I -> O: 0.372 ns
t7090 (Span4Mux_h0) I -> O: 0.147 ns
t7089 (Span4Mux_v4) I -> O: 0.372 ns
t7088 (Span4Mux_h0) I -> O: 0.147 ns
t7087 (Span4Mux_v4) I -> O: 0.372 ns
t7086 (Span4Mux_h0) I -> O: 0.147 ns
t7085 (Span4Mux_v4) I -> O: 0.372 ns
t7084 (Span4Mux_h2) I -> O: 0.203 ns
t7083 (LocalMux) I -> O: 0.330 ns
inmux_19_3_75447_75480 (InMux) I -> O: 0.260 ns
t2677 (CascadeMux) I -> O: 0.000 ns
1000020.143 ns net_75480_cascademuxed
ram_19_3 (SB_RAM40_4K) RADDR[1] [setup]: 0.290 ns
1000020.433 ns dangling_wire_513
Resolvable net names on path:
1000000.968 ns ..1000001.929 ns _j1.insn_from_memory[13]
1000002.307 ns ..1000004.075 ns $abc$26981$n3234_1
1000004.390 ns ..1000005.688 ns $abc$26981$n3939_1
1000006.137 ns ..1000006.726 ns $abc$26981$n3938_1
1000007.105 ns ..1000009.454 ns $abc$26981$n3937_1
1000009.903 ns ..1000020.143 ns _j1.pcN[1]
RDATA[11] -> _bn20.rd[11]
RDATA[3] -> _bn20.rd[3]
Total number of logic levels: 7
Total path delay: 1000020.43 ns (0.00 MHz)
As we discussed on the twitter: https://twitter.com/oe1cxw/status/821646243101372417 it would be nice to have support for the latest / greatest FPGAs. Created this ticket to scope the work need to be done:
Hi Clifford,
For Fedora 24, the following pre-requisites line should be suitable:
sudo dnf install make automake gcc gcc-c++ kernel-devel clang bison \
flex readline-devel gawk tcl-devel libffi-devel git mercurial \
graphviz python-xdot pkgconfig python python3 libftdi-devel
Hi, first off, I want to congratulate your release of Icetime.
Minor issue;
On Arch Linux, and other systems that don't use /usr/local,
this is broken
https://github.com/cliffordwolf/icestorm/blob/master/icetime/icetime.cc#L268
Hi
I just tried running icepll like this:
icepll -i 12 -o 200
to get a 200MHz (ish) output from a 12MHz xtal on the icestick
and got the following output:
F_PLLIN: 12.000 MHz (given)
F_PLLOUT: 200.000 MHz (requested)
F_PLLOUT: 201.000 MHz (achieved)
FEEDBACK: SIMPLE
F_PFD: 12.000 MHz
F_VCO: 804.000 MHz
DIVR: 0 (4'b0000)
DIVF: 66 (7'b1000010)
DIVQ: 2 (3'b010)
FILTER_RANGE: 1 (3'b001)
The value of 66 for DIVF is out of range (data sheets say 0..63) - I tried it on the Icestick (to check I am not going mad) and indeed it produces the equivalent of it wrapping around to 2, as expected.
I think the issue is at line 101 in the code:
for (int divf = 0; divf <= 127; divf++)
Which should probably be:
for (int divf = 0; divf <= 63; divf++)
Unless, of course, I am misunderstanding something (I am new to lattice ICE parts and icestorm).
PS: Thanks for all your work on this. It's a completely awesome project and a fantastic achievement. I am really enjoying working with open source tools on an FPGA. Is there any way to help with / donate to the project?
James.
clifford, would the icestorm wiki be the place to link to tutorials (like mine ~:")
I find it to be beyond my immediate capabilities to figure out how to communicate with the HX1K via USB. I can follow the instructions on https://wiki.debian.org/FPGA/Lattice, can modify that code, all fine. I have a USB-TTL converter and could imagine to use that to communicate with the device via some extra cables, basically along the examples for the IrDA. But if somehow possible I would want to use the USB port that the device is using already.
Does anybody reading this have any respective code (host and fpga) available? Maybe something along the "echo" example at ztex (http://www.ztex.de/firmware-kit/example.e.html)?
Many thanks
Steffen
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.