Ralph Malph wrote:

> PLDs come in two flavors, simple and complex.  There *are* specs for the
> simple PLDs because they consist of only the AND fuse array (AFAIK). 
> All 16L8's use the same fuse map, for example.  

Aye.

> The complex CPLDs are all different.  But if you are smart enough to
> write your own routing software, you should be clever enough to reverse
> engineer the parts from various downloads.  This may be tedious, but it
> will work. 

You don't have to be very smart to write software to decide how to 
program a PLD unless you're doing what the development tools do and 
accepting arbitrary logic equations. Then you need to allocate logic to 
PALs (or across multiple PALs) within the device based on what 
macrocells need to be connected to what and the capacities of the PALs, 
but then in the PAL generation phase you may find enough common terms 
between equations in a given PAL that it has space left over so other 
bits of logic could be implemented there, saving interconnection matrix 
space... All textbook optimisation techniques, but tricky to develop due 
to a lot of details that need attention.

My application would more be to hand-produce a number of 'macrocell' 
designs, and then at run time decide which 'macrocell' to put into each 
of a number of 'slots', and how to wire them to each other. Which is 
relatively trivial - just compose the bit streams for each macrocell to 
create the fuse maps for the PAL blocks, then work out an interconnect 
fuse map to tie them together.

 > The structures in a CPLD are very regular so that you only
> need to figure out a part of the device and you then have a much larger
> hunk.  

The ones I have lying around consist of four PALs with special I/O 
macrocells (that can be a range of flip flops, mainly) connected with an 
interconnect matrix to each other and the outputs of the chip. I reckon 
the four PAL blocks should be relatively easy to find in the fusemaps, 
particularly since I could probably isolate them by compiling designs 
with varying options for the macrocells to see where the macrocells are 
defined... but it would be much nicer to just get the programming 
documentation for the part :-)

> FPGAs are a whole new level of complexity.  But again a lot of the
> device is very regular.  But there is a lot more to the irregular part.

Yes!

ABS

Alaric B Snell wrote:
> 
> Ralph Malph wrote:
> 
> >>So a dependency upon the Xilinx software :-( Which I bet they don't
> >>provide a version of that will run on a Z80 to dynamically reconfigure
> >>an IO glue FPGA, eh? :-)
> 
> > If you are talking about using different bit streams, then you don't
> > need anything special on the Z80 other than the code to bit bang the
> > configuration data into the part.  If you are talking about *changing*
> > the bit stream in the Z80, then you are working on a very long and
> > tedious project.
> 
> I'd like to be able to generate my own bit stream. I'm not worried about
> the requirements of compiling a logical specification to a description
> of how the PLD should wire itself up, based upon the documentation of
> the PLD's routing capabilities; I can do that, it's just that I can't
> find documentation for how to generate the actual bit stream that will
> make the PLD wire itself up as I wish.
> 
> I've experimented with compiling hardware descriptions for my own design
> of *simulated* PLD :-)

PLDs come in two flavors, simple and complex.  There *are* specs for the
simple PLDs because they consist of only the AND fuse array (AFAIK). 
All 16L8's use the same fuse map, for example.  

The complex CPLDs are all different.  But if you are smart enough to
write your own routing software, you should be clever enough to reverse
engineer the parts from various downloads.  This may be tedious, but it
will work.  The structures in a CPLD are very regular so that you only
need to figure out a part of the device and you then have a much larger
hunk.  

FPGAs are a whole new level of complexity.  But again a lot of the
device is very regular.  But there is a lot more to the irregular part.

Ralph Malph wrote:

>>So a dependency upon the Xilinx software :-( Which I bet they don't
>>provide a version of that will run on a Z80 to dynamically reconfigure
>>an IO glue FPGA, eh? :-)

> If you are talking about using different bit streams, then you don't
> need anything special on the Z80 other than the code to bit bang the
> configuration data into the part.  If you are talking about *changing*
> the bit stream in the Z80, then you are working on a very long and
> tedious project.

I'd like to be able to generate my own bit stream. I'm not worried about 
the requirements of compiling a logical specification to a description 
of how the PLD should wire itself up, based upon the documentation of 
the PLD's routing capabilities; I can do that, it's just that I can't 
find documentation for how to generate the actual bit stream that will 
make the PLD wire itself up as I wish.

I've experimented with compiling hardware descriptions for my own design 
of *simulated* PLD :-)

ABS

Alaric B Snell wrote:
> 
> db wrote:
> >>Ah, but how did you generate the SVF?
> >
> > Generating SVF is an option in the Xilinx Impact Utility. You can also
> > chain together multiple devices into one chain and generate a single
> > SVF to program them both.
> 
> So a dependency upon the Xilinx software :-( Which I bet they don't
> provide a version of that will run on a Z80 to dynamically reconfigure
> an IO glue FPGA, eh? :-)

If you are talking about using different bit streams, then you don't
need anything special on the Z80 other than the code to bit bang the
configuration data into the part.  If you are talking about *changing*
the bit stream in the Z80, then you are working on a very long and
tedious project.

db wrote:
>>Ah, but how did you generate the SVF?
> 
> Generating SVF is an option in the Xilinx Impact Utility. You can also
> chain together multiple devices into one chain and generate a single
> SVF to program them both.

So a dependency upon the Xilinx software :-( Which I bet they don't 
provide a version of that will run on a Z80 to dynamically reconfigure 
an IO glue FPGA, eh? :-)

