FPGA with 5V and PLCC package

- and another reference data point, FYI, to compare with your present design flow, is the compile/build/fit time:

This design is fully rebuilt, ready to download, in ~1.0 seconds.

The editor can be set to silently reload changed files, and remembers the cursor XY, so it is not unlike a browser refresh in speed/convenience.

Interested in how that compares with what you have now ?

-jg

Since when does VHDL not have AND, OR, NAND, NOR, and D flip flops?

Perhaps the problem is that it has a lot more than these. But the solution is also simple: make rules about what they are allowed to use. Provide a preprocessor or audit tool that will enforce this - the only thing you are allowed to do is instantiate these allowed basic entities and hook them up with plain wires and vectors.

But the fact of the matter is that there is hidden technology at all levels of the system. As has been pointed out, the tools don't implement the actual gates you've drawn, they implement a logical equivelent. And there's also sorts of hidden semi-proprietary stuff on the FPGA die. You may find this easier to ignore with an older part, but it's still true. Unless you go back to very raw TTL type chips (or maybe even earlier), what your students will be designing with is a black box abstraction that _does not really match_ its logical symbol representation except in explicit ways the data sheet says it does.

Is this an engineering major's course or some sort of survey thing?

These are not electrical engineering but computer science students. Their job will be to design software and not hardware systems. But in order to do a proper software design, you need to understand the principles of the underlying hardware so you get a feeling what a few lines of HL code can mean for the hardware.

I don't know if all the supporters of VHDL/Verilog/HandleC here have done low level logic development using a graphical representation and just don't recognize how important that is to become a good designer at VHDL level or if they have never done this and still think they are good developers because the VHDL compiler is good enough and therefore they don't need to know anything about lower levels.

Again the city map is a good example: If you want to drive from A to B, you call a taxi, the driver enters the target into the navigation system and this system mostly does a much better job you could do with the city map on your lap. So this is the best you can do if you know nothing about the city. But if you know the layout of the city and you know that there is a river with only two bridges where you have to wait a long time because of the high traffic and you also know that there is a small bridge which could only be passed by foot, then you could do a much better job by driving to the small bridge, cross the river by foot and use an other taxi on the other side.

The same is true for software: if you know how the hardware works you maybe can choose a different approach to solve the problem which is much more appropriate for the hardware. The compiler can do local optimizations extremely good, but the best global strategy has to be chosen by the programmer. And I think the same is true for hardware design. Just writing down VHDL statements without understanding the consequences for the generated hardware is not the way to go.

The purpose of Universities is not to teach the students the use of tools but to teach them how to recognize, analyze and solve problems. The tools you use to solve the problems change rapidly but the ability to understand the source of a problem and analyze it from all angeles without using blinders is an essential requirement for the whole life.

And as I said in the original posting, replacing the schematic entry by VHDL/Verilg isn't an alternative. All I wanted to know is, if somebody already was able to run the old Vielogic (DOS) on an actual OS (using a virtual machine). Or, whether there exists new FPGA's with a development system which is as easy to use as Viewlogic/DOS _AND_ where the chips are available in a package which could be soldered with a normal soldering iron on a self made non-multilayer PCP. I think there are both things available, but I didn't find the _AND_ combination.

Sorry, but it really doesn't matter whether the AND gate is implemented as AND gate, by multiplexers or as a look-up table. They have learned that this all is equivalent and that the order of complexity is the same. But they must learn that there is big difference in the complexity for the ALU operation "add" and "div" and they don't see this in the VHDL source code.

I will assume this is for an undergraduate frosh level course, adjust as appropriate.

When I took such a course, it was in the days of 74LS series logic. I even remember learning that the 7474 has a positive hold time, but 74LS74 has zero hold time.

As I understand it, many such courses are now taught using only simulation.

(snip)

I try to write structural verilog (except for FF's), which tends to have more of the feel for the logic layout than behavioral verilog. (Also, I believe it is more readable than VHDL but that's a different question.)

