Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
A more typical approach would be to implement a softcore within the design which could then be programmed, using traditional methods, using script interfaces, ODBC, native API, etc to access the RDMS.
But why would you want to? It would be easier and significantly more flexible to do this using a computer and a scripting/programming language like python/perl/C/C++ than to use VHDL/Verilog+simulator.
If the plan is to build some hardware box to access an SQL server than it's still better to use a real processor, instead of an FPGA design using VHDL/Verilog with maybe a soft processor.
With a pure hardware implementation. Can you imagine the headache with adding a new field to the database...I have to change my FPGA code and run 1 week of simulations and regression tests, then I have to build a new FPGA and test it on the hardware.
If it's a "software" implementation in VHDL/Verilog. Manager...WHY do we have to pay Mentor $20K just so we can upload data to the SQL server? Can't we just write some python script to access the server and a $500 PC? Employee: Well I wanted to learn how to program in VHDL/Verilog and we need a VHDL/Verilog simulator to run the programs I write.
@ads-ee I absolutely agree, attempting to implement a connection to an RDMS in hardware using an HDL, sounds like the proverbial exercise in frustration.
If the plan is to build some hardware box to access an SQL server than it's still better to use a real processor, instead of an FPGA design using VHDL/Verilog with maybe a soft processor.
Another possible option, if a minimal footprint is required, would be to utilize a FPGA with an embedded processor, like Xilinx's Zinq which incorporates a Dual-core ARM Cortex A9 into its design, can readily run Linux and in turn can be programmed to access an RDMS using existing scripting, ODBC, .NET (Mono), native API interfaces, etc.
Another possible option, if a minimal footprint is required, would be to utilize a FPGA with an embedded processor, like Xilinx's Zinq which incorporates a Dual-core ARM Cortex A9 into its design, can readily run Linux and in turn can be programmed to access an RDMS using existing scripting, ODBC, .NET (Mono), native API interfaces, etc.
BigDog
I agree with this, but I think a cheap PC running open source software would be less expensive option and more familiar for IT to manage.
A Zynq board with the smallest versions will run ~200 and a much more featured board with a larger Zynq part allowing for more custom logic will run well over $400. Given the amount of effort involved for the two options...
FPGA VHDL/Verilog - effort HIGH, price MED to HIGH, maintenance nightmare
PC script/software - effort LOW, price LOW to MED, maintenance easy
There's a reason you don't see a bunch of SQL server hardware upload boxes around.
I guess if the OP is a masochist they could go with the VHDL/Verilog hardware route. ;-)
The original question is too vague. I certainly know of users who take information from a simulation, like high-level transactions from a UVM testbench and dump it into an SQL database for performance and profile modeling of their system. I doubt this is waht they are asking for, but I have no idea what they are asking for other than mentioning they have and HDL simulation that needs to interact with an SQL database.
On the off chance that there's a sensible plan in there somewhere ... if I'd have to do something like this I'd look at options in this order:
For simulation:
1 - use simple boring $write to dump all the relevant data to a comma seperated file, and use your favorite database import tool or script
2 - check if there's easy to use systemverilog classes out there that already fixed the problem for you
3 - lacking 2: use DPI to wrap the most elementary database C function calls from whatever API is easiest to use for your database
For synthesis aka real actual hardware:
1 - uhm?
2 - are we sure?
3 - oh alright
4 - use simple UART or whatever connectivity is appropriate for your data rate, and do a straight up value dump again. This can be processed on the PC again like option 1) for simulation above.
5 - add an embedded linux server and okay not really.
Case in point is to always always try to shift the database heavy lifting to the PC and keep the HDL side as stupid and simple as possible. Because that way you have some time to enjoy the nice weather. Without headaches.
As for the systemverilog classes, does anyone know if there are easy to use options out there? I know I could do it with DPI-C, but that would be rather silly if there is already something out there. Right now I do such thing pretty much as I described above with $write + post processing, but it would be nice if there's something even easier.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