> If you build your own boards, the 32 macrocell cplds are only a few
> dollars a piece from Nu-Horizons. Nice for when you are just getting
> started and do not want to risk a more expensive chip.

Mmmm - I have a Lattice Semi evaluation / programming board that does 
MACH devices. Very handy. Lots of I/O pins and space for some quite 
complex designs!

ABS

Alaric B Snell <alaric@alaric-snell.com> wrote in message news:<1007dsrq8sfoo7a@corp.supernews.com>...
> db wrote:
> > I just did a small test project with two Xilinx 32 macrocell cplds. In
> > my case I generated an SVF and played that through the jtag software
> > that came with my  board. You may be able to do something similar your
> > Mach CPLD.
> 
> Ah, but how did you generate the SVF?

Generating SVF is an option in the Xilinx Impact Utility. You can also
chain together multiple devices into one chain and generate a single
SVF to program them both.

If you build your own boards, the 32 macrocell cplds are only a few
dollars a piece from Nu-Horizons. Nice for when you are just getting
started and do not want to risk a more expensive chip.

db wrote:
> I just did a small test project with two Xilinx 32 macrocell cplds. In
> my case I generated an SVF and played that through the jtag software
> that came with my  board. You may be able to do something similar your
> Mach CPLD.

Ah, but how did you generate the SVF?

> For the flash in my project, I will use the jtag from the arm
> processor I am using to bit bang the flash. I do not consider that to
> be too major a project.

Clever! I like it :-)

ABS

I just did a small test project with two Xilinx 32 macrocell cplds. In
my case I generated an SVF and played that through the jtag software
that came with my  board. You may be able to do something similar your
Mach CPLD.

For the flash in my project, I will use the jtag from the arm
processor I am using to bit bang the flash. I do not consider that to
be too major a project.

The real trick is finding something open source that can talk jtag to
my processor(Sharp 79520), interface to gdb for register access, be
open source and work.

Alaric B Snell <alaric@alaric-snell.com> wrote in message news:<1005r7b63q8dp75@corp.supernews.com>...
> x wrote:
> 
> > If your are searching the lowest cost on the market, try the Chameleon 
> > POD ( by Amontec.com ). This is an JTAG emulator compatible with the 
> > Macraigor Raven. It can operate as a RAVEN at 8MHz TCK frequency.
> > Raven or Wiggler can works over GNU GDB or all other popular Debugger 
> > tools. A nice solution for ARM.
> 
> I've got a JTAG interface from my PC, and I even have documentation on 
> how it works. What I wish I had is information on how to actually use it 
> to program EPROMs and CPLDs and things. Is this kind of stuff generally 
> kept close to the manufacturer's chests, or can they be prompted to divulge?
> 
> I see there is some open source work afoot - 
> http://openwince.sourceforge.net/jtag/ - but they don't cover my Lattice 
> Semi MACH cPLDs!
> 
> What would be nice is a huge online repository containing the core JTAG 
> specs, programming examples for common JTAG adapters for PCs, and a load 
> of specifications for using them for things other than boundary scan 
> testing. Any volunteers? :-)
> 
> > 
> > Larry
> > 
> 
> ABS

I have seen the Chameleon, Raven and Wiggler. The problem with these
is that the binary software is freely available, but not the source.

I have a usb/fpga card from Mesa Electronics with some basic jtag
software included.
One requirement of my project is that all software be opensource. If
necessary I will write it.


x <x@x.com> wrote in message news:<4002B393.30803@x.com>...
> db wrote:
> > I am somewhat confused about debugging arm processors through the jtag
> > port using
> > gdb. There does not seem to be a complete GPL based option. I see alot
> > of commercial software for which I do not have the thousands to spend
> > on and I see bits and pieces of software that looks like it could be
> > integrated to provide jtag debug access, but nothing fully integrated.
> > 
> > I have experiemented with implementing the openrisc processor with
> > uclinux in a gate array. When I have worked with the openrisc emulator
> > I am used to doing something in gdb like jtag://localhost to do a
> > debugging session. Yet there does not quite seem to be something like
> > that with arm.
> > 
> > Am I missing something here?
> Hi,
> 
> If your are searching the lowest cost on the market, try the Chameleon 
> POD ( by Amontec.com ). This is an JTAG emulator compatible with the 
> Macraigor Raven. It can operate as a RAVEN at 8MHz TCK frequency.
> Raven or Wiggler can works over GNU GDB or all other popular Debugger 
> tools. A nice solution for ARM.
> 
> Larry

x wrote:

> If your are searching the lowest cost on the market, try the Chameleon 
> POD ( by Amontec.com ). This is an JTAG emulator compatible with the 
> Macraigor Raven. It can operate as a RAVEN at 8MHz TCK frequency.
> Raven or Wiggler can works over GNU GDB or all other popular Debugger 
> tools. A nice solution for ARM.

I've got a JTAG interface from my PC, and I even have documentation on 
how it works. What I wish I had is information on how to actually use it 
to program EPROMs and CPLDs and things. Is this kind of stuff generally 
kept close to the manufacturer's chests, or can they be prompted to divulge?

I see there is some open source work afoot - 
http://openwince.sourceforge.net/jtag/ - but they don't cover my Lattice 
Semi MACH cPLDs!

What would be nice is a huge online repository containing the core JTAG 
specs, programming examples for common JTAG adapters for PCs, and a load 
of specifications for using them for things other than boundary scan 
testing. Any volunteers? :-)

> 
> Larry
> 

ABS