• Content count

  • Joined

  • Last visited

  • Days Won


Notarobot last won the day on June 30

Notarobot had the most liked content!

About Notarobot

  • Rank
    Prolific Poster
  1. Hi @electronicsdevices I wanted to mention that I am using Vivado 2017.1 without any issues and for this reason I think your problem is with something else. It seems that you tested a number of projects. Sometimes these projects overlap if the project directory was not properly set up. This could create a problem. If you are using stdin/stdout then you need to check whether UART1 was active in the Processing system configuration and the default output pins were selected. Ususally they are set by default but when you create a project from scratch. It should be mentioned that xil_prinf does not output float, use print. UART0 can be used as well but requires reconfiguration of the BSP and extra hardware for physical interfacing. I tested it with PmodRS232.
  2. @D@n Experience you described is R&D. The amount of requirements for this type of work is not comparable with the production of the system where FPGA is just a piece of equipment. Every requirement should be defined and tested. Every change requirement should documented and traceable. I assume you didn't have "luck" to work in the large corp mechanism. I wish recruiters were looking for gurus. It is way more pragmatic. Totally agree with @zygot Thank you for upgrading me to a prolific poster , feels great!
  3. To all, I am not sure that portability and job security are related. Let me clarify this. In my experience only large corporation have resources for every task of an elaborate developments process: requirements specification, tests definitions, code development, testing, documentation, version control, etc.. Small companies or R&D projects have to cut corners to meet the time deadline, mostly, in documentation and version control. They have typically one FPGA designer per project and if he leaves the company it will loose ability to upgrade or change design for long because he might be the only one involved in it. This makes the designer valuable and guarantee job for the duration of the project at least. Very limited number of electrical engineers know HDL enough to use it. In my understanding portability of code means ability to be transferred the a different platform with minimal modifications (rewriting all constrains, at least). How does this help the company to mitigate the loss of the designer? Thanks.
  4. Hi @sami47 For me your code snapshot is incomplete for making definite diagnostics. However, I am guessing that slv_reg0...3 are defined as out in your entity and your are driving them from multiple sources. That is not synthesizable code. One possible solution is to create several temporary registers and use them instead. Then you will reassign temp values to the output register in a single statement. Another solution would be changing the architecture of your code, for example, by using Block RAM. To my knowledge DDR3/BRAM operations are faster than GPIO. Hope you find this helpful.
  5. Hi D@n, You well described your reasons and I totally agree with what you looking for from your point of view. I am not that deep in the FPGA development. I don't know how did I manage to get Community super-star status?! I respect your skills and knowledge and would never take challenge creating soft-core CPU, for example. My position and involvement is different. For me Zynq or other FPGAs are just components helping to accomplish project goals. I don't work in mass production and cost of more capable board is fully justified if it saves development time. Components obsolescence is inevitable and can be managed by proper system design. I guees this concludes my "presentation". Anything else would be repetition. Thank you for reading !
  6. Dear D@n I appreciate your initiative starting this discussion. It might help readers to learn from other people experience. In fact, this is why I often read this forum myself. In my comment I wanted to make a point that using tools provided by vendors carry lower risk then open source tools. Why? Because tools were in development for many years and were tested by thousands of designers, because implementation process is tuned for these tools and there is technical support from the vendor. Speaking for myself I have very little time to experiment with other tools unless they offer me substantial advantage. I use many open source tools but not in the HDL development. BTW, Xilinx is using Eclipse in the SDK and this is open source IDE, gcc is also open source tool. I use Python for multiple tasks and love it for its efficiency. Unfortunately, every tool has specific controls or GUI, thus, requires time for learning and sometimes corporate training to use it effectively. In my experience I needed to learn and use Matlab, Simulink, Altium DXP, Altera toolchain, Xilinx toolchain, Actel toolchain in relation to hardware and system development not to mention C, VHDL, Java, Python, etc. I don't mention various other proprietary simulation software, design tools and utilities needed for getting work done. When I need to choose commercial product I prefer the one that has support. This usually cost more but it saved my back and projects many times. This was the key factor in choosing the Digilent. Hardware is cheap these days, people time is the greatest expense. Usually companies recognize this very well. I think that every case is special and selection of tools should be based on available budgets and schedules. So far I am satisfied with the quality of the Xilinx IP and tools. Availability of ARM processors on Zynq and the block design methodology reduced the development time on my recent project way beyond initial expectations. It also provided transparency or the design and readable documentation. Now my collegues can understand the design. I can't imagine achieving the same results using only HDL in the same time frame. It should be mentioned that, undeniably, one of benefits of HDL only design is job security, since the debugging or reusing of multiple modules of poorly documented HDL code written by somebody in the past is mostly fruitless effort as well as cruel. Thank you for reading and hope you find it useful.
  7. Hi to all, I just wanted to note that regardless of language choice we should mind that not all statements are synthesizable. Different vendors use different versions of HDL languages and open source tools not always in sync with vendors. I believe that using open source design tools introduces additional unneccessary risk and, personally, I would use only vendor's tools for industry applications. Perhaps for education open source is acceptable. Apology for unclear statement and confusion.
  8. Dear @ZYLL In my understanding your exercise of driving GPIO at 1 MHz is just an exercise because it doen't make other sence to keep the processor busy doing a task that can be done by one small process in PL. You can start / end this process by the processor. PL can notify the processor about events invoking an interrupt. My advice is to learn HDL. You board will be able to do many tasks in paralles and free the processor for supervisory and communication functions. Personally I like and use VHDL because it is strongly typed language and majority of coding mistakes can be flagged as you type. It is more verbose than verilog but I find that VHDL code is easier to understand becuase the code is well structured. I made couple attempts switching to verilog in the past in order to add another skill but didn't find it worth the effort. It should be said that lot of people prefer Verilog.
  9. zybo

    I suggest you search the forum. Pin connections and the board constrains was covered earlier this year.
  10. Hi @elodg In my opinion, the first option to consider is to use either unique optical or RFID (NFC) tag on every screw. This will allow to register that every one was approached. The second check whether the screw was tightened can be obtained if you equip every screwdriver with something like LSM9DS0 inertial module:3D accelerometer, 3D gyroscope, 3D magnetometer. This will tell you how many revolutions the screwdriver made and potentially even 3D coordinates of the sensor. Of course this will require a processor to digest these data. Some smartphones are equipped with similar sensors and could be used for experimentation. They also can read optical ID or RFID NFC, can be connected to a database and monitor the progress. There are also commercial sensors for IoT that include gyroscope sensor. Some of Digilent boards could be used for these tasks but, in my opinion, your choice should be based on availability of software libraries and examples. In any case this seems to be fun project. Good luck!
  11. Hi @ZYLL FYI, you can send interrupt from PL directly to the processing unit bypassing the GPIO. It is not well described but it works on rising edge with no added latency. I am convinced that interrupts are the best way to make both PL and PS working on the same goal and doing what each can do best. Because PS has many resources connected to it and requires very little coding, neglecting it would be counterproductive, at least in a standalone mode. It should be mentioned that nested interrupts are not documented by Xilinx, thus, very difficult to use. When I needed I could find some information only on ARM site. It means it could cost you time if you need more than one interrupt.
  12. Hi @artvvb and @jpeyron I need to tell that I have experience using rs485 for communication of industrial controllers with equipment. The most important for me is its ability to talk with several clients using two wires only. To my knowledge RTS and CTS pins are needed only for the flow control which is optional. In my recent research I've found that UART16550 can be used for making rs485 working but only between two controllers. In order to make multiple client communication a signal disabling TX should accerted after the end of each transmission. There is no other obvious way to do it but via GPIO. However, proper timing becomes a problem since this signal is not a part of AXI controlling the uart. There are some other options but facing a deadline on my project I decided to abandon rs485 and switch to CAN which is supported by Xilinx. I am going to add CAN interface breakout board to one of the Pmod ports. I've used CAN in the past as well and it is even better than rs485 in many respects. I will share results with you, and you might add PmodCAN to your store in the future. Thank you for your input I appreciate it very much Best!
  13. @electronic-tree In order to make informed decision you need to define I/O requirements: interfaces with actuators, computer, sensors, total number of lines. In my opinion using any FPGA for such slow and trivial application is an overkill. Any processor board will be able to do everything. Besides there are plenty of open source projects and libraries available. I would add ZigBee to make the system wireless and solar panel for recharging. Also my choice would be a board which has the most of examples and documentation. This will free you for working on control algorithms and data storage instead of solving hardware issues. Good luck!
  14. Hi riche, Could you please, explain what documentation do you expect. You can always ask question if you need clarification. This area is very dynamic, everything is in constant move. That explains why some tutorials are getting obsolete and difficult to follow. Thanks
  15. 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!