FPGA VGA Controller for 8-bit computer

[pcprogrammer]

We'll see if sending CMD7 and CMD16 again before each WRITE improves anything - hopefully might be able to work on this tomorrow a little more.

I think a better approach is to have a separate initialization module that is only called once. At the end of initialization it should leave the card in a deselected state.

Then before reading select the card with the 7 command, do the read (single block or multiple block as needed) and deselect the card at the end. Do the same for the writing. The setting of the block size with command 16 only needs to be done in the initialization.

[nockieboy]

I think a better approach is to have a separate initialization module that is only called once. At the end of initialization it should leave the card in a deselected state.

Then before reading select the card with the 7 command, do the read (single block or multiple block as needed) and deselect the card at the end. Do the same for the writing. The setting of the block size with command 16 only needs to be done in the initialization.

Yes, sounds like a better idea.  I've been wanting to separate the initialisation from the read transaction in the original SDReader module - now is a good time to do that optimisation.

[nockieboy]

I think a better approach is to have a separate initialization module that is only called once. At the end of initialization it should leave the card in a deselected state.

Then before reading select the card with the 7 command, do the read (single block or multiple block as needed) and deselect the card at the end. Do the same for the writing. The setting of the block size with command 16 only needs to be done in the initialization.

That's done - I haven't created a separate module, I've just made SDReader a little smarter so that it will initialise or read as required by the host.  Working nicely.  Back to working on SDWriter now.  Have a couple of bugs to fix since modifying the HDL to pre-select and de-select the SD card around the write transaction.

[nockieboy]

I've been picking away at the WRITE transaction, fixing little timing errors here and there and sorting out the CRC calculation.

I'm now at a stage where I'm getting the correct CRC transmitted for the test block I'm writing - 512 bytes of 0xFF.  The CRC for this test payload is 0x7FA1, as you can see from the SignalTap trace below:



The shaded-blue area is the CRC being written to the SD card.  Each vertical blue line is a bit of the CRC - feel free to check those bits, but the value written should be 0x7FA1.  The next bit written is the STOP bit (not marked), immediately after the CRC value.  Then immediately after the STOP bit is written on the rising clock edge of SD_CLK (1x 125MHz clock after, to be precise), SD_D0_DIR goes LOW to read from the SD interface.

According to everything I've read and seen in HDL elsewhere, the SD card should respond in 2 SD clocks with a CRC response.  I'm getting nothing back and the HDL is timing-out the transaction after a further 1,000 SD clocks, waiting for the SD card to pull DAT0 low to signify the start of its response byte.

In my SDWriter module, 512x8 bits are written, plus the 16 CRC bits, the start bit and stop bit for a total of 4,114 bits.  Am I missing something out?

Looking at the HDL for the sd_data_serial_host module used in the previous IP core I tried, it sends 512x8 + 8 bits for the payload.  What are the additional 8 bits for?  When I look at the end of the WRITE transaction in SignalTap for my HDL, it's sending the last byte fine, so I can't see what the additional 8 bits are for?  Anyone have any ideas?

[BrianHG]

Ok, here we go nockieboy, v1.6, final test.

I set it to 400MHz Quarter - rate.  It also now appears to work at 500MHz.
Now, remember, the CMD_CLK is now 100MHz, not 150MHz.
(125MHz when you set the DDR3 to 500MHz)

Note that you can achieve 2 x 32bit 1080p windows with the DDR3 set to 500MHz.  Please test the Z80, Geometry, and VGA window functions and report back.  I believe everything should work.

Also, be careful as your old 'BrianHG-DDR3-Controller' folder needs to be flushed as the DDR3 v1.6 has many changes.  The xxx.sdc, xxx_top.sv files, and 'BrianHG_DDR3_GFX_source_v16' folder have also changed.

Let me know how it goes.

[nockieboy]

Ok, here we go nockieboy, v1.6, final test.

I set it to 400MHz Quarter - rate.  It also now appears to work at 500MHz.
Now, remember, the CMD_CLK is now 100MHz, not 150MHz.
(125MHz when you set the DDR3 to 500MHz)

Note that you can achieve 2 x 32bit 1080p windows with the DDR3 set to 500MHz.  Please test the Z80, Geometry, and VGA window functions and report back.  I believe everything should work.

Also, be careful as your old 'BrianHG-DDR3-Controller' folder needs to be flushed as the DDR3 v1.6 has many changes.  The xxx.sdc, xxx_top.sv files, and 'BrianHG_DDR3_GFX_source_v16' folder have also changed.

