Can SRAM Address lines be mixed/reorganized?

Kamac

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

Hi!

This might seem trivial question, but might be interesting:

When using SRAM ICs, does it matter which address line of SRAM to connect to
which DSP(uP) address line and which data line of SRAM to to which uP data
line? My guess is, it ISN'T important, cause either way unique address will
still point to unique location only actual SRAM locations would be mixed.

And when building for example ram that consists of two banks you can connect
together different address and data lines of ICs of each bank, right?

Why am I asking this? I'm designing PCB which has among other 8 SRAM SMD
chips (4 for each 32 bit wide bank) and I want to place chips of each bank
on different sides of PCB so that ICs from one bank will be exactly under
ICs from other bank. That way address pins from one bank are placed under
address pins from other bank and the same is with data pins. But it isn't
the same address/data pin number on each side. So for example A0 from bank 1
is under A7, A1 under A6, D0 under D7, D5 under D4, ...

Here's complete pin-pin list:

Bank1: A0 A1 A2 A3 A4 A5 A6 A7 A8 WE A09 A10 A11 A12 A13 A14
Bank2: A7 A6 A5 A4 A3 A2 A1 A0 WE A8 A16 A15 A14 A13 A12 A11
(DSP) A7 A4 A2 A0 A1 A3 A5 A8 A9 A11 A13 A15 A17 A16 A14

Bank1: A15 A16 D1 D2 D3 D4 D5 D6 D7 D8 CE OE VDD GND VDD GND
Bank2: A10 A09 D8 D7 D6 D5 D4 D3 D2 D1 OE CE GND VDD GND VDD
(DSP) A12 A10 D1 D2 D3 D4 D5 D6 D7 D8

I'd like to connect underlying Address and Data pins of each bank (but of
course not VDD with GND :) and not A8 with WE but A8 with A8) and both WE's
together, OE's to GND and CE of each bank to appropriate bank select from
address decoder. Then I'd connect address and data lines to address and data
lines of DSP (uP) and mix them together again, if this would ease routing.

This would make PCB routing a LOT simpler, but is there anything wrong with
this concept?
It might not work for FLASH ram, which is organized in SUB-BANKS, but I
don't see any problem with SRAM.
Am I missing something?

Thanx!

Please CC reply to my e-mail, too!
***************************************
Dejan Kamensek
http://www.uni-mb.si/~uelulv13b/
mailto::kamac_...@bigfoot.com

Greg Smart

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to Kamac

Hello,

there is no problem doing this, except the extra hassle chasing board
faults,
but even that's not a big deal

cheers
Greg

Kamac wrote:

> Hi!
>
> This might seem trivial question, but might be interesting:
>
> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.
>

Lasse Langwadt Christensen

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

In article <6i1h31$gue$1...@kanja.arnes.si>,

"Kamac" <ka...@bigfoot.com> writes:
> Hi!
>
> This might seem trivial question, but might be interesting:
>
> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.
>

Since each adress is still unique,theres no problem so as long as
data is written and read the same way.

--Lasse
----------------------------------------------------------
Lasse Langwadt Christensen, M.Sc. EE (to be in 1999)
Aalborg University, Department of communication technology
Applied Signal Processing and Implementation (ASPI)
e-mail: F...@control.auc.dk, http://www.control.auc.dk/~fuz
snail-mail: Lobovej 20 - 9230 Svenstrup - Denmark
Phone: +45 4026 5572

Roman Rumian

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

Hi,

in Motorola SRAM datasheets you will find only A description for every address
lines and DQ for data pins (no numbers).

Regards

Roman Rumian

--
Dr. Roman Rumian
DSP Group, Institute of Electronics, Univ. of Mining & Metallurgy,
30-059 Cracow, POLAND,al. Mickiewicza 30,
rum...@uci.agh.edu.pl tel.: +48-12-617-27-00 fax: +48-12-633-23-98

Tony Williams

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

In article <t%Y01.87$gr1.8...@sunsite.auc.dk>, Lasse Langwadt Christensen
<URL:mailto:f...@control.auc.dk> wrote:

> Since each adress is still unique,theres no problem so as long as
> data is written and read the same way.

Scrambling data or address lines used to be a common security
practice with EPROMs. Best done in top-track, hidden under
the socket. As you say, as long as the scrambling is the same
for read v write there should be no problem.
--
Tony Williams.

sta...@dspsystems.com

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

