FPGA with 5V and PLCC package

Do you have electronics recycling centers in your region? In the U.S., these places accumulate vast quantities of serviceable (usable) laptops which would be ideal platforms for the ongoing hosting of the DOS software, and one can obtain quantities of the machines for next to nothing.

Also, it would be an interesting experiment to try running the software on a VMWare MSDOS VM (a no-cost experiment); please report the results!

Regards,

Michael

Hi Herbert,

If it's OK, I have an observation. I wonder why these students are being taught design methods on design tools and FPGA parts that most folks on this newsgroup haven't used for a long time. The schematic vs. HDL wars have long since died down because modern FPGA designs are generally 'better' implemented using HDLs.

Anyway, I'm sure you have a good reason for the approach you outline; I'm interested as to what this is. If you can post your goals, maybe the group could suggest some up-to-date alternatives?

Best regards, Syms.

p.s. I HATE Viewlogic. I wasted a day on a legacy design a while back because a wire had the wrong shaped dot on it. The worst part was the bloody software guy spotted the mistake!

As a suggestion, drop the schematic entry approach and introduce a hardware design language such as Verilog, or VHDL, or some academic invention that can be translated - these are much more powerful and extensible to real world applications. They are also much more portable.

Seperate the simulation solution from the hardware implementation. That should give you many choices, both commerical and free/open source, on many platforms - with no lock-in to the FPGA hardware vendor.

Finally, for the actual implementation in an FPGA, try to give them an already canned project file to which they simply add their HDL source code. Ideally their HDL has already been vetted by the simulator and shouldn't have errors, but learning how to click on an error in the window to be taken to the offending line should not be complicate - much simpler than learning about any schematic entry tool.

Alternatively, set it up with command line tools and a makefile type environment.

You should be able to fit a project of this scope into the free- license versions of tools, so even if you do end up having to use an emulated environment to run old software, dongles at least wouldn't be an issue.

What are the prime teaching targets: learning FPGA flows, or learning shematic entry ?

Isn't '5 years old', actually new on your time scales ? Get the Atmel tools and try them

What about simpler HDLs, like CUPL or ABEL ? With those, you can 'see' the AND and OR terms ? What about 'seeing' the result in the report files - is that gate-level enough ?

Your best pathway into new devices, is a daughter card approach. Put the 'CPU'/REG/CAPS on a tiny PCB, with pin headers.

Keys on virtual parallel ports ?! Nope...

Interesting, a 3 opcode CPU.

I'd look at the CPLDs, and which devices support simpler HDLs CUPL/ABEL, or even Altera's AHDL - the biggest FPGAs are all Verilog/VHDL flows, but you are looking at the simpler end of the scale, so a simpler HDL might fit the teaching targets better.

Atmel have up to ATF1508, which could do a 3 opcode CPU, but maybe not this one, if you want to clone the SCHs precisely, as there seems to be many layers of logic.

Xilinx have XC95xx and Coolrunner II, I think with ABEL flows on all CPLDs,

Lattice have IspMACH4000 family, and Abel in their CPLD flows.

-jg

Herbert

Going sideways on what you are looking for it is worth looking at a couple of ideas from our product line to allow the easy use of modern FPGAs. The first is our Craignell family

which operate from 5V, in a DIL format, and are fully 5V tolerant. At the moment we do 32,36,40 pin versions but I expect to have 28 and 48 pin versions added to the range. Maybe a few others if someone gives us a good reason.

Almost a bigger brother our product Darnaw1 is waiting in our lab for a couple of days test before it goes into mass manufacture. This is a

2.54mm pitch PGA style module that lets you use a XC3S1200E/1600E Spartan. This module is 3.3V tolerant and operates from a single 3.3V input. The module also has spi flash and sdram to allow the implementation of fairly powerful processor applications.

If you like the concepts of these modules have a look at our university program (UAP). It offers discount and various other academic support things. Details here

John Adair Enterpoint Ltd.

project:ftp://137.193.64.130/pub/mproz/mproz_e.pdf

This is such a simple CPU, that I quickly tried it targeting the ATF1508 - which _is_ 5V and _is_ PLCC84, so you can keep all your design notes, and just re-map the pins on the PCB layout you have.

Below is the CUPL code (minus STEU and full adder), which is close enough to registers that the students should be able to "see" the processor at gate level. This FITs with 46 spare macrocells in an ATF1508, which should be plenty to complete the adder, and STEU state engine. As you can see, this is probably easier to read than the SCHs,

8 blocks in the main diagram become 8 (very simple) equation sets.