Assuming you believe that eventually it is better (as projects get larger) to use HDLs, is it better to start earlier?

-- glen

Herbert Kleebauer wrote: (snip)

My belief is that one should always understand the system one level below that which one is using, so yes HLL programmers should understand assembly programming. I don't believe that means one should learn assembly programming first, though. Even so, a lower level HLL like C tends to be pretty close in the number of operations compared to the amount of C code. In both cases some operations take more time than others, and one has to learn that eventually.

Both HDL and schematic capture can be done using library modules that are simple or complex, in pretty much the same way that either assembly or C can call complex system macros or library routines.

-- glen

Nothing much in formal words yet other than a brief description here of Craignell

tml. The main points are FPGA XC3S100E or XC3S250E or XC3S500E. Pullups to input voltage that in currently version can range cica 3.7V - 5.5V. Bus switches protection FPGA I/O. Serial flash for loading and possibly code store for Microblaze. Initial parts we are fitting a

4Mbit flash but up to 16Mbit is possible. Headers for JTAG and SPI loading.

Price for a one off from circa GBP=A330, 45 euro, US$60 depending on variation. We will have university discounts and OEM quantity discounts.

John Adair Enterpoint Ltd.

t -

Yes, that's why you look at some parts of the problem in depth. But the key to being a working engineer - especially a software engineer - is becoming comfortable with the uses (and wary of the potential ABuses) of abstraction.

The problem I see is that you are making the assumption that _graphical representation_ is the only appropriate way to do low level design. I'd argue it generally isn't.

More suitable low level design notations are things like minimum-sum- of-products equations, and the Karnough maps that one might use to create those by hand. Sum of products is directly implementable in hardware - you could indeed have them draw some representative examples as gates. But it's a much better notation system when you find it necessary to take the black boxes apart and look at their functionality.

Conversely, if you've got most of the functionality as black boxes, and putting in a single NAND symbol gate somewhere to show how a some interrupt signal works or something is a great idea. But don't draw the ALU using logic gates - instead, draw a half adder using gates, and then draw a full adder made from half adders, or get into carry chains, or whatever.

A key reality that you are refusing to acknowledge is that you will not receive an actual "map to the city" of anything but a first- generation FPGA. That kind of detail is proprietary. What you get on the data sheet is a programming model, with a lot of things already hidden from you. Using an FPGA to implement something that you've designed at the gate level is not a bad idea, but you must come to terms with the fact that your gate level design is only theoretical - even if you draw it in schematic entry, the tools is going to refactor it using its knowledge of the proprietary details of the hardware.

So what I'm saying is, if you want your students to do low level implementation, that is fine - but as they will in reality be implementing agaisnt a theoretical technology rather than a real one, pick an academically convenient theoretical technology (rather than a dated commerical programming model) and handle the inevitable translation to a purchasable chip in a more elegant way.

- Come up with a schematic entry tool if you really want to, that spits out gate-level VHDL.

- Come up witha preprocessor tool that allows students to code in a gate-and-register logic language - either a subset of a real language like Verilog or VHDL, or a made up academic one.

In today's world you do not in fact get to know how the hardware works for a processor either. Instead, you have to work against a programming model published by the processor vendor - hopefully it is not a model that causes the actual hardware to thrash around doing things that do not suit it well. It's been a long time since an x86 CPU actually ran "native".

And ever since we stopped designing chips on single pieces of paper, the number one skill for a solving problems has been developing a healthy relationship with the _concept of abstraction_.

They most certainly will see this in the VHDL source code if you have require them to code up the ALU functionality from sufficiently small building blocks!

Case in point: I re-did one of my computer archictures courses using Verilog and Xilinx FPGA, in place of the theoretical simulation. The course work walked you through building all the pieces of the ALU functionality - shifter, adder, etc... but left out hardware multiply. So I resigned myself to not using multiply. Unfortunately, when I moved on from low level assembly programming to trying to get some real work done with gcc, I couldn't convince it to not generate multiply instructions (even for things where there would have been better choices). So I decided to cheat... I instantiated a spartan-3 multiplier. The result is that I have a very good idea how my project accomplished all the other functions, but only a vague sense of how it multiplies. And that was a strategic choice - had I wanted to know about how the multiplier works I could have eventually built one, but I was satisfied with understanding the rest of the ALU, and I know that the hardware mutliplier in the spartan is much better than any FPGA-fabric implementation.

