Additional Peripheral/IO Devices

[stnolting]

I am wondering if there are further hrdware modules that would be nice-to-have as peripheral/IO devices 🤔
(I will be misusing this page as online sketchbook)

Constraints
Peripheral devices should be

• something that is hard/impossible to implement in a pure-software manner (like applications that require a precise timing)
• general purpose/not too specific (that is what the custom functions subsystem CFS is meant for)
• should be "of high interest" (for instance, a UART with FIFOs fpr buffering data would be nice, but there are a lot of Wishbone/AXI-compatible super-scale UARTs out there that can be attached to the external bus interface)
• reasonable hardware overhead - I want to keep things small
• should be something that is not already part of some RISC-V extension

Some ideas
Highly inspired by some microchip data sheets 😉

• encryption/decryption/hash accelerators? (covered by RISC-V crypto extension)
• additional SPI/TWI modules? (SPI/TWI allow "multiple connections" at once)
• additional UART modules (UART is point-to-point)?
• 32-bit timer (providing capture-and-compare hardware?)
• CORDIC for trigonometric fixed-point operations?
• peripheral interfaces for
  • CAN?
  • 1-wire?
  • I²S?
• simple DMA?

Feel free to comment if you have any ideas or remarks.

[AWenzel83]

• I think additional UARTs would be great, and I would also love an I²S Interface (in combination with DMA).
• Ethernet (RMII or MII) would be cool, too. But to be honest, there are solutions for the AXI-Interafce, and I think that would be a bit out of scope.
• What about a Neopixel/WS2812-Serial-Interface? It is not too hard to implement in software, but a dedicated hardware would be cool. Since it is not standardised there are (as far as I know) no microcontrollers with this interface available. But it is pretty common in the maker-scene

By the way, great work. One of my Students uses this Core in his Master Thesis, after struggling with the Cortex M1 and M3 available for Vivado and everything just workes!

[stnolting]

I still haven't checked the WS2812 data sheet yet.

Yes, it's a 800kbit (1.25 us) 1-wire serial interface. 0 and 1 are defined by the Duty-Cycle:

This sounds like something that could be done misusing the SPI controller but that would require a more fine-grained speed configuration... 🤔

You simply send 3*8bit color-data (RGB) to the LED.
You can daisy chain a lot of them

So there has to be some mechanism to trigger a "data strobe". The interesting question is what about the timing constraints for this? If sending RGB data to the LED chain can be stalled at any time (pulling the data line high/low) a peripheral module would be quite simple. But if there are hard timing constraints (you have to send RGB_data(n+1) with a maximum delay of x µs after RGB_data(n)) there might be a problem if the CPU cannot fetch data fast enough (e.g. interrupt by an IRQ). So basically the same problem as for the I²S interface without an DMA - but I²S could at least be stalled using clock gating.

By the way, great work. One of my Students uses this Core in his Master Thesis, after struggling with the Cortex M1 and M3 available for Vivado and everything just workes!

Oh, I've missed that completely. Anyway, good to hear that. That's pretty cool! 👍 😄

[AWenzel83]

I just ordered some LEDs to play with them, lets see how critical the timings really are

A 100 MHz clock and a prescaler of 8 should result in 6.25 Mbit SPI clk, an 8 bit transfer would be 1.28 us which is close enough to 1.25 us. That would give

• 3high (.48 us) and 5low(.8 us) for a 0
• 5high (.8 us) and 3low(.48 us) for a 1

So this should work with the current SPI Implementation

[stnolting]

I have borrowed some Neopixel modules to play around with this weekend.
After studying the data sheet the timing constraints seem to be preety sophisticated.

The SPI provides a 32-bit mode - so you could send 4 "bits" using a single transfer.
Of course this still requires some CPU processing power to break up and align RGB data into little chunks.
Maybe a dedicated controller (maybe as CFS template) is indeed a good idea 😉

[AWenzel83]

Mine should arrive today. My plan was to try to write a CFS module. Let's see what I can come up with.

[stnolting]