Let me know how it goes.

Preliminary testing has thrown up no problems so far.   I haven't gotten around to testing the window functions yet, but so far all stress-testing of the Geometry unit is looking good with no errors.

[nockieboy]

SD WRITE update.

Still getting no response from the SD card when I try to write a block to it.  When the write times-out waiting for a CRC response from the SD card, it now sends CMD13 to get the card's status.  Below is the SignalTap trace of that response, plus some labels to save anyone having to decode the response:



According to the specs, CSD_OVERWRITE means this:



Not sure what that means exactly, or how I can fix it.  Any ideas, @pcprogrammer?

EDIT: If it matters, I'm trying to write to Sector 3.

EDIT2: I've tried a different SD card as well - exactly the same response/error bits reported.

[pcprogrammer]

@nockieboy: Hi, I'm willing to help you, but do not know a lot about the low level workings of SD cards. I did the code for the 1013D as part of the reverse engineering and learned a bit about the commands.

To get a bit deeper I just soldered a bunch of wires to my 1013D and hooked up my Rigol MSO5074 as a logic analyzer. I made a single capture on 5ms time base but it still looks to short for a full write to sector 3.

I connected the 1013D to my PC and started a USB mass storage connection with it. This way I can write a single sector with the linux dd command.

Have to look into the data but it looks like the system runs into a lot of wait time with the clock running and D0 being low. Needs a bit more playing to figure things out.

Edit1: Changed the time base to 50ms and the sample memory to 100MB. Sample rate is then 200MSa/s, which should be enough. The full transaction is now captured. It yields a binary file of 50MB so no posting here unless it compresses very well. Attached is a picture saved on the Rigol.

Edit2: I zoomed in on the first activity of the signals and wonder if it is correct. D4 is the command line and D5 is the clock line. The data lines are all high. Also added the .csv export form the scope. The lower 6 bits of the hexadecimal entries are the signals. Pre trigger the clock is low and the command and data lines are high.

[nockieboy]

@nockieboy: Hi, I'm willing to help you, but do not know a lot about the low level workings of SD cards. I did the code for the 1013D as part of the reverse engineering and learned a bit about the commands.

To get a bit deeper I just soldered a bunch of wires to my 1013D and hooked up my Rigol MSO5074 as a logic analyzer. I made a single capture on 5ms time base but it still looks to short for a full write to sector 3.

Thanks so much for doing this - I really appreciate it.  I'd love to get my hands on a working write trace so I can see exactly what is going on with the bit count etc.

I connected the 1013D to my PC and started a USB mass storage connection with it. This way I can write a single sector with the linux dd command.

Have to look into the data but it looks like the system runs into a lot of wait time with the clock running and D0 being low. Needs a bit more playing to figure things out.

I can explain that.  A write transaction should go something like this:

1) Host sends CMD24 with sector address in the ARGUMENT.
2) SD responds with R1 response
3) Host sends START bit, a block of data (512 bytes), a 16-bit CRC and STOP bit.
4) SD responds with a CRC response (R1, I think) and pulls D0 LOW to signify that it's busy whilst it erases the sector and writes the new data to it.
5) Once the SD has finished writing, it releases D0 and can respond to further commands.

So what you're seeing is normal behaviour - the pause with nothing happening is whilst the SD card writes the new block of data to its addressed sector.

[pcprogrammer]

Thanks so much for doing this - I really appreciate it.  I'd love to get my hands on a working write trace so I can see exactly what is going on with the bit count etc.

You are welcome, and the full capture is attached in the previous post. It is a .csv file instead of the binary, which looks a bit weird. The .csv one shows the bits in a hex value, and the first line specifies the sample time.

I can explain that.  A write transaction should go something like this:

1) Host sends CMD24 with sector address in the ARGUMENT.
2) SD responds with R1 response
3) Host sends START bit, a block of data (512 bytes), a 16-bit CRC and STOP bit.
4) SD responds with a CRC response (R1, I think) and pulls D0 LOW to signify that it's busy whilst it erases the sector and writes the new data to it.
5) Once the SD has finished writing, it releases D0 and can respond to further commands.

So what you're seeing is normal behaviour - the pause with nothing happening is whilst the SD card writes the new block of data to its addressed sector.

I was that thinking it had to be something like that, but the wait times seemed long

