Implementing VHDL code in an embedded processor design and readout to computer.

Hello, hello,

I'm a grad student and am pretty new to the FPGA scene but I've been
learning VHDL over the last month and now come to the point where I
need to jump into embedded systems.

I am trying to build an FPGA based system where I have an input from
the outside world in the form of a logic level. Ever clock cycle, I
check what the input logic level is and then if it's high I increment
a counter. The value of this counter is then stored into the board's
onboard DDR SDRAM. The values in this DDR must then be read out to a
computer.

I figured that the best way to read out these values to the computer
would be some sort of web server that interfaces with the onboard DDR
somehow, which is more or less where I get lost.

I'm not entirely sure how to make the jump from writing VHDL scripts
and loading them into the FPGA to embedded processes which execute the
VHDL code. The BSB created a DDR memory interface to use, but using it
falls into the category of getting the two IPs to talk to eachother
which I do not yet know how to do.

So in a nutshell I'm not sure how to:

1- Have an embedded processor execute VHDL scripts.

2- Have two IPs talk to each other (getting a data acquisition script
to store values into the DDR via a MIG generated interface).

3- Have a web server interface with the onboard components (whether it
be switches, LEDs or the DDR memory) I know it's possible for switches
and LEDs because some XAPPS I've read have this as part of their
functionality but are not explicit as to how they work.

Essentially, does anyone know (or is anyone able to point me in a
direction) where I can find some reference material on any of these
subject? I doubt I'm the first person to try and readout the onboard
DDR via ethernet, does anyone here have any experience in doing this?

The board I'm planning on using is the ML402 (Virtex-4 FPGA) and I'm
running ISE/EDK 11.2 .


Thanks!

Griffin wrote:

> I am trying to build an FPGA based system where I have an input from
> the outside world in the form of a logic level. Ever clock cycle, I
> check what the input logic level is and then if it's high I increment
> a counter. The value of this counter is then stored into the board's
> onboard DDR SDRAM. The values in this DDR must then be read out to a
> computer.

If it's just one counter, I don't need any ram.
The other logic is very simple.

> I figured that the best way to read out these values to the computer
> would be some sort of web server that interfaces with the onboard DDR
> somehow, which is more or less where I get lost.

I would start with a parallel or serial port interface
to the PC.

> I'm not entirely sure how to make the jump from writing VHDL scripts
> and loading them into the FPGA to embedded processes which execute the
> VHDL code.

Your vhdl code is converted to a netlist of gates and flops by
synthesis. VHDL code is only executed on a simulator.

> So in a nutshell I'm not sure how to:
> 1- Have an embedded processor execute VHDL scripts.

An embedded processor executes machine code
from a C complier or an assembler.
If I have an external computer reading the register,
I don't need a cpu core on the fpga anyway.

VHDL code might *describe* a cpu, but it does not run on one.

   -- Mike Treseler

Mike Treseler wrote:
> Griffin wrote:
> > I am trying to build an FPGA based system where I have an input from
> > the outside world in the form of a logic level. Ever clock cycle, I
> > check what the input logic level is and then if it's high I increment
> > a counter. The value of this counter is then stored into the board's
> > onboard DDR SDRAM. The values in this DDR must then be read out to a
> > computer.
>
> If it's just one counter, I don't need any ram.
> The other logic is very simple.

It's actually 7 24-bit counters to worry about. My sampling rate is on
the order of a few every microsecond, which I'm pretty sure will
require the ram to function as a buffer.

> > I figured that the best way to read out these values to the computer
> > would be some sort of web server that interfaces with the onboard DDR
> > somehow, which is more or less where I get lost.
>
> I would start with a parallel or serial port interface
> to the PC.

I suppose this would be a good place to start. I had wanted to
implement a web server under the suggestion of a professor here, but
it's not necessary.

>
> > I'm not entirely sure how to make the jump from writing VHDL scripts
> > and loading them into the FPGA to embedded processes which execute the
> > VHDL code.
>
> Your vhdl code is converted to a netlist of gates and flops by
> synthesis. VHDL code is only executed on a simulator.
>
> > So in a nutshell I'm not sure how to:
> > 1- Have an embedded processor execute VHDL scripts.
>
> An embedded processor executes machine code
> from a C complier or an assembler.
> If I have an external computer reading the register,
> I don't need a cpu core on the fpga anyway.
>
> VHDL code might *describe* a cpu, but it does not run on one.
>
> =A0 =A0-- Mike Treseler

Thanks for the response!

Griffin wrote:

> It's actually 7 24-bit counters to worry about. My sampling rate is on
> the order of a few every microsecond, which I'm pretty sure will
> require the ram to function as a buffer.

7 24-bit counters would easily fit in registers in many FPGAs (e.g.
std_logic_vector signals in VHDL). You don't need any RAM at all, even no
internal block RAM. This makes the implementation much easier than using
external DDR SDRAM, if you are using VHDL and not some embedded system,
like NIOS or MicroBlaze.

