FPGA for hobby use

Herbert Kleebauer <klee@unibwm.de> wrote:

>A few month ago I asked for a recommendation for FPGA (not a ready to use demo board)
>which could be handled with simple home equipment. I got the link to:
>
>http://www.enterpoint.co.uk/moelbryn/darnaw1.html
>
>We ordered a few samples and did some experimenting. Here the documentation
>for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by
>step introduction which should allow anybody still unfamiliar with FPGA design
>to implement the demo in less than a hour.
>
>ftp://137.193.64.130/pub/mproz/mproz3_e.pdf  (documentation)
>ftp://137.193.64.130/pub/mproz/mproz3.zip    (documentation + schematics)
>
>Conclusion: 
>The board is great, not just an other demo board, but rather a package
>converter from the FPG ball grid to a pin grid array with the necessary
>voltage converters and program flash on board. Sadly the same can't be 
>said about the current Xilinx software (schematic editor + simulator), 
>so we will try to stay as long as possible with the X3000 chips and the
>old Xilinx DOS software (with ViewLogic schematic entry + simulator).

At this moment I think either Verilog or VHDL is the best route. And
it probably is for the next few years.
I have a customer which has a lot of legacy in schematics (Orcad/ XNF
format) which is totally useless with the newer ISE versions. Their
VHDL code however ports nicely between various ISE versions.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Dave wrote:

> I remember hearing the rumor that the Graychip (now TI) GC4014 quad
> DDC chips were designed using schematic entry - quite a feat
> considering the complexity of the chips. I'm sure the design involved
> a library like the one Ray described, eventually building NCO's and
> complex multipliers out of gates. Granted, that was an ASIC design,
> and maybe it makes more sense there, but still... maybe DSP folks are
> more biased to this design methodology than pure digital folks?

I can tell you for fact that I designed systems considerably more 
complex than those DDC chips using schematics.  In fact many of those 
systems included DDCs that compared very favorably against the Graychip 
devices in terms of performance.  For example, the design described in 
my paper "An FPGA based processor yields a real time high fidelity radar 
environment simulator" (http://www.andraka.com/files/mapld.pdf) was a 
design done with schematics that involved more than a dozen unique 
XC4025 designs.  It would have been impossible to meet the density and 
performance requirements with the VHDL tools available at the time 
because of the floorplanning required to get it all to fit.

In article <473e2dbe.1233804717@news.planet.nl>,
Nico Coesel <nico@puntnl.niks> wrote:

>I have a customer which has a lot of legacy in schematics (Orcad/ XNF
>format) which is totally useless with the newer ISE versions. Their
>VHDL code however ports nicely between various ISE versions.

So is this DOS OrCAD or Windows OrCAD?  I have a very rough tool which
converts DOS OrCAD into Verilog.  If there's interest I'll post it.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On Nov 14, 3:07 pm, cs_post...@hotmail.com wrote:
>
> The real problem is your insistence on using schematic entry for
> things of moderate complexity.
>
> Learn a hardware description language and your life will be much
> easier.

Whilst, I accept that it is necessary to know HDL, I think this is an
over-simplification of the issue.

There seems to be a complete aversion by digital hardware engineers to
graphical representation of problems, perhaps due to too many years of
limited schematic tools. There seems to be a 'Code Warrior' mentality
amongst many hardware engineers, that is reminds me of software
development a few years back. I have heard comments from my
colleagues, such as 'I look at the datasheet, and the code appears in
my head'. This is hardly a consistent process.

Considering the software case, generations of more complex languages
have meant that it is no longer necessary to code at a low level all
of the time. (Of course sometimes you need to). Graphical
representation such as UML means that you just draw your state
machines, rather than having to implement by hand. It is a lot easier
to review diagrams than code.

Now looking at hardware, whilst there may be a few occasions where it
is necessary to tweak state machines due to silicon cost /
performance, most of the time this is unecessary. Even if I am going
to write a state machine in HDL, I would much rather draw it out on
paper first, so that I can see if I have forgotten something. In
common usage, there are only so many maintainable ways to implement a
state machine, which means it is a sensible thing to template (or use
a graphical tool). For those who argue about tweaking the state
coding, this is only necessary in a few cases, as most of the time the
synthesis tool will probably change it anyhow. This is why I have now
moved to SystemVerilog enums for run of the mill state machines (much
less hassle, allowing me to concentrate on the bigger picture). Of
course, there are other instances e.g. RAM based state machines, where
you may want to do something different, but this is the exception
rather than the rule.

Having come originally from a DSP background, drawing out dataflow
diagrams of the progress of data makes sense during algorithm design.
e.g. it is much easier to have idea of multirate / CIC filters etc. by
drawing them out. Similarly, in my current non-DSP FPGA design by
drawing a block diagram of the data flow through FIFOs, compare
units,  memory interface etc., I had a better idea of what was
happening before I started to implement it. Whilst, detail may warrant
the use of HDL, it is much easier to understand how something works at
a macroscopic level by visualising it.

Another example, would be the design of clock domain crossing
schemes / handshaking etc. Personally, I find it much easier to draw
out a bunch of latches, associated timing diagram, or even a petri net
than leap straight in. That way there is no ambiguity about the
functionality that I want to implement, and I can trace the signals
round even before starting to write HDL.

I think someone mentioned about all FPGAs being LUT4. This is not
true, as Virtex-5s are LUT6. Implementation specific tweaks are always
going to be necessary for some apps, but are a complete waste of time
if you don't actually need them as they reduce the portability of your
code. I doubt that everyone is working on the hairy edge all of the
time.

Of course, synthesis all the way down from a specification level
description is not here. However, considered use of a combination of
graphical and text based approaches can make life a lot easier.

> Nobody should be instantiating discrete gates in an FPGA (iobuffers
> and other special ones exempted), instead they should be writing
> equations - HDL code - that accomplish the intended function in a
> concise and comprehensible way.


I don't think Symon's suggesting that schematics should be used at this
level, but an introduction via shematics will give some background in
what's being implemented.


It might help someone undertand why it's not a good idea to have
too many layers of 'if' statements in a process if they're trying
to meet tight timing requirements etc.



Nial.