Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
On 12/08/2013 02:09 AM, David Koontz wrote:
On 8 Dec 2013, at 2:00 am, Brian Drummondbr...@shapes.demon.co.uk wrote:
The specific import of this - to ghdl - is that ghdl's VHPI interface
really only supports procedure/function calls between languages.
So if you can structure the interaction such that a VHDL process calls a
C function or procedure (void function), that process will block until
the function's return, and that takes zero simulation time (occurs
within a delta cycle).
Thus with the VHDL side in control, the simulation cycle controls the
timing.
There was a ghdl-discuss thread earlier this year, mid April Calling functions
written in VHDL from a linked C-language-compiled binary which got slightly
derailed by a post by René Doß, where I modified an assignment statement making a foreign
call from:
Oh I remember it.
Yes I would make a similary connection but inverse. I had to verificate
a CPU written in VHDL.
background:
I have developed a 32bit MIPS softcore. In a development phase I would
control the simulator with a local Ethernet port. I had written a
gdb-server in C a but I could not change signals in VHDL/GHDL for outside.
The GDB server started in the addition process in the testbench.
gdb_init : process
variable i: integer ;
begin
i:=wait_for_connect(2020);
wait;
end process;
The C entry code and VHDL code is attached on this email.
I stopped this debugging tool because I could not initiate signal
changes by the C code.
Now I am over this development phase.
The process is a little bit others.
I have a converter tool, that produce from an elf file (compiled and
Linked Software) an VHDL file.
The OP-codes are lockated in a Block Ram. After all files are VHDL files
and I have to simulate only VHDL files.
The Softcore can you found at:
http://www.dossmatik.de/mais-cpu.html
The Mais CPU runs MIPS-I opcodes. And you can also use gcc as C compiler.
René Doß
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include netinet/tcp.h
#include arpa/inet.h
#include signal.h
#include netdb.h
#include pthread.h
#define GDBSTUB_EXECUTION_BREAKPOINT (0xac1)
#define GDBSTUB_TRACE (0xac2)
#define GDBSTUB_USER_BREAK (0xac3)
static int listen_socket_fd;
static int socket_fd;
static int hex(char ch)
{
if ((ch = 'a') (ch = 'f')) return(ch - 'a' + 10);
if ((ch = '0') (ch = '9')) return(ch - '0');
if ((ch = 'A') (ch = 'F')) return(ch - 'A' + 10);
return(-1);
}
static void put_debug_char(char ch)
{
send(socket_fd, ch, 1, 0);
}
static char get_debug_char(void)
{
char ch;
recv(socket_fd, ch, 1, 0);
return(ch);
}
static const char hexchars[]=0123456789abcdef;
static void put_reply(char* buffer)
{
unsigned char csum;
int i;
do
{
put_debug_char('$');
csum = 0;
i = 0;
while (buffer[i] != 0)
{
put_debug_char(buffer[i]);
csum = csum + buffer[i];
i++;
}
put_debug_char('#');
put_debug_char(hexchars[csum 4]);
put_debug_char(hexchars[csum % 16]);
} while (get_debug_char() != '+');
}
static void get_command(char* buffer)
{
unsigned char checksum;
unsigned char xmitcsum;
char ch;
unsigned int count;
unsigned int i;
do
{
while ((ch = get_debug_char()) != '$');
checksum = 0;
xmitcsum = 0;
count = 0;
while (1)
{
ch = get_debug_char();
if (ch == '#') break;
checksum = checksum + ch;
buffer[count] = ch;
count++;
}
buffer[count] = 0;
if (ch == '#')
{
xmitcsum = hex(get_debug_char()) 4;
xmitcsum += hex(get_debug_char());
if (checksum != xmitcsum)
{
// BX_INFO ((Bad checksum));
}
}
if (checksum != xmitcsum)
{
put_debug_char('-');
}
else
{
put_debug_char('+');
if (buffer[2] == ':')
{
put_debug_char(buffer[0]);
put_debug_char(buffer[1]);
count = strlen(buffer);
for (i = 3; i = count; i++)
{
buffer[i - 3] = buffer[i];
}
}
}
} while (checksum != xmitcsum);
}
void hex2mem(char* buf, unsigned char* mem, int count)
{
int i;
unsigned char ch;
for (i = 0; icount; i++)
{
ch = hex(*buf++) 4;
ch = ch + hex(*buf++);
*mem = ch;
mem++;
}
}
char* mem2hex(char* mem, char* buf, int count)
{
int i;
unsigned char ch;
for (i = 0; icount; i++)
{
ch = *mem;
mem++;
*buf = hexchars[ch 4];
buf++;
*buf = hexchars[ch % 16];
[Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
Hi, I am currently working on a SmartFusion2 project, and did some search on the web. I found several pages describing how to write bare-metal applications for ARM Cortex-M3 using qemu. I even found a project with efforts to make a virtual development environment for PCIe on github. https://github.com/texane/vpcie. I'm the VHDL developer in our team, and I am not really good at deciding the level of effort needed to combine qemu and ghdl to make a more generic virtual development platform for software developers. If it would be easy, I guess somebody would have done this by now. Isn't ghdl creating gcc code for the simulation, and could this generated c-code be linked into a qemu binary to have a simulation level of the hardware? I hope to provide testvectors to the VHDL hardware level which represent corner cases difficult to reproduce in the lab and to give the software developers a reliable development platform. Kind regards, -- Svenn ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
Hi Svenn, I guess you're generally referring to a Co-Simulation environment what the big guys like Cadence, Mentor, etc. offer. Now, GHDL is pretty darn powerful WRT Co-Simulation, but you have to write some code. Let me respond 'inline': I'm the VHDL developer in our team, and I am not really good at deciding the level of effort needed to combine qemu and ghdl to make a more generic virtual development platform for software developers. If it would be easy, I guess somebody would have done this by now. I've messed with some extensions to allow software simulators or data acquisition modules to directly talk to the virtual FPGA hardware. Some entry point: http://tech.section5.ch/news/?p=124 Look for the ghdlex extensions, there are some examples using either unix pipes or the netpp protocol. Isn't ghdl creating gcc code for the simulation, and could this generated c-code be linked into a qemu binary to have a simulation level of the hardware? That won't work just like that. You can import .so's into a GHDL simulation that messes with virtual pins via virtual I/O, but running qemu on top of that might be a real adventure. You could fork it as a thread, but you'll have to take care of all I/O, the VPI interface of GHDL is not thread safe, according to experiments. I'd suggest to add a virtual hardware module to qemu and let it speak to the simulation via a virtual interface (from the ghdlex extensions mentioned, that might tunnel through netpp/networking or a Unix pipe). For the interface side however, you'll have to deal a lot with timing, because the cycle accurate simulation will run way slower than the real world. I hope to provide testvectors to the VHDL hardware level which represent corner cases difficult to reproduce in the lab and to give the software developers a reliable development platform. You can do quite some funky stuff, really. So your hardware simulation can run on a linux server while the SW guys access it on their desktop via their qemu simulation through, say a virtual memory bus that tunnels through netpp/ghdlex. I've put together a few movies of a debugging scenario a while ago, basically it shows how to connect a GNU debugger to a virtual CPU SoC running as cycle accurate simulation - maybe it gives you an idea: http://www.section5.ch/doc/jtag/movies/ Cheers, - Martin ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
On Sat, 2013-12-07 at 12:02 +0100, Svenn Are Bjerkem wrote: Isn't ghdl creating gcc code for the simulation, and could this generated c-code be linked into a qemu binary to have a simulation level of the hardware? ghdl doesn't generate C code. It generates gimple, (intermediate code) just like the C, Ada, Fortran and other front ends (stored in memory, not a file). Then the gcc backend translates that to either .s (assembler) or .o(object) format; and the assembler and linker can do with those anything it can with any other .s or .o files. Which may or may not include linking into a qemu binary; I haven't tried that. I hope to provide testvectors to the VHDL hardware level which represent corner cases difficult to reproduce in the lab and to give the software developers a reliable development platform. ghdl also has a minimal vhpi interface, allowing calls to C (or indeed Ada) code, and vice versa, with some fiddling. The .o file (compiled from VHDL) links with the other components using ld in the normal way. Hope this info helps; - Brian ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
On Sat, 2013-12-07 at 13:10 +0100, Martin Strubel wrote: Hi Svenn, I guess you're generally referring to a Co-Simulation environment what the big guys like Cadence, Mentor, etc. offer. Now, GHDL is pretty darn powerful WRT Co-Simulation, but you have to write some code. Let me respond 'inline': I'm the VHDL developer in our team, and I am not really good at deciding the level of effort needed to combine qemu and ghdl to make a more generic virtual development platform for software developers. If it would be easy, I guess somebody would have done this by now. I've messed with some extensions to allow software simulators or data acquisition modules to directly talk to the virtual FPGA hardware. Some entry point: http://tech.section5.ch/news/?p=124 Look for the ghdlex extensions, there are some examples using either unix pipes or the netpp protocol. Martin, this page is good stuff! - Brian ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
Hi, lots of answers I haven't got around to read properly, but I notice that my objectives were not clear. It all starts with the simple fact that we use SmartFusion2 in a design. We have prototypes ready and I have written a lot of VHDL for this board and a bare-metal Cortex-M3 application to test that all the attached components on the board are connected and working as expected. The final CM3 application will be written by a colleague with less knowledge on hardware, but more on software During this bring-up phase, I use Libero SoC, SoftConsole and FlashPro on win7, because FlashPro only supports windows. It is the wish of my software colleagues to go to Makefile, git and Linux in order to make a proper team development environment. I am also preferring Linux, but due to FlashPro and an awkward Wind/U Motif compatibility level, I made my life easy and use win7 and the MicroSemi toolchain. Because of the request for Makefile and Linux, I googled for a while on Cortex-M3 and Linux, and got a very good feeling that sw development on a plain Cortex-M3 can be done very well with qemu-arm and the cross compile toolchain for M3 on a Linux platform. Since I knew ghdl from before, I got the great idea that it would be a great virtual prototyping platform if ghdl and qemu could be combined in some way to make sw developers independent of real hardware. Timing issues may kill this idea, but at least we have tried. I hope to trigger a sw savvy colleague to assist me when he faces the fact that the only option to test his code is to use windows. Kind regards, -- Svenn ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] ghdl with qemu to emulate SoC FPGA
Am 07.12.2013 um 15:23 schrieb Brian Drummond br...@shapes.demon.co.uk: On Sat, 2013-12-07 at 15:02 +0100, Svenn Are Bjerkem wrote: Hi, During this bring-up phase, I use Libero SoC, SoftConsole and FlashPro on win7, because FlashPro only supports windows. And that's the real problem : FlashPro only supports Windows. Just about everything else in the toolchain will support Linux; even their development toolchain is nothing more than Eclipse and gcc... (The gdb sprite to connect through FlashPro is probably also proprietary; I can't tell, since they wouldn't openly admit the compiler wasn't!) At which point it's worth asking if a different JTAG controller (supporting Linux) would work for software download and debug, reserving the FlashPro for bitfile updates. If so, it'll be a much easier solution. I haven't tried. You can certainly develop, make and revision control on a Linux machine and relegate the Windows machine to Eclipse/gdb sessions, but it's a bit awkward. I didn't get further than that. - Brian You can use Microsemis DirectC tool to build some kind of Flashpro Programmer for Linux. It is provided als C-Code and is easily portable, so you get is easy ported on a Cortex-M for example. We have such an effort running on the F4-Discovery Board from ST. The programming file is loaded per UAB-UART and flashed into the ProAsic with the DirectC running in the Cortex MCU. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss -- Mail: tors...@meissneronline.net Blog: http://blog.goodcleanfun.de signature.asc Description: Message signed with OpenPGP using GPGMail ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