The moral? Pick your battles. Your course project doesn't have anything that can't easily be implemented as gates and registers, so let your students implement in a gates and registers programming model. But recognize that just because a language will let you utilize fancy functions like a hardware multiplier does not mean that you have to choose to do so, or let your students do so.

There is nothing but obstinance stopping your student from doing very educational gate level implementation in a language also capable of higher level functions!

Ah - CS students. I can understand that Schematics look more like HW, and importantly, to a CS student, it does not look like Software. (even tho is is, long before it hits the FPGA)

I've also seen CS tutors use 8 bit Microcontroller simulators/ICE systems to teach the basics. Little devices like 8051/PIC, where you can see each opcode and port pin change.

For 'real iron' stuff, that is cheap and easy to 'see the opcodes', try this

That was why I suggested a _lower_ level language, such as CUPL or ABEL, and a CPLD. Think of these as the assemblers of the HDL world.

Absolutely agreed. If you do not know how the design maps onto the HW, you are only doing half a job.

Which is why the .FIT reports are so important. You can see every gate, and product term _actually used_ in these, and we have given Atmel much feedback to make these reports clearer, and more useful to the design process.

[*] Even this first one could be a struggle! - see other threads on XST, and users experiences with the SCH flows of that.

You could also get a copy of this

and see if that is Graphical/Schematic enough for your needs. I'd call it quasi-sch in form, in some areas of operation, not a full SCH, but it looks more like HW than SW in some views.

-jg

You might try the the SystemDesigner software that offers a complete flow. It seems that there's a free download in the FPSLIC AT94K section of the website. You'd have to try if it lets you target an AT40K FPGA (without the AVR portion).

I made bad experiences with the previous version of SystemDesigner (v2.1). The implementation was impossible for designs with high device utilization. The reason was that the place and route tool was unable to resolve "short critical paths", ie signals that race with the clock. The tools only cared about "long critical paths" (signals too slow for specified clock rate), trying different routes until they disappeared. For short paths it had no remedy but flag them in the timing report.

Maybe the v3.0 tools are better. I wouldn't want to use v2.1 for a CPU project and have to spend the last 15 minutes of the course on an explanation about why their schematic is OK but the implementation doesn't work.

Regards, Marc

In VHDL, you are correct, but in Boolean Eqn entry [CUPL], you have to manually 'build' the adder, so they are VERY much aware of the cost. You can also see the ALU resource any time you glance at the report file. You can even discuss the trade-offs in adders, with speed/width, if you want to, simply by letting the tools remove nodes, or not. [try doing that in the SCH pathway ?]

-jg

Herbert Kleebauer wrote: (snip)

To me the question isn't graphical vs. textual, it is how well one understands the underlying logic.

I agree with this one. Though a good navigation system might know about the bridge. Some city bus systems have a computer which will do route calculations. That might include walking across a bridge, otherwise it is up to the user to do that before calling the taxi.

I completely agree with this statement. One thing one must learn, either with VHDL or graphical entry is the cost for each logic block. Just as in C programming, the tools don't help much, one just has to learn it.

