FPGA for hobby use

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.

That's no alternative. At the time of the course, the students know
about logic gates, flip-flops, how to minimize a logic equation and
how to design a simple state machine. And then there are exactly 10 hours
form reading the processor specification till the download of the 
bit stream into the FPGA. This includes the time to get used to the
development software. And most of them will never do any hardware
design later anymore. But this year we will let one group use the new
Xilinx software, so we will see what's happen.

Jim Granville wrote:
> Herbert Kleebauer wrote:

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

- I had more crashes with ISI 9.2 in the last few weeks than I have seen 
  in 10 years laboratory course with the old XILINX DOS software

- The essential drawback is the missing back annotation of the simulation
  results into the schematic. This is like debugging software with print
  statements instead of a source code debugger. A few years ago I tested
  an older version (I think it was ISI 2.1) and there at least you could 
  attach probes in the schematic to display the states of signals.
  This also was only a makeshift, but better than nothing.

- To much of the screen is wasted with the different windows. There should
  be a full screen mode for the editor with keyboard commands and no menus 
  at all (only hidden pull down menus). 

- I think the documentation has to be improved. If you have to use Google 
  to find some information, then something is wrong with the documentation.
  Had real problems to find out how to update the bit stream with a new memory
  content using data2mem.exe. This was also because of some very poor error
  messages generated by the software.

- There also could be some improvement in the user interface, but this
  always depends on user preferences. Does Xilinx have a quality feed
  back program where customers are asked for suggestion for improvements?

On Wed, 14 Nov 2007 15:46:03 +0100, 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

>Conclusion: 
>The board is great, [...] 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).

Is there any technology-independent way out of the Viewlogic/Dos
software? Such as a fairly generic EDIF netlist?

The newer tools seem pretty stable, with the apparent exception of the
schematic path. Perhaps they can be induced to work with EDIF input
generated from the old schematic flow.

(If so, that may open the way to finding other, non-Xilinx, schematic
tools capable of generating compatible EDIF. Altium may have something
worth looking at, but not needing schematics, I haven't properly looked
at their products.)

- Brian

Brian Drummond wrote:

> Is there any technology-independent way out of the Viewlogic/Dos
> software? Such as a fairly generic EDIF netlist?

Yes, Viewlogic can output an edif netlist, at least it did some 10 years 
ago when I last used it.

On Nov 15, 2:41 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> - The essential drawback is the missing back annotation of the simulation
>   results into the schematic. This is like debugging software with print
>   statements instead of a source code debugger. A few years ago I tested
>   an older version (I think it was ISI 2.1) and there at least you could
>   attach probes in the schematic to display the states of signals.
>   This also was only a makeshift, but better than nothing.

Now that's funny!  You don't like HDL, but a source level (text)
debugger is a better idea?

Just how do you do a simulation without some sort of textual
stimulation (or with an hdl, at least  you can have behavioral
stimulation)? Please don't tell me  you click on a wire and start
typing ones and zeroes?

I think the bottom line is that graphics show structure better, text
shows behavior better. I use RTL viewers (synplicity and quartus are
really good) to extract the structural graphics from my HDL source if/
when I need it (presentations, reviews, etc.) It is a lot easier to do
that than to specify (or debug) behavior from graphics.

I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic
capture for xc2000/xc3000 designs, and I hated VHDL for a long time.
My old boss hung up a quote of mine about trying to design SW by
drawing pictures, while HW design was hell-bent-for-leather, headed
the other way. Previous poster notwithstanding, I used GED (precursor
to Concept) to build wonderful, intelligently parameterizable
functional blocks that could be interconnected in an easily
understood, structual way. Unless I needed to design a state
machine... That's when I started to design behaviorally, instead of
structurally. Now, design structure is mostly about managing
behavioral complexity, and a only little about managing physical
complexity. Once you make that thought shift, it's gravy from there
on.

So where is the future of "schematic capture"? Just like in board
level design, when you are designing structurally with pre-
manufactured blocks, and just hooking them up with wires, that's where
graphical design entry makes sense. We're probably headed back there
with FPGA's, what with increased use of IP, where the bulk of our
"design" is hooking up pre-designed blocks of circuitry. So we dive
into a custom block every now and then to use HDL to design a custom
behavioral translator to make block A talk to block B...

BTW, I've used Concept and Capture (Orcad) for board design, and trust
me, Concept is WAY ahead of Capture. They keep adding features from
Concept into Capture though, so one of these days...

Alright, I've ambled on enough.

Andy

On Thu, 15 Nov 2007 09:48:22 -0500, Ray Andraka <ray@andraka.com> wrote:

>Brian Drummond wrote:
>
>> Is there any technology-independent way out of the Viewlogic/Dos
>> software? Such as a fairly generic EDIF netlist?
>
>Yes, Viewlogic can output an edif netlist, at least it did some 10 years 
>ago when I last used it.

That's part of the answer. 

But is the information in that netlist comprehensible by the Xilinx
tools? It may be generic, while ISE may require Xilinx-specific
information. This would require some experimentation by the OP, if he is
considering newer FPGA platforms. 

- Brian

Andy wrote:

> 
> I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic
> capture for xc2000/xc3000 designs, and I hated VHDL for a long time.
> My old boss hung up a quote of mine about trying to design SW by
> drawing pictures, while HW design was hell-bent-for-leather, headed
> the other way. Previous poster notwithstanding, I used GED (precursor
> to Concept) to build wonderful, intelligently parameterizable
> functional blocks that could be interconnected in an easily
> understood, structual way. Unless I needed to design a state
> machine... That's when I started to design behaviorally, instead of
> structurally. Now, design structure is mostly about managing
> behavioral complexity, and a only little about managing physical
> complexity. Once you make that thought shift, it's gravy from there
> on.
> 