I'm also looking at the SD card specifications and wonder a bit about the CRC on the data line(s). I think you have to calculate them separately per line, which means creating dedicated buffers or do the calculations on the fly. With multiple data lines the bits have to be distributed on a nibble basis, according to the picture.

It is not a simple system and I'm glad the F1C100s has a dedicated peripheral for it

[nockieboy]

Edit1: Changed the time base to 50ms and the sample memory to 100MB. Sample rate is then 200MSa/s, which should be enough. The full transaction is now captured. It yields a binary file of 50MB so no posting here unless it compresses very well. Attached is a picture saved on the Rigol.

Edit2: I zoomed in on the first activity of the signals and wonder if it is correct. D4 is the command line and D5 is the clock line. The data lines are all high. Also added the .csv export form the scope. The lower 6 bits of the hexadecimal entries are the signals. Pre trigger the lock is low and the command and data lines are high.

If it makes it easier, I don't need to see all of the data lines (D0-D3) - what I really need is the SD_CLK line, CMD line and D0.  If you trigger on D0 going low, that should get the transaction from start to finish, but I need enough resolution so that I can use the clock to decipher what is going on.

You are welcome, and the full capture is attached in the previous post. It is a .csv file instead of the binary, which looks a bit weird. The .csv one shows the bits in a hex value, and the first line specifies the sample time.

I'll have to work on decoding that. 

I'm also looking at the SD card specifications and wonder a bit about the CRC on the data line(s). I think you have to calculate them separately per line, which means creating dedicated buffers or do the calculations on the fly. With multiple data lines the bits have to be distributed on a nibble basis, according to the picture.

Yes, a separate CRC is required for each data line.  Whilst I'm developing the module, I'm working solely in 1-bit mode.  Once I've gotten that working, I'll upgrade it to 4-bit mode which won't take much effort at all - I'm working on the hard part at the moment.   I'm calculating the CRC on the fly, per data line (of which there's just one currently).

[pcprogrammer]

The trigger was set on the clock line. I looked at the clock speed and it looks low. Only 2MHz or so, were I recall it being set a lot higher in the software. Also not sure which commands are send in the whole transaction being done with the linux dd option.

It was a bit of a spur of the moment action I had been thinking about it before, but with your post asking for help I thought lets go and solder some wires and hook up the scope.

Doing a single data line involves more work, because the software needs to be changed then, so hopefully the given capture is good enough to get you going.

D0 is the lsb in the captured data. CLK is bit 5. CMD is bit 4.

Edit: Here is a capture of the startup of the SD card. For the first commands it only uses the single data line.

[nockieboy]

Doing a single data line involves more work, because the software needs to be changed then, so hopefully the given capture is good enough to get you going.

No no, don't change your software or anything.  I don't need to see complete bytes - really all I need is every clock in the write transaction and D0 as that includes the START and STOP bits, so don't worry about changing over to 1-bit mode or anything!

EDIT:  D0 is the most important data line, as it signals the start and end of the transaction, as well as the CRC for the data it has transmitted.  D1-3 are just data lines with their CRC at the end, nothing else, so I don't need those.

[pcprogrammer]

I think there is a speed problem. I'm looking at the startup sequence an can see that the clock is slower in the beginning, which is correct, but when it switches to 4 line mode the clk and cmd line seem wrong in relation to each other.

I did not see a signal diagram in the specification on how the clock and the command line relate so it is a bit phishing in the dark

Edit: I will connect a normal probe to the clock line and try to figure out what is going on. It could be that the threshold level is to high. Currently set to 1.8V.

[nockieboy]

I think there is a speed problem. I'm looking at the startup sequence an can see that the clock is slower in the beginning, which is correct, but when it switches to 4 line mode the clk and cmd line seem wrong in relation to each other.

I did not see a signal diagram in the specification on how the clock and the command line relate so it is a bit phishing in the dark

The clock dictates the speed of the CMD line and the DAT lines.  The SD card (and host) reads the value of the CMD line or DAT lines on the rising edge of the clock, so the data/CMD lines must coincide with the clock's rising edges to represent meaningful data.  That last image you posted of your oscilloscope trace didn't seem to have a valid signal on it, if either of the two lines displayed was the clock line.  Are you sure it's hooked up correctly?  Presumably Linux is reading/writing the SD card okay?

[pcprogrammer]

I think there is a speed problem. I'm looking at the startup sequence an can see that the clock is slower in the beginning, which is correct, but when it switches to 4 line mode the clk and cmd line seem wrong in relation to each other.