I have read some blogs regarding the WS2812 interface - and it is quite a complex task. Small microcontrollers can do the job using inline assembly but it consumes almost all available CPU resources if you do "real time image rendering" (and not just doing a memory-intense refresh from RAM). Complex systems like an Raspberry Pi have troubles keeping up with the hard timing due to things like OS interrupts. So having a dedicated HW interface for Neopixel would really be a nice niche product! 😎

I have also started writing a simple hardware interface based on the CFS template. Unfortunately, my "Neopixel" turned out to be some cheap stuff with completely different interface timings. 👎
However, I'm trying to get some genuine Adafruit ones and as soon as I have something to present I will post it.

[umarcor]

I agree - an additional UART would be quite handy. Having only a single UART that is multiplexed for console interface and for connecting some peripheral is very annoying... I have already started implementing a secondary UART.

Is there any limitation for implementing an arbitrary number of UARTs? That is, use some generic along with a generate loop, and the corresponding tweaks to the software (if necessary). The same question would apply to other components.

In the control applications where PIC/Arduino are used, I see people might want to have an arbitrary number of PWM or SPI components, each with a number of channels. So, e.g., one PWM with 6 channels and another PWM with 2 channels, implying that all the channels in a module share the same counter/fundamental frequency.

Something I've been willing to do is writing a core for controlling 3-5 LED arrays, some addressable, some non-addressable. It would be interesting to use NEORV32 for that, by just modifying a few generic parameters.

[umarcor]

Nice to see we are on the same page! I acknowledge all of your concerns. Let's discuss for the sake of knowledge.

But on the other hand you could still add as many UARTs / PWMs / SPIs / whatever via the Wishbone / AXI bus.

Since I have no background on computer microarchitecture, it's difficult for me to judge. I wrote the typical dummy CPU with an ALU, instruction decoder, data/code RAM, etc. in some course years ago. But I've never dealt with an actual "complete" CPU supported by some compiler.
On the other hand, I'm familiar with memory hierarchies in accelerators, so I somehow understand the chache/mem architecture in devices such as Zynq, and the penalty of being close or far from the CPU.

Therefore, assuming my ignorance, what's the performance penalty of using the external bus? Let me drop my thoughts:

• In Zynq, going from the CPU to the PL takes several tens of cycles. It is not possible to do a quick read-modify-write transaction. I would expect that penalty to be much lower in NEORV32, but it might be relevant.
• There might be bottlenecks in the external bus interface. Zynq provides multiple AXI-Lite and AXI Full interfaces between the CPUs and the programmable region. In the non-ultrascale versions, those are 2 AXI-Lite slave, 2 AXI-Lite master and 4 AXI Full master, from the perspective of the hardware (not the CPU). Obviously, the scale in NEORV32 is very different, but I wonder if it makes sense to support a configurable number of external interfaces. My guess is that it's not valuable, because it would not provide a performance/area advantage over using an external crossbar interconnect for driving subnets.
• Peripherals such as PWMs, DMAs, etc. can safely be placed in the external bus, because those are low-throughput components. I mean the required control throughput between the CPU and the component. However, UARTs, SPIs, etc. might need to have "direct access". I'm thinking about your investigation with regard to neopixel too.

Overall, it might be interesting to create a subdir with optional external modules. The PWM component might be the first to be moved into that category. However, it does not resolve any of the two main challenges: allow instantiating multiple times, and allow the software to automatically adapt to the number of instances. We are just placing them in one memory region or another, and we need to connect ports in one way or another; but the tasks are the same from the system integrator's point of view.

Moreover, creating a subdir of optional external components might open the door to hell 😆. Currently, it is more reasonable that you say "I don't want too custom peripherals in the optional list". Having external components in the repo can lead to lots of cores being added, which then need to be maintained. It might be strategically better to create a separated repo (say neorv32-optional), and to submodule it. Moreover, you might want to create an organisation for NEORV32. Last, but not least, you might decide that none of that complexity is worth the effort, so all external modules should be hosted in independent repositories (and maybe listed in opencores, librecores, etc.). At some point, we are discussing about using IPXACT or *.core files and having a SoC composing system. That escalated quickly! Yet, that is obviously overkill and out of scope for this repo. There are other people working on open source projects for dealing with that (see e.g. Litex or Kactus2 in hdl.github.io/awesome).

