FPGA VGA Controller for 8-bit computer

[nockieboy]

So?  Do the tile modes/layers work?

Yes, they appear to so far.  Progress is slow due to the much-mentioned work pressures currently, along with a slight diversion to write a tileset tool that does exactly what I need (i.e. makes it much easier and quicker to realign palette indices in the image and displays the actual memory locations for each palette entry used, imports the image's palette and converts it for the GPU etc).

Layer 2 is displaying the map nicely.  Once I've finished off the Tile Set Editor, I'll pop it up on github and crack on with the next steps in the tile demo's development.



EDIT: This 'game' has been sat on CP/M for a year or two in development limbo, I've just modified it to use tile layers and graphics instead of the old ASCII art I initially set it up to use.

[BrianHG]

 

[SiliconWizard]

Great project guys!

[nockieboy]

The Tile Set Editor is now up on github.

It's not pretty, but it gets the job done in terms of turning an 8-bit indexed PNG image into a raw binary file and separate pixel table that can be uploaded via the rs232_debugger to the GPU.  Saves messing around with ImageMagick and endless checking and copying palette values directly into memory.

[BrianHG]

    Great.  What's the next step?

    I thought that your tile editor would have been done on the Z80.

    Are you having a file system compatibility and transfer problem?

    Remember, if the Z80 cant cope with .png, using uncompressed .tiff is nothing more than stripping out the header, copying the palette info and picture data directly to the DDR3 and setting my window parameters accordingly, for both working with using font/tiles and showing full pictures up to 32bit color.

    You know you can try to add the SD-Card reader.  You can tie the read and write directly to my DDR3 controller anyway you like.  The SD-Card is so slow, it just isn't worth the effort to make a super fancy cached controller as the tiny 16/32 byte cache buffer built inside my DDR3 controller should be enough for 90% of anything you can imagine.  Only a real-time MJPEG video playback codec may be the one case where a complete high speed 4kb block cache will be beneficial.

[nockieboy]

    Great.  What's the next step?

I think I was going to tackle something a little more taxing, like the videos you linked previously.

    I thought that your tile editor would have been done on the Z80.

Yeah, no.   Thanks to modern IDEs, I was able to create TSE in a few hours work.  Doing something similar on the Z80 would take significantly longer, and I've felt a little pressured recently to get results out of the door, so to speak.

    Are you having a file system compatibility and transfer problem?

    Remember, if the Z80 cant cope with .png, using uncompressed .tiff is nothing more than stripping out the header, copying the palette info and picture data directly to the DDR3 and setting my window parameters accordingly, for both working with using font/tiles and showing full pictures up to 32bit color.

My focus has been PC dev tools as that's where all the development has been done so far, so I haven't really looked into this idea much at all yet.  If I can get an SD card interface up and running, then I'll move it up the list as transferring files to the Z80 will become much easier.

    You know you can try to add the SD-Card reader.  You can tie the read and write directly to my DDR3 controller anyway you like.  The SD-Card is so slow, it just isn't worth the effort to make a super fancy cached controller as the tiny 16/32 byte cache buffer built inside my DDR3 controller should be enough for 90% of anything you can imagine.  Only a real-time MJPEG video playback codec may be the one case where a complete high speed 4kb block cache will be beneficial.

I've been wanting to make a start on this for ages now, especially since moving to the DECA (and its working SD card socket!)  The issue is, I'm not sure really where to start.  It's an unfortunate combination of two areas of knowledge I'm really deficient in - storage and storage.  I know that's technically only one area, but I thought it was worth mentioning twice.

My simplistic understanding of it is that basically data is serialised and written to/read from the interface a block at a time - the only working example is the CF card interface that I use currently with my uCOM (I didn't write that).  On top of that, there's also considerations about formatting, file/folder structure etc.  The CF card interface I'm using uses an old CP/M format - I'm able to read the contents on the PC using some old cpmtools drivers that read the old format.

Now what I'd like to do - and I have no idea if it's even possible - is have CP/M think it's accessing a floppy disk as usual (i.e. use the existing CF driver, with maybe a couple of tweaks), but in reality use a FAT32-formatted SD card and be able to drop it into a PC and have Windows read the card without any additional drivers.  The problem is, I have no idea what would be required of the FPGA interface and host driver to do that.  I've been putting off disappearing from the forum for a month or two to go read up on all this in favour of quick hits to show progress, but with the GPU now able to shift graphics about like a JCB in a sandpit, I really need a better method of file storage and transfer for the uCOM.  Looking at existing SD card interfaces on OpenCores, for example, doesn't fill me with confidence when I have to also learn about Wishbone interfaces and loads of other stuff I don't really need.

I need to stop procrastinating and bite the bullet on this task.

[BrianHG]

    Great.  What's the next step?

I think I was going to tackle something a little more taxing, like the videos you linked previously.

Really.  A multilayer 2D platformer game engine isn't too difficult with my video system, but, it's all the graphics and sound assets.

[rstofer]

Now what I'd like to do - and I have no idea if it's even possible - is have CP/M think it's accessing a floppy disk as usual (i.e. use the existing CF driver, with maybe a couple of tweaks), but in reality use a FAT32-formatted SD card and be able to drop it into a PC and have Windows read the card without any additional drivers.  The problem is, I have no idea what would be required of the FPGA interface and host driver to do that.  I've been putting off disappearing from the forum for a month or two to go read up on all this in favour of quick hits to show progress, but with the GPU now able to shift graphics about like a JCB in a sandpit, I really need a better method of file storage and transfer for the uCOM.  Looking at existing SD card interfaces on OpenCores, for example, doesn't fill me with confidence when I have to also learn about Wishbone interfaces and loads of other stuff I don't really need.

I need to stop procrastinating and bite the bullet on this task.

A Compact Flash implementation on an FPGA is dead simple because it is a parallel interface.  In fact, it is an ATA protocol just like an HDD.    At least in terms of reading and writing sectors. 

The IBM 1130 had 321 word sectors (642 bytes) which I mapped into adjacent 512 byte sectors.  The rest was trivial.

However, I didn't have to create a file system or have any ability to work with it on a PC.  The 1130 had its own file system and I was just implementing the underlying hardware.

If I couldn't come up with some other way to do things, I would use the Linux 'dd' command to read and write the CF.  Turning the raw image into a recognizable file system (FAT32) would be done in code somehow.

CP/M is the file system, all the BIOS does is read and write sectors.  You could easily map an entire CP/M drive into a named file if you could deal with the allocation table in FPGA code.  I might use a small core and some assembly language to do this mapping.  It seems rather complex to do it in hardware but maybe not.  You can use 512 byte sectors in CP/M, the code for packing and unpacking is easily obtained and was written by Digital Research.  I haven't thought about it in years.  Maybe it came with CP/M 2.2

https://en.wikipedia.org/wiki/Parallel_ATA#Compact_Flash_interface

[nockieboy]

A Compact Flash implementation on an FPGA is dead simple because it is a parallel interface.  In fact, it is an ATA protocol just like an HDD.    At least in terms of reading and writing sectors. 

The IBM 1130 had 321 word sectors (642 bytes) which I mapped into adjacent 512 byte sectors.  The rest was trivial.

However, I didn't have to create a file system or have any ability to work with it on a PC.  The 1130 had its own file system and I was just implementing the underlying hardware.

Yes, my uCOM currently uses a CF card interface I built based on Grant Searle's original designs (his CP/M design, specifically), with a few extra features like bus buffering etc, so I have a working BIOS with the low-level routines (including blocking/de-blocking) to operate the CF card with no problems, but not having to write them myself or watching how they came together I have very little true understanding of the basics of the CP/M format - I don't know what I don't know, if you know what I mean, so I don't know what's possible and what isn't - hence the question regarding whether or not it's possible to 'convert' CP/M files into FAT32/Windows files (and back) on the fly between the host and SD card, and why I'm now hitting the books hard to learn more about the subject.

If I couldn't come up with some other way to do things, I would use the Linux 'dd' command to read and write the CF.  Turning the raw image into a recognizable file system (FAT32) would be done in code somehow.

Tools exist already for Linux and Windows (cpmtools) that do this - I can take the CF card out of the uCOM, plug it into my PC and read/write the CP/M drives and files (almost) like a native Windows drive.  If I could remove cpmtools from the equation, however, it removes another potential point of failure in the system (at some point, cpmtools will probably disappear or stop being compatible with the latest OSes, etc).

CP/M is the file system, all the BIOS does is read and write sectors.  You could easily map an entire CP/M drive into a named file if you could deal with the allocation table in FPGA code.  I might use a small core and some assembly language to do this mapping.  It seems rather complex to do it in hardware but maybe not.  You can use 512 byte sectors in CP/M, the code for packing and unpacking is easily obtained and was written by Digital Research.  I haven't thought about it in years.  Maybe it came with CP/M 2.2

Yes, I've been reading about CP/M's file system earlier today (The Programmer's CP/M Handbook by Andy Johnson-Laird) and it's clear that the way the file system works is embedded deeply into BDOS and the BIOS, so it's not looking likely that what I want to do is possible without some major refactoring of CP/M's source code - a rabbit hole I certainly don't have the time or experience to dive down.

Anyway, I'm massively jumping the gun by worrying about what I can and can't achieve with the SD card's format - I've first got to get an interface up and running that allows the host to read and write SD card data at all.  I'm considering using this project on OpenCores to establish an SD interface in the FPGA.  I know nothing about the Wishbone interface, so that's something else for me to learn about, but I don't think I actually need it and might be able to remove that part from the project, as the Z80_Bridge module in the FPGA should be able to handle the data and command flow between host and SD interface without a Wishbone bus.

Once I get some form of data read/write access to the SD card for the host, I can then start thinking about DMA into a DDR3 buffer and working out what's required to get CP/M working.  Right now, though, I'm researching the basic concepts.

[rstofer]

My first FPGA project after the all-important 'blinky' was to use the Opencores T80 core (Z80 workalike) to bring up CP/M.  This was on a Spartan 2 (great 5V FPGA) with a compact flash.  It was pretty trivial after I properly terminated the INT input.  Lot of head scratching before I tumbled to unending recursive interrupts.

The next time I used a compact flash was on a Z80Eclaim! project.  CP/M at 50 MHz really screams!

Finally, I used the compact flash on my IBM1130 project.  There is a disk image build routine that lays out all of the IBM code files in the proper sequence and 'dd' copies the image to the CF.

This is the guide I use for creating the various BIOSs beginning back  in '79 or so.

http://bitsavers.trailing-edge.com/pdf/digitalResearch/cpm/2.2/CPM_2.2_Alteration_Guide_1979.pdf

[nockieboy]

My first FPGA project after the all-important 'blinky' was to use the Opencores T80 core (Z80 workalike) to bring up CP/M.  This was on a Spartan 2 (great 5V FPGA) with a compact flash.  It was pretty trivial after I properly terminated the INT input.  Lot of head scratching before I tumbled to unending recursive interrupts.

The next time I used a compact flash was on a Z80Eclaim! project.  CP/M at 50 MHz really screams!

I can see myself doing away with the uCOM stack entirely at some point and moving to a softcore Z80 CPU, but that's for when I get bored of the hardware side of the development.

Finally, I used the compact flash on my IBM1130 project.  There is a disk image build routine that lays out all of the IBM code files in the proper sequence and 'dd' copies the image to the CF.

This is the guide I use for creating the various BIOSs beginning back  in '79 or so.

http://bitsavers.trailing-edge.com/pdf/digitalResearch/cpm/2.2/CPM_2.2_Alteration_Guide_1979.pdf

Thanks for that link - you seem to have found the one CP/M book I missed when I did my research trawl at the start of this project several years ago!  Will give that a read too.

Just thinking out loud, but presumably it'd be possible to re-write the BDOS to intercept disk I/O at the file level, instead of the sector level in the BIOS, and just have CP/M work with filenames which would translate directly to an SD card interface that does the same, but handles the low-level interfacing with the SD card (and cut out the BIOS middle-man)?  Obviously it wouldn't be CP/M anymore at that point, but only in the strictest sense of the name.  This would be a brittle system, though - likely to fail terribly if a program somewhere accesses the drive at a lower level than the BDOS, but I'm not aware of anything that does? (Other than maybe formatting programs?)

[voltsandjolts]

Sorry, slight OT, but I thought this was quite cool...if you were making games for your system...
https://www.theguardian.com/games/2022/mar/07/duck-hunt-light-gun

[nockieboy]

Sorry, slight OT, but I thought this was quite cool...if you were making games for your system...
https://www.theguardian.com/games/2022/mar/07/duck-hunt-light-gun

Interesting idea.  I've missed the old CRT-enabled light guns - didn't think the Wii version was that bad, but there's clearly room for improvement/optimisation over that particular method of getting a gun to work with a modern display.

As for making games for my system - heh... yes, I suppose if there more than 48 hours in a day I'd have time to make significant progress, but at the moment it's almost strictly one-thing-at-a-time and the pressing need for an SD card interface is at the top of the list.

[nockieboy]

I think I need a little guidance or at least an opinion on which direction I should take with this SD card interface.  I've been looking very closely at this OpenCores project that provides a fully-functioning SD card interface (project files attached).

The issue is that it uses a Wishbone interface which, to my inexperienced eye at least, appears to be an unnecessary complication.  I figured it would be simplest to directly interface the SD interface logic with the Z80_Bridge, but I'm not convinced I'm up to the task of removing the Wishbone interface HDL and stripping the SD interface down to the barebones required to interface to the Z80_Bridge.  It also looks like it's going to need some additional tri-state control of a couple of the connections from sd_controller_top to the SD card on the DECA board (the DECA has SD_DAT [3:0], but sd_controller_top has separate sd_dat_dat_i [3:0] and sd_dat_out_o [3:0] buses).

In fact I'm not 100% sure that this particular interface will do what I want it to do - which is (initially, at least) to allow sector-level R/W access to the SD card.  From there I can move on to look at more advanced features of this interface - it looks like it may allow higher-level access to the card at the filename/directory level.

Anyway, I've added the SD interface files to the GPU project and made a very early start on adding the interface to the GPU_DECA_DDR3_top file (i.e. it's not connected yet).  I've attached the updated GPU_DECA_DDR3_top and SD interface files below for info.  Would it be easier to connect the Z80_Bridge via Wishbone or surgically remove it from the SD interface and replace it with a specific set of connections/buses?

[nockieboy]

Here's an interesting FPGA I just found on Mouser - https://www.mouser.co.uk/ProductDetail/Microchip-Technology/A3P250-FG256I.

Seems to use flash instead of SRAM to hold the FPGA's gate setup, so it's instant-on and doesn't require an external EEPROM to hold the FPGA's design.  Not sure how it compares with the likes of Altera and Xilinx, but it seems to be lacking in the block RAM department.

[woofy]

Hopefully a working link
https://www.mouser.co.uk/ProductDetail/Microchip-Technology/A3P250-FG256I?qs=sGAEpiMZZMsopV7UX9wSFD7ZLTigxKjg

Just had a quick look.
Only 1 PLL, 36k bits RAM, 6144 tiles which can EITHER be LUT or D-flipflop, and the LUT is only 3 input anyway.
Unless I missed something - for GBP23, not overly impressive.

[nockieboy]

Just had a quick look.
Only 1 PLL, 36k bits RAM, 6144 tiles which can EITHER be LUT or D-flipflop, and the LUT is only 3 input anyway.
Unless I missed something - for GBP23, not overly impressive.

Ah, that's where having an experienced eye look at the datasheet is handy.   I was hunting for something else and noticed the A3P250 - was mildly impressed with the use of flash rather than SRAM (at least I assume that's what it is) to hold the configuration in the FPGA, but I'm easily impressed it seems.

[nockieboy]

Think I found an error in the GPU_DECA_DDR3_top pin assignments - which would have originated from the original file we got the assignments from.

In the MicroSD Card assignments section (lines 364-317 in GPU_DECA_DDR3_top.sv), line 368 specifically, looks like this:

Code: [Select]

inout    SD_D123_DIR
Unless anyone can tell me otherwise, it should be an output, not a bi-directional port, as it controls the direction of the SN74AVCA406L voltage-translation transceiver between the FPGA and the SD card socket, and that pin is just an input on the 406L.

I don't know if that would make any difference to anyone's attempts to use the SD socket on the DECA, but I thought it was worth mentioning.

[nockieboy]

  I've finally had some time to work on this again, and this is where I'm at.  I've got the SD socket connected up to this OpenCores SD host controller IP that I'm hoping to use.

As yet I haven't touched the Wishbone interface, I'll worry about that when I can the GPU project to compile with the SD host controller module in it, which - at the moment - it is not.  There's been a succession of errors which I've corrected on the way through, but I've reached one that has stumped me.

Compilation halts with this error:

Error (10818): Can't infer register for "new_bw" at sd_bd.v(132) because it does not hold its value outside the clock edge
Error (10822): HDL error at sd_bd.v(132): couldn't implement registers for assignments on this clock edge
Error (12152): Can't elaborate user hierarchy "sd_controller_top:SID|sd_bd:rx_bd"

Offending code segment:

Code: [Select]

// Main side read/write 
always @(posedge clk or posedge rst ) begin

  new_bw <= 0 ;
 
  if ( rst ) begin

    m_wr_pnt  <= 0 ;
    write_cnt <= 0 ;
    new_bw    <= 0 ;
    read_cnt  <= 0 ;
   
  end
  else if ( we_m ) begin

    if ( free_bd > 0 ) begin

      write_cnt <= write_cnt + 1 ;
      m_wr_pnt  <= m_wr_pnt  + 1 ;

      if (!write_cnt[1]) begin // First write indicate source buffer addr (2x16)

        bd_mem[m_wr_pnt] <= dat_in_m     ;             

      end
      else begin               // Second write indicate SD card block addr (2x16)

        bd_mem[m_wr_pnt] <= dat_in_m     ;
        new_bw           <= write_cnt[0] ;      //Second 16 bytes writen, complete BD

      end

    end

  end
   
end

I've done some research elsewhere online and all of the related problems people have had (I may have missed an exception somewhere) related to VHDL implementations, which isn't helping me much, but I think the issue is to do with the always block triggering on clk or rst, but the if (we_m) is causing issues as it isn't triggered by a clock edge, but that shouldn't matter as we're just testing its value on a trigger edge, like we do loads of times in other modules....?

[BrianHG]

In the line 'always @(posedge clk or posedge rst ) begin', try removing the 'or posedge rst'.  Quartus hates that when you try multiple assignments to a logic.

Also, in addition, maybe disable line 4 if the top line doesn't work.

[nockieboy]

In the line 'always @(posedge clk or posedge rst ) begin', try removing the 'or posedge rst'.  Quartus hates that when you try multiple assignments to a logic.

Also, in addition, maybe disable line 4 if the top line doesn't work.

Thanks BrianHG, that fixes that issue.  Even fixing some more errors after this last one, it seems I'm not out of the woods yet.

Now getting these errors that I'm not sure how to fix:

Error (10170): Verilog HDL syntax error at sd_data_master.v(118) near text: ")";  expecting an operand. Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10170): Verilog HDL syntax error at sd_data_master.v(121) near text: "else";  expecting "end". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10170): Verilog HDL syntax error at sd_data_master.v(121) near text: ")";  expecting an operand. Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10170): Verilog HDL syntax error at sd_data_master.v(124) near text: "else";  expecting "end". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10170): Verilog HDL syntax error at sd_data_master.v(325) near text: ")";  expecting an operand. Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error (10112): Ignored design unit "sd_data_master" at sd_data_master.v(3) due to previous errors
Error: Quartus Prime Analysis & Synthesis was unsuccessful. 6 errors, 6 warnings
   Error: Peak virtual memory: 4745 megabytes
   Error: Processing ended: Fri Mar 18 20:15:16 2022
   Error: Elapsed time: 00:00:05
   Error: Total CPU time (on all processors): 00:00:12
