FPGA for hobby use

One of these days we might have an Altera based product. We have been
asked by various people to do one and my very able team could turn an
Altera product very quickly if we decided to do that. The current
record by the team for delivering a working main development board to
a customer is 18 days from start of development. Most of our
competitors couldn't probably get the spec written in that time. That
product is still in the range and shipping.

It's a kind of funny thing that over the years Enterpoint at various
points in time actually did more Altera based work that Xilinx. A long
time ago we considered joining Altera's ACAP but Xilinx's equivalent
at the time came up as a better deal at the same time and the rest is
history.

Back to the present and we have an exciting roll out of products
coming. We have just about caught up on things we have promised for a
while and December and January will start to see the release of things
we have not talked about yet in any detail. Some very different
concepts to appear as well as the nearly predictable. Our own PCIE
core is in beta and working well on our PCIE Broaddown4 and that will
drive PCIE based boards that are the predictable end of the set of
releases coming.

John Adair
Enterpoint Ltd.


On 14 Nov, 19:01, Mike Treseler <mike_trese...@comcast.net> wrote:
> 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

On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote:

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

I still think this is a mistake on an order comparable to trying to
use LabView to wire up assembly language instructions into a useful
program.

There's a time and a place to learn about real circuit implementations
of simple computational structures and of state machines - made of
gates and flip flops, and of gates and flip flops made of
transistors.  But that's not effectively how things work in an FPGA.
FPGAs run on logic equations, which are going to be re-interpreted
into the proprietary assortment of available doodads by the tools
anyway.

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.

The problem with schematic entry is that it's instantation-centric.
If you are using your schematic at a block diagram level to wire up
big modules, that's good.  But if you are using it at a detailed level
to instantiate gates in a real project (or even HDL to instantiate
them), that's just silly.   You should be writing equations - but how
do you enter equations in a schematic?

This is probably one reason why state machine graphical entry exists -
it's still arguably a non-serious tool, but at least it's focused on
what the circuit is supposed to do, not the obscuring detail of how it
does it.

On Nov 14, 2:41 pm, Ray Andraka <r...@andraka.com> wrote:
> cs_post...@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.

Yes, good use.  That's why I suggested a top-level block diagram
schematic made of HDL coded modules could be good.  And yes, it's
extensible down the hierarchy to a degree.  But sooner or later you
will get down to HDL modules, either your own or the vendor mega
function libraries.

> The problem is most schematic
> users don't make very good use of hierarchy at all

Exactly.

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

That says to me that the graphical block diagrams should be complexity
constrained:

- they should be legible on a letter sized piece of paper (as well as
on your monitor without scrolling)

- they shouldn't take more than an hour to re-create from the paper,
either in a buggy new graphical tool or in a textual HDL

It's when people try to create complexity in the graphical
representations - by not using hierarchy - that their unsuitability
shows up.

Hi Chris,
I added some comments below.

<cs_posting@hotmail.com> wrote in message
news:1195069602.205639.51830@o3g2000hsb.googlegroups.com...
> On Nov 14, 1:33 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>
>> 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.
>
> I still think this is a mistake on an order comparable to trying to
> use LabView to wire up assembly language instructions into a useful
> program.
>
> There's a time and a place to learn about real circuit implementations
> of simple computational structures and of state machines - made of
> gates and flip flops, and of gates and flip flops made of
> transistors.  But that's not effectively how things work in an FPGA.
> FPGAs run on logic equations, which are going to be re-interpreted
> into the proprietary assortment of available doodads by the tools
> anyway.
>
OK, but the point I'm trying to make is that schematics can be a good tool
to learn how the circuit is implemented _in_an_FPGA_. The FPGA
implementation is different than, for example, a discrete logic
implementation or an ASIC implementation. When a designer knows how the
circuit will be implementated he can tailor his design to fit. The
correlation between what is drawn in the schematic and what ends up in the
FPGA's LUTs is closer than with an equivalent RTL design, helping the
beginner see which structures are good, and which are bad.
>
> 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.
>
Usually this is true. However, some designs require extracting the fastest
possible timing from the FPGA, or the smallest resource usage. A designer
can code the design in RTL appropriately and hope the synthesis tool gets
the message or they can instantiate FPGA primitives in their RTL. It's my
contention that a designer who has a grounding of the underlying structure
of the FPGA will be at an advantage, and one way to get that knowledge is to
design as a beginner with schematics.
>
> The problem with schematic entry is that it's instantation-centric.
>
Which is my point. Sometimes instantiation is useful for the reasons I
outlined above.
>
> If you are using your schematic at a block diagram level to wire up
> big modules, that's good.  But if you are using it at a detailed level
> to instantiate gates in a real project (or even HDL to instantiate
> them), that's just silly.   You should be writing equations - but how
> do you enter equations in a schematic?
>
Again, a fair point. But the context of this thread is education, not 'real
projects', which, I think, changes what is 'good'.
>
> This is probably one reason why state machine graphical entry exists -
> it's still arguably a non-serious tool, but at least it's focused on
> what the circuit is supposed to do, not the obscuring detail of how it
> does it.
>
>
I've never used state machine graphical entry, I can't comment.