Therefore, let's focus on one internal optional module which you feel confident about making "generic". Say, the UART?

How to provide an unified interface for - let's say - multiple UARTs? Unfortunately, there is nothing like #if for the VHDL entity:

That is supported in VHDL 2019 through conditional compilation I think? Anyway, that language feature is not supported by most tools yet.

Of course one could use vectors. So in terms of the UART: one vector for all TXD, one for all RXD and so on. But I am not sure if this is a convenient solution

I believe this is the idiomatic solution. In fact, before VHDL 2019, I would write two record types, each containing the signals in one direction, and I would use an array of those types. After VHDL 2019, the two records are not required, since interfaces are single record with the modes defined (see the issues/PRs in vhdl/interfaces).

In the specific case of UART, which has a single bit in each direction, the records are not useful, so the natural solution is using an std_logic_vector. However, and this is a very important however, these "arrays of interfaces" do only need to be used in the system level. Inside the instances, you use them normally. At the board level, you can unpack the arrays for showing a "clean" external/top entity. Hence, the ugly part is probably having to generate the top-level entity based on the generic parameters.

@Paebbels, any feedback? We are talking about instantiating an arbitrary number of UARTs (using a generic or constant) and how to deal with the top-level ports for exposing a "clean" named list.

Right now the CPU provides 16 "fast interrupt" request lines. Most of the are used by the SoC's peripherals (for example for the UART0 transmission done interrupt).

I think the sensible solution is to connect all of them, if possible. Otherwise, show an error and tell the user to manually specify which interrupts are to be used and which are not. I did not look into the code, but I guess we could have an entity with a default architecture and allow the user to define an alternative architecture. The default would be just connecting the inputs to the output in a given order. That would allow users to handle "too many" interrupts or to otherwise implement customisations to the interrupt management.

One solution would be a platform interrupt controller like the RISC-V Core-Local IRQ Controller (CLIC).
But this would massively increase hardware complexity (especially when using the RISC-V CLIC)

I don't think it's worth. However, the use cases of NEORV32 might be extended to some higher-performance configurations (through the addition of floating-point, etc.). Therefore, in the future, it might make sense to have small and large variants of it. Similarly to the Microblaze setups.

In the current setup you can access the different UARTs by simply using different functions: neorv32_uart0_* for UART0 and neorv32_uart1_* for UART1. When having several UARTs one should use some kind of "handle" or device ID to address the right UART instead of providing explicit functions for every single UART. However, this is should not be a real problem.

I think the actual problem is how to let the software know about which parameters/generics were set in the hardware. This is related to the dialogue in #36. And it is also related to the "generation of a clean top-level" commented above.
You can define the parameter values in software only (and extract them for synthesis), in VHDL only (and extract them by parsing, or have synthesised registers containing metadata) or in some external file.
The usage of JSON-for-VHDL allows having a single source of truth for defining the generics/constants both in the hardware and in the software. However, Vivado has/had serious performance issues with JSON-for-VHDL. So, overall, any solution you pick which prevents duplications (potential non-sync) will be ok.

[stnolting]

I wrote the typical dummy CPU with an ALU, instruction decoder, data/code RAM, etc. in some course years ago.

Nice to hear that! Seems like we all have been there 😄

It is not possible to do a quick read-modify-write transaction. I would expect that penalty to be much lower in NEORV32, but it might be relevant.

