Hi Eddie,
>> The example also points out that the TS-7300 FPGA interface
>> has a 'platform specific access requirement'; the FPGA
>> interface can not handle arbitrary width accesses.
>> There's probably a good reason for this, or if not, thats
>> just the way it is now, so you have to deal with it.
>
> If one reads from a 16 bit register via two 8 bit reads and the data has
> not changed(seeing as though the reads are not atomic) the data will be
> correct in that the the two byte reads will represent the MSB and LSB of
> the 16 bit register. Although if one tries to write to a 16 bit register
> via two 8 bit writes (on the TS-7300 FPGA registers) it is not
> equivalent to a 16 bit write. If a 16 bit register is being written to a
> single atomic 16 bit write must take place. I spoke to the engineer who
> designed the FPGA core and he said one should differentiate between
> memory and registers. His design philosophy being that registers should
> be written atomically. This reduces complexity, space in the FPGA, and cost.
Note; the following should not be considered a critique
of the TS-7300 implementation, I merely wanted to add my
personal experience with this type of design decision,
given that it is relevant to this thread; so on with
my response:
I take a different approach. If the external memory
interface of the processor has byte-lane enables,
then its simple to create an FPGA control register that
also contains byte-lane enables. With byte-level
control, 8-bit writes to either the low-byte, or
high-byte of a 16-bit are possible, as the byte in
the register that is not being written does not get
updated (its write-enable control does not assert).
16-bit writes of course assert both byte-lanes.
The complexity is 1 additional signal - the byte lane
enable. Its 1 additional bit, not two, even though there
are two byte lane enables. For example, a 10-bit a byte
address ADDR[9:0], becomes a 16-bit address ADDR[9:1],
and the two byte-lane enables BE[1:0] indicate the LSB.
So you go from 10-bits ADDR to 9-bits ADDR and 2-bits BE.
There is no increase in logic, since the LEs in the FPGA
have sufficient LUT input resources to implement the
byte-lane enable.
Note that the RAM in the Cyclone II devices, Stratix II
devices all contain byte-lanes now.
The older FLEX devices did not, and I'm not sure if the
Cyclone devices do either; so that may have contributed
to the design decision.
The reason for implementing byte lane enables is that it
can stop you from having hard-to-find bugs.
For example, in a PCI design I was working on, there were
device registers that were defined using bit-fields.
The C standard for bit-fields describes them using
integer types. However, it turns out that gcc will
emit byte assembly operations. What this caused was
a 32-bit register to have the 3 MSBs written with whatever
the PCI bus was last parked on. For registers that had
less than 8-bits, the garbage writes did nothing since
there were no control bits to overwrite, but for the
control registers with more than 8-bits, the writes to the MSBs
would sometimes do nothing, other times cause problems.
It took a logic analyzer, and lots of toggling of I/Os
lines to track down this subtle issue.
I took the same bit-field code and compiled it with M/S
visual C++ and got different assembly instructions
generated; so the compilation of bit-fields into byte
instructions was not a processor dependent thing, it was
compiler dependent.
Since then I've stopped using bit-fields, and I've
always implemented full byte-lane control on interfaces
that use it.
Just my experience :)
Cheers,
Dave
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|