Regards, Syms.

On Nov 14, 3:23 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> OK, but the point I'm trying to make is that schematics can be a good tool
> to learn how the circuit is implemented _in_an_FPGA_.

No they can't.  Unless you are dealing strictly in terms of vendor
megafunctions (and often even then), what you see or enter gets
completely refactored by the tools when they go to implement what
you've asked for.

In contrast, something like a minimum sum of products expression,
which students should learn to write by hand, is actually quite close
to what really happens in a primitive PAL type architecture.

Not that I'm arguing for HDL coding in MSP either - put in the
unsimplified expressions that describe what you want; the tools are
better at simplifying them (hand in hand with duplicating and
expanding for fanout and speed) than you are.

> The
> correlation between what is drawn in the schematic and what ends up in the
> FPGA's LUTs is closer than with an equivalent RTL design, helping the
> beginner see which structures are good, and which are bad.

Define "bad".

Some things that are simple to enter will get expanded, but sometimes
the expansion is an intentional optimization to compensate for fanout
or propogation delay.  You shouldn't design for that.  Design simple
expressions, which are what the tools are tested to compile.

> > 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.
>
> Usually this is true. However, some designs require extracting the fastest
> possible timing from the FPGA, or the smallest resource usage. A designer
> can code the design in RTL appropriately and hope the synthesis tool gets
> the message or they can instantiate FPGA primitives in their RTL.

You can't outsmart the tools by hand coding the general logic of your
design entry like that, as they will refactor what you've done
anyway.  If you want something, you get it by using the constraints
interface to the tools to specify what you need.

> It's my
> contention that a designer who has a grounding of the underlying structure
> of the FPGA will be at an advantage, and one way to get that knowledge is to
> design as a beginner with schematics.

For architectures of the past, yes.  For todays' architectures, the
only designers who understand the underlying structure in the
necessary details are those privy to the silicon vendor's trade
secrets.  Everybody else gets to work with the interface they provide
- and most of their effort goes into the HDL interface and constraints
mechanism, not the schematic entry.

> Which is my point. Sometimes instantiation is useful for the reasons I
> outlined above.

Except that when you are coding the ficticious architecture offered,
mostly you are fooling yourself.

cs_posting@hotmail.com wrote:
> On Nov 14, 3:23 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>> OK, but the point I'm trying to make is that schematics can be a good tool
>> to learn how the circuit is implemented _in_an_FPGA_.
> 
> No they can't.  Unless you are dealing strictly in terms of vendor
> megafunctions (and often even then), what you see or enter gets
> completely refactored by the tools when they go to implement what
> you've asked for.

Any FPGA design source other than
a pure technology netlist is
completely refactored by the tools.
It's all abstraction.

The subject says "FPGA for hobby use".

If I fixed up cars for fun, I might
not want to also own a machine shop.

If I wanted to invest a few hours
wiring up some pseudo-TTL blocks
on a schematic just to make an LED flash,
I might just do it.
No worse than crossword puzzles or
posting on usenet :)

        -- Mike Treseler