Correct. There is a small additional penalty for direct (data) accesses. Furthermore, there is no data cache implemented yet making large data accesses take more time :(

Obviously, the scale in NEORV32 is very different, but I wonder if it makes sense to support a configurable number of external interfaces. My guess is that it's not valuable, because it would not provide a performance/area advantage over using an external crossbar interconnect for driving subnets.

I also thought about this. As you already said, adding more interface does not make sense (at least right now; that might change once the data cache is implemented).

Peripherals such as PWMs, DMAs, etc. can safely be placed in the external bus, because those are low-throughput components. I mean the required control throughput between the CPU and the component. However, UARTs, SPIs, etc. might need to have "direct access". I'm thinking about your investigation with regard to neopixel too.

Right. But even UARTs can get complicated when driving the Baud rate to the maximum. A DMA-based system would be great. This would relax data transfer timings for the NEOPIXEL interface, too. But this is also something that could be build "outside" of the NEORV32 processor.

Overall, it might be interesting to create a subdir with optional external modules.

Once upon a time, I had a project that also included Wishbone modules to create a custom SoC. But to be honest, I don't want to maintain all those components, too. I think it is better to use third-party IPs (as @JimLewis mentioned: https://github.com/slaclab/surf).

Moreover, creating a subdir of optional external components might open the door to hell 😆.

Absolutely! 😄

In the specific case of UART, which has a single bit in each direction, the records are not useful, so the natural solution is using an std_logic_vector. However, and this is a very important however, these "arrays of interfaces" do only need to be used in the system level. Inside the instances, you use them normally. At the board level, you can unpack the arrays for showing a "clean" external/top entity. Hence, the ugly part is probably having to generate the top-level entity based on the generic parameters.

I would prefer plain std_logic_vectors for all peripherals (UART, SPI, TWI, PWM, ...). Hence, you could define a generic to configure the number of UARTs (say IO_UART_NUM) and use that to configure the according entity signal (uart_txd_o : out std_ulogic_vector(IO_UART_NUM-1 downto 0);). Or maybe it would be "cleaner" to define a maximum amount of UARTs and use a static size of the according interface signal vectors.

I think the sensible solution is to connect all of them, if possible. Otherwise, show an error and tell the user to manually specify which interrupts are to be used and which are not. I did not look into the code, but I guess we could have an entity with a default architecture and allow the user to define an alternative architecture. The default would be just connecting the inputs to the output in a given order. That would allow users to handle "too many" interrupts or to otherwise implement customisations to the interrupt management.

Ok, I'm lost now 😅
So you mean assign the available IRQ resources of the CPU in some manner to the peripherals and if the number of peripherals somehow exceeds this resources just assert an error? 🤔

I think the actual problem is how to let the software know about which parameters/generics were set in the hardware.

Right now there are two mechanisms to allow software to discover the actual configuration of the generics.

• a read-only register inside the CPU provides flags for all implemented CPU extensions
• a read-only memory-mapped device (SYSINFO) provides all kinds of flags to tell if a certain peripheral is implemented (and how it is configured)

Of course it is up to the actual user to read these flags (via provided functions) before using certain peripherals. For example there is (in sw/lib/source/neorv32_gpio.c):

/**********************************************************************//**
 * Check if GPIO unit was synthesized.
 *
 * @return 0 if GPIO was not synthesized, 1 if GPIO is available.
 **************************************************************************/
int neorv32_gpio_available(void) {

  if (SYSINFO_FEATURES & (1 << SYSINFO_FEATURES_IO_GPIO)) {
    return 1;
  }
  else {
    return 0;
  }
}

This function extracts the according flag from the SYSINFO hardware module.

[umarcor]

I would prefer plain std_logic_vectors for all peripherals (UART, SPI, TWI, PWM, ...). Hence, you could define a generic to configure the number of UARTs (say IO_UART_NUM) and use that to configure the according entity signal (uart_txd_o : out std_ulogic_vector(IO_UART_NUM-1 downto 0);). Or maybe it would be "cleaner" to define a maximum amount of UARTs and use a static size of the according interface signal vectors.

All those peripherals have single bit signals. Hence, it's straightforward to extend them to vectors. However, when the interface itself has multi-bit signals, extending them by concating gets ugly easily. That's what records/interfaces are for. Anyway, I agree it's not worth that complexity for the serial interfaces, specially using VHDL <2019. I just wanted to explain that the VHDL language has modern and better features for dealing with this use case.

With regard to defining a fixed size, I don't think it's worth. You can always do that at the very top-level wrapper by using a resize.

Ok, I'm lost now 😅
So you mean assign the available IRQ resources of the CPU in some manner to the peripherals and if the number of peripherals somehow exceeds this resources just assert an error? 🤔

You have up to 16 IRQ lines, and you are connecting peripherals there automatically or hardcoded. Hence, you know how many of those 16 lines you are using and how many are free. If a variable number of UARTs is supported, you will have an offset because you now have n interrupt lines coming from that port (it's a vector) where there was one only. However, that n is known. Therefore, you can use a procedure/assertion for checking whether the number of lines exceeds. This is why using fixed size arrays is not good. They should be constrained by parameters or unconstrained. Then, you can get the 'length.

You can either assert an error or try writing some other logic for deciding which to leave unconnected. However, you need to communicate that to the software. Sometimes it's better to require some human intervention than trying to do everything automatically. Things such as customising IRQs or an address map are such tasks.

• a read-only memory-mapped device (SYSINFO) provides all kinds of flags to tell if a certain peripheral is implemented (and how it is configured)

This is interesting, because it's very similar to what @Paebbels does with version and JSON-for-VHDL.
So, the software is absolutely generic. There are no parameters read from the VHDL sources or from any other software header. Everything is read at runtime by accessing SYSINFO. Is that correct? Maybe the documentation is the only part that you do manually?

[stnolting]

All those peripherals have single bit signals. Hence, it's straightforward to extend them to vectors. However, when the interface itself has multi-bit signals, extending them by concating gets ugly easily. That's what records/interfaces are for. Anyway, I agree it's not worth that complexity for the serial interfaces, specially using VHDL <2019. I just wanted to explain that the VHDL language has modern and better features for dealing with this use case.

I agree. I would prefer simple vectors for all peripherals that can be replicated: UART, SPI, TWI, PWM, NCO, NEOLED

But I am not sure about those AXI stream links from #52. When talking about a single link: Would you prefer plain std_logic signals or a record type? How about using multiple links? An array of records?! When using Vivado, implementing those links as plain std_logic signals seems to be the only way to allow Vivado to "identify" those signals as one AXI stream port...

With regard to defining a fixed size, I don't think it's worth. You can always do that at the very top-level wrapper by using a resize.

👍

You can either assert an error or try writing some other logic for deciding which to leave unconnected. However, you need to communicate that to the software. Sometimes it's better to require some human intervention than trying to do everything automatically. Things such as customising IRQs or an address map are such tasks.

This is really the main argument I keep struggling with implementing a user-defined number of peripheral X. Making the user do the IRQ assignment is an overkill for beginners and also a huge source of intentional errors for advanced users. A straight forward mechanism, that is independent of the actual configuration and fully transparent for the software would be very nice - but I have no idea right now how to implement that.

This is interesting, because it's very similar to what @Paebbels does with version and JSON-for-VHDL.
So, the software is absolutely generic. There are no parameters read from the VHDL sources or from any other software header. Everything is read at runtime by accessing SYSINFO. Is that correct? Maybe the documentation is the only part that you do manually?

That is correct. We could add more version information to SYSINFO. The question is: what is really required? And which parts are placed in the software framework - i.e. including more specific version information (hashes?!) as some C struct.

[stnolting]

There is one more thing, that came to my mind...

I think I have already tried to address that (somewhere): Some peripherals like SPI and TWI are "multi-point" connections - so you can connect several/different slaves to the same port. Do you think these peripherals should be also available in a user-defined amount?

[JimLewis]

Have you looked at: https://github.com/slaclab/surf To see what you could reuse?

[umarcor]

surf is interesting, but as it is common with many similar projects, you need a very strong motivation and a few days (at least) for just starting to use it. It's a library which depends on their own build infrastructure, which is not shared by many other similar projects. In this case, it's specific for Vivado. The documentation is enough (maybe good) for the developers, and the users who have direct contact with them, but there is no "navigation" help for newcomers. Note that I'm not criticising this in their project only. It's a general problem we have in the open source hardware communities. For instance, PoC is similar. In that case, several open source tools and multiple vendors are supported. Unfortunately, it needs love. surf, PoC and others are good if you want to commit to using their ecosystem, but not easy for using just a few pieces standalone. It's possible, but not clear how to do it. If we had a single "HDL project management tool" which could undersand surf, PoC and others, that would make it much easier for all of us to share components.

[stnolting]

Have you looked at: https://github.com/slaclab/surf To see what you could reuse?

Thanks for the hint. I did not know that "library". I will check that out.

[Paebbels]

@stnolting multiple UARTs can be implemented with std_logic_vector :). No need for #ifdef or so.

Regarding CORDIC, this wuld be part of an FPU, right? No need for standalone CORDIC.

[stnolting]

multiple UARTs can be implemented with std_logic_vector :). No need for #ifdef or so.

