Re: gEDA: Re: "FREE" CPLD fitter tools

[graham-at-NOSPAMbelegost_dot_mit_dot_edu]

> 
> Specifically, I doubt the need for a fuse_array_t. 
I agree. Your fuse access is far simpler than mine. The only justification
for the extra complication in mine was for speed in dealing with
very large fuse arrays (cplds), where I could pull out/insert 32
fuses at a time rather than 1. I have no practical idea  how much
difference this will make in any case. If ok with you, I will
dump my fuse handling and replace with something modelled on yours.


> I also doubt the
> need to associate the architecture data type with a jedec file. The
> JEDEC data is just an unstructured list of fuses. 
The justification for this was in formatting Jedec output. Especially
when trying to compare output from a guessed model of a cpld with real
Jedec files for that cpld, it will be visually helpful to have the fuses 
printed by physical row or group of macrocells. This is also in line with
common practice. But only a small subset of the structural
information is needed for this.

> For example, I'm going
> to want to get the architecture of a 22v10, but I shouldn't need to
> read a jedec file to get it.
Yes. I'm reorganizing so that the API looks like:
pal_t pal_new(const char * arch_description_file)
pal_assemble(pal_t pal, const char *boolean_expression_file)
pal_read_jedec(pal_t pal, const char *jedec_file)
pal_write_jedec(pal_t pal)
pal_read_fuse(pal_t pal, long location, uchar *fuse)
pal_read_fuses(pal_t pal, long startlocation, long no_fuses, uchar *fuses)
pal_write_fuse(pal_t pal, long location, uchar fuse)
pal_write_fuses(pal_t pal, long startlocation, long no_fuses, uchar *fuses)
pal_disassemble(pal_t pal)
pal_free(pal_t pal)

So that the jedec reading is no longer central. Would this be reasonable
and fit in with what you need, or is the requirement to read the architecture
file before reading a jedec file too much? Also, is it better to have the
output from write_jedec() and disassemble() go to stdout or to file?

Graham