search

kekiefer / tinyfpga-litex

A minimal LiteX SoC definition for the TinyFPGA BX
14 stars 1 forks source link

Fix compatibility with latest LiteX #4

Closed DurandA closed 5 years ago

DurandA commented 5 years ago

Fix #3

DurandA commented 5 years ago

It seems that latest Migen/LiteX/Yosys use more resources!

kekiefer commented 5 years ago

Thanks for the PR! This is working fine for me. I've got a headerless board today, and I'm not having any problems booting it without anything plugged into it.

One extremely minor thing that I'd like your input on. The old readme didn't match the pins that were configured in code for the UART. The readme claimed to be using GPIO:0 and GPIO:1 (which are A2 and A1) but the code actually configured the pins B1 and C2 (GPIO:2 and GPIO:3). The reason I used 2 and 3 was that it allowed me to directly plug in a TTL-232R-3V3 to the pin headers as long as I leave the extra IOs tristate.

TTL-232R-3V3 pinout

As such, you've faithfully preserved this confusion in the readme :) but now's probably the time to straighten this out. What say you?

DurandA commented 5 years ago

One extremely minor thing that I'd like your input on. The old readme didn't match the pins that were configured in code for the UART. The readme claimed to be using GPIO:0 and GPIO:1 (which are A2 and A1) but the code actually configured the pins B1 and C2 (GPIO:2 and GPIO:3). The reason I used 2 and 3 was that it allowed me to directly plug in a TTL-232R-3V3 to the pin headers as long as I leave the extra IOs tristate.

I was hesitant to change it as there is probably a bug as GPIO:0 maps to C2 and GPIO:1 maps to B1. That means that the pins remain unchanged :open_mouth: until it is fixed upstream (might be Migen related rather than LiteX). Maybe we can wait a little bit before merging until this is cleared.

kekiefer commented 5 years ago

Interesting! Are you sure this wasn't happening since we were actually calling out the IOs named C2 and B1 in previous versions of code?

DurandA commented 5 years ago

That was also my first reaction but I completely removed the output folder (_soc_tinylitex_tinyfpgabx) and rebuilt everything from scratch.

I will create a new virtualenv and reclone everything just to be sure.

kekiefer commented 5 years ago

Checking the result from the build I just did (from the code in this PR and the current litex), I am getting a sane pin configuration:

set_io serial_tx A2
set_io serial_rx A1
...
DurandA commented 5 years ago

This was indeed a big facepalm from me as I edited the litex-boards package from my virtualenv. :see_no_evil:

Let's reintroduce custom pins for the serial. What do you think about changing directly the tinyfpga_bx.serial global variable? This way users can comment this block to use default values and we can annotate it as such.

tinyfpga_bx.serial = [
    (
        "serial", 0,
        Subsignal("tx", Pins("C2")),
        Subsignal("rx", Pins("B1")),
        IOStandard("LVCMOS33")
    ),
]
kekiefer commented 5 years ago

I like it. This is a good middle ground between using definitions from the main board package and demonstrating how to achieve customization.

DurandA commented 5 years ago

This is not directly related, but do you know how to use GPIOs as Signal without adding _io entries?

kekiefer commented 5 years ago

This is what platform.add_extension() is for, to add more pins to drive (this extends the ConstraintManager's available list), if I'm understanding your question correctly. You'll add an array of tuples like [("user_led", 0, Pins("D1"), IOStandard("LVCMOS33"))].

BTW, I do like the GPIO:# format for these peripherals since it really represents the header on the board. I forget why I didn't do this initially, but I can't think of a reason not to now.

kekiefer commented 5 years ago

Thanks for the updates!

DurandA commented 5 years ago

This is what platform.add_extension() is for, to add more pins to drive (this extends the ConstraintManager's available list), if I'm understanding your question correctly. You'll add an array of tuples like [("user_led", 0, Pins("D1"), IOStandard("LVCMOS33"))].

Thanks! Due to function naming, I expected it to perform something else.

BTW, I do like the GPIO:# format for these peripherals since it really represents the header on the board. I forget why I didn't do this initially, but I can't think of a reason not to now.

Be careful as it starts with GPIO:0 so you need to subtract 1.

Thanks for the updates!

Thanks to you! Without your project we wouldn't be able to experiment with LiteX easily on the TinyFPGA.