Right. I also think that would be the most straight forward solution. 👍

Regarding CORDIC, this wuld be part of an FPU, right? No need for standalone CORDIC.

There already is an FPU in this project (as part of the Zfinx ISA extension). But that FPU can "only" do floating-point add/sub/mul/div/... so no native trigonometric operations.

[Paebbels]

But that FPU can "only" do floating-point add/sub/mul/div/... so no native trigonometric operations.

Do you refer to your implementation or the RISCV ISA is self, which forgot to define it?

[stnolting]

Do you refer to your implementation or the RISCV ISA is self, which forgot to define it?

Actually, I am referring to the IEEE 754 spec itself.
IEEE 754 does not list trigonometrics as required operations: https://en.wikipedia.org/wiki/IEEE_754#Required_operations

[Paebbels]

I think a backup from IEEE Std. 754 is not needed as it caring mostly about the format. It's to my knowledge not defining the algorithms how to compute something when using floating point numbers.

[stnolting]

It's to my knowledge not defining the algorithms how to compute something when using floating point numbers.

That's right. But it does say something about the operations (not the algorithms behind them) that shall be provided:

5.4.1 Arithmetic operations
Implementations shall provide the following formatOf general-computational operations, for destinations of
all supported arithmetic formats, and, for each destination format, for operands of all supported arithmetic
formats with the same radix as the destination format. These operations shall not propagate non-canonical
results.