>>> So in a nutshell I'm not sure how to:
>>> 1- Have an embedded processor execute VHDL scripts.

I assume you are using some synthesized CPU? In NIOS it is possible to
include your own VHDL entities. They are compiled together with the rest of
the system to a netlist, which then can be loaded into the FPGA.

This would make your task very simple, but maybe a good idea to start with.
The most complicated thing would be to fiddle around with the sometimes not
very intuitve tools for creating the embedded system configuration. The
VHDL entity for counting is very simple, the rest would be C. Some embedded
system configuration tools allow you to just add TCP/IP support and
provides the C libraries, so your C program would be something like 100
lines standard C for a simple web server, which can display the counter
values. I assume nearly all embedded system tools provide RS232 support,
which would reduce your C code to something like 10 lines.

Of course, would be much more fun to implement your own RS232 entity and
protocol, all in pure VHDL :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Jul 29, 2:17 pm, Griffin <captain.grif...@gmail.com> wrote:
> Mike Treseler wrote:
> > Griffin wrote:
> > > I am trying to build an FPGA based system where I have an input from
> > > the outside world in the form of a logic level. Ever clock cycle, I
> > > check what the input logic level is and then if it's high I increment
> > > a counter. The value of this counter is then stored into the board's
> > > onboard DDR SDRAM. The values in this DDR must then be read out to a
> > > computer.
>
> > If it's just one counter, I don't need any ram.
> > The other logic is very simple.
>
> It's actually 7 24-bit counters to worry about. My sampling rate is on
> the order of a few every microsecond, which I'm pretty sure will
> require the ram to function as a buffer.
>
> > > I figured that the best way to read out these values to the computer
> > > would be some sort of web server that interfaces with the onboard DDR
> > > somehow, which is more or less where I get lost.
>
> > I would start with a parallel or serial port interface
> > to the PC.
>
> I suppose this would be a good place to start. I had wanted to
> implement a web server under the suggestion of a professor here, but
> it's not necessary.
>
>
> > > I'm not entirely sure how to make the jump from writing VHDL scripts
> > > and loading them into the FPGA to embedded processes which execute the
> > > VHDL code.
>
> > Your vhdl code is converted to a netlist of gates and flops by
> > synthesis. VHDL code is only executed on a simulator.
>
> > > So in a nutshell I'm not sure how to:
> > > 1- Have an embedded processor execute VHDL scripts.
>
> > An embedded processor executes machine code
> > from a C complier or an assembler.
> > If I have an external computer reading the register,
> > I don't need a cpu core on the fpga anyway.
>
> > VHDL code might *describe* a cpu, but it does not run on one.
>
> >    -- Mike Treseler
>
> Thanks for the response!

What's wrong with using the PC to implement the web server?  A web
server is a complex device when viewed from the gate level which is
typically several layers down from the level of web software.  If you
intend to include an embedded processor in the FPGA, then you can run
any software you want.  Mike explained that VHDL is not the sort of
software you would want to use to run a web application.  The HDL
stands for "Hardware Description Language".  Nowhere in there does it
indicate that it would be useful or remotely easy to implement a web
server.

The counters are perfect for an FPGA design.  The idea of loading the
counts into a DDR ram and accessing them is now outside of the FPGA
and at the board level.  Is there a reason not to use the internal
memory in the FPGA?  Will this be running in batch mode where you run
the measurement for a while, stop and read out the results; or will
you be reading the results in real time as the measurement is being
made?  If the latter, your comms has to keep up with the average rate
of the measurement and the ram is only a buffer to smooth out the
measurement data rate.

Rick

Griffin wrote:

> It's actually 7 24-bit counters to worry about. My sampling rate is on
> the order of a few every microsecond, which I'm pretty sure will
> require the ram to function as a buffer.

got $15 ?

http://www.amazon.com/Startech-Parallel-Interface-Adapter-Cable/dp/B00005110L

Griffin wrote:
> Hello, hello,
>
> I'm a grad student and am pretty new to the FPGA scene
>
Wow! There's a scene. Cool. :-)

p.s. What they said ^^^ 

@Frank:

> 7 24-bit counters would easily fit in registers in many FPGAs (e.g.
> std_logic_vector signals in VHDL). You don't need any RAM at all, even no
> internal block RAM. This makes the implementation much easier than using
> external DDR SDRAM, if you are using VHDL and not some embedded system,
> like NIOS or MicroBlaze.

The thing is is that I need to readout the value of the counter every
(say) microsecond or less, which is why I figured I would need a RAM
buffer, the idea being I would fill the ram with the counter values
then read it all out to the computer in one flash, then we restart the
process with (ideally) as little dead time in between "runs".


> I assume you are using some synthesized CPU? In NIOS it is possible to
> include your own VHDL entities. They are compiled together with the rest of
> the system to a netlist, which then can be loaded into the FPGA.

I was planning on using the Microblaze synthesized CPU, which I
understand is the Xilinx provided system.