Andy, before I abandoned schematics, I had come up with a very workable 
graphical state machine entry for schematics.  The schematic looked just 
like a state diagram.  Basically, I made schematic wrappers that looked 
like state diagram elements so that putting together the state machine 
was much like drawing it out.  Of course it resulted in a decoded state 
machine, but that was OK since that was the style that generally yielded 
the best results in FPGAs of the time anyway.  The components were: a 
state bubble containing a flip-flop; a decision box, which contained a 
pair of AND gates with the decision input inverted into on and not into 
the other; and a wire junction, which wrapped around an OR gate.  I 
think there were a few other elements, but these were the major ones. 
It made for very fast entry, and very readable state machine schematics. 
  I also had a methodology for encoded state machines that made it easy 
to read the function.  I don't recall off the top of my head what I did 
there, but it basically involved a mux element with all the states shown.

Brian Drummond wrote:

> On Thu, 15 Nov 2007 09:48:22 -0500, Ray Andraka <ray@andraka.com> wrote:
> 
> 
>>Brian Drummond wrote:
>>
>>
>>>Is there any technology-independent way out of the Viewlogic/Dos
>>>software? Such as a fairly generic EDIF netlist?
>>
>>Yes, Viewlogic can output an edif netlist, at least it did some 10 years 
>>ago when I last used it.
> 
> 
> That's part of the answer. 
> 
> But is the information in that netlist comprehensible by the Xilinx
> tools? It may be generic, while ISE may require Xilinx-specific
> information. This would require some experimentation by the OP, if he is
> considering newer FPGA platforms. 
> 
> - Brian


It was back then.  You could add attributes such as RLOCs, TNMs, and 
HU_SETs to the symbols and they would get passed through to the netlist 
correctly.  My standard flow back then was Viewlogic to edif netlist, 
and then netlist into the Xilinx tools.  I think the Xilinx tools may 
have become more picky about what goes in since then, in that I'm not 
sure the translate will convert generic gates to LUTs any more like it 
used to.  The synthesis tools all pretty much do all the conversion to 
LUTs and other Xilinx primitives now.

On Nov 16, 2:07 pm, Ray Andraka <r...@andraka.com> wrote:
> Andy wrote:
>
> > I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic
> > capture for xc2000/xc3000 designs, and I hated VHDL for a long time.
> > My old boss hung up a quote of mine about trying to design SW by
> > drawing pictures, while HW design was hell-bent-for-leather, headed
> > the other way. Previous poster notwithstanding, I used GED (precursor
> > to Concept) to build wonderful, intelligently parameterizable
> > functional blocks that could be interconnected in an easily
> > understood, structual way. Unless I needed to design a state
> > machine... That's when I started to design behaviorally, instead of
> > structurally. Now, design structure is mostly about managing
> > behavioral complexity, and a only little about managing physical
> > complexity. Once you make that thought shift, it's gravy from there
> > on.
>
> Andy, before I abandoned schematics, I had come up with a very workable
> graphical state machine entry for schematics.  The schematic looked just
> like a state diagram.  Basically, I made schematic wrappers that looked
> like state diagram elements so that putting together the state machine
> was much like drawing it out.  Of course it resulted in a decoded state
> machine, but that was OK since that was the style that generally yielded
> the best results in FPGAs of the time anyway.  The components were: a
> state bubble containing a flip-flop; a decision box, which contained a
> pair of AND gates with the decision input inverted into on and not into
> the other; and a wire junction, which wrapped around an OR gate.  I
> think there were a few other elements, but these were the major ones.
> It made for very fast entry, and very readable state machine schematics.
>   I also had a methodology for encoded state machines that made it easy
> to read the function.  I don't recall off the top of my head what I did
> there, but it basically involved a mux element with all the states shown.

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?

On Fri, 16 Nov 2007 13:48:11 -0800 (PST), 
Dave <dhschetz@gmail.com> 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?

When designing control logic, I generally very much prefer to
write - and think - in HDL because it helps me describe 
sequential flow of behaviour.  When designing datapath,
and especially when describing fixed-function (or nearly
fixed-function) DSP datapath, I still tend to use HDLs
nowadays but there's no doubt I'm thinking in block-level
schematic - adders, normalisers, MACs, that sort of thing.
Note that users of DSP simulation software generally use
block diagrams rather than procedural code, so I reckon
I'm in good company.

I guess the deal is roughly this:  When you have concurrently
executing blocks each of whose functions is nontrivial but
largely invariant (same behaviour on every clock tick), 
it's easier to think in block diagram terms.  When you 
have a complicated function whose behaviour varies
rapidly over time (state machine), it's easier to think
in terms of procedural code (at least, it is for me).
Ray Andraka's ingenious state-diagram-to-schematic
transformation, which I think he's described here in 
the past, is a good example of an alternative view.

*All* our design-capture tools and methodologies
are nothing more than steps on the way from 
design concept to implementation.  If a tool,
language, or diagram-methodology is to be useful,
it must:
- provide a convenient bridge between two points
  on the design refinement pathway that otherwise
  would be too far apart to link in a single step;
- provide a framework for thinking that is not
  too restrictive, but also is prescriptive enough
  to allow you to get started on a problem easily;
- be rigorous enough to allow you, and (ideally)
  automated tools, to reason about the design;
- be readily comprehensible by other practitioners.
Schematics, state diagrams, Boolean equations, 
HDLs and graphical DSP design tools have all 
proved their worth against these criteria.
Changes in technology, and changes in the scope
and difficulty of designs that you undertake,
will shift the balance in favour of some and
against others.  It's silly to be dismissive of
any of them out of context.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.