jkiv / shapool-core Goto Github PK

For testing

Branch and add support for ECP5-85.

Transcribe test cases from verilog to a prototyping MCU (e.g. Arduino) to test SPI and computational capability.

Revisiting the code, there are a few signals (e.g. skip_first, etc.) that make the code a bit confusing.

It may be better to refactor top-level module as a proper state machine.

Convert input/output data storage from registers to block RAM.

We're currently using about 700 bits worth of shift registers... Maybe we can squeeze some more compute power out of certain devices by using block RAM instead.

top.v is fairly descriptive on how the core works. Similar descriptions should be included in README.md and/or somewhere in docs/

Most resets are active high. Change to active low.

From Lattice HDL Guidelines:

The GSR can only be used for asynchronous active low resets due to the underlying hardware. The software will take this into account automatically and will not implement a synchronous reset using GSR when the Inferred GSR or User Specified Inferred GSR modes are used.

Currently using arachne-pnr, circa 2017.

• PCF
• READY neighbour signals
• ...

Combining them is messy.

Issue with yosys parsing sha_unit.v. Requires more investigation.

$ make make shapool_hx8k_ct256.bin
yosys -p 'synth_ice40 -top top_hx8k -blif shapool_hx8k.blif -abc2 -retime' top_hx8k.v top.v shapool.v sha_unit.v sha_round.v w_expand.v SHA256_K.v difficulty_map.v
[...]
Parsing Verilog input from `sha_unit.v' to AST representation.
Generating RTLIL representation for module `\sha_unit'.
ERROR: Failed to detect width of memory access `\Mt' at sha_unit.v:57!
Makefile:12: recipe for target 'shapool_hx8k.blif' failed
make: *** [shapool_hx8k.blif] Error 1

I set up a new development environment using "apt-get install" whereas I previously built from Github sources.

$ yosys -V
Yosys 0.7 (git sha1 61f6811, gcc 6.2.0-11ubuntu1 -O2 -fdebug-prefix-map=/build/yosys-OIL3SR/yosys-0.7=. -fstack-protector-strong -fPIC -Os)

It mentions using Verilog-2005 frontend. I'm not sure if I used that in the past, or if it was (somehow) iverilog. All my test code uses iverilog.

Migrated to FT232H devices. Is it possible to write tests (device programming, jobs, etc.) using libftdi (C) or pylibftdi (python)?

Hey, this is a very cool project.
Can we know what is the speed of this?

IIRC the pinout was originally decided based on how close the pins were to the perimeter of the BG121 package... In icepool-board, we're just keeping the IO to a single IO bank (not yet clear why that wouldn't be fair to do).

• Reconfigure pinout using icepool-board configuration.

Additionally (although this probably should be a separate issue), support the pinout interface defined by icepool-board, namely:

• GMOSI (Shared SPI MOSI)
• GMOSI (Shared SPI MISO)
• MISO (FIFO input)
• MOSI (FIFO output)
• SCK (Shared clock)
• ~GS (Global select -- replaces daisy select; 1: read from GMOSI, write to GMISO, 0: read from MOSI, write to MISO)
• ~WE (Write enable -- replaces "reset")

This may revert previous choices. However, it makes more sense to describe the pinout and make targets per board, e.g.

$ make shapool-icebreaker-bitsy.bin

Not sure how to implement this.

And add badge to README!

https://travis-ci.org/

• e.g. make target test_example is example_test.v.
• maybe say testbench or _tb.

Lattice development boards (e.g. UP5K, ICE40HX8K, MachXO3LF) have an FTDI device configured with an SPI interface (for programming the device in SPI slave mode) and a UART interface, whereas the icepool board has uses two SPI interfaces.

For the sake of using the development boards, is it possible to substitute the second SPI interface, e.g.

• with a UART interface?
• by doubling the first SPI interface?

Implement formal verification techniques on modules.