csr_expose removed

[nanortemis]

Does not work with the latest Litex: TypeError: init() got an unexpected keyword argument 'csr_expose'

Please check: https://github.com/enjoy-digital/litex/commit/526ba1b165a09f6c0b51646a4b3124b345428d28

[DurandA]

This doesn't seem to be the only issue using the latest LiteX. I tried to update the SoC definition to use litex-boards but I cannot make it boot. I tried with all possible combinations of verxriscv and picorv32 with min, lite and std variants.

[kekiefer]

LiteX has proved a bit of a moving target. I've been meaning to dig back into this, but let me know if you come up with anything in the meantime.

[DurandA]

First of all, thank you for making a LiteX SoC definition for the TinyFPGA.

These are my efforts to make it work on latest LiteX: I removed the csr_expose parameter. Then the leds peripheral needed to be added to the CSR. Changing these doesn't seems to be enough though, as the bitstream successfully generate but the board doesn't boot. Updating the platform to litex_boards.partner.platforms.tinyfpga_bx do not solve this issue but it seems to be the way to go now.

I am unfortunately new to LiteX and to FPGAs in general so I have no clues on how to fix this. Do you have any ideas?

[DurandA]

Could it broke with latest yosys, next-pnr, riscv64-unknown-elf-gcc toolchain or whatever? Maybe it is worth trying my patch using a toolchain known to be working.

[kekiefer]

It would appear that my last build was with enjoy-digital/litex@2c3c6bdf9bd1827741ee6937725800e3bfd11dbe and YosysHQ/yosys@4c7306185e68824cd24e666946ca7b277169c16b YosysHQ/nextpnr@4c7306185e68824cd24e666946ca7b277169c16b

I wouldn't think this would be a toolchain issue, but instead something new in litex (just based on the number and potential impact of the changes between here and there). It may be worth eliminating this variable if it's easy.

Perhaps start at the commit that @nanortemis pointed out and convince yourself that we can simply remove csr_expose and memory mapped peripherals like the leds will still work. If that is ok, I would probably git bisect from there to current and see what's falling down.

[DurandA]

~It seems that reverting to enjoy-digital/litex@2c3c6bd still fails with my setup.~ Next steps are to revert to previous versions of Yosys and YosysHQ/nextpnr@4c73061.

Can you provide me your Yosys git hash version (the provided one was mixed with nextpnr)?

[kekiefer]

I actually have yosys installed via homebrew at 0.8, so presumably that's YosysHQ/yosys@5706e90802fdf51a476e769790f6b5b526c57572

[kekiefer]

OK, I retried the original build against enjoy-digital/litex@2c3c6bdf9bd1827741ee6937725800e3bfd11dbe and it worked for me. Next I tried the build at enjoy-digital/litex@526ba1b165a09f6c0b51646a4b3124b345428d28 with the changes you made (removing csr_expose and putting an "leds" entry into the csr_map) and this does not work, so there's certainly some issue here. Unfortunately I don't have pin headers on the board I have with me today, so I can't verify if the UART is working at this point or not.

[DurandA]

This issue has nothing to do with the Yosys nor the nextpnr version since I was able to run your SoC definition with latest revisions.

I don't know what kind of sorcery is this, but the SoC doesn't start if I connect the TinyFPGA to a breadboard (sometimes it does but very unreliably):

[DurandA]

My patch seems to work as is with latest LiteX! :tada:

My current hypothesis is that the RX pin from the FPGA should always be connected to an UART adapter. If the pin is left floating, it might keep overflowing the bus/interrupting the CPU. This could also explain why connecting to a breadboard make a difference.

I tried to pull up/down RX with a 10k resistor but it seems to be unreliable.

[DurandA]

Should I make a pull request with updated documentation?

[kekiefer]

Cool! A pull request would be great.