Synthesis for 22v10

[a]

Howdy all -

I'm an ECE grad student and I'd like to come up to speed on
VHDL/Verilog. There are classes on this (and I'll be
taking some) but apparently the emphasis is solely on simulation.
I've asked profs about synthesis and generating JEDEC files
and got some rather vague suggestions about downloading from
Altera or Xilinx.

At any rate, I have a programmer that can do smaller DIP parts and
picked up some 22CV10 PEEL devices and would like to generate a
JEDEC fuse file for them. Sure, they're small parts and all, and
VHDL/Verilog is overkill for them, but I'm learning and why not?
I see no reason not to use an HDL for decoders and so forth.

So I did download Quartus II from Altera and fussed with the licensing,
etc., but it doesn't seem to support older devices. I couldn't get
the Xilinx stuff to run.

So, should I download the legacy product? Can anybody tell me if
MAX+PLUS II (interesting name, is it "max plus plus"? or maybe
"max and plus"?) supports smaller devices?

Any other options? I did a search of Google groups but didn't turn
up anything. I've also tried gEDA on Linux but neither of the last two
releases would even install on a RH9 platform.

Thanks,

Rick

rc |a| ece.pdx.edu

 

[Mike Treseler]

a wrote:

I'm an ECE grad student and I'd like to come up to speed on
VHDL/Verilog. There are classes on this (and I'll be
taking some) but apparently the emphasis is solely on simulation.
I've asked profs about synthesis and generating JEDEC files
and got some rather vague suggestions about downloading from
Altera or Xilinx.

Until you know how to write hdl code for synthesis
*and* verify it with simulation, device selection
is premature.

-- Mike Treseler

 

[David Ashley]

a wrote:

Howdy all -

I'm an ECE grad student and I'd like to come up to speed on
VHDL/Verilog. There are classes on this (and I'll be
taking some) but apparently the emphasis is solely on simulation.
I've asked profs about synthesis and generating JEDEC files
and got some rather vague suggestions about downloading from
Altera or Xilinx.

At any rate, I have a programmer that can do smaller DIP parts and
picked up some 22CV10 PEEL devices and would like to generate a
JEDEC fuse file for them. Sure, they're small parts and all, and
VHDL/Verilog is overkill for them, but I'm learning and why not?
I see no reason not to use an HDL for decoders and so forth.

So I did download Quartus II from Altera and fussed with the licensing,
etc., but it doesn't seem to support older devices. I couldn't get
the Xilinx stuff to run.

So, should I download the legacy product? Can anybody tell me if
MAX+PLUS II (interesting name, is it "max plus plus"? or maybe
"max and plus"?) supports smaller devices?

Any other options? I did a search of Google groups but didn't turn
up anything. I've also tried gEDA on Linux but neither of the last two
releases would even install on a RH9 platform.

Thanks,

Rick

rc |a| ece.pdx.edu

a,

I don't know what the 22CV10 is. The numbers reminded me of the GAL22V10,
is it a GAL? I spent a few minutes searching but just found pay for access
datasheets, and gave up.

At any rate I'm in a similiar situation. I'm trying to gain some familiarity
with VHDL and FPGA's. I happened upon GHDL, and it has been useful
somewhat. The combination of GHDL to simulate VHDL and GTKWave to
view the results has been ok so far, and it seems to be fast enough.

I purchased from Xilinx a Spartan-3E starter kit, it has lots of interesting
parts on it. I wrote VHDL code and used the Xilinx tools (ISE, 8.1i) to
synthesize bit files for the Spartan XC3S500E on the board. I got stable
SVGA video out of the connector, with a pattern of random colors on
the background, and as an exercise a black square bouncing around the
display.

Each iteration of change source -> build bitfile -> try it out on actual
hardware was getting longer and longer as the design was getting more
complicated. It was a single VHDL file about 100 lines or so. And it
was taking a few minutes to build within the Xilinx tools.

I had no debugging capability at all -- can't see what signals are doing.
Not the best way to debug.

