FPGA for hobby use

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).

On Nov 14, 9:46 am, Herbert Kleebauer <k...@unibwm.de> wrote:

> 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).

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.

cs_posting@hotmail.com wrote:
> On Nov 14, 9:46 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> 
>> 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).
> 
> 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.

... and after knowing your configuration, use a Makefile to run
implementation and say good bye to the gui.

http://www.dilloneng.com/documents/downloads/gen_ise_sh/

Cheers,

Guenter

I am pleased to have such a positive response to one of our products.

I am also pleased to say that as of this week Rev1.1 is shipping to
customers. The major change is the programing headers are changes to
2x7 2mm headers compatible with our own Prog2 cable and all of the
Xilinx cables with 2x7 ribbon cable. We also now have a limited stock
of Darnaw1 with XC3S1600E and XC3S1200 (I GRADE) fitted. They are not
on the shop website as yet but are available to anyone that needs the
different variants. Pricing etc are listed on our enginering web
pages.

I would also welcome any feedback on Darnaw1 from anyone that has seen
the product as we prepare to start the Darnaw2, and maybe even the
Darnaw3, designs. These wouldn't replace Darnaw1 but will cover
slightly different application areas albeit with the aim of a
compatible footprint within the product family.

John Adair
Enterpoint Ltd.

On 14 Nov, 14:46, Herbert Kleebauer <k...@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).

>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.

I'd agree with that, as practical advice.

Long-term, perhaps we'll expect better graphical tools.  We have
text-based languages now partly because they are easier to define
accurately and because they exploit our familiarity with complex text
written in linear fashion (over several pages), so it's a practical
way to keep a complex design under control and to write it down.

We don't (yet) have comparable graphical tools, but perhaps that will
come.  I'm not sure the Mona Lisa would be as good if Leonardo had
made it with a text-based graphics description language or that
Beethoven's Fifth Symphony has the same appeal when experienced as a
hex dump of the WAV file.

On Nov 14, 10:50 am, MikeShepherd...@btinternet.com wrote:

> Long-term, perhaps we'll expect better graphical tools.  We have
> text-based languages now partly because they are easier to define
> accurately and because they exploit our familiarity with complex text
> written in linear fashion (over several pages), so it's a practical
> way to keep a complex design under control and to write it down.
>
> We don't (yet) have comparable graphical tools, but perhaps that will
> come.  I'm not sure the Mona Lisa would be as good if Leonardo had
> made it with a text-based graphics description language

The problem is that you seem to want to use the graphical layout to
represent the wrong aspect of the design.

Schmetic level and HDL level entry both try to capture functionality,
but HDL level is far superior for managing the the kinds of complexity
involved in accomplishing real functionality.

If you want to do something graphical, do it at the system level.  Use
something like Matlab & Simluink to describe what you want the FPGA to
do, and then use the HDL generation plugins. to make the FPGA actually
do it.

The possible case where FPGA-vendor-tool schematic entry might still
make sense is if you do all the actual implementation modules in HDL
code, but make your top level a system-block-diagram sort of
schematic.

Otherwise you're just trying to represent in messy pictures what is
much clearer in text.

<cs_posting@hotmail.com> wrote in message 
news:1195063469.146499.122220@v3g2000hsg.googlegroups.com...
>
> Otherwise you're just trying to represent in messy pictures what is
> much clearer in text.
>
Dear Whoeveryouare,
That statement may well be true in your case. However, I know of engineers 
who say exactly the reverse!

Don't get me wrong, IMHO, large projects with experienced engineers are best 
served by using a HDL. That said, there are circumstances where I believe 
schematics have an advantage.

You already mentioned one of these cases, when you wrote about a block 
diagram. Another case is when an engineer is first starting to use FPGAs. 
This is the situation being discussed in this thread. The use of schematics 
allows some rookie engineers to get a better grasp of how their circuits are 
realised in the FPGA. The schematic can clearly show individual FFs and 
gates. I'd suggest this is particularly true when engineeers are coming from 
a software background. The schematic design flow is so different from 
software development, it forces a different 'hardware' mindset. When these 
same engineers 'progress' to RTL, the experience they've gained from the 
circuit structures they've built with schematics is very useful.

YMMV.
Cheers, Syms. 

Herbert Kleebauer 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).

So, hundreds of man months of SW effort have seen a nett-step backwards ?
Can you elaborate on some of the drawbacks, and perhaps Xilinx can fix 
them ?

-jg

Herbert Kleebauer wrote:

> 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).

Maybe John will do an altera board someday.
The quartus schematic capture is clean and solid.
The free simulator is also limited to waves,
but the licensed version has a very usable version of modelsim
and an rtl viewer that covers verilog and vhdl.

        -- Mike Treseler

cs_posting@hotmail.com wrote:

>
> Otherwise you're just trying to represent in messy pictures what is
> much clearer in text.
> 

I don't entirely agree with you.  Good use of hierarchy makes schematic 
far clearer than text for many if not most circuits.  It also 
facilitates reuse, maintainability etc.  The problem is most schematic 
users don't make very good use of hierarchy at all, and the tools are of 
little help there as well.  Back when I used Viewlogic, I had 
constructed a rather extensive library of 1 and 2 bit slices, of 
components built up from those slices and of macro functions.  I had 
honed that system well enough so that the top level designs looked like 
signal processing block diagrams, and as you worked down through the 
hierarchy you got to progressively simpler elements.  That methodology 
also allowed me to put placement constraints in the design.

The real advantages to using an HDL are:
1) they are readable with just a text editor, and therefore can be 
archived without also archiving the tool and the computer.  This also 
means version control is easier.

2) It is far easier to build parameterized objects with an HDL.  This 
provides a means for faster reuse.  This is mainly a tools issue, since 
nothing was really made to automate parameterized schematics.

3) Currently, the tools for HDL designs are far superior to the 
schematic tools, mainly because that is where the effort has been 
focused over the last decade.