amaranth-lang / amaranth-boards Goto Github PK

Building the ideal_spork I came across an interesting error block.

command

python -m ideal_spork --dumpall --force

Errors:

Ideal Spork
20200507 21:28:46 - ERROR - upduino_v2 main - line 32 - ()
20200507 21:28:46 - ERROR - Resource SB_HFOSC#0 does not exist main - line 33 - ()
20200507 21:28:46 - ERROR - de10_lite main - line 32 - ()
20200507 21:28:46 - ERROR - Resource clk50#0 does not exist main - line 33 - ()
20200507 21:28:46 - ERROR - tinyfpga_ax1 main - line 32 - ()
20200507 21:28:46 - ERROR - Can't instantiate abstract class TinyFPGAAX1Platform with abstract methods resources main - line 33 - ()
20200507 21:28:46 - ERROR - tinyfpga_ax2 main - line 32 - ()
20200507 21:28:46 - ERROR - Can't instantiate abstract class TinyFPGAAX2Platform with abstract methods resources main - line 33 - ()
20200507 21:28:46 - ERROR - zturn_lite_z010 main - line 32 - ()
20200507 21:28:46 - ERROR - Platform 'ZTurnLiteZ010Platform' does not define a default clock main - line 33 - ()
20200507 21:28:46 - ERROR - upduino_v1 main - line 32 - ()
20200507 21:28:46 - ERROR - Resource SB_HFOSC#0 does not exist main - line 33 - ()
20200507 21:28:46 - ERROR - zturn_lite_z007s main - line 32 - ()
20200507 21:28:46 - ERROR - Platform 'ZTurnLiteZ007SPlatform' does not define a default clock main - line 33 - ()

Patch can be built if needed.

Issue by Fatsie
Friday Jul 05, 2019 at 09:17 GMT
Originally opened as m-labs/nmigen-boards#15

This is current state for the Digilent Atlys board file. It is not finished but put forward to have feedback to solve some questions. The questions are put as TODO comments in the python code.

I used #4 (Arty A7) as inspiration but changed some things for the ethernet. Some changes: tx_col->col, tx_crs->crs. I'm wondering if we should also call tx_data and rx_data as txd and rxd according to standard.
Other change is that I defined most of the signals defined as clock also with Clock() except for mdc signal. I noticed that it is needed when one actually wants to use one of these input signals as a clock.

Fatsie included the following code: https://github.com/m-labs/nmigen-boards/pull/15/commits

Issue by Fatsie
Friday Oct 25, 2019 at 09:21 GMT
Originally opened as m-labs/nmigen-boards#34

This change will let default sync domain have a reset signal.

Fatsie included the following code: https://github.com/m-labs/nmigen-boards/pull/34/commits

Issue by HarryHo90sHK
Monday Dec 23, 2019 at 08:22 GMT
Originally opened as m-labs/nmigen-boards#38

According to Section 6.1.2 of an official ECP5 manual, only the on-chip oscillator MCLK is available as the SPI clock when in Master SPI mode by default. To use any user clock as the SPI clock, a USRMCLK Instance must be instantiated and there is no need to request for the clock from Ball U3. Requesting for such clock will lead to an error as reported by @xobs on the nextpnr repo.

Therefore, I would like to suggest modification on memory.py such that there is an option to add the SPI flash resources to a platform (not only ECP5) without the clock. Although this modification has been used to successfully build and flash a bitstream on an ECP5 board (the example was an SPI reader module on my nmigen-stdio fork), I cannot deny that there is room for improvement on my code for this pull request.

I look forward to seeing further comments, thanks.

See also: my pull request on nmigen-stdio for a SPI controller.

HarryHo90sHK included the following code: https://github.com/m-labs/nmigen-boards/pull/38/commits

Issue by Fatsie
Tuesday Jun 18, 2019 at 20:16 GMT
Originally opened as m-labs/nmigen-boards#5

icebeaker.py had DOS eols.

Fatsie included the following code: https://github.com/m-labs/nmigen-boards/pull/5/commits

Issue by nicolas-robin
Saturday Jan 18, 2020 at 19:27 GMT
Originally opened as m-labs/nmigen-boards#46

this was an unfortunate copy/paste from another board

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/46/commits

Issue by emilazy
Friday Jul 26, 2019 at 03:18 GMT
Originally opened as m-labs/nmigen-boards#25

emilazy included the following code: https://github.com/m-labs/nmigen-boards/pull/25/commits

Issue by Fatsie
Tuesday Jun 18, 2019 at 20:18 GMT
Originally opened as m-labs/nmigen-boards#6

Both onboard SRAM and PMOD connectors have been tested.

Fatsie included the following code: https://github.com/m-labs/nmigen-boards/pull/6/commits

