electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
go to the radio page Live at electro-music.com radio 1 Please visit the chat
poster
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Xilinx's MIG (Memory Interface Generator)
Post new topic   Reply to topic Moderators: State Machine
Page 1 of 2 [31 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: 1, 2 Next
Author Message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 06, 2011 2:29 pm    Post subject: Xilinx's MIG (Memory Interface Generator)
Subject description: looking for experienced user(s) ?
Reply with quote  Mark this post and the followings unread

Hi all, I've got several FPGA dev boards that have SDRAM on them that I would love to be able to use for effects like delay and reverb. I'm currently working with a Spartan-3E Starter Kit board which has a DDR SDRAM IC on board (I think it's 64 megabytes).

The Core Generator that comes with WebPACK ISE (13.1) has a MIG that supports the DDR SDRAM on the board. I've been able to find the generated files and one set includes something called a testbench. The testbench generates data and writes it to the SDRAM, reads it back and compares it to the original data. Mismatch of read and written data results in a LED turning on.

The problem (for me) is to understand how the testbench talks to the generated memory interface.

If anyone has used the MIG (from a recent version of ISE), I'd appreciate hearing about what you know.

Part of the problem is that the lines of code generated by the MIG aren't line commented and the object names use terse abbreviations. There are sparse comments only at the top of each of the modules. I'm trying first to understand how the testbench works so that I can then modify it to do what I want - namely, a simple hello-world project that writes 8 bytes to the RAM and then reads the data back from RAM to display in the LEDs.

Once I finish this, I will post what I've learned.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
thrakkor



Joined: Oct 06, 2011
Posts: 2
Location: USA

PostPosted: Thu Oct 06, 2011 10:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

The "testbench" module essentially sets up each burst transaction by driving the cmd bus, waiting for ack, driving adrs, burst done, driving data, waiting for refreshes, etc (and maybe not in that exact order)... oh and some things are done on different clock phases too.

I personally think it is a huge spaghetti mess.... makes me want to roll my own.

The other thing to note is that the "Virtex" flavor of MiG has a nice FIFO interface (data, wr/rd adrs FIFOs, IIRC) versus the crude Spartan version which makes the user do all their own rd/wr arbitration and handshaking with the MiG core controller...

The spartan flavor also uses combinatorial delays and has some crazy ucf stuff going on.

I much prefer a nice dual port QDR, just wish they were denser (and on the spartan 3AN eval boards).

I've compared the 10.1.03i and 11.1 versions and they look similar if not identical, other than the directory layouts changed.
maybe the virtex user interface could be adapted to the spartan flavor.....

hope that is somewhat helpful.
Back to top
View user's profile Send private message Visit poster's website AIM Address
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Oct 07, 2011 5:45 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks, that was helpful.

"Spaghetti" would be an apt description of what I see as well.

I was warned by someone else that trying to understand the MIG generated code will eventually cause insanity. I found that to be nearly true while I was looking at the code that actually talks to the RAM. So I stopped that and concentrated on just the user side of the interface.

I've pretty much worked out what you said regarding what it does, but the structure of the state machine and it's internal workings is a bit foreign to me. My designs tend to be a bit flatter than the MIG output because I hate going back and forth between different files to figure out what something is doing. And the use of both edges of the clock made my eyes cross a few times.

I've also got an audio recorder/playback project done by Rick Huang using an open source wishbone thing. In the long run, that might be a better solution, but Rick's code doesn't look much prettier than the MIG output. And again, looking at Rick's code, it's difficult to see where the data is read from the ADC and stored in the RAM or where the data is read from the RAM and sent to the DAC. I try to design my state machines in a way that makes things like that a bit more obvious (to me). I need to look at his code again from the standpoint of locating the user end of things.

I too would liked to have seen a more simple interface that hides the refresh abort requirements and just has in, out, in_strobe, etc. on the user side especially since my application will have extremely low performance requirements of the interface.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Oct 07, 2011 7:23 am    Post subject: Reply with quote  Mark this post and the followings unread

Looking at Rick Huang's code again, I notice that he's used code that is much older than what is currently available in open source.

I've gotten an email from another person who points me to this:

http://opencores.org/project,sdram_controller

which he says is an open source alternative to the MIG. So I will spend some time there and see what is available.

EDIT ADD: And of course, the project is in VHDL while I do Verilog. I will read about it and see if it will allow me to use it without having to read the code - since I can't at this time.

EDIT ADD: The opencores route, for me, is not an option. There is no documentation save what is in the comments which I find insufficient. Therefore, it's back to the ugly MIG again... [sigh]

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Oct 07, 2011 9:43 am    Post subject: Reply with quote  Mark this post and the followings unread

Back to the MIG output, I am starting by reformatting the code in a visually more pleasing way. This is helping me understand what the bits and pieces do.

I will be attempting to rewrite the testbench in a single file and using a coding style that fits with my previous projects. At the very least, moving the dependant modules into the testbench file will help when I need to find something in another module.

One of the problems I have, however, is that the testbench as delivered is basically a little memory diagnostic. It writes, reads, compares and moves on. If an error occurrs, then a LED turns on. If all is well, all LEDs stay dark. Assuming the RAM on the board is good, this isn't very useful to me, since if after I rewrite the code it is not functional and the LED never comes on - did it work ? or not ? I really would have preferred a more "looky-see" thing, like what I would like to do - a simple design that writes 8 different byte values to consecutive locations and then starts a loop to read them back at 1/2 second intervals and display the 8 bit values in the LEDs. For my tiny brain, this would make it easier for me to see that it is working.

EDIT ADD: As I come closer and closer to learning the truth, I find more ugliness. There is a 4 stage pipeline of registers that is never used. It looked as if it was to be filled with user data, but the end of the pipeline isn't connected to anything. So it appears that the testbench code was "thrown together" and was never reviewed for such things. This is, in my opinion, quite sloppy. But I will push forward...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
thrakkor



Joined: Oct 06, 2011
Posts: 2
Location: USA

PostPosted: Fri Oct 07, 2011 6:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

in regards to the 4 stage unused pipeline, i believe you can generate the core with or without this included.... but a 4 stage is required to meet timing etc if I remember the documentation correctly.

i found these 2 other DDR/DDR2 cores on opencores:

http://opencores.org/project,ddr2_sdram
http://opencores.org/project,ddr_sdr

not sure how well written as i have not untarred them yet...

the only opencores core i've successfully used was the CRC in a 10/100 interface...
Back to top
View user's profile Send private message Visit poster's website AIM Address
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Oct 10, 2011 2:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

I've made progress - I've reformatted and commented the code that was mysterious and copied it all to a new project where I am modifying the testbench pieces into my hello_world project.

One of the challenges is that the testbench code is set up to run continuously. I am attempting to add an enable signal so that I can trigger writes or reads at any address at any time. The hello_world code will write 8 bytes of RAM and then read them back at a visually slow rate to display in LEDs. I hope to have that working in a couple of day. The operative word there is "hope"...

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Wed Oct 12, 2011 6:46 am    Post subject: Reply with quote  Mark this post and the followings unread

Of course, the first test of the hello-world project failed. As I started troubleshooting, the first thing I noticed is that the data mismatch error LED indicator was routed to an FPGA pin that is connected to a PCB connector pin (with no LED attached).

This morning, I looked at ug230.pdf (User Guide for the Spartan-3E Starter Kit board) and discovered (not at all to my surprise) that the memory interface as generated doesn't connect to the RAM at all. So I will begin by editing the UCF file to conform to the reality of the board.

There may be a way to make MIG use an already established UCF file, but I don't know how that would be done. There is a place in MIG to tell it to do so, but when I tried, there were errors that I didn't know how to resolve. It may be that certain exact names of things need to be in the UCF so that MIG recognizes where the pin locations for the RAM are. For now, I will try editing the UCF file...

[sigh] I knew this would not be easy.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Wed Oct 12, 2011 3:38 pm    Post subject: Reply with quote  Mark this post and the followings unread

Well, I believe I've come to the end of my road with this.

What I've learned is that there is actually a basic problem with the design of the Starter Kit board. To do this correctly, there needs to be a loopback trace that connects two specific FPGA pins together with the loop being a certain length. This provides for accounting for the IO buffer propogation delay time associated with the data strobe so that the FPGA sees a data strobe that is certain to occur after the data is known to be asserted on the data bus. Early versions of the MIG included a way to connect LUTs together to make an "appropriate" delay. But Xilinx forum posts indicate that this doesn't work 100% of the time.

It would be nice if I could smoo the SDRAM timing, but that doesn't look easy at all.

The issue for me is that I'd like to add audio effects like reverb and/or delay using this RAM. But if I can't guarantee it will work for others who have this board, it's not too good.

Much of the point of this effort was to produce something that others could also use, whether simply downloading my projects or to design their own with the information.

I was also very disappointed with the "open" stuff I looked at. I found nothing that had documentation, just code. I kinda know what I'm doing with FPGAs, but I am not an expert and it seems to use open cores etc. one needs to be an expert.

[big sigh]

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
doitagain



Joined: Jun 01, 2011
Posts: 2
Location: usa

PostPosted: Thu Oct 13, 2011 6:06 am    Post subject: Reply with quote  Mark this post and the followings unread

I've been following your work for a while, nice work and I really appreciate your putting it out there for others to see.

I'm also attempting to get a mig design to work, in my case on the Avnet Spartan 6 lx9 micro-board. For as easy as Xilinx tries to make it, they have gone way wide of the mark.

I'm sure you are already going down this path but the easiest thing to do is to find a design that already implements the memory interface. It will probably have a project file with it so that you can load it up in ISE and see all of the interconnects that way. Unfortunately getting reliable designs with DDR RAMs does seem to take having some IP to do the delay calibration.

You probably don't need the traffic generator, I'll probably just set mine up so that I can peek/poke it over the serial interface.
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 13, 2011 6:34 am    Post subject: Reply with quote  Mark this post and the followings unread

Heh, well, I won't say this has been fun. I sort of understand why Xilinx creates the MIG output the way they do - I think that they want to produce an interface that can be high performance. But in that endeavor, there are ugly complications. It's too bad for me, I really don't need high performance. In my application, if I could get a reliable interface that transfers data at say 2 MHz, I'd be ecstatic. My intention was to build such an external interface that makes the SDRAM stuff look like a black box with a few signals like data_in, data_out, address_in, do_a_read, do_a_write and hiding all that ugliness of working with rising AND falling edges of clocks and quadrature clocks. And if this problem with the Spartan-3E Starter Kit board not having the calibration loopback is fixable by running the design at less than top speed - I wish they would do it. But Xilinx forum comments indicate that there is no incentive due to the fact that DDR is pretty much done. So unless one of us soldiers in the foxhole figures out how to do it, it's pretty much not gonna happen.

I agree about taking a working design and modifying it. In fact, I have a design by Rick Huang that is an audio recorder/playback using the RAM. He used open something other and made it wishbone compliant (which is, IMO, an unnecessary complication). But even if I can make it work, I can't guarantee that others with the same board will be able to use my designs. I may do it, just to see if I can... Rick's coding style is very different from mine, so deciphering the function from the alphabet soup will be the mountain to climb. It's not really a big deal, but one of the "problems" with Rick's design is that it doesn't use the whole RAM, only 4 or 8 megs of the 64 that are there. But I suppose that even a single megabyte would be a great resource for delay and/or reverb. And perhaps I can figure out where the restriction is and remove it.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 13, 2011 2:42 pm    Post subject: Reply with quote  Mark this post and the followings unread

Here is Rick Huang's widebus-recorder project. It's an audio record and playback design that uses the SDRAM on the Spartan-3E Starter Kit.

http://member.newsguy.com/~rhuang/FPGA/WideBus-Recorder.zip

The wishbone thing doesn't look too bad now that I dive in.

This project runs the SDRAM at 100 MHz which is slower than the max of 133 MHz. I was also mistaken about the RAM size, all 32 megawords (16 bit) are available in 4 banks of 8 megaword each. The project is very neat IMO, there doesn't seem to be any multi clock phase ugliness.

This looks the most promising of anything I've seen so I will try to make a hello-world out of this...

EDIT ADD: This project looks pretty good. The coding style turns out to be quite a bit like mine once I reformatted the text a bit. There's enough documentation in comments and pretty good object naming. I've already located most of the functional bits. Hoping to have a hello-world working in a few days. A nice two state section of a state machine labeled "CLEAR SDRAM" that does just that, making it quite clear how to use the interface. Basically, wait for idle state and send your command.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Fri Oct 14, 2011 2:31 pm    Post subject: Reply with quote  Mark this post and the followings unread

Another cool thing about this particular interface is it also has interfaces to the on board DAC and ADC - (both I believe are 50 MHz max SPI parts) - the interface provides the clocking to both SPI devices, yet the rest of the design runs at 100 MHz. I will now have an opportunity to work at 100 MHz instead of only 50 MHz.
_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sun Oct 16, 2011 9:32 am    Post subject: Reply with quote  Mark this post and the followings unread

I finally got a hello-world demo project running.

All it does is write 8 32 bit words to RAM in sequential locations, then goes into infinite read mode where it reads a byte, writes to a LED register and waits 0.25 seconds, increment address with wrap and do again.

The written pattern starts with 0x00000001 and after each write is left shifted. When played back, you see the illumination move leftward from LED 0 to LED 7, start over and repeat forever.

I tested this on 3 different Spartan-3E Starter Kit boards.

The basis for this project was Rick Huang's widebus recorder project.

Thank you Rick, wherever you are.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sun Oct 16, 2011 12:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

For those of you who have a Spartan-3E Starter Kit board and want to try this, you can get the source code here:

http://scott.joviansynth.com/FPGA_synth/SDRAM_hello_world.zip

Just source code. Nothing special about the project settings. I'm using
WebPACK ISE ver. 13.1

Most of the code is Rick's. I've replaced one of his state machines with
my own (in ctrl_FSM.v). I've reformatted the text to be more visually
pleasing to me and I've added comments to what Rick put there.

When first started, the LED readout will probably be incorrect. This is
because it needs to be reset (I didn't take the time to write an automatic
startup reset cycle). To perform a reset for this project, do this:

Press and hold down the rotary encoder pushbutton.
Press the south pushbutton and release it.
Relase the rotary encoder pushbutton.

A correct result will display one illuminated LED starting with the right
side. The illumination shifts left every 0.25 seconds. When the last LED
is illuminated, the process starts over and goes forever.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima

Last edited by JovianPyx on Wed Mar 18, 2015 10:51 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Tue Oct 18, 2011 2:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

I've been able to play data from SDRAM into the DAC. Today's little project was starting with a pre-initialized set of 4 block RAMs containing a sine wave cycle, copy the block RAM to SDRAM and play to the DAC from SDRAM.
_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Wed Oct 19, 2011 8:42 am    Post subject: Reply with quote  Mark this post and the followings unread

Next step is a real synthesizer using the DDR SDRAM for a large delay effect. This will require that the design operate as two sections of logic living in two different clock domains. Multiple clock domains is virgin territory for me.
_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 20, 2011 10:31 am    Post subject: Reply with quote  Mark this post and the followings unread

Here's another tidbit of information that may come in handy for others:

On another forum that deals with FPGA synthesizers, I was seeking opinions on how to move forward with a synth project that uses the SDRAM for an audio effect. My point was that I had synths that run at 50 MHz or less and said that was mainly because the PicoBlaze soft microcontroller I use for a MIDI controller is spec'd to run at 50 MHz (25 MIPS). Note that the SDRAM has a lower clock limit of about 77 MHz so to use the SDRAM with a 50 MHz synth, clock domains would be crossed.

Someone responded that the top clock speed of 50 MHz isn't necessarily true. So I tried a simple hello-world project I had done before, but goosed it up to 100 MHz. Sure enough, he was correct, it compiled without timing constraint violations and it does indeed work. The slack time was 0.124 nS.

So I've been encouraged to attempt making the whole synth work at 100 MHz so that interfacing with the SDRAM controller doesn't require crossing clock domains.

EDIT ADD 2015-03-18:
I'm not sure if I added this note elsewhere, but it bears posting now that I see it again in print.

The idea of using PicoBlaze at 100 MHz works only under very constrained conditions. What I discovered was that PicoBlaze will work at 100 MHz when there is almost nothing else in the FPGA design. Once a bunch of complex logic is connected to the PicoBlaze module, it is no longer capable of operating at 100 MHz. 50 MHz is a reliable figure that can be used in designs that max out the real estate of the FPGA.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima

Last edited by JovianPyx on Wed Mar 18, 2015 11:41 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
doitagain



Joined: Jun 01, 2011
Posts: 2
Location: usa

PostPosted: Thu Oct 20, 2011 10:46 am    Post subject: Reply with quote  Mark this post and the followings unread

That would be great to be able to run at 100 MHz, but as long as you are using one of their PLLs to generate 100 and 50, the domains are still in sync and all you have to do is account for the 2x speed up/slow down. I haven't looked at the code you are using but for the Spartan 6, the MIG takes care of the memory and user clocks being different internally.

I'm glad to see the progress you are making. After about 3 weeks of putting an hour or two a day on it, I've finally gotten the lx9 microboard to compile and be timing clean for a MIG generated design. In the end, it wasn't anything complicated, just a matter of wading through all of their documentation and source code for the 4 or 5 things that needed to be changed in the generated code.

Of course, I still need to code something to test it and don't really expect it to work....
Back to top
View user's profile Send private message
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 20, 2011 11:26 am    Post subject: Reply with quote  Mark this post and the followings unread

Well, the main reason I'm doing this is that it's easier to work in a single clock domain as opposed to multiple clock domains.

While the DCM in the 3E can produce 50 MHz and 100 MHz required in sync, there still would be extra clock enables so that the correct rising edge is used when exchanging data across the domain barrier.

Additionally, at 100 MHz (as opposed to 50 MHz) and the same sample rate, it's more than possible to add more features and/or more voices.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Thu Oct 20, 2011 3:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

And I discover the caveat.

PicoBlaze works to 100 MHz in a very simple usage of it. When I tried to goose up a synth from 50 MHz to 100 MHz, I quickly found that additional logic (which complicates place and route) has an obvious affect on timing. I got it barely working at 80 MHz, but there are problems using 80 MHz with the SDRAM (clock jitter mainly). From what I see, the only clock rate possible with this board (Spartan-3E Starter Kit) is 100 MHz due to the way the DCMs are used.

So I'm back to 2 clock domains where only the SDRAM interface runs at 100 MHz and the rest at 50 MHz.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sat Oct 29, 2011 5:39 pm    Post subject: Reply with quote  Mark this post and the followings unread

I got it working

I have the DDR SDRAM interface servicing a 16 second (max) looped delay effect on an FM bell synth.

Samples yes, to come - I post this as I _just_ got it working.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Sun Oct 30, 2011 2:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Here is a sample. It is flawed in that I need to put binary wrap protection to clip instead of wrap, so there is a pop that will repeat because it was part of the input to the delay loop.

The sound is a capture after I had played with the synth using 3 different FM settings from sweet bells to cymbals and then chimes. So there's a lot of sound in the loop. Delay time setting was maxed at a hair over 16 seconds, feedback amount was 93%.

Radio People: I would ask please not to use this on the radio - it's flawed.


SDRAM_Delay_FM_Bell_Demo.mp3
 Description:
FM Bell Synth with DDR SDRAM Delay Effect

Download
 Filename:  SDRAM_Delay_FM_Bell_Demo.mp3
 Filesize:  1.42 MB
 Downloaded:  1409 Time(s)


_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Oct 31, 2011 8:18 am    Post subject: Reply with quote  Mark this post and the followings unread

Source code for synth and patch editor:

http://jovianpyx.dyndns.org:8080/public/FPGA_synth/FM_Bell_SDRAM_Delay_ver_k.zip

EDIT ADD: A WORD OF CAUTION ...

This code is still a little raw. When the delay time is expanded, it will likely expand into random data (noise) or old data. It can wake you up if you have the volume level high. I first turn feedback amount to 0% then change the delay time. After doing this, you must wait for the 0% setting to "clear" the SDRAM. After it's been silent for more than one (new) total delay time, it's safe to put feedback percent up where you want it.

I will have to come up with a better way, but for now, that's the workaround.

_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
JovianPyx



Joined: Nov 20, 2007
Posts: 1988
Location: West Red Spot, Jupiter
Audio files: 224

PostPosted: Mon Nov 07, 2011 6:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

I've created what I would call a low performance general purpose interface to the DDR SDRAM using code from Rick Huang's widebus-recorder project and my own changes and additions.

From Rick, I got the actual DDR SDRAM interface, the bits that actually talk to the integrated circuit and a state machine which accepts and performs read and write commands.

What I added are several state machines which allow DDR SDRAM data to cross between a 50 MHz domain and a 100 MHz domain and a state machine that implements a mono 16 bit looped delay effect.

The 100 MHz domain is for the DDR SDRAM environment. The 50 MHz domain is, in my case, for the synthesizer hardware. I do this because there is a practical limit to the clock rate at which the PicoBlaze microcontroller can run, that being 50 MHz for a rather complex system. For all of the synth electronics to run with PicoBlaze (as a MIDI controller), it was easiest to cross the clock domain boundary for the SDRAM. I could have moved the synth electronics to the 100 MHz domain and leave only PicoBlaze in the 50 MHz domain, but that seemed like a lot of work for synths that already do what I want them to.

I refer to this as a low performance interface because I use full handshake in communication across the clock domain boundaries. From what I can see in the docs, my access time can't be any longer than 10 clocks at 50 MHz per SDRAM operation. To that are added a few clocks (3 I think) for the handshaking for 13 clocks at 50 MHz per SDRAM access. I haven't backed any of that up with measurements, but I plan to do that. If that is true, I can plan on about 58 SDRAM accesses per sample time at 65 kHz. Each of those accesses is a 32 bit operation. So as you can see, it's not screaming fast. Since the two clock domains are actually synchronous, one could probably figure out how to reduce the handshaking overhead. One of the reasons for the lack of performance is that that interface uses a burst size short enough that an SDRAM transfer never needs to be interrupted in order to comply with a refresh request, so that hardware doesn't need to be there. This simplifies things, but is a performance hit. It's not horrible though, each SDRAM transfer delivers 4 bytes, so 16 bit stereo is easy.

Regardless of what might make it better, this thing works so I'm posting a zip with the code and some notes.

state_machines.v.txt contains snippets of code that can actually be copied and pasted into your own code. This is a "use at your own risk" sort of thing... The system is pipelined at the DACena level, that is, each processing stage shifts it's pipeline at DACena. So the delay effect is one sample behind the synth output and the DAC output is a sample behind the delay effect.

The .v files need to be added to the project. References to these modules are in state_machines.v.txt.

Note that this is designed for the Spartan-3E Starter Kit board.

Note also that the files in the zip are not a complete project.


DDR_SDRAM_INTERFACE.zip
 Description:
Files for the DDR SDRAM interface

Download
 Filename:  DDR_SDRAM_INTERFACE.zip
 Filesize:  17.31 KB
 Downloaded:  835 Time(s)


_________________
FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.
Fruit flies when you're having fun.
BTW, Do these genes make my ass look fat?
corruptio optimi pessima
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: State Machine
Page 1 of 2 [31 Posts]
View unread posts
View new posts in the last week
Goto page: 1, 2 Next
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » Microcontrollers and Programmable Logic
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use