Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

Hi All,

I'm new to fpga design and was trying to research on logic on how to
implement several memory mapped registers on an FPGA.  I'm trying not
to take shortcuts by relying on the FPGA tool to make them for me,
because I want to know how it's put together.  
I was thinking that it might consist of several decoders which
generate signals that go the appropriate latches to store the data on
the bus.  But it seems that if I have more registers, then the
interconnect and number of decoders would increase substantially.
I'm just curious if there are more elegant ways to go about doing
this.  If anyone knows of any book/web site/journal/paper that I can
read up on this subject, please let me know.

Thanks,

-win
	

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In fpga-cpu@fpga..., "windam_2000" <windam_2000@...> wrote:
>
> Hi All,
> 
> I'm new to fpga design and was trying to research on logic on how to
> implement several memory mapped registers on an FPGA.  I'm trying not
> to take shortcuts by relying on the FPGA tool to make them for me,
> because I want to know how it's put together.  
> I was thinking that it might consist of several decoders which
> generate signals that go the appropriate latches to store the data on
> the bus.  But it seems that if I have more registers, then the
> interconnect and number of decoders would increase substantially.
> I'm just curious if there are more elegant ways to go about doing
> this.  If anyone knows of any book/web site/journal/paper that I can
> read up on this subject, please let me know.
> 
> Thanks,
> 
> -win
>

The registers have an output enable signal that puts the register
contents on the bus or lets the output float.

The registers also have a load signal to take the new contents from
the bus, a clock signal and, perhaps, a reset signal.

You just design the entity (or use one from a library) and instantiate
as many as you need.

The alternative is to use BlockRAM if it is available.

Two books worth having:  HDL Chip Design by Douglas J. Smith and
Essential VHDL by Sundar Rajan.  If I could just have one, it would be
Essential VHDL.

There are many other books available but, like most technical books,
they are quite expensive.

Richard
	

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> I'm new to fpga design and was trying to research on logic on how to
> implement several memory mapped registers on an FPGA.  I'm trying not

> I'm just curious if there are more elegant ways to go about doing
> this.  If anyone knows of any book/web site/journal/paper that I can
> read up on this subject, please let me know.
> 

I guess this is a post for fpga-io....

What I do is try and map all the registers that need to be memory 
mapped (eg. I/O device registers) into a small area of memory, then 
use block ram available in the FPGA as a regular memory to record what 
is read from and written to the registers. The block ram effectively 
acts as a shadow to the real I/O registers. There's no benefit to 
using a block ram to shadow I/O writes, however on readback it can 
eliminate a tremendous amount of logic in the form of multiplexors 
that would be needed. This does mean that a read of an I/O register 
doesn't actually reflect the state of the outputs of the register. 
Instead it's just a copy. However for a lot of purposes whether the 
read is from a copy of the I/O value or the actual I/O value doesn't 
matter. Sometimes it is necessary to read the state of actual I/O. One 
way to do this is to provide a signal from the I/O device that 
indicates when to override the value that would be read from the 
shadow memory.

What the block ram does is turn what might be six or seven 4-to-1 (or 
more) 32 bit multiplexers in a system into a much smaller multiplexor 
(eg single 4-to-1 mux). It saves a lot of logic (at least in an FPGA). 
However, it does cost block ram and the register mapping is 
restrictive so it's a design tradeoff.

In something like the Spartan3 (this is not an ad) a single 2KiB block 
ram can record 512-32 bit registers.

Rob
	

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hello windam,

w> If anyone knows of any book/web site/journal/paper that I can
w> read up on this subject, please let me know.

Frequently Asked Questions And Answers Books on VHDL
http://www.vhdl.org/pub/comp.lang.vhdl/FAQ2.pdf

ECE 449 "Computer Design Lab"
http://ece.gmu.edu/courses/ECE449/ece449_main.html#Lectures
http://ece.gmu.edu/courses/ECE449/Lectures/

ECE679 Special Topic on Computer Engineering
http://web.engr.oregonstate.edu/~sllu/vhdl.html
	-- 
Best regards,
 Alexander                            mailto:Aleksandr.Zorkaltsev@Alek...
	

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- windam_2000 <windam_2000@wind...> wrote:

> Hi All,
> 
> I'm new to fpga design and was trying to research on logic on how to
> implement several memory mapped registers on an FPGA.  
(...)

I beleve it is important to know if FPGA You are willing to use supports
tri-state busses. It can be either true tri-state or 'wired-or' (or something
like that). If it supports such then buss does not cost alot. On FPGA which
does not support tri-state busses HDL tool will generate muxes instead. In this
case any buss on-chip is very expensive. Always keep buss width matching the
available hardware. You may also use external buss but remember - it is wise to
isolate external buss from on-chip buss by some logic to get gain in speed and
power consumption.

To conserve logic used on decoders and muxes this is wise to extend buss with
IOWRITE/IOREAD/IOSEL\MEMSEL signals and choose much smaller width and address
space for I/O registers than for memory. Take a look how it is done on x86 -
you have separate OUT and IN instructions and up to 64k of address space. Such
approach simplifies hardware logic at the expense of less effective instruction
set. It also allows to easy differentiate timings when accesing I/O and memory
directly during instruction decoding instead of during buss access.

On ole 8051 it was common trick to put one 8-input nand on A8..A15 as an 'I/O
page' decoder to quickly select addresses belonging to I/O space. It allowed up
to 256 8 bit I/O registers to be selected. Or in simpler case, each of A0..A7
was tied to chip select of one of eight I/O regs.

Also make registers readable only when it is really necessary - write logic is
much less expensive since no datapath multiplexer is necessary. Software can
quite easily deal with write-only registers by keeping shadow value somewhere.
Make readable registers as narrow as possible. And always consider the case
when one will be willing to toggle single bit of I/O register - some design
decissions can make it very complicated. In heavy bit-toggling environment it
is better to have one 1bit I/O register for each I/O bit than one wide I/O port
which keeps all bits together (with the use of read-modify-write approach).

cheers,
	Tomasz Sztejka
 POLON ALFA
(work) http://www.polon-alfa.com.pl/
(private) http://www.sztejkat.prv.pl/
	___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security
Centre. http://uk.security.yahoo.com

(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Thanks for all the suggestions and references. These help!

Thanks,

-win

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )