[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Icarus PAL snapshot 20001118
On Sat, 18 Nov 2000, Stephen Williams wrote:
> Welcome to Icarus PAL!
Cool! I've a number of PALs from old hobby projects that were done with
proprietary tools that no longer exist.
> This is pretty early and only supports 22v10 devices, and only reads files,
> and ..., well you get the idea. The package includes libraries for accessing
> JEDEC files and device descriptions, and a couple programs that make use of
> these descriptions to describe a design.
I've just been playing with ipaledit and ipalrev on an old 22v10 design,
and I think the macrocell-configuration data in pal22v10.pa may not be
quite right.
Is there an ipal-bugs alias or database yet?
According to the 1990 Texas Instruments Programmable Logic Databook,
the higher-numbered fuse (i.e. fuse 5809) is the "register" fuse, and the
lower-numbered one (5808) is the polarity-invert fuse.
Also, the databook includes this little table:
S1 S0 (S1=5809, 5811, etc)
0 0 = registered feedback, registered, active-low output
0 1 = registered feedback, registered, active-high output
1 0 = I/O feedback, combinational, active-low output
1 1 = I/O feedback, combinational, active-high output
(0=intact, 1=blown, same convention as documented in the .pa file)
After swazzling around the pal22v10.pa, the patch is larger than the file,
so I respectfully submit the edited version below for Steve and everyone
else's consideration.
Another little thing:
In the 22v10, the array inputs for the I/O pins (14, 15, ... 23) do not
come directly from the pins, rather they come from the macrocell, which
may drive them either from the pin or the register.
(it makes a difference when the output-enable isn't always asserted)
In the 22v10, the feedback source is controlled by the "register"
configuration fuse. The 22vp10 adds another fuse to control the feedback.
Some of the more esoteric PALs have much more complex macrocells, that may
have multiple outputs feeding back to the fuse array. I've got a book
that shows the gory details on a lot of wierd ones.
So somehow, information on all this will have to get integrated into the
model of the world represented by the .pa files, libipal, ipalrev and
ipaledit.
Here are some very half-baked idea:
Instead of trying to code the names of configuration flags (register,
invert, etc) into the libraries and tools, consider allowing new ones to
be defined dynamicly on the fly in the .pa files. ipaledit could use this
directly. And perhaps instead of putting knowledge of how the flags
affect the ouput verilog, somehow put fragments of verilog into the .pa
files, such as for example:
mode 0 {register invert}
verilog "
reg REG$pin;
always @(posedge $clk)
REG$pin <= $sop_expr;
bufif1(PIN$pin, ~REG$pin, OE$pin);
wire FEEBACK$pin = ~REG$pin;
"
The problem with somthing like this of course is that it is great for
ipalrev, but requires a lot more work to use a description like this for
synthesis. I guess you'd have to compile the verilog fragment, and then
do some kind of graph-matching search for fragments to match what a design
needs. (I think synthesis tools for ASIC standard-cell libraries works
this way, so you'd be in good company.)
Next: hacking up a pal16l8.pa file and seeing what happens with that...
cheers,
Steve Tell
edited pal22v10.pa follows.
#
# PAL devices have a core matrix that implements all the combinational
# logic. The dimensions are the number of columns (inputs) and the
# number of rows (outputs).
#
# The outputs from the matrix connect to a set of sum-of-product devices
# that reduce the rows to a small, named set.
#
# The outputs from the SOP steps connects either to magic signals or
# to CELLs. The cells are configureable devices that can register or
# invert the SOP value. The cells have 0 or more configuration fuses.
#
# So, the generic PAL looks like this:
#
#
# input pin
# pins SOP Macrocells drivers
# |||||||
# +++++++-- \ |
# +++++++-- | --- <CELL> ----|>------
# +++++++-- /
# +++++++-- \ |
# +++++++-- | --- <CELL> ----|>------
# +++++++-- /
#
# In theory, every row connects to a SOP that connects to a cell. However,
# PLDs often have magic internal signals such as global presets that
# don't connect through real macrocells. In these cases, it is enough to
# leave the cell for the SOP undescribed, and a null cell will be inferred.
#
# This is the total number of fuses contained in the part. It is not
# really needed, but is a cross-check of the rest of the configuration.
fuse_count 5828;
# These are the inputs to the matrix, in FUSE ORDER. So far as I know,
# these are always connected to pins or the inverted pins.
# NB: not true - often array inputs come from the macrocell.
# In the 22v10, the array inputs can come either either from the
# I/O pin or from the macrocell's register (before the tristate buffer),
# depending on the macrocell configuration. (tell)
#
inputs {
PIN1, ~PIN1, PIN23, ~PIN23, PIN2, ~PIN2, PIN22, ~PIN22,
PIN3, ~PIN3, PIN21, ~PIN21, PIN4, ~PIN4, PIN20, ~PIN20,
PIN5, ~PIN5, PIN19, ~PIN19, PIN6, ~PIN6, PIN18, ~PIN18,
PIN7, ~PIN7, PIN17, ~PIN17, PIN8, ~PIN8, PIN16, ~PIN16,
PIN9, ~PIN9, PIN15, ~PIN15, PIN10, ~PIN10, PIN14, ~PIN14,
PIN11, ~PIN11, PIN13, ~PIN13
}
# These are the outputs from the matrix, again in fuse order. The fuses
# of all the inputs of a row are listed above (in the inputs clause) so
# these describe the sum-of-product expressions in row order.
outputs {
(AR 1),
(OE23 1), (CELL23 8),
(OE22 1), (CELL22 10),
(OE21 1), (CELL21 12),
(OE20 1), (CELL20 14),
(OE19 1), (CELL19 16),
(OE18 1), (CELL18 16),
(OE17 1), (CELL17 14),
(OE16 1), (CELL16 12),
(OE15 1), (CELL15 10),
(OE14 1), (CELL14 8),
(SP 1)
}
# --
# The input to a macrocell is always the single bit result of the
# sum-of-products calculation. The cell can be configured to register
# its input, or to simply pass it to the output buffer. Its output
# stage can be configured to invert the data value.
#
# The CELL description includes a list of the fuses that configure
# the behavior of the cell. The fuses are listed MOST-SIGNIFICANT-
# BIT-FIRST (i.e. like a Verilog concatenation) with a 1 value meaning
# the fuse is blown. The configuration fuses are put together to form
# a number that selects the configuration modes.
#
# Each CELL has its own description because they have different
# configuration fuses, and theoretically (though not typically)
# different capabilities.
#
# For PAL22v10 devices, the configuration fuses are C0 and C1. I choose
# for the purpose of assigning modes to make C1 the MSB and C0 the LSB
# of the mode number, and describe the modes accordingly. That of course
# means that the config_fuses list should list the fuses for {C1 C0}.
macrocell CELL23 {
config_fuses {5809 5808}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL22 {
config_fuses {5811 5810}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL21 {
config_fuses {5813 5812}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL20 {
config_fuses {5815 5814}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL19 {
config_fuses {5817 5816}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL18 {
config_fuses {5819 5818}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL17 {
config_fuses {5821 5820}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL16 {
config_fuses {5823 5822}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL15 {
config_fuses {5825 5824}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}
macrocell CELL14 {
config_fuses {5827 5826}
mode 0 {register invert}
mode 1 {register }
mode 2 { invert}
mode 3 { }
}