<cs_posting@hotmail.com> wrote in message 
news:1195073458.863809.291210@v3g2000hsg.googlegroups.com...
> On Nov 14, 3:23 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>> OK, but the point I'm trying to make is that schematics can be a good 
>> tool
>> to learn how the circuit is implemented _in_an_FPGA_.
>
> No they can't.  Unless you are dealing strictly in terms of vendor
> megafunctions (and often even then), what you see or enter gets
> completely refactored by the tools when they go to implement what
> you've asked for.
>
I disagree! Because I know that FPGAs consist of 4 input LUTs that feed FFs, 
I can design pipelined structures that are faster and smaller than if I had 
no clue as to how the logic is implemented in an FPGA.
>
> Not that I'm arguing for HDL coding in MSP either - put in the
> unsimplified expressions that describe what you want; the tools are
> better at simplifying them (hand in hand with duplicating and
> expanding for fanout and speed) than you are.
>
Speak for yourself! ;-)
>
>> The
>> correlation between what is drawn in the schematic and what ends up in 
>> the
>> FPGA's LUTs is closer than with an equivalent RTL design, helping the
>> beginner see which structures are good, and which are bad.
>
> Define "bad".
>
Slower, bigger, longer P&R, ...
>
> Some things that are simple to enter will get expanded, but sometimes
> the expansion is an intentional optimization to compensate for fanout
> or propogation delay.  You shouldn't design for that.  Design simple
> expressions, which are what the tools are tested to compile.
>
>
> You can't outsmart the tools by hand coding the general logic of your
> design entry like that, as they will refactor what you've done
> anyway.  If you want something, you get it by using the constraints
> interface to the tools to specify what you need.
>
Again, please speak for yourself. I can and do 'outsmart' the tools, 
particularly in pipelined designs. If I structure my VHDL so it can pipeline 
logic that neatly fits the 4 LUT followed by a FF, my design has fewer space 
and timing problems, and P&R runs faster. Or, if I code my design so that a 
clock enable signal gets routed directly to the FFs CE pin, I can take 
advantage of multi-cycle paths much more easily.
>
>
> For architectures of the past, yes.  For todays' architectures, the
> only designers who understand the underlying structure in the
> necessary details are those privy to the silicon vendor's trade
> secrets.  Everybody else gets to work with the interface they provide
> - and most of their effort goes into the HDL interface and constraints
> mechanism, not the schematic entry.
>
>> Which is my point. Sometimes instantiation is useful for the reasons I
>> outlined above.
>
> Except that when you are coding the ficticious architecture offered,
> mostly you are fooling yourself.
>
>
I think that's nonsense. The basic structure of a V4 FPGA is still a 4-LUT 
followed by a FF the same as it was in an XC3000 20 years ago.
To illustrate, here's a problem where you can search C.A.F. for examples. 
Population count. A circuit to count the number of '1's in a vector. If you 
know the FPGA is made of 4-LUTs you can do a much better job of coding it 
than if you don't.

Anyway, I see from Google you had a brief exchange on a similar subject on 
comp.arch.embedded Oct.3rd with Ray Andraka. If he didn't change your mind, 
I'm sure I'm wasting my time also. :-(
This thread is getting way off topic, and I think I've outlined my position 
fairly clearly.

Good luck, Syms.

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

>...HDL level is far superior for managing the the kinds of complexity
>involved in accomplishing real functionality

I don't want to use graphical layout at all.  As I suggested, the
tools aren't yet good enough, so I feel much more comfortable with
text.

But we would be wrong to suggest that text communication is "far
superior" a priori.  That makes as much sense as saying that GOTO is
bad "a priori".  In both cases, it's just good practical advice in
certain circumstances.  Some engineers (perhaps including the original
poster) will always feel more comfortable with a graphical
representation.  It makes it possible, after all, to take in at a
glance a great deal more of the "complexity" which you mention.  I
don't see that text (as we know it) will ever achieve that.  Apart
from syntax colouring and screens bigger than 80x25, we're just where
we were 30 years ago.

If you listen to Swahili for a week, you might conclude that it's not
a practical means of communication.  That doesn't mean that others
won't find it perfectly usable (and preferable to your method, which
they might find intolerably complex).  This isn't because either side
is right.  It's because it's impossible properly to evaluate
alternative systems until you've used both a great deal and, even
then, your preference depends on you.  The comfort you feel with
what's familiar and the discomfort with what isn't are not a good
basis for comparison.

>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

Experience from software systems is that graphical tools don't scale to 
large systems. The trick is to reduce a complex system to a few components 
that can be glued together with graphical tools.

-- 
	mac the na�f

I just want to say that old DOS OrCAD plus old Xilinx "Xblox" ended up being
very quick and very abstract, even if you are instaniating things instead of
synthesizing them.  First, DOS OrCAD is *still* the best schematic editor
(which is just pathetic but true- compare it with Cadance Concept). Second,
Xblox adds the abstraction.  It worked like this- there is for example and
adder component.  A parameter on the adder sets its width.  Wires are used
for busses instead of OrCAD busses, which means to change the width you only
have to mess with the parameters and not a bunch of bus labels.

Also I will point out that ASICs generally use synthesis but high end CPUs
tend to use all hand instantiation (no Verilog case statements allowed). 
This makes hand layout and especially gate-level patches easier.
-- 
/*  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]]);}