FPGA with 5V and PLCC package

Herbert Kleebauer wrote:

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

OK, I understand why you want to keep as much 'visible' as possible.


> 
>>Isn't '5 years old', actually new on your time scales ?
>>Get the Atmel tools and try them
> 
> 
> 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.
> 
> 
>>>   - 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.

Yes, I can follow this SCH thrust, only to a point, so let's look more
closely :

In your Doc, there is a nice block diagram, on page 3.
That's what I used, [and I note it is not actually from Viewlogic]

So, you certainly keep that.

but if I drill down, to your ALU example, I can see 16 blocks, but
they are still macros, and I need to drill further to ADDNOR.

Now, ask the student : "Quick, how many macrocells will the ALU need
in device AAX ? "

Next, look at YGATE or YREG, and in both HDL, and SCH I'd call that
pretty much a tie.

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

should be clear to anyone, as a CE DFF ?

Next, look at the state engine - and this is where SCH fails badly.
I would not try and duplicate your design from the GATES on p10, but
I would either use the table you give on page 4, and probably paste that
into a CUPL table statement, or I'd use the Boolean equations you have
provided on page 4, and code using those, or I could use a Sequence
state construct.
With state engines, I prefer to make it readable.maintainable, and let 
the tools do the packing - they are tricky things, and clarity is
important.

Another advantage of HDL/Boolean eqn entry, is the student WILL have
to read the FIT reports, and the equations in those are ? - yes, boolean 
Eqns. So, it is faster/easier to jump between Source in editor, and 
report, in the same editor, than Source in SCH XYZ, and report in 
separate editor.

Source Code:

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

YGate = s6 & YReg
       # !s6 & 'h'0001;


FIT report

YReg0.C = CLK;
YReg0.CE = s2;
YReg0.D = Din0;

!YGate0 = (!YReg0.Q & s6); /* student exercise: what/why has the fitter 
done this ? */

I spend a significant portion of design time looking at the FIT reports, 
and I also frequently use multiple constructs, and pick the best one.

$IFDEF  VesionCom
Code = here # there;
$ELSE
Code.d = here # there;
$ENDIF

Try that in Viewlogic ? :)

Then we come to tool control: I can feed commands to the fitter, from 
CUPL source, - how do you do that from Viewlogic ?

Simulation ?: Also in the same editor. How do you enter/view simulation
data, with Viewlogic ?



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

I thought it almost was, in this type of case, in the EU ?

-jg

Jim Granville wrote:
> and I also frequently use multiple constructs, and pick the best one.
> 
> $IFDEF  VesionCom
> Code = here # there;
> $ELSE
> Code.d = here # there;
> $ENDIF
> 
> Try that in Viewlogic ? :)
> 
> Then we come to tool control: I can feed commands to the fitter, from 
> CUPL source, - how do you do that from Viewlogic ?
> 
> Simulation ?: Also in the same editor. How do you enter/view simulation
> data, with Viewlogic ?

- 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

On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote:

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

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.

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

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?

Herbert Kleebauer wrote:
(snip)

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

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

Herbert Kleebauer wrote:
> 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.

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)

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

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

cs_posting@hotmail.com wrote:
> On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote:


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


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

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.

Nothing much in formal words yet other than a brief description here
of Craignell http://www.enterpoint.co.uk/component_replacements/craignell.h=
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.


On 21 Mar, 10:24, Herbert Kleebauer <k...@unibwm.de> wrote:
> 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?- Hide quoted tex=
t -
>
> - Show quoted text -

On Mar 22, 5:34 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> cs_post...@hotmail.com wrote:
> > On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > 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.

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.

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

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.

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

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.

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

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".

> 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 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_.

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

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!

Herbert Kleebauer wrote:

> cs_posting@hotmail.com wrote:
> 
>>On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> 
> 
> 
>>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.

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
http://www2.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/USBToolStick.htm


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

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.


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


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.

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

[*] 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
http://www.diodes.com/anachip/winplace/index.php

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

Herbert Kleebauer 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.

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