Vivado HLS from ROM

This link breaks down how to read in a csv (or other data file type) and gives instructions about how to convert each of the files to header files that can be synthesized by the HLS tool. The problem is, if this is all done by the Zedboard, it would mean that converting to a header file from a csv would have to be executed one by one because the function to do so includes fopen, fscanf, and fclose (which cannot be synthesized by hls because they are too high level.

https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/HLS-ROM-from-file/td-p/654517

So from digging the answer might be in one of many places but for now my ideas are the following:

1. Place the function that will convert the csv to a header file in the testbench function in HLS. 
1. This function will create the header file that can be read by the "to be synthesized source file" in HLS. The pre-filter, pass1, and pass2 can all be pipelined from there although I doubt that will speed up the process at all. If the idea is to process in parallel, then the part we want to pipeline would be the conversion (more files at once)
2. Of course one would have to look at the time it takes to receive one sample data set (that 2x502) file that comes from the scope (I will learn later this week or next how exactly this is done and have a better idea of what direction to go). If the time it takes to create one pulse is similar to the time it takes to convert that data into a header file that can be read by HLS code, then we are in good shape because the processor will be able to keep up with the incoming data. However, if the data coming in exceeds the speed of the testbench conversion into a header file then we are in trouble, and this would seem like a good place to begin parallel processing but we are again met with the problem of fopen, fscanf, and fclose not being able to be synthesized. 
1. So I plan on figuring out the times for each of these processes and figuring out what the best course of action is. The fear is that the data will come in much quicker thatn the processor can process, and we will be in trouble...............BUT that's why I'm thinking of other ways to solve this problem from the beginning!
2. Extract the fopen, fscanf, and fclose functions from the stdio.h library and see if the lower level code that creates those functions can be synthesized.
1. It would seem as though, at some level, the code HAS to be able to be synthesized, but you know, nothing ever works correctly, so there could be a third option on this blog by next week. 

Digilent PmodENC

The Digilent Rotary Encoder Module

This Pmod features a rotary shaft encoder with an integral push button. It also includes a sliding switch that is commonly used as an on/off output.

A rotary encoder is most commonly used to detect how many "clicks" a knob has been rotated. This is the number in GTKterm labeled 'Encoder Value' and underneath that it records the angle.

We also created a knob for the top of the rotary shaft in order to increase stability and accuracy when rotating.

Initially we were hoping that we would be able to use the exact code and process that we use in Emily's previous blog 'Angle Encoder' but unfortunately we came across some problems. We were able to complete all of the steps successfully, however, we had some issues with the outputs. For example, when using the ALPHA encoder we were easily able to recognize a pattern within each click of the LEDs but with the new encoder we were unable to find any sort of pattern at all. The LEDs seemed to be lighting in a random fashion and the Encoder Value was not counting consecutively like it should be. Instead, it would repeat numbers several times and jump around. 

We checked the Pmod connections to the ZedBoard, which were correct so we know that is not the problem and we also checked to make sure it was receiving power. We measured the output to be about 3.3 volts so that is also not where the issue lies. At this point we think that the problem is most likely somewhere within the code.

If we had some more time we would try these options provided to us by Mike:

1. Disconnect the encoder from the PMOD and hook it up to a breadboard. Then use wires to connect back to the PMOD appropriately. I have a feeling that the way the encoder is set up, it has the encoder pins opposite of the ones we are used to. So essentially, the output pins from the encoder would have to be switched (using wires) to connect to JA1 and JA2. 

2. Leaving the encoder attached to the PMOD, change which input is the MSB. I mean that somewhere in the code, in the interrupt function, you are reading from both encoder pins, then combining the two read values into one. If it says MSB >> LSB, change it to LSB >> MSB. I do not remember the exact structure of the code off the top of my head, so you'll have to do some messing around.

3. If both above options fail, and you really want this thing to work before you leave tomorrow, get a multimeter out, hook up power to the power pin of the encoder, and see what each encoder pin is spitting out as you rotate the shaft. If it is a different readout then what you get from the other encoders, then you'll have to do some restructuring of the code to get the encoderValue to change when it is supposed to.

4. BEFORE YOU TRY ANY OF THESE THOUGH, make sure the design is working correctly with the other encoders. This will eliminate a lot of troubleshooting because the issue could lie with the PMOD rather than the enocders or the software.*-+

Helpful Links:

https://reference.digilentinc.com/_media/pmod:pmod:pmodENC_rm.pdf

To Be Continued...

Digilent Pmod ADC

The new Digilent Pmod ADC1 has arrived!

Useful Links:
http://store.digilentinc.com/pmodad1-two-12-bit-a-d-inputs/
https://reference.digilentinc.com/_media/pmod:pmod:pmodAD1_rm.pdf
https://reference.digilentinc.com/_media/pmod:pmod:pmodAD1_sch.pdf

When connecting the Analog Discovery to the chip, refer to the following link:
https://reference.digilentinc.com/_media/analog_discovery:analog_discovery_pinout.pdf

The datasheet for the Pmod explains that the external power provided to the chip must be within 2.35 to 5.25 volts.

Note: The sampling rate is 1 million samples per second and  will provide 12 bits of information through 16 clock cycles.

The issue of testing this chip is the software. It appears that the pins of both the Maxim ADC and the Digilent ADC are the same so the hardware and the pmod interface should be the same as well. However, the maxim code only recognizes the maxim chips and the code on the blog from last summer that allowed us to read in a code using a function generator and the Max11205 does not work either. It is possible that there is an error in the code because the computer crashed the last day and it is possible that the final code was not saved.

Angle Encoder

The first thing we want to do is clone the repository:
1. Create a new folder in zynquser where you want to store your new files: zynquser > Angle_Encoder
2. In the terminal, type sudo yum install git in order to install github.
3. Find the directory where you want your files to be save: cd Angle_Encoder
4. In this file, type git clone https://github.com/mf06engl/Angle_Encoder
This clones the files that Mike posted on github into the folder you created.


5. Open Vivado > Open Project > zynquser > Angle_Encoder > Angle_Encoder > Encoder Hardware > Encoder_Hardware.xpr
(Automatically upgrade to current version if need be).
6. If your IP blocks need to be upgraded, click the Show IP Status button near the top of the page, select all the blocks and upgrade them. If there are any warnings click OK.
7. Run synthesis and run implementation.
8. Generate the bitstream.
9. File > Export > Export Hardware to Local Project (include bitstream). If a warning comes up asking if you would like to overwrite a previously made hardware click YES.
10. File > Launch SDK.



Once you open SDK, you should see the application project, board support package, and the hardware platform.
The software code should be located under Encoder Software > src


Next, we need to make sure GTKterm is open in order to read the values that we read from the encoder. 

1. In the terminal, make sure GTKterm is downloaded. If not, go to  http://dl.fedoraproject.org/pub/epel/6/i386/ and search for  epel-release-6-8.noarch.rpm.

2.  Once you locate the previous link, download and install the application. 

3. In the terminal, type sudo yum install gtkterm.
4. Then type the following: 
                       cd ..
                       cd ..
                       cd dev (in zynquser)
                       ls -l ttyACM0
   If the permission are denied (it does not show crw-rw-rw) then type:  
                       sudo chmod 666 ttyACM0


 To connect the angle encoder, we need to use a breadboard and connect wires from the encoder to the pin outs on the PMOD. Using the previous blog post from Sam, 'Connecting the ALPHA Angle Encoder to the Zedboard,' we can see exactly how it's connected. We use pins JA1 and JA2 connected to Prong 1 and 3 respectively while the 2nd Prong is connected to ground.  

Once everything is properly connected to the Zedboard, we can program the Zedboard in SDK and launch the hardware to the board. 

In the GTKterm we can see that it reads an Encoder Value as well as the value of the Angle. We can conclude that each turn either increases or decreases by 7.5 degrees, depending on whether it is turning clockwise or counterclockwise. Each click of a turn on the angle encoder is equivalent to 4 values, so in order to read each single value you must turn the encoder very slowly and carefully.  The Angle Encoder value is the number of clicks that it has turned from its starting position, which should be zero. When it turns clockwise, this value is negative, and when it turns counterclockwise this value is positive.

The values are shown by the lighting of the LEDs, which only light 4 at a time, having the first 2 bits reading the outputs of Pin 1 and Pin 2 respectively, and the 3rd and 4th bits act as place holders. It acts through a process called 'bit shifting,' where it will read the values through Pin 1 and Pin 2 and then for the next turn it will move the previous measurement to the place holder and read another set of values. 

For example, let's say the four bits are numbered 4  3  2  1  , and the first read measurement is 01. The 01 would be placed in spots 2 and 1 and would look like the following: 
0  0  0  1 .  If the next read value is 11, the previous measurement (01) would be shifted from spots 2 and 1 and into spots 4 and 3, while the current measurement replaces it in spots 2 and 1. That would look like the following:  0  1  1  1 . This pattern would continue with every new read value.  

When it is turned clockwise, the LEDs rotate in the following rotation:
                                0 1 1 1 
                                1 1 1 0
                                1 0 0 0 
                                0 0 0 1
 When it is turned counterclockwise, the LED's 
                                1 0 1 1 
                                1 1 0 1
                                0 1 0 0
                                0 0 1 0 





Part 1: The following video is of the angle encoder being rotated counterclockwise

https://www.youtube.com/watch?v=quktJql8WBI


Part 2: The following video is of the angle encoder being rotated clockwise.

https://www.youtube.com/watch?v=kSy4wF8xKa8&spfreload=5











 

Connecting the ALPHA Angle Encoder to the ZedBoard

When trying to connect an angle encoder to a ZedBoard it can become confusing because when searching the internet, you can really only find examples of an angle encoder connected to an Arduino. However, after some research and sessions of trial and error, we were able to determine a successful connection option.

When looking a the encoder, ALPHA should be listed at the top. The side that has three prongs is where we are going to be working. The three prongs at the bottom we will refer to as Prong 1-3, going from left to right. Prongs 1 and 3 are inputs and Prong 2 is ground.

An example of the specific connections we made when using the angle encoder are, Prong 1 connected to JA1, Prong 2 connected to ground and Prong 3 connected to JA2 (These specific connections JA1 and JA2 may vary depending on the code you are using). We were successful with these connections to the ZedBoard which can be further read about in Emily's Post titled, Angle Encoder.

Helpful Link:
http://bildr.org/2012/08/rotary-encoder-arduino/

Waveform generator outputs

Using the following setup where the yellow wire is the waveform generator and is connected to Vin of the max11205 chip, and the black wire is ground.

The waveform generator is sending a constant signal of 3.6 volts. The output is 32767 decimal.

However, I noticed that the value for the decimal  is the same for signals above 2.5 V. After looking at the datasheet (highlighted below), it is possible that the 2.5V is the maximum voltage for the chip. 

Then the following outputs would make sense.

2.5 V    ->        32767

1.25  V      ->           16489

0.625 V       ->            8323

0        ->           160

I don't understand why zero volts outputs 160 but if you add this value to the rest of the outputs, as you go down the list which is taking half of the previous voltage, then the output is halved as well. 

This is also why the following line of code from menu.c includes the number 2500mV:

printf("%d of %d samples = %d decimal.  (%d mV)\r\n",i+1,unNumberSamplesToCapture,nAdcValue,((nAdcValue * 2500)/32768));

This is just converting the read bit value to a voltage in mV. This is done by simply multiplying by 2500mV and dividing by 32768 just as you would when solving a proportion.

Using the Analog Discovery Box and the ADC

The picture above shows how to connect the Analog Discovery Portable Analog Circuit Design Kit to the ADC Maxim chip. The black wire is ground and the yellow wire is the wave generator.

The wave generated is just a constant signal of 3.6 V shown in the picture below.

This is the output when using the 3.6 V. This makes sense because the max voltage that the maxim chip can take is 3.6 V so this should result in the max value of the 15 bit number which is 32767. I am confused on why it wouldn't be the max value of a 16 bit number but I have to look into this some more. 

When a signal of 1.8 V was created using the wave generator, the output was 14971, which behaved almost like I expected. When I took half of the wave voltage, the output was almost halved. I will also have to look into the relationship between these values.