FIELD Sta = [Sta2..Sta0]; FIELD Din = [Din15..Din0]; FIELD Adr = [Adr15..Adr0]; FIELD PC = [PC15..PC0]; FIELD XReg = [XReg15..XReg0]; FIELD YReg = [YReg15..YReg0]; FIELD XGate = [XGate15..XGate0]; FIELD YGate = [YGate15..YGate0]; FIELD ALU = [ALU15..ALU0];

/* ~~~~~~~~~ XReg, YReg, PC Simple Registers ~~~~~~~~~~~~ */ XReg.d = Din; XReg.ck = CLK; XReg.ce = s1;

YReg.d = Din; YReg.ck = CLK; YReg.ce = s2;

PC.d = ALU; PC.ck = CLK; PC.ce = s3;

/* ~~~~~~~~~~~~~~~~ Adr is AMUX out ~~~~~~~~~~~~~~ */ /* AMUX: IF (s4=0) THEN out=in1 ELSE out=in2 */ Adr = s4 & YReg # !s4 & PC;

/* ~~~~~~~~~~~~~~~~ XGate, YGate ~~~~~~~~~~~~~~~~~ */ /* XGATE: IF (s5=0) THEN out=$0000 ELSE out=in */ XGate = s5 & XReg # !s5 & 'h'0000;

/* YGATE: IF (s6=0) THEN out=$0001 ELSE out=in */ YGate = s6 & YReg # !s6 & 'h'0001; /* ~~~~~~~~~~~~~~~ ALU, pre-adder ~~~~~~~~~~~~~~~~~ */ /* ALU: IF (s7=0) THEN out=in1 ADD in2 , F=carry ELSE out=in1 NOR in2 , F=zero

*/ ALU = s7 & !(XGate # YGate) # !s7 & (XGate $ YGate); /* Dummy, until adder done */

F.d = s7 & 'b'0 # !s7 & (XGate0 $ YGate0); /* Dummy, until adder-CY done */ F.ck = CLK; F.ce = s8;

The problem is not the money, but the time of the students. The system must be very easy to use so the students can built the simple CPU at gate level in 10 hours including the time to learn the tools. And we don't want to use old hardware (we want to replace our old PC's). It would be ideal if the software would run on an actual OS (XP or maybe VISTA) so we wouldn't need any own hardware at all and could use the already existing computers in an electronic classroom (which also isn't in the first place a question of money but of available free rooms).

I hoped somebody already has done this and I could get some information.

This is an exercise to a lecture about computer organization. The student have just learned how to make a truth table, minimize logic functions and design simple state machines. In this exercise they should use this knowledge to implement a little bit more complex design. And what can be more interesting than designing your own CPU. Therefore VHDL isn't any alternative, they are only allowed to use D-FF's and simple gates like AND,OR,NAND,NOR. We could stop the course after simulating the design, but it is much more motivating when at the end your CPU is running in hardware. But this hardware has to be a simple hardware (not one of this complex multilayer FPGA prototyping boards) so they see that there is no hidden technology and they even could make the same board at home with an cheap soldering iron.

Maybe you didn't use the DOS version. I suppose this software was made by hardware engineers to support there work. An it was so good that other people also wanted it. But with the success of the tool the company hired software engineers and these people can destroy any perfect usable SW in nearly no time. I installed the Windows version of WorkView when it was available, but after testing immediately deleted it. The same happened a few years before with the Daisy CAD system.

As I explained in the other reply, that isn't an alternative.

Nothing of both. The goal is, to use a handful of FlipFlops and gates to implement a design for which you only get the specification. It's just a replacement for a prototyping board with many TTL gates.

Atmel only offers a place and route tool. Therefore I asked if somebody can suggest a simple to use design software (with a schematic entry) for the Atmel FPGA's.

That's like a city map which doesn't use graphics but only textual description of the street position and connections. You will never get a feeling for the layout of the city whereas a fast glance on the graphical city map shows you all. Sure, if you use one of the modern navigation systems you don't need any overview of the city, you are told when to turn left or right. This may be is the best way if you only want to go from position A to position B, but if have to understand how the city is organized, then this is completely inappropriate.

Then it should be legal to remove the copy protection from the software.

Sounds interesting. Are there any data sheets available?

Thanks for the mail. But this example clearly shows the difference between a textual and a graphical representation of circuit.

How should the student get a feeling how many gates are necessary to implement this two lines? It's the same as programming in a HLL. No question, it is much more effective to us a HLL than using an assembler. But any HLL programmer should have done assembly programming so he has a feeling what a HLL code snippet has for consequences for the CPU and so he not always selects the code which is most easily written but the code which most easily can be calculated by the CPU.

