Notarobot

Members
  • Content Count

    214
  • Joined

  • Last visited

  • Days Won

    13

Reputation Activity

  1. Like
    Notarobot got a reaction from jpeyron in Stuck in SDK   
    Kris,
    Printing via xil_print is using STDIO by default and could reconfigured in Vivado and SDK. With little info you provided a lot left for guessing.
    My last recommendation is to pay attention to a configuration of your build in SDK. The interrupt interrupt service routine (ISR) might not work if GCC compiler has optimization ON. To make it work the variable in the ISR should be declared volatile. Debug build usually has flag -O0 that optimization none.
    Good luck!
  2. Like
    Notarobot got a reaction from Jonathon Kay in Would I be able to self learn FPGA programming Zynq 7000 series?   
    @Jonathon Kay
    My recommendation is to start with this board and follow tutorials from here. Download and install recommended Vivado versions not the latest.
    This board is very affordable and has everything to start. Tutorials will give you a picture of the design process with Vivado. It will help to see integration of the FPGA part in the system. Udemy Zynq tutorials are applicable to this board with minor corrections. I wish to have this when I started.
    It might be hard but it is a lot of fun as well and without fun who would do it.
  3. Like
    Notarobot got a reaction from Abdul Qayyum in Reading Data From BRAM of Zybo but receiving data is garbage.   
    Hi, Abdul,

    Here are my notes/recommendations:

    1. Open your block diagram in Vivado where you created BRAM configuration and then check the address editor. You should see whether the BRAM address was assigned. If you find assigned see axi_bram_ctrl_0 OffsetAdress and the Range then the BRAM was created and mapped to the memory.

    2. Writing and reading from BRAM requires a clock signal. Check Xilinx templates for BRAM which you can access inside the Vivado. I am not sure that the code you've used to write into BRAM does anything.

    3. You don't use an absolute address in your HDL when BRAM created in Vivado. Vivado maps the address 0x4000_0000 to 0. So you can start from the address 0 and it will be the lowest address of the BRAM. If your don't use Vivado then you will need to define your block in HDL and include addresses, and many other parameters.

    4. The C-code in SDK should use BRAM address from the file parameters.h. You just need to use XPAR_AXI_BRAM_CTRL_0_S_AXI_BASEADDR as the begining of the BRAM address space.

    5. You can treat BRAM as RAM meaning that all read/write operators are the same.
    For example you can copy BRAM content into the RAM:

    for(i = 0 ; i < BRAM_SIZE ; i++)
    *(destination + i) = *(source + i);
    where source = XPAR_AXI_BRAM_CTRL_0_S_AXI_BASEADDR

    Disclaimer: always read documentation, whatever you find on Internet might not be correct.

    Good luck!
  4. Like
    Notarobot got a reaction from That_Guy in State machine vs Microblaze MCU   
    In my humble opinion, FSM is the best architecture for the supervisory controller regardless of its implementation.
    Since the poster indicated AVR (C-code) experience I believe that using Microblaze would be easier or less time consuming because pretty much everything can be accomplished in C-code.

    However, without knowing the requirements specification this is just my opinion based on personal experience.

    It should be mentioned that Xilinx provides FSM templates for both VHDL and Verilog. Also, it is imperative to simulate FSM to make sure that it doesn't have dead states.
    Simulink Stateflow is a good tool for designing FSMs. C-code implementations of FSMs could be found in textbooks.

  5. Like
    Notarobot got a reaction from jpeyron in Reading Data From BRAM of Zybo but receiving data is garbage.   
    Hi, Abdul,

    Here are my notes/recommendations:

    1. Open your block diagram in Vivado where you created BRAM configuration and then check the address editor. You should see whether the BRAM address was assigned. If you find assigned see axi_bram_ctrl_0 OffsetAdress and the Range then the BRAM was created and mapped to the memory.

    2. Writing and reading from BRAM requires a clock signal. Check Xilinx templates for BRAM which you can access inside the Vivado. I am not sure that the code you've used to write into BRAM does anything.

    3. You don't use an absolute address in your HDL when BRAM created in Vivado. Vivado maps the address 0x4000_0000 to 0. So you can start from the address 0 and it will be the lowest address of the BRAM. If your don't use Vivado then you will need to define your block in HDL and include addresses, and many other parameters.

    4. The C-code in SDK should use BRAM address from the file parameters.h. You just need to use XPAR_AXI_BRAM_CTRL_0_S_AXI_BASEADDR as the begining of the BRAM address space.

    5. You can treat BRAM as RAM meaning that all read/write operators are the same.
    For example you can copy BRAM content into the RAM:

    for(i = 0 ; i < BRAM_SIZE ; i++)
    *(destination + i) = *(source + i);
    where source = XPAR_AXI_BRAM_CTRL_0_S_AXI_BASEADDR

    Disclaimer: always read documentation, whatever you find on Internet might not be correct.

    Good luck!
  6. Like
    Notarobot got a reaction from Amin in How to read from SD card on ZYBO   
    Hi shahbaz,
    If you are Ok using micro SD card adapter embedded in Zybo I would recommend to use it with the driver xsdps provided by Xilinx. Please note that it is connected and intended for use by PS not PL. The driver is located in Vivado library \embeddedsw\XilinxProcessorIPLib\drivers\sdps
    In Vivado the only thing is needed is enabling SD card in the processing system. Everything else is done in SDK. There you will need to add library xilffs to the BSP. File system and functions are described in here
    Good luck!
     
  7. Like
    Notarobot got a reaction from Bianca in Zebo board: one connector missing   
    The JF connector is physically connected to MIO ports. These ports allows to connect such peripheral as UART and CAN to PS. Configuration of such connections is done in the processing_system7_0 block in Vivado.
    In my understanding they are not present in the block design because there is no easy way to utilize it with PL.
    It is always helpful to check the schematic diagram of the board.
    Hope I've answered your question.
  8. Like
    Notarobot got a reaction from jpeyron in How to read from SD card on ZYBO   
    shahbaz,
    Typically src folder contains C-code written by the person who design the project. It should contain the main function.
    You can try attached Xilinx test code. It's rudimentary but you can change it to your needs.
    Also you don't need to copy Xilinx files into src folder, they will be added to your project from the BSP.
     
    TestSD.c
  9. Like
    Notarobot got a reaction from shahbaz in How to read from SD card on ZYBO   
    Hi shahbaz,
    If you are Ok using micro SD card adapter embedded in Zybo I would recommend to use it with the driver xsdps provided by Xilinx. Please note that it is connected and intended for use by PS not PL. The driver is located in Vivado library \embeddedsw\XilinxProcessorIPLib\drivers\sdps
    In Vivado the only thing is needed is enabling SD card in the processing system. Everything else is done in SDK. There you will need to add library xilffs to the BSP. File system and functions are described in here
    Good luck!
     
  10. Like
    Notarobot got a reaction from Sridhar Prasath Aruppukottai Ganesan in connecting IP blocks for PL side - project includes GPS module, GSM module,Memory, Debug TAP controller   
    Hi,
    I am wondering what is the justification for adding FPGA to your project. All tasks can be accomplished using SBC with ARM processors. Adding FPGA into the project will double your effort since you'll need to program and debug PL which is time consuming. 
  11. Like
    Notarobot got a reaction from xc6lx45 in Protocol Development   
    xc6Ix45
    You are absolutely correct, I should have noticed that you are proposing direct connection.
    Sorry for bringing unrelated issue.
  12. Like
    Notarobot got a reaction from JColvin in Preparation for an FPGA (VHDL) developer job interview   
    @Tickstart
    From my experience you will be asked questions to verify claims you put on your resume. Expect, for example, to be asked HDL syntacsis, implementation of I2C protocol, digital filters, etc. Expect also several people who might be your coworkers will talk with you to get the feel and to test your skills.
    Everything depends on what is the company doing. Most of US companies don't train employees, they might pay for their classes but that's about all. If you are lucky and the company eager to higher you then they can give you time for training.
    Once more from my experience companies hire people who can bring something the company doesn't have. Think about it and decide if you have something to offer, otherwise spend time on learning.
    During the Internet boom one of my friends after reading a few software tutorials managed to be hired as a software developer. Needless to say he didn't last long and his experience was painful since he didn't have developer skills.
  13. Like
    Notarobot got a reaction from D@n in Preparation for an FPGA (VHDL) developer job interview   
    @Tickstart
    From my experience you will be asked questions to verify claims you put on your resume. Expect, for example, to be asked HDL syntacsis, implementation of I2C protocol, digital filters, etc. Expect also several people who might be your coworkers will talk with you to get the feel and to test your skills.
    Everything depends on what is the company doing. Most of US companies don't train employees, they might pay for their classes but that's about all. If you are lucky and the company eager to higher you then they can give you time for training.
    Once more from my experience companies hire people who can bring something the company doesn't have. Think about it and decide if you have something to offer, otherwise spend time on learning.
    During the Internet boom one of my friends after reading a few software tutorials managed to be hired as a software developer. Needless to say he didn't last long and his experience was painful since he didn't have developer skills.
  14. Like
    Notarobot got a reaction from Geralt in Capabilities of Zynq-7000 DevBoards   
    @Geralt
    1. I used Zybo only for proof of concept then I switched to the Avnet MicroZed and PicoZed boards which provide access to PL via expansion connectors. They also sell a prototype carrier card and one very elaborate FMC carrier board.
    2. Achieving "simultaneous" (within ns) sampling is absolutely possible because properly designed boards have equalized propagation on all IO traces and FPGA timing tolerances can keep propagation inside the chip very tight.
    3. SD card can be easily utilized by the processor because Xilinx provided free IP. WIth it I got writing speed around 11 MB/s. Commercial IP promised 25 MB/s but I didn't test it. Latencies and delays depend on the architecture but at your data rates shouldn't pose a problem. In my case because of much higher data rate I was forced to test and benchmark every operation to find bottlenecks. SD card requires a whole chapter to discuss but I have to tell that it is reliable; extensive data validation showed no data losses
    4. To ensure deterministic performance and due to unavoidable latencies I used only VHDL and C for programming in a standalone ARM environment.
    5. In my opinion CAN is the best / easiest data transfer option. All IP is provided by Xilinx, all programming requires several subroutines in C and one extra breakout board for physical external interface. With standard protocol Zynq can transfer about 66 kB/s (1 Mbit/s connection speed).  It is very reliable and 2-wires only.
    Good luck!
  15. Like
    Notarobot got a reaction from Geralt in Capabilities of Zynq-7000 DevBoards   
    @Geralt
    In addition to very valuable consideration by @xc6lx45 and @zygot I'd like to share some of my experience in multi-channel ADC on Zynq at much higher speed.
    First of all It is definitely durable and cross-coupling can be made a on issue. However, it depends on your requirements and implementation.
    I used a combination of both FPGA and ARM processors on Zynq 7010. ARM were utilized for data storage, communication (CAN, RS232) and control while FPGA did parallel data acquisition and control of ADC chips. Everything was done using one ARM processor running under barebone realtime environment. I've tried XADC at 1 MHz sampling rate and abandoned when realized that amount of load it would put on the processor won't leave any resources for my other tasks. The beauty of FPGA that it does wonderfully multiple routine operations in parallel and releases the processor for math, data management and communication. 
    For prototyping I've used Zybo board with three Pmod-AD1 each combining two 12-bit ADC chips. All were sampled at the same frequency, however, you can skip as many acquisition periods as you want. Single frequency simplifies FPGA implementation or, specifically, timing constraints. Although at 100 kHz rate it shouldn't be difficult. The key issue in this project was finding an optimal architecture applicable to Zynq. Writing and testing of the VHDL programming code was on the second place.
    With that said you may find that multiplexing of XADC will meet your requirements. As far as I know most of TI motor controllers use multiplexing of analog sensors. This way you will minimize the need for HDL programming and save on development time, possibly.
    I am wondering what is the benefit of switching from microcontrollers to Zynq, higher DAQ rate?
  16. Like
    Notarobot got a reaction from JColvin in High Speed Image Sensor interface options   
    Hi @pollutioncontroltech
    I agree with the @xc6lx45 statement about underestimating the task. As a newbie you can see only parts that are covered by your experience.The concept you described in my view would require substantial knowledge and highly qualified FPGA professional.
    Now regarding to your options I'd like to say that answering requires some research to substantiate either choices. I think that the key factor is the bandwidth. You need to construct a block diagram of your system (may be several) and estimate required I/O data rates for each particular module. You also need to check whether required IP is available or you will need to write your own code. After making these estimates you will be able to see bottlenecks and critical points of your concept.
    Personally. I would prefer to avoid USB interface because of IP complexity, ARM processors' and RAM latencies. The best would be using Gigabit Transceivers for interfacing with the video source.
    Good luck!
  17. Like
    Notarobot got a reaction from techno-rogue in How high is the switching rate of the High-Speed PMOD on the Zybo Board?   
    Dear @techno-rogue
    It is not clear what is your goal. Do you want to use Zybo as a signal source for some 50 Ohm load or it will interface some kind of digital logic? If the goal is the first one then your experiment can be representitive. However you need to account for the capacitance of the 50 Ohm cable and the bandwidth of the scope you are using. Typically measurements of ns pulse are done using special scope hih impedance probes with very small input capacitance.
    If your load is some digital logic then the experiment is not representitive because most of 3.3V logic is CMOS and its input is pure capacitance with some loss component.
    In my experience I was able to drive 40 MHz clock to my custom logic out of Zybo Pmod. I didn't try higher since it was no need. Higher rates can be achived using LVDS but Zybo is not equipped for this.
    Hope you find it useful.
  18. Like
    Notarobot got a reaction from techno-rogue in How high is the switching rate of the High-Speed PMOD on the Zybo Board?   
    @techno-rogue
    I would suggest
    1) check your scope measurements capability here
    2) try to add a clock buffer at the Pmod output. Xilinx recommends to us such buffers for clocks. In VHDL it is
    component BUFG
        port (  I : in STD_LOGIC;
                    O : out STD_LOGIC);
    end component;
     
  19. Like
    Notarobot got a reaction from techno-rogue in How high is the switching rate of the High-Speed PMOD on the Zybo Board?   
    Hi @techno-rogue
    I might be wrong but it appears from the picture that the Pmod output is directly connected to 50 Ohms coax cable. The scope is showing about 2V amplitude which is inconsistent with the description of the experiment but consistent with the driving 50 Ohms directly from logic. Note that Zybo traces probably designed to have 60 Ohms impedance. Tail waves on the waveforms indicate impedance mismatch between 50 Ohms load and driving impedance.
    If I would do such experiment I would interface Pmod using high speed line buffer and measure timing on its output. This is how design should be done and this way we would get realistic measurements.
    Overall I think this is a good learning experience of electronic design theory in practice.
    Good luck!
  20. Like
    Notarobot got a reaction from Allan in Zybo 7010 Board File Integration   
    @Allan
    Your problem could be resolved very quickly if you care to provide details about what have you tried.
    I suggest go through "Hello World" project and make sure that USB uart is working.
  21. Like
    Notarobot got a reaction from david.600 in Zybo I2C   
    @david.600,
    In my undestanding there are two ways to implement I2c on Zybo:
    - using I2C peripherals embedded in ARM; these can be conigured to be connected to Pmod JF because MIO pins can be wired to this Pmod only. You can use MIO configuration and select MIO 10 (scl) and MIO 11 (sda), for example. 
    - using Xilinx AXI_IIC. You can get HDL source code from the PmodRTCC project and modify it to your requirements.
    Advantage of the first option is that all programming is done in C-code. I am not sure that you can implement interrupts.
    The second option has fewer limitations. It is possible to use four Pmod ports and implement interrupts but at cost of more coding and FPGA fabric. I think that it might be also slower that ARM peripheral because AXI peripherals introduce latency.
  22. Like
    Notarobot got a reaction from david.600 in Zybo I2C   
    Hi, @david.600
    My advice would be to look at the Digilent PmodRTCC. It communicates with the Zynq ARM via I2c. I tested it in the past and it worked as advertised. Communication works two-way. I was able to read RTCC and write settings.
    Looking at the code provided on GiHub you will find answers for your questions. I made only few modifications when used it because  had other components in the system. You can use other devices instead of RTCC, even several devices on the same I2c bus provided they have different addresses. Also I2c is very well supported on Arduino although not very fast.
    Good luck!
     
  23. Like
    Notarobot got a reaction from david.600 in Using Canbus on the Zynq 7000 board   
    @david.600
    There are two Xilinx documents describing ARM implememtation of CAN interface controller: UG585 and PG096. CAN protocol is much more elaborate than RS232 or RS485 and I am not sure that starting oroginal development of CAN controller has reasonable justification.
    PmodCAN is an option but it will duplicate functionality of the existing controller implemented in Zynq. In my personal opinion the easiest way to implement CAN would be using approach described in UG585. You will need to use CAN SN65HVD230 breakout board, connect it to JF MIO Pmod and configure Zynq processing system for CAN0, for example.
    Xilinx also provides canps driver, example and test application in Vivado XilinxProcessorIPLib.
    Good luck!
  24. Like
    Notarobot got a reaction from D@n in The usefullness of Soft CPU Cores in FPGA Devices   
    Gentlemen,

    I don't have much to say in defense of soft CPU but I can see circumstances when they can be a very good choice, for example for ASICs.
    In my observations the cost of labor on software development, especially, on FPGA is far exceeding the cost of hardware. One month of fully loaded salary of an experienced engineer might cost for a company from $20k to $35k or even more. At current prices on COTS hardware any savings on hardware would only be meaningful if a mass production in very large quantities is the goal. 
    With this in mind my choice is usually based not on hardware cost but on project specs and for possibility for speedy development. I appreciate Zynq with ARM processors because of a large variety of libraries and solutions. It is relatively straight forward to implement I/O with external world. I believe ARM will be supported for a foreseeable future or long enough for me to worry.
    With Zynq as my current choice I didn't have reasons for using Microblaze.
    Thank you for the good weekend discussion.
  25. Like
    Notarobot got a reaction from Shekhar in Zedboard   
    Hi @Shekhar
    It looks like you put substantial thought in your decision. Its obvious benefit is that you will learn a lot.
    Anyway, you will need to install Linux compatible with GNURadio, download GNURadio source code and recompile it on Zedboard. You will also need to find and install video drivers for prefered interface along with the drivers for a keyboard and mouse. You will also need drivers for interfacing RF input stream. I assume that you know Linux applications and FPGA development well, if not you will learn it.
    Search internet for similar projects. I doubt that someone has enough time on hands to write a guide for you.
    Good luck!