In article <6i1h31$gue$1...@kanja.arnes.si>,

"Kamac" <ka...@bigfoot.com> wrote:
>
> Hi!
>
> This might seem trivial question, but might be interesting:
>
> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.

Dejan,

Yes you can do that. I have done so on several of our products. You can also
do it with DRAM as long as you only swap column addresses within columns and
row addresses within rows. This doesn't normally come up, but you can also
write to memory with inverted data as long as you invert it coming back out.
Back when memory was on a bus, some bus drivers inverted the data and this was
done to avoid having to add an additional inverter stage.

>
> It might not work for FLASH ram, which is organized in SUB-BANKS, but I
> don't see any problem with SRAM. Am I missing something?
>

You can do the same thing with PROMs if you observe the bank boundaries and
all programming is done incircuit. You will have a problem using the locking
features though. I have avoided do this with PROMs as it would cause too much
trouble in software trying to implement locking and such.

Scott Taylor - DSP Fibre Channel Systems

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

John Williams

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

Yes, you can do this, but did you know that many SRAMs in surface mount packages
come in two different pinouts? They are denoted as "forward" and "reverse"
packages and are intended to be used on opposite sides of the board just as you
described.

John Williams

Kamac wrote:

> Hi!
>
> This might seem trivial question, but might be interesting:
>
> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.
>

> And when building for example ram that consists of two banks you can connect
> together different address and data lines of ICs of each bank, right?
>
> Why am I asking this? I'm designing PCB which has among other 8 SRAM SMD
> chips (4 for each 32 bit wide bank) and I want to place chips of each bank
> on different sides of PCB so that ICs from one bank will be exactly under
> ICs from other bank. That way address pins from one bank are placed under
> address pins from other bank and the same is with data pins. But it isn't
> the same address/data pin number on each side. So for example A0 from bank 1
> is under A7, A1 under A6, D0 under D7, D5 under D4, ...
>
> Here's complete pin-pin list:
>
> Bank1: A0 A1 A2 A3 A4 A5 A6 A7 A8 WE A09 A10 A11 A12 A13 A14
> Bank2: A7 A6 A5 A4 A3 A2 A1 A0 WE A8 A16 A15 A14 A13 A12 A11
> (DSP) A7 A4 A2 A0 A1 A3 A5 A8 A9 A11 A13 A15 A17 A16 A14
>
> Bank1: A15 A16 D1 D2 D3 D4 D5 D6 D7 D8 CE OE VDD GND VDD GND
> Bank2: A10 A09 D8 D7 D6 D5 D4 D3 D2 D1 OE CE GND VDD GND VDD
> (DSP) A12 A10 D1 D2 D3 D4 D5 D6 D7 D8
>
> I'd like to connect underlying Address and Data pins of each bank (but of
> course not VDD with GND :) and not A8 with WE but A8 with A8) and both WE's
> together, OE's to GND and CE of each bank to appropriate bank select from
> address decoder. Then I'd connect address and data lines to address and data
> lines of DSP (uP) and mix them together again, if this would ease routing.
>
> This would make PCB routing a LOT simpler, but is there anything wrong with
> this concept?

> It might not work for FLASH ram, which is organized in SUB-BANKS, but I
> don't see any problem with SRAM.
> Am I missing something?
>

> Thanx!
>
> Please CC reply to my e-mail, too!

Lasse Langwadt Christensen

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

In article <6i2alt$qmb$1...@nnrp1.dejanews.com>,

sta...@dspsystems.com writes:
> In article <6i1h31$gue$1...@kanja.arnes.si>,

> "Kamac" <ka...@bigfoot.com> wrote:
>>
>> Hi!
>>
>> This might seem trivial question, but might be interesting:
>>
>> When using SRAM ICs, does it matter which address line of SRAM to connect to
>> which DSP(uP) address line and which data line of SRAM to to which uP data
>> line? My guess is, it ISN'T important, cause either way unique address will
>> still point to unique location only actual SRAM locations would be mixed.
>

I have seen a "neat" trick that used that fact that you can do that.
it was a datalogger/buffer implemented in a FPGA it were to copy 64K
of data in to a buffer at high speed and the data should then later be
read at a lower speed. Instead of using a ordinary binary counter to
step trough the adresses, a 16bit shift register and two xors were used,
(a bit like a pseudo random generator), because it was able to count much
faster that a ordinary counter, but there was still 64K (minus one I think)
unique 16 bit combinations so when was data was read with the same generator
and startvalue the result was correct.