I did not see a signal diagram in the specification on how the clock and the command line relate so it is a bit phishing in the dark

The clock dictates the speed of the CMD line and the DAT lines.  The SD card (and host) reads the value of the CMD line or DAT lines on the rising edge of the clock, so the data/CMD lines must coincide with the clock's rising edges to represent meaningful data.  That last image you posted of your oscilloscope trace didn't seem to have a valid signal on it, if either of the two lines displayed was the clock line.  Are you sure it's hooked up correctly?  Presumably Linux is reading/writing the SD card okay?

I think I found the problem. Poor eyesight The wires I used are enamel-led so need tinning, which I did, but the connection of the probe with the clock line was not making good contact. It was half on the tinned part and half on the enamel. I'm going to make another capture and check if it works now.

Edit: It was not my eyes, but the clock. Aliasing on the sampling. As I wrote earlier I thought the clock was set higher and it is. 50MHz instead of the 2MHz the measurement showed. Which is a bit strange because the sampling rate according to the scope should have been 200MSa/s which should be high enough to catch the clock.

The question is if it is possible to still capture the whole sequence in 50ms if the clock is lowered to 5MHz? Does a lower clock also affect the erase and write time of the card?

[pcprogrammer]

It looks like I'm having an off day

Tried to switch to a lower clock in the software, but with 4.8MHz the scope would not start. On 400KHz, the initial speed, it did start but then the link to the computer fails. After that, finally the light went on I did another capture on 2GSa/s, which is at 5ms/div where I noticed that the write of the sector is only the first ~10ms and the rest of the communication is the reading of the card directory. On my linux system I have to un-mount the partition before using dd, and after the dd command it mounts the partition again. So here is a new capture which should do the trick.

Edit: just to be sure here is also a capture on 8GSa/s. 1ms/div.

[nockieboy]

It looks like I'm having an off day

Tried to switch to a lower clock in the software, but with 4.8MHz the scope would not start. On 400KHz, the initial speed, it did start but then the link to the computer fails. After that, finally the light went on I did another capture on 2GSa/s, which is at 5ms/div where I noticed that the write of the sector is only the first ~10ms and the rest of the communication is the reading of the card directory. On my linux system I have to un-mount the partition before using dd, and after the dd command it mounts the partition again. So here is a new capture which should do the trick.

Edit: just to be sure here is also a capture on 8GSa/s. 1ms/div.

Thanks for doing this pcprogrammer, it's a real help.  I'm just looking into viewing/manipulating the .CSV files.  Is there any chance you could post the .DAT version of those captures, rather than the CSV?   I can import the .DAT format into Octave and view it with minimal fuss, it seems, but I'm having trouble doing anything usable with the CSVs.

[pcprogrammer]

The Rigol only supports .bin, .wfm and the .csv. At first I looked at the .bin data, but it's not clear to me how the data is stored there. Don't know about the .wfm format. To try that one I would have to do a new capture since the scope won't load the .bin or .csv back into memory

Probably not to difficult to convert the .csv file with a bit of c code if you know the .dat format. I'm not familiar with it nor the Octave program you mentioned.

As I'm winding down now any action has to wait till tomorrow though.

[nockieboy]

The Rigol only supports .bin, .wfm and the .csv. At first I looked at the .bin data, but it's not clear to me how the data is stored there. Don't know about the .wfm format. To try that one I would have to do a new capture since the scope won't load the .bin or .csv back into memory

Ah - I only suggested .DAT because I'd read in another forum where a question was asked about viewing .CSVs in something other than Excel (which won't open the whole file due to its size) and a respondent suggested saving the data in .DAT instead of .CSV, as a piece of freeware called Octave can view the .DAT with an add-on.  I'd assumed they were still talking about the Rigol the OP was asking for, but apparently not.

I'm not familiar with Octave either, was just hoping for a quick way to view the data - I'm away for four days after tonight, so it won't be until next week when I can spend some time checking out Octave to see if it will do what I want or write a program to do what I want.  I'll post an update next week! 

[BrianHG]

I found an easy to make game which uses tile mode where if you find the roms online, since it is an NES game, is has a separate tile rom file.  My GPU hardware should be able to do this quite easily with a text layer, another for the score and one extra layer for the player sprite: https://youtu.be/c_SPGJxZ1LM?t=2

[BrianHG]

@nockieboy, new parameters in the DDR3 controller in your gpu top.sv:

Code: [Select]