So I moved to GHDL + GTKWave.

I want to develop under linux. I find I could get the ISE + Xilinx tools to
install under linux. The USB driver I couldn't get working 100% from
linux. It uses a mechanism where when the USB is first plugged into
the computer, the driver downloads new code to the USB device, and that
then does the required jtag interface + whatnot. This works from
windows 2000 + windows versions of xilinx tools, not from linux.

However if I first boot into windows, plug the USB cable in on the
spartan-3e starter board, then let it initialize, I can reboot into linux
and linux will be able to download over the jtag/usb from then on
until I power off the system, or possibly unplug the usb port.

Regarding simulation + that realm -- the whole point of my experimenting
with VHDL and I expect yours as well is to create code that will actually
get loaded onto actual hardware. Textbooks on VHDL seem often to
suffer from a horrible defect -- they imply VHDL is itself a programming
language someone would use for its own right. What a joke.

The only VHDL code I'll be creating is synthesizable code, I'd hope.
All this
X := '1' after 1ns;
Riiiiiight. Make it look pretty + realistic on a simulation. But that's
not synthesizable.

It'd be nice to just cut out all the textbooks say about non-synthesizable
VHDL and move that to an appendix or something. Cut through all the
crap that I'm not going to use anyway. Just give me the meat. I already
know how to program.

Whatever works for you, go with it. It's easy to give up with learning
VHDL. My own involvement goes in fits and starts. Very frustrating,
actually.

Good luck. I don't think I've helped much though.

-Dave

 

[KJ]

David Ashley wrote:

The only VHDL code I'll be creating is synthesizable code, I'd hope.
All this
X := '1' after 1ns;
Riiiiiight. Make it look pretty + realistic on a simulation. But that's
not synthesizable.

It'd be nice to just cut out all the textbooks say about non-synthesizable
VHDL and move that to an appendix or something. Cut through all the
crap that I'm not going to use anyway. Just give me the meat. I already
know how to program.

What is or isn't synthesizable though is to a large degree just a
function of the technology of the day that is used to implement the
code. Even X <= Y after 1ns is synthesizable. It's called a delay
line, they do exist just maybe not inside your garden variety CPLD or
FPGA but if given enough market demand they certainly will be all over
the place.

Now of course the ASIC folks can synthesize darn near anything and when
you think about it, anything that has been built has been synthesized
but you (me and most other people) when yacking about
'non-synthesizable' code now-a-days are usually referring to what can
be synthesized into an FPGA. Here is a short list off the top of my
head that couldn't be synthesized into early FPGA/CPLDs but 25 years
later can.

- Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
- Phase locked loops
- A/D Converters
- D/A Converters

Some other points are:
- The stuff you shove over into the appendix as being not synthesizable
will in many cases be synthesizable in a few years. Well, OK type
'real' and 'time' might be m-a-n-y years out.

