FPGA for hobby use

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.

Reply to
Herbert Kleebauer
Loading thread data ...

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

Reply to
Herbert Kleebauer

board)

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

Reply to
Brian Drummond

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

Reply to
Ray Andraka

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

Reply to
Andy

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

Reply to
Brian Drummond

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.

Reply to
Ray Andraka

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.

Reply to
Ray Andraka

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?

Reply to
Dave

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
 Click to see the full signature
Reply to
Jonathan Bromley

board)

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
Reply to
Nico Coesel

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"

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

Reply to
Ray Andraka

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)
 Click to see the full signature
Reply to
Joseph H Allen

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.

Reply to
Andrew Burnside

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.

Reply to
Nial Stewart

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.