How's about getting some XC95108 in PLCC-84? Use Webpack/ISE for schematic entry..

You have the perfect opportunity to build on this to introduce an HDL afterwards...

Only thing might be cost and availability of devices and proto-boards for them, and the efficiency of only 108 macrocells in creating a useable microcontroller.

Just an idea. but...

I _wish_ i'd been introduced to VHDL in level one at university. All digital logic design ties together, and in my opinion all the different aspects can and should be taught as interrelated topics. (contrary to some practices)

Have you asked your students if they're interested in messing around with Viewlogic and associated parts versus getting their feet wet with FPGA/CPLD/VHDL/Xilinx?

just my 2p. Ben

By making them implement select pieces of the design in gates - on paper, in a graphical simulator (various java thingies are popular in course work for that purpose), on a piece of graph paper representing the configuration of a classic sum-of-products PLD, or even in 74xx ttl.

A major point of engineering education (both academic and on-the-job) is learning to manage abstraction and scope. Learning to look at some pieces in ultimate detail where that is important, but learning to look at others in their abstract or high-level representation, so that you can get actual work done and build interesting things in finite amounts of time.

As a working engineer, probably my most valuable skill is having the "knack" for rapidly finding the specific part of the system where I need to drill down to the basic level to fix a fundamental problem - vs. the many parts where the high level abstraction is valid.

If you really want to stick to date level design, another thing you could do is write or adapt your own gate level graphical design too that outputs simplistic HDL. Then you have a tool that you can port - both across computing platforms and across target hardware devices.

Hi Benjamin, OTOH, I'm glad that I know what the VHDL is compiled into. I think Herbert's intention in this class is to show his students what the logic is made up from, and schematics of gates and FFs do achieve this. As you say, I'd expect the course to then go on to show how the same thing can be implemented in 5 minutes with 10 lines of Verilog (or 50 lines of VHDL! :-)) but I do see where he's coming from. Cheers, Syms.

As I explained in the other reply... yes in fact it is an alternative.

Use your own front end outputting low-level HDL to the atmel or any other implementation-specific tool

Two words: block diagram

Don't make them build a city brick by brick. Building a piece of a wall in the lab out of bricks is a great idea - but if you want to talk about cities, you then zoom out to a larger unit size.

Hey Syms,

I agree with what you say... In some cases these subjects are so closely linked that I begin to question why they should be separate at all.

Especially CPLD design. I always suggest designing the circuit mentally (i.e. Get the designer to question how the circuit could be made if all he/she had was a pile of 74LSxxx) and writing the VHDL to match, and I refer an awful lot to Burn Rate - 7400 series understanding is fundemental to 9500 series design!

Ben

Herbert Kleebauer wrote:

By reading the Fitter report, pasted below. Each node eqn is there, and there is also a summary. These reports are a vital part of the design understanding.

As an exercise, I'd ask the student to write something more than one way, and to sumbit the FIT report file portions, that show the trade offs of either way.

Just like I'd expect a Microcontroller student to be able to inspect the MAP file from an linker, to tell me the exact size of any function, be it assembler, C, library or whatever.

A student should also be aware that there is not a 1:1 correlation between gates and Schematic - the tools WILL shuffle things about (sometimes quite a lot), as they pack it into the silicon.

-jg

[This will wrap in the news system]