-- Lasse

Don Yuniskis

unread,

Apr 27, 1998, 3:00:00 AM4/27/98

to

In article <Hs411.95$gr1.8...@sunsite.auc.dk>,

Lasse Langwadt Christensen <f...@control.auc.dk> wrote:
>In article <6i2alt$qmb$1...@nnrp1.dejanews.com>,
> sta...@dspsystems.com writes:
>> In article <6i1h31$gue$1...@kanja.arnes.si>,
>> "Kamac" <ka...@bigfoot.com> wrote:
>>>
>>> Hi!
>>>
>>> This might seem trivial question, but might be interesting:
>>>
>>> When using SRAM ICs, does it matter which address line of SRAM to connect to
>>> which DSP(uP) address line and which data line of SRAM to to which uP data
>>> line? My guess is, it ISN'T important, cause either way unique address will
>>> still point to unique location only actual SRAM locations would be mixed.
>>
>I have seen a "neat" trick that used that fact that you can do that.
>it was a datalogger/buffer implemented in a FPGA it were to copy 64K
>of data in to a buffer at high speed and the data should then later be
>read at a lower speed. Instead of using a ordinary binary counter to
>step trough the adresses, a 16bit shift register and two xors were used,
>(a bit like a pseudo random generator), because it was able to count much

