FPGA VGA Controller for 8-bit computer

[nockieboy]

Try this fix:
Read any GPU memory location which is at least 16 bytes outside the read address you desire forcing the old read data in the DDR3 Z80's read cache to be dumped.
Now, read the address you actually want to read, now being on a different cache bank read address, this will now force a fetch direct from the DDR3.

Ah yes, that does it.    I had the idea to try that earlier, but didn't bother for some reason.

Would a fix for this be easy enough to do, or shall I just remember this 'hack' for whenever I need to read the SD buffer?

[BrianHG]

Try this fix:
Read any GPU memory location which is at least 16 bytes outside the read address you desire forcing the old read data in the DDR3 Z80's read cache to be dumped.
Now, read the address you actually want to read, now being on a different cache bank read address, this will now force a fetch direct from the DDR3.

Ah yes, that does it.    I had the idea to try that earlier, but didn't bother for some reason.

Would a fix for this be easy enough to do, or shall I just remember this 'hack' for whenever I need to read the SD buffer?

Or any other device which can write to the DDR3.  For example, if your Z80 wrote and monitored a byte while the RS232 debugger edit's a memory address, the Z80 will not see the change until the Z80 once again flushes it's cache.

I'm thinking of enhancing my ddr3 with version 2.0 to look for such cross-multiport writes.

[BrianHG]

I can imagine the same situation for the SD card interface.

If you tell the SD-Card to read 4 bytes from DDR3 to write to the card.  If after that the Z80 changes those 4 bytes and you tell the SD-Card to write the same 4 bytes again without any other DDR3 read access from the SD-Card, the SD interface will not see the new 4 bytes that the Z80 wrote.

[nockieboy]

I can imagine the same situation for the SD card interface.

If you tell the SD-Card to read 4 bytes from DDR3 to write to the card.  If after that the Z80 changes those 4 bytes and you tell the SD-Card to write the same 4 bytes again without any other DDR3 read access from the SD-Card, the SD interface will not see the new 4 bytes that the Z80 wrote.

Hmmm, yes, possibly. I suppose there's a number of scenarios where the cross-cache-hit issue will be a problem - if not for the SD peripheral, then possibly for others that we haven't yet implemented or thought of.

[BrianHG]

Well, all you have left is my VGA processor, and believe me, it reads way more than the size of the DDR3 read cache...

[nockieboy]

Well, all you have left is my VGA processor, and believe me, it reads way more than the size of the DDR3 read cache...

I think the project is hitting around 82% LE usage.  I can't run a build at the moment so I'm working from memory, but I think it has around 8,000 LEs left.  I guess that should be enough for everything; VGA processor, 8-bit programmable sound generator, maybe even a softcore Z80 processor. 

[BrianHG]

We'll have to check and see if the SD card reader is using logic elements as a data buffer, or ram blocks.  You should only be at ~65% full.  Using LE for data buffer eats up so many.

As for a Z80 softcore, we are talking something like 1k logic elements.
Audio will be around 1-2k LE depending on how you do it and how many features and channels, like 16bit stereo, 16 channels would eat ~2k LE.

What else do you want to put in there.

RS232 Com ports are something like 150LE.
Old fashioned joystick ports are something 20 LE.
I don't know about USB.  I guess it depends on the USB interface chip.

[nockieboy]

We'll have to check and see if the SD card reader is using logic elements as a data buffer, or ram blocks.  You should only be at ~65% full.  Using LE for data buffer eats up so many.

The project stats without my SignalTap instance:

39,451 / 49,760 LEs (79%)
24135 registers
796,392 / 1,677,312 memory bits (47%)

According to Quartus, the SD controller is using 2,449 combinational ALUTs, 1,785 dedicated logic registers, 1,024 memory bits, 2 DSP elements and one DSP 18x18...

As for a Z80 softcore, we are talking something like 1k logic elements.
Audio will be around 1-2k LE depending on how you do it and how many features and channels, like 16bit stereo, 16 channels would eat ~2k LE.

