epsilon

Hello,

I've been experimenting with one bit DAC recently to get a very easy way to output sound from the Basys3.

So, here it is.
It uses a 100MHz clock (even if the output one bit modulation is 12.5MHz).
The input is 20 bit.
The output bit is meant to be sent directly to a physical port.

Before going Verilog I experimented it in a Java benchmark to check stability
- the first integrator u is leaky ( hence the - (u>>>3) ) to limit chaotic behavior for low level sounds.

This is not an intent to replace a genuine converter.
But I think it can be handy if you don't have one at hand and want to experiment with sound generation.

 
`timescale 1ns / 1ps ////////////////////////////////////////////////////////////////////////////////// // Engineer: Thierry Rochebois // // Create Date: 22.12.2021 10:31:45 // Module Name: DAC // Description: A second order one bit audio DAC. // inputs: clk 100 MHz clock // in 20 bit signed input // (can be refreshed at a rate up to 200kHz) // output: out 1 bit out modulated at 12.5MHz // // Dependencies: NONE // Revision 0.01 - File Created // Additional Comments: // ////////////////////////////////////////////////////////////////////////////////// module DAC( input clk, // 100MHz clock input signed [19:0] in, // input (update rate up to 200kHz) output reg out // one bit out modulated at 12.5MHz ); reg signed [2:-21] x = 24'b0; // input cast to q3.21 reg signed [2:-21] u = 24'b0; // first integrator reg signed [2:-21] v = 24'b0; // second integrator wire signed [2:0] y; // output for feedback q3.0 -1 or +1 always @(posedge clk) begin x <= {{4{in[19]}}, in}; // 20 bit input -> q3.21 [-0.5 0.5[ end // 1/8 counter -> 12.5MHz reg [2:0] cpt8; always @(posedge clk) begin cpt8 <= cpt8 - 1; end // for feedback -1 q3.0 +1 q3.0 assign y = (v > 0) ? 3'b111 : 3'b001; wire signed [2:-20] s1; wire signed [2:-21] s1h; assign s1 = {x[2:0] + y, x[-1:-20]}; assign s1h = {s1[2], s1[2:-20]}; wire signed [2:-20] s2; wire signed [2:-21] s2h; assign s2 = {u[2:0] + y, u[-1:-20]}; assign s2h = {s2[2], s2[2:-20]}; // 100MHz / 8 = 12.5MHz for the 1 bit DAC always @(posedge clk && (cpt8 == 0)) begin u <= u + s1h - (u>>>3); // first integrator with feedback v <= v + s2h; // second integrator with feedback out <= v[2]; // output end endmodule
Here is an example with some triangle waves :
 

I integrated the VERA (Versatile Embedded Retro Adapter) core into BoxLambda: https://epsilon537.github.io/boxlambda/integrating-vera/

Hey all, quick update on this interface's progress.
tl;dr: I've made a change to the PHY component of this interface, and, in my testing at least, it is now possible to communicate with the DDR3 chip at much higher frequencies than MIG allows. My Spartan chip "only" allowed me to test up to 928 MT/s, where communication was still robust.
After some thinking, tinkering, and testing, I've come up with a solution to the clocking instability at higher frequencies. I still don't have proper timing constraints, but the problem before seemed to be an obvious delay between the address and command lines that were routed from the logic to an output buffer directly, and the data bus (DQ, DQS, DM), which was processed through OSERDES. The trick I've employed now, at a slight cost to FPGA area usage and write/read latency for the end user, is to route all of the mentioned signals (cmd/addr/data) through OSERDES.
As far as I'm aware, the IO blocks manage data transfer from the slow logic clock domain to the fast memory clock domain themselves, and the external lines, clocked by the fast clock, are inherently in sync. Relying on this seems to work well: I've done some testing by raising frequencies, but I hit a stop at the maximum BUFG frequency of my Spartan 7, 464 MHz, at which point my controller still works. For reference, Xilinx's MIG only works up to 333 MHz. How's 40% for a sequential performance increase? :)
Write leveling is still impossible, so using more than one SDRAM chip is out of the question, The DQ lines in a multi-chip arrangement go to each chip individually, but the command bus employs a fly-by topology, introducing skew. I'm not too worried about this, as the MIG IP on my Spartan doesn't use write leveling, either.
That's all from my end, at least for the time being. Anyone reading this is of course welcome to contribute, ask, test etc. If you happen to have a faster 7 series FPGA connected to a DDR3 chip, and are willing to do some testing at higher frequencies (1066 or even 1333 MT/s), please do let me know.
 
Edited to add: While the interface seems to work at 928 MT/s, this means that the bus frequency is 464 MHz, and, because the interface has a 2:1 PHY to logic clock ratio, this means the internal logic runs at 232 MHz. Designing (top) modules that run at this frequency on a -1 speed grade Spartan 7 is not trivial. For example, a 128 bit comparator will fail timing at this frequency unless pipelined. There are 3 solutions to this that I can think of, listed here in what I deem to be increasing difficulty/complexity: (1) Simply pipeline your design where it meets with the interface's high frequency. (2) Employ one of many CDC techniques, such as an asynchronous FIFO, to enable your modules to run at different frequencies than the interface. (3) Kindly ask Xilinx to provide us the documentation for the SERDES primitives in the "MEMORY-DDR3" mode, as currently this mode is not supported, and is the only one that will result in a 4:1 PHY to internal clock ratio.
I've seen that there is a company called Xylon that sells a DDR3 interface for 7 Series devices that operates with a 4:1 clock ratio, but the license for that is 3500 € yearly, the delivered product is just encrypted VHDL, there are no reviews I could find of it, and it is still twice as large as my own work.
I also remember a user on here asking about running MIG on an Arty S7-25 board and having had difficulties due to the IP core's FPGA area usage. I hope that it isn't against some unwritten rule of forum bon ton to tag @Mathias despite their inactivity.

Hi,
This is my attempt at building an alternative controller to Xilinx's MIG. Its FPGA utilization is much lower than MIG's, and it enables support for DDR3's optional "DLL disabled" mode, for frequencies <125 MHz. It also enables read calibration, which, according to my research, is rare for a custom/open-source memory core.
I haven't checked the datasheets of other FPGA parts, but the primitives used in this core (SERDES, IDELAY) should be generic to the entire 7-Series lineup, so there is wide use case potential.
There are some limitations to how well a custom controller may be built. In my testing, the controller runs faultlessly at 125 MHz, with sequential read speeds effectively reaching 444 MB/s. A more exhaustive readme file is available in the github repository: https://github.com/someone755/ddr3-controller
Any comments or contributions are welcome :)
--jb

Hi all,
All while ago, I started BoxLambda, a Blog and open-source project with the goal of creating a retro-style FPGA-based microcomputer. The microcomputer serves as a platform for software and RTL experimentation.
https://epsilon537.github.io/boxlambda/
https://github.com/epsilon537/boxlambda/tree/develop
Does the world need another retro-style computer? Probably not, but I do. I’m a software engineer and I’ve been studying FPGA development for more than a year now, specifically for this project.
BoxLambda is a system-integration project. There's very little from-scratch RTL development. The project is mostly about studying relevant GitHub projects (CPU, graphics, sound cores etc.) and bringing them into the BoxLambda SoC.
Since the project is based on Digilent's Arty and Nexys A7, I thought some of the folks on this forum might find it interesting.
Recently, I've been working on setting up OpenOCD JTAG Debug access for BoxLambda:
https://epsilon537.github.io/boxlambda/hello-debugger/
Let me know what you think.
Cheers,
Epsilon.

Hi all,
All while ago, I started BoxLambda, a Blog and open-source project with the goal of creating a retro-style FPGA-based microcomputer. The microcomputer serves as a platform for software and RTL experimentation.
https://epsilon537.github.io/boxlambda/
https://github.com/epsilon537/boxlambda/tree/develop
Does the world need another retro-style computer? Probably not, but I do. I’m a software engineer and I’ve been studying FPGA development for more than a year now, specifically for this project.
BoxLambda is a system-integration project. There's very little from-scratch RTL development. The project is mostly about studying relevant GitHub projects (CPU, graphics, sound cores etc.) and bringing them into the BoxLambda SoC.
Since the project is based on Digilent's Arty and Nexys A7, I thought some of the folks on this forum might find it interesting.
Recently, I've been working on setting up OpenOCD JTAG Debug access for BoxLambda:
https://epsilon537.github.io/boxlambda/hello-debugger/
Let me know what you think.
Cheers,
Epsilon.

Hi all,
All while ago, I started BoxLambda, a Blog and open-source project with the goal of creating a retro-style FPGA-based microcomputer. The microcomputer serves as a platform for software and RTL experimentation.
https://epsilon537.github.io/boxlambda/
https://github.com/epsilon537/boxlambda/tree/develop
Does the world need another retro-style computer? Probably not, but I do. I’m a software engineer and I’ve been studying FPGA development for more than a year now, specifically for this project.
BoxLambda is a system-integration project. There's very little from-scratch RTL development. The project is mostly about studying relevant GitHub projects (CPU, graphics, sound cores etc.) and bringing them into the BoxLambda SoC.
Since the project is based on Digilent's Arty and Nexys A7, I thought some of the folks on this forum might find it interesting.
Recently, I've been working on setting up OpenOCD JTAG Debug access for BoxLambda:
https://epsilon537.github.io/boxlambda/hello-debugger/
Let me know what you think.
Cheers,
Epsilon.