I 100% agree here. (Though I know a lot of people don't.)

In different discussions I have suggested that people should remember the days of wiring up TTL gates on breadboards. Using lower level HDL constructions is closer to that than some higher level ones. I don't know about VHDL, but you can do verilog at the gate level. That is, in addition to behavioral and structural there is a level with references to gate level primitives.

(snip)

Thinks may have changed, last I knew the synthesis tools wouldn't synthesize divide, at least not divide by a variable. Maybe it is just how much I hate using schematic entry tools. If you draw the design on paper using a gate template, maybe using 7400 series logic blocks, and then write the corresponding HDL I don't think you are missing out on anything. I can probably do it with a minimal hand drawn schematic, as I can solve algebraic equations without doing all the intermediate steps, but it does still help to write some down on paper.

-- glen

I have to argue somewhere in between. The designer should have some idea about what is going on in the hardware. For FPGA it isn't quite as easy to see, so imagine a standard cell design instead. For standard cell the actual complexity is closer to that seen by the designer.

It does help to imagine it in terms of gates, just as a C programmer can imagine his code in terms of machine instructions. Though with modern RISC machines you might be as far from what one can imagine as FPGAs are from gates. One should be able to choose a design based on complexity or speed. (Often speed is more important than size, and that isn't so obvious if you can't imagine the gate level.)

One has to look at the problem at different levels. One is the gate level, another would have been the MSI level in TTL days, adders, counters, multiplexers, decoders. One doesn't need the exact details (though I do still like to see the designs in the TTL data book), but just to know how complex each one is or isn't.

(snip)

That is true, but as I said one can imagine it for standard cell. One might even be able to run the synthesis and P&R for a standard cell design to see how big or small things actually are.

(snip)

This is still very true for today's software. Maybe even more, as many of the old rules don't apply anymore. With overlapped execution it isn't easy to predict the timing for even simple software projects. (snip)

But the order of complexity really isn't the same. A four input exclusive or gate is much more complicated than a four input nand gate made out of transistors, but not made out of LUTs.

(snip)

One should pick the appropriate blocks, either as schematic capture or HDL. Most schematic capture systems include a library of logic blocks, probably similar to those available in HDL. Actually, more than the synthesis tools will generate directly!

-- glen

Downloaded Microsoft Virtual PC 2007 and installed it on a 3.4 GHz P4 with Windows XP. Workview runs on a DOS 6.22 installation on the virtual PC (the parallel port dongle works) but needs an extra mouse on the serial port (the Windows USB mouse is not recognized by Workview). But it's not usable because it is extremely slow (slower than on a 486), especially the mouse movements.

Does anybody know whether there is a company which sells Spartan3 chips (or any other FPGA type) already soldered to an adaptor board like:

Preferable with the GND an VCC pins already connected and capacitors on the adapter.

Hi Herbert, Apart from the ones John mentioned?

Also, this might help.

I wonder, given that you're in the computer science faculty, have you spoken to the guys in EE to ask for their help? Just a thought...

Good luck, Syms.

Yes I know, there are many development boards, but we don't want a board but the chip. As there is a big difference whether you make a design at gate level using a schematic entry or use high level VHDL code, there also is a big difference whether you buy a CPU and built a computer system or you buy a ready to use motherboard to built a computer system. The same is true for FPGA's and ready to use FPGA development boards. You have to go at least once to the low level to understand the problems, then you can do it at a higher level.

Yes, I can follow that, but then why not use a PLCC CPLD, for the hardware ? That is further to the low level, than a FPGA ?

-jg

You can use Xilinx Spartan chips such as XCS10-xPC84 (x is the speed grade). I don't remember how big the array goes in the PC84 package. With a little more soldering skill, there are flat pack Spartan chips, such as 144-pin.

You need to use Xilinx's ise 5.2 or earlier software to generate configs for these older chips. Despite Xilinx pulling all references to them off their web site, the 5 V Spartans are still available. They are a little harder to get in small quantity, but if you need 50 or something, it would be no problem.

Jon

This is a fantasy! You could probably design a 2-bit adder at the gate level in 10 hours, starting from not knowing the package. There is no way a student could design a CPU at the gate level, unless it was maybe a Turing machine (one-bit CPU), in 10 hours. Even if they were fluent in VHDL, every toolkit has its own dialect of what is accepted and what is not. Then, you have to learn the simulator, how to write test benches, debug the board, the FPGA soldering, testing the FPGA config ON the target board.....

I run Xilinx ise 5.1 and 5.2 on Windows 2000. I'm still working in the

5 V world for a little while longer.

Jon