These are called shift counters. Their design is a bit of an art
form. I've used them in semi-custom (ASIC) designs because they
have very low cost (i.e. no logic between stages). IIRC, Motogorilla
had an app note describing them (back in the days when semi vendors
*wrote* app notes... :-(

>faster that a ordinary counter, but there was still 64K (minus one I think)

It is only faster if the "feedback" (in the case you cited, the two XORs)
have a shorter delay than a typical counter, etc. Since you can
implement any function in two levels of logic (e.g., AOI), the goal
is to minimize the complexity of each gate in those levels.

>unique 16 bit combinations so when was data was read with the same generator
>and startvalue the result was correct.

Usually, you build large shift counters as two relatively prime counters
beating against each other.

--don

Daniel Haude

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to

On 27 Apr 1998 20:15:02 GMT,
Don Yuniskis <d...@rtd.com> wrote:

> These are called shift counters. Their design is a bit of an art
> form. I've used them in semi-custom (ASIC) designs because they
> have very low cost (i.e. no logic between stages). IIRC, Motogorilla
> had an app note describing them (back in the days when semi vendors
> *wrote* app notes... :-(

Um, I fail to see in what _significant_ way a 16bit shift register would
be less complex (costly) than a 16bit synchronous counter.

--Daniel

Ray Andraka

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to

A binary counter needs to have a carry from all of the lower bits into
each bit of the count. In FPGA implementations, each logic block
typically only has a few inputs (typically 4), so for bits higher than
the 4th bit require multiple levels of combinatorial logic in front of
each flip-flop. Each level and the associated signal routing introduces
propagation delay, which in turn reduces the maximum clocking frequency
of the counter. The logic also uses up logic resource, which in some
cases can be important.

A linear feedback shift register (LFSR) counter on the other hand
eliminates the combinatorial logic except for one exclusive NOR gate
(may have 4 inputs for certain maximal length sequences) at the input
end of the shift register. The result is that in certain technologies,
like FPGAs, the LFSR counter can be much faster than an equivalent
binary counter. The price is the sequence is not a neat binary one.
Often times, the combinatorial logic block can be used separately from
the flip-flop, so that logic is usable for other functions (such as
decodes of certain count states)

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email rand...@ids.net
http://users.ids.net/~randraka

The Andraka Consulting Group is a digital hardware design firm
specializing in high performance FPGA designs for digital signal
processing, computing and control applications.

Jerry Avins

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to Daniel...@public.uni-hamburg.de

Daniel Haude wrote:
>
> On 27 Apr 1998 20:15:02 GMT,
> Don Yuniskis <d...@rtd.com> wrote:
>
> > These are called shift counters. Their design is a bit of an art
> > form. I've used them in semi-custom (ASIC) designs because they
> > have very low cost (i.e. no logic between stages). IIRC, Motogorilla
> > had an app note describing them (back in the days when semi vendors
> > *wrote* app notes... :-(
>
> Um, I fail to see in what _significant_ way a 16bit shift register would
> be less complex (costly) than a 16bit synchronous counter.
>
> --Daniel

Daniel,

At the last stage of a synchronous counter, the control gate needs
(stages - 1) inputs. In longish counters, that usually has to be
implemented by cascading simpler gates. (Even a custom high fan-in gate
is likely to be slower than than a simpler one with the same
technology.) In a memory system, every nanosecond of extra address
settling time eats into access time.

Jerry
--
******* REMOVE THE "x" TO REPLY *******
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
----------------------------------------------------------

Lasse Langwadt Christensen

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to

In article <354603...@ids.net>,

Ray Andraka <no_spam_...@ids.net> writes:
>
> A linear feedback shift register (LFSR) counter on the other hand
> eliminates the combinatorial logic except for one exclusive NOR gate
> (may have 4 inputs for certain maximal length sequences) at the input
> end of the shift register. The result is that in certain technologies,
> like FPGAs, the LFSR counter can be much faster than an equivalent
> binary counter. The price is the sequence is not a neat binary one.
> Often times, the combinatorial logic block can be used separately from
> the flip-flop, so that logic is usable for other functions (such as
> decodes of certain count states)
>

The app. note from AT&T I saw such a counter in used one two input
xnor for 32K-1 states or two two input xnors for 64K-1 states. The
advantages they listed was, less routing, faster, and less noise on
the supply, because of the "random" bit changes .

Aerospace Software

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to

Kamac wrote:
>
> Hi!
>
> This might seem trivial question, but might be interesting:
>
> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.
>

Yes, you can mix it, but that is a form of hardware hacking that I
cannot condone. Mixing things up increases the maintenance cost, due to
confusion and special documentation needs and is therefore not good
practice.

Cheers,

Herman.

David VanHorn

unread,

Apr 28, 1998, 3:00:00 AM4/28/98

to

>Yes, you can mix it, but that is a form of hardware hacking that I
>cannot condone. Mixing things up increases the maintenance cost, due to
>confusion and special documentation needs and is therefore not good
>practice.

Only if you don't routinely produce schematics. I don't think we've done a
product with SRAM yet where we DID leave the address and data lines in
order. My first trip back to capture from PCB is always to swap pins and
gates to make the route go better.

Don Yuniskis

unread,

Apr 29, 1998, 3:00:00 AM4/29/98

to

In article <354682...@agt.net>,
Aerospace Software <aero...@agt.net> wrote:
>Kamac wrote:

>> When using SRAM ICs, does it matter which address line of SRAM to connect to
>> which DSP(uP) address line and which data line of SRAM to to which uP data
>> line? My guess is, it ISN'T important, cause either way unique address will
>> still point to unique location only actual SRAM locations would be mixed.
>>
>> And when building for example ram that consists of two banks you can connect
>> together different address and data lines of ICs of each bank, right?

>> This would make PCB routing a LOT simpler, but is there anything wrong with
>> this concept?
>> It might not work for FLASH ram, which is organized in SUB-BANKS, but I
>> don't see any problem with SRAM.
>> Am I missing something?
>

>Yes, you can mix it, but that is a form of hardware hacking that I
>cannot condone. Mixing things up increases the maintenance cost, due to
>confusion and special documentation needs and is therefore not good
>practice.

What "special documentation needs" are there besides the schematic
(that is needed regardless)? I frequently do small designs in which
I deliberately assign pin numbers knowing the characteristics of a package
and it's likely placement in a layout.

One could argue that the reliability and manufacturabilty costs
incurred by a (possibly) larger PCB, extra vias, etc. necessitated
by a "less inspired" layout are incurred on *every* board manufactured
while the issues you fear are really only applicable to boards
that are serviced/defective/etc. And, any technician worth his
job title would quickly learn this characteristic of the design/layout...
just like folks working with CMOS/TTL/ECL heterogenous designs get
used to seeing "GND" tied to *voltage* sources, etc. And, in very
high speed designs, opting for short and/or even stub lengths
can be far more important than what something "looks like"
aesthetically -- "gee, that's not right..."

--don

Garry Allen

unread,

Apr 29, 1998, 3:00:00 AM4/29/98

to

Aerospace Software wrote:
> Yes, you can mix it, but that is a form of hardware hacking that I
> cannot condone. Mixing things up increases the maintenance cost, due to
> confusion and special documentation needs and is therefore not good
> practice.
>

> Cheers,
>
> Herman.
And is common practive on most SIMM and DIMM modules now sold throughout
the world. The only memory type where you will have real problems and
cannot do this is SDRAM as the memory is configured using the address
and data lines. Otherwise it is very common to swap both data and
address lines on most memory types. There are also major noise
advantages if it is done well as memory typically presents quite a large
load to the address and data bus drivers. The shorter the traces the
better. It is alos good practice to make sure the address and data lines
are daisy chained rather routed in a star configuration or with stubs.
Garry Allen

sta...@dspsystems.com

unread,

Apr 29, 1998, 3:00:00 AM4/29/98

to

In article <slrn6kb8b2....@insitu.physnet.uni-hamburg.de>,

Daniel...@public.uni-hamburg.de wrote:
>
> On 27 Apr 1998 20:15:02 GMT,
> Don Yuniskis <d...@rtd.com> wrote:
>
> > These are called shift counters. Their design is a bit of an art
> > form. I've used them in semi-custom (ASIC) designs because they
> > have very low cost (i.e. no logic between stages). IIRC, Motogorilla
> > had an app note describing them (back in the days when semi vendors
> > *wrote* app notes... :-(
>
> Um, I fail to see in what _significant_ way a 16bit shift register would
> be less complex (costly) than a 16bit synchronous counter.
>

Daniel,

I read a couple of other replies to you prior to writing this. I tto fail to
see the advantage. I use synchronous lookahead carry stages to handle the
fan-in for longer counters. In register rich FPGAs it makes more sense than
having cascaded combinatorial logic elements.

unread,

Apr 29, 1998, 3:00:00 AM4/29/98

to

In article <354682...@agt.net>#1/1,

aero...@agt.net wrote:
>
> Yes, you can mix it, but that is a form of hardware hacking that I
> cannot condone. Mixing things up increases the maintenance cost, due to
> confusion and special documentation needs and is therefore not good
> practice.
>

Herman,

unread,

Apr 30, 1998, 3:00:00 AM4/30/98

to

Exactly my point. If you wanted to make a programming adapter, then just do it.

Tony Williams

unread,

Apr 30, 1998, 3:00:00 AM4/30/98

to

In article <3547D9...@agt.net>, Aerospace Software
<URL:mailto:aero...@agt.net> wrote:

> Won't help, I've seen a complete military two-way radio that was cloned
> by a desperate crowd in another country. Switching a few lines, will
> not be enough to discourage guys like that!

Tricks, like scrambling addr lines, stop the less skillful and/or
makes it just that little bit more expensive for the cloner. But a
dedicated and skillful cloner will generally get there in the end.

--
Tony Williams.

S. D. Stafford

unread,

Apr 30, 1998, 3:00:00 AM4/30/98

to

Other than address lines A0 and A1 in SRAMs larger than 8 bits wide
that must support multiple width accesses (byte, short, long), specific
address lines designations shouldn't be required.

Micron SRAM Data Sheet pinouts actually have the address pins labeled
either "A0", "A1", or "A".

My 2 cents!

Scott
--
Scott Stafford BBN Technologies
email: staf...@bbn.com [A Division of GTE Internetworking]
http://www.bbn.com 4 John Clarke Rd
(401)849-2543 x3534 Middletown RI, 02842

Aerospace Software wrote:
>
> sta...@dspsystems.com wrote:
> >
> > In article <354682...@agt.net>#1/1,

> > aero...@agt.net wrote:
> > >
> > > Yes, you can mix it, but that is a form of hardware hacking that I
> > > cannot condone. Mixing things up increases the maintenance cost, due to
> > > confusion and special documentation needs and is therefore not good
> > > practice.
> > >
> >

Magnus Homann

unread,

Apr 30, 1998, 3:00:00 AM4/30/98

to

"Kamac" <ka...@bigfoot.com> writes:

> Hi!
>
> This might seem trivial question, but might be interesting:
>

> When using SRAM ICs, does it matter which address line of SRAM to connect to
> which DSP(uP) address line and which data line of SRAM to to which uP data
> line? My guess is, it ISN'T important, cause either way unique address will
> still point to unique location only actual SRAM locations would be mixed.

I would suspect that burst SRAM would require a bit of thought. I
don't know if that's what you are going to use though.

Homann
--
Magnus Homann Email: d0a...@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Mike Playle

unread,

May 1, 1998, 3:00:00 AM5/1/98

to

On Mon, 27 Apr 1998 09:36:31 -0700, John Williams
<john.w...@alumni.stanford.org> wrote:

>Yes, you can do this, but did you know that many SRAMs in surface mount packages
>come in two different pinouts? They are denoted as "forward" and "reverse"
>packages and are intended to be used on opposite sides of the board just as you
>described.

Or you could make such a "reverse" pinout yourself by (carefully)
bending the legs of the chip the other way and fitting it to the
board upside down.

Don Yuniskis

unread,

May 1, 1998, 3:00:00 AM5/1/98

to

In article <6i6f84$4fv$1...@nnrp1.dejanews.com>, <sta...@dspsystems.com> wrote:
>In article <slrn6kb8b2....@insitu.physnet.uni-hamburg.de>,
> Daniel...@public.uni-hamburg.de wrote:
>>
>> On 27 Apr 1998 20:15:02 GMT,
>> Don Yuniskis <d...@rtd.com> wrote:
>>
>> > These are called shift counters. Their design is a bit of an art
>> > form. I've used them in semi-custom (ASIC) designs because they
>> > have very low cost (i.e. no logic between stages). IIRC, Motogorilla
>> > had an app note describing them (back in the days when semi vendors
>> > *wrote* app notes... :-(
>>
>> Um, I fail to see in what _significant_ way a 16bit shift register would
>> be less complex (costly) than a 16bit synchronous counter.

In a shift counter, there is *no* logic between stages. Q(i+1) gets
Q(i) on the next clock edge for all i != 0. *All* of the logic is moved
to the "front" (lsb) of the counter. Try designing a counter from
D flipflops and AOI gates and then note the difference in the number
of packages you use. A 4 bit counter is simple enough to design for
the purpose of this "exercise". :>

>I read a couple of other replies to you prior to writing this. I tto fail to
>see the advantage. I use synchronous lookahead carry stages to handle the
>fan-in for longer counters. In register rich FPGAs it makes more sense than
>having cascaded combinatorial logic elements.

Regardless, you are adding logic at *each* stage of the counter. Perhaps
in an FPGA where those gates are already part of a "cell" you can
convince yourself that there is no cost. But, try a semi-custom
design (or a full custom) where you are building those counters
from primitive functions (FF, gates, etc.) and you'll see that each
stage you add increases the amount of silicon you consume.

>Granted, it is more difficult, and probably cannot be easily implemented in
>VHDL, nor will many canned library modules do this, but it does address and
>solve the problem. I have done it several times.

--don

Don Yuniskis

unread,

May 1, 1998, 3:00:00 AM5/1/98

to

In article <3547C5...@martin.com.au>,
Russell Shaw <rus...@martin.com.au> wrote:

[snip]

>Don't make the mistake of swapping pins on an EPROM!!!

*Sure* you can. It will cost you an hour to write a program
(even if it has to be in "BASIC") to reorder the data from
your "original" data file into your new "transformed" format
but that's a tiny investment considering the potential
savings, etc.

--don

Don Yuniskis

unread,

May 1, 1998, 3:00:00 AM5/1/98

to

In article <ant29095...@ledelec.demon.co.uk>,
Tony Williams <to...@ledelec.demon.co.uk> wrote:
>In article <354682...@agt.net>, Aerospace Software

><URL:mailto:aero...@agt.net> wrote:
>
>> Yes, you can mix it, but that is a form of hardware hacking that I
>> cannot condone. Mixing things up increases the maintenance cost, due to
>> confusion and special documentation needs and is therefore not good
>> practice.
>

> I don't see a problem. SRAM is randomly addressable down to the
> bit level without penalty. The pin-designations, Data(x) and Addr(y),
> are simply those assigned by the mfr and are not sacrosanct.
> Scrambling them for layout convenience is ok, and may even produce
> a better layout sometimes... eg, if a data-bus is approaching SRAM
> with D0 to D7 completely reversed why bother to do the unscrambling.
> It just has to be documented once, on the schematic.
>

> I *do* see a problem with other types of memory where bank-addressing
> is important (eg EEPROM), in which case casual scrambling of the
> address-lines could produce unfortunate performance penalties.

It can also affect memory testing algorithms -- though most vendors
don't provide the details of internal topology anymore...

--don

CETEC 1er nivel

unread,

May 2, 1998, 3:00:00 AM5/2/98

to

Anyone could help me ,cause i got my final project at school and i am
goingo to build a panoramical display like those that are at airports ,but
i dont know how to build it , i am confuse about using shift registers
,are they the best choice ? i would like to know if there exist something
more practic ..

thanks ..
a lot

Rito III

Ag@whd

unread,

May 3, 1998, 3:00:00 AM5/3/98

to

On Wed, 29 Apr 1998 11:20:41 -0700, "Jon Harris"
<jha...@NOSPAMspectralinc.com> wrote these words:

>Russell Shaw wrote in message <3547C5...@martin.com.au>...

>>Don't make the mistake of swapping pins on an EPROM!!!
>
>

>You're OK as long as you make a special adapter socket for your EPROM programmer
>to swap the data correspondingly. Or you can write software to take the
>programming file and swap the bits around. I've had to do the former due to
>accidentally wiring up D0:7 as D7:0. D'oh!

And be aware that some eprom manufacturers programming instructions (don't ask
I don't recall which) deliberately program memory in an order that
minimises heat by sequentially programming different physical areas of
the device.

Therefore re-ordering the pins on your programming adaptor may
circumvent or exceed the programming characteristics.

(Unlikely I know, but it's worth knowing about it).

Adrian

WWW WWW Adrian Gothard
WWW ww WWW White Horse Design
WWWWWWWWWW
WWWW WWWW w...@zetnet.co.uk, http://www.users.zetnet.co.uk/whd
---
Designers of GPS-based satellite tracking systems for vehicles

Don Yuniskis

unread,

May 4, 1998, 3:00:00 AM5/4/98

to

In article <3552d433....@news.netcomuk.co.uk>,

Peter <z1...@nospam24.com> wrote:
>
>>It can also affect memory testing algorithms -- though most vendors
>>don't provide the details of internal topology anymore...
>

>I was going to mention this :)

Heh heh heh... I beat you to it! :>

>If however one does a simple pseudo-random fill test (my favourite)
>then this doesn't matter.

Yes. However, if you back up one more level in abstraction and
allow arbitrary swaps of address lines to the MEMORY SUBSYSTEM (!!)
it starts to take on a new significance. ;-)

Random fills (a few passes) seem to be more than adequate for catching
most *real* memory failures without worrying if the algorithm has
some subtle flaw (assuming your fill pattern is "truly" random and
relatively prime in it's period with respect to the size of the
memory tested).

>Actually, I recall seeing the internal topology data on a Siemens
>(==Toshiba IIRC) 1mbit DRAM, and that device had the most weird swaps
>on the address lines.

Yes, and each vendor can opt for a different internal topology, etc.
This can be really amusing when trying to design good DRAM tests.
Thankfully, the quality of most DRAM is so good that this isn't an issue
anymore except in certain camps...

Testing CMOS SRAM, though, can still be an area where most tests
are useless (false positives).

--don

BTW, "testing" herein refering to BIST technology...

Jerry Avins

unread,

May 5, 1998, 3:00:00 AM5/5/98

to CETEC 1er nivel

Rito,

I can only guess what you mean by a panoramic display. Is it for text,
or for graphics? I assume that the image moves, but does it change, or
simply translate? What display technology is involved; LED (one color,
or more), LCD, gas discharge, flipping disks (like Ferranti), something
else? How many pixels do you plan to use (hight by width). How do you
want to do the electronics; processor based, or medium-scale integration
(gates, flipflops, shift regesters, etc.), or a combination? Depending
on your answers, I may be able to help you, and whatever they are, I'm
sure someone here can.

Jerry

Mike McCarty

unread,

May 8, 1998, 3:00:00 AM5/8/98

to

I would not want to be a technician trying to figure out what's wrong
with your circuit using a data analyzer and putting the hooks on your
RAM chip. I'd go nuts, and curse you to the nethermost regions of hell.

Mike

In article <ant29095...@ledelec.demon.co.uk>,
Tony Williams <to...@ledelec.demon.co.uk> wrote:

)In article <354682...@agt.net>, Aerospace Software
)<URL:mailto:aero...@agt.net> wrote:
)
)> Yes, you can mix it, but that is a form of hardware hacking that I
)> cannot condone. Mixing things up increases the maintenance cost, due to
)> confusion and special documentation needs and is therefore not good
)> practice.
)
) I don't see a problem. SRAM is randomly addressable down to the
) bit level without penalty. The pin-designations, Data(x) and Addr(y),
) are simply those assigned by the mfr and are not sacrosanct.
) Scrambling them for layout convenience is ok, and may even produce
) a better layout sometimes... eg, if a data-bus is approaching SRAM
) with D0 to D7 completely reversed why bother to do the unscrambling.
) It just has to be documented once, on the schematic.
)
) I *do* see a problem with other types of memory where bank-addressing
) is important (eg EEPROM), in which case casual scrambling of the
) address-lines could produce unfortunate performance penalties.
)
)--
)Tony Williams.
)