Error (293001): Quartus Prime Full Compilation was unsuccessful. 8 errors, 6 warnings

I can't see a typo in the lines referred to, but the sensitivity list for the always block the code is within is pretty long:

Code: [Select]

always @ (state or resend_try_cnt or tx_full or free_tx_bd or free_rx_bd or bd_cnt or send_done or rec_done or rec_failed or trans_done or trans_failed)
begin : FSM_COMBO
 next_state  = 0;   
case(state) 
 
  IDLE: begin
   if (free_tx_bd !=`BD_EMPTY)begin   <--- LINE 118
      next_state = GET_TX_BD;
   end
   else if (free_rx_bd !=`BD_EMPTY) begin  <-- LINE 121
      next_state = GET_RX_BD;
   end 
   else begin                        <--- LINE 124
      next_state = IDLE;
   end
  end
There I was thinking I'd be spending most of my time picking the Wishbone interface apart, instead I can't even get the darn project to compile.   At this rate, I think I'll be switching to the far simpler SPI version of the SD card interface and just make do with the 'poor' transfer rates - they'll be more authentic, I suppose.

[nockieboy]

I've found an updated repo using the same SD controller code but heavily modified so that it actually compiles, which is a start and means I can focus on wiring it all up.

Have a question, though.  The SD interface needs access to the DDR3 RAM as I'd like to be able to use a buffer in DDR3 RAM to read from/write to, that the host can access as well.   Can I just increase PORT_TOTAL to 6 and wire the SD DMA to the new port, or are there any concerns/considerations if I up the total ports accessing the DDR3_controller to 6?