This is a subject for a whole other thread, or section of this one, but as you've mentioned it: 

Initially at least, my requirements for audio are very limited - just a straight simulation of the AY-3-8910 PSG is all I want.  I have a Verilog module that does just that - but it has three analogue outputs (like the real chip), which ideally would be output directly to an audio amp, so I am glacially slowly researching how I would interface it's outputs to the audio DAC on the DECA board.  EDIT:  I've just found a YM2149 project (essentially the same as the AY) with a 14-bit PCM output - the only downside is it's in VHDL, but so long as it works then that shouldn't be a problem.  It's a bit annoying that there aren't a lot of DECA projects out there, and most (if not all) of the example projects supplied for the DECA all use a NIOS core, making reverse-engineering how the audio works an opaque and difficult process that I have little time for at the moment.  I'll be going to the datasheet for the DAC chip and seeing if I can work out how to send data to it.

I'm actually really surprised at how 'simple' the module is to emulate the PSG.  I don't understand any of it - analogue electronics and music is a dark art to me at the best of times - but it surprises me how apparently basic the HDL is to replicate an (admittedly very basic) programmable sound generator chip.

What else do you want to put in there.

RS232 Com ports are something like 150LE.
Old fashioned joystick ports are something 20 LE.
I don't know about USB.  I guess it depends on the USB interface chip.

USB won't take up many LEs at all - it'll be around 150LE like the RS232 com ports you've quoted, as I'm likely to use a CH559 as the USB host chip and link this to the FPGA via serial (or SPI if I ever get time to really put some effort into researching/working on the CH559 more).  I have created dev boards to test out the RP2040, SAMD21 (boards already exist for these two, I know, but they all have mini/micro USB ports and I like designing and making boards! ) and CH559 and the CH559 seems to be winning out thanks to simplicity, cost and requiring least supporting components.  It also supports two USB slave ports 'out of the box', so attaching a keyboard and mouse would be simples.  I just need more hours in the day to work on all this stuff.

[nockieboy]

Actually, ignore most of what I've said about audio output to the DAC above.  I forgot about the HDMI audio pathway, which is much more preferable as it doesn't require headphones, or an external amplifier, or messing around learning how to use the TLV320AIC3254 on the DECA.  I just need to feed a suitable audio signal to the HDMI output module.

[BrianHG]

Actually, ignore most of what I've said about audio output to the DAC above.  I forgot about the HDMI audio pathway, which is much more preferable as it doesn't require headphones, or an external amplifier, or messing around learning how to use the TLV320AIC3254 on the DECA.  I just need to feed a suitable audio signal to the HDMI output module.

I'm sorry to tell you this, but,... the HDMI audio pathway uses the same exact I2S audio port as the TLV320AIC3254.  Pin for Pin compatible.  If you are going to learn how to use the HDMI audio out port, then you are learning the TLV320AIC3254, just that you will ignore the serial audio input pin which runs in parallel containing the sampled Line-In audio.  You might as well just tie the 2 I2S busses together in Quartus and have simultaneous headphone line out and HDMI audio out running both at the same time in parallel.

[nockieboy]

I'm sorry to tell you this, but,... the HDMI audio pathway uses the same exact I2S audio port as the TLV320AIC3254.  Pin for Pin compatible.  If you are going to learn how to use the HDMI audio out port, then you are learning the TLV320AIC3254, just that you will ignore the serial audio input pin which runs in parallel containing the sampled Line-In audio.  You might as well just tie the 2 I2S busses together in Quartus and have simultaneous headphone line out and HDMI audio out running both at the same time in parallel.

Ah nuts. Never mind.   I'll work it out when I get to it.  Must get the SD interface working first!

[BrianHG]

I'm sorry to tell you this, but,... the HDMI audio pathway uses the same exact I2S audio port as the TLV320AIC3254.  Pin for Pin compatible.  If you are going to learn how to use the HDMI audio out port, then you are learning the TLV320AIC3254, just that you will ignore the serial audio input pin which runs in parallel containing the sampled Line-In audio.  You might as well just tie the 2 I2S busses together in Quartus and have simultaneous headphone line out and HDMI audio out running both at the same time in parallel.

Ah nuts. Never mind.   I'll work it out when I get to it.  Must get the SD interface working first!

Yes.

The TLV320AIC3254 has an I2C control port where you will need to set a few regs, just like the HDMI transmitter, but it can be setup to be compatible with I2S audio bus.  With a simple I2S LUT map, you will basically be setting sample rate, audio filter, which input and the bit direction and word length of the I2S port.

SEE this file as an example: https://github.com/BrianHGinc/BrianHG-DDR3-Controller/blob/main/BrianHG_DDR3_DECA_GFX_DEMO_v15_300MHz_HR/I2C_HDMI_Config.v

Just a copy & paste with a different host address and different look-up-table at the bottom of the file.

[BrianHG]

Ok, it's been around a week.  Anything new to see?  Any new bugs found?

[nockieboy]

Ok, it's been around a week.  Anything new to see?  Any new bugs found?

Uh no, not this week anyway - have been really too busy to even look at it until just now.  Made some progress last week, however I've hit a bit of a block with the SD interface.  I can read sectors from the SD card, and have even managed to write a sector once (haven't been able to repeat that feat).  The problems I'm facing are:

• Sector data read from SD card by the Z80 doesn't match what HxD tells me is on the SD card.  It seems valid; Sector 0 when read for example ends with 0x55 0xAA bytes at the end of the sector which is expected, but the rest of the previous 510 bytes don't match Sector 0 on the SD card.
• The 512 bytes I did manage to write to the SD card last week is still there and I can read it back, though, so I know read is working, it's just a question of where it's reading from and writing to!  HxD can't find the data in Sector 1 that I wrote with the Z80, so either the SD interface is lying about where it's read/writing to, or HxD is telling porkies instead and not showing me the full picture on the SD card.
• I'm getting some other odd behaviour which made debugging the above issues problematic; it only seems to read every other time I send CMD17, I'm getting weird errors back even when a read appears to have worked, and CMD24 (write sector) isn't working currently and is resulting in weird error behaviour.

I've gone as far as contacting the author of the SD interface IP, but he's a busy guy and made the interface a long time ago, so he's not really able to help much with my very specific use-case.

I'll have some more time this week to start plugging away at the problem(s) again, but I'm not feeling confident and wondering if the only option is to scrap this IP and see if I can find another, simpler, example that I can use.

[BrianHG]

Is there an SD card reader which comes with the DECA cd?  And, who made it?  Is it complex, or can you edit it?

maybe : https://github.com/xesscorp/VHDL_Lib/blob/master/SDCard.vhd
However, it looks like it's 1 bit bus.


take a look here, they seem to support 4bit mode: https://github.com/WangXuan95/FPGA-SDcard-Reader
Also, if you want to ignore the file system and make the Z80 handle that, the code really shrinks down to 2 tiny modules.  However, can it write?


Just so we are clear, if you programmed this from scratch yourself giving simple read, erase, write access to an SD card and programmed the Z80 with the file system, it might have already been done and working as the interface isn't much more complex than the I2S audio bus, though you still need to read the specification.

[nockieboy]

Is there an SD card reader which comes with the DECA cd?  And, who made it?  Is it complex, or can you edit it?

Yes, there's an example project in the DECA materials, but it uses a NIOS core which puts it well out of my ability to pull it apart and understand what's going on (at the moment, anyway).

maybe : https://github.com/xesscorp/VHDL_Lib/blob/master/SDCard.vhd
However, it looks like it's 1 bit bus.

1-bit SPI by the looks of it, and would involve a little editing of the VHDL to make it work, which I have little confidence in doing without causing more problems.

take a look here, they seem to support 4bit mode: https://github.com/WangXuan95/FPGA-SDcard-Reader
Also, if you want to ignore the file system and make the Z80 handle that, the code really shrinks down to 2 tiny modules.  However, can it write?

No, it can't.  Funnily enough I'd looked at this project before starting on the SD journey, as it looks perfect for what I want and looks like it provides a possible future upgrade path to allow me to access files by filename on a FAT32 USB stick, potentially allowing me to break away from CP/M-formatted storage and use easily readable non-Jurassic storage filesystems.  The only issue is I need to write a write function.  I'll probably give that project a try this week to see how stable/effective it is at reading data and get my head around what I need to do to write a write block function for it.

Just so we are clear, if you programmed this from scratch yourself giving simple read, erase, write access to an SD card and programmed the Z80 with the file system, it might have already been done and working as the interface isn't much more complex than the I2S audio bus, though you still need to read the specification.

Without you leading me through it like you have done with all the GPU work, I'd still be reading the specifications and throwing random HDL at the wall to see what sticks.   I don't need a file system at all, but I also want something better than a 1-bit SPI interface.  All I need is that and sector access to the SD card.  CP/M handles the filesystem as part of its BDOS module, all I'm doing is providing low-level hardware access to the SD card for the BDOS.  The BIOS already handles blocking/de-blocking for writes and reads to the CF card as that handles 512-byte transactions, so really there's not much to do once I get the read/write access to the SD card sorted.  The reason I went with the IP I'm using currently is because of the fast 4-bit access, but I think I'll cut it free and look at the other project you've mentioned again.

[nockieboy]

Okay, I have sector reads working with the modules attached below.

SDInterface.sv is the top-level of the SD interface, instantiated in GPU_DECA_DDR3_top as 'SID'.  I started writing this module last November (and I'd forgotten about it - it's fun being me) and it acts as an interface between the SDReader.sv module and the rest of the GPU/uCOM.  Its primary purpose is to send the sector address and a read request pulse to SDReader.sv when the host requests it and collates data returned from SDReader.sv (which is received a byte at a time) into a 16-byte cache.  When the cache is full, it's written to DDR3 memory as a single 128 bit-wide write transaction.  It also keeps track of the DDR3 buffer location (currently hardwired to 0x5000, but I might make this a register so the host can move it around if needed) and fills the 512-byte buffer in DDR3 memory with 32 successive writes over the course of the SD sector read.

SDReader.sv and SDCmdCtrl.sv are from a project very similar to the one BrianHG linked here:

take a look here, they seem to support 4bit mode: https://github.com/WangXuan95/FPGA-SDcard-Reader
Also, if you want to ignore the file system and make the Z80 handle that, the code really shrinks down to 2 tiny modules.  However, can it write?

Reads seem to be working perfectly - I still have some work to get the STATUS data out of the SDInterface module to Bridgette (it's an 8-bit value made up of a number of different signals); I'm looking into why it never changes from 0x00 currently, but other than that it's reading the SD sectors with no issues.  Ironically, it's reading the exact data that the last iteration of the interface wrote to the SD card.  I need to low-level reformat the SD card with FAT32 again and I'll see if I can get MBR data from it.

With no registers to worry about, all I have to do is set the sector address (using the same method I used previously to set any of the 32-bit registers in the previous version of the interface) and the read is executed when the 4th byte is written to Bridgette, making for a much simpler interface.  Also, there's no errors being returned (no feature for them), which is both good and bad, but sequential sector reads are working fine - no 'only working every odd attempt' like with the last version interface.

Once I've got the STATUS output working, I'll start looking at adding write functionality to the interface.  Further down the line will be opening it up from 1-bit to 4-bit transfers too.

EDIT:  Have reversed the byte-order for loading the cache in SDInterface.sv so each 16-byte write is in the correct sequence now. 

EDIT 2: Attached latest files with correct-order byte output.  With the SD card reformatted, I'm now able to read the MBR with no issues.

[nockieboy]

This is frustrating me - I'm trying to set an 8-bit output port to a collection of other signals, so the host can query the status of the SD read and know when it's complete, amongst other things, rather than clumsily setting a timer or reading a memory location for a change of value (risky if the value doesn't change, e.g.).

The component values change - I can see in SignalTap that CARDTYPE, for example, has the value 3.  STATUS, however, remains zero throughout.  What am I doing wrong?

Here's the SignalTap showing CARDTYPE, SIDSTATE, RD_RDY, SID_BUSY - all have changing values at appropriate times:

Code: [Select]

// SD Interface v0.1
//
// Connects the SD modules to the rest of the GPU and manages the
// 4KB dual-port M9K block RAM read/write buffer.
//
// TODO: Handle write requests to the SD card.

module SDInterface #(

    parameter int          CLK_DIV     = 3,      // clock divider
    parameter int          BUFFER_ADDR = 'h5000  // default DDR3 buffer location

)(

    input  logic           CLK,            // 100MHz system clock
    input  logic           RESET,          // reset active HIGH
    // interface <-> Bridgette
    input  logic           RD_REQ,         // HIGH for read request
    input  logic   [ 31:0] SECTOR,         // sector number to read/write
    output logic           RD_RDY,         // HIGH when read is complete from SD card
    output logic           SD_BUSY,        // HIGH when interface is busy
    output logic   [  3:0] SIDSTATE,       // current state machine value
    output logic   [  1:0] CARDTYPE,       // SD card type
    output logic           BUSY,           // HIGH when SDInterface is busy
    output logic   [  7:0] STATUS,         ****** THIS IS ALWAYS ZERO ******
    // SD phy connections
    inout  logic   [  3:0] SD_DATA,        // data from SDReader.sv
    inout                  SD_CMD,         // CMD signal to SDReader.sv
    output logic           SD_CLK,         // clock signal to SD card
    output logic           SD_CMD_DIR,     // HIGH = TO SD card, LOW = FROM SD card
    output logic           SD_D0_DIR,      // HIGH = TO SD card, LOW = FROM SD card
    output logic           SD_D123_DIR,    // HIGH = TO SD card, LOW = FROM SD card
    output logic           SD_SEL,         // SD select
    // DDR3 connections
    //    input  (DDR3 -> SD WR ops)
    input  logic           DDR3_busy,      // HIGH when DDR3 is busy
    input  logic   [127:0] DDR3_rd_data,   // read data from DDR3
    input  logic           DDR3_rd_rdy,    // data from DDR3 is ready
    //    output (SD -> DDR3 RD ops)
    output logic    [31:0] DDR3_addr_o,
    output logic           DDR3_ena,       // Flag HIGH for 1 CMD_CLK when sending a DDR3 command
    output logic           DDR3_wr_ena,    // HIGH signals write request to DDR3 Controller
    output logic   [127:0] DDR3_wr_data,   // 128-bit data bus
    output logic    [15:0] DDR3_wr_mask    // Write data enable mask

);

// data IO for read and write data, to connect to buffer
wire          cache_wren ;
wire          rd_ready   ;
wire          rd_req     ; // HIGH when not BUSY and RD_REQ is made by Bridgette
wire    [1:0] cardtype   ;
wire    [3:0] sd_state   ;
wire          sd_busy    ;

logic         cache_full ; // HIGH when 16-byte cache is full
logic         rEna       ; // HIGH whilst rData is being sent
logic [  7:0] SD_rData   ; // Data read from cache
logic [  8:0] buf_ptr    ; // 512-byte buffer address pointer
logic [  3:0] data_ptr   ; // pointer to current byte in cache
logic [127:0] data_cache ; // temporary 16-byte storage to be written to DDR3 or SD

//                          1         2          4        1
assign STATUS       = '{ rd_ready, cardtype, sd_state, sd_busy } ;    ******** THIS IS WHERE STATUS' VALUE IS SET ********
assign RD_RDY       = rd_ready                 ;
assign CARDTYPE     = cardtype                 ;
assign SIDSTATE     = sd_state                 ;
assign SD_BUSY      = sd_busy                  ;
assign rd_req       = BUSY ? 1'b0 : RD_REQ     ; // only pass rd_req if interface isn't busy
// DDR3 Write Request
assign DDR3_wr_ena  = cache_full && !DDR3_busy ; // Set the write enable.
assign DDR3_wr_data = data_cache               ; // Send write data.
assign DDR3_wr_mask = 16'hFFFF                 ; // Write enable for the byte.
// DDR3 transaction controls
assign DDR3_addr_o  = BUFFER_ADDR + buf_ptr    ; // DDR3 write address.
assign DDR3_ena     = DDR3_wr_ena              ; // Write full 128-bits.

// For more detail, see SDReader.sv
SDReader #(

    .CLK_DIV         ( CLK_DIV     )  // because clk=100MHz, CLK_DIV is set to 2 - see SDReader.sv for detail

) SDReader_inst(

    .clk             ( CLK         ),
    .rst_n           ( !RESET      ), // rst_n is active low, so RESET must be inverted
   
    // signals connect to SD bus
    .sdclk           ( SD_CLK      ),
    .sdcmd           ( SD_CMD      ),
    .sddat           ( SD_DATA     ),
   
    // bus direction controls
    .SD_CMD_DIR      ( SD_CMD_DIR  ), // HIGH = TO SD card, LOW = FROM SD card
    .SD_D0_DIR       ( SD_D0_DIR   ), // HIGH = TO SD card, LOW = FROM SD card
    .SD_D123_DIR     ( SD_D123_DIR ), // HIGH = TO SD card, LOW = FROM SD card
    .SD_SEL          ( SD_SEL      ), // SD socket select

    // status and information
    .card_type       ( cardtype    ), // 0=Unknown, 1=SDv1.1 , 2=SDv2 , 3=SDHCv2
    .card_stat       ( sd_state    ), // current state of SDReader's state machine
   
    // user read sector command interface
    .rstart          ( rd_req      ), // rstart HIGH starts read operation
    .rsector_no      ( SECTOR      ), // target sector to read in SDcard
    .rbusy           ( sd_busy     ), // signals read is ongoing or complete
    .rdone           ( rd_ready    ), // signals read is complete   ********* EVEN ASSIGNING STATUS TO THE PORT DIRECTLY DOESN'T WORK ***********
   
    // sector data output interface
    .outreq          ( cache_wren  ), // HIGH whilst data is received from SD card (for each byte?)
    .outaddr         ( readAddr    ), // cache address to be written to
    .outbyte         ( SD_rData    )  // data read from SD card

);

