Jim Granville wrote:> What are the prime teaching targets: learning FPGA flows, or > learning shematic entry ?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.> Isn't '5 years old', actually new on your time scales ? > Get the Atmel tools and try themAtmel 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.> > - has anybody experience with ATMEL's AT40K20 and can suggest > > development software (it must be a schematic entry, no VHDL > > because the students have to "see" the processor at gate level. > > 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 ?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.> > 2. Was somebody able to run Viewlogic (DOS version) in a virtual > > PC emulation. The problem is, the virtual PC must provide > > the proper graphics mode, mouse type and support a physical > > dongle on the virtual parallel port. > > Keys on virtual parallel ports ?! Nope...Then it should be legal to remove the copy protection from the software.
FPGA with 5V and PLCC package
Started by ●March 20, 2007
Reply by ●March 21, 20072007-03-21
Reply by ●March 21, 20072007-03-21
John Adair wrote:> > 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 > http://www.enterpoint.co.uk/component_replacements/craignell.html > 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.Sounds interesting. Are there any data sheets available?
Reply by ●March 21, 20072007-03-21
Jim Granville wrote:> Herbert Kleebauer wrote:> > Here a description of the students 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.Thanks for the mail. But this example clearly shows the difference between a textual and a graphical representation of circuit.> > /* ~~~~~~~~~~~~~~~ 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 */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.
Reply by ●March 21, 20072007-03-21
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 "Herbert Kleebauer" <klee@unibwm.de> wrote in message news:46010821.9FBCAAF6@unibwm.de...> Jim Granville wrote: >> Herbert Kleebauer wrote: > >> > Here a description of the students 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. > > Thanks for the mail. But this example clearly shows the difference > between a textual and a graphical representation of circuit. > > >> >> /* ~~~~~~~~~~~~~~~ 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 */ > > 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.
Reply by ●March 21, 20072007-03-21
On Mar 21, 5:25 am, Herbert Kleebauer <k...@unibwm.de> wrote:> Thanks for the mail. But this example clearly shows the difference > between a textual and a graphical representation of circuit. > > > /* ~~~~~~~~~~~~~~~ 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 */ > > 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.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.
Reply by ●March 21, 20072007-03-21
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> wrote in message news:etrgnt$gov$1@cernne03.cern.ch...> > 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) >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.
Reply by ●March 21, 20072007-03-21
On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote:> cs_post...@hotmail.com wrote: > > On Mar 20, 11:23 am, Herbert Kleebauer <k...@unibwm.de> wrote: > > > The last > > > version of XILINX ISE software which supports XC3000 FPGA's > > > isn't an alternative (and I'm not sure whether it will > > > run on W2k/XP) because the system must be extremely easy to > > > use so the students are able to design and implement a simple > > > CPU in about 10 hours (including the time to learn how to use > > > the schematic entry and simulation tool). > > > 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. > > As I explained in the other reply, that isn't an alternative.As I explained in the other reply... yes in fact it is an alternative.
Reply by ●March 21, 20072007-03-21
On Mar 21, 5:24 am, Herbert Kleebauer <k...@unibwm.de> wrote:> 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.Use your own front end outputting low-level HDL to the atmel or any other implementation-specific tool> 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.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.
Reply by ●March 21, 20072007-03-21
"Symon" <symon_brewer@hotmail.com> wrote in message news:4601501d_1@x-privat.org...> "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> > wrote in message news:etrgnt$gov$1@cernne03.cern.ch... >> >> 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) >> > 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. >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
Reply by ●March 21, 20072007-03-21
Herbert Kleebauer wrote:> Jim Granville wrote: > >>Herbert Kleebauer wrote: > > >>>Here a description of the students 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. > > > Thanks for the mail. But this example clearly shows the difference > between a textual and a graphical representation of circuit. > > > >>/* ~~~~~~~~~~~~~~~ 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 */ > > > How should the student get a feeling how many gates are necessary > to implement this two lines?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.> 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.-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