[BrianHG]

I've found an updated repo using the same SD controller code but heavily modified so that it actually compiles, which is a start and means I can focus on wiring it all up.

Have a question, though.  The SD interface needs access to the DDR3 RAM as I'd like to be able to use a buffer in DDR3 RAM to read from/write to, that the host can access as well.   Can I just increase PORT_TOTAL to 6 and wire the SD DMA to the new port, or are there any concerns/considerations if I up the total ports accessing the DDR3_controller to 6?

No problem, direct connection to the DDR3 with an additional port #/total is allowed.
No fifo buffer needed, the SD card is too slow anyways, so long as you can pause the SD card reader's reads and writes.

[nockieboy]

I've found an updated repo using the same SD controller code but heavily modified so that it actually compiles, which is a start and means I can focus on wiring it all up.

Have a question, though.  The SD interface needs access to the DDR3 RAM as I'd like to be able to use a buffer in DDR3 RAM to read from/write to, that the host can access as well.   Can I just increase PORT_TOTAL to 6 and wire the SD DMA to the new port, or are there any concerns/considerations if I up the total ports accessing the DDR3_controller to 6?

No problem, direct connection to the DDR3 with an additional port #/total is allowed.
No fifo buffer needed, the SD card is too slow anyways, so long as you can pause the SD card reader's reads and writes.

