FPGA VGA Controller for 8-bit computer

[BrianHG]

Just have to wrap my head around how the modules work and write a WRITE module now.  I suspect that I won't need to touch SDCmdCtrl - in theory the workings of that module shouldn't need to be changed, a WRITE is just a different command to a READ, after all.  I just need to create an SDWriter.sv module and reverse the bitstream flow, essentially.  Will hit the specifications tomorrow and make a start then.

Writing is one thing, but I think with SD cards, you need to worry about an ERASE.
If I remember correctly, you can only erase complete blocks or sectors.
So if you want to edit data in a sector, you need to read it to local ram, erase the sector, modify the local ram, the write the sector.  During the first read, you should be able to tell if you need to erase or not due to the bits you want to change having a 0 or 1 already in them.

If the technology has progressed to erasing single bytes, then ignore what I have just said.

[nockieboy]

No, AFAIK it's still sector/block erasing, with some SD cards reporting up to 4MB block sizes...  I'll look into this tomorrow, as I hadn't really thought about it before and just assumed you could write a sector over an existing one without worrying about erasing.

[nockieboy]

Quick update.  I'm currently working on creating the module that will write data to the SD card.  Progress has been slow - combination of a lack of time to work on it and me being no expert.

I do have the SDInterface controller sending a 512-byte stream to the Writer module, though.  It reads 16 bytes at a time from the DDR3 buffer, in much the same way as the Reader writes to DDR3, and presents those 16 bytes to the writer module so it can read each one when it needs to as it writes to the SD card.  The HDL may not be pretty, but it works (at least as far as I can tell via SignalTap).

I figured adapting the Reader module to create a Writer module would be a moderately sensible way to go about creating a write function.  I just need to look closely at the SD specs for write ops and adapt the Reader's state machine to fit the format required for writing data to the SD card.  I'm a little concerned I'm going to have to modify the SDCmdCtrl.sv module for writing (it looks to be a bit beyond my understanding) due to the CRC values required after the block is sent, but we'll see.

[BrianHG]

Ok, what you have looks fine.  If signal-tap shows everything is ok, then it is a go.
I wont trouble you with functional shortcuts to address 8 bits of the 128bit array.

IE:
data_cache[byte_position*8 +:8] <= SD_dat ; //
or
wr_dat <= data_cache[byte_position*8 +:8] ; //


I have not seen the 'SDCmdCtrl.sv', but I can take a look if you provide the one you are using.

[nockieboy]

Ok, what you have looks fine.  If signal-tap shows everything is ok, then it is a go.
I wont trouble you with functional shortcuts to address 8 bits of the 128bit array.

IE:
data_cache[byte_position*8 +:8] <= SD_dat ; //
or
wr_dat <= data_cache[byte_position*8 +:8] ; //

I knew there'd be a more efficient way of doing it, I just hadn't gotten around to optimising the HDL yet as I only got the byte stream for SDWriter working this afternoon.   I'll try giving your suggestion a go.

I have not seen the 'SDCmdCtrl.sv', but I can take a look if you provide the one you are using.