MCell Pin# Oe PinDrive DCERP FBDrive DCERP Foldback CascadeOut TotPT SO MC1 0 -- PC14 Dge-- -- -- 2 f- MC2 0 -- PC13 Dge-- -- -- 2 f- MC3 12 on ALU0 C---- PC7 Dge-- NA -- 5 f- MC4 0 -- PC12 Dge-- -- -- 2 f- MC5 11 on ALU1 C---- PC5 Dge-- NA -- 5 f- MC6 10 -- Din1 INPUT PC3 Dge-- -- -- 2 f- MC7 0 -- PC11 Dge-- -- -- 2 f- MC8 9 -- Din3 INPUT PC4 Dge-- -- -- 2 f- MC9 0 -- PC9 Dge-- -- -- 2 f- MC10 0 -- PC10 Dge-- -- -- 2 f- MC11 8 -- Din2 INPUT PC2 Dge-- -- -- 2 f- MC12 0 -- PC8 Dge-- -- -- 2 f- MC13 6 -- Din4 INPUT PC1 Dge-- YGate1 -- 3 f- MC14 5 -- Din6 INPUT PC0 Dge-- YGate0 -- 3 f- MC15 0 -- PC6 Dge-- XGate1 -- 3 f- MC16 4 on F Dge-- -- XGate0 -- 4 f- MC17 22 -- Din5 INPUT XReg5 Dge-- -- -- 2 f- MC18 0 -- XReg15 Dge-- -- -- 2 f- MC19 21 -- Din7 INPUT XReg6 Dge-- -- -- 2 f- MC20 0 -- XReg13 Dge-- -- -- 2 f- MC21 20 -- Din9 INPUT XReg4 Dge-- -- -- 2 f- MC22 0 -- XReg11 Dge-- -- -- 2 f- MC23 0 -- XReg12 Dge-- -- -- 2 f- MC24 18 -- Din8 INPUT XReg2 Dge-- -- -- 2 f- MC25 17 -- Din10 INPUT XReg3 Dge-- -- -- 2 f- MC26 0 -- XReg10 Dge-- -- -- 2 f- MC27 16 -- Din12 INPUT XReg1 Dge-- -- -- 2 f- MC28 0 -- XReg8 Dge-- -- -- 2 f- MC29 15 -- Din11 INPUT PC15 Dge-- -- -- 2 f- MC30 0 -- XReg9 Dge-- -- -- 2 f- MC31 0 -- XReg7 Dge-- -- -- 2 f- MC32 14 -- TDI INPUT XReg0 Dge-- -- -- 2 f- MC33 0 -- YReg13 Dge-- -- -- 2 f- MC34 0 -- YReg14 Dge-- -- -- 2 f- MC35 31 -- Din13 INPUT YReg6 Dge-- -- -- 2 f- MC36 0 -- YReg12 Dge-- -- -- 2 f- MC37 30 -- Din15 INPUT YReg4 Dge-- -- -- 2 f- MC38 29 -- s2 INPUT YReg5 Dge-- -- -- 2 f- MC39 0 -- YReg10 Dge-- -- -- 2 f- MC40 28 -- s8 INPUT YReg3 Dge-- -- -- 2 f- MC41 0 -- YReg11 Dge-- -- -- 2 f- MC42 0 -- YReg9 Dge-- -- -- 2 f- MC43 27 -- Din14 INPUT YReg1 Dge-- -- -- 2 f- MC44 0 -- YReg7 Dge-- -- -- 2 f- MC45 25 -- YReg2 Dge-- -- -- 2 f- MC46 24 -- YReg0 Dge-- -- -- 2 f- MC47 0 -- YReg8 Dge-- -- -- 2 f- MC48 23 -- TMS INPUT XReg14 Dge-- -- -- 2 f- MC49 41 on ALU8 C---- -- -- -- 3 f- MC50 0 -- -- -- -- 0 f- MC51 40 on ALU7 C---- -- YGate8 -- 4 f- MC52 0 -- -- YGate7 -- 1 f- MC53 39 on ALU6 C---- -- YGate6 -- 4 f- MC54 0 -- -- YGate4 -- 1 f- MC55 0 -- -- YGate3 -- 1 f- MC56 37 on ALU5 C---- -- YGate5 -- 4 f- MC57 36 on ALU4 C---- -- YGate2 -- 4 f- MC58 0 -- -- XGate8 -- 1 f- MC59 35 on ALU3 C---- -- XGate7 -- 4 f- MC60 0 -- -- XGate6 -- 1 f- MC61 34 on ALU2 C---- -- XGate5 -- 4 f- MC62 0 -- -- XGate4 -- 1 f- MC63 0 -- -- XGate3 -- 1 f- MC64 33 -- YReg15 Dge-- XGate2 -- 3 f- MC65 44 on Adr0 C---- -- -- -- 2 f- MC66 0 -- -- -- -- 0 f- MC67 45 on ALU15 C---- -- YGate14 -- 4 f- MC68 0 -- -- YGate13 -- 1 f- MC69 46 on ALU14 C---- -- YGate15 -- 4 f- MC70 0 -- -- YGate11 -- 1 f- MC71 0 -- -- YGate10 -- 1 f- MC72 48 on ALU13 C---- -- YGate12 -- 4 f- MC73 49 on ALU12 C---- -- YGate9 -- 4 f- MC74 0 -- -- XGate15 -- 1 f- MC75 50 on ALU11 C---- -- XGate14 -- 4 f- MC76 0 -- -- XGate13 -- 1 f- MC77 51 on ALU10 C---- -- XGate12 -- 4 f- MC78 0 -- -- XGate11 -- 1 f- MC79 0 -- -- XGate10 -- 1 f- MC80 52 on ALU9 C---- -- XGate9 -- 4 f- MC81 0 -- -- -- -- 0 f- MC82 0 -- -- -- -- 0 f- MC83 54 on Adr7 C---- -- -- -- 2 f- MC84 0 -- -- -- -- 0 f- MC85 55 on Adr6 C---- -- -- -- 2 f- MC86 56 on Adr5 C---- -- -- -- 2 f- MC87 0 -- -- -- -- 0 f- MC88 57 on Adr4 C---- -- -- -- 2 f- MC89 0 -- -- -- -- 0 f- MC90 0 -- -- -- -- 0 f- MC91 58 on Adr3 C---- -- -- -- 2 f- MC92 0 -- -- -- -- 0 f- MC93 60 on Adr2 C---- -- -- -- 2 f- MC94 61 on Adr1 C---- -- -- -- 2 f- MC95 0 -- -- -- -- 0 f- MC96 62 -- TCK INPUT -- -- -- 0 f- MC97 63 on Adr14 C---- -- -- -- 2 f- MC98 0 -- -- -- -- 0 f- MC99 64 on Adr13 C---- -- -- -- 2 f- MC100 0 -- -- -- -- 0 f- MC101 65 on Adr12 C---- -- -- -- 2 f- MC102 0 -- -- -- -- 0 f- MC103 0 -- -- -- -- 0 f- MC104 67 on Adr11 C---- -- -- -- 2 f- MC105 68 on Adr10 C---- -- -- -- 2 f- MC106 0 -- -- -- -- 0 f- MC107 69 on Adr9 C---- -- -- -- 2 f- MC108 0 -- -- -- -- 0 f- MC109 70 on Adr8 C---- -- -- -- 2 f- MC110 0 -- -- -- -- 0 f- MC111 0 -- -- -- -- 0 f- MC112 71 -- TDO C---- -- -- -- 0 f- MC113 0 -- -- -- -- 0 f- MC114 0 -- -- -- -- 0 f- MC115 73 -- s4 INPUT -- -- -- 0 f- MC116 0 -- -- -- -- 0 f- MC117 74 -- s7 INPUT -- -- -- 0 f- MC118 75 -- s5 INPUT -- -- -- 0 f- MC119 0 -- -- -- -- 0 f- MC120 76 -- s6 INPUT -- -- -- 0 f- MC121 0 -- -- -- -- 0 f- MC122 0 -- -- -- -- 0 f- MC123 77 -- s3 INPUT -- -- -- 0 f- MC124 0 -- -- -- -- 0 f- MC125 79 -- Din0 INPUT -- -- -- 0 f- MC126 80 -- s1 INPUT -- -- -- 0 f- MC127 0 -- -- -- -- 0 f- MC128 81 on Adr15 C---- -- -- -- 2 f- MC0 2 -- -- -- -- 0 f- MC0 1 -- -- -- -- 0 f- MC0 84 -- -- -- -- 0 f- MC0 83 CLK INPUT -- -- -- 0 f-

