Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Discussion Groups
Discussion Groups | FPGA-CPU | Re: 4-read, 4-write* ram
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Re: RAM loading via JTAG - Piotr Zbysinski - EP\\H\\ - Aug 18 14:27:00 2005
----- Original Message -----
From: Richard Duits
To: lpc2000@lpc2...
Sent: Thursday, August 18, 2005 1:15 AM
Subject: Re: [lpc2000] RAM loading via JTAG When you switch the ARM7 into debug mode, all instructions and data are
read from the jtag interface. You can just upload a ldm instruction for
example with the data following the instruction and then use a stm
instruction to store it in sram.
** Do you mean: should I send via JTAG binary code of LDM/STM instructions?
Then you setup the registers to call
the IAP routine and set a breakpoint to the same address the LR is
pointing to. The ARM site has excelent documentation on this, so I
suggest you browse www.arm.com and lookup the information you need.
** OK, I\'ll try. A suggestion: use a FT2232 (see
http://www.ftdichip.com/FTProducts.htm#FT2232C) for the low level JTAG
stuff, they have a JTAG DLL for windows and good documentation the write
this yourself for other platforms. All you need is this single FT2232
and some passive components to make this work.
** JTAG is not a problem for me (I used FT2232 in universal PLD programmer/configurator IEEE1532 compatible). My idea is to prepare Windows software for simple Macraigor interface for fast programming LPC uCs.
Thanks for answer.
Piotr
[Non-text portions of this message have been removed]
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: RAM loading via JTAG - Piotr Zbysinski - EP\\\\H\\\\ - Aug 18 14:27:00 2005
----- Original Message -----
From: Richard Duits
To: lpc2000@lpc2...
Sent: Thursday, August 18, 2005 1:15 AM
Subject: Re: [lpc2000] RAM loading via JTAG When you switch the ARM7 into debug mode, all instructions and data are
read from the jtag interface. You can just upload a ldm instruction for
example with the data following the instruction and then use a stm
instruction to store it in sram.
** Do you mean: should I send via JTAG binary code of LDM/STM instructions?
Then you setup the registers to call
the IAP routine and set a breakpoint to the same address the LR is
pointing to. The ARM site has excelent documentation on this, so I
suggest you browse www.arm.com and lookup the information you need.
** OK, I\\\'ll try. A suggestion: use a FT2232 (see
http://www.ftdichip.com/FTProducts.htm#FT2232C) for the low level JTAG
stuff, they have a JTAG DLL for windows and good documentation the write
this yourself for other platforms. All you need is this single FT2232
and some passive components to make this work.
** JTAG is not a problem for me (I used FT2232 in universal PLD programmer/configurator IEEE1532 compatible). My idea is to prepare Windows software for simple Macraigor interface for fast programming LPC uCs.
Thanks for answer.
Piotr
[Non-text portions of this message have been removed]
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: RAM loading via JTAG - Piotr Zbysinski - EP\\\\\\\\H\\\\\\\\ - Aug 18 14:27:00 2005
----- Original Message -----
From: Richard Duits
To: lpc2000@lpc2...
Sent: Thursday, August 18, 2005 1:15 AM
Subject: Re: [lpc2000] RAM loading via JTAG When you switch the ARM7 into debug mode, all instructions and data are
read from the jtag interface. You can just upload a ldm instruction for
example with the data following the instruction and then use a stm
instruction to store it in sram.
** Do you mean: should I send via JTAG binary code of LDM/STM instructions?
Then you setup the registers to call
the IAP routine and set a breakpoint to the same address the LR is
pointing to. The ARM site has excelent documentation on this, so I
suggest you browse www.arm.com and lookup the information you need.
** OK, I\\\\\\\'ll try. A suggestion: use a FT2232 (see
http://www.ftdichip.com/FTProducts.htm#FT2232C) for the low level JTAG
stuff, they have a JTAG DLL for windows and good documentation the write
this yourself for other platforms. All you need is this single FT2232
and some passive components to make this work.
** JTAG is not a problem for me (I used FT2232 in universal PLD programmer/configurator IEEE1532 compatible). My idea is to prepare Windows software for simple Macraigor interface for fast programming LPC uCs.
Thanks for answer.
Piotr
[Non-text portions of this message have been removed]
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 4-read, 4-write* ram - Brett Wildermoth - Aug 23 3:56:00 2005
I believe he is trying to have a pool of RAM in which four devices can read
and write to at almost the same time. Each device should be able to address
the full capacity of the RAM.... Four seperate RAMs would enable concurrent
reading and writing but the addresses would not be shared......
It is a bit like the shared memory model in Parallel Computing.....
Brett
On Mon, 22 Aug 2005 03:33 pm, fpga-cpu@fpga... wrote:
> If you constrain the write ports so that each one has a separate address
> modulo 4, then this is just four separate banks of RAM. No rocket science
> here.
>
> At 04:09 AM 8/22/2005, you wrote:
> >Now something else that I've been playing with for a
> >while: how to grow the ports on internal ram.
> >Obviously, as long as only one write port is needed,
> >an arbitrarily number of read ports can be had by
> >simple replication of dual port rams (sharing the same
> >write port), however for more truly random access
> >write ports, I know of no alternative to time-sharing
> >(short of an complicated arbitration scheme that might
> >require wait cycles).
> >
> >If we constrain the the problem a bit and demand that
> >all writes must go to consecutive location (thus the
> >4-write*), then the design space opens up slightly.
> >I've tried a few approaches, but the most obvious
> >(below) is the one I've had the most success with.
> >
> >The 4-write* constraint implies that all writes go to
> >different addresses modulo 4 so we can split up the
> >ram into the four modulo classes and mux read accesses
> >and swivel the write data around to read the right
> >ram. Using this approach a Altera Cyclone
> >EP1C20F400C7 manages a 11.95 ns cycle time.
> >
> >Another idea I haven't tried yet is less portable and
> >involves using a wide write port and a two cycle write
> >(for alignment).
>
> I can't say I understand this. >
>
> Rick Collins
>
> rick.collins@rick...
>
> Arius - A Signal Processing Solutions Company http://www.arius.com
> Specializing in DSP and FPGA design http://www.gnuarm.com
> 4 King Ave. 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX >
>
> To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to:
> fpga-cpu-unsubscribe@fpga... Yahoo! Groups Links >
--
-------------------------------------------------------------------
Brett Wildermoth BEng(ME) MPhil
Lecturer
Convenor:
2010MEE Microprocessor Techniques
3021MEE Computer Systems
7010MEE Design of Embedded Systems
Program Convenor:
Fullcast Embedded Systems Software Training Program
Address:
School of Microelectronic Engineering
Faculty of Engineering and Info. Tech.
Phone: +61 7 3735 5063
Fax: +61 7 3735 5384
Email:
B...@B.Wi...
-------------------------------------------------------------------
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
and write to at almost the same time. Each device should be able to address
the full capacity of the RAM.... Four seperate RAMs would enable concurrent
reading and writing but the addresses would not be shared......
It is a bit like the shared memory model in Parallel Computing.....
Brett
On Mon, 22 Aug 2005 03:33 pm, fpga-cpu@fpga... wrote:
> If you constrain the write ports so that each one has a separate address
> modulo 4, then this is just four separate banks of RAM. No rocket science
> here.
>
> At 04:09 AM 8/22/2005, you wrote:
> >Now something else that I've been playing with for a
> >while: how to grow the ports on internal ram.
> >Obviously, as long as only one write port is needed,
> >an arbitrarily number of read ports can be had by
> >simple replication of dual port rams (sharing the same
> >write port), however for more truly random access
> >write ports, I know of no alternative to time-sharing
> >(short of an complicated arbitration scheme that might
> >require wait cycles).
> >
> >If we constrain the the problem a bit and demand that
> >all writes must go to consecutive location (thus the
> >4-write*), then the design space opens up slightly.
> >I've tried a few approaches, but the most obvious
> >(below) is the one I've had the most success with.
> >
> >The 4-write* constraint implies that all writes go to
> >different addresses modulo 4 so we can split up the
> >ram into the four modulo classes and mux read accesses
> >and swivel the write data around to read the right
> >ram. Using this approach a Altera Cyclone
> >EP1C20F400C7 manages a 11.95 ns cycle time.
> >
> >Another idea I haven't tried yet is less portable and
> >involves using a wide write port and a two cycle write
> >(for alignment).
>
> I can't say I understand this. >
>
> Rick Collins
>
> rick.collins@rick...
>
> Arius - A Signal Processing Solutions Company http://www.arius.com
> Specializing in DSP and FPGA design http://www.gnuarm.com
> 4 King Ave. 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX >
>
> To post a message, send it to: fpga-cpu@fpga...
> To unsubscribe, send a blank message to:
> fpga-cpu-unsubscribe@fpga... Yahoo! Groups Links >
--
-------------------------------------------------------------------
Brett Wildermoth BEng(ME) MPhil
Lecturer
Convenor:
2010MEE Microprocessor Techniques
3021MEE Computer Systems
7010MEE Design of Embedded Systems
Program Convenor:
Fullcast Embedded Systems Software Training Program
Address:
School of Microelectronic Engineering
Faculty of Engineering and Info. Tech.
Phone: +61 7 3735 5063
Fax: +61 7 3735 5384
Email:
B...@B.Wi...
-------------------------------------------------------------------
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 4-read, 4-write* ram - Jan Gray - Aug 23 17:37:00 2005
Interesting topic. This has been discussed before. Consider looking
through fpgacpu.org and this group
(http://groups.yahoo.com/group/fpga-cpu/messages) for articles containing
"register file" or "LIW" or "lut ram", for example,
http://groups.yahoo.com/group/fpga-cpu/message/976.
Also note that in Virtex-4 the BRAMs have a configurable extra pipeline
output register that means you can approximately double the frequency of
accesses. With proper pipelining you can treat them as a 4-port RAM or
faster 2-port RAM. Put another way, in V-4 register files in BRAMs become
more interesting.
Such a pity Spartan-3E BRAMs didn't pick up this output register.
Cheers,
Jan.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
through fpgacpu.org and this group
(http://groups.yahoo.com/group/fpga-cpu/messages) for articles containing
"register file" or "LIW" or "lut ram", for example,
http://groups.yahoo.com/group/fpga-cpu/message/976.
Also note that in Virtex-4 the BRAMs have a configurable extra pipeline
output register that means you can approximately double the frequency of
accesses. With proper pipelining you can treat them as a 4-port RAM or
faster 2-port RAM. Put another way, in V-4 register files in BRAMs become
more interesting.
Such a pity Spartan-3E BRAMs didn't pick up this output register.
Cheers,
Jan.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 4-read, 4-write* ram - Tommy Thorn - Aug 23 21:54:00 2005
--- Jan Gray <jsgray@jsgr...> wrote:
> Interesting topic.
I think so and figured I wasn't be the only one
struggling to overcome the 1-write port limit.
> This has been discussed before.
I've read that discussion, but it has only covered
completely independent write port for which there
really isn't any alternative to multiplexing the
ports. Multiplexing doesn't scale at all -- the total
bandwidth remains is constant, but is divided between
ports.
The additional constraint on writes allows for a
banked model (which btw I never claimed it was rocket
science). In my example with a 4 port ram on the
EP1C20 it was more than twice as fast as simply
multiplexing the ports.
I finally tested the other approach I mentioned.
Altera M4K ram blocks can be configured for unequal
width, which can be used to write 2^n consecutive
aligned words. Unfortunately it was no faster than
the banked model and is strictly less desirable due to
the alignment requirement.
The use case? I can imagine many, but the immediate
application for a stack with 4 parallel random access
reads and 0 to 4 elements pushed each cycle.
> Also note that in Virtex-4 the BRAMs have a
> configurable extra pipeline output register that
> means you can approximately double the frequency of
> accesses.
Altera's M4K have this register, but in my experience
it doesn't quite halve the cycle time.
YMMV,
Tommy __________________________________________________
">http://mail.yahoo.com
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
> Interesting topic.
I think so and figured I wasn't be the only one
struggling to overcome the 1-write port limit.
> This has been discussed before.
I've read that discussion, but it has only covered
completely independent write port for which there
really isn't any alternative to multiplexing the
ports. Multiplexing doesn't scale at all -- the total
bandwidth remains is constant, but is divided between
ports.
The additional constraint on writes allows for a
banked model (which btw I never claimed it was rocket
science). In my example with a 4 port ram on the
EP1C20 it was more than twice as fast as simply
multiplexing the ports.
I finally tested the other approach I mentioned.
Altera M4K ram blocks can be configured for unequal
width, which can be used to write 2^n consecutive
aligned words. Unfortunately it was no faster than
the banked model and is strictly less desirable due to
the alignment requirement.
The use case? I can imagine many, but the immediate
application for a stack with 4 parallel random access
reads and 0 to 4 elements pushed each cycle.
> Also note that in Virtex-4 the BRAMs have a
> configurable extra pipeline output register that
> means you can approximately double the frequency of
> accesses.
Altera's M4K have this register, but in my experience
it doesn't quite halve the cycle time.
YMMV,
Tommy __________________________________________________
">http://mail.yahoo.com
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: 4-read, 4-write* ram - Arius - Rick Collins - Aug 24 1:20:00 2005
This is a difficult topic to discuss in email. Once you start allowing
limitations in the memory there are a lot of issues and tradeoffs. What
works for any given application depends on exactly what you can accept and
what you can't. There are so many tradeoffs, that it is hard to describe
clearly.
My comment about rocket science was not meant to be rude or snide. I just
meant that the banked memory model is rather simple. Likewise a true n
port memory is very simple (if you have it). Everything in between is much
more complicated to know what will work for you and what won't.
The approach described below is one that falls in the middle and I actually
don't understand what is happening. Terms like "swivel the write data
around" are what I mean by this being hard to describe. I don't understand
this and I doubt that I could describe it better. At 03:56 AM 8/23/2005, you wrote:
>I believe he is trying to have a pool of RAM in which four devices can read
>and write to at almost the same time. Each device should be able to address
>the full capacity of the RAM.... Four seperate RAMs would enable concurrent
>reading and writing but the addresses would not be shared......
>
>It is a bit like the shared memory model in Parallel Computing.....
>
>Brett
>
>On Mon, 22 Aug 2005 03:33 pm, fpga-cpu@fpga... wrote:
> > If you constrain the write ports so that each one has a separate address
> > modulo 4, then this is just four separate banks of RAM. No rocket science
> > here.
> >
> > At 04:09 AM 8/22/2005, you wrote:
> > >Now something else that I've been playing with for a
> > >while: how to grow the ports on internal ram.
> > >Obviously, as long as only one write port is needed,
> > >an arbitrarily number of read ports can be had by
> > >simple replication of dual port rams (sharing the same
> > >write port), however for more truly random access
> > >write ports, I know of no alternative to time-sharing
> > >(short of an complicated arbitration scheme that might
> > >require wait cycles).
> > >
> > >If we constrain the the problem a bit and demand that
> > >all writes must go to consecutive location (thus the
> > >4-write*), then the design space opens up slightly.
> > >I've tried a few approaches, but the most obvious
> > >(below) is the one I've had the most success with.
> > >
> > >The 4-write* constraint implies that all writes go to
> > >different addresses modulo 4 so we can split up the
> > >ram into the four modulo classes and mux read accesses
> > >and swivel the write data around to read the right
> > >ram. Using this approach a Altera Cyclone
> > >EP1C20F400C7 manages a 11.95 ns cycle time.
> > >
> > >Another idea I haven't tried yet is less portable and
> > >involves using a wide write port and a two cycle write
> > >(for alignment).
> >
> > I can't say I understand this. Rick Collins
rick.collins@rick...
Arius - A Signal Processing Solutions Company http://www.arius.com
Specializing in DSP and FPGA design http://www.gnuarm.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
limitations in the memory there are a lot of issues and tradeoffs. What
works for any given application depends on exactly what you can accept and
what you can't. There are so many tradeoffs, that it is hard to describe
clearly.
My comment about rocket science was not meant to be rude or snide. I just
meant that the banked memory model is rather simple. Likewise a true n
port memory is very simple (if you have it). Everything in between is much
more complicated to know what will work for you and what won't.
The approach described below is one that falls in the middle and I actually
don't understand what is happening. Terms like "swivel the write data
around" are what I mean by this being hard to describe. I don't understand
this and I doubt that I could describe it better. At 03:56 AM 8/23/2005, you wrote:
>I believe he is trying to have a pool of RAM in which four devices can read
>and write to at almost the same time. Each device should be able to address
>the full capacity of the RAM.... Four seperate RAMs would enable concurrent
>reading and writing but the addresses would not be shared......
>
>It is a bit like the shared memory model in Parallel Computing.....
>
>Brett
>
>On Mon, 22 Aug 2005 03:33 pm, fpga-cpu@fpga... wrote:
> > If you constrain the write ports so that each one has a separate address
> > modulo 4, then this is just four separate banks of RAM. No rocket science
> > here.
> >
> > At 04:09 AM 8/22/2005, you wrote:
> > >Now something else that I've been playing with for a
> > >while: how to grow the ports on internal ram.
> > >Obviously, as long as only one write port is needed,
> > >an arbitrarily number of read ports can be had by
> > >simple replication of dual port rams (sharing the same
> > >write port), however for more truly random access
> > >write ports, I know of no alternative to time-sharing
> > >(short of an complicated arbitration scheme that might
> > >require wait cycles).
> > >
> > >If we constrain the the problem a bit and demand that
> > >all writes must go to consecutive location (thus the
> > >4-write*), then the design space opens up slightly.
> > >I've tried a few approaches, but the most obvious
> > >(below) is the one I've had the most success with.
> > >
> > >The 4-write* constraint implies that all writes go to
> > >different addresses modulo 4 so we can split up the
> > >ram into the four modulo classes and mux read accesses
> > >and swivel the write data around to read the right
> > >ram. Using this approach a Altera Cyclone
> > >EP1C20F400C7 manages a 11.95 ns cycle time.
> > >
> > >Another idea I haven't tried yet is less portable and
> > >involves using a wide write port and a two cycle write
> > >(for alignment).
> >
> > I can't say I understand this. Rick Collins
rick.collins@rick...
Arius - A Signal Processing Solutions Company http://www.arius.com
Specializing in DSP and FPGA design http://www.gnuarm.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )