0

I have a Lattice Diamond project for an SPI multiplexer, which has the following module definition:

module spimux
(
input bmck,
input bssel,
input bmosi,
output bmiso,
input[3:0] a,
output[13:0] mck,
output[13:0] ssel,
output[13:0] mosi,
input[13:0] miso,
output reg[7:0] LED
);

OutputMux bmiso_mux (
    .clk(osc_clk),
    .out(bmiso),
    .a(a),
    .in(miso)
    );

// the idea here is that on each rising clock edge, the module will take
// the 4-bit address a and then set *one* of the 14 bits in "in".  One
// problem I see is that I don't prevent an invalid address of 0b1111 or
// 0b1110 from getting used.
module OutputMux
(
input clk,
output reg out,
input[3:0] a,
input[13:0] in
);

reg mask;

always @(posedge clk) begin
    // I tried this and it didn't help my situation
    //out <= (in & (14'b1 << a));
    // so I tried to assign to a temp variable and then do the bitmasking.. no change.
    mask = 14'b1 << a;
    out <= (in[13:0] & mask);
end

endmodule

endmodule

When I go into the Spreadsheet View to assign my pins, not all of them show up in the Signal Name droplist. For example, it looks like this:

enter image description here

You'll see that miso[0] is in there as an Input Port, but all of the other 13 miso bits are not. In addition, bmck, bssel, and bmosi are missing. They have not yet been assigned to any other pins, so can anyone explain why they would not be there?

Paebbels
  • 15,573
  • 13
  • 70
  • 139
Dave
  • 14,618
  • 13
  • 91
  • 145
  • 1
    How do you drive `LED` in your `spimux` module? – Qiu Nov 19 '14 at 18:36
  • @Qiu thanks, I just checked that. Turns out I had a typo and was only driving half of the LEDs! – Dave Nov 19 '14 at 20:06
  • I'm going to change this question because I have another issue. – Dave Nov 19 '14 at 20:08
  • @Qiu based on the solution to my previous problem, is it fair to assume that the missing signal names are due to incorrect assignments in my other modules? – Dave Nov 19 '14 at 20:15
  • Yes, it's possible that some of your logic was simply synthesised away. – Qiu Nov 19 '14 at 20:37
  • I'll add more code shortly. – Dave Nov 19 '14 at 20:56
  • It dawned on me that I should look for a tool to make testing Verilog easier for the newbies (i.e. me). I found http://www.compileonline.com/compile_verilog_online.php, which is actually very useful for me to test out my bitmasking and shifting. There is definitely a bug in my logic due to my lack of understanding of Verilog syntax. – Dave Nov 19 '14 at 21:19

1 Answers1

0

Thanks to Qiu for getting me going in the right general direction. I should have guessed that the signal name list is generated after compiling the Verilog code, so if the output/input isn't getting used, you won't need to map it to a pin.

Using compileonline.com, I was able to quickly iterate over my Verilog logic statements and figure out where the problem came from. For miso, I was able to make them appear by changing my always block to look like this:

always @(posedge clk) begin
    out = (in[13:0] & (14'b1 << a)) > 0;
end

The idea here is really simple -- out of all of the MISO inputs entering the FPGA, we only want to look at the one coming from the SPI device that is currently selected (identified by address a). We just need to set out to the value of the bit identified by a. After masking, the value is going to be 0 or !0, so we just write this to out.

I wanted to use a reduction operator, but the online compiler didn't seem to work with this notation, so I just compared to 0 instead, which seems to work. I still have to test this on hardware.

Dave
  • 14,618
  • 13
  • 91
  • 145