With arachne-pnr this circuit couldn't hit 60MHz, just barely under it.
OTOH, nextpnr hits about ~68 MHz. So let's set it somewhere inbetween to
make sure this is true over time!
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes it easier to build separate bitstreams for simulation targets
vs the real bitstream for hardware, without editing any source code.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This dumps a simple IceTime report for the bitstream; we fix the device
package to CT256, corresponding to the HX8K.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The IceStorm example core doesn't include compressed instructions or the
MULT extension; it is an rv32i core, not rv32i[m|c]. If the given
riscv32 toolchain is not explicitly told to generate rv32i code for the
firmware, it may generate invalid instructions which cause a trap during
simulation or on the hardware itself (although CATCH_ILLINSN is set to
zero in this case, too).
Luckily, any rv32i* toolchain (rv32imc for example) can fit the bill
here -- there's no use of libgcc or anything (which might introduce
illegal instructions generated previously) so just forcing the compiler
to generate the right code works nicely.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
nextpnr-ice40 gives a better fMAX for this design (by about ~9Mhz for
me: ~59MHz -> ~68MHz) and is The Way Of The Future.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This touches up the Makefile so that it:
- uses $@, $< and $^ in more places for brevity and robustness (typo
guards, etc)
- tracks dependencies slightly better (e.g. .pcf file changes weren't
tracked before)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The net result of this is that cd'ing into the main source directory and
running:
$ nix-shell
will get you every tool needed to immediately do RISC-V development with
picorv32 or picosoc (assuming you're targeting ICE40 or ECP5).
The shell.nix file contains many comments on how to use the resulting
environment.
Signed-off-by: Austin Seipp <aseipp@pobox.com>