Issue by rroohhh
Sunday Aug 18, 2019 at 21:17 GMT
Originally opened as m-labs/nmigen-boards#27

There is a version of this board with the xc7z007s aswell, not sure how to best handle that.

rroohhh included the following code: https://github.com/m-labs/nmigen-boards/pull/27/commits

Issue by whitequark
Friday Jun 28, 2019 at 03:47 GMT
Originally opened as m-labs/nmigen-boards#11

Boards using it:

• versa_ecp5, versa_ecp5_5g

Issue by peteut
Thursday Jan 02, 2020 at 01:49 GMT
Originally opened as m-labs/nmigen-boards#39

The Blinky test works fine on my board.

peteut included the following code: https://github.com/m-labs/nmigen-boards/pull/39/commits

Issue by ZirconiumX
Thursday Oct 10, 2019 at 22:13 GMT
Originally opened as m-labs/nmigen-boards#33

It'd be nice to have some way for this to inherit from DE10NanoPlatform, but oh well.

ZirconiumX included the following code: https://github.com/m-labs/nmigen-boards/pull/33/commits

Issue by ZirconiumX
Thursday Oct 03, 2019 at 13:21 GMT
Originally opened as m-labs/nmigen-boards#31

ZirconiumX included the following code: https://github.com/m-labs/nmigen-boards/pull/31/commits

Issue by zignig
Thursday Jun 06, 2019 at 13:47 GMT
Originally opened as m-labs/nmigen-boards#3

First part of some blinky bling.

zignig included the following code: https://github.com/m-labs/nmigen-boards/pull/3/commits

Issue by nicolas-robin
Sunday Jan 12, 2020 at 00:08 GMT
Originally opened as m-labs/nmigen-boards#40

These 2 pins were reversed

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/40/commits

Issue by nicolas-robin
Monday Jan 13, 2020 at 18:53 GMT
Originally opened as m-labs/nmigen-boards#42

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/42/commits

Issue by nicolas-robin
Sunday Jan 12, 2020 at 10:21 GMT
Originally opened as m-labs/nmigen-boards#41

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/41/commits

Issue by cr1901
Sunday Jul 07, 2019 at 14:35 GMT
Originally opened as m-labs/nmigen-boards#18

Occasionally, it is possible a user will want to add their custom Resource to their boards Connectors that matches the following conditions:

• A Subsignal of their shiny new Resource has multiple Pins that should be associated with it.
• The Pins of this Subsignal will be spread out across multiple Connectors.

omigen already handles this case by hardcoding the connector to use into the Pins string, as per this example on the b Subsignal.

What should the equivalent nmigen behavior be?

My Proposal

vga = [
        ("vga_out", 0,
            Subsignal("hsync", PinsN("3", dir="o", conn=("led", 0))),
            Subsignal("vsync", PinsN("4", dir="o", conn=("led", 0))),

            Subsignal("r", Pins("1 2 3", dir="o", conn=("dio", 0))),
            Subsignal("g", Pins("4 5 6", dir="o", conn=("dio", 0))),
            Subsignal("b", Pins("7", dir="o", conn=("dio", 0)),
                           Pins("1", dir="o", conn=("clkio", 0))),
            Attrs(IOSTANDARD="LVCMOS33", SLEW="FAST")
        )
    ]

Issue by whitequark
Friday Jun 28, 2019 at 03:51 GMT
Originally opened as m-labs/nmigen-boards#13

Primarily because defining many of them in sequence is tedious, annoying and error-prone. NB: non-sequential resource numbers should be handled well.

Hey, would it be possible to tag a release so that migen-boards can be properly distributed?

Issue by whitequark
Wednesday Sep 18, 2019 at 04:22 GMT
Originally opened as m-labs/nmigen-boards#29

Blocked on m-labs/nmigen#178.

whitequark included the following code: https://github.com/m-labs/nmigen-boards/pull/29/commits

Issue by TiltMeSenpai
Tuesday Jan 14, 2020 at 23:06 GMT
Originally opened as m-labs/nmigen-boards#44

Notes:

• Alchitry Au requires a loader program from Alchitry. I tried to follow a pattern similar to what nmigen uses to locate Yosys/Vivado but I'm not sure if that's the right approach
• DDR3 is untested. The pins are copied from the schematic so I may have gotten something wrong there.
• There's also an io shield for the Au with a few buttons, some 7 segment displays, and a bunch of LED's. I was debating adding a resource for that, similar to how the icebreaker pmod's are defined, but ultimately decided I was gambling whether I'd finish that pin definition before running out of motivation. Let me know if you'd like that pin definition in this PR and I'll try to add it.

TiltMeSenpai included the following code: https://github.com/m-labs/nmigen-boards/pull/44/commits