Ah great.   I'm working on an interface that will sit between the SD's Wishbone interface and the DDR3 controller at the moment.  At first glance it appears all that's needed is some wires to connect different signals together, but I'm sure it won't be that simple once I drill down into it.

I'm not confident in my ability or knowledge enough to strip out the Wishbone interface from the SD project I'm using, so I thought it might be simpler to just work with it instead.  We'll see.

[nockieboy]

I've just finished the DDR3_Controller to Wishbone interface - I don't suppose you'd mind casting your eye over it when you can to point out any obvious mistakes I've made?

I put this together based on the READ/WRITE cycle diagrams on pages 47-50 of the Wishbone B3 specification document here.  Note that the interface isn't intended to support block read/writes, as it seems the Wishbone bus coming out of the SD interface doesn't require them (there's no LOCK_O signal in that interface).

The interface is clocked by CMD_CLK, which is also used to clock the SD interface / Wishbone bus.  I've still got to have to have a closer look at the sel_i signals - I don't suppose it's likely that they work the same way or mean the same thing as CMD_write_mask.

Zip attached has the new interface module and the current GPU_DECA_DDR3_top module, so you can see how the DDR3_wb_interface module is connected up.

EDIT:  Just fixed a typo on line 92 - STB_O instead of STB_I, and removed line 62 which zeroed DAT_O, which wasn't required.