- Assertion checking is never going to be synthesizable....but is dang
handy just about everywhere (inside your design code, outside in the
simulation model of the stuff surrounding the design you're testing).
While waveform viewing will probably always be useful for debug of a
known problem, assertion checking is replacing waveform viewing for
finding those problems in the first place. For many people, myself
included, would change "is replacing" to "has almost completely
replaced" in the previous sentence....depends on the designer.

- That non-synthesizable stuff comes in mighty handy when modelling
those other pesky parts that surround your FPGA/CPLD. If you're not
taking advantage of that modelling capability today and instead are
forcing/scripting I/O to the design that you're testing than you're
probably doing things the hard way.

Add some simulation models and assertion checking and use that
non-synthesizable stuff and you'll find you're flying higher than some
of the others.

KJ

 

[David Ashley]

KJ wrote:

...
- That non-synthesizable stuff comes in mighty handy when modelling
those other pesky parts that surround your FPGA/CPLD. If you're not
taking advantage of that modelling capability today and instead are
forcing/scripting I/O to the design that you're testing than you're
probably doing things the hard way.

Add some simulation models and assertion checking and use that
non-synthesizable stuff and you'll find you're flying higher than some
of the others.

KJ

KJ,

Lots of interesting points. I think the "assert" can certainly be useful
as you describe. One thing to note is that it would be very very much
easier to code expected behaviour in 'c' or 'c++' than in vhdl. If we're
talking about non-synthesizable code being used to verify the
synthesizable code, then VHDL wouldn't be my first choice. I think I
heard there is movement towards embedding 'c' code within VHDL or
some hybrid approach or something, just for this issue.

Another issue of simulation vs actual use -- I have in mind an application
for an FPGA where the FPGA is the main brain of a multimedia system,
including audio, video, networking, etc. The chips I want to use to
connect to the fpga are from various suppliers. How can I hope to
simulate this whole system? Some of the chips are made in Taiwan --
sketchy to no documentation and I'd be very surprised if they
provided any simulation models.

So the only way to debug this thing is through using actual hardware,
doing things in real time since it will require human interaction.

So I guess the dividing line isn't so much as what is synthesizable as
what am I actually going to be doing with VHDL instead of with a
more familiar (to me) language. All I want VHDL for is to help create
the bit file I'll be downloading into the FPGA to make the device do
what it needs to do...I'm not interested in the intellectual exercise of
implementing ELIZA in VHDL :^).

- Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
- Phase locked loops
- A/D Converters
- D/A Converters

Other stuff moved onto the fpga fabric -- embedded processors,
multipliers, MAC's perhaps. Special output buffers to handle DDR2
memory signals.

-Dave

 

[KJ]

"David Ashley" <dash@nowhere.net.dont.email.me> wrote in message
news:44e23aa3$1_2@x-privat.org...

KJ wrote:
...
- That non-synthesizable stuff comes in mighty handy when modelling
those other pesky parts that surround your FPGA/CPLD. If you're not
taking advantage of that modelling capability today and instead are
forcing/scripting I/O to the design that you're testing than you're
probably doing things the hard way.

Add some simulation models and assertion checking and use that
non-synthesizable stuff and you'll find you're flying higher than some
of the others.

KJ


KJ,

Lots of interesting points. I think the "assert" can certainly be useful
as you describe. One thing to note is that it would be very very much
easier to code expected behaviour in 'c' or 'c++' than in vhdl.

Not necessarily any easier in c/c++. Inside a non-synthesizable model
you're only interested in modelling the behaviour somewhat and in that
context you generally have the freedom to code everything in a single
process (or a handful at best) and make it look very 'c-like'. If you want
to code in c/c++ than probably you want SystemC and then of course a mixed
language simulation environment.

If we're
talking about non-synthesizable code being used to verify the
synthesizable code, then VHDL wouldn't be my first choice. I think I
heard there is movement towards embedding 'c' code within VHDL or
some hybrid approach or something, just for this issue.

I think you may be talking about mixing SystemC and VHDL or Verilog or

SystemVerilog. Every language has it's proponents, plusses and minuses and
such. I wouldn't call it a movement just that one needs to cope with
integrating code written in various languages. Since each language 'seems'
to all be evolving and have some users it suggests that each has a niche and
over time the ebb and flow of which language fits best under certain design
conditions will vary.

Another issue of simulation vs actual use -- I have in mind an application
for an FPGA where the FPGA is the main brain of a multimedia system,
including audio, video, networking, etc. The chips I want to use to
connect to the fpga are from various suppliers. How can I hope to
simulate this whole system? Some of the chips are made in Taiwan --
sketchy to no documentation and I'd be very surprised if they
provided any simulation models.

Ideally the supplier would supply a model, but if they don't you can do it
yourself. But you don't need to code up a model for general use by anyone,
just something good enough for your use. I'm in a similar situation in that
I use ASICs with no sim model from the vendor but I do know what the I/O
pins are supposed to be doing and can model some form of behaviour that
validates that information is properly flowing around the system. As an
example, one of the part I use is a Philips processor. I don't have a
'real' model for the processor and I don't run the 'real' code, instead what
my VHDL model does is emulate the two together. From the standpoint of an
external viewer of the signal pins (which is what your FPGA is) it doesn't
know or care how that model gets generated.