See attached zip file.  It has the SDInterface and its sub-modules, SDReader (which works fine) and SDWriter (which, at the moment, is little more than a test-bed for me to check SDInterface's byte stream to it).  Both SDReader and SDWriter implement SDCmdCtrl.sv as a sub-module, which is also in the zip obviously.

[nockieboy]

I wont trouble you with functional shortcuts to address 8 bits of the 128bit array.

IE:
data_cache[byte_position*8 +:8] <= SD_dat ; //
or
wr_dat <= data_cache[byte_position*8 +:8] ; //

Actually, please do - if I can write it using less lines of code then I'm happy to learn!

So, for the rd_op section (lines 218-238-ish of SDInterface.sv), I could replace that entire case...endcase structure with something like this?

Code: [Select]

data_cache[data_ptr*8+:8] <= SD_dat ;
if ( data_ptr == 'h0F ) cache_full <= 1'b1 ;
Wouldn't that reverse the byte-order though?  At the moment, if data_ptr is zero, it returns the byte at the highest end of the cache (bits 127-120).  Using the code above, wouldn't that return the LSB from the other end, or have I misunderstood how that shortcut works?

[BrianHG]

Actually, please do - if I can write it using less lines of code then I'm happy to learn!

So, for the rd_op section (lines 218-238-ish of SDInterface.sv), I could replace that entire case...endcase structure with something like this?

Code: [Select]

data_cache[data_ptr*8+:8] <= SD_dat ;
if ( data_ptr == 'h0F ) cache_full <= 1'b1 ;
Wouldn't that reverse the byte-order though?  At the moment, if data_ptr is zero, it returns the byte at the highest end of the cache (bits 127-120).  Using the code above, wouldn't that return the LSB from the other end, or have I misunderstood how that shortcut works?

Wouldn't that then be ' (15-data_ptr)*8 ' ?
Remember, the added ' 15- ' doesn't add gates or delay, the compiler just will end up wiring the 'data_cache' latch enables backwards.

[BrianHG]

Also, what's wrong with resetting the 'data_ptr' to 15, then subtracting 1 every clock, and ending on 0 instead of counting up?

[nockieboy]

Also, what's wrong with resetting the 'data_ptr' to 15, then subtracting 1 every clock, and ending on 0 instead of counting up?

Well, that's just far too logical. 

Think you might have missed a reply of mine earlier?  I'd attached the current SDInterface files (you asked about the SDCmdCtrl.sv file):

I have not seen the 'SDCmdCtrl.sv', but I can take a look if you provide the one you are using.

See attached zip file.  It has the SDInterface and its sub-modules, SDReader (which works fine) and SDWriter (which, at the moment, is little more than a test-bed for me to check SDInterface's byte stream to it).  Both SDReader and SDWriter implement SDCmdCtrl.sv as a sub-module, which is also in the zip obviously.

[BrianHG]

I've been too busy here.  What's the latest on your side?  Did you load your first file?

[nockieboy]

I've been too busy here.  What's the latest on your side?  Did you load your first file?

Progress has been slow - whilst I haven't read my first file yet, I'm happy with the read function; it's getting the MBR and subsequent sectors from the SD card with no issues, so I have no concerns with that aspect of the interface.

I'm working on the write function at the moment as I really need that to format the card and get the CP/M tracks down onto it.  I've used the existing SDReader.sv file as a template to work from and am writing the HDL to build the 'write' function using SD specs and the read/writer (specifically the sd_data_serial_host.v file) from the previous SD interface IP core I wasted time on as a reference.

EDIT:  If I'm honest, I think I'm lost in writing the state machine to write data to the SD card.  I've started out tweaking the SDReader code to use a basic framework for the write SM, using the HDL from the previous IP core as a guide to set up the write process, but the more I look at it all, the more confused I'm getting.  It should just be a 'simple' case of:

• Send the write command (CMD24) to the SD card with the sector address in the argument - good examples of how to do this are already in the SDReader module.
• Send the START_TRANSMISSION bit (i.e. pull DAT0 LOW for 1 SD_CLK).
• Send 4,096 bits of data to be written to the SD card.  I've written (and tested) the ByteStreamer in the SDInterface module that gives SDWriter the data it needs to stream.  Again, not a problem.
• Calculate a CRC based on the sent data, as it's sent.
• When all 4,096 data bits are sent, send CRC (up to 32 bits).
• End transmission by pulling DAT0 HIGH.

I'm up to calculating the CRC and writing it back to the SD card.  The more I look at the module from the previous IP core, the more I want to convert it for use in the current interface as it combines writing and reading into one module and - most importantly - supports 4-bit mode.  I just worry I'd spend an age trying to convert it only for it not to work.

[nockieboy]

Help!

Frustration has gotten the better of me and I'm about ready to pull the plug on the SD interface.

I managed to create a working interface that would read sectors from an SD card with no errors - that was pretty easy.

I have now spent the past four weeks thinking about, researching and experimenting in HDL to create a WRITE function so I can save data TO an SD card.

At first I thought I'd build on the existing READ side of the interface and repurpose the HDL framework to create a WRITE side (this is the SDCard_Interface/SDInterface_old.sv module).  After making tentative steps towards setting it up, I realised I didn't have a clue what I was doing with the state machine and how I would include CRC checks etc.

Then I had the hair-brained idea to look at the previous IP core (the one that was reading/writing gobbledook, it seems) to see how that was doing it, and found the sd_data_serial_host.v module which seemed to make more sense than what I was trying to do - plus it showed me how I could use 4-bit SD mode as well, so I thought I could tweak that to work and the SDInterface module to use it.  I got to the point where the module is building with no errors and I'm debugging via SignalTap, but I've spent since Thursday last week looking at SignalTap traces in my spare time trying to piece together why the interface isn't initialising the SD card.  Damned if I can work it out.

I've been trying to do it all on my own without asking for help, but all it seems I've got to show for a month's (or more) work is the ability to read from an SD card.

I'll continue to plug away at SignalTap as ideas for possible issues pop up, or as my understanding of the HDL improves, but it'll be at a much-reduced rate now.  If anyone has any time and inclination to give me a hand, it would probably be a project lifesaver at this point.

The attached zip file is the current GPU project, with the non-working SD interface which I'm trying to bug fix and get working.  It should initialise the SD card, read or write the SD card as three different operations, selectable by a value written by the host to the appropriate IO port (242).

[BrianHG]

Arrrg, 3 days... 3 days of trying to track down this silly bug where a read port may freeze when running my DDR3 controller in Quarter Rate Mode with an unusual slip in the read address (when slanting 1 of 2 superimposed video layers on my VGA controller) only after millions of read commands issued.  I just cant simulate it and the signal tap would be useless as there are too many environment variables to track at 300MHz.  It's driving me nuts as it is the one thing I have left before issuing a proper v1.6 release.  There is no reason for this to operate properly in half-rate mode, but not quarter-rate mode and I know which modules are involved.  Worse, turning off the read-cache solves the problem at the expense of making repetitive reads slow.

[BrianHG]

@nockieboy, pls upload your complete latest GPU project.  I have ver 1.6 beta 2 ready for testing and I want to integrate it into your code.  Ok, I got your latest code above...

So far, I'm stumped about using the quarter rate mode, however, improvements along the way have made 400MHz half rate possible, though I know there is a bottleneck with regard to the ellipse command and it's 27bit multiply-add command.  At least 300MHz in half-rate mode should now hopefully achieve an all black timing report.

[BrianHG]

Info on version BrianHG_DDR3_Controller 1.6 update:

https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg4192249/#msg4192249

[nockieboy]

Arrrg, 3 days... 3 days of trying to track down this silly bug where a read port may freeze when running my DDR3 controller in Quarter Rate Mode with an unusual slip in the read address (when slanting 1 of 2 superimposed video layers on my VGA controller) only after millions of read commands issued.  I just cant simulate it and the signal tap would be useless as there are too many environment variables to track at 300MHz.  It's driving me nuts as it is the one thing I have left before issuing a proper v1.6 release.  There is no reason for this to operate properly in half-rate mode, but not quarter-rate mode and I know which modules are involved.  Worse, turning off the read-cache solves the problem at the expense of making repetitive reads slow.

Eesh - didn't realise it was such a pervasive little problem!

I'll take a look at the updated DDR3 controller this weekend and update my project with it.

I've managed to keep plugging away at the SD interface this last week or so and have made some significant progress - I'm now at the testing and bug-hunting stage, having written a WRITE function for the interface.  It is somewhat based on the existing SDReader module, but I've leaned heavily on the HDL within the SD-card-controller sd_data_serial_host module for guidance.  I've also been deep-diving the SD Part_1_Physical_Layer_Specification (albeit version 3.01, but it's not the simplified version and has some key diagrams showing WRITE timings).

I'm reading Sector 0 off the SD card into the SD Buffer in GPU RAM.  Then I'm trying to write that data (the FAT32 MBR, basically) to Sector 3.  I'm writing it to Sector 3 as Sector 3 appears to be all zeros on the SD card, and failed writes erase the sector but don't write anything, so I'm not changing any data on the SD card with a failed write (which is all I'm managing to do at the moment).

It appears that I'm not getting anything back from the SD card when I attempt to write to it.  I'm sending CMD24, then writing the 512-byte payload, immediately followed by the 16-bit CRC and STOP bit, but I'm not seeing any life on DAT0 when the SD card should be responding with the CRC response byte (which should be an error or OK, if I've got the CRC function working correctly).

Here's a SignalTap of the start of the process, showing the start of payload transmission to the SD card (CMD24 is sent using the same module that the READ command is sent, I have no reason to think it's not working as intended):



And here's a SignalTap of the end of the process, showing the last two bytes of the payload (0x55 and 0xAA being the last two bytes of Sector 0) and the 16 CRC bits and STOP bit:



It seems there are quite a few possible points of failure in this process - I'm gravitating towards it being an issue with the DAT0 direction or the CRC being incorrect, but the SD card should respond if it's a CRC error.

I'd really, really appreciate the help of anyone who knows a bit about the SD interface and 1-bit SD mode, which is what I'm using here.  Latest project files attached for reference.  The SD modules are in the SDCard_Interface folder in the project folder - SDWriter is the module that I'm debugging.

[BrianHG]

Question, don't you have to erase a block to change all the bits from 0's ti 1's, then, whatever you write, only 0's are actually written.  Meaning you can progressively keep on writing again and again changing any 1's to 0's, but once the bit is 0, you cannot flip it back to a '1' unless you do a block/sector erase with erases an entire chunk at once.

[nockieboy]

Question, don't you have to erase a block to change all the bits from 0's ti 1's, then, whatever you write, only 0's are actually written.  Meaning you can progressively keep on writing again and again changing any 1's to 0's, but once the bit is 0, you cannot flip it back to a '1' unless you do a block/sector erase with erases an entire chunk at once.

I must have missed everything in the specification documents and even HDL examples I've been using where any kind of erase is performed before a write.  As far as I can tell, the SD card erases the sector when the write command is issued, then writes the new 512 bytes of data to the sector from its internal buffer once it has all been received and the CRC checks out.  Pre-erase seems to be for multi-block writes - you can let the SD card know how many blocks you intend to write and the SD card can pre-erase those blocks before you send all the data, eliminating the pauses between each block write whilst it erases the next block.

At least, that's how I understand it, but I've not actually read anything in the specification documents explicitly saying that's how it works.  This flowchart in the specifications also makes no mention of pre-erase for single-block writes:



Of course, there's always the possibility I'm wrong - it isn't exactly unheard of. 

EDIT: Also, when I've accidentally written to Sector 0, it has been set to all zeros.

[BrianHG]

Arrrg, 3 days... 3 days of trying to track down this silly bug where a read port may freeze when running my DDR3 controller in Quarter Rate Mode with an unusual slip in the read address (when slanting 1 of 2 superimposed video layers on my VGA controller) only after millions of read commands issued.  I just cant simulate it and the signal tap would be useless as there are too many environment variables to track at 300MHz.  It's driving me nuts as it is the one thing I have left before issuing a proper v1.6 release.  There is no reason for this to operate properly in half-rate mode, but not quarter-rate mode and I know which modules are involved.  Worse, turning off the read-cache solves the problem at the expense of making repetitive reads slow.

Eesh - didn't realise it was such a pervasive little problem!

I'll take a look at the updated DDR3 controller this weekend and update my project with it.

Once in a few hundred million bytes causing a random freeze is sometimes tough to find the true root cause, especially if it has more than one problem behind it.

No update yet.  I have some other priorities which is sapping my time.

[pcprogrammer]

@nockieboy

About the SD card write you are correct that the card does the erase when needed. Before sending command 24 you have to select the card with command 7 and only when it returns an OK it is ready to receive the write command.

When there are multiple 512 byte blocks to write you have to use command 25.

At least this is how it works for me in the FNIRSI 1013D. I guess you have to also get the low level interfacing done to make it work. The F1C100s has a dedicated SD card interface that takes care of this.

As I wrote before look at the code here https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/sd_card_interface.c

The function "int32 sd_card_write(uint32 sector, uint32 blocks, uint8 *buffer)" takes care of the users write request by calling the function "int32 sd_card_send_command(PSD_CARD_COMMAND command, PSD_CARD_DATA data)" with the needed commands.

This latter function does the controlling of the F1C100s low level SD card interface peripheral.

The card also has to be in the correct state to be able to select and deselect it. This is done with the "int32 sd_card_init(void)" function.

Hope this helps.

Cheers,
Peter

[pcprogrammer]

Question, don't you have to erase a block to change all the bits from 0's ti 1's, then, whatever you write, only 0's are actually written.  Meaning you can progressively keep on writing again and again changing any 1's to 0's, but once the bit is 0, you cannot flip it back to a '1' unless you do a block/sector erase with erases an entire chunk at once.

This is true for FLASH ic's. They need a block erase command when a 0 needs to be turned into a 1.

[nockieboy]

@nockieboy

About the SD card write you are correct that the card does the erase when needed. Before sending command 24 you have to select the card with command 7 and only when it returns an OK it is ready to receive the write command.

I think my setup should be working okay then - when the system boots up, the SD interface automatically interrogates any SD card plugged into the DECA board to establish if it's SDHC or some other standard.  The SDReader module sends the following commands as part of the bootup process:

CMD0, CMD8, ACMD41, CMD2, CMD3, CMD7 with RCA, CMD16 (set block length to 0x200).

It leaves the card in this state, so the SD card should be in 'transfer mode' by default.  When I write to the card, the SDWriter module assumes that the card is in this state and just transmits CMD24, then the payload and CRC.  I shouldn't have to send CMD7 every time I want to write, unless the SD card is not in 'transfer mode' or I want to select a different card (there's only one, by the way).

As I wrote before look at the code here https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/sd_card_interface.c

The function "int32 sd_card_write(uint32 sector, uint32 blocks, uint8 *buffer)" takes care of the users write request by calling the function "int32 sd_card_send_command(PSD_CARD_COMMAND command, PSD_CARD_DATA data)" with the needed commands.

This latter function does the controlling of the F1C100s low level SD card interface peripheral.

The card also has to be in the correct state to be able to select and deselect it. This is done with the "int32 sd_card_init(void)" function.

I'll take another look at this code - I seem to have forgotten about it amongst all the other stuff going off, so I'll revisit it to see if I can see what's going wrong with my HDL.  Thanks!

EDIT: I'm going to modify SDWriter to send CMD7 before every write anyway, I think, just to make sure the card is selected.  SDReader (the module I didn't write) seems to go through the whole initialisation process from CMD0 to CMD16 before reading a block (I'm sure I can optimise that later) but for the moment, I think it's probably a good idea that SDWriter at least sends CMD7 before CMD24.

[pcprogrammer]

EDIT: I'm going to modify SDWriter to send CMD7 before every write anyway, I think, just to make sure the card is selected.  SDReader (the module I didn't write) seems to go through the whole initialisation process from CMD0 to CMD16 before reading a block (I'm sure I can optimise that later) but for the moment, I think it's probably a good idea that SDWriter at least sends CMD7 before CMD24.

Then you also have to add it at the end to do the deselect. (See my write function)

I did my code based upon partially reverse engineering the original firmware, bits of linux source code, other samples I found on the net and the simplified SD card specifications you also mentioned a while back. Did not try it without the 7 commands. Was glad it was working. It also took its time to get it done. Had no previous experience with SD cards what so ever

I have tested it with a number of cards but not sure about the actual types. The code does have provisions for SDHC or other standards but to truly test it you need all these different types of cards, which I don't have

[pcprogrammer]

The SDReader module sends the following commands as part of the bootup process:

CMD0, CMD8, ACMD41, CMD2, CMD3, CMD7 with RCA, CMD16 (set block length to 0x200).

In my code I see a command 55 before the ACMD41.

Also the response to command 8 should be OK to indicate it being a version 2.0 or later card. Otherwise a different initialization is needed.

The command 7 is send before and after every action my code takes, so you have to make sure yours does the same. So don't send it in the initialization. Use it before and after reading or writing.

Edit: Another thing I noticed is that the card needs to be set to the used clock speed and bus width depending on the type of card. Check this function "int32 sd_card_set_clock_and_bus(int32 usewidebus)" Also look at this function "int32 sd_card_check_switchable_function(void)" These are part of the initialization.

[nockieboy]

The SDReader module sends the following commands as part of the bootup process:

CMD0, CMD8, ACMD41, CMD2, CMD3, CMD7 with RCA, CMD16 (set block length to 0x200).

In my code I see a command 55 before the ACMD41.

Yeah, sorry, I didn't bother listing CMD55 in there as it was implied in the ACMD41, but you're right to question whether it was actually there or not.

Also the response to command 8 should be OK to indicate it being a version 2.0 or later card. Otherwise a different initialization is needed.

The initialisation is fairly basic, but works with the SDHC card I'm using currently.  The HDL is able to identify SDv1, SDv2 and SDHCv2 cards.

The command 7 is send before and after every action my code takes, so you have to make sure yours does the same. So don't send it in the initialization. Use it before and after reading or writing.

Okay, so instead of putting the SD card into 'transfer mode' and leaving it there after initialisation, I should select and deselect the card for each transaction?  Will give that a try.  Am in the midst of adding CMD7 select to the start of each WRITE at the moment.  Can't see how deselecting it will change anything, but might check that out later.

Edit: Another thing I noticed is that the card needs to be set to the used clock speed and bus width depending on the type of card. Check this function "int32 sd_card_set_clock_and_bus(int32 usewidebus)" Also look at this function "int32 sd_card_check_switchable_function(void)" These are part of the initialization.

The initialisation is all done using the SDReader module, which works perfectly - I have no issues with reading sectors from the SD card, so I am assuming initialisation is fine for the SD card.  The only difference with the SDWriter module is that it doesn't do the full initialisation that the SDReader module does before each read.  Unless the SD card 'times out' of transfer mode, it should still be selected and in transfer mode when I perform the first WRITE, hence I haven't bothered with any setup for the WRITE, it just sends CMD24.

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.