parameter bit    PORT_R_CACHE_TOUT_ENA [0:15] = '{  0,  0,  0,  0,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1},
                                                // A 0 will direct the read cache to indefinitely keep its contents valid until a new read address is
                                                // requested outside the the current cache contents.  Recommended for very slow read cycles where you may
                                                // manually read outside the current cached address if you wish to re-read from the DDR3.
                                                // A 1 will use the automatic timeout setting below to automatically clear the read cache address.
parameter bit [8:0]  PORT_R_CACHE_TOUT [0:15] = '{256,256,256,256,  0,256,256,256,256,256,256,256,256,256,256,256},
                                                // A timeout for the read cache to consider its contents stale.
                                                // 0   = Always read from DDR3, or no read caching.
                                                // 256 = Wait up to 256 CMD_CLK clock cycles since the previous read req before considering the cached read stale.

Looking at the 'PORT_R_CACHE_TOUT_ENA', you will see I have the 8bit Z80 port disabled, meaning that the read cache is held indefinitely.  If you change the Z80 port to a '1', then looking at the ***_TOUT setting set to 256, it means if the Z80 preforms a read within the cache within 256 CMD_CLK cycles, the Z80 will get an immediate answer from the cache.  If it takes longer than 256 CMD_CLKs since the last read on that port, then your read command will be fetched from the DDR3 even if there is a cache match.  Remember, the timer counts the 100 MHz CMD clock cycles, not the Z80 8MHz clock cycles.

Also note that the 128 bit VGA system on channel 4 has the cache enabled with the timeout set to 0 to prevent it from using the read cache system as it has compatibility issues with some video modes.

[pcprogrammer]

I'm not familiar with Octave either, was just hoping for a quick way to view the data - I'm away for four days after tonight, so it won't be until next week when I can spend some time checking out Octave to see if it will do what I want or write a program to do what I want.  I'll post an update next week! 

As I'm also intrigued by this SD card stuff I looked into it and converted the data to Sigrok input. At first I tried to do it with the Saleae format but that fails for some reason I can't put my finger on. Then I remembered some mention of the open source Sigrok project and that file format is very easy and it worked straight away

You can download the appimage for your system here: http://sigrok.org/wiki/Downloads

Edit1: Sigrok supports SD card (SD mode) protocol decoding. Saves on doing work on that
Edit2: Due to the ~50MHz signal speed and the way the logic analyzer probe is connected there are glitches in the data, but the protocol decoder seems to function properly. I noticed that the write is done with the multiple blocks command (CMD25). If the capture is not conclusive for your problem I can do another with some test software that only uses the one data line and CMD24. Just let me know if you need that.

Remove the .zip extension and load it into Sigrok.

[BrianHG]

The final release v1.6!   
All bugs fixed with some final fine tuning of internal controls. 
Your project should achieve timing FMAX once you finish up the timing .sdc for your SD card.
(Note it already passes at 0deg, plus a few Mhz slow on one VGA clock[1] at 85deg.)

Download attached file and assume all of my DDR3 folder, VGA System folder, your xxx_top.sv, .sdc and maybe some compiler controls in the project configuration have been changed.

See my new 2 layer LSD hallucination ellipse demo here: https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg4230856/#msg4230856

Yes, the demo would still run at 400MHz, like your GPU, but the ellipses draw slower.  Also, this means 4 full screen sized super-imposed 16 bit 1080p windows is now possible as well as 8 layers at 720p and all 16 layers at 480p 32bit color.  (If these windows are smaller than full screen, or X zoomed, or in text mode, then even 4x32bit color is possible.)  You should be able to increase the 'PDI_LAYERS' from to 4 to 8, allowing 8x 1080p layers with 8 bit pixels, maybe 1 of those 8 at 16 or 32 bit (maybe more running at 500MHz).  8 PDI layers would also double all the other layer counts as well.  You may need to increase the 'HW_REGS' size, or check that all the window controls don't interfere with the base address for the palettes and font/tile memory.  I would save this for after you get the SD card and audio are working as compile times will also vastly increase.  Temporarily lowering both the PDI and SDI layers to 1 would vastly shrink compile time, but should maintain compatibility so long as you are only using layer 0.

[BrianHG]

Full final BrianHG_DDR3_Controller_v16 with VGA window system here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415

And here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

And complete .zip package here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller/archive/refs/tags/v1.60.zip

@nockieboy, don't forget to update the Fork of my DDR3 controller in your Github repository using the 'Fetch upstream' function.