Logic Array Block Macro Cells I/O Pins Foldbacks TotalPT FanIN Cascades A: MC1 - MC16 18/16(112%) 8/16(50%) 4/16(25%) 43/80(53%) 24/40(60%) 0 B: MC17 - MC32 16/16(100%) 8/16(50%) 0/16(0%) 32/80(40%) 18/40(45%) 0 C: MC33 - MC48 16/16(100%) 6/16(37%) 0/16(0%) 32/80(40%) 17/40(42%) 0 D: MC49 - MC64 8/16(50%) 7/16(43%) 14/16(87%) 37/80(46%) 19/40(47%) 0 E: MC65 - MC80 8/16(50%) 8/16(50%) 14/16(87%) 37/80(46%) 20/40(50%) 0 F: MC81 - MC96 7/16(43%) 8/16(50%) 0/16(0%) 14/80(17%) 15/40(37%) 0 G: MC97 - MC112 8/16(50%) 8/16(50%) 0/16(0%) 14/80(17%) 15/40(37%) 0 H: MC113- MC128 1/16(6%) 8/16(50%) 0/16(0%) 2/80(2%) 3/40(7%) 0

Total dedicated input used: 1/4 (25%) Total I/O pins used 61/64 (95%) Total Macro cells used 82/128 (64%) Total Flip-Flop used 49/128 (38%) Total Foldback logic used 32/128 (25%) Total Nodes+FB/MCells 114/128 (89%) Total cascade used 0 Total input pins 28 Total output pins 34 Total Pts 211