On 7/29/17 3:32 PM, Mike Perkins wrote:> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote: >> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff: >>> Hi Cecil, >>> >>> >>> Thanks for your reply. >>> >>> >>> I agree it's not a bulk-mode as such. >>> >>> What I meant was that when doing multiple reads one after the other you >>> can stich them together: >>> >>> >>> Correct me if I am wrong, but how I interprete the datasheets, the "read >>> data from the address-bus" can be done at the same time as the "set next >>> address on address-bus". This -I think- means you can "overlap" two >>> concequative reads, resulting in one read per clock cycle. >> >> SRAM doesn't have a clock, you just have to comply with the required >> timing > > There are some forms of clocked SRAM. ZBT was one type introduced by IDT. > > I assume it still exists? > >The datasheet pointed to was a classical Asynchronous Static Ram, which doesn't have a clock. There ARE Synchronous Static Rams which do have a clock pin. Synchronous devices tend to be a bit easier to interface to a synchronous systems, which most FPGA systems tend to be. Sometimes you lose a bit in latency when using them though.
sram
Started by ●July 22, 2017
Reply by ●July 29, 20172017-07-29
Reply by ●July 31, 20172017-07-31
Richard Damon wrote on 7/29/2017 6:06 PM:> On 7/29/17 3:32 PM, Mike Perkins wrote: >> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote: >>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff: >>>> Hi Cecil, >>>> >>>> >>>> Thanks for your reply. >>>> >>>> >>>> I agree it's not a bulk-mode as such. >>>> >>>> What I meant was that when doing multiple reads one after the other you >>>> can stich them together: >>>> >>>> >>>> Correct me if I am wrong, but how I interprete the datasheets, the "read >>>> data from the address-bus" can be done at the same time as the "set next >>>> address on address-bus". This -I think- means you can "overlap" two >>>> concequative reads, resulting in one read per clock cycle. >>> >>> SRAM doesn't have a clock, you just have to comply with the required timing >> >> There are some forms of clocked SRAM. ZBT was one type introduced by IDT. >> >> I assume it still exists? >> >> > > The datasheet pointed to was a classical Asynchronous Static Ram, which > doesn't have a clock. > > There ARE Synchronous Static Rams which do have a clock pin. Synchronous > devices tend to be a bit easier to interface to a synchronous systems, which > most FPGA systems tend to be. Sometimes you lose a bit in latency when using > them though.I don't know the details of how SRAM is constructed, but there was a strong market for it until maybe about 10 years ago. Then growth of SRAM sizes pretty much stopped as new devices dwindled. DRAM has continued to improve at the cutting edge of semiconductor technology along with Flash, but SRAM is now the red headed stepchild. I guess the functionality of SRAM has largely been incorporated internally in FPGAs. If more size is needed than is convenient in FPGAs, DRAM is used. They may have longer latency, but speed is certainly not lacking. -- Rick C
Reply by ●July 31, 20172017-07-31
On 31/07/17 05:26, rickman wrote:> Richard Damon wrote on 7/29/2017 6:06 PM: >> On 7/29/17 3:32 PM, Mike Perkins wrote: >>> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote: >>>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff: >>>>> Hi Cecil, >>>>> >>>>> >>>>> Thanks for your reply. >>>>> >>>>> >>>>> I agree it's not a bulk-mode as such. >>>>> >>>>> What I meant was that when doing multiple reads one after the other >>>>> you >>>>> can stich them together: >>>>> >>>>> >>>>> Correct me if I am wrong, but how I interprete the datasheets, the >>>>> "read >>>>> data from the address-bus" can be done at the same time as the "set >>>>> next >>>>> address on address-bus". This -I think- means you can "overlap" two >>>>> concequative reads, resulting in one read per clock cycle. >>>> >>>> SRAM doesn't have a clock, you just have to comply with the required >>>> timing >>> >>> There are some forms of clocked SRAM. ZBT was one type introduced by >>> IDT. >>> >>> I assume it still exists? >>> >>> >> >> The datasheet pointed to was a classical Asynchronous Static Ram, which >> doesn't have a clock. >> >> There ARE Synchronous Static Rams which do have a clock pin. Synchronous >> devices tend to be a bit easier to interface to a synchronous systems, >> which >> most FPGA systems tend to be. Sometimes you lose a bit in latency when >> using >> them though. > > I don't know the details of how SRAM is constructed, but there was a > strong market for it until maybe about 10 years ago. Then growth of > SRAM sizes pretty much stopped as new devices dwindled. DRAM has > continued to improve at the cutting edge of semiconductor technology > along with Flash, but SRAM is now the red headed stepchild. I guess the > functionality of SRAM has largely been incorporated internally in > FPGAs. If more size is needed than is convenient in FPGAs, DRAM is > used. They may have longer latency, but speed is certainly not lacking. >Roughly speaking, DRAM needs one transistor and a capacitor for a cell - SRAM needs more transistors (4, I think). So SRAM costs a good deal more per bit than DRAM. Once speeds reached the point where bus speeds were the limiting factor for throughput rather than the memory speed, and after DRAM started having internal refresh rather than external refresh (needing active read/re-write cycles from the memory controller), DRAM was almost as fast as SRAM but much cheaper. SRAM still wins out on latency (and lower standby power), but as you say the SRAM has moved on board on devices (FPGAs, caches in processors, on-chip ram in microcontrollers) for even lower latency.
Reply by ●August 1, 20172017-08-01
kristoff wrote:> > I'll start with the simpest setup and after that experiment with using > the falling edge of the clock to clear the /WE signal (option 3). >Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives. I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago: https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076 https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177 That S3 example code can be found here: https://sites.google.com/site/fpgastuff/ram_test.zip The dual-edge I/O primitive for the ICE family would be SB_IO or SB_IO_OD, see: https://www.latticesemi.com/~/media/latticesemi/documents/technicalbriefs/sbticetechnologylibrary201701.pdf -Brian
Reply by ●August 6, 20172017-08-06
On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote:> Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives. > > I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago: > https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076 > https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177 >It's even easier than that to synchronously control a standard async SRAM. Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM. Kevin Jennings
Reply by ●August 6, 20172017-08-06
KJ wrote on 8/6/2017 8:01 AM:> On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote: > >> Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives. >> >> I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago: >> https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076 >> https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177 >> > > It's even easier than that to synchronously control a standard async SRAM. Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM.That would depend a *lot* on the details of the setup and hold times for the async SRAM, no? You can do what you want with data for much of the clock cycle, but the address has to meet setup and hold for the entire WE time. That's typically more than half a clock cycle and makes it hard to use it on every clock cycle. -- Rick C
Reply by ●August 6, 20172017-08-06
Den søndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman:> KJ wrote on 8/6/2017 8:01 AM: > > On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote: > > > >> Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives. > >> > >> I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago: > >> https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076 > >> https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177 > >> > > > > It's even easier than that to synchronously control a standard async SRAM. Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM. > > That would depend a *lot* on the details of the setup and hold times for the > async SRAM, no? You can do what you want with data for much of the clock > cycle, but the address has to meet setup and hold for the entire WE time. > That's typically more than half a clock cycle and makes it hard to use it on > every clock cycle. >and just using the clock give you the headache of trying to control routing delays on data vs. WE using the dual edge output flipflop makes it all much controllable
Reply by ●August 6, 20172017-08-06
On Sunday, August 6, 2017 at 12:40:25 PM UTC-4, rickman wrote:> KJ wrote on 8/6/2017 8:01 AM: > > It's even easier than that to synchronously control a standard async SRAM. Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM. > > That would depend a *lot* on the details of the setup and hold times for the > async SRAM, no? You can do what you want with data for much of the clock > cycle, but the address has to meet setup and hold for the entire WE time. > That's typically more than half a clock cycle and makes it hard to use it on > every clock cycle. >Address (and data) setup and hold times are easily met. As a first order approximation, the setup time will be T/2-Tco(max). The address hold time will be Tco(min). What is your source for statement "That's typically more than half a clock cycle"? The ancient Cypress CY62256N lists both of these requirements (Tsa and Tha) as 0 ns [1]. The technique works. You get single cycle read or write on 100% of the clock cycles, timing is met, period...and it worked 20+ years ago on product I designed [2]. Kevin Jennings [1] http://www.cypress.com/file/43841/download page 7. [2] USPTO 6,169,703 (Patent status = Expired) https://patentimages.storage.googleapis.com/8a/c2/3d/f566f483f9e961/US6169703.pdf
Reply by ●August 6, 20172017-08-06
On Sunday, August 6, 2017 at 1:30:46 PM UTC-4, lasselangwad...@gmail.com wr= ote:> Den s=C3=B8ndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman: >=20 > and just using the clock give you the headache of trying to control routi=ng=20> delays on data vs. WE=20 >=20 > using the dual edge output flipflop makes it all much controllableNot true. There is nothing special that needs to be done to "control routi= ng delays on data vs. WE". Do you have any basis for that statement? Using the method I described is absolutely the same as connecting up two 74= X374 flip flops, nothing more, nothing less. How is that a 'headache'? Kevin Jennings
Reply by ●August 6, 20172017-08-06
KJ wrote on 8/6/2017 1:40 PM:> On Sunday, August 6, 2017 at 1:30:46 PM UTC-4, lasselangwad...@gmail.com wrote: >> Den søndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman: >> >> and just using the clock give you the headache of trying to control routing >> delays on data vs. WE >> >> using the dual edge output flipflop makes it all much controllable > > Not true. There is nothing special that needs to be done to "control routing delays on data vs. WE". Do you have any basis for that statement?As long as the signals are register in the output FFs that's true. But you can't register the clock! So the routing delays will be *very* important if running a fast asynch SRAM. If the dual edge output flipflops are used the clock can in fact be registers in essence giving all signals the same delays within a tolerance.> Using the method I described is absolutely the same as connecting up two 74X374 flip flops, nothing more, nothing less. How is that a 'headache'?Huh? -- Rick C