always @( posedge CLK ) begin

    if ( RESET ) begin

        buf_ptr    <= 'hFF0  ; // start at 0xFF0 so when first read completes, buf_ptr = 0 for first memory write
        cache_full <= 1'b0   ;
        data_cache <= 128'b0 ;
        data_ptr   <= 4'b0   ;
        BUSY       <= 1'b0   ;

    end else if ( rd_req ) begin // new read request received

        buf_ptr    <= 'hFF0  ;
        BUSY       <= 1'b1   ;

    end else if ( !RD_RDY && cache_full && !DDR3_busy ) begin // 16-byte cache is full

        cache_full <= 1'b0   ;

    end else if ( RD_RDY ) begin // End of SD Read; reset pointers and data bus
   
        buf_ptr    <= 'hFF0  ;
        cache_full <= 1'b0   ;
        data_cache <= 128'b0 ;
        data_ptr   <= 4'b0   ;
        BUSY       <= 1'b0   ;

    end else if ( cache_wren ) begin // byte received from SDReader

        case ( data_ptr )

            0  : data_cache[127:120] <= SD_rData ; // 127-120
            1  : data_cache[119:112] <= SD_rData ; // 119-112
            2  : data_cache[111:104] <= SD_rData ; // 111-104
            3  : data_cache[103: 96] <= SD_rData ; // 103-96
            4  : data_cache[ 95: 88] <= SD_rData ; // 95-88
            5  : data_cache[ 87: 80] <= SD_rData ; // 87-80
            6  : data_cache[ 79: 72] <= SD_rData ; // 79-72
            7  : data_cache[ 71: 64] <= SD_rData ; // 71-64
            8  : data_cache[ 63: 56] <= SD_rData ; // 63-56
            9  : data_cache[ 55: 48] <= SD_rData ; // 55-48
            10 : data_cache[ 47: 40] <= SD_rData ; // 47-40
            11 : data_cache[ 39: 32] <= SD_rData ; // 39-32
            12 : data_cache[ 31: 24] <= SD_rData ; // 31-24
            13 : data_cache[ 23: 16] <= SD_rData ; // 23-16
            14 : data_cache[ 15:  8] <= SD_rData ; // 15-8
            15 : begin
                 data_cache[  7:  0] <= SD_rData ; // 7-0
                 cache_full          <= 1'b1     ;
            end

        endcase
        buf_ptr  <= buf_ptr  + 1'b1 ;
        data_ptr <= data_ptr + 1'b1 ;

    end

