amaranth-lang / amaranth-stdio Goto Github PK

I was reading through the code and noticed that AsyncSerial.Signature contains AsyncSerialRX.Signature and AsyncSerialTX.Signature, and all three of them contains a member named divisor.

Furthermore, AsyncSerial assigns to the inner two:

        m.d.comb += [
            self.rx.divisor.eq(self.divisor),
            self.tx.divisor.eq(self.divisor),
        ]

This implies that they are effectively outputs, despite having a signature denoting them as inputs. I believe this will cause a driver conflict error if you attempt using wiring.connect() on either of the three interfaces.

This is not an immediate problem to me, as I only caught this on a read-through, but it seems like an anti-pattern that deserves some attention.

Issue by jfng
Wednesday Jan 01, 2020 at 20:39 GMT
Originally opened as m-labs/nmigen-stdio#3

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

Issue by zignig
Thursday Sep 05, 2019 at 11:37 GMT
Originally opened as m-labs/nmigen-stdio#1

from m-labs @2019-09-04

here's the plan I had in mind: nmigen-cores implements protocols, things like SPI, I2C, JTAG TAP, and so on. nmigen-soc adapts these cores to various buses, wishbone of course but I suspect it would pay off to not hardcode everything to wishbone specifically

Create some cores in a neutral format.

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

On this pull request, I propose an SPI flash controller module exclusively for reading data or registers out of a flash device. Currently, it has:

• _SPIFlashReaderBase: a base class from which can be inherited to create a new controller module, such as one that reads the ID of the flash device by issuing the opcode 0x9F (or 0x9E)
• SPIFlashSlowReader: a module for normal reads from the device, meaning no dummy cycles of waiting is needed right after sending the address bytes to the device, while the read frequency is often capped.
• SPIFlashFastReader: a module for "fast reads", meaning a faster frequency than normal reads while a number of dummy cycles of waiting is needed right after sending the address bytes.

Note that only the SlowReader but not the FastReader has been successfully tested on the ECP5 evaluation board.

In order to use the clock signal clk as the SPI clock for this module design, ECP5 requires the user NOT to request for SPI clock that corresponds to the on-chip oscillator (MCLK) but to instantiate a USRMCLK Instance. Therefore, to use this module and bulid the configuration bitstream on nextpnr without errors (see this comment), the user must avoid requesting for the normal clock pin from Ball U3 by some means. One way is to use my proposed modification of nmigen-boards.

I look forward to seeing further comments, thanks.

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

• fix fallout from RFC 37 and RFC 38
• set requirement to "amaranth>=0.4<0.6"
• add CI tests against 0.4

Issue by HarryHo90sHK
Friday Jan 03, 2020 at 06:47 GMT
Originally opened as m-labs/nmigen-stdio#4

On this pull request, I propose modifications on @whitequark's UART / asynchronous serial transmitter/receiver that would introduce a way to formally verify the I/O. The major changes include:

1. Deprecated nMigen syntax (e.g. FFSynchronizer, nmigen.tools) have been eradicated.
2. AsyncSerialRX now has the following signals: ack for enabling transfer of received data to another module, busy for indicating ongoing data reception, and r_rdy for indicating whether or not the received data is ready to transfer.
3. AsyncSerialTX now has the following signals: ack for enabling transmission of data from another module, busy for indicating ongoing data transmission, and w_done for indicating whether or not the data has been transmitted.
4. The data bits are now ordered in ascending significance of bit, i.e. LSB is transmitted first, MSB is transmitted last.
5. Two test cases (AsyncSerialLoopbackTestCase and AsyncSerialBitstreamTestCase) that use a formal verification approach has been added to nmigen_stdio.test.test_serial. In short, they use Bounded Model Checking to check if the desired states (e.g. "DONE" for correct data transmission, or "ERROR" for data with errors) can be reached within certain numbers of cycles, usually equal to the duration that starts before the RX/TX is enabled and ends after the RX/TX asserts r_rdy/w_done.

I will provide further useful descriptions and explanations later on. I look forward to seeing further comments, thanks.

Edit: the version check in setup.py will be modified according to the final decision.

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