Issue by emilazy
Friday Sep 20, 2019 at 14:10 GMT
Originally opened as m-labs/nmigen-boards#30

emilazy included the following code: https://github.com/m-labs/nmigen-boards/pull/30/commits

Issue by jfng
Friday Jun 07, 2019 at 21:53 GMT
Originally opened as m-labs/nmigen-boards#4

jfng included the following code: https://github.com/m-labs/nmigen-boards/pull/4/commits

Issue by cr1901
Sunday Aug 04, 2019 at 13:18 GMT
Originally opened as m-labs/nmigen-boards#26

As requested. This is a breaking change because the order of arguments to SRAMResource changed by making oe optional.

cr1901 included the following code: https://github.com/m-labs/nmigen-boards/pull/26/commits

Issue by whitequark
Tuesday Jun 04, 2019 at 09:55 GMT
Originally opened as m-labs/nmigen-boards#1

It's very important to have an easily available litmus check for a correctly installed and configured toolchain for any particular board. I propose that any board that is run as __main__ should demonstrate that by running a blinky. (Are there any boards without LEDs and what can we do about it?)

This is currently done and tested for:

• icestick
• ice40_hx1k_blink_evn
• tinyfpga_bx

Issue by ZirconiumX
Saturday Nov 30, 2019 at 21:22 GMT
Originally opened as m-labs/nmigen-boards#37

(not a breaking change, because trying to use this never worked in the first place due to the cmd/dat3 conflict)

ZirconiumX included the following code: https://github.com/m-labs/nmigen-boards/pull/37/commits

I've noticed that dtr and rts signals of UARTResource are defined as outputs, but on the IceStick they are actually inputs, according to the schematic.

I see two options for fixing this:

1. Add role argument (dce/dte) to UARTResource, similar to SPIResource; set the direction of the flow control pins based on the role; set correct role for ICEStickPlatform.
2. Assume that UARTResource is only going to be used with role=="dce", and reverse the direction of flow control pins. This might (?) break some designs.

I can submit a PR for either of the options, would appreciate some guidance which one to choose.

Thanks for maintaining this project!

Issue by Fatsie
Tuesday Jun 18, 2019 at 20:20 GMT
Originally opened as m-labs/nmigen-boards#7

I don't have BlackIce II board so this is untested.
It is based on tested BlackIce boards file with changes in schema for SRAM connection applied.

Fatsie included the following code: https://github.com/m-labs/nmigen-boards/pull/7/commits

Issue by whitequark
Friday Jun 28, 2019 at 03:47 GMT
Originally opened as m-labs/nmigen-boards#12

Boards using it:

• Alchitry Au
• Arty A7
• Arty S7
• ECPIX5
• Genesys2
• OrangeCrab r0.1, r0.2
• versa_ecp5, versa_ecp5_5g

Issue by whitequark
Friday Jun 28, 2019 at 03:47 GMT
Originally opened as m-labs/nmigen-boards#10

Boards using it:

• Atlys
• ECPIX5
• Genesys2
• versa_ecp5, versa_ecp5_5g

Issue by rroohhh
Wednesday Aug 21, 2019 at 21:21 GMT
Originally opened as m-labs/nmigen-boards#28

fyi: @mithro

rroohhh included the following code: https://github.com/m-labs/nmigen-boards/pull/28/commits

Issue by nicolas-robin
Friday Jan 17, 2020 at 21:36 GMT
Originally opened as m-labs/nmigen-boards#45

Blinky tested OK on the actual board.

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/45/commits

Issue by cr1901
Sunday Jul 07, 2019 at 13:55 GMT
Originally opened as m-labs/nmigen-boards#17

Differences between various 7SDs:

• Common cathode vs anode?
• Is decimal point used?
• Are the digit enable signals one-hot coming out of the FPGA or not?
  • Using a single enable line, where 0 controls one digit, and 1 controls the other seems more
    common when only two digits are present (fairly common setup). Otherwise, one-hot is used.

Potential Subsignal naming scheme:

• a, b, ... g, dp for decimal point (if present)
• en{0, 1, 2}
  • How should one-hot vs shared en be handled in naming. Should there be a difference?

Boards using it right now

None! But Mercury will (for the baseboard peripheral that is normally attached to it), and in omigen, the naming scheme was inconsistent. So I want to fix this before it becomes a problem.

Issue by cr1901
Wednesday Jun 05, 2019 at 23:34 GMT
Originally opened as m-labs/nmigen-boards#2

Self-explanatory, please give the usual feedback and desired changes; this should functionally match the platform file in omigen.

cr1901 included the following code: https://github.com/m-labs/nmigen-boards/pull/2/commits

Issue by whitequark
Friday Jul 05, 2019 at 19:58 GMT
Originally opened as m-labs/nmigen-boards#16

