openXC7 / xc7k325t-picosoc-nextpnr

Picosoc for the XC7K325T using yosys+nextpnr
BSD 3-Clause "New" or "Revised" License
9 stars 1 forks source link

PicoSOC works! #1

Closed hansfbaier closed 2 years ago

hansfbaier commented 2 years ago

@jrrk2 @unbtorsten , PicoSOC works! I used only IOs on bank14 and it works! https://twitter.com/hansfbaier/status/1490804604451573760

kdunn926 commented 2 years ago

I'm trying to replicate this... I soldered on headers and am using pins 58/57 on U5. I think this should correspond to B25 (rx) and B26 (tx) for the UART. I don't see anything when attaching minicom to the serial converter, any ideas what I'm missing?

hansfbaier commented 2 years ago

Did you use the baud rate from the readme?

hansfbaier commented 2 years ago

Also the UART rx need to be connected to board tx and vice versa. Does it blink?

kdunn926 commented 2 years ago

The two LEDs are solid and very dim using this example, blinky works flawlessly, cycling between both with normal brightness. I think I have the polarity of tx/rx correct and am using the baud you specified (227894). Earlier I did see minicom print a bunch of garbage to the screen, though it then froze up - I may try an connect the serial to a Linux machine instead.

Are there other serial settings needed (e.g. 8N1, flow control, etc)?

hansfbaier commented 2 years ago

The LEDs definitely should blink. If they are dim, that means probably wrong pin configuration, or the clock is not working somehow. If the serial port seems to output something, try hooking up a logic analyzer, and see what's going on there.

hansfbaier commented 2 years ago

The blinky should only blink one LED, and the other should be dim. If it is blinking alternately then what you are seeing is the factory blinky flashed on the board. So something seems to be wrong with your setup.

hansfbaier commented 2 years ago

Also try rebuilding the project. I had just dim LEDs on both picosoc and blinky until a rebuild. It might be possible that sometimes nexpnr outputs a routed design which does not work.

hansfbaier commented 2 years ago

In picosoc both LEDs should blink (10 - 11 - 01 - 00). Please note that I just replaced the build scripts with a Makefile.

hansfbaier commented 2 years ago

@kdunn926 Not I can't also build a working bitstream for the QMTech board. I even started to go back in the history to where it worked with the same result. I ran the build many times today and all resulted in tristated LEDs. I wonder what made the difference.

kdunn926 commented 2 years ago

@hansfbaier - I've been setting up a new environment on a VM to see if that makes any difference. Any chance you can share SHA hashes for the different intermediate artifacts (e.g. xc7k325tffg676-1.{bba,bin}, picosoc.{json,fasm,frames,bit}) so I can compare? I don't know which (if any) of these files are deterministic but it might be helpful anyway.

On the Mac OS environment I was using clang (10.0.1) and yosys (c76d533e).

hansfbaier commented 2 years ago

@kdunn926 Let's continue in this new issue: https://github.com/kintex-chatter/xc7k325t-picosoc-nextpnr/issues/2

kdunn926 commented 2 years ago

The LEDs definitely should blink. If they are dim, that means probably wrong pin configuration, or the clock is not working somehow. If the serial port seems to output something, try hooking up a logic analyzer, and see what's going on there.

Just to close the loop on this @hansfbaier , after hooking it up to a scope and poking around the scope UART decode settings, using "Idle High" mode, I could see many characters being decoded (e.g. Press, enter, cont), though there are frequent transmission errors. I never got my USB-Serial converter functioning in this case, it is probably junk.

I've still never seen the LEDs cycle correctly for this design, though when I "merged" the blinky code with the picosoc code, I did see LEDs work as expected while the picosoc design was running. Odd.