In this article http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf on the second page there's a description of the memory architecture. A can't wrap around my head how did they configure 8 BRAMs to a 32KB memory with 12 independent ports. Can anybody explain this to me?
Multi-port memory
Started by ●May 21, 2016
Reply by ●May 21, 20162016-05-21
On 5/21/2016 12:28 PM, Ilya Kalistru wrote:> In this article > http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf > on the second page there's a description of the memory architecture. > A can't wrap around my head how did they configure 8 BRAMs to a 32KB > memory with 12 independent ports. Can anybody explain this to me?The 32 kB CRAM has four ports, but each port only accesses a quarter of the memory. If each port were able to access the full memory there would be no need for the crossbar switch. So really the CRAM is four separate 8 kB RAMs. Or did I miss something? -- Rick C
Reply by ●May 21, 20162016-05-21
On Sat, 21 May 2016 09:28:03 -0700, Ilya Kalistru wrote:> In this article > http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf on > the second page there's a description of the memory architecture. A > can't wrap around my head how did they configure 8 BRAMs to a 32KB > memory with 12 independent ports. Can anybody explain this to me?I only skimmed that paper so my impression could be wrong, but it seemed that the buzzword/content ratio was fairly high. In such cases, close examination of questionable content -- when it doesn't lead to outright evasion -- often leads to finding out they're doing something predictable, ordinary, and not too astonishing. If I recall correctly, the Xilinx BRAMs are already dual-port. The predictable, ordinary, and not too astonishing way that I'd do what they describe would be to design an arbitrating interface to the BRAM blocks in such a manner that any two accesses to any one BRAM would be "perfect" dual-port, but simultaneous accesses beyond two would generate "not ready" signals. I might even design it so that while there are 12 ports, each port would have preferred access to just one or two BRAMs, with accesses to BRAMs that are "further afield" (conceptually if not physically on the chip) would take longer. You could possibly speed this up by stacking up any write requests to be done in slack time, but you'd have to do it in a consistent manner -- you wouldn't a subsequent read of old data, for instance. So, basically, you'd do the same thing as you'd do if you were making a "dual port" RAM with a controller and a bunch of single-port RAM chips, only more so. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●May 21, 20162016-05-21
On Sat, 21 May 2016 12:39:47 -0500, Tim Wescott wrote:> On Sat, 21 May 2016 09:28:03 -0700, Ilya Kalistru wrote: > >> In this article >> http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf on >> the second page there's a description of the memory architecture. A >> can't wrap around my head how did they configure 8 BRAMs to a 32KB >> memory with 12 independent ports. Can anybody explain this to me? > > I only skimmed that paper so my impression could be wrong, but it seemed > that the buzzword/content ratio was fairly high. In such cases, close > examination of questionable content -- when it doesn't lead to outright > evasion -- often leads to finding out they're doing something > predictable, ordinary, and not too astonishing. > > If I recall correctly, the Xilinx BRAMs are already dual-port. The > predictable, ordinary, and not too astonishing way that I'd do what they > describe would be to design an arbitrating interface to the BRAM blocks > in such a manner that any two accesses to any one BRAM would be > "perfect" > dual-port, but simultaneous accesses beyond two would generate "not > ready" signals. > > I might even design it so that while there are 12 ports, each port would > have preferred access to just one or two BRAMs, with accesses to BRAMs > that are "further afield" (conceptually if not physically on the chip) > would take longer. > > You could possibly speed this up by stacking up any write requests to be > done in slack time, but you'd have to do it in a consistent manner -- > you wouldn't a subsequent read of old data, for instance. > > So, basically, you'd do the same thing as you'd do if you were making a > "dual port" RAM with a controller and a bunch of single-port RAM chips, > only more so.I should mention -- for the most part I'm not an FPGA guy. I'm circuit design and software, with enough FPGA chops to do simple stuff. I have done FPGA projects that have left the customer happy, but I've done more work that involves credibly _threatening_ (one says "offering" with an ingratiating smile for maximum effect) to write some Verilog or VHDL. Given a reasonably competent and territorial FPGA guy, this usually prompts a response of "here, Tim, let me take that off your hands". -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●May 21, 20162016-05-21
On Saturday, May 21, 2016 at 7:48:43 PM UTC+3, rickman wrote:> On 5/21/2016 12:28 PM, Ilya Kalistru wrote: > > In this article > > http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf > > on the second page there's a description of the memory architecture. > > A can't wrap around my head how did they configure 8 BRAMs to a 32KB > > memory with 12 independent ports. Can anybody explain this to me? >=20 > The 32 kB CRAM has four ports, but each port only accesses a quarter of==20> the memory. If each port were able to access the full memory there=20 > would be no need for the crossbar switch. So really the CRAM is four=20 > separate 8 kB RAMs. Or did I miss something? >=20 > --=20 >=20 > Rick Cyes. That makes sense. I just thought that if they mentioned pipeline halti= ng in the case of simultaneous access to 2:1 mux, that means that there is = no arbitrating in 4 ports of memory. But now I see that in the sentence abo= ut halting they don't mention 2:1 mux. It can be about this 4 ports too.
Reply by ●May 22, 20162016-05-22
On 5/21/2016 1:43 PM, Tim Wescott wrote:> > I should mention -- for the most part I'm not an FPGA guy. I'm circuit > design and software, with enough FPGA chops to do simple stuff. I have > done FPGA projects that have left the customer happy, but I've done more > work that involves credibly _threatening_ (one says "offering" with an > ingratiating smile for maximum effect) to write some Verilog or VHDL. > Given a reasonably competent and territorial FPGA guy, this usually > prompts a response of "here, Tim, let me take that off your hands".I think it's more like the FPGA guy feels you are offensive to the art of FPGAs. Maybe not truly dangerous, but not the sort of thing an FPGA guy wants to think about. I haven't worked with you obviously, I'm just going from your description. :) Actually I just finished a simple presentation on test benches for an FPGA workshop being given next week. The guy doing it is providing an 8080 core that he is testing by loading a Forth interpreter into the CPU memory. I ran a testbench driven by a text command file and in the simple test I put together I found a bug in the increment/decrement commands. I mentioned that in my writeup since that is a good illustration of using testbenches. -- Rick C
Reply by ●May 22, 20162016-05-22
On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:> On 5/21/2016 1:43 PM, Tim Wescott wrote: >> >> I should mention -- for the most part I'm not an FPGA guy. I'm circuit >> design and software, with enough FPGA chops to do simple stuff. I have >> done FPGA projects that have left the customer happy, but I've done >> more work that involves credibly _threatening_ (one says "offering" >> with an ingratiating smile for maximum effect) to write some Verilog or >> VHDL. Given a reasonably competent and territorial FPGA guy, this >> usually prompts a response of "here, Tim, let me take that off your >> hands". > > I think it's more like the FPGA guy feels you are offensive to the art > of FPGAs. Maybe not truly dangerous, but not the sort of thing an FPGA > guy wants to think about. I haven't worked with you obviously, I'm just > going from your description. :)You're probably right. I believe that I have a pretty good grasp of what's possible with FPGAs, but I'm not an experienced or even a hugely interested practitioner. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●May 22, 20162016-05-22
On 5/22/2016 1:32 AM, Tim Wescott wrote:> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote: > >> On 5/21/2016 1:43 PM, Tim Wescott wrote: >>> >>> I should mention -- for the most part I'm not an FPGA guy. I'm circuit >>> design and software, with enough FPGA chops to do simple stuff. I have >>> done FPGA projects that have left the customer happy, but I've done >>> more work that involves credibly _threatening_ (one says "offering" >>> with an ingratiating smile for maximum effect) to write some Verilog or >>> VHDL. Given a reasonably competent and territorial FPGA guy, this >>> usually prompts a response of "here, Tim, let me take that off your >>> hands". >> >> I think it's more like the FPGA guy feels you are offensive to the art >> of FPGAs. Maybe not truly dangerous, but not the sort of thing an FPGA >> guy wants to think about. I haven't worked with you obviously, I'm just >> going from your description. :) > > You're probably right. I believe that I have a pretty good grasp of > what's possible with FPGAs, but I'm not an experienced or even a hugely > interested practitioner.I was a bit confused by your description of using HDL. You do use HDL now, right? -- Rick C
Reply by ●May 23, 20162016-05-23
On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:> On 5/22/2016 1:32 AM, Tim Wescott wrote: >> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote: >> >>> On 5/21/2016 1:43 PM, Tim Wescott wrote: >>>> >>>> I should mention -- for the most part I'm not an FPGA guy. I'm >>>> circuit design and software, with enough FPGA chops to do simple >>>> stuff. I have done FPGA projects that have left the customer happy, >>>> but I've done more work that involves credibly _threatening_ (one >>>> says "offering" with an ingratiating smile for maximum effect) to >>>> write some Verilog or VHDL. Given a reasonably competent and >>>> territorial FPGA guy, this usually prompts a response of "here, Tim, >>>> let me take that off your hands". >>> >>> I think it's more like the FPGA guy feels you are offensive to the art >>> of FPGAs. Maybe not truly dangerous, but not the sort of thing an >>> FPGA guy wants to think about. I haven't worked with you obviously, >>> I'm just going from your description. :) >> >> You're probably right. I believe that I have a pretty good grasp of >> what's possible with FPGAs, but I'm not an experienced or even a hugely >> interested practitioner. > > I was a bit confused by your description of using HDL. You do use HDL > now, right?Yes, although my favorite HDL is a block diagram and a bunch of math, handed to someone like you. It works ever so much better for everyone on the project than me banging out Verilog or VHDL. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●May 23, 20162016-05-23
On 5/23/2016 2:44 AM, Tim Wescott wrote:> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote: > >> On 5/22/2016 1:32 AM, Tim Wescott wrote: >>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote: >>> >>>> On 5/21/2016 1:43 PM, Tim Wescott wrote: >>>>> >>>>> I should mention -- for the most part I'm not an FPGA guy. I'm >>>>> circuit design and software, with enough FPGA chops to do simple >>>>> stuff. I have done FPGA projects that have left the customer happy, >>>>> but I've done more work that involves credibly _threatening_ (one >>>>> says "offering" with an ingratiating smile for maximum effect) to >>>>> write some Verilog or VHDL. Given a reasonably competent and >>>>> territorial FPGA guy, this usually prompts a response of "here, Tim, >>>>> let me take that off your hands". >>>> >>>> I think it's more like the FPGA guy feels you are offensive to the art >>>> of FPGAs. Maybe not truly dangerous, but not the sort of thing an >>>> FPGA guy wants to think about. I haven't worked with you obviously, >>>> I'm just going from your description. :) >>> >>> You're probably right. I believe that I have a pretty good grasp of >>> what's possible with FPGAs, but I'm not an experienced or even a hugely >>> interested practitioner. >> >> I was a bit confused by your description of using HDL. You do use HDL >> now, right? > > Yes, although my favorite HDL is a block diagram and a bunch of math, > handed to someone like you. It works ever so much better for everyone on > the project than me banging out Verilog or VHDL.Yeah, see, that is the part where it gets dangerous. Not trying to be rude, but when you "sort of" know how to do something, that is when mistakes get made. HDL isn't so horribly hard, but there are subtleties that can cause hard to debug problems. When you only do something once in a while and nothing very big, you never really learn all the details. I don't consider myself proficient in Verilog because I have only worked with it a bit. In particular there are a lot of assumptions the tools make when you do arithmetic that need to be understood to get the correct results. I don't know them all and I've never found a good book on the subject, so I stick with VHDL where most everything is explicit with no assumptions. Then VHDL can be cranky if you don't know how to work within the various restrictions. You must not be so bad at HDL. You've gotten along so far without major issues, right? My main gripe with non-FPGA people is the frequent biases they seem to develop that FPGAs have to be power hungry, large and complex to work with. I mostly work with small devices that use little power from a single power supply where the only complexity is in the design itself. Not too many people appreciate these types of devices. As a demonstration I have wanted to design a battery powered WWVB receiver in an FPGA. Will do it some day. -- Rick C