Having said that though, by modelling the part yourself, you're also putting
yourself in the situation of wanting to validate that the model is at least
accurate enough for your purposes. But I would argue that you are
implicitly doing this anyway with whatever form of stimulus/expected
response set that you come up with. By putting this explicitly in the form
of a simulation model you're just changing the form that you encode that
knowledge and if you try it out you may find that it's roughly the same
level of effort.

The other thing I do is use an accurate board model. Our CAD system, when
you save a schematic also writes out a VHDL model that can be used in
simulation as well. If you're new to trying to "model the entire system" I
wouldn't suggest starting at this point until you've gotten your feet wet by
writing your own VHDL that plops down part X, Y and Z and your FPGA and then
interconnecting them (and of course writing/scrounging sim models for X, Y
and Z). Using the CAD produced VHDL model is the most accurate but requires
the most models and you'll find yourself fighting seemingly 'stupid' things
like resistor models (like what is the logical value of a net with a
pullup/pulldown termination; or what about that resistor that connects two
ends of a differential pair).

The last thing I do is that the board typically is not the entire system
either. It connects to external devices....so I model them as well and
connect them to the CAD produced simulation model.

So the only way to debug this thing is through using actual hardware,
doing things in real time since it will require human interaction.

I agree to a point. But if you go into the debug phase with a solid feel

for what you believe parts X, Y and Z 'should' be doing based on your
simulation model and whatever knowledge of the part you have you can go
about the debug more quickly.

Eventually of course you run across the situation where the real parts are
not behaving as you thought they should and of course it is causing some
actual problem on the board that you have to fix. What this implies then is
that either the simulation model was not quite as complete as you need it to
be or that your testing didn't exercise things in the manner that the real
part does on your board. Sometimes the problem is a relatively simple one
where you can with confidence put in the FPGA design change and fix the
problem.

For the not so easy problems though you should 'fix' the simulation model by
adding the new behaviour that you're actually seeing and then you should
also be able to see the failure that you're seeing on the board (even more
ideally because you added an 'assert' to catch it) and debug in a simulation
environment from there. Simulation time is w--a--y longer than real time
but the simulation environment lets you probe down to every blasted signal
in your design to get at the root cause of a problem. Debug in hardware
either doesn't allow this luxury or when it does (i.e. bringing out internal
nodes to observable pins) is limited because you go through various
iterations bringing out more and more new and interesting signals whereas in
simulation you just drag the new signal over to the wave window and can
immediately see the entire history of that signal.

So I guess the dividing line isn't so much as what is synthesizable as
what am I actually going to be doing with VHDL instead of with a
more familiar (to me) language. All I want VHDL for is to help create
the bit file I'll be downloading into the FPGA to make the device do
what it needs to do...I'm not interested in the intellectual exercise of
implementing ELIZA in VHDL :^).

And if there is no need for design verification prior to build then you're
right you don't need any of this so you could've stopped reading this long
ago

- Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
- Phase locked loops
- A/D Converters
- D/A Converters

Other stuff moved onto the fpga fabric -- embedded processors,
multipliers, MAC's perhaps. Special output buffers to handle DDR2
memory signals.

Yep, the list goes on and on.

KJ

 

a wrote:

Howdy all -

At any rate, I have a programmer that can do smaller DIP parts and
picked up some 22CV10 PEEL devices and would like to generate a
JEDEC fuse file for them. Sure, they're small parts and all, and
VHDL/Verilog is overkill for them, but I'm learning and why not?
I see no reason not to use an HDL for decoders and so forth.

Thanks,

Rick

What you want is a package called "Cypress Warp".

With that package, you can generate JED files for PALs & GALs in VHDL
or Verilog. It even has a rudimentary simulator.

Good luck finding one, Cypress stopped selling it a while back.