• formatOf-addition(source1, source2)
  The operation addition(x, y) computes x + y.
  The preferred exponent is min(Q(x), Q( y)).
• formatOf-subtraction(source1, source2)
  The operation subtraction(x, y) computes x − y.
  The preferred exponent is min(Q(x), Q( y)).
• [...]

(reference: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjMoZD95f3wAhXugf0HHQ22CpsQFnoECAMQAA&url=https%3A%2F%2Firem.univ-reunion.fr%2FIMG%2Fpdf%2Fieee-754-2008.pdf&usg=AOvVaw36Ex4FT7fGoyV4ere8jIhP)

[agamez]

A small DMA peripheral would be really nice. There are some devices that are relatively high speed that would benefit from fast access to DMA, such as ADCs that are continuously streaming. A simple dual-buffer style DMA that would allow the user code to read from one slot while the DMA is transferring to the second slot in a circular fashion would be really great.

So maybe just a few registers to set slot A address and size, slot B address and size, an interrupt output and a few bits for control and status (which slot is actively being written to, enable/disable, etc).

The doubt is what should be the data input interface. Wishbone, axi lite? Is this similar to the old SLINK interface that existed a few versions ago and hence has the same conceptual problems it had?

[stnolting]

Hey @agamez!

I think a DMA would be a nice thing to have. I also thought about this in the past but I dropped the idea again because I could not see any relevant use case.

There are some devices that are relatively high speed that would benefit from fast access to DMA, such as ADCs that are continuously streaming.

These would be processor-external. Wouldn't a large FIFO buffer + "fill level interrupt" be more suitable in this case?

A simple dual-buffer style DMA that would allow the user code to read from one slot while the DMA is transferring to the second slot in a circular fashion would be really great.

The DMA transfers would still need to be initiated by the CPU, right?

So maybe just a few registers to set slot A address and size, slot B address and size, an interrupt output and a few bits for control and status (which slot is actively being written to, enable/disable, etc).

Sounds interesting 😉
So just a minimal DMA with many/one-to-many/one transfer options that is directly programmed (i.e. not a descriptor-based DMA)?

[agamez]

Hi!

Hey @agamez!

I think a DMA would be a nice thing to have. I also thought about this in the past but I dropped the idea again because I could not see any relevant use case.