--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC. <- They make me say that.

Aerospace Software

unread,

May 8, 1998, 3:00:00 AM5/8/98

to

Hi Mike!

Glad to see somebody agrees with me... I really hate debugging things
that were mixed up. You only design the PCB once, while the testing
activity continues for the whole production run and repair for the next
20 years!

Cheers,

Herman

David VanHorn

unread,

May 9, 1998, 3:00:00 AM5/9/98

to

Mike McCarty wrote in message <6j045h$6...@sun001.spd.dsccc.com>...

>I would not want to be a technician trying to figure out what's wrong
>with your circuit using a data analyzer and putting the hooks on your
>RAM chip. I'd go nuts, and curse you to the nethermost regions of hell.

I'd ask if you looked at the schematic, and then beat you with it when you
said "umm. no" :)

Slavishly following arbitrary designations is pointless.

bill tighe

unread,

May 12, 1998, 3:00:00 AM5/12/98

to

Hitachi took this concept to an even higher order in one of their 4 bit
controllers. The instruction fetch addresses came out in pseudo-random order
that was different for each developed product. This was done for product
security to prevent theft of the code. A matching linker-loader would put
the instructions in the ROM in the correct order so the code would run. The
"plaintext" instruction code appeared only inside the processor. I don't
remember the part number of the chip but Hitachi should be able to tell you
if it is still available.