end

endmodule

[BrianHG]

What happens if you trigger on the signal tap on the RD_RDY (this may be a 1clk pulse on only pulse during certain commands) or wait for the SD_BUSY (this may be a more true state of the SD card interface) to go low?

Maybe the SD_BUSY never toggles because the controller can accept more than 1 command before it's command buffer gets full?

[nockieboy]

What happens if you trigger on the signal tap on the RD_RDY (this may be a 1clk pulse on only pulse during certain commands) or wait for the SD_BUSY (this may be a more true state of the SD card interface) to go low?

This next image is triggered on the rising edge of RD_RDY:

Maybe the SD_BUSY never toggles because the controller can accept more than 1 command before it's command buffer gets full?

It's not SD_BUSY that's the issue - it's STATUS.  It remains zero throughout, despite RD_RDY, CARDTYPE, SIDSTATE and SD_BUSY all having non-zero values.  This next line doesn't seem to be working:

Code: [Select]

assign STATUS       = '{ rd_ready, cardtype, sd_state, sd_busy } ;
Originally I had used the port names instead of wire names for RD_RDY, CARDTYPE etc, but I couldn't get them to show up in the node finder.

[nockieboy]

Never mind, fixed it.  Removed the apostrophe from the start of the array declaration and added in the size for STATUS and it works now.

Code: [Select]

assign STATUS       = '{ rd_ready, cardtype, sd_state, sd_busy } ;
Should be:

Code: [Select]

assign STATUS[7:0] = { rd_ready, cardtype, sd_state, sd_busy } ;

[BrianHG]

assign STATUS       = ' { rd_ready, cardtype, sd_state, sd_busy } ;

Do not use a ' in front of a brace unless you are filling an array of data.  Status is not a multidimensional array, it is a wire or reg 8 bits wide, but 1 multidimensional word, not 4 8 bit words.


If that doesn't help, then try changing:

    output logic   [  7:0] STATUS,         ****** THIS IS ALWAYS ZERO ******
to:
    output           [  7:0] STATUS,         ****** THIS IS ALWAYS ZERO ******
or:
    output wire    [  7:0] STATUS,         ****** THIS IS ALWAYS ZERO ******

[BrianHG]

Shit, if I didn't preview, I would have posted the answer just before you.

[nockieboy]

Shit, if I didn't preview, I would have posted the answer just before you.

 

[nockieboy]

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.