It's not very often that we see DMA controllers in small SoCs, truth be told. And when it exists it's typically used in conjunction to other internal peripherals. For example, why use a FIFO for SPI/I2C when you can just leave your data where it is in memory and make them read the memory directly via the DMA? This only makes sense for high speed protocols, but maybe you want to run SPI on the hundreds of MHz, who knows...

Anyways, here is some random example of why using DMA with SPI is useful sometimes https://hackaday.com/2016/09/26/pic32-dma-spi/

There are some devices that are relatively high speed that would benefit from fast access to DMA, such as ADCs that are continuously streaming.

These would be processor-external. Wouldn't a large FIFO buffer + "fill level interrupt" be more suitable in this case?

Well, for a continuous stream, yes, that'd be the immediate solution. But a large FIFO is a lot of logic that you may not have available or that you are dedicating exclusively to this purpose. If I write directly to the DMEM, I can make this as large as it fits on my device and not care about partitioning of resources (how much logic should I dedicate to the FIFO? Doesn't matter, decide it upon software execution via DMA transfer size).

A simple dual-buffer style DMA that would allow the user code to read from one slot while the DMA is transferring to the second slot in a circular fashion would be really great.

The DMA transfers would still need to be initiated by the CPU, right?

In principle yes, but once setup, the DMA could be self sustaining, initiating the next transfer after the last has finished, so that would make it look like an infinite FIFO, provided the software is able to read each slot before the DMA overwrites its contents.

So maybe just a few registers to set slot A address and size, slot B address and size, an interrupt output and a few bits for control and status (which slot is actively being written to, enable/disable, etc).

Sounds interesting wink So just a minimal DMA with many/one-to-many/one transfer options that is directly programmed (i.e. not a descriptor-based DMA)?

The Xilinx DMA core allows two modes of configuration:

1. Single transfer mode: 1 control register, 1 status register, 1 source/destination address register, 1 length register. You just define how many data want to transfer and where it is, and an interrupt is raised when it's finished.
2. Scatter-Gather: the source/destination and length registers are replaced with a register with the address of a struct that define each the address and length of a DMA transaction and has a pointer to the next struct defining the next transaction, kind of a singly linked list describing DMA transactions. If you make the last struct point to the first one, you have a circular list that can work in continuous mode.

My proposal for the neorv32 would be a mix of them, to keep it simple. So instead of having just a single DMA transfer that must be triggered manually every time -and thus make you lose precious time-, the DMA core itself would allow the definition of two different transfers that can be set to swap from one to another, thus allowing continuous transfer.

This core could be used not only by external devices such as the ADC I mention, but also by the SPI/UART/(future ethernet) cores. Of course, it should be bidirectional and allow transfers from and to DMEM. But in the SPI and UART cases it should definitely not be the default, as the DMA core would probably use more logic than a small FIFO which is probably enough most of the time.

Truth be told also, even Xilinx' AXI ethernet lite does not use DMA and does a fine job with a small microblaze to run near to 100Mbps, so maybe it's all overkill anyway...

[stnolting]

I think this sounds very good. 🤔

Let's start a new discussion or (preffered) a new issue so we can discuss this more in detail (and maybe get some more feedback). What so you think?

[agamez]

Sure! Shall I do it or will you?

[stnolting]

For the records: -> #579

[cweickhmann]

Along the "arbitrary number of UARTs" argument, I found a use case where two SPIs would be nice: I happen to have a board here where all except one SPI-controlled chips are 4-wire, but one is 3-wire. It would be really nice if I could just get a second SPI controller and have that nicely separated hw wise, but use the same software on one MCU to get the job done.

If I wanted to try making a second SPI myself, is there a recommended place to start?

[stnolting]

I'm not sure what "3-wire" SPI actually means 😅 Do such devices share SDI/SDO as a single wire or do they omit the CS line?

If I wanted to try making a second SPI myself, is there a recommended place to start?

The simplest way would be to instantiate the existing SPI controller inside the custom functions subsystem (CFS). You could use the CFS interrupt for the secondary SPI interrupt and wire-up external devices using the provides CFS in/out conduits.

