FPGA for hobby use

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.

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 Enterpo> A few month ago I asked for a recommendation for FPGA (not a ready to use demo

board)

(documentation)ftp://137.193.64.130/pub/mproz/mproz3.zip (documentation + schematics)

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.

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.

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.

board)

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

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

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.

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.

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.

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.

Exactly.

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.

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.

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.

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

Again, a fair point. But the context of this thread is education, not 'real projects', which, I think, changes what is 'good'.

I've never used state machine graphical entry, I can't comment.

Regards, Syms.

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.

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.

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.

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.

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

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

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.

Speak for yourself! ;-)

Slower, bigger, longer P&R, ...

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.

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.

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.

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:p158?-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]]);}