> Of course, would be much more fun to implement your own RS232 entity and
> protocol, all in pure VHDL :-)

The more I think about it, the more I think that doing something like
this will be the way to go. I'm not died down to any one method yet,
so changing tracks wouldn't be any trouble.

@rickman:

> What's wrong with using the PC to implement the web server?  A web
> server is a complex device when viewed from the gate level which is
> typically several layers down from the level of web software.  If you
> intend to include an embedded processor in the FPGA, then you can run
> any software you want.  Mike explained that VHDL is not the sort of
> software you would want to use to run a web application.  The HDL
> stands for "Hardware Description Language".  Nowhere in there does it
> indicate that it would be useful or remotely easy to implement a web
> server.

I figured I would use the web server on the FPGA board as my method of
reading out the data (i.e. have the computer download some file from
the webserver that contains the measurements taken.

> The counters are perfect for an FPGA design.  The idea of loading the
> counts into a DDR ram and accessing them is now outside of the FPGA
> and at the board level.  Is there a reason not to use the internal
> memory in the FPGA?  Will this be running in batch mode where you run
> the measurement for a while, stop and read out the results; or will
> you be reading the results in real time as the measurement is being
> made?  If the latter, your comms has to keep up with the average rate
> of the measurement and the ram is only a buffer to smooth out the
> measurement data rate.

Ideally I want to be reading the results in real time as the sources
I'm triggering off of are expected to have extremely short durations
(because pausing half a millisecond to break and read out the data
could cause us to miss an event). Thus, the memory buffer would be put
there so that we would never have to stop taking data and have the PC
perpetually reading the DDR memory (containing the values of the
counters after specific time intervals).This is, of course, assuming
that the mean PC read rate is faster than the FPGA write rate.


This does, however, raise the question of if this is the case, why not
readout the counter values directly to the PC every microsecond (or
so) as suggested by Frank? I'm assuming that there's a limit on how
many times per second a computer can access (say) an Ethernet or
serial jack (i.e if I can only look at my computer's serial port once
per millisecond (example) I could not sample the counter values often
enough, regardless of how fast it can then read data out) which is
what inspired the idea of having a memory buffer. This last bit
though, is much more speculative. Perhaps some tests are in order.



-Sean.

Griffin wrote:

> The thing is is that I need to readout the value of the counter every
> (say) microsecond or less, which is why I figured I would need a RAM
> buffer, the idea being I would fill the ram with the counter values
> then read it all out to the computer in one flash, then we restart the
> process with (ideally) as little dead time in between "runs".

First you should think about your problem in more detail, like how fast
your counters can be triggered, how fast you need to read it and for which
time, all with hard numbers. Then you can plan better what you need.

From the FPGA you can send RS232 data without dead time. Maximum standard
speed usable with all modern PCs or USB adapters is 115200 baud. One stop
bit and one start bit means you can transfer 11520 bytes per second. Some
PCs provides higher baudrates.

The PC has a FIFO, so no byte get lost. If your timing base on the FPGA
side is good, you don't need a timestamp, because you can calculate it from
the byte position in the received stream.

You can implement a full duplex RS232 entity, then you can reset the
counters from the PC. The whole concept should be really simple to
implement.

> I was planning on using the Microblaze synthesized CPU, which I
> understand is the Xilinx provided system.

If you need ethernet for the speed, this would be a good idea, because
developing it on your own, or even trying to use some ethernet core from
OpenCores, is not a good idea for a beginner. Caching in external RAM and
transfering with RS232 would be easier with a CPU, too.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Jul 30, 1:44=A0pm, Frank Buss <f...@frank-buss.de> wrote:
> Griffin wrote:
> > The thing is is that I need to readout the value of the counter every
> > (say) microsecond or less, which is why I figured I would need a RAM
> > buffer, the idea being I would fill the ram with the counter values
> > then read it all out to the computer in one flash, then we restart the
> > process with (ideally) as little dead time in between "runs".
>
> First you should think about your problem in more detail, like how fast
> your counters can be triggered, how fast you need to read it and for whic=
h
> time, all with hard numbers. Then you can plan better what you need.
>

Will do.

> > I was planning on using the Microblaze synthesized CPU, which I
> > understand is the Xilinx provided system.
>
> If you needethernetfor the speed, this would be a good idea, because
> developing it on your own, or even trying to use some ethernet core from
> OpenCores, is not a good idea for a beginner. Caching in external RAM and
> transfering with RS232 would be easier with a CPU, too.
>

Your help is very much appreciated.

The trick here is is that I'm not sure how to implement and actually
use IPs with a synthesized CPU, which is what I must look into I
guess. Essentially, I understand the project build process until one
gets to the Xilinx SDK. The way I understand it, the SDK allows one to
apply C and C++ code to an FPGA project.

Can anyone point me in the right direction for use of the SDK to
implement IPs such as memory interfaces and ethernet controllers (i.e.
a good reference document, a working example of something doing one of
these things, etc.)

Thanks in advance!

Sean