So I took it upon myself to learn all about the FPGA this semester. To test my skills, I picked up a project to encrypt and decrypt files using a FPGA implementation of the age old AES. Now implementation of AES using Verilog has been done umpteen times and for my reference I used the code at http://opencores.org/project,systemcaes. What I wish to do is use the Verilog file handling functions to read a small file, use it as input to the encryption block on the FPGA, and save the encrypted file back on the computer. I am aware that this can be done on the testbench(though I have not attempted it, I am sure it can be done). But how do I do the same when I implement the code on the FPGA board? Is there a way to select the file to be encrypted/decrypted and pass it onto the board? Is it even possible?
Sorry if I come across as a noobie, its my first time in the world of FPGAs. Thanks in advance everyone!
You need to understand that the FPGA will only take a description of the hardware that you are going to build. It is not like a programming language.
So if you want to load data into a memory on the FPGA you need a way to move the data from you PC into the FPGA. The easiest way is to implement an UART on the FPGA so you can communicate with a serial port on your PC. Then you load data from some terminal program on your PC into the FPGA.
Then you can use the serial port to read the data back to your PC.
This of course require you to have implemented the hardware needed to read and write things to and from a memory in your FPGA.
It might also be that you can stream data through the FPGA. But then I think I would use two serial ports.
Verilog RTL does not have a concept of a file system, you would need the FPGA 'driver' to break the file down and send it over byte by byte or load it into a memory for the program on the FPGA to read.
I am not experienced with FPGAs, my under standing is that you synthesis the design and stream it into the FPGA. I thought that you might have still had some connectivity to the device where you were able to stream data to it. In the same way I think you can control the Arduino over USB.
How do you plan on getting the data back out of the FPGA? Do your tools allow you access to send and load data?
Related
I am using Ethernet to feed data into my LabVIEW system from a custom FPGA hardware. I wanted to know if there is some vi functionality or front panel functionality to display the throughput of the data received from the Ethernet port into the LabVIEW system or the PC.
Scouting through the National Instruments forums, I did not find a solution for showing this statistic in LabVIEW.
This level of diagnostic is not something that is typically available from a LabVIEW function.
If you want to determine this data rate, you have a couple of options depending on your implementation:
Monitor the data rate yourself: Presumably you are catching and processing this data somewhere so write your own wrapper that counts the number of cycles and packets it is processing
Look for a .NET implementation: LabVIEW has fairly nice integration with Windows .NET libraries, and if you are able to find an appropriate library that implements this functionality you should be able to work with it.
Run a monitoring tool like iPerf via the command line periodically. This may not return as accurate data since it is external, but it should be reasonably straight-forward for testing.
as I mentioned above,
does Arduino Uno capable of running application that is taking input from sensors around 6 sensors and sending that input to a remote database through out internet by using either (Wi-Fi shield, ethernet shield)?
I am asking such a question because I am going to use it in the next semester of academic year as a part of my final year project, but I am worried that it's RAM size is not enough since it is 2KB and I need to decide either using Arduino Uno or switch to Raspberry Pi.
It should be possible, altough you may have a hard time searching for a suitable driver for your database. If using MySQL, there is already a project to do exactly what you want.
Another (more flexible) approach is to write a small PC software to receive sensor data in a simple protocol you define, and write them to the database. Run it on the database machine (or any other machine, really), and then make the Arduino communicate with your proxy software instead.
I need to create a hardware-in-the-loop test setup. I will be using Modelica (Dymola) to do a real time simulation of a system. Dymola should send/receive data to/from some hardware and where the received data will be input to the model.
I am trying to communicate with Modbus over a serial connection. The hardware is a PLC-like device so this seems like the preferred method.
I do not have the hardware yet, so I am testing with an Arduino Uno. I have installed a Modbus-slave library from here on the Arduino, and tested it with it with an Modbus tester.
I cannot figure out how to communicate with Dymola. I have tried the Modelica_DeviceDrivers library and was able to send or receive (not both together) data from the arduino but not by the Modbus protocol. My question is if there is any modelica library for modbus communication or any other way to accomplish this from Dymola/modelica?
The free ModelPlug library will connect SystemModeler (and potentially Dymola too) to an Arduino board for I/O. You can download it here: http://www.wolfram.com/system-modeler/libraries/model-plug/
If you want to write your own drivers, you could go to the Resources\Include folder under Modleica_Device_Drivers library, there is a bunch of c header files, and they are very good examples of how to write your own driver. If you can write it in the way that it could be compatible with Modleica_Device_Drivers "package", then it will be quite easy to assemble/disassemble your data messages.
If you just want something quick, you can write a C function and reference it in Dymola.
Both methods may require when(sample(...)) clauses in order to sync your sim time with real time. But this means event generation, tho it is a time event, but for big models with a lot of states, it may slow down your simulation.
I would prefer to create several inputs and outputs around the model, then export the Dymola model as a C or FMU model, I'll write another communication program to control the data flow.
I am communicating across USB, using a proprietary protocol, with some custom hardware I've built. I have a GUI that handles all the communications/interaction with that hardware and a (C#) DLL which exposes all the relevant USB functionality. I need to write a LabVIEW driver (VI) for communicating with the hardware. My thought is that I just use LabVIEW to open up my GUI and have a socket with which I expose all the relevant control to LabVIEW with. Is it possible to open a socket in LabVIEW and communicate with my GUI? Is this a bad approach or should I just try and make LabVIEW invoke the DLL and handle the hardware control instead of my GUI (polled communications, solicited/unsolicited commands, etc)?
IS there a reason you want to use your GUI only? In terms of time, I would say build a good front panel in LabVIEW and just communicate to the hardware directly using the DLL. Adding the GUI is just an added layer of complexity which might be difficult to maintain later on? Why not do everything in LabVIEW if you can?
Yes, LabVIEW supports sockets using both TCP/IP and UDP.
You should be able to create a program/service that continually runs acting as TCP/IP server. You can send commands and receive responses as strings. If you need to pack data, you can use the flatten to string command.
Essentially, your application should be structured as a loop running the TCP/IP server, and another loop that actually communicates with the instrument. This might change if you need to get data back from the devices to your TCP client. A producer consumer model, if you will :)
To get you started off, open up the NI Example Finder (Help -> Find Examples) and browse to Networking->TCP and UDP-> Simple Data Server.vi
It depends who is going to be using the LabVIEW driver and for what. If you're handing over this hardware to someone else who is going to want to create their own application(s) for it, they would probably prefer to talk directly to the DLL rather than go through your GUI. If it's more about automating your existing software from LabVIEW to do testing or repetitive tasks on the hardware, for example, then driving your GUI from LabVIEW might be less work.
I'm using a DSP to control a sensorless brushless DC motor, The DSP is on a board which has a parallel port and a jtag connection (it's an eZdspTMS320F2812). What would be the best way to communicate between a PC application and the DSP as it was running? Ideally I'd like to have a GUI program with buttons like start, stop, accelerate, decelerate... but I've never done anything like that before. Which ports and method would be easiest to use?
Thanks
You can also use simple RS232 communications. I use always because it`s cheap and easy to implement.
The RS232 transceivers are very cheap (like MAX232 from Maxim-IC), and easy to use. Also they come in many packages like DIP or SOIC for example and can be found almost every electronic shop.
You can use any USART from your microcontroller to link with MAX232. Then, using a PC serial-usb converter (or if your PC does have a serial port it`s easier), you can use serial port programming from any programming language to develop your desktop application.
After that, all you have to do is create a protocol to exchange data between your PC programm and your DSP (some simple commands to start, stop and change motor direction for example).
Good luck in your project.
The parallel port is probably the easiest route. Depending on what OS and programming language you are using you should be able to find example code or libraries to support bi-directional communication via the parallel port. Since you have a small set of commands that you might want to send to the DSP board then you can probably just send a single character to the board for each command, e.g. 'R' = start, 'S' = stop, etc.