A friend of mine used this processor in 1982 to design a unique calculator.
He considered the scrambling feature very important in choosing the
controller. He didn't want somebody stealing the results of all his work.

Every bit in a RAM or ROM is the same as any other bit. They can be
scrambled any way you want as long as the write scramble matches the read
descramble.

Tony Williams wrote:

> In article <354682...@agt.net>, Aerospace Software

> <URL:mailto:aero...@agt.net> wrote:
>
> > Yes, you can mix it, but that is a form of hardware hacking that I

> > cannot condone. Mixing things up increases the maintenance cost, due to

> > confusion and special documentation needs and is therefore not good

> > practice.

>
> I don't see a problem. SRAM is randomly addressable down to the

> bit level without penalty. The pin-designations, Data(x) and Addr(y),

> are simply those assigned by the mfr and are not sacrosanct.

> Scrambling them for layout convenience is ok, and may even produce

> a better layout sometimes... eg, if a data-bus is approaching SRAM

> with D0 to D7 completely reversed why bother to do the unscrambling.

> It just has to be documented once, on the schematic.
>

> I *do* see a problem with other types of memory where bank-addressing

> is important (eg EEPROM), in which case casual scrambling of the

> address-lines could produce unfortunate performance penalties.
>

> --
> Tony Williams.

nick toop

unread,

May 13, 1998, 3:00:00 AM5/13/98

to

In article <3558C444...@jps.net>, bill tighe <wti...@jps.net>
writes

>Hitachi took this concept to an even higher order in one of their 4 bit
>controllers. The instruction fetch addresses came out in pseudo-random order
>that was different for each developed product. This was done for product
>security to prevent theft of the code. A matching linker-loader would put
>the instructions in the ROM in the correct order so the code would run. The
>"plaintext" instruction code appeared only inside the processor. I don't
>remember the part number of the chip but Hitachi should be able to tell you
>if it is still available.
>
>A friend of mine used this processor in 1982 to design a unique calculator.
>He considered the scrambling feature very important in choosing the
>controller. He didn't want somebody stealing the results of all his work.
>
>Every bit in a RAM or ROM is the same as any other bit. They can be
>scrambled any way you want as long as the write scramble matches the read
>descramble.
>

A company I worked for used this processor for a handheld chess
computer. I still have one somewhere if the number is important. I was
told the program counter was generated by a psuedo-random sequencer
because they could not make a synchronous counter fast enough. I
thought the sequencer feedback taps were public info because I thought
we considered writing our own linker as we did not like the development
tools.

--
nick toop