Issue by nicolas-robin
Tuesday Jan 14, 2020 at 08:25 GMT
Originally opened as m-labs/nmigen-boards#43

Tested succesfully on the actual board with blinky and an UART demo with flow control.
The others resources are based on the official XDC (and schematic for the DDR2), but not tested.

nicolas-robin included the following code: https://github.com/m-labs/nmigen-boards/pull/43/commits

Issue by whitequark
Friday Jun 28, 2019 at 03:46 GMT
Originally opened as m-labs/nmigen-boards#9

Boards using it:

• blackice, blackice_ii

Hi,

For some peripherals (eg. DDR memory) there are inverted pins (RAS_N, CAS_N, etc. in DDR3) that are configured as PinsN. The issue with PinsN is that it gets an inverter inserted between the TRELLIS_IO instance (on ECP5 platform) and the .o exposed to the user which prevents the use of DDR primitives (ERROR: ODDRX2F 'ddrphy.U$$19' Q output must be connected only to a top level output).

Assuming this issue isn't vendor-specific, should we declare those resources with the "*_n" naming style and expect the user to do the inversion themselves? Or should we keep it as-is and request the resource as raw IO?

Issue by alexhude
Monday Jun 24, 2019 at 12:35 GMT
Originally opened as m-labs/nmigen-boards#8

Currently when you add plat.add_resources(plat.break_off_pmod) there is a build error

NameError: Trying to add (resource user_led 0 (pins o pmod_2:7) (attrs IO_STANDARD=SB_LVCMOS33)), but (resource user_led 0 (pins-n o 11) (attrs IO_STANDA
RD=SB_LVCMOS33)) has the same name and number

It is caused by overlapping resource indices in icebreaker.py board description.
In order to address this issue numeration has changed to be contiguous.
For example, user_led on main board have indices 0 and 1 and PMOD user_led are now assigned to numbers from 2 to 6. Similar adjustments are made to user_ledr, user_ledg and user_btn

alexhude included the following code: https://github.com/m-labs/nmigen-boards/pull/8/commits

Issue by cr1901
Sunday Jul 07, 2019 at 22:12 GMT
Originally opened as m-labs/nmigen-boards#19

Self-explanatory, meant to test the newly-added Spartan3A support in nmigen (and so I can continue using a board with lots of 5V tolerance until I can buy a Mercury 2 :)).

cr1901 included the following code: https://github.com/m-labs/nmigen-boards/pull/19/commits

Issue by zignig
Friday Nov 29, 2019 at 11:30 GMT
Originally opened as m-labs/nmigen-boards#36

Store a map of the flash addresses for a flash driver to set up addressing.

zignig included the following code: https://github.com/m-labs/nmigen-boards/pull/36/commits

Issue by whitequark
Tuesday Jul 09, 2019 at 02:45 GMT
Originally opened as m-labs/nmigen-boards#23

This was added in m-labs/nmigen@367ad5a and could be used to make resources more flexible.

Issue by jfng
Wednesday Jul 03, 2019 at 16:25 GMT
Originally opened as m-labs/nmigen-boards#14

jfng included the following code: https://github.com/m-labs/nmigen-boards/pull/14/commits

Is there any reason why my pull requests from m-labs/nmigen-boards are no longer present in this fork ? Will it be accepted if I pull request again here ?

Issue by Stary2001
Thursday Nov 28, 2019 at 16:32 GMT
Originally opened as m-labs/nmigen-boards#35

As in https://github.com/tinyfpga/TinyFPGA-BX/blob/master/icestorm_template/pins.pcf#L59, pin 17 should be C9 instead of pin 17/19 both being B8. This caused issues when using both pins 17/19 in a design.

Stary2001 included the following code: https://github.com/m-labs/nmigen-boards/pull/35/commits

Issue by whitequark
Monday Jul 08, 2019 at 10:50 GMT
Originally opened as m-labs/nmigen-boards#21

Now that m-labs/nmigen#128 and m-labs/nmigen#129 are merged, board files may be improved.

Issue by cr1901
Monday Jul 08, 2019 at 03:38 GMT
Originally opened as m-labs/nmigen-boards#20

This makes it easy to create peripherals like SPI ADCs, among others.

cr1901 included the following code: https://github.com/m-labs/nmigen-boards/pull/20/commits

Issue by cr1901
Wednesday Jul 10, 2019 at 15:53 GMT
Originally opened as m-labs/nmigen-boards#24

Feature parity with #20.

cr1901 included the following code: https://github.com/m-labs/nmigen-boards/pull/24/commits

Issue by ZirconiumX
Thursday Oct 10, 2019 at 10:50 GMT
Originally opened as m-labs/nmigen-boards#32

ZirconiumX included the following code: https://github.com/m-labs/nmigen-boards/pull/32/commits