Prev: [ANN] Menace of the Mines 0.4 released!
Next: Simple Hack To Get $2000 To Your PayPal Account
From: Greg Menke on 13 Jul 2010 14:44

David Blubaugh <davidblubaugh2000(a)gmail.com> writes:
> To All,
>
>
> I am right now in the process to determine if LISP can be utilized to
> develop an FPGA applications??
>

I've not used it to develop firmware but I have used it to summarize
and graph data collected from logic analyzers. Essentially, the logic
analyzer collects designated events, the data is copied off the analyzer
and a Lisp program reads it, computes and produces graphs, reports, etc.
The analyzers usually have extensive summarization and analysis tools,
but this "custom" approach where your analysis algorithm is exactly
suited to the domain-specific idiosyncracies of the device (&
measurements) is sometimes (possibly often) very useful.

Lisp is handy because setting up the structures to contain the data is
straightforward and the reader does the hard work of parsing the data.
The robust numeric type system also lets you avoid fussing with integer
lengths and float rounding- which start to show up when you have to deal
with timing in the nanoseconds (with resolution in the picoseconds)
using C-like languages. You can do the same in most any language but I
found Lisp the quickest environment to do it in.

As a rule, each device I've dealt with needs a different analysis
algorithm, and different data is recorded by the analyzer, so being able
to quickly adapt older code is important, which is another place where
Lisp is helpful because the investment in syntax per algorithm element
is smaller- thus easier to change & verify. I use CLISP for quick &
dirty work, Lispworks when the datasets are large, algorithms need a lot
of cpu time, or are more involved.

The older HP analyzers we had a nice TCP based shell that my Lisp code
could connect with directly to operate the analyzer and read the data.
Since HP went Windows, those sorts of nice features were removed in
favor of the ActiveX/COM nonsense, which means the process is less
efficient. Now instead I have to save off a comma delimited file and
read that- it isn't a huge problem, just more fiddling & less
flexibility.

Greg
From: Petter Gustad on 20 Jul 2010 09:41
rpw3(a)rpw3.org (Rob Warnock) writes:

> David Blubaugh <davidblubaugh2000(a)gmail.com> wrote:
> +---------------
> | Can I use LISP as a hardware description language and then have LISP
> | to be generated into a binary file to be downloaded to an FPGA??
> +---------------
>
> Short answer: Yes, but you'll need to have *good* documentation
> on the binary file format.

Well, you could simply read the EDIF file into the FPGA back-end tools
and generate FPGA image file. But it will probably not save you much
in terms of compute time over other HDL input, unless you can generate
the EDIF in such a way that it fits perfectly into the device so there
is almost zero effort in the fitter and place&route tools.

There has been some Lisp influence in the EDA world. EDIF is one, SDF
(standard delay file) is another. Also the Cadence extension language
(SKILL) was Lisp based. Even though ACL2 is not an HDL, it has been
use to formally prove HDL code.

Petter
--
..sig removed by request.
From: David Blubaugh on 21 Jul 2010 19:58
On Jul 13, 11:44 am, Greg Menke <guse...(a)comcast.net> wrote:
> David Blubaugh <davidblubaugh2...(a)gmail.com> writes:
> > To All,
>
> > I am right now in the process to determine if LISP can be utilized to
> > develop an FPGA applications??
>
> I've not used it to develop firmware but I have used it to summarize
> and graph data collected from logic analyzers.  Essentially, the logic
> analyzer collects designated events, the data is copied off the analyzer
> and a Lisp program reads it, computes and produces graphs, reports, etc.
> The analyzers usually have extensive summarization and analysis tools,
> but this "custom" approach where your analysis algorithm is exactly
> suited to the domain-specific idiosyncracies of the device (&
> measurements) is sometimes (possibly often) very useful.
>
> Lisp is handy because setting up the structures to contain the data is
> straightforward and the reader does the hard work of parsing the data.
> The robust numeric type system also lets you avoid fussing with integer
> lengths and float rounding- which start to show up when you have to deal
> with timing in the nanoseconds (with resolution in the picoseconds)
> using C-like languages.  You can do the same in most any language but I
> found Lisp the quickest environment to do it in.  
>
> As a rule, each device I've dealt with needs a different analysis
> algorithm, and different data is recorded by the analyzer, so being able
> to quickly adapt older code is important, which is another place where
> Lisp is helpful because the investment in syntax per algorithm element
> is smaller- thus easier to change & verify.  I use CLISP for quick &
> dirty work, Lispworks when the datasets are large, algorithms need a lot
> of cpu time, or are more involved.
>
> The older HP analyzers we had a nice TCP based shell that my Lisp code
> could connect with directly to operate the analyzer and read the data.
> Since HP went Windows, those sorts of nice features were removed in
> favor of the ActiveX/COM nonsense, which means the process is less
> efficient.  Now instead I have to save off a comma delimited file and
> read that- it isn't a huge problem, just more fiddling & less
> flexibility.
>
> Greg

Greg,

Are you out there ?? I would like to talk with you more on this
subject??

David

First  |  Prev  | 
Pages: 1 2
Prev: [ANN] Menace of the Mines 0.4 released!
Next: Simple Hack To Get $2000 To Your PayPal Account