Jump to content
  • 0

PmodMIC with BASYS 3


small_vhdl_projects

Question

Hello everyone,

I'm doing a little project where I use a PmodMIC and a Digilent BASYS 3 board.

I understand all the code that is been given (https://github.com/bhanderson/ee324/blob/master/andrew/audioRec/PmodMicRefComp.vhd#L227), but I want to get the data to the leds on my board.

My goal is to show how loud it is in a room on the leds. So for example if it's very loud all the leds shine, if it's not so loud only a few leds brighten up.

But I don't know how I get the DATA on my leds, en how to see what loud or soft is, can someone help me with that?

Also, if I put my PmodMIC on connector JA , what do I have to change in my entity/.XDC file?

 

Thanks for reading and answering!

Small_vhdl_projects guy

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

Hey guy,

From what I can tell, the 12 bit DATA coming from the PmodMICs analog-digital converter is already a scaled version of the volume. So the major design steps will be creating a state machine to handle fetching data from the reference component as well as determining how to convert the data into good looking LED patterns. I am not sure of the default scaling of the microphone, so you may have to experiment to find what the maximum volume you want to represent is. With a maximum volume, it should be fairly straightforward to represent the volume level on the leds, by lighting each one up if the volume has passed an appropriate threshold. For Verilog, I'd be thinking along the lines of:

assign led[0] = (volume > 2**8) ? 1'b1 : 1'b0;
assign led[1] = (volume > 2**9) ? 1'b1 : 1'b0;
assign led[2] = (volume > 2**10) ? 1'b1 : 1'b0;
assign led[3] = (volume > 2**11) ? 1'b1 : 1'b0;

These thresholds, and how they scale with increasing volume, are fairly arbitrary, depending on how you want the led pattern to look. I might just start up by writing the data fetcher state machine and running the project with the binary data tied directly to the leds, to take a look at the raw data before any modification.

As for the XDC file, I'd use the Basys3 Master XDC, found in the sidebar here. Lines 124-148 contain the pin descriptions for JA, if you want to attach the MIC to the top row of JA, the signal names for JA[0] to JA[3] need to be replaced with the pin names (1 to 4) for the MIC, in the order presented in the reference manual.

Hope this helps!

Arthur

Link to comment
Share on other sites

17 hours ago, artvvb said:

Hey guy,

From what I can tell, the 12 bit DATA coming from the PmodMICs analog-digital converter is already a scaled version of the volume. So the major design steps will be creating a state machine to handle fetching data from the reference component as well as determining how to convert the data into good looking LED patterns. I am not sure of the default scaling of the microphone, so you may have to experiment to find what the maximum volume you want to represent is. With a maximum volume, it should be fairly straightforward to represent the volume level on the leds, by lighting each one up if the volume has passed an appropriate threshold. For Verilog, I'd be thinking along the lines of:


assign led[0] = (volume > 2**8) ? 1'b1 : 1'b0;
assign led[1] = (volume > 2**9) ? 1'b1 : 1'b0;
assign led[2] = (volume > 2**10) ? 1'b1 : 1'b0;
assign led[3] = (volume > 2**11) ? 1'b1 : 1'b0;

These thresholds, and how they scale with increasing volume, are fairly arbitrary, depending on how you want the led pattern to look. I might just start up by writing the data fetcher state machine and running the project with the binary data tied directly to the leds, to take a look at the raw data before any modification.

As for the XDC file, I'd use the Basys3 Master XDC, found in the sidebar here. Lines 124-148 contain the pin descriptions for JA, if you want to attach the MIC to the top row of JA, the signal names for JA[0] to JA[3] need to be replaced with the pin names (1 to 4) for the MIC, in the order presented in the reference manual.

Hope this helps!

Arthur

Thank you for your answer and advice!

I tried to do the steps you said, but now I get an ERROR saying:

[DRC 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 19 out of 31 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: DATA[11:0], CLK, RST, SDATA, SCLK, nCS, START, DONE.(1 more like this).

 

I don't know what to do now, can you help me any further?

Do I need something like "CLK => CLK" or something ? (sorry I'm a newbie)

 

Greets!

Guy
 

Link to comment
Share on other sites

@small_vhdl_projects

Your problem now lies within your XDC file.  This message shows up any time you have input or output ports to your top level RTL (VHDL or Verilog) file that aren't defined in your XDC file.  The XDC file is what maps these pins to names.  Hence, once you grab the XDC file for your device, you need to edit it so that your names match the names within the file.  Further, any pins from that master XDC file that aren't used, you will need to comment out.  That'll get you another step further.

Dan

Link to comment
Share on other sites

2 minutes ago, D@n said:

@small_vhdl_projects

Your problem now lies within your XDC file.  This message shows up any time you have input or output ports to your top level RTL (VHDL or Verilog) file that aren't defined in your XDC file.  The XDC file is what maps these pins to names.  Hence, once you grab the XDC file for your device, you need to edit it so that your names match the names within the file.  Further, any pins from that master XDC file that aren't used, you will need to comment out.  That'll get you another step further.

Dan

Hi Dan, thanks for the answer!

But there is one thing I don't understand. In the code I use (in the link in my question) there are inputs like START and nCS and DONE, do I have to get them in the XDC file as well? And if so, where or how? 

 

Guy

Link to comment
Share on other sites

@small_vhdl_projects,

Anything and everything that must be mapped to an external pin on the FPGA must be placed into the XDC file.  Older configurations used the ISE tool instead of Vivado, which used UCF files instead of XDC files.  Indeed, you'll find a UCF file in the directory you cited.  The formats are slightly different.  Then, Vivado determines what these things are by looking at your top level RTL file and looking at the inputs and outputs of it.  Hence, if you have an output like nCS, it needs to be declared in your XDC file.

One question for you, though, are you using the file you referenced above as your top level file?  It wasn't designed to be a top level file, but rather the component of a larger system.  Have you looked at this file as a potential top level file instead?  That handles the CLK and nCS things, properly wiring them to external ports, however it also has pins assigned for an external memory port that the Basys3 doesn't have.

Dan

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...