[cweickhmann]

That's what they said ;-) Yes, it's SDI/SDO on the same shared line.
Thanks for the heads-up! I hadn't worked my way down to CFS in the manual, yet.
Let me try that via CFS and - once I've got something to share - share it. Might take a while though.

[stnolting]

I'm still not sure how these 3-wire SPI things are supposed to work... However, I think you could use the default SPI module to also talk to 3-wire devices 🤔 This is what I would try:

NEORV32
----+
    |
SDO >----------------o-------|10k|------+
    |                |                  |
SDI <------------o---)------------------o
    |            |   |                  |
SCK >--------o---)---)--------------+   |
    |        |   |   |              |   |
CS0 >--------)---)---)----------+   |   |
    |        |   |   |          |   |   |
CS1 >----+   |   |   |          |   |   |
    |    |   |   |   |          |   |   |
----+    |   |   |   |          |   |   |
         |   |   |   |          |   |   |
      +--v---v---^---v--+    +--v---v---|---+
      | CSN SCK SDO SDI |    | CSN SCK SDIO |
      +-----------------+    +--------------+
      4-wire SPI device      3-wire SPI device

If you send a bunch of zeros to the 3-wire device the device's output driver should be able to drive the data line high (due to the 10k resistor) in order to send back data to the processor. I'm not sure if this would really work, but maybe it is worth a try 😉

[benjacam]

Hello, I'm just looking into FPGA soft CPUs for the first time and came across this repo which looks great - thank you!

I have a use case where I'm pairing a FPGA and MCU. The FPGA is performing some custom hardware acceleration tasks with the soft CPU assisting and doing some general housekeeping. The MCU (e.g. STM32) is running network stacks to connect the device to the cloud and has modern security features (secure boot, upgrade, trust zone etc).

I need a fast interface for control and bidirectional data transfers between the MCU and FPGA. UART/SPI/I2C are too slow. PCIe isn't available in this class of device. A parallel memory bus requires too many pins. An interface that is common in MCU peripheral sets is SD/SDIO - low pin count, high throughput, reasonably simple, standard CMOS I/O.

It would be great to have SDIO slave interface support in this soc. It would bridge between the sdio interface and the memory bus of the soc (either as another bus master, or perhaps using the DMA).

I appreciate this is quite a specific request for my particular use case, but I think it could be a useful option.

[stnolting]

came across this repo which looks great - thank you!

Thank you very much! :)

It would be great to have SDIO slave interface support in this soc.

I'm not too familiar with SDIO, but isn't that basically a bi-directional 4-bit SPI channel?
Furthermore, I fear that it might be non-royalty-free. 🤔

UART/SPI/I2C are too slow

Simple SPI at 16MHz (realistic for short PCB traces) already gives you 2MB/s. How much throughput do you need for your application?

[benjacam]

It would be great to have SDIO slave interface support in this soc.

I'm not too familiar with SDIO, but isn't that basically a bi-directional 4-bit SPI channel?

Yes, that's right, there's also a bidirectional CMD signal that is used for control and for setting up the data transfers.

JFYI, there are simplified specs here https://www.sdcard.org/downloads/pls/ the physical layer and sdio specs are relevant.

UART/SPI/I2C are too slow

Simple SPI at 16MHz (realistic for short PCB traces) already gives you 2MB/s. How much throughput do you need for your application?

I'm looking at using a 10MHz clock, in 4-bit DDR mode, so the raw bitrate is 80Mbps.

[benjacam]

Furthermore, I fear that it might be non-royalty-free. 🤔

Yes, unfortunately there is a membership fee and licensing fee to pay SD card organisation.

Looking further, there is the e.MMC standard now managed by JEDEC. The official spec is here https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf.
MMC is very similar to SD at the physical layer so MCU peripherals typically support both SD and MMC. Similar to USB, there is a fee to purchase a manufacturer ID from JEDEC. IMO, in a proprietary system this isn't really necessary. Other than that, I can't see any other licensing requirements.

[stnolting]

Unfortunately, that makes it also rather hard to implement for an open-source system 🙈